Strukturerad data internationellt: Schema.org över språkgränser

Introduktion till strukturerad data för flerspråkiga webbplatser

Strukturerad data enligt Schema.org hjälper sökmotorer att förstå innehållet på din webbplats – över språkgränserna. När du har flera språkversioner blir korrekt märkning ännu viktigare. Sökmotorer som Google använder strukturerad data för att visa Rich Results som utdrag, produktpriser eller FAQ-element. För flerspråkiga sidor måste dessa märkningar vara språkspecifika, annars kan felaktig information visas – till exempel ett telefonnummer från den tyska sidan i den franska versionen.

Ett typiskt misstag: Man överför schemat från ett språk till andra versioner utan att anpassa språkangivelserna. Det räcker inte att bara översätta innehållet; strukturen måste också återspegla målspråket. Till exempel bör inLanguage-fältet i schemaobjektet ange sidans språk. En tysk produktsida får `inLanguage: 'de'`, den engelska `inLanguage: 'en'`. Dessutom kan du med `translationOfWork` hänvisa till originalversionen.

Praktiskt taget börjar du med de viktigaste sidtyperna: Organisation, Produkt, FAQ. Dessa används mest för Rich Results. Kontrollera först vilka sidor på vilket språk som är särskilt relevanta. För en internationell företagssida passar Organization-schemat, för en onlinebutik Product-schemat. Se till att varje språkversion får ett eget JSON-LD-skript eller separata poster i skriptet. Använd verktyg som Googles Rich Results Test för att validera varje språkversion separat. Observera att testet bara ger en ögonblicksbild – regelbunden kontroll rekommenderas.

Juridiskt bör du notera att strukturerad data inte får innehålla personuppgifter som strider mot GDPR. Vid angivelse av kontaktuppgifter i olika länder bör du säkerställa att uppgifterna är korrekta och aktuella. Sök vid tvivel stöd från en juridisk rådgivare. Genom en ren implementering av flerspråkig strukturerad data ökar du chanserna att hittas med relevanta Rich Results på olika språkområden.

Grunderna i Schema.org och språkmärkning

Schema.org tillhandahåller en gemensam vokabulärstruktur som stöds av sökmotorer. För flerspråkiga webbplatser är korrekt språkmärkning central. Varje schemaobjekt kan ha en `inLanguage`-egenskap som anger innehållets språk (t.ex. `'de'`, `'en'`, `'fr'`). Denna angivelse bör överensstämma med sidans faktiska språk. I JSON-LD anger du `@language` antingen på hela dokumentet eller på enskilda objekt om flera språk förekommer.

Ett exempel: För en produkt på tyska använder du: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Om du märker samma produkt på en engelsk sida står istället `"inLanguage": "en"` och namnet på engelska. Undvik att blanda flera språkversioner i ett enda schemaobjekt – det leder till inkonsekvenser. Använd istället separata markup-block per språk eller arbeta med `@language`-arrayer inom ett objekt om entiteten är flerspråkig.

För webbplatsspecifika uppgifter som `WebSite` eller `WebPage` bör du också ange språket. Vid språkomkoppling på sidan kan du hänvisa till andra språkversioner med `potentialAction` eller `translationOfWork`. I praktiken är det beprövat att placera ett eget JSON-LD-block för varje språk i motsvarande sidhuvud. På så sätt förblir tilldelningen entydig och tolkas korrekt av valideringsverktyg.

Se till att språkkoderna följer ISO-639-1-standarden (t.ex. "de" för tyska, "en" för engelska). För regionala varianter kan du lägga till landskoder, alltså "de-CH" för schweizisk tyska. Då måste du kontrollera om sökmotorn stöder denna finåtskillnad – i regel räcker basspråkskoden. Validera varje språkversion separat med Googles verktyg för strukturerad data eller Rich Results Test. Anteckna eventuella varningar om saknade språlangivelser och åtgärda dem riktat.

Organisationsschema: Företagsuppgifter på flera språk

Organisationsschemat är idealiskt för företag med flerspråkiga webbplatser eftersom det tillhandahåller central information som namn, adress och kontaktuppgifter. För varje språkversion bör du skapa ett eget organisationsobjekt som är märkt på motsvarande språk. `name` bör anges på målspråket – alltså "Muster GmbH" på tyska och "Sample Inc." på engelska. Om företaget har ett enhetligt namn räcker det med översättning av beskrivningen (`description`).

Vid adresser använder du `PostalAddress`-schemat med `addressCountry` och `addressLocality`. För internationella platser kan du ange flera `location`-poster. Se till att telefonnummer (`telephone`) har korrekt landskod. Exempel: För den tyska sidan `+49 30 1234567`, för den schweiziska sidan `+41 44 1234567`. Detsamma gäller e-postadresser och öppettider. Använd `areaServed` för att täcka vilka länder företaget verkar i.

En ofta förbisedd detalj är `sameAs`-egenskapen för sociala medier. Ange språkspecifika profiler om sådana finns – till exempel den tyska Facebook-sidan och den engelska Twitter-närvaron. Även `url` bör peka på den språkspecifika startsidan. För flerspråkiga webbplatser kan du använda `translationOfWork` för att skapa samband mellan språkversionerna om sidorna återger samma innehåll på olika språk.

Praktisk rekommendation: Implementera organisationsschemat på startsidan för varje språkversion. Använd ett JSON-LD-skript i `<head>`. Undvik dubbletter genom att skapa ett eget block för varje språk med lämpligt `inLanguage`. Validera märkningen med Googles Rich Results Test och kontrollera att kontaktuppgifterna visas korrekt. Juridiskt måste du beakta att den angivna informationen är fullständig och dataskyddskonform. Särskilt vid flera platser: Impressumskyldigheten kan variera mellan länder. Rådfråga vid behov juridisk expertis. Genom dessa detaljer säkerställer du att ditt företag representeras enhetligt och korrekt i alla språkregioner.

Produktschema: Produktbeskrivningar språkspecifikt märka

För flerspråkiga webbplatser är det avgörande att märka upp produkter med Schema.org Product på respektive språk. Varje språkversion av en produkt bör få en egen schemamarkering som innehåller det lokala namnet, beskrivningen samt attribut som pris, valuta eller tillgänglighet. Använd attributet `inLanguage` per språk – t.ex. `"inLanguage": "de-DE"` för tyska (Tyskland). Se till att produktnamn och beskrivning i JSON-LD-objektet faktiskt står på tyska, inte bara språktaggen.

Ett vanligt misstag är att märka alla språkvarianter med samma `@id` (t.ex. en global produkt-ID). Använd istället en egen `@id` för varje språk, som `https://example.com/de/produkt/123` och `https://example.com/fr/produit/123`. På så sätt kan Google visa rätt version. Vid priser använder du `priceCurrency` med ISO-4217-kod (t.ex. EUR, USD) och anger priset språkspecifikt – även om priset är detsamma, hör det till den lokala sidan.

Praktisk rekommendation: Skapa en JSON-LD-mall för varje produkt som dynamiskt ställer in språkparametrar. Testa varje språkversion separat med Googles Rich Results Test. Kontrollera att `url`-attributet pekar på respektive språk-URL. Undvik att blanda alla språk i ett enda JSON-LD-block – det leder ofta till valideringsfel. För bilder kan du hålla `image`-attributet språkoberoende, men se till att bild-URL:erna är korrekta.

Dessutom kan du anpassa `offers` med `availability` beroende på marknad (t.ex. `InStock` för Tyskland, `PreOrder` för Frankrike). Använd `gtin` eller `mpn` globalt, men behåll lokala varianter för `sku`. Testa slutligen om de strukturerade datumen i Search Console indexeras korrekt för varje språkversion.

FAQ-schema: Optimera frågor och svar-sidor för flera språk

FAQ-sidor på flera språk drar nytta av en tydlig, språkspecifik märkning med schemat FAQPage. Varje språkversion av FAQ-sidan får ett eget JSON-LD-objekt. Ställ in `inLanguage` på motsvarande språkkod (t.ex. `fr-FR` för franska). Frågorna och svaren måste formuleras på målspråket i objektet – maskinöversättning räcker ofta inte; låt en modersmålstalare granska dem eftersom nyanser är avgörande.

Ett typiskt misstag: Samma `@id` för alla språkvarianter. Använd istället den språkspecifika URL:en som `@id`, t.ex. `https://example.com/de/faq/` och `https://example.com/en/faq/`. Inom FAQPage-schemat listar du frågorna som `mainEntity` med `@type: Question` och tillhörande svar som `acceptedAnswer`. Varje fråga kan dessutom få `inLanguage`, men det är redundant om hela sidan är märkt. Begränsa antalet frågor per sida till högst 10–15, eftersom sökmotorer bara beaktar ett begränsat antal poster.

Rekommendation: Använd ett CMS som per FAQ-post erbjuder ett flerspråksfält. I JSON-LD-utmatningen frågar du dynamiskt efter aktuellt språk. Validera varje språkversion separat med Rich Results Test och var uppmärksam på varningar om saknade `name`-egenskaper hos frågorna. Lägg till en `url` för varje fråga som pekar på den specifika ankarpunkten – så kan användare hoppa direkt till rätt svar.

Observera: FAQPage är endast lämplig för sidor med explicita frågor och svar. Använd det inte för allmänna supportsidor. Testa synligheten i Google Sök efter driftsättning – FAQ-rikliga utdrag visas ofta vid sökfrågor med frågepartiklar. För flerspråkig SEO är det värt att anpassa svaren till landsspecifika formuleringar (t.ex. „Hur kan jag?” vs. „Comment puis-je?”).

Finesserna med inLanguage: Språkkod och språkområde

Attributet `inLanguage` i Schema.org anger språket för ett innehåll, där värdet idealiskt består av en språkkod (ISO 639-1) och en valfri regionskod (ISO 3166-1 Alpha-2) – t.ex. `en-US` för amerikansk engelska. Regionen är viktig när innehållet skiljer sig: „colour“ vs. „color“ eller olika måttenheter. Utan region tolkas koden som allmänt språk. Använd därför `de-DE`, `de-AT`, `de-CH` för landsspecifika sidor, även om texten är nästan identisk.

Ett praktiskt exempel: En produkt erbjuds på en tysk och en österrikisk sida. Språket är tyska, men priserna och leveransvillkoren skiljer sig. Använd `inLanguage: "de-DE"` för den tyska och `"de-AT"` för den österrikiska sidan. På så sätt kan Google bättre förstå den regionala relevansen. Samma gäller för `en-GB` och `en-US`. Om du inte behöver någon regional åtskillnad räcker `"de"` eller `"en"`. Observera dock att språkkoden alltid skrivs i gemener och regionen i versaler (t.ex. `fr-CA`).

Ett vanligt misstag är att använda `inLanguage` på ett överordnat objekt medan underobjekt har ett annat språk. Exempel: En webbplats på tyska, men en enskild artikel på engelska. Ange då `inLanguage: "de"` på webbplatsen och `inLanguage: "en"` på artikeln. Validera detta med en schema-validerare eftersom vissa verktyg rapporterar konflikter. För flerspråkiga sidor med hreflang-taggar bör `inLanguage` motsvara respektive hreflang-värde – det hjälper Google att leverera rätt version.

Praktisk implementering: Definiera ett unikt `@id` per språkversion och ange `inLanguage` konsekvent. Använd en central konfigurationsfil som innehåller korrekta koder för varje språk. Testa med verktyget från schema.org om `inLanguage`-taggen accepteras. Ett tips: Glöm inte `inLanguage` även på AMP-sidor eller strukturerad data via mikrodatam. Vid JSON-LD placerar du det på den översta nivån (t.ex. `WebSite` eller `WebPage`). För dynamiskt innehåll som bloggartiklar kan `inLanguage` variera per inlägg – ange det då per objekt.

Korrekt märkning av flerspråkighet på en enskild URL

När en URL innehåller innehåll på flera språk – till exempel via språkväljare, flikar eller accordions – måste du i den strukturerade datan tydligt markera vilken text som hör till vilket språk. Annars kan en sökmotorrobot felaktigt anta att allt innehåll är på ett språk, vilket leder till fel vid indexering och visning.

Grundmetoden är att använda attributet `inLanguage` på motsvarande element. För ett FAQ-schema med frågor och svar på tyska och engelska på samma sida markerar du varje fråga och svar separat: ```json { "@type": "Question", "name": "Wie melde ich mich an?", "inLanguage": "de", "acceptedAnswer": { "@type": "Answer", "text": "Klicken Sie auf ...", "inLanguage": "de" } } ``` Samma sak gäller för produkt-scheman: Beskriv `name` och `description` per språk i ett eget `Product`-objekt med separat `inLanguage`, eller använd `@language` och `@value` i en `multilingualDescription`-egenskap (om ditt vokabulär stöder det).

För organisationer med flerspråkiga namn använder du en array av `name`-objekt: ```json { "name": [ {"@language": "de", "@value": "Baduno GmbH"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Undvik att deklarera hela sidan som flerspråkig. Gör i stället språktilldelningen så granulär som möjligt. Ett vanligt misstag är att enbart ange `inLanguage` på den översta nivån i ett schema utan att markera underordnade element. Kontrollera därför i din valideringsprocess att alla texter är korrekt språkmärkta.

Som konkret rekommendation: Skapa ett separat schema-objekt för varje språkvariant på en URL, som endast innehåller texterna på det språket, och ange `inLanguage` med rätt språkkod. Om sidan som standard visar ett huvudspråk men laddar andra via JavaScript, placera den strukturerade datan för alla språk statiskt i HTML. Verktyg som Google Rich Results Test visar om märkningen tolkas korrekt. Testa varje språkversion separat genom att tvinga crawler till önskat språk med URL-parameter eller cookie.

Avgränsning mellan hreflang och inLanguage: När ska vilken metod användas?

`hreflang` och `inLanguage` fyller olika syften inom internationell SEO och bör inte förväxlas. `hreflang` är ett HTML-element eller HTTP-huvud som signalerar till sökmotorer att det finns alternativa språk- eller regionsversioner av samma sida. Det används för att leverera rätt sida till användare i olika länder eller med specifika språkinställningar. `inLanguage` å andra sidan är ett attribut i strukturerad data (Schema.org) som anger språket för ett visst textelement.

När använder ni vad? Använd `hreflang` om ni har separata URL:er för olika språkversioner (t.ex. `example.com/de/` och `example.com/en/`). Det förhindrar problem med dubblettinnehåll och säkerställer att rätt sida visas i sökutdraget. `inLanguage` krävs när ni på en enda URL markerar flerspråkigt innehåll eller när ett strukturerat dataelement som en produktbeskrivning finns på flera språk. `inLanguage` kompletterar alltså `hreflang` på enskilda textblocksnivå.

Ett vanligt missförstånd: `inLanguage` ersätter inte `hreflang`. Även om ni markerar varje rad i en artikel med `inLanguage` vet sökmotorerna utan `hreflang` inte om det finns alternativa versioner av hela sidan. Omvänt räcker inte `hreflang` för att finmaskigt beskriva flerspråkigt innehåll inom en URL. I praktiken innebär detta: Har ni separata sidor för varje språk krävs primärt `hreflang`, medan `inLanguage` endast anger det specifika språket för innehållet i de strukturerade data på dessa sidor. Finns flera språk på en URL måste ni använda `inLanguage` för varje språkspecifikt element.

Konkret rekommendation: Planera er URL-strategi före implementeringen. Bestäm om ni ska ha en egen URL per språk (ccTLD, subdomän, underkatalog) eller en gemensam URL med dynamiskt språkbyte. För det senare är korrekt `inLanguage`-markering oumbärlig. Kontrollera alltid att era `hreflang`-taggar pekar på alla relevanta språkversioner och inte motsäger `inLanguage`-angivelserna i de strukturerade data. En avstämning av dessa två signaler kan hjälpa sökmotorer att korrekt klassificera ert innehåll.

Valideringsarbetsflöde: Verktyg och automatiska kontroller

Manuell kontroll av strukturerad data på varje språkversion är felbenägen och tidskrävande. Ett automatiserat valideringsarbetsflöde säkerställer att era Schema.org-markeringar är korrekta och förblir så – även efter innehållsuppdateringar eller när nya språk läggs till. De viktigaste verktygen är Google Rich Results Test (för Googlestödda typer som FAQ, Product) och Schema.org Validator (för ren syntaxkontroll). Kompletterande hjälp ges av crawlerverktyg som Screaming Frog SEO Spider för att extrahera och granska strukturerad data på hela webbplatsen.

Integrera kontrollen i er CI/CD-process: Efter varje driftsättning eller språkuppdatering körs en automatisk testomgång. Använd API:t för Google Rich Results Test eller ett skript som tolkar era sidor och jämför JSON-LD-blocken mot ett eget definierat schema. Var särskilt uppmärksam på följande felkällor: - Saknat `inLanguage` på ställen där flera språk förekommer. - Motsägelsefulla språkkoder (t.ex. „de“ istället för „de-DE“ vid regionsspecifika varianter). - Ofullständiga obligatoriska fält (t.ex. `name` för Product på varje språk). - Föråldrade `hreflang`-taggar som inte längre matchar era aktuella URL:er.

Konkret handlingsrekommendation: Skapa en checklista för varje schematyp (Organization, Product, FAQ) med nödvändiga attribut per språk. Använd ett testverktyg som `json-schema` för automatisk validering. Genomför dessutom regelbundet (t.ex. månatligen) en fullständig crawl med Schema.org Validator och generera rapporter över felaktiga sidor. Dokumentera felkategorierna och utse ansvariga för korrigeringar. Observera att de strukturerade data måste kontrolleras på livesidorna – test i staging räcker inte eftersom innehållet kan skilja sig åt. Endast så säkerställer ni att sökmotorrelevanta fel åtgärdas i tid.

Vanliga fel vid internationella strukturerade data

Att märka upp flerspråkiga webbplatser med Schema.org innebär typiska fallgropar. Ett vanligt misstag är att språkatributet `inLanguage` saknas eller anges felaktigt. Om du till exempel erbjuder en produkt på tyska men inte anger `inLanguage: "de-DE"` i markupen kan sökmotorer tolka datan som språkneutral. Ett annat grundläggande fel är att blanda språk inom ett enda Schema-block. Undvik att i ett `Product`-objekt sätta `name`-egenskapen på engelska och `description` på tyska. Skapa istället separata block för varje språkversion med korrekt `inLanguage`.

Ytterligare ett vanligt misstag är att använda olämpliga Schema-typer. För ett flerspråkigt företag väljer många felaktigt `LocalBusiness`, trots att `Organization` är rätt val om det inte finns en fysisk adress på varje språk. Vid produkter glöms ofta `offers`-egenskapen att märkas upp språkspecifikt. Dessutom försummas uppdatering av strukturerad data efter översättningar: en nyligen översatt produkttext måste också justeras i markupen – annars visar sökresultat föråldrad eller felaktig information.

Att försumma validering är ytterligare ett kardinalfel. Efter varje ändring bör du kontrollera markuperna med lämpliga verktyg. Felaktiga eller saknade `@id`-referenser för entiteter som är språköverskridande identiska (t.ex. en organisation) leder till dubbletter eller ofullständiga data. Dessutom ignoreras ofta samspelet med `hreflang`: där inga alternativa URL:er finns måste du arbeta med `inLanguage` på samma sida.

Rekommendationer: Kontrollera varje markup för korrekt språktilldelning. Använd separata Schema-block för varje språkversion med unika `@id`. Undvik blandningar – även i `aggregateRating` eller `review` måste språket stämma. Genomför en ny validering efter varje översättning och avstäm datan med synligt innehåll. Endast på så sätt säkerställer du att sökmotorer tolkar dina flerspråkiga erbjudanden korrekt.

Test med Google Rich Results, Bing Webmaster Tools och Yandex

Kontroll av flerspråkiga Schema.org-markup bör inte begränsas till ett enda verktyg. Varje sökmotor har egna tolkningar och valideringskriterier. Google Rich Results Test är den första anhalten: ange en URL med ditt markup eller klistra in koden direkt. Var uppmärksam på alla fel och varningar – särskilt om `inLanguage`-angivelserna känns igen korrekt. Ett vanligt problem är att Google accepterar `de-DE` men vid avsaknad av regiondel (`de`) ändå utfärdar en varning. Testa varje språkversion separat.

Bing Webmaster Tools erbjuder en URL-kontroll med en strukturerad datavy. Här kan du se om Bing tolkar markuperna som förväntat. Bing är ofta strängare vid validering av `inLanguage` och förväntar sig eventuellt obligatoriskt den tvåställiga språkkoden utan region (t.ex. `de` istället för `de-DE`). Genomför ett live-test och korrigera avvikelser. Bing visar dessutom möjliga dubbletter om `@id`-värden används flera gånger.

Yandex Webmaster har en egen validator som främst är relevant för ryskspråkiga sidor. Även här kan du testa strukturerad data. Yandex stöder de flesta Schema.org-typer men felhanteringen skiljer sig. Särskilt vid `Product`-markup anmärks ofta `availability`-egenskapen. Testa därför även här varje språkversion. Observera att Yandex kan vikta regionala språkkoder som `de-DE` annorlunda.

Rekommendationer: Testa varje språkversion i alla tre verktygen efter implementering och efter varje ändring. Anteckna avvikelser och justera markuperna så att de accepteras av alla tre sökmotorer. Använd idealiskt den tvåställiga språkkoden (`de`, `en`) i `inLanguage` eftersom den förstås av de flesta system. Automatisera testerna med CI-verktyg för att hålla översikten på flerspråkiga webbplatser med många sidor.

Checklista för implementering av flerspråkiga Schema.org-markup

Ett strukturerat tillvägagångssätt förhindrar typiska misstag vid internationalisering. Innan implementeringen bör du fastställa språkstrategin: Använd separata URL:er per språk (t.ex. `/de/produkt` och `/en/product`) eller en enda URL med språkomkoppling? För separata URL:er använder du `hreflang` och per URL en egen markup. Vid en enda URL använder du flera `inLanguage`-block med olika språkkoder. Planera även vilka schematyper som behövs: Företag (Organization), produkter (Product), FAQ (FAQPage) etc.

Vid implementeringen beakta följande punkter: Varje schemaobjekt får ett unikt `@id` som identifierar entiteten oberoende av språk. För varje språkversion lägger du upp ett separat objekt som via `inLanguage` anger språket. Använd konsekventa språkkoder – företrädesvis den tvåställiga ISO-koden (t.ex. `de`, `en`) kompletterad med region vid behov. Länka korrekt inom markupen: Vid `Organization` använder du `url` och `logo` med språkspecifika sökvägar. Kontrollera att texter som `name` och `description` överensstämmer med synligt innehåll.

Efter implementeringen följer valideringen: Testa varje språkversion med Google Rich Results Test, Bing Webmaster Tools och Yandex. Korrigera fel och varningar. Var särskilt uppmärksam på saknade `inLanguage` eller felaktiga språkkoder. Använd även Schema.org-valideringsverktyget från Google för att kontrollera syntaxen. Dokumentera alla ändringar och utför efter varje översättning nya tester.

Slutligen hör övervakning till processen: Övervaka prestandan i Search Console, särskilt rapporterna om strukturerad data. Reagera på nya fel eller varningar. Uppdatera markupen i god tid när du ändrar eller översätter innehåll. Genomför regelbundna revisioner för att säkerställa konsekvens över alla språkversioner. En väl underhållen Schema.org-implementering förbättrar synligheten i sökresultaten – utan garantier, men med praktisk nytta.

Juridiska anmärkningar: Eget ansvar vid automatisk översättning

Den automatiska översättningen av strukturerad data medför juridiska risker som du som ansvarig för en flerspråkig webbplats måste granska på eget ansvar. Särskilt vid Schema.org-markup som innehåller juridiskt relevant innehåll som produktsäkerhetsanvisningar, allmänna villkor eller varumärkesbeteckningar kan en felaktig översättning leda till ansvarsfall. Till exempel kan ett felaktigt översatt produktnamn eller en vilseledande produktbeskrivning strida mot konkurrenslagstiftningen. Vi rekommenderar därför att alla automatiskt skapade översättningar korrekturläses av en språkkunnig fackperson. Detta gäller särskilt fält som "description" i Product-schemat eller "answer" i FAQ-schemat, där nyanser är avgörande.

Förutom innehållets korrekthet spelar även dataskyddsaspekter en roll: Om ditt schema innehåller personuppgifter (t.ex. kundrecensioner i Review-schemat), måste du säkerställa att översättningen sker i enlighet med GDPR. Automatiska översättningstjänster bör endast användas om tjänsten erbjuder tillräckliga dataskyddsgarantier. Det finns inget generellt förbud, men ansvaret för databehandlingen ligger hos dig som webbplatsansvarig. Rådgör med en juridisk rådgivare om de specifika kraven i dina målländer.

En annan juridisk fallgrop: Användningen av "inLanguage" med otillåtna språkkoder. Använd alltid officiella BCP-47-koder (t.ex. "de-DE" istället för "deutsch"). Felaktiga koder kan leda till att din markup ignoreras av sökmotorer – vilket visserligen inte är ett juridiskt problem, men som påverkar sökbarheten. Genomför därför före lansering en validering med verktyg som Google Rich Results Test, och kontrollera dessutom att översättningarna korrekt täcker alla juridiskt relevanta fält.

Rekommendation: Definiera ett arbetsflöde där varje automatiskt översatt schemaannotation granskas av en språkkunnig redaktör eller jurist. Dokumentera processen för att i tvistefall kunna påvisa att du uppfyllt din omsorgsplikt. Avstå från automatisk översättning av textblock med juridisk karaktär (t.ex. garantivillkor, ansvarsfriskrivningar); översätt dem manuellt eller via en facktjänst.

Utblick: AI-stödd lokalisering och framtida schemautvecklingar

Lokaliseringen av Schema.org-markup underlättas alltmer av AI-drivna verktyg. Nuvarande system kan med hjälp av neurala nätverk skapa översättningar som är kontextuellt mer precisa än äldre statistiska metoder. För flerspråkiga webbplatser innebär detta att du snabbare kan överföra stora mängder produktdata eller FAQ-innehåll till flera språk. Kvalitetssäkring är dock fortfarande avgörande, eftersom AI-modeller inte alltid korrekt fångar branschspecifika termer eller regionala nyanser. En praktisk metod är att använda AI för råöversättning, följt av en manuell granskning. Verktyg som Baduno kombinerar AI-översättning med granskning av modersmålstalare och erbjuder därmed en skalbar lösning.

Parallellt med AI-utvecklingen utökar Schema.org kontinuerligt sitt ordförråd. Framtida typer kan vara mer inriktade på AI-genererat innehåll, till exempel ett ”AIContent”-schema för att märka maskinellt skapade texter. Även kopplingen till knowledge grafer blir viktigare: Flerspråkiga markups kan i framtiden genereras automatiskt från centrala kunskapsbaser. Redan nu finns egenskapen ”translationOfWork” som tydliggör relationen mellan översatt innehåll. Vi rekommenderar att du tidigt inkluderar sådana nya egenskaper i din strategi för att vara redo för sökmotoruppdateringar.

En annan trend är dynamiska, språkspecifika markups som visas baserat på användarens kontext. Till exempel kan ett Product-schema innehålla lokal valuta och måttenhet beroende på användarens plats. Utmaningen ligger i korrekt användning av ”inLanguage” och att undvika konflikter med hreflang. Framtida Schema-versioner kan tydligare definiera hur regionala varianter inom ett schema kan representeras. För att förbereda dig bör du bygga dina markups modulärt: Använd separata block för varje språk inom samma JSON-LD eller separata script-taggar per språkversion – beroende på din tekniska infrastruktur.

Handlingsrekommendation: Testa AI-baserade översättningslösningar med en representativ uppsättning av dina schema-data och mät felfrekvensen. Håll dig uppdaterad om Schema.org-utgåvors release notes för att identifiera nya egenskaper. Pilota dynamisk visning av markups för olika målgrupper och validera resultaten med sökmotorernas Search Consoles. På så sätt säkerställer du att din flerspråkiga webbplats drar nytta av framtida utvecklingar utan att ta juridiska eller tekniska risker.

Praktikfall: Stegvis implementering av en flerspråkig produktsida

För att omsätta de teoretiska grunderna i praktiken betraktar vi en fiktiv e-handelswebbplats som erbjuder en smartphone på tyska, engelska och franska. Antag att produktsidan är tillgänglig under en enda URL med språkomkopplare (t.ex. example.com/smartphone). Målet är att märka upp Schema.org Product-markup med språkspecifik information.\n\n1. **Fastställ språkkoder**: För varje språkvariant används ett unikt inLanguage-värde. Exempel: Tyska: "de-DE", Engelska: "en-US", Franska: "fr-FR".\n\n2. **Märk upp namn och beskrivning språkspecifikt**: I JSON-LD-markupen används en @graph-array. Varje språkvariant tilldelas ett eget produktobjekt med tillhörande inLanguage. Exempel:\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. **Validera markup**: Med Googles Rich Results Test kontrolleras för varje språkversion om markuppen accepteras. Se till att inLanguage-angivelserna överensstämmer med sidans faktiska språk.\n\n4. **Integration via server-side eller JavaScript**: I praktiken genereras markuppen bäst server-side så att sidans källkod innehåller den fullständiga JSON-LD. Vid dynamiska språkväxlingar via JavaScript kan markup laddas in i efterhand, men detta kanske inte upptäcks av sökmotorer.\n\n5. **Test av synlighet**: Efter implementeringen kontrolleras om strukturerad data rapporteras som giltig i Google Search Console och om Rich Results visas i sökresultaten.\n\nDetta steg-för-steg-exempel visar hur du konkret kan gå tillväga. Anpassa strukturen efter din teknik och testa varje språkvariant separat.

Samarbete med översättnings- och lokaliseringstjänsteleverantörer

När du implementerar flerspråkiga strukturerade data arbetar du ofta med översättare eller lokaliseringsbyråer. Det är då viktigt att även Schema.org-markup blir en del av lokaliseringsprocessen. Diskutera med din tjänsteleverantör att inte bara det synliga innehållet utan även värdena i JSON-LD (t.ex. 'name', 'description') måste översättas. Ett vanligt misstag: Byrån får bara texten på sidan, inte de strukturerade datumen. Tillhandahåll därför ett separat dokument med alla schemafält – helst i JSON-format – och bestäm vilka fält som ska översättas språkspecifikt (t.ex. 'offers' eller 'review' kan vara globala medan 'name' varierar per språk).

Praktiskt tips: Använd ordlistor och översättningsminnen även för dina strukturerade data. På så sätt säkerställer du att produktnamn och facktermer är enhetliga i alla markups. Be också tjänsteleverantören att ställa in språkkoderna (inLanguage) enligt dina anvisningar – till exempel 'de-DE' istället för bara 'de'. Efter leverans bör du stickprovsmässigt kontrollera att alla översatta fältvärden är korrekt inlagda i markups. Ett automatiserat test med Googles Rich Results Test kan ge första indikationer.

En annan aspekt: Samarbetet kring kvalitetssäkring. Kom överens om att de översatta schemadata läses av en modersmålstalande redaktör innan publicering. Felöversatta produktattribut eller instruktioner i FAQ-frågor kan skada den internationella rankingen. Dokumentera hela processen – från extrahering av källtexter till implementering – och uppdatera din checklista för varje språkversion. På så sätt undviker du att de strukturerade datumen föråldras vid senare innehållsuppdateringar.

Juridisk anmärkning: Ansvaret för korrekta översättningar ligger hos dig. Begär skriftlig bekräftelse på att dina riktlinjer följs och reglera ansvarsfrågor vid felöversättningar i avtal. Oberoende juridisk rådgivning rekommenderas.

Budgetplanering och kostnadsuppskattning för flerspråkig schema-implementering

Införandet av strukturerade data på flera språk medför engångs- och löpande kostnader. Förutom själva översättningen av markup-innehållet tillkommer kostnader för teknisk integration, testning och underhåll. För en realistisk budgetplanering måste du ta hänsyn till följande poster:

1. Översättning av schemafälten: Per språkversion uppstår kostnader för översättning av alla relevanta JSON-LD-element (titlar, beskrivningar, frågor, svar etc.). Eftersom det rör sig om korta, ofta tekniska texter kan översättningsbyråer erbjuda särskilda priser. Kalkylera med ett påslag på 10–20 % för att sätta sig in i schema-definitionerna.

2. Teknisk anpassning: Markup måste per språk antingen ske i separata JSON-LD-block eller via flerspråkiga fält. Beroende på system behöver din utvecklare ytterligare tid för att implementera logik för språkväxling och fallbacks. Erfarenhetsmässigt ligger den initiala insatsen för en webbplats med fem språkversioner mellan 15 och 25 persondagar i utveckling.

3. Testning och kvalitetssäkring: Varje språkversion måste valideras separat – med Googles Rich Results Test, Schema.org-validatorer och manuella stickprov. Planera in cirka 1–2 dagar per språk för den första installationen och en halvtimme per ändring.

4. Löpande underhåll: Vid uppdateringar av produktsortimentet eller FAQ-innehåll måste även markups justeras i tid. Bestäm om översättningsteamet alltid ska leverera schemadata tillsammans med nytt innehåll. Ett innehållshanteringssystem som automatiskt genererar strukturerade data minskar långtidsinsatsen men kräver en motsvarande installation.

5. Verktyg och licenser: Om du använder särskilda verktyg för övervakning av strukturerade data (t.ex. Webmaster Tools-API:er eller egna instrumentpaneler) kan det tillkomma prenumerationsavgifter.

Som tumregel bör du för hela processen (införande i tre huvudspråk) räkna med en budget på 5 000 till 15 000 euro, beroende på sidans omfattning och antalet produkter. För mindre projekt med få FAQ-sidor kan beloppet vara lägre.

Juridisk anmärkning: Angivna siffror är endast vägledande. Begär individuella offerter från utvecklare och översättare och observera att de faktiska kostnaderna kan variera beroende på komplexitet. För bindande uttalanden kontakta din juridiska och skattemässiga rådgivning.