Lokalisering af skema-markering til e-handel handler om at få dine strukturerede data til at tale dine kunders sprog og søgemaskiner. For internationale online butikker, især dem, der er målrettet mod forskellige regioner som EU, Sydøstasien eller Mellemøsten, er skema -lokalisering nøglen til at hjælpe søgemaskiner med at levere de rigtige rige uddrag baseret på brugersprog, region og valuta.
Ved at lokalisere nøgleskema -typer, som produktinfo, prisfastsættelse og forretningsdetaljer, forbedrer du synlighed, tillid og konverteringsfrekvens på forskellige markeder. Denne artikel udforsker, hvilke skemaelementer der skal lokaliseres, almindelige fejl at undgå og bedste praksis for at hjælpe dit internationale e-handelswebsted med at fungere bedst.
Betydningen af skema lokalisering for din e-handel
Skema lokalisering sikrer, at dine strukturerede data er i overensstemmelse med sproget, valutaen og kulturel kontekst på hvert marked, du tjener. Dette forbedrer din synlighed i lokale søgeresultater og forbedrer brugeroplevelsen på tværs af forskellige regioner.
- Boosts Local SEO Performance- Når skema-markering bruger lokaliseret sprog, valuta og regionspecifikke felter, kan søgemaskiner bedre forstå og matche dit indhold med lokal søgningsintention.
- Aktiverer nøjagtige rige uddrag- rige uddrag som priser, produkttilgængelighed og anmeldelser afspejler brugerens lokale kontekst, opbygger tillid og forbedrer klikpriser.
- Forbedrer flersproget brugeroplevelse - Lokaliseret skema hjælper med at sikre konsistens mellem det synlige sideindhold og de strukturerede data bag det og undgår forvirring for internationale besøgende.
- Understøtter regional overholdelse og forventninger - forskellige regioner kan have specifikke datakrav (som moms i EU eller forsendelseszoner i Sydøstasien), der kan behandles gennem skema.
- Øger konverteringsfrekvenserne på målmarkeder - brugere, der ser velkendt sprog, valuta og kontaktoplysninger i søgningsforandringer, er mere tilbøjelige til at stole på og engagere sig i dit websted.
Nøgle e-handelsskema-typer, der kræver lokalisering
Skema -markering er en type strukturerede data tilføjet til dit websteds HTML, der hjælper søgemaskiner med at forstå konteksten af dit indhold. For e-handel driver det rige resultater som produktvurderinger, priser, tilgængelighed og mere at få dine lister til at skille sig ud i søgningen. Når du er målrettet mod internationale markeder, er det ikke nok at bruge skema ikke nok, at du også skal lokalisere det.
Nedenfor er de vigtigste skematyper, der har brug for omhyggelig lokalisering for global e-handelssucces.
Produkt
Produktskemaet giver strukturerede oplysninger såsom produktnavn, beskrivelse, SKU, brand, image og anmeldelser. Når man lokaliserer dette skema, er det vigtigt at oversætte produktnavne og beskrivelser nøjagtigt, ikke kun ord-for-ord, men på en måde, der resonerer med hvert markeds kulturelle og sproglige normer.
Flere nøgleelementer skal tilpasses til hvert målmarked for at lokalisere produktskemaet korrekt. Disse elementer går ud over grundlæggende oversættelse-kulturel tilpasning, overholdelse af lokale forventninger og tilpasning til sprogspecifik SEO. Her er de vigtigste aspekter af det produktskema, der skal lokaliseres.
- Navn: Oversæt produktnavnet for at bevare mening og appel på det lokale sprog. Undgå bogstavelige oversættelser, der kan forvirre eller vildlede lokale publikum.
- Beskrivelse: Lokaliserer beskrivelser med opmærksomhed på tone, måleenheder (f.eks. Inches vs. centimeter) og terminologi, der er kendt for regionale publikum.
- Billede: Selvom det ikke er tekstbaserede, kan lokaliserede billeder afspejle kulturelle præferencer. For eksempel kan tøjbilleder på Mellemøstlige markeder muligvis kræve mere beskedne visuals.
- Brand: Hvis mærket har forskellige navne i forskellige regioner, eller hvis undermærker er mere genkendelige lokalt, skal du sikre dig, at brandfeltet afspejler det.
- SKU: Selvom du ofte er konsistent globalt, hvis du bruger regionale produktkoder eller identifikatorer, skal du opdatere SKU for at matche det lokale katalog.
- Gennemgang og aggregaterering: Disse elementer kan også drage fordel af lokalisering. Hvis kundevurderinger er inkluderet i skema, skal du sikre dig, at de er skrevet på det lokale sprog og afspejler regionspecifik kundefeedback.
- Tilbud (indlejret i produktet): Dette inkluderer prisfastsættelse og tilgængelighed, der skal afspejle lokal valuta, formater og aktieniveau. Overvej også at tilpasse Pricevaliduntil til lokale salgscyklusser.
For eksempel kan et "Winter Coat - Arctic Series" -produkt på engelsk være lokaliseret som "Chaqueta Invernnal - Serie ártica" på spansk. På arabiske markeder skal navnet og beskrivelsen ikke kun oversættes til arabisk, men du kan også være nødt til at tilpasse billeder og indeholde højdepunkter til det, der betragtes som tiltalende eller beskedent.
Manglende lokalisering af produktskemaet kan skabe et misforhold mellem hvad der vises i søgestykket og hvad der er på selve produktsiden, beskadiget tillid og skade klikfrekvenser. Ved at skræddersy dit produktskema pr. Lokale sikrer du konsistens, bedre SEO -justering og en glattere shoppingoplevelse.
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "Chaqueta Invernal – Serie Ártica",
"description": "Una chaqueta cálida ideal para el invierno, con capucha desmontable y bolsillos amplios.",
"sku": "ARCTIC-ES",
"image": "https://example.com/es/images/arctic-coat.jpg",
"brand": {
"@type": "Brand",
"name": "FrostWear"
}
}
Her er et eksempel på markering af produktskema, der vises online, når du søger efter et produkt.
Prisfastsættelse og valuta
Prisfastsættelse er et af de mest følsomme informationsstykker for online shoppere. Tilbudskemaet, typisk indlejret i produktskemaet, inkluderer nøglefelter såsom pris, rensning og tilgængelighed. Lokalisering af valuta og prisfastsættelse er afgørende, især når dit websted er målrettet mod regioner, der ikke bruger USD, EUR eller andre standardstandard.
For eksempel, hvis du sælger i Mellemøsten, skal dit skema afspejle priserne i AED eller SAR ved hjælp af den relevante ISO 4217 valutakode, som "Pricecurrency": "AED". Derudover skal prisformatet følge regionale konventioner - nogle lande bruger kommaer i stedet for perioder som decimalseparatorer eller placere valutasymbolet efter beløbet i stedet for før.
Forkerte eller generiske valutakoder i skema -markering kan føre til vildledende rige uddrag, forvirrede shoppere og endda sanktioner for søgemaskiner for datainkonsistens. Dit skema skal synkronisere med, hvad brugerne ser i frontend og afspejler konverteringshastigheder i realtid eller lokaliserede prisstrategier. Tilpasning af dette skema pr. Sprog eller regionalt underdomæne er vigtigt for at sikre nøjagtig repræsentation på tværs af dit flersprogede websted. Nøgleelementer i prisskemaet, der skal lokaliseres.
- Pris: Numerisk prisværdi formateret for den lokale region (f.eks. 99,99 i stedet for 99,99).
- Pricecurrency: Brug den rigtige ISO 4217 valutakode (f.eks. AED, SAR, JPY osv.).
- Valutasymbolplacering: Tilpas symbol til lokale konventioner (f.eks. “99 ر.س” i stedet for “SAR 99”).
- Tilgængelighed: Brug lokaliseret sprog eller etiketter, hvis relevant (f.eks. "På lager" → "disponibel" på spansk).
Her er et eksempel på et lokaliseret skema til priser, der er skræddersyet til et Mellemøstlig marked.
{
"@context": "https://schema.org/",
"@type": "Offer",
"price": "89.99",
"priceCurrency": "EUR",
"availability": "https://schema.org/InStock",
"priceValidUntil": "2025-12-31",
"itemCondition": "https://schema.org/NewCondition",
"url": "https://example.com/es/productos/chaqueta-artica"
}
Her er et eksempel på prisfastsættelse og valutakema -markering, der vises online, når man søger efter et produkt.
Forretningsoplysninger
Organisationen og kontaktpoint -skemaerne definerer din forretningsidentitet, og hvordan kunder kan nå dig. Lokalisering her involverer mere end bare oversættelse - det kræver tilpasning af åbningstider, supportsprog og kontaktmetoder, der passer til lokale forventninger.
Lokalisering af forretnings- og kontaktskema, forbedrer du tillid og hjælper søgemaskiner med at vise nøjagtige kontaktoplysninger i SERP'er (især på mobil). Dette hjælper også stemmesøgning og intelligente assistenter med at tilbyde korrekte forretningsresponser baseret på placering. Et godt lokaliseret skema sikrer, at kunderne ser de rigtige kontaktmuligheder på det rigtige tidspunkt, tilpasset deres sprog, region og foretrukne kommunikationsmetoder.
De vigtigste elementer i organisationen og kontaktpoint -skemaer, der skal lokaliseres, inkluderer.
- Navn: Oversæt eller tilpas virksomhedsnavnet, hvis du bruger en lokal brandidentitet i forskellige regioner.
- ContactType: Brug lokaliserede udtryk for typer support (f.eks. “Servicio al Cliente” på spansk).
- Telefon: Medtag lokale supportnumre med passende internationale formater.
- Arealserved: Specificer målregionen ved hjælp af ISO-koder for at sikre geo-relation.
- TILGÆNGELIGHED: Angiv, hvilke sprog dit supportteam kan håndtere (f.eks. Engelsk, arabisk, fransk).
- ContactOption: Tilføj regionspecifikke kontaktmetoder såsom WhatsApp, WeChat eller lokale chatværktøjer.
- URL: Punktbrugere til lokaliseret hjælp eller kontaktsider, hvis de er tilgængelige.
Ved at skræddersy hvert af disse felter til hver målregion, vil dit skema imødekomme lokale forventninger og øge chancerne for at blive vist i relevante søgeresultater, især dem, der er afhængige af mobile eller stemmeinteraktioner. Følgende er et eksempel på anvendelse af skemaet.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "YourBusiness",
"url": "https://www.yourbusiness.com",
"contactPoint": {
"@type": "ContactPoint",
"telephone": "+33-1-23-45-67-89",
"contactType": "customer support",
"areaServed": "FR",
"availableLanguage": ["en", "fr"]
}
}
Forsendelse og leveringsdetaljer
Leveringsforventninger og regler varierer markant fra land til land. Ved at bruge skema-typer såsom leveringstider, forsendelsesdeleveringstid eller tilbyder afhipDetails, der er regionspecifikke, kan du ikke kun kommunikere tilgængelighed og estimerede leveringstider, men også regioner, der serveres, forsendelsesrater og håndtering af tider, som alle skal lokaliseres for hvert marked. Forsendelsesskemaelementer, der skal lokaliseres, inkluderer.
- ShippingDestination: Region eller land serveret.
- Leveringstid: Estimeret leveringstid i lokalt format (f.eks. 2 dage mod 5-7 arbejdsdage).
- Forsendelsesrate: Forsendelsesrate i lokal valuta.
- Transittimelabel: Etiket brugt til at beskrive leveringstiden (såsom "Express", "Regelmæssig" eller "Levering inden for 24 timer").
- Håndteringstid: Behandlingstid inden leveringen begynder.
For eksempel kan en kunde i Tyskland forvente levering inden for 3 arbejdsdage, mens et typisk skøn i Indonesien kunne være 5-7 dage. Hvis forsendelsesordningen ikke er lokaliseret, får brugerne muligvis ikke relevant info i søgeresultaterne, hvilket får dem til at tøve med at købe. Her er et eksempel på, at ObSserhippingDetails lokaliseres til det tyske marked.
{
"@context": "https://schema.org",
"@type": "OfferShippingDetails",
"shippingDestination": {
"@type": "DefinedRegion",
"name": "Germany"
},
"deliveryTime": {
"@type": "ShippingDeliveryTime",
"handlingTime": {
"@type": "QuantitativeValue",
"minValue": 1,
"maxValue": 2,
"unitCode": "d"
},
"shippingRate": {
"@type": "MonetaryAmount",
"value": "5.00",
"currency": "EUR"
}
}
Butikplacering og lokal forretningsinfo
Nøjagtigt at vise butiksplaceringer i Google-søgning eller Google Maps afhænger stærkt af godt lokaliseret lokalbusiness-skema. Især når brugerne søger på deres lokale sprog eller region, har de rigtige oplysninger øget synligheden og bygger tillid. De vigtigste elementer i det lokale forretningskema, der har brug for lokalisering, inkluderer.
- Navn: Forretningsnavnet oversættes, hvis det er relevant for den lokale kontekst.
- Adresse: Den adresse, der er formateret i henhold til lokale konventioner, herunder adresselokalitet, adresseregion, postalkode og adresselountry.
- Telefon: Telefonnummeret ved hjælp af den korrekte landekode og lokal formatering.
- Åbning afhours -specifikation: Driftstider justeres til lokale tidszoner og forretningsvaner.
- Geo: Geografiske koordinater (breddegrad og længdegrad) af butikens placering.
- Områderede: Den region eller det område, som virksomheden tjener.
For eksempel er her et skemauddrag til en butik, der opererer i Berlin, Tyskland.
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Modehaus Berlin",
"address": {
"@type": "PostalAddress",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"telephone": "+49 30 12345678",
"openingHours": "Mo-Fr 10:00-19:00"
}
Følgende er et eksempel på en lokal forretningsmarkup -ordning.
Breadcumb -navigation
Brødkrumblistskemaet hjælper med at definere dit websteds navigationsstruktur, der viser brugere (og søgemaskiner), hvor de er inden for webstedets hierarki. Selvom dette kan virke ligetil, er det kritisk at lokalisere brødkrummer på et flersproget e- handelswebsted for at sikre konsistens, forbedre SEO og forbedre brugeroplevelsen.
For eksempel en brødkrumme på engelsk, spansk og arabisk
- “Hjem> Mænds mode> Jakker”
- “Inicio> Moda Masculina> Chaquetas”,
- “الرئ> أزاء الرجال> المعاطف”.
Antag, at brødkrummeskemaet er på engelsk, mens sideindholdet er på et andet sprog. I dette tilfælde kan brugerne opleve forvirring, og søgemaskiner kan kæmpe for at indeksere det lokaliserede indhold korrekt. Det kan også skade din interne sammenkoblingsstrategi, da brødkrummer påvirker, hvordan Link Equity flyder gennem dit websted.
Nøgleelementer i brødkrumblisteskemaet, der har brug for lokalisering.
- ItemListElement.Name: Det synlige navn på hvert brødkrummniveau skal oversættes.
- ItemListElement.Item: URL'en skal pege på den korrekte lokaliserede version af hver side.
- Position: afspejler niveauet i brødkrummesporet (forbliver normalt det samme, men skal svare til lokaliseret struktur).
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Inicio",
"item": "https://example.com/es/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Moda Masculina",
"item": "https://example.com/es/moda-masculina"
},
{
"@type": "ListItem",
"position": 3,
"name": "Chaquetas",
"item": "https://example.com/es/moda-masculina/chaquetas"
}
]
}
Følgende er et eksempel på en markering af brødkrumme.
Almindelige fejl i skema-lokaliseringen til e-handel
Virksomheder støder ofte på kritiske, men alligevel undgåelige problemer, når man lokaliserer skema-markering til e-handelswebsteder. Mange antager, at oversættelse alene er tilstrækkelig, men strukturerede data skal tilpasses fuldt ud til hver regions sprog, valuta og brugerforventninger. Disse oversigter kan føre til ødelagte rige uddrag, dårlig søgesynlighed eller brugerforvirring.
Nedenfor er nogle af de mest almindelige fejl i skema -lokaliseringen - og hvorfor man undgår dem kan påvirke dit websteds ydelse og brugeroplevelse markant.
Brug kun et sprog eller valuta
En af de hyppigste fejltagelser i lokaliseringen af e-handelsskemaet holder sig til et enkelt sprog eller valuta i hele webstedets strukturerede data-selv når front-end-indholdet oversættes. Denne uoverensstemmelse forvirrer både brugere og søgemaskiner. En shopper i Frankrig kan muligvis læse produktbeskrivelser på fransk, men se skema, der stadig henviser til USD i stedet for EUR, hvilket kan forårsage tillidsspørgsmål.
Lokaliseret skema skal afspejle de oversatte indhold og lokale valutaformater. F.eks. SKAL "EKSEKURCENCY": "EUR" erstatte "eCercurrency": "USD" på den franske version af webstedet, og "Navn" og "Beskrivelse" -felterne i produktskemaet skal vises på fransk. Uden dette kan søgemaskiner muligvis ikke vise dine lokaliserede lister nøjagtigt i søgeresultater.
Ignorering af sprog- og valutaklokalisering fører til stakkels Rich Strappet-forhåndsvisninger, reducerer klikfrekvenser og kan endda krænke retningslinjer for struktureret datanøjagtighed. Skræddersy altid dit skema pr. Sprog og region ved hjælp af hreflang og regionspecifikke underdomæner eller stier.
Opdaterer ikke valutakoder korrekt
Mange glemmer at opdatere valutakoden i skema -markeringen, selv når købmænd bruger det korrekte lokaliserede valutasymbol på frontend. Schema.org bruger standardiserede ISO 4217 -koder (som "USD" for amerikanske dollar eller "JPY" til japansk yen), og at de ikke afspejler disse korrekt i "pricecurrency" fører til ødelagte eller vildledende rige resultater.
For eksempel, hvis din butik i UAE viser priser i Dirhams, men stadig bruger "Pricecurrency": "USD" i skema, kan Google muligvis fejlagtigt fortolke produktprisen eller vælge ikke at vise den overhovedet. Værre er det, at en kunde kan antage, at et produkt er billigere eller dyrere på grund af forkert valutakontekst, hvilket fører til afvisningsrater eller forladte vogne.
Altid dobbeltkontrol valutaværdier i dit skema, især for butikker med flere valutaer ved hjælp af geolocation eller valutakontakt. Tilpasning af visuel og struktureret valutainformation forbedrer søgningsudseende og kundetillid.
Spring over regionspecifikke skemaområder
En anden fejltagelse er at bruge generisk skema på tværs af regioner uden at inkorporere regionspecifikke elementer som "forsendelsesdestination", "områder, der er" eller "tilgængeligt" fra ". Disse felter er kritiske for at kommunikere logistik og servicedækning, især inden for international forsendelse eller lokal kundesupport.
For eksempel bør shoppere i Australien se estimater og levering af leveringstid og leveringsmuligheder baseret på lokale standarder (f.eks. "ShippingDestination": {"@Type": "DefinedRegion", "Navn": "Australien"}). At udelade sådanne detaljer kan føre til, at søgemaskiner antager, at du ikke sender der, der påvirker opdagelsen i lokal søgning.
Derudover hjælper felter som "områder, der er" og "tilgængelige" fra ", din virksomhed til" i nærheden af mig "eller regionbaserede søgninger. Hvis du ikke bruger disse skema -felter på regionale sider, går du sandsynligvis glip af lokaliserede søgemuligheder.
Ignorerer RTL -sprogstøtte
Sprog som arabisk og hebraisk læsning fra højre til venstre (RTL), og at undlade at justere skema -markering for at redegøre for dette kan forårsage læsbarhed og SEO -problemer. Selvom skema ikke er visuelt gengivet, skal det stadig afspejle den sproglige kontekst for at matche on-side-oplevelsen og søgesproget målretning.
F.eks. Skal felterne "Navn" og "Beskrivelse" i produktskemaet på en arabisk side oversættes passende og kodes ved hjælp af det korrekte Unicode -format. Derudover skal siden selv bruge lang = ”ar” og dir = ”rtl” i HTML, og skemaet skal matche det samme.
Forsømmelse af RTL -støtte forårsager inkonsekvens mellem det visuelle og strukturerede indhold, potentielt forvirrende brugere og påvirker det rige resultatberettigelse. Sørg altid for, at både sprog- og læsningsretningen afspejles i skema -strukturen.
Mangler oversatte brødkrummer
Brødkrummer fungerer som navigationshjælpemidler og bidrager væsentligt til intern link og SEO. En almindelig fejl i skema -lokaliseringen er at holde brødkrummeskemaet på originalsproget, selv når den synlige navigationssti oversættes.
For eksempel, hvis din side viser "Inicio> Moda Femenina> Vestidos" (spansk til "Home> Women's Fashion> kjoler"), skal dit brødkrumblistskema spejle dette nøjagtigt. Brug af “Navn”: “Hjem” i stedet for “Inicio” skaber en afbrydelse og kan have negativ indflydelse på, hvordan Google fortolker stedstrukturen.
Hvert brødkrummniveau ("navn") skal lokaliseres, og det tilsvarende "emne" skal linke til den lokaliserede URL. At holde alt tilpasset sikrer konsistens for brugere og crawlere, hvilket forbedrer synligheden og indekseringen.
Genbruger det samme skema for alle sprog
Den mest skadelige fejl er at bruge en skema-tilgang i én størrelse, der passer til alle, på tværs af alle sprog. Genbrug af de samme strukturerede data uden at tilpasse indhold, valuta, sprog og regionkontekst besejrer hele formålet med lokaliseringen .
Hver lokaliseret version af dit websted skal have sit skema, der afspejler det lokale indhold og metadata. For eksempel, hvis du har separate produktsider til engelsk og fransk, burde deres produktskema have oversat "navn", "beskrivelse", "eCercurrency" og endda sprogspecifikke URL'er.
At forsømme denne praksis kan resultere i modstridende søgesignaler, dårlig uddragskvalitet eller endda manuelle handlinger til vildledende strukturerede data. En bedste praksis er at opretholde separate skemaer for hvert sprog underdomæne eller hreflang-mærket version, hvilket sikrer, at de strukturerede data stemmer overens med sproget og regionen, der serveres.
Bedste praksis til lokalisering af skema-markering til e-handel
Skema -markering spiller en afgørende rolle i, hvordan søgemaskiner fortolker og viser dit indhold. Når det er lokaliseret korrekt, øger det din synlighed i lokale SERP'er, forbedrer klikfrekvenser og forbedrer shoppingoplevelsen for brugere over hele verden.
Her er den bedste praksis, som enhver global e-handelsvirksomhed skal følge for at få mest muligt ud af lokaliseringen.
Brug sprogspecifikt skema pr. Side
Hver sprogversion af dit websted skal omfatte skema -markering på det specifikke sprog. Hvis du bruger underdomæner eller undermapper (f.eks. Eksempel.com/en/ for engelsk og eksempel.com/de/ for tysk), skal hver indeholde et unikt, sprog-passende skema.
Hvis din tyske side stadig bruger skema på engelsk, kan Google muligvis kæmpe for at forstå sidens lokale kontekst, og brugere kan finde oplevelsen uforenelig med deres forventninger, for eksempel som nedenfor.
Land | Skema felt | Lokaliseret værdi |
/FR/produktside | "navn" | “Veste d'Hiver Pour Homme” |
"beskrivelse" | “Une Veste Chaude Pour L'Hiver Français” | |
“Inlanguage” | “FR” |
Lokaliser produktnavne og beskrivelser
Produktnavne og beskrivelser bør ikke kun oversættes og kulturelt tilpasses. Sætninger, der lyder tiltalende i et land, kan muligvis ikke resonere i et andet. Brug naturligt sprog til lokale målgrupper og tilpasser sig deres shoppingadfærd.
Stol på indfødte oversættere eller lokale eksperter for at undgå akavet formulering eller uklar besked. Felter som navn, beskrivelse og brand i dit skema skal afspejle det lokale sprog og præferencer.
Sprog | navn | beskrivelse |
engelsk | “Mænds slanke jakke” | “En stilfuld jakke perfekt til vinteren” |
japansk | “メンズウィンタージャケット” | “冬に最適なおしゃれなジャケットです。” |
Indstil en nøjagtig pris og valuta
Pris er et følsomt emne inden for e-handel. Konverter ikke bare valutaer visuelt på dit websted - sørg for, at dit skema afspejler nøjagtigt den korrekte valuta ved hjælp af ISO 4217 -koden i feltet Pricecurrency. Priserne skal også formateres i henhold til lokale konventioner, herunder decimaler og tusind separatorer.
Undgå kun at vise USD på tværs af alle sprogversioner, da dette kan forvirre brugere eller erodere tillid. Hvis du bruger valutakonvertering i realtid, skal du være sikker på, at dit skema forbliver synkroniseret. For eksempel.
Land | pris | Pricecurrency | Lokalt format |
Japan | 4500 | JPY | ¥4,500 |
Saudi -Arabien | 180 | Sar | 180 ر.س |
Lokaliser forretningsinfo
Forretningskontaktoplysninger, såsom adresser, telefonnumre og åbningstider, skal lokaliseres efter region. Brug lokale formater til felter som AdressLocality, Postalcode og AddressCountry. Medtag internationale opkaldskoder i telefonnumre for at gøre det lettere for brugerne at kontakte dig.
Felter som åbning afhours -specifikation bør afspejle lokale tidszoner og forretningspraksis. Disse detaljer hjælper med at etablere tillid og forbedre din virksomheds udseende i lokale søgeresultater. For eksempel.
Land | adresselokalitet | Postalkode | åbning afhoursformat |
Spanien | Barcelona | 08001 | MO-FR 09: 00–18: 00 |
Thailand | Chiang Mai | 50000 | Mo-Sa 10: 00–19: 00 |
Strukturskema til RTL -sprog
Sprog som arabisk og hebraisk er skrevet fra højre til venstre (RTL). Mens JSON-LD selv ikke afhænger af visuel formatering, er ethvert skemafelt, der indeholder synlig tekst-såsom navn, beskrivelse eller brødkrumme-skal afspejle det rigtige sprog og retning for at undgå uoverensstemmelser mellem indholdet og markeringen.
Hvis din side er på arabisk, men skemaet indeholder stadig engelske værdier eller venstre til højre indhold, kan det føre til forvirring for både brugere og søgemaskiner. Sørg altid for, at HTML inkluderer Lang = ”AR”, og at de strukturerede datafelter er lokaliseret i overensstemmelse hermed.
Felt | Ikke-lokaliseret (LTR/engelsk) | Lokaliseret (RTL/arabisk) |
navn | Vinterjakke | معطف ش |
beskrivelse | En varm frakke til vinteren | معطف دافئ مثالي لفصل الشاء |
brødkrumme | Hjem> Tøj> Jakker | الرئ> الملاب> المعاطف |
Automatiser skema lokalisering med Linguise
Lokalisering af skema -markering manuelt på tværs af flere sprog kan være komplekse, især når man administrerer hundreder af dynamiske produktsider. Det synlige indhold og de strukturerede data, inklusive produktet, tilbud, brødkrumblist og lokalbusiness -skemaer, skal oversættes. Rige uddrag afspejler muligvis ikke det korrekte sprog, valuta eller struktur for hver region uden ordentlig lokalisering.
Linguise tilbyder en automatisk oversættelsesløsning , der udvides til strukturerede data, oversættelse af skema -markering og dit indhold. Gennem sin Live Editor kan du manuelt finjustere skemaindhold såsom produktnavne, beskrivelser eller brandværdier for at sikre, at de nøjagtigt afspejler den lokale kontekst. Dette er især nyttigt, når man lokaliserer produktskema -felter, der kræver kulturel nuance og nøgleordstilpasning til regional SEO.
Derudover understøtter Linguise oversættelse af links og medier, hvilket muliggør lokalisering af brødkrumme -URL'er, interne links og endda billedreferencer. Dette sikrer, at alle elementer, navigationsstier, aktiver og strukturerede data - er tilpasset den rigtige sprogversion, hvilket hjælper søgemaskiner med at levere mere nøjagtige og relevante rige resultater til brugere over hele verden.
Konklusion
Lokalisering af skema-markering er afgørende for internationale e-handelsvirksomheder, der sigter mod at forbedre synligheden i lokale søgeresultater, forbedre rige uddrag og give brugerne en problemfri flersproget oplevelse. Fra produktnavne og prisfastsættelse til forsendelsesoplysninger og forretningsoplysninger, skal hvert stykke strukturerede data tilpasse sig hvert målmarkeds sprog, kultur og forventninger.
For at strømline denne proces skal du overveje at bruge Linguise - en oversættelsesløsning, der ikke kun automatiserer indholdsoversættelse, men også tilpasser din skema -markering, links og medier pr. Sprog. Med funktioner som Live Editor og oversættelse til URL'er og billeder brug af Linguise hjælpe hele dit websted-synligt indhold og strukturerede data er fuldt lokaliseret og SEO-klar.
