Lokalisering af skema-mærkning til e-handel handler om at få dine strukturerede data til at tale dit kunders og søgemaskiners sprog. For internationale online-butikker, især dem der målretter 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 snippets baseret på brugersprog, region og valuta.
Ved at lokalisere centrale skemautyper, såsom produktinformation, prissætning og forretningsdetaljer, øger du synlighed, tillid og konverteringsrate på forskellige markeder. Denne artikel undersøger hvilke skemaelementer der skal lokaliseres, almindelige fejl der skal undgås, og bedste praksis for at hjælpe din internationale e-handels side til at fungere bedst muligt.
Vigtigheden af skema-lokalisering for din e-handel
Skema lokalisering 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 schema markup bruger lokaliseret sprog, valuta og regionsspecifikke felter, kan søgemaskiner bedre forstå og matche dit indhold med lokal søgeintention.
- Aktivere præcise rich snippets – Rich snippets som priser, produkt tilgængelighed og anmeldelser vil afspejle brugerens lokale kontekst, opbygge tillid og forbedre klikfrekvensen.
- Forbedrer flersproget brugeroplevelse –Lokaliseret skema sikrer overensstemmelse mellem synligt sideindhold og 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 skema.
- Øger konverteringsraten på målmærkerne – 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øgle e-handels schema typer der kræver lokalisering
Skemamærkning er en type strukturerede data, der føjes til din websites HTML, så søgemaskiner bedre forstår indholdets kontekst. For e-handel driver det rige resultater som produktbedømmelser, priser, tilgængelighed og mere, så dine listings skiller sig ud i søgninger. Når du målretter internationale markeder, er det ikke nok blot at bruge skema - du skal også lokalisere det.
Nedenfor er de vigtigste skematyper, der kræver omhyggelig lokalisering for global e-handelssucces.
Produkt
Produkt-skemaet indeholder 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 genlyd hos hver 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 vigtigste aspekter af produkt-skemaet, der skal lokaliseres.
- navn: Oversæt produktnavnet for at bevare betydningen og appellen på det lokale sprog. Undgå bogstavelige oversættelser, der kan forvirre eller vildlede lokale målgrupper.
- beskrivelse: Lokaliser beskrivelser med opmærksomhed på tone, måleenheder (f.eks. tommer vs. centimeter) og terminologi, der er kendt af regionale målgrupper.
- billede: Selvom det ikke er tekstbaseret, kan lokaliserede billeder afspejle kulturelle præferencer. For eksempel kan beklædningsbilleder på mellemøstlige markeder kræve mere beskedne visuals.
- brand:Hvis brandet har forskellige navne i forskellige regioner, eller hvis under-brand er mere genkendelige lokalt, skal du sikre, at brand-feltet afspejler det.
- varenummer: Selvom det ofte er konsistent globalt, hvis du bruger regionale produktkoder eller identifikatorer, skal du opdatere varenummeret, så det passer til den lokale katalog.
- anmeldelse og aggregateRating: Disse elementer kan også have gavn af lokalisering. Hvis kundeanmeldelser er inkluderet i skemaet, skal de være skrevet på det lokale sprog og afspejle regionspecifikke kunde feedback.
- 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 salgskredsløb.
For eksempel kan et produkt på engelsk kaldet “Vinterjakke – Arktisk Serie” blive lokaliseret som “Chaqueta Invernal – Serie Ártica” på spansk. På arabiske markeder skal ikke kun navn og beskrivelse oversættes til arabisk, men du skal muligvis også tilpasse billedmateriale og fremhævede funktioner til, hvad der anses for tiltalende eller beskeden.
Manglende lokalisering af produktskemaet kan skabe et misforhold mellem hvad der vises i søgefragmentet og hvad der er på den faktiske produkt side, hvilket skader tilliden og reducerer klikraten. Ved at tilpasse dit produktskema pr. lokalitet sikrer du konsistens, bedre SEO-justering og en mere gnidningsfri 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å et produkt skema markup, der vises online, når der søges efter et produkt.
Prissætning og valuta
Prisfastsættelse er en af de mest følsomme informationer for online-shoppere. Tilbudsskemaaet, som typisk er indlejret i produktskemaaet, indeholder nøglefelter som pris, priskurrency og tilgængelighed. Lokalisering af valuta og priser er afgørende, især når din side målretter regioner, der ikke anvender USD, EUR eller andre standardvalutaer.
For eksempel, hvis du sælger i Mellemøsten, skal dit schema 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-markup kan føre til vildledende rich snippets, forvirrede kunder og endda sanktioner fra søgemaskiner for inkonsistens i data. Dit skema skal synkroniseres med, hvad brugerne ser på front-end, og afspejle realtids-valutakurser eller lokaliserede prisstrategier. 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 pris-skemaet, som skal lokaliseres.
- pris: Numerisk prisværdi formateret til den lokale region (f.eks. 99,99 i stedet for 99,99).
- valutaKode: Brug den korrekte ISO 4217 valutakode (f.eks. AED, SAR, JPY osv.).
- Valutategnplacering: 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” → “Disponible” på spansk).
Her er et eksempel på et lokaliseret schema for prissætning tilpasset til 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å prissætning og valuta-schema markup, der vises online, når der søges efter et produkt.
Virksomheds- og kontaktoplysninger
Organisationen og ContactPoint-skemaerne definerer din virksomheds identitet og hvordan kunderne kan nå dig. Lokalisering her involverer mere end blot oversættelse - det kræver tilpasning af åbningstider, supportsprog og kontaktmetoder til lokale forventninger.
Lokalisering af forretnings- og kontaktskemaer øger tilliden og hjælper søgemaskiner med at vise nøjagtige kontaktoplysninger 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 kontaktoplysninger på det rigtige tidspunkt, tilpasset deres sprog, region og foretrukne kommunikationsmetoder.
Nøgleelementer i Organisation- og Kontaktpunkt-skemaerne, der skal lokaliseres, omfatter.
- navn: Oversæt eller tilpas virksomhedsnavnet, hvis du bruger 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.
- tilgængeligSprog: Angiv, hvilke sprog dit supportteam kan håndtere (f.eks. dansk, engelsk, fransk).
- contactOption:Tilføj regionspecifikke kontaktmetoder såsom WhatsApp, WeChat eller lokale chat-værktøjer.
- url: Peg brugere til lokaliserede hjælpe- eller kontaktsider hvis tilgængelige.
Ved at tilpasse 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"]
}
}
Forsendelse & leveringsdetaljer
Leveringsforventninger og regler varierer betydeligt fra land til land. Ved at bruge schema typer som DeliveryTimeSettings, ShippingDeliveryTime eller OfferShippingDetails der er regionspecifikke, kan du kommunikere ikke kun tilgængelighed og estimerede leveringstider, men også regioner der betjenes, forsendelsespriser og håndteringstider - alt sammen skal være lokaliseret for hvert marked. Forsendelses schema elementer der skal lokaliseres omfatter.
- leveringsdestination: region eller land, der betjenes.
- leveringstid: estimeret leveringstid i lokalt format (f.eks. 2 dage vs. 5-7 hverdage).
- forsendelsesRate: forsendelsesomkostninger i lokal valuta.
- transitTimeLabel: Etiket brugt til at beskrive leveringstiden (såsom “Ekspres”, “Normal” eller “Levering inden for 24 timer”).
- handlingTime: behandlingstid før levering begynder.
For eksempel kunne en kunde i Tyskland forvente levering inden for 3 hverdage, mens det i Indonesien kunne være 5-7 dage. Hvis leveringsskemaet ikke er lokaliseret, får brugerne muligvis ikke relevant information i søgeresultaterne, hvilket gør dem tøvende over for 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"
}
}
Butikslokation og lokal virksomhedsinformation
Nøjagtig visning af butikssteder i Google Søgning eller Google Maps afhænger i høj grad af vel lokaliseret LocalBusiness schema. Især når brugere søger på deres lokale sprog eller region, øger korrekt information synlighed og opbygger tillid. Nøgle elementer i LocalBusiness schema der kræver lokalisering omfatter.
- navn: forretningsnavnet oversættes, hvis det er relevant for den lokale kontekst.
- adresse: adressen formateret efter lokale konventioner, inklusive addressLocality, addressRegion, postalCode og addressCountry.
- telefon: telefonnummeret ved hjælp af den korrekte landekode og lokale formatering.
- openingHoursSpecification: Åbningstiderne tilpasses lokale tidszoner og forretningsvaner.
- geo: geografiske koordinater (breddegrad og længdegrad) for butikkens lokation.
- areaServed: det område eller den region, som 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å et lokalt forretningsopmærkningsskema.
Brødkrummesti
BreadcrumbList-schemaet hjælper med at definere din websites navigationsstruktur, viser brugere (og søgemaskiner) hvor de er inden for site-hierarkiet. Selvom dette kan synes ligetil, er lokalisering af brødkrummer kritisk på en flersproget e-handel-site for at sikre konsistens, forbedre SEO og forbedre brugeroplevelsen.
For eksempel, en brødkrummesti på engelsk, spansk og arabisk
- “Forside > Mænds Mode > Jakker”
- “Startside > Herremode > Jakker”,
- “Forside > Herremode > Frakker”.
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-schemaet, der kræver 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ødkrummestien (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-opmærkningsskema.
Almindelige fejl i skemalokalisering 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 til hvert regions sprog, valuta og brugerforventninger. Disse oversigter kan føre til brudte rige snippets, dårlig søgsynlighed eller brugerforvirring.
Nedenfor er nogle af de mest almindelige fejl i skema-lokalisering — 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 fejl i e-handel schema lokalisering er at holde fast i et enkelt sprog eller valuta på tværs af sidens strukturerede data - selv når front-end-indholdet er oversat. Denne uoverensstemmelse forvirrer både brugere og søgemaskiner. En kunde i Frankrig kan læse produktbeskrivelser på fransk, men se schema, der stadig henviser til USD i stedet for EUR, hvilket kan give tillidsproblemer.
Lokalt skema bør 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 produkt-skema bør 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 struktureret data-nøjagtighed. Tilpas altid dit schema efter sprog og region ved hjælp af hreflang og regionspecifikke underdomæner eller stier.
Opdaterer ikke valutakoder korrekt
Mange glemmer at opdatere valutakoden i schema-mæ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 manglende evne til at afspejle disse korrekt i “priceCurrency” fører 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 måske 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 højere afvisningsprocent eller forladte indkøbskurve.
Dobbelttjek altid valutaværdier i dit schema, især for butikker med flere valutaer, der bruger geolocation eller valutaswitchere. Ved at tilpasse visuel og struktureret valutainformation forbedres søgeoptræden og kundetillid.
Spring over regionspecifikke schema-felter
En anden fejl er at bruge generisk schema på tværs af regioner uden at inkorporere regionspecifikke elementer som "shippingDestination", "areaServed" eller "availableAtOrFrom". Disse felter er kritiske 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 sådanne detaljer, kan søgemaskiner antage, at man ikke sender derhen, hvilket påvirker synligheden i lokale søgninger.
Desuden hjælper felter som “areaServed” og “availableAtOrFrom” med at fremhæve din virksomhed ved “near me”- eller regionsbaserede søgninger. Hvis du ikke bruger disse skema-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 manglende tilpasning af skema-opmærkning til dette kan forårsage læsbarheds- og SEO-problemer. Selvom skemaet ikke vises visuelt, skal det stadig afspejle sprogkonteksten for at matche oplevelsen på siden og målrette søgesprog.
For eksempel skal felterne "name" og "description" i produktschemaet 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 schemaet skal matche det samme.
At negligere RTL-understøttelse medfører inkonsistens mellem det visuelle og strukturerede indhold, hvilket potentielt kan forvirre brugere og påvirke berettigelsen til rige resultater. 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 schema-lokalisering er at beholde brødkrumme-schemaet i det oprindelige sprog, selv når den synlige navigationssti er oversat.
For eksempel, hvis din side viser “Inicio > Moda Femenina > Vestidos” (spansk for “Hjem > Damesmode > Kjoler”), skal din BreadcrumbList-skema afspejle dette præcist. Brug af “name”: “Hjem” i stedet for “Inicio” skaber en diskontinuitet og kan have en negativ indvirkning på, hvordan Google fortolker webstedets struktur.
Hvert niveau i breadcrumb-listen (“name”) bør lokaliseres, og det tilsvarende “item” bør linke til den lokaliserede URL. At holde alt sammen på linje 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 one-size-fits-all schema-tilgang på tværs af alle sprog. Gendannelse af de samme strukturerede data uden at tilpasse indhold, valuta, sprog og regionssammenhæng besejrer hele formålet med lokalisering.
Hver lokaliserede version af din hjemmeside bør have sin skema, der afspejler det lokale indhold og metadata. For eksempel, hvis du har separate produktsider for engelsk og fransk, bør deres produkt-skema have oversat “name”, “description”, “priceCurrency”, og endda sprogspecifikke URL'er.
Hvis man forsømmer denne praksis, kan det 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 sprog-underdomæne eller hreflang-mærket version, hvilket sikrer, at de strukturerede data matcher sproget og den region, der betjenes.
Bedste praksis for lokalisering af schema-mærkning til e-handel
Schema-mærkning 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 søgeresultater, forbedrer klikfrekvensen og forbedrer købsoplevelsen for brugere over hele verden.
Her er de bedste praksisser, som enhver global e-commerce virksomhed 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 skema-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, sprogtilpasset skema.
Hvis din tyske side stadig bruger schema på engelsk, kan Google måske have svært ved at forstå sidens lokale kontekst, og brugerne kan finde oplevelsen inkonsistent med deres forventninger, for eksempel som nedenfor.
Land | Skema-felt | Lokalt værdi |
/fr/produkt-side | “navn” | "Vinterjakke til mænd" |
“beskrivelse” | “En varm jakke til den franske vinter” | |
“sprog” | “fr” |
Tilpas produktnavne og beskrivelser til lokalområdet
Produktnavne og beskrivelser bør ikke bare oversættes og kulturelt tilpasses. Sætninger, der lyder tiltalende i ét land, kan 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 eksperter for at undgå akavet formulering eller uklar budskab. Felter som navn, beskrivelse og mærke i dit skema skal afspejle det lokale sprog og præferencer.
Sprog | navn | beskrivelse |
Engelsk | “Mænds Sleek Jakke” | “En stilfuld jakke perfekt til vinter” |
japansk | “Herre vinterjakke” | “En smart jakke, der er perfekt til vinteren.” |
Angiv 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 skema nøjagtigt afspejler den korrekte valuta ved hjælp af ISO 4217-koden i feltet priceCurrency. Priser bør også formatters 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 SAR |
Lokalisér forretningsinformation
Forretningskontaktoplysninger, såsom adresser, telefonnumre og åbningstider, skal lokaliseres efter region. Brug lokale formater til felter som addressLocality, postalCode og addressCountry. Inkluder internationale opkaldskoder i telefonnumre for at gøre det lettere for brugerne at kontakte dig.
Felter som openingHoursSpecification bør afspejle lokale tidszoner og forretningsforhold. Disse detaljer hjælper med at etablere tillid og forbedre din forretnings udseende i lokale søgeresultater. For eksempel.
Land | by | postnummer | åbningstiderFormat |
Spanien | Barcelona | 08001 | Ma-Fr 09:00–18:00 |
Thailand | Chiang Mai | 50000 | Man-Lør 10:00–19:00 |
Struktur schema 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 indhold fra venstre mod højre, 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) | Lokalisering (RTL/Arabisk) |
navn | Vinterjakke | معطف شتوي |
beskrivelse | En varm frakke til vinter | Varm jakke ideel til vinteren |
brødkrumme | Hjem > Tøj > Jakker | Forside > Tøj > Jakker |
Automatiser skema-lokalisering med Linguise
Lokalisering af skema markup manuelt på tværs af flere sprog kan være komplekst, især når man håndterer hundredvis af dynamiske produktsider. Det synlige indhold og de strukturerede data, herunder Produkt, Tilbud, BreadcrumbList og LocalBusiness-skemaer, 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-mærkning og dit indhold. Gennem sin 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 lokalisering af breadcrumb-URL'er, interne links og endda billedreferencer. Dette sikrer, at alle elementer, navigationsstier, aktiver og strukturerede data—er på linje med den korrekte sprogversion, hvilket hjælper søgemaskiner med at levere mere præcise og relevante rich results til brugere verden over.
Konklusion
Lokalisering af skema-opmærkning 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 priser til leveringsoplysninger og forretningsinformation skal alle strukturerede data være i overensstemmelse med måmarkedets sprog, kultur og forventninger.
For at strømline denne proces, kan du overveje 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 brug af Linguise kan hjælpe hele din hjemmeside—synligt indhold og strukturerede data ligeledes er fuldt ud lokaliseret og SEO-klart.
