Lokalisering af skemaopmærkning til e-handel handler om at få dine strukturerede data til at tale dine kunders og søgemaskiners sprog. For internationale onlinebutikker, især dem der målretter mod forskellige regioner som EU, Sydøstasien eller Mellemøsten, er skemalokalisering nøglen til at hjælpe søgemaskiner med at levere de rigtige rige snippets baseret på brugerens sprog, region og valuta.
Ved at lokalisere nøgle-skematyper, såsom produktinformation, prissætning og forretningsdetaljer, øger du synlighed, tillid og konverteringsrater på forskellige markeder. Denne artikel udforsker, hvilke skemaelementer der skal lokaliseres, almindelige fejl, der skal undgås, og bedste praksis for at hjælpe din internationale e-handelsside med at præstere på sit bedste.
Vigtigheden af skemalokalisering for din e-handel

Tilpasning af skema sikrer, at dine strukturerede data stemmer overens med sprog, valuta og kulturel kontekst på hvert marked, du betjener. Dette forbedrer din synlighed i lokale søgeresultater og forbedrer brugeroplevelsen på tværs af forskellige regioner.
- Forbedrer lokal SEO ydeevne – Når skema-mærkning bruger lokaliseret sprog, valuta og regionspecifikke felter, kan søgemaskiner bedre forstå og matche dit indhold med lokal søgeintention.
- Aktiviserer nøjagtige rige snippets – Rige snippets som priser, produkt tilgængelighed og anmeldelser vil afspejle brugerens lokale kontekst, opbygge tillid og forbedre klikfrekvenser.
- Forbedrer flersproget brugeroplevelse – Lokaliseret skema hjælper med at sikre konsistens mellem det synlige sideindhold og de strukturerede data bagved, undgår forvirring for internationale besøgende.
- Understøtter regional overholdelse og forventninger – Forskellige regioner kan have specifikke krav til data (som moms i EU eller leveringszoner i Sydøstasien), som kan håndteres via schema.
- Øger konverteringsraten på målmærker – Brugere, der ser velkendte sprog, valuta og kontaktoplysninger i søgepreview, er mere tilbøjelige til at stole på og engagere sig med din side.
Nøgletyper af e-handelsschema, der kræver lokalisering

Schema-opmærkning er en type struktureret data, der tilføjes din hjemmesides HTML, og som hjælper søgemaskiner med at forstå konteksten af dit indhold. For e-handel giver det rige resultater som produktbedømmelser, priser, tilgængelighed og mere, hvilket får dine lister til at skille sig ud i søgninger. Når du målretter internationale markeder, er det ikke nok blot at bruge schema; du skal også lokalisere det.
Nedenfor er de vigtigste schema-typer, der kræver omhyggelig lokalisering for succes med global e-handel.
Produkt

Produkt-skemaet giver struktureret information såsom produktnavn, beskrivelse, SKU, mærke, billede og anmeldelser. Når dette skema lokaliseres, er det vigtigt at oversætte produktnavne og beskrivelser præcist, ikke kun ord for ord, men på en måde, der giver genklang hos hvert markeds kulturelle og sproglige normer.
Flere nøgleelementer skal tilpasses hver målgruppe for at lokalisere Produkt-skemaet 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 vigtige aspekter af Produkt-skemaet, der bør lokaliseres.
- navn: Oversæt produktnavnet for at bevare betydning og appel på det lokale sprog. Undgå bogstavelige oversættelser, der kan forvirre eller vildlede lokale målgrupper.
- beskrivelse: Tilpas beskrivelser med opmærksomhed på tone, måleenheder (f.eks. tommer vs. centimeter) og terminologi, der er velkendt for regionale målgrupper.
- billede: Selvom det ikke er tekstbaseret, kan lokaliseret billedmateriale afspejle kulturelle præferencer. For eksempel kan beklædningsbilleder på mellemøstlige markeder kræve mere beskedne visuals.
- mærke: Hvis mærket har forskellige navne i forskellige regioner, eller hvis undermærker er mere genkendelige lokalt, skal du sikre, at mærkefeltet afspejler det.
- varenummer: Selvom det ofte er konsistent globalt, hvis du bruger regionale produktkoder eller identifikatorer, skal du opdatere varenummeret, så det matcher den lokale katalog.
- anmeldelse og sammenfattende vurdering: Disse elementer kan også have gavn af tilpasning. Hvis kundeanmeldelser er inkluderet i skema, skal du sikre, at de er skrevet på det lokale sprog og afspejler regionspecifik kundetilbageføring.
- tilbud (indlejret i Produkt): Dette omfatter pris og tilgængelighed, som skal afspejle lokal valuta, formater og lagerniveauer. Overvej også at tilpasse priceValidUntil til lokale salgskurser.
For eksempel kan et produkt ved navn “Vinterfrakke – Arktisk Serie” på engelsk blive lokaliseret som “Chaqueta Invernal – Serie Ártica” på spansk. På det arabiske marked skal ikke kun navn og beskrivelse oversættes til arabisk, men du skal muligvis også tilpasse billeder og fremhævede funktioner, så de passer til hvad der anses for attraktivt eller beskedent.
Manglende lokalisering af produkt-skemaet kan skabe et misforhold mellem hvad der vises i søge-snippet og hvad der er på den faktiske produkt-side, hvilket kan skade tilliden og mindske klik-frekvensen. Ved at tilpasse dit produkt-skema pr. lokalitet sikrer du konsistens, bedre SEO-justering og en mere jævn købsoplevelse.
{
"@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å produktskema-opmærkning, der vises online, når der søges efter et produkt.

Prisfastsættelse og valuta

Prissætning er en af de mest følsomme informationer for online-kunder. Offer-skemaet, som typisk er indlejret i produkt-skemaet, indeholder nøglefelter som pris, prisvaluta og tilgængelighed. Lokalisering af valuta og prissætning er afgørende, især når din hjemmeside retter sig mod regioner, der ikke bruger USD, EUR eller andre standard-valutaer.
For eksempel, hvis du sælger i Mellemøsten, skal dit skema afspejle priser 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 komma i stedet for punktum som decimaladskiller eller placerer valutasymbolet efter beløbet i stedet for før.
Forkerte eller generiske valutakoder i skema-opmærkning kan føre til vildledende rich snippets, forvirrede kunder og endda straffeforanstaltninger fra søgemaskiner på grund af inkonsistente data. Dit skema bør synkroniseres med, hvad brugerne ser på front-end, og afspejle realtids-kurser eller lokaliserede prissætningsstrategier. Tilpasning af dette skema pr. sprog eller regionalt underdomæne er afgørende for at sikre en nøjagtig repræsentation på tværs af din flersprogede hjemmeside. Nøgleelementer i prissætnings-skemaet, der skal lokaliseres.
- pris: Numerisk prisværdi formateret til den lokale region (f.eks. 99,99 i stedet for 99.99).
- priceCurrency: Brug den korrekte ISO 4217-valutakode (f.eks. AED, SAR, JPY osv.).
- Valutasymbolplacering: Tilpas symbolet til lokale konventioner (f.eks. “99 ر.س” i stedet for “SAR 99”).
- Tilgængelighed: Brug lokaliseret sprog eller etiketter, hvis det er relevant (f.eks., “På Lager” → “Disponible” på Spansk).
Her er et eksempel på et lokaliseret skema til prissætning, der er tilpasset til Mellemøsten-markedet.
{
"@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å prissætning og valuta-skema markup, der vises online, når der søges efter et produkt.

Forretnings- og kontaktinformation
Organisationen og ContactPoint-skemaerne definerer din forretningsidentitet og hvordan kunderne kan nå dig. Lokalisering her involverer mere end blot oversættelse - det kræver tilpasning af forretningsåbningstider, supportsprog og kontaktmetoder til lokale forventninger.
Ved at lokalisere forretnings- og kontaktskema kan du forbedre tilliden og hjælpe søgemaskiner med at vise nøjagtige kontaktinformationer i SERPs (især på mobil). Dette hjælper også stemmesøgning og intelligente assistenter med at tilbyde korrekte forretningsresponser baseret på lokation. Et veltilpasset skema sikrer, at kunderne ser de rigtige kontaktmuligheder på det rigtige tidspunkt, tilpasset til deres sprog, region og foretrukne kommunikationsmetoder.
Nøgleelementer i Organisation- og Kontaktpunkt-skemaerne, der skal lokaliseres, omfatter.
- navn: Oversæt eller tilpas virksomhedens navn, hvis du anvender en lokal brandidentitet i forskellige regioner.
- kontaktType: Brug lokaliserede termer for typer af support (f.eks. “kundeservice” på dansk).
- telefon: Inkluder lokale supportnumre med korrekte internationale formater.
- områdeBetjent: Angiv målregionen ved hjælp af ISO-koder for at sikre geo-relevans.
- availableLanguage: Angiv hvilke sprog dit supportteam kan håndtere (f.eks. engelsk, arabisk, fransk).
- kontaktMulighed: Tilføj regionspecifikke kontaktmetoder som WhatsApp, WeChat eller lokale chat-værktøjer.
- url: Peg brugere på lokaliserede hjælpe- eller kontaktsider, hvis tilgængelige.
Ved at skræddersy hvert af disse felter til hver målregion, vil dit skema opfylde lokale forventninger og øge chancerne for at blive vist i relevante søgeresultater, især dem der er afhængige af mobil- 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"]
}
}
Forsendelses- og leveringsdetaljer
Leveringsforventninger og regler varierer betydeligt fra land til land. Ved at bruge skematyper som DeliveryTimeSettings, ShippingDeliveryTime eller OfferShippingDetails, der er regionspecifikke, kan du ikke kun kommunikere tilgængelighed og estimerede leveringstider, men også serviceregioner, forsendelsespriser og håndteringstider - alt sammen skal lokaliseres for hvert marked. Forsendelsesschemaelementer, der skal lokaliseres, omfatter.
- leveringsdestination: område eller land der betjenes.
- leveringstid: estimeret leveringstid i lokalt format (f.eks. 2 dage vs. 5-7 hverdage).
- leveringsomkostninger: leveringsomkostninger i lokal valuta.
- transitTimeLabel: mærkat brugt til at beskrive leveringstiden (såsom “Ekspres”, “Normal” eller “Levering inden for 24 timer”).
- håndteringstid: behandlingstid før levering begynder.
For eksempel kan en kunde i Tyskland forvente levering inden for 3 hverdage, mens det i Indonesien kan være 5-7 dage. Hvis leveringsordningen ikke er tilpasset lokale forhold, får brugerne måske ikke relevante oplysninger i søgeresultaterne, hvilket gør dem tøvende over for at købe. Her er et eksempel på OfferShippingDetails tilpasset 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"
}
}
Butikslokation & lokal forretningsinformation
En præcis visning af butikssteder i Google Søgning eller Google Maps afhænger i høj grad af et veltilpasset LocalBusiness-skema. Især når brugere søger på deres lokale sprog eller i deres region, øger korrekte oplysninger synligheden og skaber tillid. Nøgleelementer i LocalBusiness-skemaet, der kræver tilpasning, omfatter.
- navn: forretningsnavnet oversættes hvis relevant for den lokale kontekst.
- adresse: adressen formateret efter lokale konventioner, inklusive addressLocality, addressRegion, postalCode og addressCountry.
- telefon: telefonnummer med korrekt landekode og lokal formatering.
- åbningstiderSpecification: Åbningstiderne tilpasses lokale tidszoner og forretningsvaner.
- geo: geografiske koordinater (breddegrad og længdegrad) for butikkens lokation.
- områdeBetjent: det område eller den region, virksomheden betjener.
For eksempel, her er et skema-uddrag for 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 forretnings markup-skema.

Brødkrummene navigation

BrødkrummeList skemaet hjælper med at definere din websides navigationsstruktur, viser brugere (og søgemaskiner) hvor de er inden for sidens hierarki. Selvom dette kan synes ligetil, er lokalisering af brødkrummer kritisk på en flersproget e-handel side for at sikre konsistens, forbedre SEO og forbedre brugeroplevelsen.
For eksempel, en brødkrummesti på engelsk, spansk og arabisk
- “Forside > Mænds Mode > Jakker”
- “Forside > Herremode > Jakker”,
- “الرئيسية > أزياء الرجال > المعاطف”.
Antag, at brødkrummeschemaet er på engelsk, mens sideindholdet er på et andet sprog. I så fald kan brugerne opleve forvirring, og søgemaskiner kan have svært ved at indeksere det lokaliserede indhold korrekt. Det kan også skade din interne linkstrategi, da brødkrummer påvirker, hvordan link equity flyder gennem din side.
Nøgleelementer i BreadcrumbList-skemaet, der kræver lokalisering.
- itemListElement.name: Det synlige navn på hvert brødkrummeniveau skal oversættes.
- itemListElement.item: URL'en skal pege på den korrekte lokaliserede version af hver side.
- position: afspejler niveauet i brødkrummestien (normalt forbliver det samme, men skal svare til den lokaliserede 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å et breadcrumb-opmærkningsskema.

Almindelige fejl i schema-lokalisering for e-handel

Virksomheder støder ofte på kritiske, men undgåelige problemer, når de lokaliserer skemaopmærkning for e-handelswebsteder. Mange antager, at oversættelse alene er tilstrækkeligt, men strukturerede data skal være fuldt tilpasset hver regions sprog, valuta og brugerforventninger. Disse oversigter kan føre til ødelagte rich snippets, dårlig søgevisibilitet eller brugerforvirring.
Nedenfor er nogle af de mest almindelige fejl i skemalokalisering - og hvorfor det at undgå dem kan påvirke din sides ydeevne og brugeroplevelse betydeligt.
Brug af kun ét sprog eller én valuta
En af de mest hyppige fejltrin i e-handelsschema-lokalisering er at holde fast i et enkelt sprog eller valuta på tværs af sidens strukturerede data - selv når indholdet på forsiden er oversat. Denne uoverensstemmelse forvirrer både brugere og søgemaskiner. En shopper i Frankrig kan læse produktbeskrivelser på fransk, men se skemaet stadig henvise til USD i stedet for EUR, hvilket kan give tillidsproblemer.
Lokaliseret skema skal afspejle det oversatte indhold og lokale valutaformater. For eksempel bør “priceCurrency”: “EUR” erstatte “priceCurrency”: “USD” på den franske version af webstedet, og felterne “name” og “description” i produktskemaet skal vises på fransk. Uden dette kan søgemaskiner muligvis ikke vise dine lokaliserede lister nøjagtigt i søgeresultaterne.
Ignorering af sprog- og valutalokalisering fører til dårlige rich snippet-forhåndsvisninger, reducerer klikfrekvensen og kan endda overtræde retningslinjerne for nøjagtighed i strukturerede data. Tilpas altid dit skema pr. sprog og region ved hjælp af hreflang og regionspecifikke underdomæner eller stier.
Ikke at opdatere valutakoder korrekt

Mange glemmer at opdatere valutakoden i skemaopmærkningen, selv når handlende bruger det korrekte lokaliserede valutasymbol på front-end. Schema.org bruger standardiserede ISO 4217-koder (som “USD” for amerikanske dollar eller “JPY” for japanske yen), og hvis man ikke afspejler disse korrekt i “priceCurrency”, fører det til brudte eller vildledende rige resultater.
For eksempel, hvis din butik i UAE viser priser i dirham, men stadig bruger “priceCurrency”: “USD” i schema, kan Google misfortolke produktprisen eller vælge slet ikke at vise den. Værre er det, hvis en kunde går ud fra, at et produkt er billigere eller dyrere på grund af forkert valuta kontekst, hvilket fører til afvisningsrater eller forladte indkøbskurve.
Dobbelttjek altid valutaværdier i dit skema, især for butikker med flere valutaer, der bruger geolokalisering eller valutaswitchere. Ved at tilpasse visuel og struktureret valutainformation forbedres søgeudseende og kundetillid.
Spring over regionspecifikke skema-felter
En anden fejl er at bruge generiske skemaer på tværs af regioner uden at inkorporere regionspecifikke elementer som “shippingDestination”, “areaServed” eller “availableAtOrFrom”. Disse felter er afgørende for at kommunikere logistik og service-dækning, især ved international forsendelse eller lokaliseret kundesupport.
For eksempel bør købere i Australien se estimater for leveringstid og leveringsmuligheder baseret på lokale standarder (f.eks. “shippingDestination”: { “@type”: “DefinedRegion”, “name”: “Australia” }). Hvis man undlader at give sådanne detaljer, kan søgemaskiner gå ud fra, at man ikke sender dertil, hvilket påvirker synligheden i lokale søgninger.
Desuden hjælper felter som “areaServed” og “availableAtOrFrom” med at fremhæve din virksomhed i forbindelse med søgninger efter “near me” eller regionsbaserede søgninger. Hvis du ikke bruger disse skema-felter på regionale sider, går du glip af lokaliserede søgemuligheder.
Ignorerer RTL-sprogsunderstøttelse

Sprog som arabisk og hebraisk læses fra højre mod venstre (RTL), og manglende tilpasning af skema-opmærkning til dette kan forårsage læsbarheds- og SEO-problemer. Selvom skemaet ikke er visuelt gengivet, skal det stadig afspejle sprogkonteksten for at matche oplevelsen på siden og søgesprogets målretning.
For eksempel skal felterne “name” og “description” i produktskemaet på en arabisk side være korrekt oversat og kodet ved hjælp af det korrekte Unicode-format. Derudover skal siden selv bruge lang=”ar” og dir=”rtl” i HTML-koden, og skemaet skal matche det samme.
Manglende RTL-understøttelse forårsager inkonsistens mellem det visuelle og strukturerede indhold, hvilket potentielt kan forvirre brugere og påvirke berettigelsen til rige søgeresultater. Sørg altid for, at både sprog og læseretning afspejles i skemastrukturen.
Manglende oversatte brødkrummer
Brødkrummer fungerer som navigationshjælpemidler og bidrager væsentligt til intern linking og SEO. En almindelig fejl i skema-lokalisering er at beholde brødkrumme-skemaet på originalsproget, selv når den synlige navigationssti er oversat.
For eksempel, hvis din side viser “Forside > Dametøj > Kjoler” (Spansk for “Hjem > Kvinders Mode > Kjoler”), skal dit BreadcrumbList-skema afspejle dette præcist. Brug af “name”: “Hjem” i stedet for “Forside” skaber en diskrepans og kan have en negativ indvirkning på, hvordan Google fortolker webstedets struktur.
Hvert brødkrummniveau (“name”) bør være lokaliseret, og det tilsvarende “item” bør linke til den lokaliserede URL. At holde alt sammenhængende sikrer konsistens for brugere og crawlere, hvilket forbedrer synlighed og indeksering.
Genbrug af samme skema til alle sprog

Den mest skadelige fejl er at bruge en ensartet skema-tilgang på tværs af alle sprog. Gendannelse af de samme strukturerede data uden tilpasning af indhold, valuta, sprog og regional kontekst underminerer hele formålet med lokalisering.
Hver lokaliserede version af din hjemmeside bør have sin egen skema, der afspejler det lokale indhold og metadata. For eksempel, hvis du har separate produktsider for engelsk og fransk, skal deres produkt-skema have oversat "name", "description", "priceCurrency" og endda sprogspecifikke URL'er.
At forsømme denne praksis kan resultere i modstridende søgesignaler, dårlig uddragskvalitet eller endda manuelle handlinger for vildledende strukturerede data. En bedste praksis er at vedligeholde separate skemaer for hver sprogunderdomæne eller hreflang-mærket version, hvilket sikrer, at de strukturerede data matcher sproget og den region, der betjenes.
Bedste praksis for lokalisering af skema-opmærkning for e-handel

Skemaopmærkning spiller en afgørende rolle i, hvordan søgemaskiner fortolker og viser dit indhold. Når det er korrekt lokaliseret, øger det din synlighed i lokale søgeresultater, forbedrer klikfrekvensen og forbedrer købsoplevelsen for brugere verden over.
Her er de bedste fremgangsmåder, som enhver global e-handelsvirksomhed bør følge for at få mest muligt ud af lokalisering.
Brug sprogspecifik schema per side
Hver sprogversion af din hjemmeside bør indeholde schema-mærkning på det pågældende sprog. Hvis du bruger underdomæner eller undermapper (f.eks. example.com/en/ for engelsk og example.com/de/ for tysk), skal hver enkelt indeholde et unikt, sprogrelateret schema.
Hvis din tyske side stadig bruger skema på engelsk, kan Google have svært ved at forstå sidens lokale kontekst, og brugerne kan finde oplevelsen inkonsistent med deres forventninger, som vist nedenfor.
Land | Skemafelt | Lokaliseret værdi |
/fr/produkt-side | “navn” | “Vinterjakke til mænd” |
“beskrivelse” | “En varm jakke til den franske vinter” | |
“sprog” | “fr” |
Lokalisér produktnavne og beskrivelser

Produktnavne og beskrivelser bør ikke bare oversættes og kulturelt tilpasses. Sætninger, der lyder tiltalende i ét land, kan måske ikke give resonans i et andet. Brug naturligt sprog til lokale målgrupper og tilpas det til deres købsadfærd.
Stol på lokale oversættere eller lokale eksperter for at undgå akavet formulering eller uklar besked. Felter som navn, beskrivelse og mærke i dit skema skal afspejle det lokale sprog og præferencer.
Sprog | navn | beskrivelse |
Dansk | “Mænds slanke jakke” | “En stilfuld jakke perfekt til vinter” |
Japansk | “Herre vinterjakke” | “En smart jakke perfekt til vinteren.” |
Indstil en nøjagtig pris og valuta
Pris er et følsomt emne inden for e-handel. Konverter ikke blot valutaer visuelt på din side – sørg for, at dit schema nøjagtigt afspejler den korrekte valuta ved hjælp af ISO 4217-koden i feltet priceCurrency. Priser bør også formateres i henhold til lokale konventioner, herunder decimaler og tusind-separatorer.
Undgå at vise kun USD på tværs af alle sprogversioner, da dette kan forvirre brugerne eller underminere tilliden. Hvis du bruger realtidsvalutaomregning, skal du sikre, at dit schema forbliver synkroniseret. For eksempel.
Land | pris | prisValuta | Lokal Format |
Japan | 4500 | JPY | ¥4,500 |
Saudi-Arabien | 180 | SAR | 180 ر.س |
Tilpas forretningsinformation

Forretningskontaktoplysninger, såsom adresser, telefonnumre og åbningstider, skal lokaliseres efter region. Brug lokale formater til felter som addressLocality, postalCode og addressCountry. Inkluder internationale opkaldsnumre i telefonnumre for at gøre det lettere for brugerne at kontakte dig.
Felter som openingHoursSpecification skal afspejle lokale tidszoner og forretningsforhold. Disse detaljer hjælper med at etablere tillid og forbedre din virksomheds synlighed i lokale søgeresultater. For eksempel.
Land | addressLocality | postnummer | åbningstiderFormat |
Spanien | Barcelona | 08001 | Ma-Fr 09:00–18:00 |
Thailand | Chiang Mai | 50000 | Ma-Lø 10:00–19:00 |
Strukturskema for RTL-sprog
Sprog som arabisk og hebraisk skrives fra højre mod venstre (RTL). Selvom JSON-LD i sig selv ikke afhænger af visuel formatering, skal ethvert skema-felt, der indeholder synlig tekst - såsom navn, beskrivelse eller breadcrumb - afspejle det korrekte sprog og retning for at undgå inkonsistenser mellem indholdet og markeringen.
Hvis din side er på arabisk, men skemaet stadig indeholder 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'en indeholder lang=”ar” og at de strukturerede datafelter er lokaliseret i overensstemmelse hermed.
Felt | Ikke-lokaliseret (LTR/Engelsk) | Lokalt (RTL/Arabisk) |
navn | Vinterjakke | معطف شتوي |
beskrivelse | En varm kappe til vinteren | معطف دافئ مثالي لفصل الشتاء |
brødkrumme | Hjem > Beklædning > Jakker | الرئيسية > الملابس > المعاطف |
Automatiser skema-lokalisering med Linguise
Lokalisering af skemamarkup på tværs af flere sprog kan være komplekst, især når man skal håndtere hundredvis af dynamiske produktsider. Det synlige indhold og de strukturerede data, herunder Product-, Offer-, BreadcrumbList- og LocalBusiness-skemærker, skal oversættes. Rich snippets afspejler muligvis ikke det korrekte sprog, valuta eller struktur for hver region uden korrekt lokalisering.
Linguise tilbyder en automatisk oversættelse løsning, der udvider sig til strukturerede data, oversætter skema-markup og dit indhold. Gennem dets Live Editor kan du manuelt finjustere skema-indhold som produktnavne, beskrivelser eller brandværdier for at sikre, at de nøjagtigt afspejler lokal kontekst. Dette er særligt nyttigt, når du lokaliserer produkt-skema-felter, der kræver kulturel nuance og søgeords-tilpasning til regional SEO.
Derudover understøtter Linguise oversættelse af links og medier, hvilket muliggør lokalisation af breadcrumb-URL'er, interne links og endda billedreferencer. Dette sikrer, at alle elementer, navigationsstier, aktiver og strukturerede data er tilpasset den korrekte sprogversion, hvilket hjælper søgemaskiner med at levere mere præcise og relevante rige resultater til brugere verden over.
Konklusion
Lokalisering af skema-markup er afgørende for internationale e-handelsvirksomheder, der sigter mod at forbedre synligheden i lokale søgeresultater, forbedre rige snippets og give brugerne en problemfri flersproget oplevelse. Fra produktnavne og priser til leveringsdetaljer og forretningsinformation skal hver enkelt struktureret data-pakke stemme overens med målets markedssprog, kultur og forventninger.
For at strømline denne proces, overvej at bruge Linguise—en oversættelsesløsning, der ikke kun automatiserer indholdsoversættelse, men også tilpasser dit schema-markup, links og medier pr. sprog. Med funktioner som Live Editor og oversættelse af URL'er og billeder, ved at bruge Linguise kan hjælpe hele din hjemmeside—synligt indhold og strukturerede data ligeledes er fuldt lokaliseret og SEO-klart.




