Hoe we stopten met JSON-LD als SEO-soep en een machineleesbare kennisslaag voor LLM's bouwden
We hadden net een ogenschijnlijk vlekkeloze Schema.org-implementatie opgeleverd voor een B2B-hardwareklant. Elke validator gaf groene vinkjes. Google Search Console toonde nul fouten en kende rich snippets toe aan de hele catalogus.
Toen deed ik een test in ChatGPT-4o en vroeg om een vergelijking van de specificaties van hun belangrijkste industriële pomp.
Totale mislukking.
Het model verzon de helft van de technische toleranties en pakte de garantievoorwaarden van de concurrent. We behandelden LLM's als traditionele zoekmachines, en dat liep compleet verkeerd af.
Waarom tokenisatie complexe structuren sloopt
De kern van het probleem is simpel:
LLM's lezen geen webpagina's. Ze lezen tokens.
Wanneer een AI-bot je site scrapt, ziet die geen overzichtelijk genest JSON-LD-script zoals in een DOM-visualizer. De parser sloopt alle structurele elegantie en breekt ruwe karakters af tot subwoord-tokens.
We dumpten standaard Schema.org-markup op de pagina en gingen ervan uit dat de AI de geneste hiërarchieën tussen gerelateerde productentiteiten wel zou behouden.
Niet dus.
Tokenisatie vlakt die expliciete relaties juist af. Het model herkent de losse termen, maar verliest de onderliggende logica tussen de nodes. Het resultaat is statistische soep.
Het is alsof je iemand een alfabetische woordenlijst geeft en verwacht dat diegene het plot van een technisch handboek begrijpt.
Traditionele SEO-markup werkt niet meer voldoende. Als het model entiteitsrelaties niet kan behouden tijdens tokenisatie, is je gestructureerde data waardeloos.
Ik ben helemaal klaar met adviezen die roepen dat teams gewoon "meer schema moeten toevoegen." Generieke SEO-plugins stapelen lost structurele degradatie tijdens token-ingestie echt niet op.
Als het LLM die exacte entiteitsrelaties niet kan reconstrueren uit de ruwe bytestream, bestaat je merk simpelweg niet in de gegenereerde output.
Waarom traditionele Schema.org faalt in Generative Engine Optimization
Gebruiken LLM's überhaupt wel JSON-LD schema?
Moderne grote taalmodellen leunen zwaar op gestructureerde JSON-LD-data wanneer ze gekoppeld zijn aan redeneerkaders en knowledge graphs om exacte entiteitsrelaties te extraheren zonder te hallucineren.
Ja, AI-modellen verwerken gestructureerde data. Maar ze consumeren het niet zoals een traditionele zoekbot die een omgekeerde index bouwt.
De meeste teams zien Schema.org als een oppervlakkig lijstje: gooi er een Article-tag op, dump een FAQ-blok en hoop op rich snippets. Dat werkte prima voor Google in 2020. Voor Generative Engine Optimization werkt dit niet meer.
Modellen browsen niet op je site voor esthetische markup. Ze zoeken naar expliciete connecties tussen nodes.
Zelfs wanneer engineers snappen dat modellen schema gebruiken, verpesten ze het vaak met veel te zware implementaties.
Het plugin-conflict: duplicatie en overhead
Ik zat gisteravond drie uur lang een enterprise e-commercesite met meer dan 15.000 SKU's te analyseren. Ze begrepen maar niet waarom Perplexity hun belangrijkste productspecificaties negeerde.
Wat bleek? Een complete puinhoop in de broncode.
Ze hadden drie afzonderlijke WordPress-plugins tegelijk draaien: één voor sitewide metadata, één voor geautomatiseerde reviews en een oude e-commerce-extensie. Elk injecteerde een eigen, ongecoördineerd @context-blok. Eén productpagina bevatte drie tegenstrijdige @type: Organization-definities en dubbele productnodes met verschillende valuta's.
Door herhalende schema-loops over gerelateerde varianten was de ruwe JSON-LD-payload al groter dan 400KB voordat de scraper überhaupt bij de body-tekst aankwam.
Het probleem is dat AI-scrapers keihard zijn met tokenlimieten en time-outs. Zodra een autonome agent stuit op een halve megabyte aan overbodige JSON-tekst, kapt hij de payload af of degradeert het naar onbruikbare ruis.
En dat brengt ons bij het echte heikele punt:
De meeste AI-crawlers voeren geen client-side JavaScript uit.
Als je klantbeoordelingen lazy-loadt of vertrouwenssignalen pas toont via dynamische scripts onderaan de pagina, ziet de AI-crawler alleen een lege huls. Google's traditionele webcrawler rendert client-side scripts later misschien nog in een tweede wachtrij. Een LLM-bot die realtime informatie moet ophalen, wacht daar niet op.
Als de data niet vanaf de allereerste byte in statische, deterministische HTML staat, bestaat het simpelweg niet voor de machine.
De paradigmaverschuiving: gestructureerde data als kennisslaag
Tien jaar lang zagen we JSON-LD als een visueel foefje. Je voegde wat code toe, duimde hard en hoopte dat Google je zoekresultaat sterren gaf of een uitklapbare FAQ toonde. Een cosmetisch lapmiddel.
Die tijd is voorbij.
Vandaag is gestructureerde data geen generator voor rich results. Het is de fundamentele kennisslaag voor grote taalmodellen.
Wanneer een AI-engine je site bekijkt, zoekt hij niet naar scherpe afbeeldingen. Hij zoekt eenduidige feiten: directe nodes, gevalideerde eigenschappen en concrete relaties. Vertrouw je puur op natuurlijke taal, dan dwing je het model om je betekenis te gokken via statistische waarschijnlijkheid.
Verder kijken dan Retrieval-Augmented Generation (RAG)
Veel mensen denken dat ruwe RAG-pipelines alles oplossen. Gewoon ongestructureerde artikelen in een vector database gooien, cosinus-overeenkomst berekenen, de beste tekstblokken ophalen en het LLM het laten uitzoeken.
Dat gaat continu mis.
We hebben dit direct getest: een standaard RAG-pipeline op basis van vectoren tegenover een schone, op entiteiten gemodelleerde JSON-LD knowledge graph voor complexe vragen over een gespecialiseerde B2B-catalogus.
De vector-RAG-opzet was rommelig. Het haalde gefragmenteerde stukken op, haalde prijsstaffels van vergelijkbare modellen door elkaar en verzon specificaties omdat de context eromheen dubbelzinnig was.
Daarna gaven we het model de schone JSON-LD-graph.
Nul hallucinaties. Directe entiteitsresolutie. Het model begreep exacte hiërarchieën, geneste attributen en productrelaties zonder onnodig tokens te verspillen.
Vector-overeenkomst vindt relevante tekst, maar gestructureerde data levert machineleesbare context. RAG geeft een LLM de ruwe ingrediënten; een correcte JSON-LD-structuur geeft de complete bouwtekening. Wil je dat een AI jouw entiteit foutloos citeert? Stop met het voeden van overbodige lappen tekst en bouw je kennisslaag direct in je markup.
Het exacte JSON-LD-framework dat wij inzetten voor AI-zichtbaarheid
Hoe controleer je of JSON-schema zichtbaar is voor LLM's?
Om te controleren of je JSON-schema zichtbaar is voor LLM's, moet je serverlogbestanden direct analyseren op user-agent strings van AI-crawlers (zoals GPTBot of ClaudeBot). Controleer of ze daadwerkelijk de specifieke statische HTML-bestanden met je ingesloten JSON-LD-payload ophalen, in plaats van te vertrouwen op Google Search Console, dat enkel traditionele indexering bijhoudt.
Google Search Console vertelt je niets over de vraag of de scrapers van OpenAI of Anthropic jouw Organization-schema hebben verwerkt. GSC monitort Googlebot en klassieke SERP-functies.
Wij lieten GSC links liggen en bouwden geautomatiseerde logfilters om verzoeken van GPTBot, ClaudeBot en PerplexityBot te isoleren. We keken niet naar de indexatiestatus, maar controleerden de ruwe fetch-payloads.
Haalde de bot de ruwe HTML op en bevatte die statische response onze geconsolideerde JSON-LD-graph? Dan werd de data correct verwerkt. Werd de JSON-LD pas via client-side JavaScript na de hydratatie ingeladen? Dan registreerde de bot een 200 OK, zag lege ruimte en vertrok weer.
Organization- en FAQPage-schema structureren voor AI
Om te zorgen dat je entiteit betrouwbaar opduikt in generatieve engines, heb je een deterministische structuur nodig. Elk beschikbaar Schema-type op één pagina dumpen zorgt alleen voor ruis.
Dit is het concrete patroon dat wij uitrollen:
- Organization Schema (Het anker): Globaal geplaatst over het hele domein. Dit stelt de entiteitsidentiteit vast en vertelt het LLM exact wie er spreekt, terwijl het de entiteit koppelt aan geverifieerde Wikidata-ID's en externe autoriteitsprofielen via
sameAs. - Article / TechArticle Schema (De context): Gestript van ballast. We focussen op
author,datePublisheden explicieteabout/mentionsarrays die paginathema's koppelen aan gedefinieerde entiteitsnodes. - FAQPage Schema (De directe feed): LLM's verwerken deterministische Q&A-formats zeer nauwkeurig. We mappen technische parameters en specificaties direct als heldere Vraag/Antwoord-paren in de JSON-LD-payload.
De oplevering is waar het bij de meeste technische teams misgaat.
Je kunt voor AI-bots absoluut niet leunen op client-side rendering.
We leerden dit via de harde weg bij een klant wiens FAQ-schema dynamisch werd ingeladen via React. De AI-crawlers laadden de initiële server-response en voerden het client-script nooit uit.
De regel is glashelder: je JSON-LD-payload moet vanaf byte nul statisch gerenderd zijn in de initiële HTML-response. Geen vertraagde hydratatie, geen client-side injectie.
Stop met optimaliseren voor Google, begin met bouwen voor entiteiten
Traditionele zoekmachineoptimalisatie loopt tegen zijn grenzen aan. Wie zich blindstaart op blauwe linkjes, negeert hoe informatie tegenwoordig wordt opgehaald. De operationele verschuiving draait om Machine-to-Machine communicatie.
Kopers klikken steeds minder door naar je site wanneer een AI-agent direct het antwoord formuleert, opties vergelijkt en intenties afhandelt in de interface. Als die agent jouw eigenschappen en relaties niet kan verifiëren via deterministische markup, ontbreekt je merk simpelweg in het antwoord.
De toekomst van M2M SEO
Als schema een bijzaak blijft—een decoratief script over een overladen DOM-structuur—kost dat onnodig veel context tokens. Het verwerken van ongeorganiseerde data verhoogt de latency en dwingt modellen terug te vallen op statistische gissingen in plaats van feiten.
Moet een AI-bot jouw entiteitsrelaties raden uit ongestructureerde tekst? Dan verzint hij er zo een concurrent bij.
Bij AnswerShaper zien we schema niet als een SEO-extraatje, maar als een expliciete API voor autonome modellen. Door dichte, onderling verbonden entiteitsgrafieken direct in statische code vast te leggen, elimineer je parsingfouten en lever je geverifieerde data tegen een fractie van de tokenkosten.
Houdt je SEO geen rekening met M2M? Dan bouw je voor een zoekwereld die snel verdwijnt. Zorg dat je in de prompt zit, anders tel je niet mee. Bouw die machineleesbare kennisslaag direct in je kerninfrastructuur, of accepteer dat je onzichtbaar bent op het generatieve web. Bekijk onze blueprint over How We Stopped Burning Tokens and Mastered Knowledge Graph Optimization for AI om te zien hoe wij onze entiteitsarchitectuur inrichten.