2026-01-14 · Redactie Baduno · 7 blog.readMin · Blog & Kennis
Gestructureerde gegevens: Schema.org begrijpelijk uitgelegd
Machineleesbare extra informatie maakt van zoekresultaten rijke resultaten met beoordelingen, FAQ's en bedrijfsgegevens. Zo werkt het.
Wat zijn gestructureerde gegevens
Onzichtbare JSON-blokken in de broncode beschrijven wat er op de pagina staat: dat is een bedrijf met dit adres, dat is een artikel met deze datum, dat is een FAQ met deze vragen. Zoekmachines hoeven niet te raden – ze lezen.
Wat het oplevert
Recht op uitgebreide weergaven (FAQ-fragmenten, broodkruimelpaden, organisatiepaneel), beter begrip van verbanden en schonere kennisgraafvermeldingen. Geen ranking-turbo – maar meer ruimte en vertrouwen in het zoekresultaat.
De belangrijkste typen voor bedrijven
Organization met registergegevens, WebSite, Service of Product met Offer, Article voor vakartikelen, FAQPage en BreadcrumbList. Meertalig geldt: elke taalversie draagt zijn eigen, vertaalde markering.
Niet vergeten te valideren
De Rich-Results-test toont wat Google leest, de Schema-Validator controleert de syntaxis. Foutieve markering is erger dan geen – het kost vertrouwen en in het ergste geval de uitgebreide weergave.
Gestructureerde gegevens en hreflang: Perfect samenspel voor meertalige pagina's
Een veelvoorkomende foutbron bij meertalige websites is het inconsistente gebruik van gestructureerde gegevens en hreflang-tags. Terwijl hreflang zoekmachines de taal- en regioalternatieven van een pagina signaleert, geven gestructureerde gegevens het inhoudstype prijs. Beide zijn onafhankelijk van elkaar, maar vullen elkaar aan: Een Duitse productpagina moet zowel een hreflang-tag naar de Engelse variant verwijzen als in het gestructureerde gegevensblok dezelfde product-ID met verschillende aanbiedingen en talen markeren. Belangrijk: Elke taalversie krijgt zijn eigen JSON-LD-blok met passende waarden – anders ontstaan er tegenstrijdigheden. De Rich-Results-test van Google toont vaak fouten wanneer bijvoorbeeld de organisatie in de Duitse versie een Engels adres bevat. Controleer daarom na elke taalimplementatie altijd beide markeringen parallel.
Onderhoud en actualisatie: Wie beheert de gegevens?
Gestructureerde gegevens zijn geen eenmalig project. Veranderen prijzen, openingstijden of productdetails, dan moeten de JSON-LD-blokken worden geactualiseerd. Idealiter neemt het Content-Management-Systeem de dynamische vulling over. Ontbreekt deze automatisering, dan is een duidelijke verantwoordelijke in het team nodig – bijvoorbeeld de redacteur voor artikel- en FAQ-gegevens, de ontwikkelaar voor organisatorische gegevens. Vermijd datasilo's: Een verouderd telefoonnummer in het Organization-blok schaadt het vertrouwen. Plan kwartaalreviews van alle gestructureerde gegevens, maar in ieder geval vóór elke grote herlancering. Een centraal dashboard dat alle gemarkeerde pagina's en hun validatiestatus weergeeft, is nuttig.
AI-ondersteunde creatie en controle van gestructureerde gegevens
Moderne AI-tools kunnen uit ongestructureerde tekst automatisch JSON-LD genereren – bijvoorbeeld voor FAQ-pagina's of artikelen. Dat versnelt het werk, maar brengt risico's met zich mee: AI ziet vaak contextuele nuances over het hoofd (bijv. verkeerde prijs of verouderde datum). Daarom is moedertaalcontrole door een redacteur onmisbaar. Gebruik AI voor de ruwe versie, laat dan een mens de waarden valideren. Ook bij meertalige pagina's helpt AI bij vertalingen van de gestructureerde gegevens, maar hreflang-tags en taalspecifieke ID's moeten handmatig worden ingesteld. Een beproefde aanpak: AI maakt het Engelse standaardblok, een lokale redacteur corrigeert en vult de landspecifieke velden aan.
Machineleesbare extra informatie maakt van zoekresultaten rijke resultaten met beoordelingen, FAQ's en bedrijfsgegevens. Zo werkt het.
Dynamische inhoud markeren: FAQ's, recensies en producten
Fouten komen vooral vaak voor bij dynamische inhoud. FAQ-pagina's moeten per vraag een eigen JSON-LD-entry hebben – niet de volledige lijst als één enkel Question-object. Bij recensies moet de beoordelingsschaal correct worden opgegeven (bijv. bestRating en worstRating). Productpagina's met varianten vereisen AggregateOffer-blokken met alle prijs- en beschikbaarheidsinformatie. Gebruik sjablonen in het CMS die automatisch de juiste typen genereren. Test elke dynamische pagina afzonderlijk in de Rich-Results-test, omdat fouten pas bij concrete waarden zichtbaar worden. Een veelvoorkomende fout: het gebruik van 'Review' in plaats van 'AggregateRating' voor gemiddelde beoordelingen.
Combinatie van meerdere Schema.org-typen op één pagina
Op een enkele pagina kunt u meerdere Schema.org-typen parallel markeren, mits deze verschillende aspecten van de inhoud beschrijven. Een productpagina kan tegelijkertijd een Product-blok (met prijs, beschikbaarheid), een Organization-blok (voor de fabrikant) en een Review-blok (voor beoordelingen) bevatten. Belangrijk is dat elk type in een apart JSON-LD-script staat of via @id consistent wordt gekoppeld. Voorbeeld: het Product-blok verwijst met "brand": {"@id": "#organisation"} naar het Organization-blok. Vermijd tegenstrijdige gegevens – zoals verschillende adressen in het Organization- en LocalBusiness-blok. Elk type moet inhoudelijk correct en taalspecifiek worden gemarkeerd: een Franse pagina krijgt Franse waarden in alle blokken. Gebruik het CMS om typen modulair te beheren, zodat u niet elk blok handmatig hoeft aan te passen. Controleer in de Rich-Results-test of alle blokken worden geaccepteerd – sommige tests tonen alleen het eerste blok. Een nette combinatie van meerdere typen vergroot de kans op rijke resultaten zoals carrousel, productboxen of organisatiepaneel.
Werken met @id en verwijzingen voor verbonden gegevens
Schema.org staat toe om objecten via @id te refereren en zo redundante gegevens te vermijden. In plaats van op elke pagina de volledige organisatie te herhalen, definieert u een centraal Organization-blok met een unieke @id (bijv. "https://voorbeeld.nl/#firma") en verwijst u in andere blokken ernaar via "@id": "https://voorbeeld.nl/#firma". Dit is vooral handig bij meertalige websites: de organisatie blijft hetzelfde, alleen de taalspecifieke velden zoals "name" of "description" wijken af. Zorg ervoor dat de @id consistent is over alle taalversies – dus dezelfde URI voor Nederlands, Engels enz. Referenties kunnen ook worden gebruikt voor auteur, productmerk of recensie-items. Valideer met de Schema-validator dat alle @id-verwijzingen oplosbaar zijn. Een fout: als de gerefereerde @id niet in dezelfde paginabron of op een andere pagina is gedefinieerd, breekt de validatie. Daarom kunt u centrale entiteiten het beste in een globaal bestand (bijv. organisatie.json) plaatsen en deze via JavaScript insluiten, of het CMS gebruiken voor dynamische integratie. Een nette @id-structuur helpt zoekmachines informatie te koppelen en verbetert de consistentie in de Knowledge Graph.
BreadcrumbList correct markeren: tips en valkuilen
Het markeren van BreadcrumbList mag eenvoudig lijken, maar in de praktijk komen vaak fouten voor die het succes van de rich snippet in gevaar brengen. Een correcte implementatie begint met het begrijpen van de hiërarchie: elk item in de lijst heeft een ItemListElement-object nodig, dat op zijn beurt een ListItem-object bevat. Cruciaal is de position-eigenschap: deze nummert de oplopende elementen, te beginnen met 1 voor de startpagina. Vermijd het weglaten van de startpagina – zelfs als deze niet in de zichtbare breadcrumb verschijnt, moet deze in de gestructureerde gegevens worden opgenomen. Een veelgemaakte fout is het gebruik van absolute URL's zonder rekening te houden met de taalversie: zorg ervoor dat de URL in de breadcrumb naar de juiste taalvariant verwijst, dus bijvoorbeeld naar /nl/producten in plaats van /en/products. Ook de benaming van de elementen moet taalspecifiek zijn – 'Startpagina' in het Nederlands, 'Home' in het Engels. Gebruik het name-veld voor de weergegeven tekst en vermijd afkortingen die zoekmachines verkeerd kunnen begrijpen. Controleer na de implementatie elk pad met de Rich-Results-test, omdat vooral bij dynamisch gegenereerde breadcrumbs gemakkelijk posities worden verwisseld of dubbele items ontstaan. Houd er ook rekening mee dat Google maximaal tien elementen weergeeft – een kortere, precieze navigatie heeft dan ook de voorkeur boven een te lange.
Geneste objecten en verwijzingen: @id en @context
Complexe gestructureerde gegevens maken vaak gebruik van de koppeling van meerdere typen via @id-referenties. Een typisch voorbeeld is een productpagina die zowel een aanbieding als een review bevat. In plaats van alle gegevens in één monolitisch blok te stoppen, is het schoner om aparte blokken met unieke @id-waarden te definiëren en deze vervolgens te refereren. De @id-waarde moet uniek zijn binnen de pagina en het gehele domein – idealiter gebruikt u de absolute URL van het object met een fragment zoals #product-1. Vermijd generieke ID's zoals #product, omdat deze bij meerdere pagina's tot conflicten leiden. Een ander belangrijk aspect is de @context: standaard wordt het Schema.org-vocabulaire gebruikt, maar voor eigen extensies kan een eigen context worden opgegeven. Zorg ervoor dat geteste extensies zoals health-lifesci of bib niet per ongeluk op commerciële pagina's terechtkomen. Bij meertalige pagina's moeten @id-referenties taalspecifiek zijn: de Duitse productpagina verwijst naar de Duitse aanbiedings-ID, niet naar de Engelse. Een nuttige techniek is het gebruik van @reverse voor inverse relaties, bijvoorbeeld wanneer een product verwijst naar een organisatie, maar de organisatie geen directe lijst van alle producten heeft. Test dergelijke ketens in de Schema-validator, omdat een ontbrekende dubbele punt al tot een validatiefout leidt. Plan voldoende tijd in voor het opsporen van fouten in gerefereerde objecten – ze zijn een veelvoorkomende foutbron in uitgebreide implementaties.
blog.faqT
Kan ik gestructureerde data ook achteraf op oude pagina's toevoegen?
Ja, gestructureerde data kunnen op elk moment worden toegevoegd. Zorg ervoor dat alle gegevens actueel zijn. Gebruik de Rich-Results-test van Google om de juiste implementatie te controleren. Bij veel pagina's wordt een stapsgewijze aanpak per inhoudstype aanbevolen.
Hoe vaak moeten gestructureerde data worden bijgewerkt?
Altijd wanneer de onderliggende informatie verandert (prijzen, openingstijden, productdetails). Plan minstens een kwartaalcontrole in. Dynamische systemen kunnen gegevens automatisch vullen – dat vermindert de update-inspanning en foutenbronnen.
