Structured data in JSON-LD maakt uw pagina’s machineleesbaar en vergroot de kans dat AI-assistenten uw content correct interpreteren en citeren. Het vocabulaire komt van Schema, de markup controleert u met validator.schema.org. Het directe voordeel is een betere entity-toewijzing: AI koppelt uw tekst aan de juiste organisatie, auteur en pagina. Wij, Informatiegidsen Nederland, leggen hieronder uit hoe u dat praktisch en beheersbaar inricht.
Kort samengevat:
- Gebruik Organization en WebSite op de homepage, Article of BlogPosting met auteur en uitgever bij artikelen, en FAQPage alleen bij zichtbare vragen en antwoorden.
- Geef elke pagina één hoofdentiteit met een stabiele, absolute @id; koppel auteur, uitgever en broodkruimelnavigatie eraan in plaats van organisatiegegevens telkens te herhalen.
- Leg voor een eigen zoekpijplijn voor AI documentnummer, sectienummer, taal en versie vast; bewaar metadata bij vectorrepresentaties om oude of verkeerdstalige fragmenten te filteren.
- Lever JSON-LD aan de serverkant aan en test sjablonen automatisch bij elke bouw; controleer ook de productieversie, want uitbreidingen of caching kunnen gegevens wijzigen.
- Begin met pagina’s met veel verkeer of zakelijk belang; schaal pas op als de basis stabiel is en wijs per sjabloon een verantwoordelijke aan.
Inhoudsopgave
- Welke schema-types gebruikt AI het meest en wanneer past u ze toe?
- Hoe gebruiken AI en LLM’s structured data, van kennisgrafieken tot RAG?
- Zo bouwt u stap voor stap valide JSON-LD die AI ondersteunt
- Hoe zet u structured data in voor AI-workflows en RAG-pijplijnen?
- Met welke tools valideert en automatiseert u structured data?
- Governance en onderhoud: datacontracts, versiebeheer en change control
- Herkenbare patronen: zo ziet een werkbare architectuur eruit
- Ons redactionele standpunt: begin klein, meet en schaal met governance
- Zichtbaarheid en autoriteit opbouwen via Informatiegidsen Nederland
- Veelgestelde vragen
- Bronnen
Welke schema-types gebruikt AI het meest en wanneer past u ze toe?
Niet elk schema-type heeft evenveel waarde voor AI-vindbaarheid. Yoast beschrijft structured data als een betekeniskaart die AI-assistenten, LLM’s en kennisgrafieken helpt content correct te interpreteren en nauwkeurig toe te schrijven aan de juiste entiteit. Dat maakt de keuze van types vooral een keuze over identiteit en context: wie publiceert dit, wie schreef het, waar gaat het over en hoe hangt het samen met de rest van de site?
Een bruikbare indeling per doel:
- Organization, WebSite en WebPage leggen vast wie u bent en hoe uw site is opgebouwd. Organization is de anker-entiteit waar al het andere naar verwijst.
- Article of BlogPosting en Person koppelen een tekst aan een auteur en een uitgever. Zonder deze koppeling moet een model raden wie achter een bewering staat.
- FAQPage en HowTo geven vraag-antwoordparen en stappenlijsten in een vorm die AI direct kan overnemen, mits de inhoud ook zichtbaar op de pagina staat.
- BreadcrumbList vertelt waar een pagina in de sitehiërarchie hoort, wat het thema van een pagina verduidelijkt.
- Product en Service beschrijven wat u aanbiedt, met prijs, categorie en aanbieder als de gegevens kloppen.
- AggregateRating gebruikt u alleen wanneer er echt beoordelingen zichtbaar op de pagina staan.
Eén hoofdentiteit per pagina
De belangrijkste ontwerpregel is eenvoudig: geef elke pagina een duidelijke hoofdentiteit. Een artikel is een Article, een bedrijfspagina is een Organization of LocalBusiness, een productpagina is een Product. Alles wat daaromheen hangt, zoals auteur, uitgever, breadcrumbs en afbeelding, is een ondersteunende node die u via een @id koppelt in plaats van opnieuw volledig uit te schrijven.
Dat helpt veelvoorkomende fouten te voorkomen. De eerste is dubbele, afwijkende beschrijvingen van dezelfde organisatie op tientallen pagina’s, waardoor een model niet meer weet welke versie de juiste is. De tweede is een pagina die zichzelf als vier dingen tegelijk presenteert, waardoor het onduidelijk wordt waar de pagina echt over gaat.
Wanneer welk type?
Een praktische vuistregel per paginatype helpt bij de selectie. Een homepage krijgt Organization en WebSite. Een nieuwsartikel of blogpost krijgt Article of BlogPosting met een gekoppelde Person en de Organization als publisher. Een veelgestelde-vragenpagina krijgt FAQPage, maar alleen als de vragen en antwoorden zichtbaar zijn. Schema.org documenteert dat uitdrukkelijk. Een handleiding met genummerde stappen krijgt HowTo. Een dienstenpagina krijgt Service, gekoppeld aan de Organization die de dienst levert.
Wie bij nul begint, bouwt eerst de centrale entiteiten en pas daarna de uitzonderingen. Een site met alleen een goed gekoppelde Organization, WebSite, Article en Person is al beter leesbaar voor een machine dan een site met tientallen losse, inconsistente blokken. De implementatiegidsen op schema.org bieden daarvoor voorbeelden per type.
Hoe gebruiken AI en LLM’s structured data, van kennisgrafieken tot RAG?
Een taalmodel leest geen markup zoals een mens een pagina leest, maar structured data verkleint de ruimte voor misverstanden. Wanneer een pagina expliciet aangeeft wie de auteur is, welke organisatie publiceert en welke externe profielen bij die organisatie horen, kan een systeem die gegevens ondubbelzinnig toewijzen. Dat heet entity confidence: de mate waarin een systeem zeker weet dat twee vermeldingen naar dezelfde entiteit verwijzen.
Stabiele, absolute @id-identifiers spelen hierin een sleutelrol. Volgens Generativ creëert het gebruik van stabiele, absolute @id’s een robuuste kennisgraaf die AI helpt entiteiten ondubbelzinnig te koppelen, wat cruciaal is voor entity confidence. Een @id is dus geen technisch detail, maar het scharnier waarop uw hele entiteitenmodel draait.
Velden die er in de praktijk toe doen
Sommige eigenschappen leveren meer op dan andere. Dit zijn de velden waar wij bij een audit als eerste naar kijken:
- author, gekoppeld via @id aan een Person-node met naam en profielen, zodat een bewering een herleidbare bron heeft.
- datePublished en dateModified, zodat een systeem kan beoordelen hoe actueel een tekst is.
- @id, stabiel en absoluut, zodat dezelfde entiteit op elke pagina dezelfde identiteit houdt.
- sameAs, met verwijzingen naar officiële profielen en registers, zodat uw organisatie aan externe bronnen wordt gekoppeld.
- publisher, verwijzend naar de centrale Organization-node.
Van markup naar protocollen en retrieval
Structured data staat niet los van de bredere ontwikkeling waarin AI-systemen gestandaardiseerde manieren krijgen om bronnen aan te spreken. Het Model Context Protocol (MCP) is zo’n standaard: het beschrijft hoe een model gegevens en tools via vaste velden kan benaderen. Het principe lijkt op dat van schema.org. Wie zijn gegevens consistent benoemt en structureert, maakt het een model makkelijker om ze te vinden en te gebruiken.
Bij retrieval-augmented generation (RAG) haalt een systeem eerst relevante tekstfragmenten op en laat het model daarna een antwoord formuleren. Metadata per fragment helpt dan bij drie dingen: knippen in zinvolle chunks, filteren op bijvoorbeeld taal of versie, en het ophalen van de juiste embeddings. Microsoft beschrijft in de Azure Databricks-documentatie dat een RAG-pijplijn bestaat uit corpusselectie, preprocessing, chunking, embedding en indexering, en dat metadata naast de chunks de retrieval en filtering verbetert.
Kernpunt: Yoast stelt dat structured data niet langer alleen voor rich results dient, maar ook fungeert als betekeniskaart voor AI-assistenten en kennisgrafieken. Behandel uw markup daarom als onderdeel van uw contentarchitectuur, niet als een SEO-extra.
Wie hier verder in wil: in ons artikel over een AI SEO-strategie voor Nederlandse marketeers werken we de strategische kant verder uit.
Zo bouwt u stap voor stap valide JSON-LD die AI ondersteunt
Deze checklist is geschreven voor developers en SEO’s die samen aan de slag gaan. Werk de stappen in volgorde af. De latere stappen steunen op de entiteiten die u in de eerdere stappen vastlegt.
- Lever JSON-LD server-side aan. Zet het blok in de HTML die de server uitlevert, of gebruik server-side rendering. Dan lezen crawlers en AI-systemen de markup direct, zonder dat ze eerst JavaScript hoeven uit te voeren.
- Definieer centrale entiteiten. Maak één Organization-node en één WebSite-node met stabiele, absolute @id’s, bijvoorbeeld een URL met een fragment zoals
https://voorbeeld.nl/#organization. Gebruik die @id’s op elke pagina opnieuw en verander ze nooit. - Koppel auteurs aan de organisatie. Maak per auteur een Person-node met @id en leg via worksFor de relatie met de Organization vast. Dat maakt zichtbaar wie namens wie schrijft.
- Koppel elk artikel aan auteur en uitgever. Laat het Article of BlogPosting verwijzen naar de Person via author en naar de Organization via publisher, steeds met de @id en niet met een herhaald blok.
- Gebruik FAQPage alleen bij zichtbare Q&A. De vragen en antwoorden in de markup moeten letterlijk op de pagina staan. Staat er geen zichtbare vraag-antwoordsectie, laat het type dan weg.
- Voeg breadcrumbs toe waar ze helpen. Een BreadcrumbList die overeenkomt met de zichtbare kruimelpad-navigatie geeft de hiërarchie van de site door.
- Leg RAG-metadata vast. Gebruikt u uw content in een eigen retrieval-pijplijn, geef elk document dan een document-id, sectie-id, taal en versie mee. Zo kunt u later filteren en teruglopen naar de bron.
- Valideer en automatiseer. Test elke template met validator.schema.org en bouw een controle in uw CI/CD-proces, zodat een fout in de markup een release kan tegenhouden.
Waar het in de praktijk misgaat
De meeste problemen ontstaan niet in de eerste implementatie, maar bij het onderhoud. Een CMS-update verandert een template, een plugin voegt een tweede, afwijkende Organization toe, of een redacteur wijzigt een auteursnaam op de pagina maar niet in de markup. Plugins automatiseren veel werk, maar Generativ waarschuwt dat ze beperkt kunnen zijn en dat een doordachte architectuur met datacontracts tussen bron en consument nodig is, zodat automatische updates de juistheid van de gegevens niet verbreken. Daar komen we in het governance-gedeelte op terug.
Denk ook aan de volgorde van uw werk. Begin met de pagina’s die het meeste verkeer of het meeste zakelijke belang hebben: de homepage, de belangrijkste dienstenpagina’s en de artikelen waarmee u autoriteit wilt opbouwen. Schaal pas op wanneer de basis stabiel is. Een kleine, foutloze set entiteiten is waardevoller dan een brede uitrol met inconsistenties.
Pro-tip: Houd een eenvoudig register bij met alle @id’s die u gebruikt, inclusief de pagina waarop ze zijn gedefinieerd. Zo voorkomt u dat twee teams onafhankelijk van elkaar dezelfde entiteit onder een andere identifier aanmaken.
Wilt u de bredere context van AI-gestuurde zoekresultaten begrijpen? Lees dan ook Van AI tot Zero Click, waarin we uitleggen waarom uw SEO-strategie anders moet worden ingericht.
Hoe zet u structured data in voor AI-workflows en RAG-pijplijnen?
Voor teams die zelf retrieval bouwen, is structured data meer dan markup op een webpagina. Het is een denkwijze: elk stuk content krijgt een stabiele identiteit en beschrijvende eigenschappen waarop een systeem kan sorteren, filteren en verwijzen. De Microsoft-documentatie over unstructured data pipelines voor RAG laat zien dat de pijplijn begint bij corpusselectie en preprocessing en doorloopt via chunking en embedding naar indexering en opslag. Op elk van die stappen kunt u metadata meegeven.
Metadata als filter naast vectorzoeken
Vectorzoeken vindt fragmenten die inhoudelijk lijken op de vraag, maar het weet niet of een fragment verouderd is, in de verkeerde taal staat of bij een ander product hoort. Metadata vult dat aan. Door naast de embedding velden als taal, versie, documenttype en publicatiedatum op te slaan, kunt u eerst de kandidaten beperken en daarna pas op gelijkenis rangschikken. Dat levert preciezere antwoorden op en vermindert de kans dat een model een achterhaald fragment gebruikt.
Chunking en consistente metadata
Hoe u een document knipt, bepaalt wat een model later kan terugvinden. Een paar richtlijnen die we aanhouden:
- Knip langs de natuurlijke structuur van het document, zoals koppen en alinea’s, en niet op een vast aantal tekens.
- Geef elke chunk een sectie-id en een verwijzing naar het bovenliggende document-id, zodat de herkomst altijd te herleiden is.
- Neem de kop van de sectie op als context bij de chunk, zodat een losgeknipt fragment nog zin heeft.
- Gebruik voor metadata overal dezelfde veldnamen en waardenlijsten. Een filter op taal werkt niet als het ene document “nl” gebruikt en het andere “Nederlands”.
Consistentie is hier belangrijker dan volledigheid. Velden die overal kloppen, leveren meer op dan veel velden die half zijn ingevuld.
Opslag en platformkeuze
Bewaar de metadata samen met de embeddings in dezelfde index, zodat filteren en zoeken in één stap gebeuren en u geen tweede opzoeking nodig hebt. Bij de keuze van een platform wijst het Azure Well-Architected Framework erop dat een platform voor AI-workloads vectorzoekondersteuning, ETL/ELT-capaciteiten en schaalbare opslag moet bieden, en dat u moet controleren of het audit- en metadatacatalogusfuncties heeft. Voor teams met meerdere bronnen is die catalogus belangrijk: zonder centrale beschrijving van welke bron welke velden levert, groeit de inconsistentie met elke koppeling.
Wie vanuit marketing meekijkt, kan de relatie met conversational interfaces bekijken. Adworth beschrijft in een praktische gids over AI-chatbots op uw site hoe zulke interfaces in de praktijk worden ingezet. Ook daar geldt dat een chatbot alleen zo goed antwoordt als de gestructureerde content waaruit hij put.
Met welke tools valideert en automatiseert u structured data?
Valideren is geen eenmalige actie bij de lancering. Markup kan na elke templatewijziging stuk gaan zonder dat iemand het merkt, omdat de pagina er voor een bezoeker hetzelfde uitziet. Combineer daarom handmatige controles met geautomatiseerde.
- validator.schema.org controleert de syntaxis en de types van uw schema.org-markup. Deze validator is geschikt om een template of een losse URL snel door te lichten.
- De schema.org-documentatie vertelt per type welke eigenschappen bestaan en wat de verwachte waarden zijn. Raadpleeg die bij elke nieuwe eigenschap die u wilt toevoegen.
- De rich results-test van Google laat zien of een pagina in aanmerking komt voor verrijkte weergave en welke fouten of waarschuwingen er zijn.
- Google Search Console geeft voor uw live site meldingen en rapporten over structured data, zodat u problemen ziet die na de release zijn ontstaan.
- CI/CD-controles voeren bij elke build een automatische test uit op uw JSON-LD en laten de release falen als verplichte velden ontbreken of een @id verandert.
Het formaat zelf staat gedocumenteerd op Json-ld, dat JSON-LD beschrijft als formaat voor linked data en als aanbevolen standaard voor webmarkup. Het is nuttig om de basisprincipes daar eens door te nemen, zeker als u zelf templates schrijft: het helpt u begrijpen waarom een @id en een @type op de manier werken zoals ze werken.
Een vaste controleroutine
Stel een ritme vast dat bij uw organisatie past. Na elke release draait de geautomatiseerde test. Maandelijks kijkt iemand in Search Console naar nieuwe meldingen. Per kwartaal trekt u een steekproef van pagina’s uit elk paginatype en valideert u die handmatig. Wie dit vastlegt, voorkomt dat markup stilzwijgend verslechtert.
Pro-tip: Test niet alleen uw eigen templates, maar ook de gerenderde output op productie. Een template kan lokaal correct zijn en toch iets anders uitleveren door caching, een plugin of een tagmanager.
Governance en onderhoud: datacontracts, versiebeheer en change control
Structured data die niemand beheert, veroudert. De technische implementatie is meestal het kleinste probleem. De uitdaging is dat de markup en de zichtbare content uit elkaar lopen zodra meerdere teams eraan werken. Governance zorgt dat dat niet gebeurt.
- Datacontracts tussen bron en consument. Leg vast welk systeem de waarheid is voor welk veld, bijvoorbeeld auteursnaam, prijs of publicatiedatum, en welke velden de markup mag aflezen. Dit sluit aan bij het advies van Generativ om datacontracts te gebruiken zodat automatische updates de juistheid niet verbreken.
- Eigenaarschap van templates. Wijs een verantwoordelijke aan voor elke schema-template: wie mag aanpassen, wie beoordeelt en hoe wordt getest voordat het live gaat.
- Versiebeheer en release-checklists. Zet schema-templates in versiebeheer en neem een korte checklist op in elke release: zijn de @id’s ongewijzigd, valideert de markup en komt de markup overeen met de zichtbare tekst?
- Periodieke audits en synchronisatie. Plan terugkerende controles waarin u markup en content naast elkaar legt, en zorg dat wijzigingen in bronsystemen automatisch doorwerken in de markup.
Een goed ingericht proces maakt ook duidelijk wie verantwoordelijk is wanneer er iets misgaat. Dat lijkt bureaucratisch, maar het scheelt veel tijd wanneer een rapport in Search Console plotseling tientallen fouten toont. Over de kosten en het onderhoud van AI-pijplijnen schreven we eerder in Laat AI werk besparen? Of raak je sneller opgebrand?.
Herkenbare patronen: zo ziet een werkbare architectuur eruit
Patronen helpen u sneller te kiezen dan een lege editor. De volgende patronen komen in de praktijk vaak terug.
- Centrale Organization met artikelen eronder. Definieer de Organization één keer met een vaste @id, bijvoorbeeld op de homepage. Elk Article verwijst via publisher naar die @id en via author naar de @id van een Person. Zo ontstaat een netwerk waarin elke pagina dezelfde entiteiten deelt.
- FAQPage gekoppeld aan een zichtbare sectie. Genereer de FAQPage-markup uit dezelfde bron als de zichtbare vragen en antwoorden. Dan kunnen tekst en markup niet uit elkaar lopen, en voldoet u aan de eis uit de schema.org-documentatie dat de vraag-antwoordparen op de pagina zichtbaar zijn.
- RAG-metadata per document. Geef elk document een document-id, elk fragment een sectie-id, en leg taal en versie vast. Zo kunt u bij een antwoord altijd teruggaan naar de bron en oude versies uitfilteren.
- Acceptatie-checklist per template. Voordat een template live gaat, controleert u drie dingen: staat alles wat in de markup staat ook zichtbaar op de pagina, valideert de markup zonder fouten, en blijft de laadtijd binnen de afgesproken grens?
Het eerste patroon is het meest waardevolle om mee te beginnen, omdat de overige patronen erop voortbouwen. Een stabiele Organization-node is de ruggengraat van uw entiteitenmodel. Het laatste patroon, de acceptatie-checklist, voorkomt dat u technisch correcte maar inhoudelijk onjuiste markup uitrolt. Een veelgemaakte fout is bijvoorbeeld een beoordelingsscore in de markup die nergens op de pagina te zien is. Dat is niet alleen een kwaliteitsprobleem, maar kan ook leiden tot afstraffing door zoekmachines.
Een eenvoudige volgorde om de patronen te introduceren: begin met de centrale entiteiten, voeg daarna Article met author en publisher toe, breid uit met FAQPage waar zichtbare Q&A bestaat, en leg pas daarna de RAG-metadata vast als u een eigen retrieval-oplossing bouwt. Werk elke stap af en valideer die voordat u verdergaat.
Ons redactionele standpunt: begin klein, meet en schaal met governance
Wij vinden dat organisaties structured data niet langer als een technische bijzaak moeten zien. Wie wil dat AI-assistenten zijn naam, zijn experts en zijn standpunten correct weergeven, moet die informatie in een vorm aanbieden die machines ondubbelzinnig kunnen lezen. Dat is geen kwestie van een plugin aanzetten, maar van een bewuste keuze over hoe u uw identiteit online vastlegt.
Onze aanpak is bewust bescheiden. Begin met uw kernpagina’s: de homepage, uw belangrijkste dienstenpagina’s en de artikelen waarmee u autoriteit wilt opbouwen. Leg daar de entiteiten vast, valideer ze en wijs een eigenaar aan. Pas als dat stabiel draait, schaalt u op naar de rest van de site, en dan met governance in plaats van met losse hotfixes.
Wij denken ook dat veel teams het meten onderschatten. Kijk of uw organisatie correct wordt genoemd wanneer u AI-assistenten vragen stelt over uw vakgebied, en leg dat periodiek vast. Zo ziet u of uw markup effect heeft en waar nog gaten zitten. Consistentie wint van ambitie: een kleine set correcte, goed gekoppelde entiteiten levert meer op dan een uitgebreide maar rommelige implementatie.
— Mike
Zichtbaarheid en autoriteit opbouwen via Informatiegidsen Nederland
Goede markup versterkt uw eigen site, maar autoriteit ontstaat ook door vermeldingen op plekken waar uw doelgroep en AI-systemen al kijken. Een publicatie op een zakelijk platform geeft uw organisatie een extra, onafhankelijk vindbare vermelding in een relevante zakelijke context. Dat kan uw entiteit sterker verankeren.
Wij bieden onder meer:
- Bedrijfsprofielen, waarmee uw organisatie een eigen, vindbare pagina krijgt.
- Expertartikelen, waarin uw specialisten hun kennis delen onder hun eigen naam.
- Branded content, waarmee u uw verhaal redactioneel laat vertellen.
Meer lezen over wat een bedrijfsprofiel oplevert? Bekijk dan de voordelen van een betaald bedrijfsprofiel. Wilt u direct aan de slag? Via de aanmeldpagina vertelt u ons wat u wilt publiceren, en wij nemen contact met u op over de mogelijkheden. Prijzen zijn op aanvraag beschikbaar.
Veelgestelde vragen
Werkt AI beter met gestructureerde data?
Ja, AI kan gestructureerde gegevens ondubbelzinniger toewijzen aan de juiste entiteit dan llopende tekst alleen. Yoast noemt structured data een betekeniskaart die AI-assistenten, LLM’s en kennisgrafieken helpt content correct te interpreteren. Ongestructureerde tekst blijft bruikbaar, maar de kans op misinterpretatie is groter.
Hoe organiseert u data voor AI?
Geef elk stuk content een stabiele identiteit en consistente beschrijvende velden. Gebruik absolute @id’s, koppel auteurs en organisatie aan elkaar en leg metadata zoals taal en versie vast. Voor retrieval-pijplijnen bewaart u die metadata samen met de embeddings.
Kan AI werken met ongestructureerde data?
Ja, taalmodellen verwerken gewone tekst prima, en RAG-pijplijnen zijn juist gebouwd voor ongestructureerde bronnen. Metadata verbetert daarbij wel de retrieval en filtering, zoals Microsoft beschrijft. Structuur maakt het resultaat voorspelbaarder en beter herleidbaar.
Welke typen gestructureerde data zijn er?
Gangbaar is het onderscheid tussen gestructureerde, semigestructureerde en ongestructureerde data. Tabellen met vaste kolommen zijn gestructureerd, JSON en JSON-LD zijn semigestructureerd en vrije tekst is ongestructureerd. Voor het web gebruikt u meestal JSON-LD met types uit schema.org.
Bronnen
De aanbevelingen in dit artikel steunen op openbare standaarden en documentatie, niet op eigen aannames. Het vocabulaire komt van schema.org, het formaat van json-ld.org en de syntaxiscontrole van validator.schema.org. De ideeën over AI-interpretatie en entiteitentoewijzing komen uit de uitleg van Yoast, en de technische kant van RAG uit de documentatie van Microsoft.
Daarnaast benadrukken we wat in de praktijk het verschil maakt: monitoring, governance en testen. Een correcte eerste implementatie is slechts het begin. De waarde zit in het vasthouden van die kwaliteit. Als redactie met een eigen publicatieplatform kennen wij dat uit eigen ervaring met ons platform.
- Structured data with schema for search and AI • Yoast
- Build an unstructured data pipeline for RAG – Azure Databricks | Microsoft Learn
- Validator
- Schema
- Structured Data & Schema Markup uitgelegd
