Lokalisering af schema-markup til e-handel handler om at få dine strukturerede data til at tale dine kunders og søgemaskinernes sprog. For internationale onlinebutikker, især dem der henvender sig til forskellige regioner som EU, Sydøstasien eller Mellemøsten, er schema-lokalisering afgørende for at hjælpe søgemaskiner med at levere de rigtige rich snippets baseret på brugerens sprog, region og valuta.
Ved at lokalisere centrale schematyper, som produktinformation, prissætning og virksomhedsoplysninger, øger du synlighed, tillid og konverteringsrater på forskellige markeder. Denne artikel undersøger, hvilke schemaelementer der skal lokaliseres, almindelige fejl du bør undgå, og bedste praksis for at hjælpe din internationale e-handelsside med at præstere optimalt.
Vigtigheden af schema-lokalisering for din e-handel
Schema-lokalisering sikrer, at dine strukturerede data stemmer overens med sproget, valutaen og den kulturelle kontekst i hvert marked, du betjener. Dette forbedrer din synlighed i lokale søgeresultater og forbedrer brugeroplevelsen på tværs af forskellige regioner.
- Forbedrer lokal SEO – Når schema-markup bruger lokaliseret sprog, valuta og regionsspecifikke felter, kan søgemaskiner bedre forstå og matche dit indhold med lokal søgeintention.
- Muliggør præcise rich snippets – Rich snippets som priser, produkttilgængelighed og anmeldelser afspejler brugerens lokale kontekst, hvilket opbygger tillid og forbedrer klikfrekvensen.
- Forbedrer flersproget brugeroplevelse – Lokaliseret schema hjælper med at sikre sammenhæng mellem det synlige sideindhold og de strukturerede data bag det, hvilket undgår forvirring for internationale besøgende.
- Understøtter regional overholdelse og forventninger – Forskellige regioner kan have specifikke datakrav (f.eks. moms i EU eller forsendelseszoner i Sydøstasien), der kan imødekommes via skema.
- Øger konverteringsraten på målgruppemarkeder – Brugere, der ser velkendt sprog, valuta og kontaktoplysninger i søgeresultater, er mere tilbøjelige til at stole på og interagere med dit websted.
Centrale e-handelsschematyper, der kræver lokalisering
Schema-markup er en type strukturerede data, der tilføjes til din websites HTML, og som hjælper søgemaskiner med at forstå konteksten af dit indhold. For e-handel driver det rige resultater som produktvurderinger, priser, tilgængelighed og meget mere, hvilket får dine opslag til at skille sig ud i søgningen. Når du målretter mod internationale markeder, er det ikke nok blot at bruge schema – du skal også lokalisere det.
Nedenfor er de vigtigste skematyper, der kræver omhyggelig lokalisering for global e-handelssucces.
Product
Produktskemaet indeholder strukturerede oplysninger som produktnavn, beskrivelse, SKU, brand, billede og anmeldelser. Når dette skema lokaliseres, er det afgørende at oversætte produktnavne og beskrivelser præcist, ikke bare ord for ord, men på en måde der resonerer med hvert markeds kulturelle og sproglige normer.
Flere centrale elementer skal tilpasses hvert enkelt målmarked for at lokalisere Product-schemaet korrekt. Disse elementer rækker ud over grundlæggende oversættelse—kulturel tilpasning, overholdelse af lokale forventninger og tilpasning til sprogspecifik SEO. Her er de centrale aspekter af Product-schemaet, der bør lokaliseres.
- name: Oversæt produktnavnet for at bevare betydning og appel i det lokale sprog. Undgå ordrette oversættelser, der kan forvirre eller vildlede lokale målgrupper.
- description: Lokaliser beskrivelser med opmærksomhed på tone, måleenheder (f.eks. tommer vs. centimeter) og terminologi, der er velkendt for regionale målgrupper.
- image: Selvom det ikke er tekstbaseret, kan lokaliserede billeder afspejle kulturelle præferencer. For eksempel kan tøjbilleder på mellemøstlige markeder kræve mere ærbare visuals.
- brand: Hvis brandet har forskellige navne i forskellige regioner, eller hvis undermærker er mere genkendelige lokalt, skal du sikre, at brandfeltet afspejler dette.
- sku: Selvom det ofte er ens globalt, bør du opdatere sku'en, så den matcher det lokale katalog, hvis du bruger regionale produktkoder eller -identifikatorer.
- review og aggregateRating: Disse elementer kan også drage fordel af lokalisering. Hvis kundeanmeldelser er inkluderet i schema, skal du sikre, at de er skrevet på det lokale sprog og afspejler regionsspecifik kundefeedback.
- offers (indlejret i Product): Dette omfatter priser og tilgængelighed, som bør afspejle lokal valuta, formater og lagerbeholdning. Overvej også at tilpasse priceValidUntil til lokale salgscyklusser.
For eksempel kan et produkt som "Winter Coat – Arctic Series" på engelsk lokaliseres som "Chaqueta Invernal – Serie Ártica" på spansk. På arabiske markeder skal ikke kun navnet og beskrivelsen oversættes til arabisk, men du kan også have brug for at tilpasse billeder og funktionsfremhævelser til det, der anses for tiltrækkende eller beskedent.
Hvis du ikke lokaliserer Product-schemaet, kan det skabe uoverensstemmelse mellem det, der vises i søgeresultatet, og det, der står på den faktiske produktside, hvilket skader tilliden og reducerer klikfrekvensen. Ved at tilpasse dit produktschema pr. lokalitet sikrer du konsistens, bedre SEO-overensstemmelse og en mere problemfri 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å Product-schema-markup, der vises online, når man søger efter et produkt.
Priser og valuta
Priser er en af de mest følsomme oplysninger for onlinekunder. Offer-schemaet, som typisk er indlejret i Product-schemaet, indeholder nøglefelter som price, priceCurrency og availability. Det er afgørende at lokalisere valuta og priser, især når dit website henvender sig til regioner, der ikke bruger USD, EUR eller andre standardvalutaer.
Hvis du for eksempel sælger i Mellemøsten, bør dit schema afspejle priser i AED eller SAR ved hjælp af den relevante ISO 4217-valutakode, som "priceCurrency": "AED". Derudover bør prisformatet følge regionale konventioner—nogle lande bruger kommaer i stedet for punktummer som decimalseparatorer eller placerer valutasymbolet efter beløbet i stedet for før.
Forkerte eller generiske valutakoder i schema-markup kan føre til misvisende rich snippets, forvirrede kunder og endda søgemaskinestraffe for datainkonsistens. Dit schema bør synkroniseres med det, brugerne ser på frontend, og afspejle realtidskonverteringskurser eller lokaliserede prisstrategier. Det er afgørende at tilpasse dette schema pr. sprog eller regionalt subdomæne for at sikre en nøjagtig gengivelse på tværs af dit flersprogede website. Nøgleelementer i pris-schemaet, der skal lokaliseres.
- price: 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.).
- Placering af valutasymbol: Tilpas symbolet til lokale konventioner (f.eks. "99 ر.س" i stedet for "SAR 99").
- availability: Brug lokaliseret sprog eller etiketter, hvis det er relevant (f.eks. “In Stock” → “Disponible” på spansk).
Her er et eksempel på et lokaliseret schema til prissætning, der er tilpasset et mellemøstligt 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å schema-markup for priser og valuta, som vises online, når man søger efter et produkt.
Forretnings- og kontaktoplysninger
Organisation- og ContactPoint-schemaerne definerer din virksomhedsidentitet, og hvordan kunder kan kontakte dig. Lokalisering her indebærer mere end blot oversættelse—det kræver tilpasning af åbningstider, supportsprog og kontaktmetoder, så de passer til lokale forventninger.
Ved at lokalisere forretnings- og kontaktskemaer øger du tilliden 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 give korrekte forretningssvar baseret på placering. Et vellokaliseret skema sikrer, at kunderne ser de rigtige kontaktmuligheder på det rigtige tidspunkt, tilpasset deres sprog, region og foretrukne kommunikationsmetoder.
Vigtige elementer i Organization- og ContactPoint-schemaerne, der skal lokaliseres, omfatter.
- name: Oversæt eller tilpas virksomhedsnavnet, hvis du bruger en lokal brandidentitet i forskellige regioner.
- contactType: Brug lokaliserede udtryk for supporttyper (f.eks. “servicio al cliente” på spansk).
- telephone: Medtag lokale supportnumre med korrekte internationale formater.
- areaServed: Angiv målregionen ved hjælp af ISO-koder for at sikre geografisk relevans.
- availableLanguage: Angiv, hvilke sprog dit supportteam kan håndtere (f.eks. engelsk, arabisk, fransk).
- contactOption: Tilføj regionsspecifikke kontaktmetoder som WhatsApp, WeChat eller lokale chadværktøjer.
- url: Henvis brugere til lokaliserede hjælpe- eller kontaktsider, hvis de findes.
Ved at tilpasse hvert af disse felter til hver målregion vil dit schema leve op til lokale forventninger og øge chancerne for at blive vist i relevante søgeresultater, især dem der er baseret på mobil- eller stemneinteraktioner. Følgende er et eksempel på anvendelse af schemaet.
{
"@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 & leveringsdetaljer
Forventninger til og regler for levering varierer betydeligt fra land til land. Ved at bruge schematyper som DeliveryTimeSettings, ShippingDeliveryTime eller OfferShippingDetails, der er regionsspecifikke, kan du ikke blot kommunikere tilgængelighed og estimerede leveringstider, men også hvilke regioner der betjenes, fragtpriser og håndteringstider – alt sammen noget, der bør lokaliseres for hvert marked. Schemaelementer for forsendelse, der skal lokaliseres, omfatter.
- shippingDestination: region eller land, der betjenes.
- deliveryTime: anslået leveringstid i lokalt format (f.eks. 2 dage vs. 5-7 hverdage).
- shippingRate: forsendelsespris i lokal valuta.
- transitTimeLabel: etiket, der bruges til at beskrive leveringstiden (såsom “Ekspres”, “Almindelig” eller “Levering inden for 24 timer”).
- handlingTime: behandlingstid, før leveringen begynder.
For eksempel kan en kunde i Tyskland forvente levering inden for 3 hverdage, mens et typisk skøn i Indonesien kan være 5-7 dage. Hvis forsendelsesordningen ikke er lokaliseret, får brugerne muligvis ikke relevant information i søgeresultaterne, hvilket gør dem tøvende med at købe. Her er et eksempel på OfferShippingDetails lokaliseret 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"
}
}
Butikkens placering og lokale virksomhedsoplysninger
Nøjagtig visning af butikslokationer i Google Search eller Google Maps afhænger i høj grad af et velimplementeret LocalBusiness-schema. Især når brugere søger på deres lokale sprog eller i deres region, øger korrekt information synligheden og opbygger tillid. Vigtige elementer i LocalBusiness-schemaet, der kræver lokalisering, omfatter:.
- name: virksomhedsnavnet oversættes, hvis det er relevant for den lokale kontekst.
- address: adressen formateret i overensstemmelse med lokale konventioner, herunder addressLocality, addressRegion, postalCode og addressCountry.
- telephone: telefonnummeret med korrekt landekode og lokal formatering.
- openingHoursSpecification: Åbningstider tilpasses lokale tidszoner og forretningsvaner.
- geo: geografiske koordinater (bredde- og længdegrad) for butikkens placering.
- areaServed: den region eller det område, virksomheden betjener.
Her er for eksempel et schema-uddrag til en butik, der driver virksomhed 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å et markup-skema for lokale virksomheder.
Brødkrummenavigation
BreadcrumbList-skemaet hjælper med at definere din websites navigationsstruktur og viser brugerne (og søgemaskinerne), hvor de befinder sig i webstedets hierarki. Selvom dette kan virke ligetil, er lokalisering af breadcrumbs afgørende på et flersproget e-handelswebsted for at sikre konsistens, forbedre SEO og forbedre brugeroplevelsen.
For eksempel en brødkrummesti på engelsk, spansk og arabisk
- “Hjem > Herretøj > Jakker”
- “Inicio > Moda Masculina > Chaquetas”,
- “الرئيسية > أزياء الرجال > المعاطف”.
Hvis breadcrumb-schemaet efterlades på engelsk, mens sidens indhold er på et andet sprog, kan brugerne opleve forvirring, og søgemaskiner kan få svært ved at indeksere det lokaliserede indhold korrekt. Det kan også skade din interne linkstrategi, da breadcrumbs påvirker, hvordan linkværdi flyder gennem dit website.
Nøgleelementer i BreadcrumbList-schemaet, der skal lokaliseres.
- itemListElement.name: Det synlige navn på hvert breadcrumb-niveau skal oversættes.
- itemListElement.item: URL'en skal pege på den korrekte lokaliserede version af hver side.
- position: Afspejler niveauet i breadcrumb-stien (forbliver normalt 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-markup-skema.
Almindelige fejl ved schema-lokalisering til e-handel
Virksomheder støder ofte på kritiske, men undgåelige problemer, når de lokaliserer schema-markup til e-commerce-websites. Mange antager, at oversættelse alene er tilstrækkeligt, men strukturerede data skal fuldt ud tilpasses hver regions sprog, valuta og brugernes forventninger. Disse forsømmelser kan føre til ødelagte rich snippets, dårlig søgesynlighed eller forvirring hos brugerne.
Nedenfor er nogle af de mest almindelige fejl i lokalisering af schema—og hvorfor det kan have stor betydning for dit websites ydeevne og brugeroplevelse at undgå dem.
Brug af kun ét sprog eller én valuta
En af de hyppigste fejl i lokalisering af e-handelsschemaer er at holde fast i et enkelt sprog eller en enkelt valuta i hele webstedets strukturerede data—selv når frontend-indholdet er oversat. Denne uoverensstemmelse forvirrer både brugere og søgemaskiner. En kunde i Frankrig læser måske produktbeskrivelser på fransk, men ser et schema, der stadig henviser til USD i stedet for EUR, hvilket kan skabe tillidsproblemer.
Lokaliserede schemaer bør afspejle det oversatte indhold og de lokale valutaformater. For eksempel bør “priceCurrency”: “EUR” erstatte “priceCurrency”: “USD” på den franske version af webstedet, og felterne “name” og “description” i Product-schemaet bør vises på fransk. Uden dette kan søgemaskiner muligvis ikke vise dine lokaliserede opslag korrekt i søgeresultaterne.
Hvis du ignorerer sprog- og valuta-lokalisering, får du dårlige rich snippet-previews, lavere klikfrekvens og kan endda overtræde retningslinjerne for nøjagtighed i strukturerede data. Tilpas altid dit schema pr. sprog og region ved hjælp af hreflang og regionsspecifikke subdomæner eller stier.
Opdaterer ikke valutakoder korrekt
Mange glemmer at opdatere valutakoden i schema-markup, selv når forhandlere bruger det korrekte lokaliserede valutasymbol i frontend. Schema.org bruger standardiserede ISO 4217-koder (som “USD” for amerikanske dollars eller “JPY” for japanske yen), og hvis disse ikke afspejles korrekt i “priceCurrency”, fører det til brudte eller misvisende rich results.
Hvis din butik i De Forenede Arabiske Emirater f.eks. viser priser i dirham, men stadig bruger “priceCurrency”: “USD” i schema, kan Google misforstå produktprisen eller helt vælge ikke at vise den. Endnu værre kan en kunde tro, at et produkt er billigere eller dyrere på grund af en forkert valutasammenhæng, hvilket kan føre til højere afvisningsprocent eller forladte indkøbskurve.
Dobbelttjek altid valutaværdier i dit skema, især for butikker med flere valutaer, der bruger geolokation eller valutaomskiftere. At bringe visuel og struktureret valutainformation i overensstemmelse forbedrer søgevisningen og kundernes tillid.
Spring af regionsspecifikke schema-felter over
En anden fejl er at bruge generisk schema på tværs af regioner uden at indarbejde regionsspecifikke elementer som “shippingDestination”, “areaServed” eller “availableAtOrFrom”. Disse felter er afgørende for at kommunikere logistik og serviceområde, især ved international forsendelse eller lokaliseret kundesupport.
For eksempel bør kunder i Australien se estimater for leveringstid og leveringsmuligheder baseret på lokale standarder (f.eks. “shippingDestination”: { “@type”: “DefinedRegion”, “name”: “Australia” }). Hvis du udelader sådanne detaljer, kan søgemaskiner antage, at du ikke leverer dertil, hvilket påvirker synligheden i lokale søgninger.
Desuden hjælper felter som “areaServed” og “availableAtOrFrom” med at fremhæve din virksomhed i søgninger som “i nærheden af mig” eller regionsbaserede søgninger. Hvis du ikke bruger disse schema-felter på regionale sider, går du sandsynligvis glip af lokale søgemuligheder.
Ignorering af RTL-sprogunderstøttelse
Sprog som arabisk og hebraisk læses fra højre mod venstre (RTL), og hvis man undlader at tilpasse schema-markup for at tage højde for dette, kan det føre til problemer med læsbarhed og SEO. Selvom schema ikke vises visuelt, skal det stadig afspejle sprogkonteksten for at matche oplevelsen på siden og målretningen af søgesproget.
For eksempel bør felterne “name” og “description” i produktskemaet på en arabisk side oversættes korrekt og kodes med det korrekte Unicode-format. Derudover bør selve siden bruge lang=”ar” og dir=”rtl” i HTML'en, og skemaet bør matche det samme.
Manglende understøttelse af RTL skaber inkonsistens mellem det visuelle og det strukturerede indhold, hvilket potentielt kan forvirre brugerne og påvirke muligheden for at få vist rich results. Sørg altid for, at både sproget og læseretningen afspejles i skemastrukturen.
Manglende oversatte breadcrumbs
Brødkrummer fungerer som navigationshjælpemidler og bidrager betydeligt til intern linkopbygning og SEO. En almindelig fejl inden for schema-lokalisering er at beholde brødkrumme-schemaet på originalsproget, selv når den synlige navigationssti er oversat.
Hvis din side for eksempel viser “Inicio > Moda Femenina > Vestidos” (spansk for “Home > Women’s Fashion > Dresses”), bør din BreadcrumbList-schema afspejle dette præcist. Hvis du bruger “name”: “Home” i stedet for “Inicio”, skabes der en afbrydelse, og det kan påvirke Googles fortolkning af webstedsstrukturen negativt.
Hvert breadcrumb-niveau (“name”) bør lokaliseres, og det tilsvarende “item” bør linke til den lokaliserede URL. At holde alt på linje sikrer konsistens for brugere og crawlere og forbedrer synlighed og indeksering.
Genbrug af samme schema til alle sprog
Den mest skadelige fejl er at bruge en ensartet skema-tilgang på tværs af alle sprog. Genbrug af de samme strukturerede data uden at tilpasse indhold, valuta, sprog og regionskontekst ødelægger hele formålet med lokalisering.
Hver lokaliseret version af dit websted bør have et schema, der afspejler det lokale indhold og metadata. Hvis du for eksempel har separate produktsider til engelsk og fransk, bør deres Product-schema have oversatte “name”, “description”, “priceCurrency” og endda sprogafhængige URL'er.
Hvis denne praksis forsømmes, kan det føre til modstridende søgesignaler, dårlig snippet-kvalitet eller endda manuelle handlinger på grund af vildledende strukturerede data. En bedste praksis er at vedligeholde separate skemaer for hvert sprogligt subdomæne eller hreflang-markeret version, så de strukturerede data matcher det sprog og den region, der betjenes.
Bedste praksis for lokalisering af schema-markup til e-handel
Schema-markup spiller en afgørende rolle for, hvordan søgemaskiner fortolker og viser dit indhold. Når det lokaliseres korrekt, øger det din synlighed i lokale SERP'er, forbedrer klikfrekvensen og forbedrer shoppingoplevelsen for brugere over hele verden.
Her er de bedste praksisser, som enhver global e-handelsvirksomhed bør følge for at få mest muligt ud af lokalisering.
Brug sprogspecifikt schema pr. side
Hver sprogversion af dit website bør indeholde schema-markup på det pågældende sprog. Hvis du bruger subdomæner eller undermapper (f.eks. example.com/en/ til engelsk og example.com/de/ til tysk), bør hver især indeholde et unikt, sprogpassende schema.
Hvis din tyske side stadig bruger schema på engelsk, kan Google have svært ved at forstå sidens lokale kontekst, og brugerne kan opleve, at oplevelsen ikke stemmer overens med deres forventninger, for eksempel som nedenfor.
Land | Schema-felt | Lokaliseret værdi |
/fr/product-page | “name” | “Veste d'hiver pour homme” |
“description” | “Une veste chaude pour l’hiver français” | |
“inLanguage” | "fr" |
Lokaliser produktnavne og -beskrivelser
Produktnavne og -beskrivelser bør ikke bare oversættes og kulturtilpasses. Fraser, der lyder tiltalende i ét land, rammer måske ikke plet i et andet. Brug et naturligt sprog for det lokale publikum, og sørg for, at det passer til deres købsadfærd.
Stol på modersmålstalende oversættere eller lokale eksperter for at undgå akavede formuleringer eller uklar kommunikation. Felter som navn, beskrivelse og brand i dit schema bør afspejle det lokale sprog og lokale præferencer.
Sprog | name | description |
Engelsk | “Men’s Sleek Jacket” | “En stilfuld jakke, perfekt til vinteren” |
Japansk | “メンズウィンタージャケット” | “冬に最適なおしゃれなジャケットです。” |
Angiv en præcis pris og valuta
Pris er et følsomt emne inden for e-handel. Konverter ikke bare valutaer visuelt på dit website—sørg for, at dit schema nøjagtigt afspejler den korrekte valuta ved at bruge ISO 4217-koden i feltet priceCurrency. Priser bør også formateres i overensstemmelse med lokale konventioner, herunder decimaler og tusindtalsseparatorer.
Undgå kun at vise USD på tværs af alle sprogversioner, da det kan forvirre brugerne eller svække tilliden. Hvis du bruger realtidsvalutakonvertering, skal du sikre dig, at dit schema forbliver synkroniseret. For eksempel.
Land | price | priceCurrency | Lokalt Format |
Japan | 4500 | JPY | ¥4,500 |
Saudi-Arabien | 180 | SAR | 180 kr |
Lokaliser virksomhedsoplysninger
Virksomhedens kontaktoplysninger, såsom adresser, telefonnumre og åbningstider, skal lokaliseres efter region. Brug lokale formater til felter som addressLocality, postalCode og addressCountry. Medtag internationale landekoder i telefonnumre for at gøre det nemmere for brugere at kontakte dig.
Felter som openingHoursSpecification bør afspejle lokale tidszoner og forretningspraksisser. Disse detaljer hjælper med at opbygge tillid og forbedre din virksomheds fremtoning i lokale søgeresultater. For eksempel.
Land | adresseLokation | postalCode | openingHoursFormat |
Spanien | Barcelona | 08001 | Man-fre 09:00–18:00 |
Thailand | Chiang Mai | 50000 | Man-lør 10:00–19:00 |
Struktur-schema til 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 schemafelt, der indeholder synlig tekst – såsom name, description eller breadcrumb – afspejle det korrekte sprog og den korrekte retning for at undgå uoverensstemmelser mellem indholdet og markupen.
Hvis din side er på arabisk, men schemaet stadig indeholder engelske værdier eller venstre-til-højre-indhold, kan det skabe forvirring for både brugere og søgemaskiner. Sørg altid for, at HTML'en indeholder lang=”ar”, og at felterne i de strukturerede data er lokaliserede i overensstemmelse hermed.
Felt | Ikke-lokaliseret (LTR/engelsk) | Lokaliseret (RTL/arabisk) |
name | Vinterjakke | معطف شتوي |
description | En varm frakke til vinteren | Varm frakke, perfekt til vinteren |
brødkrumme | Forside > Tøj > Jakker | Forside > Tøj > Frakker |
Automatiser schema-lokalisering med Linguise
Det kan være komplekst manuelt at lokalisere schema-markup på tværs af flere sprog, især når man administrerer hundredvis af dynamiske produktsider. Det synlige indhold og de strukturerede data, herunder Product-, Offer-, BreadcrumbList- og LocalBusiness-schemaer, skal oversættes. Rich snippets afspejler muligvis ikke det korrekte sprog, den korrekte valuta eller struktur for hver region uden korrekt lokalisering.
Linguise tilbyder en automatisk oversættelse -løsning, der også omfatter strukturerede data, og oversætter schema-markup og dit indhold. Via dens Live Editor kan du manuelt finjustere schema-indhold såsom produktnavne, beskrivelser eller brandværdier for at sikre, at de nøjagtigt afspejler den lokale kontekst. Dette er særligt nyttigt, når du lokaliserer Product schema-felter, der kræver kulturel nuance og søgeordsadaptation til regional SEO.
Derudover understøtter Linguise oversættelse af links og medier, hvilket muliggør lokalisering 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 rich results til brugere over hele verden.
Conclusion
Lokalisering af schema-markup er afgørende for internationale e-handelsvirksomheder, der ønsker at forbedre synligheden i lokale søgeresultater, forbedre rich snippets og give brugerne en problemfri flersproget oplevelse. Fra produktnavne og priser til forsendelsesoplysninger og virksomhedsinformation bør hver enkelt del af de strukturerede data stemme overens med hvert målgemarkeds sprog, kultur og forventninger.
For at strømline denne proces kan du overveje at bruge Linguise—en oversættelsesløsning, der ikke blot automatiserer oversættelse af indhold, men også tilpasser din schema-markup, links og medier pr. sprog. Med funktioner som Live Editor og oversættelse af URL'er og billeder, kan brug af Linguise hjælpe hele dit websted—såvel synligt indhold som strukturerede data er fuldt lokaliseret og SEO-klar.
