Gestructureerde data internationaal: Schema.org over taalgrenzen heen

Inleiding tot gestructureerde gegevens voor meertalige websites

Gestructureerde gegevens volgens Schema.org helpen zoekmachines om de inhoud van uw website te begrijpen – en dat over taalgrenzen heen. Als u meerdere taalversies beheert, wordt de juiste markering des te belangrijker. Zoekmachines zoals Google gebruiken gestructureerde gegevens om Rich Results zoals snippets, productprijzen of FAQ-elementen weer te geven. Bij meertalige pagina's moeten deze markeringen taalspecifiek zijn, anders kunnen er verkeerde informatie worden getoond – bijvoorbeeld een telefoonnummer van de Duitse pagina in de Franse versie.

Een typische fout: men neemt het schema van de ene taal eenvoudig over in andere versies, zonder de taalinstellingen aan te passen. Daarbij is het niet voldoende om alleen de inhoud te vertalen; ook de structuur moet de doeltaal weerspiegelen. Het inLanguage-veld van het schema-object moet bijvoorbeeld de taal van de betreffende pagina aangeven. Een Duitse productpagina krijgt `inLanguage: 'de'`, de Engelse `inLanguage: 'en'`. Bovendien kunt u met `translationOfWork` verwijzen naar de originele versie.

Praktisch begint u met de belangrijkste paginatypen: Organisatie, Product, FAQ. Deze worden het meest gebruikt voor Rich Results. Controleer vooraf welke pagina's in welke taal bijzonder relevant zijn. Voor een internationale bedrijfspagina is het Organization-schema geschikt, voor een webshop het Product-schema. Zorg ervoor dat elke taalversie een eigen JSON-LD-script of aparte vermeldingen in het script krijgt. Gebruik tools zoals de Google Rich Results Test om elke taalversie afzonderlijk te valideren. Let daarbij op dat de test slechts een momentopname geeft – een regelmatige controle is aanbevolen.

Juridisch dient te worden opgemerkt dat gestructureerde gegevens geen persoonsgegevens mogen bevatten die in strijd zijn met de AVG. Bij het vermelden van contactgegevens in verschillende landen moet u ervoor zorgen dat de gegevens correct en actueel zijn. Laat u bij twijfel bijstaan door een juridisch adviseur. Door een zuivere implementatie van meertalige gestructureerde gegevens verbetert u de kansen om in de verschillende taalregio's met relevante Rich Results te worden gevonden.

Grondbeginselen van Schema.org en taalmarkering

Schema.org biedt een gemeenschappelijke vocabulairestructuur die wordt ondersteund door zoekmachines. Voor meertalige websites is de juiste taalmarkering essentieel. Elk schema-object kan een `inLanguage`-eigenschap hebben die de taal van de inhoud aangeeft (bijv. `'de'`, `'en'`, `'fr'`). Deze aanduiding moet overeenkomen met de werkelijke taal van de pagina. In JSON-LD stelt u `@language` in op het hele document of op afzonderlijke objecten wanneer er meerdere talen voorkomen.

Een voorbeeld: voor een product in de Duitse taal gebruikt u: ``` "@context": "https://schema.org", "@type": "Product", "name": "Lederjacke", "inLanguage": "de" ``` Wanneer u hetzelfde product op een Engelse pagina markeert, gebruikt u `"inLanguage": "en"` en de naam in het Engels. Vermijd het mengen van meerdere taalversies in één schema-object – dat leidt tot inconsistenties. Gebruik in plaats daarvan aparte markup-blokken per taal of werk met `@language`-arrays binnen een object als de entiteit meertalig is.

Voor websitespecifieke gegevens zoals `WebSite` of `WebPage` moet u ook de taal aangeven. Bij een taalschakeling op de pagina kunt u met `potentialAction` of `translationOfWork` naar de andere taalversies verwijzen. In de praktijk is het raadzaam om voor elke taal een apart JSON-LD-blok in de bijbehorende pagina-head te plaatsen. Zo blijft de toewijzing eenduidig en wordt deze correct geïnterpreteerd door validatietools.

Zorg ervoor dat de taalcodes de ISO-639-1-standaard gebruiken (bijv. 'de' voor Duits, 'en' voor Engels). Voor regionale varianten kunt u landcodes toevoegen, dus 'de-CH' voor Zwitsers Duits. Hierbij moet u controleren of de zoekmachine deze fijne differentiatie ondersteunt – doorgaans volstaat de basistaalcode. Valideer elke taalversie afzonderlijk met de Google Structured Data Testing Tool of de Rich Results Test. Noteer mogelijke waarschuwingen over ontbrekende taalangaven en los deze gericht op.

Organization-schema: bedrijfsgegevens in meerdere talen

Het Organization-schema is ideaal voor bedrijven met meertalige websites, omdat het centrale informatie zoals naam, adres en contactgegevens biedt. Voor elke taalversie moet u een apart Organization-object maken dat in de betreffende taal is gemarkeerd. De `name` moet in de doeltaal worden vermeld – dus 'Muster GmbH' in het Duits en 'Sample Inc.' in het Engels. Als het bedrijf een uniforme naam heeft, volstaat de vertaling van de beschrijving (`description`).

Bij adressen gebruikt u het `PostalAddress`-schema met `addressCountry` en `addressLocality`. Voor internationale locaties kunt u meerdere `location`-vermeldingen voorzien. Zorg ervoor dat telefoonnummers (`telephone`) zijn voorzien van de juiste landcode. Voorbeeld: voor de Duitse pagina `+49 30 1234567`, voor de Zwitserse pagina `+41 44 1234567`. Hetzelfde geldt voor e-mailadressen en openingstijden. Gebruik `areaServed` om aan te geven in welke landen het bedrijf actief is.

Een vaak over het hoofd gezien detail is de `sameAs`-eigenschap voor sociale media-profielen. Voeg taalspecifieke profielen toe indien aanwezig – bijvoorbeeld de Duitse Facebook-pagina en de Engelse Twitter-aanwezigheid. Ook de `url` moet verwijzen naar de taalspecifieke startpagina. Bij meertalige websites kunt u met `translationOfWork` een verband leggen tussen de taalversies, op voorwaarde dat de pagina's dezelfde inhoud in een andere taal weergeven.

Praktische aanbeveling: implementeer het Organization-schema op de startpagina van elke taalversie. Plaats hiervoor een JSON-LD-script in de `<head>`. Vermijd duplicaten door voor elke taal een apart blok met de juiste `inLanguage` te maken. Valideer de markering met de Google Rich Results Test en controleer of de contactgegevens correct worden weergegeven. Juridisch moet u er rekening mee houden dat de verstrekte informatie volledig en privacy-conform is. Vooral bij meerdere locaties: de verplichting tot een impressum kan per land verschillen. Raadpleeg bij twijfel juridisch advies. Door deze details zorgt u ervoor dat uw bedrijf in alle taalregio's uniform en correct wordt vertegenwoordigd.

Product-schema: productbeschrijvingen taalspecifiek markeren

Voor meertalige websites is het markeren van producten met Schema.org Product in de betreffende taal essentieel. Elke taalversie van een product moet een eigen Schema-markering krijgen met de lokale naam, beschrijving en attributen zoals prijs, valuta of beschikbaarheid. Gebruik daarbij het attribuut `inLanguage` per taal – bijv. `"inLanguage": "de-DE"` voor Duits (Duitsland). Zorg ervoor dat de productnaam en beschrijving in het JSON-LD-object daadwerkelijk in het Duits staan, niet alleen de taaltag.

Een veelgemaakte fout is het markeren van alle taalvarianten met dezelfde `@id` (bijv. een globale product-ID). In plaats daarvan moet u voor elke taal een eigen `@id` toewijzen, zoals `https://example.com/de/produkt/123` en `https://example.com/fr/produit/123`. Zo kan Google de juiste versie tonen. Gebruik bij prijzen `priceCurrency` met ISO-4217-code (bijv. EUR, USD) en geef de prijs taalspecifiek op – ook als de prijs hetzelfde blijft, hoort deze bij de lokale pagina.

Praktische aanbeveling: Maak voor elk product een JSON-LD-sjabloon dat dynamisch de taalparameters instelt. Controleer elke taalversie afzonderlijk met de Rich Results Test van Google. Zorg ervoor dat het `url`-attribuut naar de betreffende taal-URL verwijst. Vermijd het mengen van alle talen in één JSON-LD-blok – dit leidt vaak tot validatiefouten. Voor afbeeldingen kunt u het `image`-attribuut taal-onafhankelijk houden, maar zorg ervoor dat de afbeeldings-URL's correct zijn.

Daarnaast kunt u `offers` met `availability` aanpassen per markt (bijv. `InStock` voor Duitsland, `PreOrder` voor Frankrijk). Gebruik `gtin` of `mpn` wereldwijd, maar behoud bij `sku` lokale varianten. Test ten slotte of de gestructureerde gegevens in de Search Console voor elke taalversie correct worden geïndexeerd.

FAQ-Schema: Vraag-en-antwoordpagina's meertalig optimaliseren

FAQ-pagina's in meerdere talen profiteren van een duidelijke, taalspecifieke markering met het Schema FAQPage. Elke taalversie van de FAQ-pagina krijgt een eigen JSON-LD-object. Stel `inLanguage` in op de juiste taalcode (bijv. `fr-FR` voor Frans). De vragen en antwoorden moeten in het object in de doeltaal zijn geformuleerd – een machinale vertaling is vaak niet voldoende; laat ze controleren door een moedertaalspreker, omdat nuances cruciaal zijn.

Een typische fout: dezelfde `@id` voor alle taalvarianten. Gebruik in plaats daarvan de taalspecifieke URL als `@id`, bijv. `https://example.com/nl/faq/` en `https://example.com/en/faq/`. Binnen het FAQPage-schema vermeldt u de vragen als `mainEntity` met `@type: Question` en het bijbehorende antwoord als `acceptedAnswer`. Elke vraag kan aanvullend `inLanguage` krijgen, maar dat is overbodig als de hele pagina is gemarkeerd. Houd het aantal vragen per pagina op maximaal 10–15, omdat zoekmachines slechts een beperkt aantal items in aanmerking nemen.

Actieaanbeveling: Gebruik een contentmanagementsysteem dat per FAQ-item een meertalig veld biedt. In de JSON-LD-uitvoer vraagt u dynamisch de huidige taal op. Valideer elke taalversie afzonderlijk met de Rich Results Test en let op waarschuwingen over ontbrekende `name`-eigenschappen bij de vragen. Voeg bij elke vraag een `url` toe die naar de specifieke anchor verwijst – zo kunnen gebruikers direct naar het juiste antwoord springen.

Let op: FAQPage is alleen geschikt voor pagina's met expliciete vragen en antwoorden. Gebruik het niet voor algemene ondersteuningspagina's. Test na de implementatie de zichtbaarheid in de Google-zoekopdracht – FAQ-Rich-Snippets verschijnen vaak bij zoekopdrachten met vraagdeeltjes. Voor meertalige SEO is het de moeite waard om de antwoorden aan te passen aan landspecifieke formuleringen (bijv. „Hoe kan ik?“ vs. „Comment puis-je?“).

De finesses van inLanguage: Taalcode en regionale instellingen

Het attribuut `inLanguage` in Schema.org geeft de taal van een inhoud aan, waarbij de waarde idealiter bestaat uit een taalcode (ISO 639-1) en een optionele regioncode (ISO 3166-1 Alpha-2) – bijvoorbeeld `en-US` voor Amerikaans Engels. De regio is belangrijk wanneer inhoud verschilt: „colour” vs. „color” of verschillende meeteenheden. Zonder regio wordt de code als algemene taal geïnterpreteerd. Gebruik dus `de-DE`, `de-AT`, `de-CH` voor landspecifieke pagina's, ook al is de tekst bijna identiek.

Een praktijkvoorbeeld: Een product wordt aangeboden op een Duitse en een Oostenrijkse pagina. De taal is Duits, maar de prijzen en verzendvoorwaarden verschillen. Stel `inLanguage: "de-DE"` in voor de Duitse en `"de-AT"` voor de Oostenrijkse pagina. Zo kan Google de regionale relevantie beter begrijpen. Hetzelfde geldt voor `en-GB` en `en-US`. Als u geen regionaal onderscheid nodig hebt, volstaat `"de"` of `"en"`. Let er echter op dat de taalcode altijd in kleine letters en de regio in hoofdletters wordt geschreven (bijv. `fr-CA`).

Een veelgemaakte fout is het gebruik van `inLanguage` op een bovenliggend object, terwijl subobjecten een andere taal hebben. Voorbeeld: Een website in het Duits, maar een enkel artikel in het Engels. Stel dan `inLanguage: "de"` in op de website en `inLanguage: "en"` op het artikel. Valideer dit met een schema-validator, omdat sommige tools conflicten melden. Voor meertalige pagina's met hreflang-tags moet `inLanguage` overeenkomen met de respectieve hreflang-waarde – dat helpt Google de juiste versie te leveren.

Praktische implementatie: Definieer per taalversie een unieke `@id` en stel `inLanguage` consistent in. Gebruik een centrale configuratie met de juiste codes voor elke taal. Test met de tool van schema.org of de `inLanguage`-tag wordt geaccepteerd. Tip: vergeet `inLanguage` niet bij AMP-pagina's of gestructureerde data via microdata. Bij JSON-LD plaatst u het op het hoogste niveau (bijv. `WebSite` of `WebPage`). Voor dynamische inhoud zoals blogartikelen kan `inLanguage` per bericht variëren – stel het dan per item in.

Meertaligheid op één URL correct markeren

Wanneer een URL inhoud in meerdere talen bevat – bijvoorbeeld via taalwisselaars, tabs of accordeons – moet u in de gestructureerde data duidelijk aangeven welke tekst bij welke taal hoort. Anders kan een zoekmachine-crawler ten onrechte aannemen dat alle inhoud in één taal is, wat leidt tot fouten in indexering en weergave.

De basismethode is het gebruik van het `inLanguage`-attribuut op de betreffende elementen. Bij een FAQ-schema met vragen en antwoorden in het Duits en Engels op dezelfde pagina, markeert u elke vraag en antwoord afzonderlijk: ```json { "@type": "Question", "name": "Hoe meld ik me aan?", "inLanguage": "nl", "acceptedAnswer": { "@type": "Answer", "text": "Klik op ...", "inLanguage": "nl" } } ``` Hetzelfde geldt voor Product-schema's: beschrijf `name` en `description` per taal in een eigen `Product`-object met aparte `inLanguage`, of gebruik `@language` en `@value` in een `multilingualDescription`-eigenschap (indien uw vocabulaire dit ondersteunt).

Voor organisaties met meertalige namen gebruikt u een array van `name`-objecten: ```json { "name": [ {"@language": "nl", "@value": "Baduno BV"}, {"@language": "en", "@value": "Baduno Ltd."} ] } ``` Vermijd het om de hele pagina als meertalig te verklaren. Maak de taaltoewijzing zo granulair mogelijk. Een veelgemaakte fout is om `inLanguage` alleen op het hoogste niveau van een schema te zetten, zonder de onderliggende elementen te markeren. Controleer daarom in uw validatieworkflow of alle teksten correct taalkundig zijn gemarkeerd.

Als concrete handelingsaanbeveling: maak voor elke taalvariant op een URL een apart schema-object dat alleen de teksten van die taal bevat, en stel `inLanguage` in op de juiste taalcode. Als de pagina standaard een hoofdtaal toont, maar de andere via JavaScript laadt, plaats de gestructureerde data dan statisch in de HTML voor alle talen. Tools zoals de Google Rich Results Test laten zien of de markering correct wordt geïnterpreteerd. Test elke taalversie afzonderlijk door de crawler via een URL-parameter of cookie naar de gewenste taal te dwingen.

Onderscheid tussen hreflang en inLanguage: Wanneer welke methode?

`hreflang` en `inLanguage` dienen verschillende doelen in internationale SEO en mogen niet verward worden. `hreflang` is een HTML-element of HTTP-header die zoekmachines signaleert dat er alternatieve taal- of regio-versies van dezelfde pagina bestaan. Het zorgt voor de juiste weergave van de juiste pagina voor gebruikers in verschillende landen of met specifieke taalinstellingen. `inLanguage` daarentegen is een attribuut in gestructureerde data (Schema.org) dat de taal aangeeft waarin een bepaald tekstelement is geschreven.

Wanneer gebruik je wat? Gebruik `hreflang` wanneer je aparte URL's hebt voor verschillende taalversies (bijv. `example.com/de/` en `example.com/en/`). Hiermee voorkom je duplicate content-problemen en zorg je ervoor dat de juiste pagina in het snippet verschijnt. `inLanguage` is nodig wanneer je op één URL meertalige inhoud markeert of wanneer een gestructureerd data-element zoals een productbeschrijving in meerdere talen beschikbaar is. `inLanguage` vult `hreflang` dus aan op het niveau van individuele tekstblokken.

Een veelvoorkomend misverstand: `inLanguage` vervangt `hreflang` niet. Zelfs als je elke regel van een artikel markeert met `inLanguage`, weten zoekmachines zonder `hreflang` niet of er alternatieve versies van de hele pagina bestaan. Omgekeerd is `hreflang` niet voldoende om meertalige inhoud binnen één URL fijnmazig te beschrijven. In de praktijk betekent dit: heb je aparte pagina's voor elke taal, dan is `hreflang` primair vereist, terwijl `inLanguage` alleen in de gestructureerde data op die pagina's de specifieke taal van de inhoud aangeeft. Bevinden meerdere talen zich op één URL, dan heb je dwingend `inLanguage` nodig voor elk taalspecifiek element.

Concrete aanbeveling: Plan je URL-strategie vóór de implementatie. Besluit of je per taal een eigen URL (ccTLD, subdomein, submap) of een gedeelde URL met dynamische taalwissel gebruikt. Voor dat laatste is een correcte `inLanguage`-markering onmisbaar. Controleer in elk geval of je `hreflang`-tags verwijzen naar alle relevante taalversies en niet in tegenspraak zijn met de `inLanguage`-aanduidingen in de gestructureerde data. Een afstemming van deze twee signalen kan zoekmachines helpen om je inhoud correct te classificeren.

Validatieworkflow: tools en geautomatiseerde controles

Het handmatig controleren van gestructureerde data op elke taalversie is foutgevoelig en tijdrovend. Een geautomatiseerde validatieworkflow zorgt ervoor dat je Schema.org-markeringen correct blijven – ook na content-updates of bij het toevoegen van nieuwe talen. De belangrijkste tools zijn de Google Rich Results Test (voor door Google ondersteunde typen zoals FAQ, Product) en de Schema.org Validator (voor pure syntaxcontrole). Aanvullend helpen crawlers zoals Screaming Frog SEO Spider om gestructureerde data op je hele website te extraheren en op fouten te controleren.

Bouw de controle in je CI/CD-proces: na elke deployment of taalupdate laat je een geautomatiseerde testrun uitvoeren. Gebruik hiervoor de API van de Google Rich Results Test of een script dat je pagina's parseert en de JSON-LD-blokken controleert tegen een zelf gedefinieerd schema. Let vooral op de volgende foutbronnen: - Ontbrekend `inLanguage` op plekken waar meerdere talen voorkomen. - Tegenstrijdige taal-codes (bijv. "de" in plaats van "de-DE" bij regiospecifieke varianten). - Onvolledige verplichte velden (bijv. `name` bij Product in elke taal). - Verouderde `hreflang`-tags die niet meer overeenkomen met je huidige URL's.

Concrete handelingsaanbeveling: Maak voor elk schema-type (Organization, Product, FAQ) een checklist met de vereiste attributen per taal. Gebruik een testtool zoals `json-schema` voor automatische validatie van je data. Voer daarnaast regelmatig (bijv. maandelijks) een volledige crawl uit met de Schema.org Validator en laat rapporten genereren over foutieve pagina's. Documenteer de foutcategorieën en wijs verantwoordelijken aan voor correcties. Houd er rekening mee dat de gestructureerde data op de live-pagina's gecontroleerd moeten worden – een test in staging volstaat niet, omdat daar mogelijk andere inhoud staat. Alleen zo zorg je ervoor dat zoekmachine-relevante fouten tijdig worden opgelost.

Veelvoorkomende fouten bij internationale gestructureerde gegevens

Het markeren van meertalige websites met Schema.org brengt typische valkuilen met zich mee. Een veelgemaakte fout is het ontbreken of onjuist opgeven van het taalattribuut `inLanguage`. Als u bijvoorbeeld een product in het Duits aanbiedt, maar in de markup geen `inLanguage: "de-DE"` plaatst, kunnen zoekmachines de gegevens als taalneutraal interpreteren. Een andere fundamentele fout is het vermengen van talen binnen één enkel Schema-blok. Vermijd dat u in een `Product`-object de `name`-eigenschap in het Engels en de `description` in het Duits plaatst. Maak in plaats daarvan voor elke taalversie een apart blok met de juiste `inLanguage`.

Een even veelvoorkomende fout is het gebruik van ongeschikte Schema-typen. Voor een meertalig bedrijf grijpen velen ten onrechte naar `LocalBusiness`, terwijl `Organization` de juiste keuze is als er geen fysiek adres in elke taal is. Ook bij producten wordt vaak vergeten de `offers`-eigenschap taalspecifiek te markeren. Daar komt bij dat gestructureerde data niet worden bijgewerkt na vertalingen: een nieuw vertaalde producttekst moet ook in de markup worden aangepast – anders tonen zoekresultaten verouderde of onjuiste informatie.

Het verwaarlozen van validatie is een andere kardinale fout. Na elke wijziging moet u de markups controleren met geschikte tools. Foutieve of ontbrekende `@id`-verwijzingen bij entiteiten die taaloverschrijdend gelijk zijn (bijv. een organisatie) leiden tot duplicaten of onvolledige gegevens. Daarnaast wordt vaak de samenwerking met `hreflang` genegeerd: waar geen alternatieve URL's bestaan, moet u met `inLanguage` op dezelfde pagina werken.

Aanbevelingen: Controleer elke markup op correcte taaltoewijzing. Gebruik voor elke taalversie aparte Schema-blokken met unieke `@id`s. Vermijd vermenging – ook in `aggregateRating` of `review` moet de taal kloppen. Voer na elke vertaling een nieuwe validatie uit en vergelijk de gegevens met de zichtbare inhoud. Alleen zo zorgt u ervoor dat zoekmachines uw meertalige aanbod correct begrijpen.

Test met Google Rich Results, Bing Webmaster Tools en Yandex

Het controleren van meertalige Schema.org-markups mag niet beperkt blijven tot één enkel hulpmiddel. Elke zoekmachine heeft eigen interpretaties en validatiecriteria. De Google Rich Results Test is het eerste aanspreekpunt: voer een URL in met uw markup of plak de code direct. Let op alle fouten en waarschuwingen – met name of de `inLanguage`-opgaven correct worden herkend. Een veelvoorkomend probleem is dat Google `de-DE` accepteert, maar bij een ontbrekend regio-onderdeel (`de`) toch een waarschuwing geeft. Test elke taalversie afzonderlijk.

Bing Webmaster Tools biedt een URL-controle met een gestructureerde gegevensweergave. Hier kunt u zien of Bing de markups naar verwachting interpreteert. Bing is vaak strenger bij het valideren van `inLanguage` en verwacht mogelijk verplicht de tweedelige taalcode zonder regio (bijv. `de` in plaats van `de-DE`). Voer een live-test uit en corrigeer afwijkingen. Bing geeft ook mogelijke duplicaten aan als `@id`-waarden meerdere keren worden gebruikt.

Yandex Webmaster heeft een eigen validator, die vooral relevant is voor Russischtalige pagina's. Ook hier kunt u gestructureerde gegevens testen. Yandex ondersteunt de meeste Schema.org-typen, maar de foutafhandeling verschilt. Vooral bij `Product`-markups wordt vaak de `availability`-eigenschap bekritiseerd. Test daarom ook hier elke taalversie. Houd er rekening mee dat Yandex regionale taalcodes zoals `de-DE` anders kan wegen.

Aanbevelingen: Test elke taalversie in alle drie de tools na implementatie en na elke wijziging. Noteer afwijkingen en pas de markups zo aan dat ze door alle drie zoekmachines worden geaccepteerd. Gebruik bij voorkeur de tweedelige taalcode (`de`, `en`) in `inLanguage`, omdat deze door de meeste systemen gelijkelijk wordt begrepen. Automatiseer de tests met CI-tools om bij meertalige websites met veel pagina's het overzicht te behouden.

Checklist voor de implementatie van meertalige Schema.org-markups

Een gestructureerde aanpak voorkomt typische fouten bij internationalisering. Bepaal vóór de implementatie de taalstrategie: gebruikt u aparte URL's per taal (bijv. `/de/produkt` en `/en/product`) of één URL met taalschakeling? Gebruik voor aparte URL's `hreflang` en een eigen markup per URL. Bij één URL plaatst u meerdere `inLanguage`-blokken met verschillende taalcodes. Plan ook welke schematypen nodig zijn: organisatie (Organization), producten (Product), FAQ (FAQPage) enz.

Let bij de uitvoering op de volgende punten: Elk schema-object krijgt een unieke `@id` die de entiteit taalonafhankelijk identificeert. Maak voor elke taalversie een apart object aan dat via `inLanguage` de taal aangeeft. Gebruik consistente taalcodes – bij voorkeur de tweeletterige ISO-code (bijv. `de`, `en`) aangevuld met regio indien nodig. Link correct binnen de markups: Gebruik bij `Organization` `url` en `logo` met taalspecifieke paden. Controleer of teksten zoals `name` en `description` overeenkomen met de zichtbare inhoud.

Na de implementatie volgt validatie: Test elke taalversie met de Google Rich Results Test, Bing Webmaster Tools en Yandex. Corrigeer fouten en waarschuwingen. Let vooral op ontbrekende `inLanguage` of verkeerde taalcodes. Gebruik daarnaast de Schema.org-validatietool van Google om de syntaxis te controleren. Documenteer alle wijzigingen en voer na elke vertaling opnieuw tests uit.

Tot slot hoort monitoring bij het proces: Monitor de prestaties in de Search Console, met name de rapporten over gestructureerde gegevens. Reageer op nieuwe fouten of waarschuwingen. Werk de markups tijdig bij wanneer u inhoud wijzigt of vertaalt. Voer regelmatige audits uit om de consistentie over alle taalversies te waarborgen. Een goed onderhouden Schema.org-implementatie verbetert de zichtbaarheid in de zoekresultaten – zonder garanties, maar met praktisch nut.

Juridische opmerkingen: Eigen verantwoordelijkheid bij automatische vertaling

De automatische vertaling van gestructureerde gegevens brengt juridische risico's met zich mee die u als beheerder van een meertalige website eigen verantwoordelijk moet controleren. Met name bij Schema.org-markups die juridisch relevante inhoud bevatten zoals productveiligheidsinformatie, algemene voorwaarden of merkaanduidingen, kan een onnauwkeurige vertaling leiden tot aansprakelijkheid. Een verkeerd vertaalde productnaam of misleidende productbeschrijving kan bijvoorbeeld in strijd zijn met het mededingingsrecht. Wij adviseren daarom om alle automatisch gegenereerde vertalingen te laten controleren door een moedertaalsprekende specialist. Dit geldt met name voor velden zoals 'description' in het Product-schema of 'answer' in het FAQ-schema, waar nuances cruciaal zijn.

Naast inhoudelijke juistheid spelen ook gegevensbeschermingsaspecten een rol. Als uw schema persoonsgegevens bevat (bijv. klantbeoordelingen in het Review-schema), moet u ervoor zorgen dat de vertaling AVG-conform is. Automatische vertaaldiensten mogen alleen worden gebruikt als de dienst voldoende gegevensbeschermingsgaranties biedt. Er is geen algemeen verbod, maar de verantwoordelijkheid voor de gegevensverwerking ligt bij u als websitebeheerder. Raadpleeg een juridisch adviseur over de specifieke vereisten in uw doellanden.

Een ander juridisch struikelblok is het gebruik van 'inLanguage' met onjuiste taalcodes. Gebruik altijd de officiële BCP-47-codes (bijv. 'de-DE' in plaats van 'deutsch'). Onjuiste codes kunnen ertoe leiden dat uw markups door zoekmachines worden genegeerd – wat geen juridisch probleem is, maar de vindbaarheid schaadt. Voer daarom voor livegang een validatie uit met tools zoals de Google Rich Results Test en controleer daarnaast of de vertalingen alle juridisch relevante velden correct dekken.

Aanbevolen werkwijze: Definieer een workflow waarbij elke automatisch vertaalde schema-markup wordt gecontroleerd door een moedertaalsprekende redacteur of jurist. Documenteer dit proces om bij een geschil te kunnen aantonen dat u aan uw zorgplicht heeft voldaan. Vermijd automatische vertaling van tekstblokken met juridisch karakter (bijv. garantievoorwaarden, vrijwaringsclausules); vertaal deze handmatig of via een gespecialiseerde dienst.

Vooruitblik: AI-gestuurde lokalisatie en toekomstige Schema-ontwikkelingen

De lokalisatie van Schema.org-markups wordt steeds meer vergemakkelijkt door AI-gestuurde tools. Huidige systemen kunnen op basis van neurale netwerken vertalingen maken die contextueel preciezer zijn dan oudere statistische methoden. Voor meertalige websites betekent dit: u kunt grote hoeveelheden productgegevens of FAQ-inhoud sneller in meerdere talen omzetten. De kwaliteitsborging blijft echter cruciaal, omdat AI-modellen branchespecifieke termen of regionale nuances niet altijd correct weergeven. Een praktische aanpak is het inzetten van AI voor de ruwe vertaling, gevolgd door een menselijke controle. Tools zoals Baduno combineren AI-vertaling met moedertaalcontrole en bieden zo een schaalbare oplossing.

Parallel aan de AI-ontwikkeling breidt Schema.org continu zijn vocabulaire uit. Toekomstige typen kunnen sterker inspelen op AI-gegenereerde inhoud, zoals een 'AIContent'-schema voor het markeren van machinegeschreven teksten. Ook de koppeling met knowledge graphs wordt belangrijker: meertalige markups kunnen in de toekomst automatisch worden gegenereerd uit centrale kennisbanken. Er is al de 'translationOfWork'-eigenschap die de relatie tussen vertaalde inhoud expliciet maakt. Wij adviseren om dergelijke nieuwe eigenschappen vroegtijdig in uw strategie op te nemen, zodat u voorbereid bent op zoekmachine-updates.

Een andere trend zijn dynamische, taalspecifieke markups die worden getoond op basis van de gebruikerscontext. Zo kan een Product-schema afhankelijk van de locatie van de gebruiker de lokale valuta en maateenheid bevatten. De uitdaging ligt in het correct gebruiken van 'inLanguage' en het vermijden van conflicten met hreflang. Toekomstige Schema-versies kunnen duidelijker definiëren hoe regionale varianten binnen een schema kunnen worden weergegeven. Om u hierop voor te bereiden, moet u uw markups modulair opbouwen: gebruik voor elke taal aparte blokken binnen dezelfde JSON-LD of gebruik aparte script-tags per taalversie – afhankelijk van uw technische infrastructuur.

Actieaanbeveling: Test AI-gebaseerde vertaaloplossingen met een representatieve set van uw schemagegevens en meet de foutmarge. Blijf op de hoogte van Schema.org-release notes om nieuwe eigenschappen te identificeren. Piloot de dynamische weergave van markups voor verschillende doelgroepen en valideer de resultaten met de Search Consoles van de belangrijkste zoekmachines. Zo zorgt u ervoor dat uw meertalige site profiteert van toekomstige ontwikkelingen, zonder juridische of technische risico's te lopen.

Praktijkvoorbeeld: Stapsgewijze implementatie van een meertalige productpagina

Om de theoretische grondslagen in de praktijk te brengen, bekijken we een fictieve e-commercewebsite die een smartphone aanbiedt in het Duits, Engels en Frans. Stel dat de productpagina beschikbaar is onder één URL met taalkiezer (bijv. example.com/smartphone). Doel is om Schema.org Product-markup met taalspecifieke gegevens te annoteren.

1. **Taalcodes vastleggen**: Voor elke taalvariant wordt een unieke inLanguage-waarde gebruikt. Voorbeeld: Duits: "de-DE", Engels: "en-US", Frans: "fr-FR".

2. **Naam en beschrijving taalspecifiek annoteren**: In de JSON-LD-markup wordt een @graph-array gebruikt. Elke taalvariant krijgt een eigen Product-object met bijbehorende inLanguage. Voorbeeld: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Product", "inLanguage": "de-DE", "name": "Smartphone Pro Max", "description": "Krachtige smartphone met 128 GB opslagruimte", "offers": { ... } }, { "@type": "Product", "inLanguage": "en-US", "name": "Smartphone Pro Max", "description": "Krachtige smartphone met 128 GB opslagruimte", "offers": { ... } }, { "@type": "Product", "inLanguage": "fr-FR", "name": "Smartphone Pro Max", "description": "Krachtige smartphone met 128 GB opslagruimte", "offers": { ... } } ] } ```

3. **Markup valideren**: Met de Google Rich Results Test wordt voor elke taalversie gecontroleerd of de markup wordt geaccepteerd. Hierbij moet worden gelet op overeenstemming van de inLanguage-waarden met de werkelijke taal van de pagina.

4. **Integratie via server-side of JavaScript**: In de praktijk wordt de markup het best server-side gegenereerd, zodat de paginabroncode de volledige JSON-LD bevat. Bij dynamische taalwisselingen via JavaScript kan de markup later worden geladen, maar dit wordt mogelijk niet door zoekmachines opgemerkt.

5. **Test van zichtbaarheid**: Na implementatie wordt gecontroleerd of de gestructureerde gegevens in Google Search Console als geldig worden gerapporteerd en of de Rich Results in de zoekresultaten verschijnen.

Dit stapsgewijze voorbeeld laat zien hoe u concreet te werk kunt gaan. Pas de structuur aan uw technologie aan en test elke taalvariant afzonderlijk.

Samenwerking met vertaal- en lokalisatiedienstverleners

Wanneer u meertalige gestructureerde gegevens implementeert, werkt u vaak samen met vertalers of lokalisatiebureaus. Het is daarbij belangrijk dat ook de Schema.org-markeringen deel uitmaken van het lokalisatieproces. Bespreek met uw dienstverlener dat niet alleen de zichtbare inhoud, maar ook de waarden in JSON-LD (bijv. 'name', 'description') vertaald moeten worden. Een veelgemaakte fout: het bureau krijgt alleen de paginatekst, niet de gestructureerde gegevens. Zorg daarom voor een apart document met alle schema-velden – idealiter in JSON-formaat – en bepaal welke velden taalspecifiek vertaald moeten worden (bijv. 'offers' of 'review' kunnen globaal blijven, terwijl 'name' per taal varieert).

Praktijktip: Gebruik glossaria en translation memories ook voor uw gestructureerde gegevens. Zo zorgt u ervoor dat productnamen en vaktermen consistent in alle markeringen verschijnen. Vraag de dienstverlener bovendien om de taalcodes (inLanguage) conform uw specificatie in te stellen – bijvoorbeeld 'nl-NL' in plaats van alleen 'nl'. Na levering controleert u steekproefsgewijs of alle vertaalde veldwaarden correct in de markeringen zijn opgenomen. Een geautomatiseerde test met de Rich Results Test van Google kan hier eerste aanwijzingen geven.

Een ander aspect: de samenwerking bij kwaliteitsborging. Spreek af dat de vertaalde schemagegevens voor publicatie door een moedertaalsprekende redacteur worden nagelezen. Want verkeerd vertaalde productattributen of instructies in FAQ-vragen kunnen schadelijk zijn voor de internationale ranking. Documenteer het hele proces – van extractie van de bronteksten tot implementatie – en werk uw checklist bij voor elke taalversie. Zo voorkomt u dat bij latere contentupdates de gestructureerde gegevens verouderen.

Juridische opmerking: De verantwoordelijkheid voor correcte vertalingen ligt bij u. Laat de naleving van uw specificaties schriftelijk bevestigen en regel aansprakelijkheidskwesties bij foutieve vertalingen contractueel. Onafhankelijk juridisch advies wordt aanbevolen.

Budgetplanning en inspanningsschatting voor meertalige schema-implementatie

De invoering van gestructureerde gegevens in meerdere talen brengt eenmalige en doorlopende kosten met zich mee. Naast de pure vertaling van de markup-inhoud komen er kosten bij voor technische integratie, testen en onderhoud. Voor een realistische budgetplanning moet u rekening houden met de volgende posten:

1. Vertaling van de schema-velden: Per taalversie ontstaan kosten voor de vertaling van alle relevante JSON-LD-elementen (titels, beschrijvingen, vragen, antwoorden etc.). Omdat het om korte, vaak technische teksten gaat, kunnen vertaalbureaus speciale prijzen aanbieden. Reken met een toeslag van 10–20% voor het inwerken in de schemadefinities.

2. Technische aanpassing: De markering moet per taal ofwel in aparte JSON-LD-blokken of via meertalige velden gebeuren. Afhankelijk van uw systeem heeft uw ontwikkelteam extra tijd nodig om de logica voor taalwisseling en fallbacks te implementeren. Ervaren leert dat de initiële inspanning voor een website met vijf taalversies tussen de 15 en 25 mensdagen in de ontwikkeling ligt.

3. Testen en kwaliteitsborging: Elke taalversie moet afzonderlijk worden gevalideerd – met Google Rich Results Test, Schema.org-validators en handmatige steekproeven. Plan per taal ongeveer 1–2 dagen voor de eerste inrichting en een half uur per wijziging.

4. Doorlopend onderhoud: Bij actualisaties van het productassortiment of FAQ-inhoud moeten ook de markeringen tijdig worden aangepast. Bepaal of het vertaalteam bij nieuwe inhoud steeds de schemagegevens meelevert. Een contentmanagementsysteem dat gestructureerde gegevens automatisch genereert, vermindert de langetermijninspanning, maar vereist een passende inrichting.

5. Gereedschap en licenties: Als u speciale tools gebruikt voor het monitoren van gestructureerde gegevens (bijv. Webmaster Tools-API's of eigen dashboards), kunnen er abonnementskosten ontstaan.

Als vuistregel moet u voor het hele proces (invoering in drie hoofd talen) rekenen op een budget van 5.000 tot 15.000 euro, afhankelijk van de omvang van de site en het aantal producten. Bij kleine projecten met enkele FAQ-pagina's kan het bedrag lager uitvallen.

Juridische opmerking: De genoemde cijfers dienen slechts ter oriëntatie. Vraag individuele offertes aan ontwikkelaars en vertalers en houd er rekening mee dat de werkelijke kosten per complexiteit kunnen verschillen. Voor bindende uitspraken wendt u zich tot uw juridische en fiscale adviseurs.