Een menselijke lezer begrijpt moeiteloos dat een pagina een recept, een product van 49 euro of een artikel van een bepaalde auteur toont. Een robot moet dat uit de HTML afleiden. Gestructureerde data geven hem die informatie in een expliciete, gestandaardiseerde vorm. Dat vermindert interpretatiefouten en opent de weg naar bepaalde verrijkte weergaven op de resultatenpagina’s.
Hoe gestructureerde data werken
De opmaak koppelt een type (Article, Product, Organization, BreadcrumbList, Event…) aan eigenschappen (titel, auteur, datum, prijs, beschikbaarheid). Het meest gebruikte vocabulaire is dat van schema.org, dat door verschillende zoekmachines samen wordt onderhouden. Google accepteert drie syntaxen, JSON-LD, Microdata en RDFa, en beschouwt ze als gelijkwaardig zolang de opmaak geldig is. Het raadt wel JSON-LD aan, omdat dat makkelijker te onderhouden is: het staat in een apart scriptblok, los van de zichtbare content.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "WordPress-back-ups: de 3-2-1-strategie",
"datePublished": "2026-03-12",
"author": { "@type": "Person", "name": "Sanne de Vries", "url": "https://voorbeeld.nl/over-ons/" }
}
</script>Voor de functies van Google Zoeken is de documentatie van Google leidend: als die afwijkt van schema.org (verplichte of aanbevolen eigenschappen), volg je eerst Google.
Wat ze opleveren, en wat ze niet garanderen
- Een beter begrip van de pagina: wie publiceert, om wat voor content het gaat, op welke datum.
- Geschiktheid voor rich results (kruimelpad, reviews, producten, evenementen…). Alleen geschiktheid: Google garandeert nooit dat ze verschijnen, en opmaak die zijn richtlijnen niet volgt, kan een pagina ongeschikt maken.
- Geen bonus voor generatieve AI. De handleiding van Google over optimaliseren voor zijn AI-functies vermeldt dat gestructureerde data niet nodig zijn om daarin te verschijnen en dat er geen speciale schema.org-opmaak vereist is. Ze raadt wel aan ze te blijven gebruiken voor rich results. Meer daarover in de definitie van GEO.
Voor WordPress
WordPress maakt zelf geen JSON-LD aan. Dat doen SEO-plugins (Yoast SEO, Rank Math, All in One SEO…) en sommige thema’s, die een graaf genereren die de site, de organisatie, de pagina en de auteur beschrijft. Een paar vuistregels:
- Eén bron van opmaak: een thema en een plugin die elk het artikel beschrijven, leveren tegenstrijdige duplicaten op. Schakel een van de twee uit.
- Alleen zichtbare content: zet geen reviews, prijzen of vragen in de opmaak die de lezer niet op de pagina ziet.
- Test na elke wijziging met de test voor rich results van Google, en volg daarna de bijbehorende rapporten in Search Console.
- Houd de plugin up-to-date: SEO-plugins draaien op miljoenen sites en hebben ook kwetsbaarheden gekend, zoals de beveiligingsgeschiedenis van Yoast SEO laat zien.
Veelgemaakte fout: inlognamen prijsgeven
Het type Person dat de auteur beschrijft, bevat vaak het adres van het auteursarchief, waarvan het laatste deel standaard de inlognaam is. Dat is een handige hulp bij gebruikersenumeratie door aanvalsrobots. Laat de auteur liever naar een “Over ons”-pagina verwijzen en geef hem een weergavenaam die verschilt van zijn inlognaam: zo houd je een vertrouwenssignaal dat nuttig is voor E-E-A-T, zonder de helft van de inloggegevens weg te geven. Ons artikel over een beveiligde WordPress-site klaarmaken voor GEO beschrijft die instellingen.