Schema.org voor AI: welke gestructureerde data begrijpen assistenten echt?
Schema.org vertelt een machine expliciet wát een pagina is, in plaats van het te laten raden. Welke types daadwerkelijk iets opleveren voor AI-assistenten, hoe je ze aan elkaar knoopt met @id, en waar het in de praktijk misgaat.
Schema.org is een gedeelde woordenlijst waarmee je in machinetaal opschrijft wát er op een
pagina staat: dit is een organisatie, dit is een artikel met deze auteur en datum, dit is
een product met deze prijs. Je zet die woordenlijst meestal in als
JSON-LD — een blokje JSON in de <head> van je pagina.
Voor AI-assistenten is dat geen ranking-trucje maar iets nuchterders:
het verwijdert giswerk. Een model dat je pagina samenvat hoeft niet af te
leiden wie de uitgever is of wanneer het stuk geschreven werd — het staat er expliciet.
Welke types leveren dan echt iets op? In de praktijk een handvol:
Organization (wie ben je, met sameAs-links naar profielen die
modellen al kennen), Article of BlogPosting (wat is dit stuk, van
wanneer, van wie), FAQPage (vraag en antwoord in precies de vorm die een
assistent nodig heeft), Product of SoftwareApplication voor wat je
aanbiedt, en BreadcrumbList voor waar de pagina in je site hangt. De rest van de
ruim 800 types uit de woordenlijst is zelden de moeite — tenzij je toevallig recepten,
evenementen of vacatures publiceert.
Waarom een taalmodel iets heeft aan markup die het niet ziet
De reflex is begrijpelijk: een taalmodel leest toch gewoon de tekst? Klopt — en juist daarom helpt markup. Uit lopende tekst moet een model afleiden dat "Neuralex" de uitgever is en niet een genoemde klant, dat "18 juli" de publicatiedatum is en niet een datum in het verhaal, dat de auteur een organisatie is en geen persoon. Elk van die afleidingen kan misgaan. JSON-LD maakt er feiten van die geen interpretatie vragen.
Daar komt bij dat de systemen die je wilt bereiken zelden rechtstreeks je HTML lezen. Een assistent die live zoekt, leunt op zoekindexen en extractiepijplijnen die gestructureerde data al jaren uitlezen en als apart veld bewaren. Wat jij in JSON-LD zet, overleeft die reis vaak beter dan een zin halverwege je pagina. Hoe die technische laag samenhangt met robots.txt, llms.txt en agent-cards staat in ons stuk over wat GEO wél is.
De vijf types waar je mee begint
Organization. Eén keer goed, op je hele site herbruikt. Naam, url, logo,
contact, en vooral sameAs: links naar je profielen elders. Dat is het haakje
waarmee een model jouw site koppelt aan wat het buiten je site over je weet — en dat is
precies de kruisverificatie waarop vertrouwen wordt gebouwd.
Article / BlogPosting. Koptitel, beschrijving, publicatie- én wijzigingsdatum, taal, auteur, uitgever. De wijzigingsdatum is geen detail: bij vragen waar actualiteit telt, is "wanneer is dit voor het laatst herzien" een van de weinige signalen die een assistent objectief kan gebruiken.
FAQPage. Een lijst van Question-objecten met een acceptedAnswer. Let op de verwachting: Google beperkte in 2023 het tónen van FAQ-rich-results in de zoekresultaten tot een kleine groep sites, dus als visuele uitbreiding is dit type grotendeels uitgespeeld. Voor extractie is het dat niet — het levert een vraag-en-antwoordpaar aan in exact de vorm die een generatief antwoord nodig heeft.
Product / SoftwareApplication. Voor wat je verkoopt of aanbiedt. Naam, beschrijving, categorie, en waar van toepassing prijs en beschikbaarheid. Verzin hier niets bij: markup die niet klopt met wat er op de pagina staat, is erger dan geen markup.
BreadcrumbList. Onopvallend maar nuttig: het vertelt waar een pagina in de hiërarchie hangt, waardoor een losse URL niet als los blaadje wordt gelezen maar als onderdeel van een geheel.
@id: van losse blokjes naar één entiteit
De meestgemaakte fout is markup als een verzameling losse briefjes behandelen: op elke
pagina opnieuw een volledig Organization-blok, telkens net iets anders. Beter is één
canonieke definitie met een vaste identifier — bijvoorbeeld
https://jouwsite.nl/#org — en op alle andere pagina's alleen nog een verwijzing
naar dat @id. Dat is precies wat de artikelen op deze site doen: het
publisher-veld wijst naar één organisatie-definitie in plaats van hem te
herhalen.
Het effect is dat je markup één samenhangende graaf wordt in plaats van vijftig losse beschrijvingen. Een machine die drie van jouw pagina's ophaalt, ziet dan dat het over dezelfde uitgever gaat — in plaats van drie mogelijk verschillende organisaties met toevallig dezelfde naam.
Waar het in de praktijk misgaat
Markup die niet overeenkomt met de zichtbare pagina. Een FAQPage-blok met vragen die nergens op de pagina staan, of een prijs die afwijkt van wat de bezoeker ziet: dat is precies wat richtlijnen voor gestructureerde data verbieden, en het is ook gewoon slecht idee. Wie hier oprekt, riskeert dat álle markup van het domein genegeerd wordt.
Markup die pas na JavaScript verschijnt. Wordt je JSON-LD door een script ingevoegd, dan zien alleen de crawlers die JavaScript uitvoeren hem. Een deel van de AI-crawlers doet dat niet. Server-side renderen dus, of statisch genereren.
Verlopen data. Een dateModified die al twee jaar stilstaat
terwijl je de tekst herschreef, of sameAs-links naar profielen die niet meer
bestaan, werken tegen je. Behandel schema als onderdeel van de pagina, niet als iets wat je
er ooit één keer onder plakte.
Alles willen markeren. Twintig types stapelen levert geen twintig keer zo veel begrip op. Vijf kloppende types zijn meer waard dan twintig half ingevulde.
Hoe je controleert of het klopt
Twee gratis controles volstaan. De Schema Markup Validator van schema.org zelf checkt of je JSON-LD geldig is tegen de woordenlijst. Google's Rich Results Test checkt daarnaast of een type in aanmerking komt voor weergave in de zoekresultaten. Die tweede is strenger en smaller — geldige markup die "geen rich result" oplevert, is niet per se fout.
Belangrijker dan beide: lees je eigen JSON-LD een keer als mens en vraag je af of het klopt met wat er op het scherm staat. Wij nemen die vraag mee in de Agentic Search Optimizer, die een site langs 15+ checks legt — waaronder de vraag of de gestructureerde data beschrijft wat de pagina werkelijk is.
Conclusie
Schema.org is geen slimme truc om assistenten te overtuigen; het is de saaiste, meest
betrouwbare manier om ze niet te laten gokken. Vijf types, één canonieke organisatie met
een vast @id, markup die exact matcht met de zichtbare pagina, en een
validator die je af en toe draait. Dat is het hele verhaal — en het is een van de weinige
GEO-maatregelen die volledig in je eigen hand ligt. Hoe het past in het bredere plaatje,
van crawler-toegang tot citeerbare alinea's, staat in
ons pilaarartikel over GEO.