Strukturerede data internationalt: Schema.org på tværs af sprog

Introduktion til strukturerede data for flersprogede websites

Strukturerede data efter Schema.org hjælper søgemaskiner med at forstå indholdet på dit website – på tværs af sproggrænser. Hvis du driver flere sprogversioner, bliver korrekt markering endnu vigtigere. Søgemaskiner som Google bruger strukturerede data til at vise Rich Results som snippets, produktpriser eller FAQ-elementer. På flersprogede sider skal disse markeringer være sprogspecifikke, ellers kan der leveres forkerte oplysninger – f.eks. et telefonnummer fra den tyske side i den franske version.

En typisk fejl: Man overfører skemaet fra ét sprog til andre versioner uden at justere sprogangivelserne. Det er ikke nok kun at oversætte indholdet; strukturen skal også afspejle målsproget. For eksempel bør inLanguage-feltet i skemaobjektet angive sidens sprog. En tysk produktside får `inLanguage: 'de'`, den engelske `inLanguage: 'en'`. Derudover kan du med `translationOfWork` henvise til originalversionen.

Praktisk set bør du starte med de vigtigste sidetyper: Organisation, Produkt, FAQ. Disse bruges oftest til Rich Results. Forhåndsundersøg, hvilke sider på hvilket sprog der er særligt relevante. For en international virksomhedsside er Organization-skemaet velegnet, for en webshop Product-skemaet. Sørg for, at hver sprogversion får sit eget JSON-LD-script eller separate poster i scriptet. Brug værktøjer som Google Rich Results Test til at validere hver sprogversion individuelt. Bemærk, at testen kun giver et øjebliksbillede – regelmæssig kontrol anbefales.

Juridisk skal du være opmærksom på, at strukturerede data ikke må indeholde personoplysninger, der overtræder GDPR. Ved angivelse af kontaktoplysninger i forskellige lande skal du sikre, at data er korrekte og ajourførte. Søg rådgivning hos en juridisk rådgiver ved tvivl. Ved en ren implementering af flersprogede strukturerede data forbedrer du chancerne for at blive fundet med relevante Rich Results i de forskellige sprogregioner.

Grundlæggende om Schema.org og sprogmarkering

Schema.org tilbyder en fælles vokabularstruktur, der understøttes af søgemaskiner. For flersprogede websites er korrekt sprogmarkering central. Hvert skemaobjekt kan have en `inLanguage`-egenskab, der angiver sproget for indholdet (f.eks. `'de'`, `'en'`, `'fr'`). Denne angivelse bør stemme overens med sidens faktiske sprog. I JSON-LD sætter du `@language` enten på hele dokumentet eller på enkelte objekter, hvis flere sprog forekommer.

Et eksempel: For et produkt på tysk bruger du: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Hvis du markerer det samme produkt på en engelsk side, står der i stedet `"inLanguage": "en"` og navnet på engelsk. Undgå at blande flere sprogversioner i ét enkelt skemaobjekt – det fører til inkonsistens. Brug i stedet separate markup-blokke pr. sprog eller arbejd med `@language`-arrays inden for et objekt, hvis enheden er flersproget.

For website-specifikke angivelser som `WebSite` eller `WebPage` bør du også angive sproget. Ved en sprogskiftefunktion på siden kan du referere til de andre sprogversioner med `potentialAction` eller `translationOfWork`. I praksis har det vist sig fordelagtigt at placere en separat JSON-LD-blok for hvert sprog i det tilsvarende sidehoved. Så forbliver tilknytningen entydig og fortolkes korrekt af valideringsværktøjer.

Sørg for, at sprogkoderne følger ISO-639-1-standarden (f.eks. „de“ for tysk, „en“ for engelsk). For regionale varianter kan du tilføje landekoder, altså „de-CH“ for schweizertysk. Her skal du kontrollere, om søgemaskinen understøtter denne fintuning – som regel er basis-sprogkoden tilstrækkelig. Valider hver sprogversion enkeltvist med Googles Structured Data Testing Tool eller Rich Results Test. Notér eventuelle advarsler om manglende sprogangivelser og ret dem målrettet.

Organization-skema: Virksomhedsoplysninger på flere sprog

Organization-skemaet er ideelt for virksomheder med flersprogede websites, da det giver centrale oplysninger som navn, adresse og kontaktdata. For hver sprogversion bør du oprette et separat Organization-objekt, der er markeret på det pågældende sprog. `name` bør angives på målsproget – altså „Muster GmbH" på tysk og „Sample Inc." på engelsk. Hvis virksomheden har et ensartet navn, er oversættelsen af beskrivelsen (`description`) tilstrækkelig.

Ved adresser bruger du `PostalAddress`-skemaet med `addressCountry` og `addressLocality`. For internationale lokationer kan du have flere `location`-poster. Sørg for, at telefonnumre (`telephone`) har korrekt landekode. Eksempel: For den tyske side `+49 30 1234567`, for den schweiziske side `+41 44 1234567`. Det samme gælder for e-mail-adresser og åbningstider. Brug `areaServed` for at dække, hvilke lande virksomheden opererer i.

En ofte overset detalje er `sameAs`-egenskaben for sociale medieprofiler. Angiv sprogspecifikke profiler, hvis de findes – f.eks. den tyske Facebook-side og den engelske Twitter-tilstedeværelse. Også `url` bør henvise til den sprogspecifikke startside. For flersprogede websites kan du med `translationOfWork` oprette en forbindelse mellem sprogversionerne, hvis siderne viser samme indhold på et andet sprog.

Praktisk anbefaling: Implementer Organization-skemaet på startsiden for hver sprogversion. Tilføj et JSON-LD-script i `<head>`. Undgå dubletter ved at oprette en separat blok for hvert sprog med passende `inLanguage`. Valider markeringen med Googles Rich Results Test og kontrollér, at kontaktoplysningerne vises korrekt. Juridisk skal du være opmærksom på, at de angivne oplysninger er fuldstændige og databeskyttelseskompatible. Især ved flere lokationer: Impressumskravene kan variere fra land til land. Søg om nødvendigt juridisk rådgivning. Med disse detaljer sikrer du, at din virksomhed repræsenteres ensartet og korrekt på tværs af alle sprogregioner.

Product-skema: Produktbeskrivelser markeret sprogspecifikt

For flersprogede websider er det essentielt at markere produkter med Schema.org Product på det pågældende sprog. Hver sprogversion af et produkt bør have sin egen Schema-markering, der indeholder det lokale navn, beskrivelsen og attributter som pris, valuta eller tilgængelighed. Brug attributten `inLanguage` pr. sprog – f.eks. `"inLanguage": "de-DE"` for tysk (Tyskland). Sørg for, at produktnavnet og beskrivelsen i JSON-LD-objektet faktisk står på tysk, ikke kun sprogtagget.

En hyppig fejl er at markere alle sprogvarianter med samme `@id` (f.eks. en global produkt-id). I stedet bør du give hvert sprog sin egen `@id`, f.eks. `https://example.com/de/produkt/123` og `https://example.com/fr/produit/123`. Sådan kan Google vise den rigtige version. Ved priser bruger du `priceCurrency` med ISO-4217-kode (f.eks. EUR, USD) og angiver prisen sprogspecifikt – selvom prisen er den samme, hører den til den lokale side.

Praktisk anbefaling: Opret en JSON-LD-skabelon for hvert produkt, der dynamisk indstiller sprogparametrene. Test hver sprogversion individuelt med Googles Rich Results Test. Sørg for, at `url`-attributten peger på den respektive sprog-URL. Undgå at blande alle sprog i én JSON-LD-blok – det fører ofte til valideringsfejl. For billeder kan du holde `image`-attributten sproguafhængig, men sørg for, at billed-URL'erne er korrekte.

Derudover kan du tilpasse `offers` med `availability` afhængigt af marked (f.eks. `InStock` for Tyskland, `PreOrder` for Frankrig). Brug `gtin` eller `mpn` globalt, men behold lokale varianter for `sku`. Afslutningsvis test, om de strukturerede data i Search Console indekseres korrekt for hver sprogversion.

FAQ-Skema: Optimer spørgsmål-og-svar-sider flersproget

FAQ-sider på flere sprog drager fordel af en klar, sprogspecifik markering med skemaet FAQPage. Hver sprogversion af FAQ-siden får sit eget JSON-LD-objekt. Indstil `inLanguage` til den relevante sprogkode (f.eks. `fr-FR` for fransk). Spørgsmål og svar skal i objektet formuleres på målsproget – maskinoversættelse er ofte utilstrækkelig; få dem tjekket af en modersmålstalende, da nuancer er afgørende.

En typisk fejl: Samme `@id` for alle sprogvarianter. Brug i stedet den sprogspecifikke URL som `@id`, f.eks. `https://example.com/de/faq/` og `https://example.com/en/faq/`. Inden for FAQPage-skemaet lister du spørgsmålene som `mainEntity` med `@type: Question` og tilhørende svar som `acceptedAnswer`. Hvert spørgsmål kan desuden få `inLanguage`, men det er redundant, hvis hele siden er markeret. Begræns antallet af spørgsmål pr. side til maksimalt 10–15, da søgemaskiner kun tager begrænsede poster i betragtning.

Handlingsanbefaling: Brug et content management-system, der pr. FAQ-indlæg tilbyder et flersprogsfelt. I JSON-LD-outputtet forespørger du dynamisk det aktuelle sprog. Valider hver sprogversion individuelt med Rich Results Test og vær opmærksom på advarsler om manglende `name`-egenskaber ved spørgsmålene. Tilføj en `url` til hvert spørgsmål, der peger på det konkrete anker – så brugere kan springe direkte til det relevante svar.

Bemærk: FAQPage egner sig kun til sider med eksplicitte spørgsmål og svar. Brug det ikke til generelle supportsider. Test efter implementeringen synligheden i Google-søgning – FAQ-rich snippets vises ofte ved søgninger med spørgepartikler. For flersproget SEO er det værd at tilpasse svarene til landetypiske formuleringer (f.eks. „Hvordan kan jeg?“ vs. „Comment puis-je?“).

Finesserne ved inLanguage: Sprogkode og landestandard

Attributten `inLanguage` i Schema.org angiver sproget for et indhold, hvor værdien ideelt set består af en sprogkode (ISO 639-1) og en valgfri regionskode (ISO 3166-1 Alpha-2) – f.eks. `en-US` for amerikansk engelsk. Regionen er vigtig, hvis indholdet adskiller sig: „colour“ vs. „color“ eller forskellige måleenheder. Uden region tolkes koden som et generelt sprog. Brug derfor `de-DE`, `de-AT`, `de-CH` til landespecifikke sider, selvom teksten er næsten identisk.

Et praksiseksempel: Et produkt tilbydes på en tysk og en østrigsk side. Sproget er tysk, men priser og forsendelsesbetingelser er forskellige. Sæt `inLanguage: "de-DE"` for den tyske side og `"de-AT"` for den østrigske side. På den måde kan Google bedre forstå den regionale relevans. Det samme gælder for `en-GB` og `en-US`. Hvis du ikke har brug for regional differentiering, er `"de"` eller `"en"` tilstrækkeligt. Vær dog opmærksom på, at sprogkoden altid skrives med små bogstaver, og regionen med store bogstaver (f.eks. `fr-CA`).

En almindelig fejl er at bruge `inLanguage` på et overordnet objekt, mens underobjekter har et andet sprog. Eksempel: En WebSite på tysk, men en enkelt artikel på engelsk. Sæt da `inLanguage: "de"` på WebSite og `inLanguage: "en"` på Article. Valider dette med en schema-validator, da nogle værktøjer rapporterer konflikter. For flersprogede sider med hreflang-tags bør `inLanguage` korrespondere med den respektive hreflang-værdi – det hjælper Google med at levere den korrekte version.

Praktisk implementering: Definér en unik `@id` pr. sprogversion, og sæt `inLanguage` konsekvent. Brug en central konfigurationsfil, der indeholder de korrekte koder for hvert sprog. Test med schema.orgs værktøj, om `inLanguage`-tagget accepteres. Et tip: Glem ikke `inLanguage` selv ved AMP-sider eller strukturerede data via Microdata. Ved JSON-LD placeres det på øverste niveau (f.eks. `WebSite` eller `WebPage`). For dynamisk indhold som blogindlæg kan `inLanguage` variere pr. bidrag – sæt det da pr. emne.

Korrekt markering af flersprogethed på en enkelt URL

Hvis en URL indeholder indhold på flere sprog – f.eks. via sprogvælger, faneblade eller accordions – skal du i de strukturerede data tydeligt angive, hvilken tekst der hører til hvilket sprog. Ellers kan en søgemaskine-crawler fejlagtigt antage, at alt indhold er på ét sprog, hvilket kan føre til fejl i indeksering og visning.

Den grundlæggende metode er at bruge `inLanguage`-attributten på de relevante elementer. Ved et FAQ-skema med spørgsmål og svar på både tysk og engelsk på samme side markerer du hvert spørgsmål og svar individuelt: ```json { "@type": "Question", "name": "Hvordan tilmelder jeg mig?", "inLanguage": "da", "acceptedAnswer": { "@type": "Answer", "text": "Klik på ...", "inLanguage": "da" } } ``` Tilsvarende gælder for Product-skemaer: Beskriv `name` og `description` pr. sprog i et separat `Product`-objekt med eget `inLanguage`, eller brug `@language` og `@value` i en `multilingualDescription`-egenskab (hvis dit vokabular understøtter det).

For organisationer med flersprogede navne bruger du et array af `name`-objekter: ```json { "name": [ {"@language": "da", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Undgå at erklære hele siden som flersproget. I stedet bør du foretage sprogtildelingen så granulært som muligt. En almindelig fejl er at sætte `inLanguage` kun på øverste niveau af et skema uden at markere underordnede elementer. Kontrollér derfor i din valideringsworkflow, om alle tekster er korrekt sprogligt markeret.

Som konkret handlingsanbefaling: Opret for hver sprogvariant på en URL et separat skema-objekt, der kun indeholder teksterne på dette sprog, og sæt `inLanguage` til den tilsvarende sprogkode. Hvis siden som standard viser ét hovedsprog, men de andre indlæses via JavaScript, skal du placere de strukturerede data for alle sprog statisk i HTML. Værktøjer som Googles Rich Results Test viser dig, om markeringen fortolkes korrekt. Test hver sprogversion individuelt ved at tvinge crawleren til det ønskede sprog via en URL-parameter eller cookie-kontrol.

Afgrænsning af hreflang og inLanguage: Hvornår skal hvilken metode bruges?

`hreflang` og `inLanguage` opfylder forskellige formål inden for international SEO og bør ikke forveksles. `hreflang` er et HTML-element eller en HTTP-header, der signalerer til søgemaskiner, at der findes alternative sprog- eller regionsversioner af samme side. Det sikrer, at den relevante side leveres til brugere i forskellige lande eller med bestemte sprogindstillinger. `inLanguage` derimod er et attribut i strukturerede data (Schema.org), der angiver det sprog, som et bestemt tekstelement er skrevet på.

Hvornår bruger du hvad? Brug `hreflang`, når du har separate URL'er til forskellige sprogversioner (f.eks. `example.com/de/` og `example.com/en/`). Det forhindrer problemer med dubletindhold og sikrer, at den korrekte side vises i søgeresultatet. `inLanguage` er nødvendigt, når du på en enkelt URL markerer flersproget indhold, eller når et struktureret dataelement som en produktbeskrivelse foreligger på flere sprog. `inLanguage` supplerer altså `hreflang` på niveauet af enkelte tekstblokke.

En almindelig misforståelse: `inLanguage` erstatter ikke `hreflang`. Selvom du markerer hver linje af en artikel med `inLanguage`, ved søgemaskiner uden `hreflang` ikke, om der findes alternative versioner af hele siden. Omvendt er `hreflang` ikke tilstrækkeligt til at beskrive flersproget indhold inden for én URL i fin detaljegrad. I praksis betyder det: Har du separate sider for hvert sprog, er `hreflang` primært påkrævet, mens `inLanguage` kun i de strukturerede data på disse sider angiver det konkrete sprog for indholdet. Hvis flere sprog ligger på én URL, har du brug for `inLanguage` for hvert sprogspecifikt element.

Konkret anbefaling: Planlæg din URL-strategi før implementering. Beslut, om du vil have én URL pr. sprog (ccTLD, subdomæne, underkatalog) eller en fælles URL med dynamisk sprogskift. For sidstnævnte er korrekt `inLanguage`-markering afgørende. Kontrollér under alle omstændigheder, at dine `hreflang`-tags peger på alle relevante sprogversioner, og at der ikke er modsætninger til `inLanguage`-angivelserne i de strukturerede data. En afstemning af disse to signaler kan hjælpe søgemaskiner med at klassificere dit indhold korrekt.

Valideringsworkflow: Værktøjer og automatiserede kontroller

Manuel kontrol af strukturerede data på hver sprogversion er fejlbehæftet og tidskrævende. Et automatiseret valideringsworkflow sikrer, at dine Schema.org-markeringer er korrekte og forbliver det – også efter indholdsopdateringer eller ved tilføjelse af nye sprog. De vigtigste værktøjer er Google Rich Results Test (for af Google understøttede typer som FAQ, Product) og Schema.org Validator (til ren syntakskontrol). Derudover hjælper crawlers som Screaming Frog SEO Spider med at udtrække strukturerede data på hele dit website og kontrollere for fejl.

Integrer kontrollen i din CI/CD-proces: Efter hver implementering eller sprogopdatering skal du køre en automatiseret test. Brug API'en til Google Rich Results Test eller et script, der parser dine sider og kontrollerer JSON-LD-blokkene mod et selvdefineret skema. Vær særligt opmærksom på følgende fejlkilder: - Manglende `inLanguage` på steder, hvor flere sprog forekommer. - Modstridende sprogkoder (f.eks. "de" i stedet for "de-DE" ved regionsspecifikke varianter). - Ufuldstændige obligatoriske felter (f.eks. `name` for Product på hvert sprog). - Forældede `hreflang`-tags, der ikke længere matcher dine aktuelle URL'er.

Konkret handlingsanbefaling: Opret en tjekliste for hver Schema-type (Organization, Product, FAQ) med de nødvendige attributter pr. sprog. Brug et testværktøj som `json-schema` til automatisk validering af dine data. Foretag desuden regelmæssigt (f.eks. månedligt) et fuldt crawl med Schema.org Validator, og lad dig generere rapporter over fejlbehæftede sider. Dokumentér fejlkategorierne, og tildel ansvarlige for rettelser. Bemærk at strukturerede data skal kontrolleres på de levende sider – en test i staging er ikke tilstrækkelig, da der kan være andet indhold. Kun på den måde sikrer du, at søgemaskinerelaterede fejl bliver rettet rettidigt.

Almindelige fejl ved internationale strukturerede data

Annotering af flersprogede websider med Schema.org indeholder typiske faldgruber. En hyppig fejl er manglen eller forkert angivelse af sprogattributten `inLanguage`. Hvis du f.eks. tilbyder et produkt på tysk, men ikke angiver `inLanguage: "de-DE"` i markeringen, kan søgemaskiner fortolke dataene som sprogneutrale. En anden grundlæggende fejl er at blande sprog inden for en enkelt Schema-blok. Du bør undgå at sætte `name`-egenskaben på engelsk og `description` på tysk i et `Product`-objekt. I stedet skal der oprettes en separat blok for hver sprogversion med korrekt `inLanguage`.

En anden udbredt fejl er brugen af uhensigtsmæssige Schema-typer. For en flersproget virksomhed griber mange fejlagtigt til `LocalBusiness`, selvom `Organization` er det rigtige valg, når der ikke foreligger en fysisk adresse på hvert sprog. Også ved produkter glemmes det ofte at markere `offers`-egenskaben sprogspecifikt. Hertil kommer undladelse af at opdatere strukturerede data efter oversættelser: En nyligt oversat produkttekst skal også justeres i markeringen – ellers viser søgeresultater forældede eller forkerte oplysninger.

Forsømmelse af validering er en anden kardinalfejl. Efter hver ændring bør du kontrollere markeringerne med egnede værktøjer. Forkerte eller manglende `@id`-referencer for enheder, der er ens på tværs af sprog (f.eks. en organisation), fører til dubletter eller ufuldstændige data. Derudover ignoreres samspillet med `hreflang` ofte: Hvor der ikke findes alternative URL'er, skal du arbejde med `inLanguage` på samme side.

Handlingsanbefalinger: Kontroller hver markering for korrekt sprogtildeling. Brug separate Schema-blokke for hver sprogversion med unikke `@id`-værdier. Undgå blanding – også i `aggregateRating` eller `review` skal sproget være korrekt. Udfør en ny validering efter hver oversættelse, og afstem dataene med de synlige indhold. Kun på den måde sikrer du, at søgemaskiner forstår dine flersprogede tilbud korrekt.

Test med Google Rich Results, Bing Webmaster Tools og Yandex

Kontrollen af flersprogede Schema.org-markeringer bør ikke begrænses til ét enkelt værktøj. Hver søgemaskine har sine egne fortolkninger og valideringskriterier. Google Rich Results Test er det første sted at starte: Indtast en URL med din markering, eller indsæt koden direkte. Vær opmærksom på alle fejl og advarsler – især om `inLanguage`-angivelserne genkendes korrekt. Et almindeligt problem er, at Google accepterer `de-DE`, men ved manglende regionsdel (`de`) alligevel udsender en advarsel. Test hver sprogversion enkeltvis.

Bing Webmaster Tools tilbyder en URL-kontrol med en struktureret datavisning. Her kan du se, om Bing fortolker markeringerne som forventet. Bing er ofte strengere ved validering af `inLanguage` og forventer muligvis udelukkende den to-cifrede sprogkode uden region (f.eks. `de` i stedet for `de-DE`). Udfør en live-test, og ret afvigelser. Bing viser desuden mulige dubletter, hvis `@id`-værdier bruges flere gange.

Yandex Webmaster har sin egen validator, som især er relevant for russisksprogede sider. Også her kan du teste strukturerede data. Yandex understøtter de fleste Schema.org-typer, men fejlhåndteringen er anderledes. Især ved `Product`-markeringer påpeges ofte `availability`-egenskaben. Test derfor også hver sprogversion her. Bemærk, at Yandex kan vægte regionale sprogkoder som `de-DE` anderledes.

Handlingsanbefalinger: Test hver sprogversion i alle tre værktøjer efter implementeringen og efter hver ændring. Notér afvigelser, og tilpas markeringerne, så de accepteres af alle tre søgemaskiner. Brug ideelt set den to-cifrede sprogkode (`de`, `en`) i `inLanguage`, da den forstås ens af de fleste systemer. Automatisér testene med CI-værktøjer for at bevare overblikket på flersprogede websider med mange sider.

Tjekliste til implementering af flersprogede Schema.org-markeringer

En struktureret fremgangsmåde forhindrer typiske fejl ved internationalisering. Før implementeringen bør du fastlægge sprogstrategien: Brug separate URL'er pr. sprog (f.eks. `/de/produkt` og `/en/product`) eller en enkelt URL med sprogskift? For separate URL'er bruger du `hreflang` og pr. URL et eget markup. Ved en enkelt URL sætter du flere `inLanguage`-blokke med forskellige sprogkoder. Planlæg desuden, hvilke skematyper der er nødvendige: Virksomhed (Organization), Produkter (Product), FAQ (FAQPage) etc.

Ved implementeringen skal du være opmærksom på følgende punkter: Hvert skema-objekt får et unikt `@id`, der identificerer entiteten sprog-uafhængigt. For hver sprogversion opretter du et separat objekt, der via `inLanguage` angiver sproget. Brug konsistente sprogkoder – fortrinsvis den to-cifrede ISO-kode (f.eks. `de`, `en`) suppleret med region, hvis nødvendigt. Link korrekt inden for markupperne: Ved `Organization` bruger du `url` og `logo` med sprogspecifikke stier. Kontroller, at tekster som `name` og `description` stemmer overens med de synlige indhold.

Efter implementeringen følger validering: Test hver sprogversion med Google Rich Results Test, Bing Webmaster Tools og Yandex. Ret fejl og advarsler. Vær særlig opmærksom på manglende `inLanguage` eller forkerte sprogkoder. Brug desuden Schema.org-valideringsværktøjet fra Google til at kontrollere syntaksen. Dokumentér alle ændringer, og foretag fornyede tests efter hver oversættelse.

Afslutningsvis hører overvågning til processen: Overvåg ydeevnen i Search Console, især rapporterne om strukturerede data. Reager på nye fejl eller påtaler. Opdater markupperne rettidigt, når du ændrer eller oversætter indhold. Foretag regelmæssige audits for at sikre konsistens på tværs af alle sprogversioner. En velplejet Schema.org-implementering forbedrer synligheden i søgeresultaterne – uden garantier, men med praktisk nytte.

Juridiske bemærkninger: Eget ansvar ved automatisk oversættelse

Den automatiske oversættelse af strukturerede data indebærer juridiske risici, som du som operatør af en flersproget hjemmeside selvstændigt skal kontrollere. Især ved Schema.org-markupper, der indeholder juridisk relevante indhold som produktsikkerhedshenvisninger, handelsbetingelser eller varemærkebetegnelser, kan en unøjagtig oversættelse føre til erstatningsansvar. For eksempel kan et forkert oversat produktnavn eller en vildledende produktbeskrivelse overtræde konkurrenceretten. Vi anbefaler derfor, at alle automatisk oprettede oversættelser korrekturlæses af en modersmålsfagkyndig. Dette gælder især for felter som "description" i Product-skemaet eller "answer" i FAQ-skemaet, hvor nuancer er afgørende.

Ud over den indholdsmæssige korrekthed spiller databeskyttelsesretlige aspekter også en rolle: Hvis dit skema indeholder personoplysninger (f.eks. kundeanmeldelser i Review-skemaet), skal du sikre, at oversættelsen er GDPR-konform. Automatiske oversættelsestjenester bør kun anvendes, hvis tjenesten tilbyder tilstrækkelige databeskyttelsesgarantier. Der er intet generelt forbud, men ansvaret for databehandlingen ligger hos dig som hjemmesideoperatør. Få rådgivning fra en juridisk rådgiver om de specifikke krav i dine mållande.

En anden juridisk faldgrube: Brugen af "inLanguage" med ugyldige sprogkoder. Brug altid de officielle BCP-47-koder (f.eks. "de-DE" i stedet for "deutsch"). Forkerte koder kan føre til, at dine markupper ignoreres af søgemaskiner – hvilket ganske vist ikke er et juridisk problem, men påvirker findbarheden. Foretag derfor inden offentliggørelse en validering med værktøjer som Google Rich Results Test, og kontroller supplerende, om oversættelserne dækker alle juridisk relevante felter korrekt.

Handlingsanbefaling: Definér en arbejdsgang, hvor hver automatisk oversat skema-annotering kontrolleres af en modersmålsredaktør eller jurist. Dokumentér denne proces for at kunne påvise, at du har opfyldt din omsorgspligt i en eventuel tvist. Undlad automatisk oversættelse af tekstblokke med retlig karakter (f.eks. garantibetingelser, ansvarsfraskrivelser); oversæt disse manuelt eller via en fagtjeneste.

Udsigt: AI-understøttet lokalisering og fremtidige skema-udviklinger

Lokaliseringen af Schema.org-markups bliver i stigende grad lettet af AI-drevne værktøjer. Moderne systemer kan baseret på neurale netværk skabe oversættelser, der er mere kontekstuelt præcise end ældre statistiske metoder. For flersprogede websteder betyder det: Du kan hurtigere overføre store mængder produktdata eller FAQ-indhold til flere sprog. Alligevel er kvalitetssikring afgørende, da AI-modeller ikke altid fanger branchespecifikke termer eller regionale nuancer korrekt. En praktisk tilgang er at bruge AI til råoversættelse efterfulgt af en menneskelig gennemgang. Værktøjer som Baduno kombinerer AI-oversættelse med modersmålsgennemgang og tilbyder dermed en skalerbar løsning.

Parallelt med AI-udviklingen udvider Schema.org løbende sit ordforråd. Fremtidige typer kan i højere grad fokusere på AI-genereret indhold, for eksempel et "AIContent"-skema til mærkning af maskinelt skrevne tekster. Også forbindelsen til Knowledge Graphs bliver vigtigere: Flersprogede markups kan i fremtiden automatisk genereres fra centrale vidensbaser. Allerede nu findes der egenskaben "translationOfWork", som eksplicit gør forholdet mellem oversat indhold synligt. Vi anbefaler, at du inddrager sådanne nye egenskaber tidligt i din strategi for at være klar til søgemaskineopdateringer.

En anden trend er dynamiske, sprogspecifikke markups, der vises baseret på brugerkontekst. For eksempel kan et Product-skema afhængigt af brugerens placering indeholde den lokale valuta og måleenhed. Udfordringen ligger i korrekt brug af "inLanguage" og undgåelse af konflikter med hreflang. Fremtidige skemaversioner kan definere tydeligere, hvordan regionale varianter kan præsenteres inden for et skema. For at forberede dig bør du opbygge dine markups modulært: Brug separate blokke for hvert sprog inden for samme JSON-LD eller brug separate script-tags pr. sprogversion – afhængigt af din tekniske infrastruktur.

Handlingsanbefaling: Test AI-baserede oversættelsesløsninger med et repræsentativt sæt af dine skemadata og mål fejlprocenten. Hold dig opdateret via Schema.org-udgivelsesnoter for at identificere nye egenskaber. Pilottest dynamisk visning af markups til forskellige målgrupper og valider resultaterne med søgemaskinernes Search Consoles. På den måde sikrer du, at dit flersprogede websted drager fordel af fremtidige udviklinger uden at påtage sig juridiske eller tekniske risici.

Praktisk eksempel: Trinvis implementering af en flersproget produktside

For at omsætte de teoretiske grundlag til praksis ser vi på et fiktivt e-handelswebsted, der tilbyder en smartphone på tysk, engelsk og fransk. Antag, at produktsiden er tilgængelig under en enkelt URL med sprogvælger (f.eks. example.com/smartphone). Målet er at forsyne Schema.org Product-markup med sprogspecifikke oplysninger.\n\n1. **Fastlæg sprogkoder**: For hver sprogvariant bruges en unik inLanguage-værdi. Eksempel: Tysk: "de-DE", Engelsk: "en-US", Fransk: "fr-FR".\n\n2. **Mærk navn og beskrivelse sprogspecifikt**: I JSON-LD-markuppen bruges et @graph-array. Hver sprogvariant tildeles sit eget produktobjekt med tilhørende inLanguage. Eksempel:\n```json\n{\n "@context": "https://schema.org",\n "@graph": [\n {\n "@type": "Product",\n "inLanguage": "de-DE",\n "name": "Smartphone Pro Max",\n "description": „Leistungsstarkes Smartphone mit 128 GB Speicher“,\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "en-US",\n „name“: „Smartphone Pro Max“,\n "description": „Powerful smartphone with 128 GB storage“,\n "offers": { ... }\n },\n {\n "@type": "Product",\n "inLanguage": "fr-FR",\n "name": „Smartphone Pro Max“,\n "description": „Smartphone puissant avec 128 Go de stockage“,\n "offers": { ... }\n }\n ]\n}\n```\n\n3. **Valider markup**: Med Google Rich Results Test kontrolleres for hver sprogversion, om markuppen accepteres. Vær opmærksom på, at inLanguage-angivelserne stemmer overens med sidens faktiske sprog.\n\n4. **Integration via server-side eller JavaScript**: I praksis genereres markuppen bedst serverside, så sidens kildekode indeholder den komplette JSON-LD. Ved dynamiske sprogskift via JavaScript kan markuppen indlæses efterfølgende, men dette registreres muligvis ikke af søgemaskiner.\n\n5. **Test synlighed**: Efter implementeringen kontrolleres, om de strukturerede data i Google Search Console rapporteres som gyldige, og om Rich Results vises i søgningen.\n\nDette trin-for-trin-eksempel viser, hvordan du helt konkret kan gå frem. Tilpas strukturen til din teknologi, og test hver sprogvariant individuelt.

Samarbejde med oversættelses- og lokaliseringsudbydere

Når du implementerer flersprogede strukturerede data, samarbejder du ofte med oversættere eller lokaliseringsbureauer. Det er vigtigt, at Schema.org-markups også bliver en del af lokaliseringsprocessen. Drøft med din tjenesteudbyder, at ikke kun det synlige indhold, men også værdierne i JSON-LD (f.eks. 'name', 'description') skal oversættes. En almindelig fejl: Bureauet modtager kun sidens tekst, ikke de strukturerede data. Lever derfor et separat dokument med alle Schema-felter – ideelt set i JSON-format – og fastlæg, hvilke felter der skal oversættes sprogspecifikt (f.eks. kan 'offers' eller 'review' forblive globale, mens 'name' varierer efter sprog).

Praktisk tip: Brug glossarer og oversættelseshukommelser også til dine strukturerede data. På den måde sikrer du, at produktnavne og fagudtryk fremstår ensartet i alle markups. Bed desuden tjenesteudbyderen om at sætte sprogkoderne (inLanguage) i henhold til din anvisning – f.eks. 'da-DK' i stedet for kun 'da'. Efter levering bør du stikprøvevis kontrollere, at alle oversatte feltværdier er korrekt indsat i markups. En automatiseret test med Googles Rich Results Test kan give første indikationer.

Endnu et aspekt: Samarbejdet om kvalitetssikring. Aftal, at de oversatte Schema-data bliver gennemlæst af en modersmålstalende redaktør før offentliggørelse. Forkert oversatte produktattributter eller instruktioner i FAQ-spørgsmål kan skade den internationale rangering. Dokumentér hele processen – fra ekstraktion af kildetekster til implementering – og opdater din tjekliste for hver sprogversion. På den måde undgår du, at de strukturerede data forældes ved senere opdateringer.

Juridisk bemærkning: Ansvaret for korrekte oversættelser ligger hos dig. Få skriftlig bekræftelse på overholdelse af dine krav, og afklarlig erstatningsspørgsmål ved fejloversættelser kontraktligt. Uafhængig juridisk rådgivning anbefales.

Budgetplanlægning og ressourceestimering til flersproget schema-implementering

Indførelsen af strukturerede data på flere sprog medfører både engangs- og løbende omkostninger. Ud over selve oversættelsen af markup-indholdet kommer udgifter til teknisk integration, test og vedligeholdelse. For en realistisk budgetplanlægning skal du tage højde for følgende poster:

1. Oversættelse af Schema-felter: Per sprogversion opstår der omkostninger til oversættelse af alle relevante JSON-LD-elementer (titler, beskrivelser, spørgsmål, svar osv.). Da der ofte er tale om korte, tekniske tekster, kan oversættelsesbureauer tilbyde særlige priser. Beregn et tillæg på 10–20 % til indføring i Schema-definitionerne.

2. Teknisk tilpasning: Markup skal for hvert sprog enten ske i separate JSON-LD-blokke eller via flersprogede felter. Afhængigt af systemet har dit udviklerteam brug for ekstra tid til at implementere logik for sprogskift og fallbacks. Erfaringsmæssigt ligger det indledende arbejde for en hjemmeside med fem sprogversioner mellem 15 og 25 personers dages udvikling.

3. Test og kvalitetssikring: Hver sprogversion skal valideres individuelt – med Googles Rich Results Test, Schema.org-validatorer og manuelle stikprøver. Planlæg ca. 1–2 dage pr. sprog til den første opsætning og en halv time pr. ændring.

4. Løbende vedligeholdelse: Ved opdateringer af produktsortimentet eller FAQ-indhold skal markups også tilpasses rettidigt. Fastlæg, om oversættelsesteamet altid skal levere Schema-data sammen med nyt indhold. Et content management-system, der automatisk genererer strukturerede data, reducerer den langsigtede indsats, men kræver tilsvarende opsætning.

5. Værktøjer og licenser: Hvis du bruger særlige værktøjer til overvågning af strukturerede data (f.eks. Webmaster Tools-API'er eller egne dashboards), kan der være abonnementsgebyrer.

Som tommelfingerregel bør du for hele processen (indførelse i tre hovedsprog) regne med et budget på 5.000 til 15.000 euro, afhængigt af sidens omfang og antallet af produkter. Ved små projekter med få FAQ-sider kan beløbet også være lavere.

Juridisk bemærkning: De nævnte tal er kun vejledende. Indhent individuelle tilbud fra udviklere og oversættere, og vær opmærksom på, at de faktiske omkostninger kan variere afhængigt af kompleksiteten. For bindende udsagn henvises til din juridiske og skattemæssige rådgivning.