Schema.org en gestructureerde gegevens voor AI: waar ligt het werkelijke probleem Het implementeren van gestructureerde gegevens is al lang niet meer alleen bedoeld om Google sterretjes, broodkruimels of uitgebreide resu...

Schema.org en gestructureerde data voor AI: waar ligt het echte probleem

Het implementeren van gestructureerde data dient al lang niet meer alleen om Google sterren, breadcrumbs of een uitgebreid resultaat te laten tonen. Tegenwoordig staat er meer op het spel. De site moet leesbaar zijn niet alleen voor de klassieke crawler, maar ook voor systemen die synthesiserende antwoorden, samenvattingen en citaten in AI-resultaten opbouwen. En precies daar begint het probleem: veel implementaties lijken technisch correct, maar leveren modellen en zoekmachines geen samenhangend, betrouwbaar beeld van entiteiten, relaties en context.

De meest voorkomende fout is niet het ontbreken van schema-markup. De fout is het behandelen van Schema.org als een versiersel. Iemand voegt Article, FAQPage of Product toe, de validator geeft groen licht en het onderwerp wordt als afgehandeld beschouwd. In de praktijk ondersteunt zulke markup vaak noch semantische indexering, noch systemen die verantwoordelijk zijn voor AI-overzichten, conversationele antwoorden of engines zoals Perplexity. De reden is eenvoudig: modellen "zoeken" niet naar schema omwille van schema. Ze zoeken goed beschreven entiteiten, attributen en afhankelijkheden die bevestigd kunnen worden in de inhoud, de structuur van de pagina en externe signalen.

Dat onderscheid is belangrijk. Als je deskundige inhoud publiceert over medische apparaten, zoals holters, oximeters en pulsoximeters, dan volstaat een product- of categorieomschrijving op zichzelf niet. Het systeem moet herkennen wat het object is, tot welke klasse entiteit het behoort, welke parameters het heeft, waarvoor het gebruikt wordt en in welke context het geciteerd zou moeten worden. Gestructureerde data zijn een van de zuiverste manieren om die informatie over te brengen, maar alleen als ze overeenkomen met wat de gebruiker op de pagina ziet.

Waarom AI gestructureerde data nodig heeft, als het gewone tekst "leest"

Die vraag komt regelmatig terug en komt meestal voort uit de foutieve veronderstelling dat taalmodellen werken als mensen. Dat doen ze niet. Ze kunnen ongestructureerde tekst interpreteren, maar ze presteren veel beter waar informatie expliciet, consistent en te koppelen is aan bekende entiteitstypen. Schema.org vervangt de inhoud niet. Het ordent de semantische laag van een site.

In de praktijk gebruiken zoek- en AI-systemen meerdere lagen signalen gelijktijdig: HTML, koppen, interne links, benoemde entiteiten, gestructureerde data, feeds, reputatiesignalen en consistentie van informatie tussen pagina's. Als een pagina een auteur, organisatie, publicatie, product of procedure beschrijft, helpen gestructureerde data dubbelzinnigheid te verminderen. Voor modellen is dat waardevol. Minder gokken, meer zekerheid.

Dit is vooral belangrijk bij specialistische content en YMYL. Bij onderwerpen rond gezondheid, diagnostiek of apparatuur die vitale parameters monitort, zijn systemen voorzichtiger. Alleen aanwezigheid van trefwoorden bouwt geen geloofwaardigheid op. Er is overeenstemming nodig tussen wat je als organisatie declareert, wat de auteur publiceert, welke gebieden de site bestrijkt en welke entiteiten door de site-architectuur lopen. Gestructureerde data helpen dat beeld te sluiten.

Gestructureerde data als semantische laag, geen SEO-toevoeging

De meest volwassen implementaties zien schema-markup als een datamodel voor content. Ze beginnen niet met de vraag "welk rich result willen we krijgen", maar met de vraag "welke entiteiten hebben we op de site en welke relaties tussen hen moeten duidelijk worden beschreven". Dat verandert alles.

Voorbeeld: een educatief artikel over saturatiemonitoring kan enkel als Article worden gemarkeerd. Dat is correct, maar oppervlakkig. Een betere implementatie koppelt Article aan WebPage, Organization, Person of MedicalEntity, als de context dat toelaat, en plaatst het in een logische structuur van de site. Daardoor ziet de crawler en het AI-systeem geen losstaand bericht uit de context, maar een element van een grotere kenniskaart.

Welke Schema.org-typen het grootste belang hebben in de context van AI

Er is niet één type schema dat "werkt op AI". Het werkt niet zo simpel. Effectieve implementaties vertrouwen op meerdere lagen van annotatie, waarvan elke laag een ander semantisch probleem oplost. De ene identificeert een entiteit, de andere bepaalt de functie van de pagina, weer een andere ordent de relaties tussen elementen.

Organization en Person: fundament van vertrouwen

Als een site deskundige content publiceert, moet je eerst de entiteit die verantwoordelijk is voor de publicatie en de auteurs duidelijk beschrijven. Dat klinkt banaal, maar slechts schijnbaar. Op veel sites bestaat de auteur alleen als een regel met voor- en achternaam, zonder profielpagina, zonder specialisatie, zonder koppeling aan een organisatie. Voor de gebruiker is dat zwak. Voor de machine nog erger.

In de praktijk werkt het goed wanneer de organisatie een eigen, consequent beschreven entiteit heeft met naam, URL, logo, sociale profielen en een relatie naar gepubliceerde content. De auteur zou op zijn beurt een eigen pagina moeten hebben, een vaste identificator-URL en een beschrijving van de specialisatie. In deskundige content is dat geen detail. Het is een signaal van inhoudelijke verantwoordelijkheid.

WebSite, WebPage en BreadcrumbList: context van de pagina

De tweede laag is informatie over de site zelf en de plaats van de pagina in de sitestructuur. WebSite helpt de hele site als entiteit te identificeren, WebPage specificeert het karakter van een bepaald document, en BreadcrumbList laat zien hoe een resource binnen de informatiearchitectuur past.

Het gaat niet alleen om UX. AI en zoekmachines gebruiken deze signalen om het onderwerp van een sectie, de hiërarchie van content en de relaties tussen categorieën te begrijpen. Als een site een uitgebreide product- en educatiestructuur heeft, ondersteunen breadcrumbs de interpretatie of een gebruiker een categoriepagina, een instructieartikel, een productpagina of een informatieve pagina leest.

Article, BlogPosting, MedicalWebPage, TechArticle: het type content doet ertoe

De keuze van het contenttype mag niet willekeurig zijn. Heel vaak zie je dat een hele blog met één sjabloon BlogPosting wordt gemarkeerd, ongeacht of de tekst over een handleiding, technische analyse, vergelijking van parameters of medische kwesties gaat. Dat is handig voor de implementatie, maar semantisch armoedig.

Als het onderwerp technisch of specialistisch is, is het beter een type te kiezen dat zo dicht mogelijk bij de werkelijke aard van het document ligt. Het hoeft niet altijd de meest exotische klasse in Schema.org te zijn. Soms levert een gewone Article met goed opgebouwde eigenschappen een beter resultaat dan overdreven ambitieus typeren zonder dekking in de inhoud. De regel is simpel: precisie ja, kunstzinnigheid om de kunst niet.

Product, Offer i parametry techniczne

Op sites die content en e-commerce of content en catalogus combineren, is het van cruciaal belang producten en hun attributen correct te beschrijven. Dit geldt ook voor categoriepagina's, zoals bloeddrukmeting, waar de gebruiker en de crawler een helder signaal nodig hebben welke reeks entiteiten een sectie omvat.

Bij specialistische apparatuur is Product op zich slechts het begin. Voor AI zijn ook eigenschappen belangrijk: merk, model, identificator, gebruiksbeschrijving, parameterbereik, compatibiliteit, beschikbaarheidsstatus, en in sommige contentmodellen ook de relatie met een overkoepelende categorie. Als de productbeschrijving mager is en het schema velden automatisch met vaagheden invult, krijgt het systeem ruis in plaats van kennis.

Beste implementatiepraktijken die de interpretatie door AI daadwerkelijk verbeteren

De beste praktijken draaien niet om het toevoegen van zoveel mogelijk eigenschappen. Ze draaien om consistentie, samenhang en semantische bruikbaarheid. Dat zijn de drie pijlers waarop zinvolle implementatie rust.

1. Consistentie van gestructureerde data met zichtbare inhoud

De problematischste implementaties verklaren meer dan ze laten zien. Een pagina gemarkeerd als FAQPage zonder volledige vragen en antwoorden in de inhoud, een product met een prijs die voor de gebruiker niet zichtbaar is, een auteur met een toegewezen specialisatie die nergens verifieerbaar is. Zulke afwijkingen bouwen geen voorsprong op. Ze vormen een risico dat het signaal wordt genegeerd.

Voor AI is consistentie cruciaal, omdat modellen en zoeksystemen continu lagen data vergelijken. Als JSON-LD iets zegt en de body van de pagina iets anders, neemt het vertrouwen in het hele document af. Goed geïmplementeerde schema's zouden de pagina niet moeten "oppoetsen". Ze zouden die trouw moeten beschrijven.

2. Constante identificatoren en relaties tussen entiteiten

In de praktijk levert consequent gebruik van @id veel op. Daarmee kun je organisatie, auteur, artikel, pagina en product verbinden in één netwerk van relaties. Dat is een ondergewaardeerd element van implementaties. Zonder het blijft markup vaak een verzameling losse objecten. Met het wordt het een kennisgrafiek.

Op implementatieniveau betekent dit dat de organisatie-entiteit in de hele site dezelfde identificator zou moeten hebben, hetzelfde voor auteurs, en dat artikelen en pagina's naar diezelfde entiteiten verwijzen in plaats van duplicaten te creëren. Die orde helpt niet alleen robots. Het vergemakkelijkt ook het onderhoud van data bij uitbreiding van de site.

3. Kiezen voor JSON-LD in plaats van het onnodig mixen van formaten

Je kunt schema implementeren via Microdata, RDFa en JSON-LD. In content- en e-commerceprojecten blijkt JSON-LD meestal het meest geschikt, omdat het leesbaar is, eenvoudiger te versioneren en makkelijker in kwaliteitscontrole. Het mixen van formaten op één pagina biedt zelden voordeel. Het leidt vaker tot conflicten, duplicatie of uiteenlopende waardes voor eigenschappen.

Als een site meerdere databronnen heeft — CMS, productensysteem, blogmodule, externe feed — is het zinvol centraal vast te leggen welke laag welke entiteiten genereert en welke velden de bron van waarheid zijn. Zonder dat ontstaan er na een paar maanden inconsistenties die zonder handmatige audit moeilijk te detecteren zijn.

4. Beperk automatisering waar het de kwaliteit schaadt

Automatisch genereren van schema is nuttig, maar je kunt er gemakkelijk mee overdrijven. Dit geldt vooral voor grote sites waar elk artikel dezelfde set eigenschappen krijgt ongeacht het onderwerp. Het resultaat? Formeel is er markup, maar semantisch levert het bijna niets op.

Uit ervaring werken hybride implementaties het beste: een systeemgegenereerde datakern, waarbij sleutelvelden in de contentbewerking worden geschreven of ten minste geverifieerd. Deze aanpak is bijzonder effectief voor specialistische sites, waar de beschrijving van een procedure, apparaat of technische parameter precies en niet sjabloonmatig moet zijn.

Praktische implementatiescenario's

Deskundig artikel op een brancheplatform

In het eenvoudigste scenario hebben we een educatief artikel. Dit moet worden beschreven als Article of BlogPosting, gekoppeld aan WebPage, een auteur, een organisatie en een hoofdafbeelding. Daarnaast zijn er basisattributen: headline, datePublished, dateModified, author, publisher, mainEntityOfPage.

Klinkt standaard, maar het verschil zit in de uitvoering. De titel in de schema moet overeenkomen met de op de pagina zichtbare titel. Data moeten overeenkomen met de daadwerkelijke publicaties en updates. De auteur mag geen anoniem label zijn. Als de tekst deskundig van aard is, moet het profiel van de auteur de competenties bevestigen. Voor AI-systemen is dat een signaal of het de moeite waard is het materiaal als bron te gebruiken.

Categoriepagina met semantisch potentieel

Categoriepagina's worden vaak verwaarloosd, omdat veel teams er alleen naar kijken vanuit het oogpunt van navigatie of productfiltering. Terwijl het vaak een van de sterkste bronnen is om topical authority op te bouwen. Als een categorie een beschrijvende laag heeft, een zinvolle H1-H2-structuur, logische subcategorieën en gerelateerde productentiteiten, kan het een belangrijk knooppunt van kennis worden voor zoekmachines en AI.

Hier zou schema zich niet moeten beperken tot toevallige CollectionPage. Het is zinvol het paginatype, breadcrumbs, de organisatie duidelijk te bepalen en, als dat technisch gerechtvaardigd is, ook de relatie tot de vermelde producten of het bovenliggende themagebied. Het doel is niet een overvloed aan markup. Het doel is een betere verankering van de categorie in de sitegrafiek.

Specialistisch product met veel parameters

Bij de productpagina's van technische en medische producten betreft het probleem meestal niet de implementatie van Product zelf, maar de kwaliteit van de attributen. Gegevens worden vaak geïmporteerd uit ERP-systemen of groothandels, waardoor de beschrijvingen catalogusachtig zijn en weinig zeggen over toepassing. Voor de gebruiker ongemakkelijk. Voor AI betekent het een laag niveau van context.

Een goed voorbereide productpagina zou transactionele gegevens moeten combineren met een inhoudelijke laag. Schema kan dan zowel het product en het aanbod omvatten, als technische eigenschappen, als deze op een gestructureerde manier in de content worden gepubliceerd. Een dergelijk model bevordert betere herkenning van entiteiten en vergroot de kans dat een bron wordt gebruikt in feitelijke antwoorden, en niet alleen in de klassieke ranking.

Meest voorkomende technische problemen die de waarde van gestructureerde gegevens verminderen

De meeste problemen komen niet door de standaard Schema.org zelf. Ze vloeien voort uit het implementatieproces. Redactie, SEO, ontwikkelaars en het CMS-team werken apart, en schema ontstaat als een apart module aan het einde. In zo'n opzet is het heel makkelijk om fouten te maken.

Duplicatie van entiteiten

Dezelfde auteur beschreven vijf keer met verschillende URL's. Een organisatie die de ene keer met volledige naam voorkomt, de andere keer in verkorte vorm. Een product met een ander model in de content dan in de gestructureerde gegevens. Dat is typisch. Voor een mens klinkt het als een kleinigheid; voor een systeem betekent het verlies van zekerheid over de identiteit van het object.

Sjabloonmatig invullen van velden zonder inhoudelijke waarde

Velden zoals description, about, knowsAbout of keywords worden soms automatisch gevuld in de hoop dat „meer data zal helpen”. In de praktijk helpt dat alleen als de data zinvol zijn. Anders wordt schema een laag semantische spam.

Geen updates na wijzigingen op de pagina

De site verandert de titel, auteur, de categorie-structuur of de beschikbaarheid van een product, maar de JSON-LD blijft ongewijzigd. Dit is een veelvoorkomend effect van eenmalige implementaties. Gestructureerde gegevens zijn geen decoratief element dat je één keer toevoegt. Ze zouden samen met de content en het catalogus moeten meebewegen.

Technische validatie zonder semantische validatie

Dit is een probleem dat ik regelmatig bij audits zie. De site doorstaat de tooltests, maar blijft slecht te begrijpen. Een validator zegt of de syntax correct is. Hij zegt niet of het gekozen entiteitstype zinvol is, of de eigenschappen adequaat zijn, en of de hele markup daadwerkelijk de interpretatie van de pagina versterkt. Dit deel moet handmatig worden beoordeeld, in de context van het zakelijke doel en het soort content.

Hoe ziet een volwassen implementatieproces voor gestructureerde gegevens eruit

Een degelijke implementatie begint niet in de code. Het begint met een informatiemodel. Eerst moet je vaststellen welke paginatypes er op de site bestaan, welke entiteiten cruciaal zijn en welke relaties expliciet beschreven moeten worden. Pas daarna kies je de Schema.org-types en de wijze van genereren.

In de praktijk werkt een gelaagde indeling goed. De eerste laag zijn globale entiteiten: organisatie, website, auteurs. De tweede laag zijn entiteiten afhankelijk van het paginatype: artikel, categorie, product, aanbieding. De derde laag zijn relaties: auteur van de publicatie, publisher, breadcrumbs, mainEntity, verbanden tussen pagina's. Zo'n opzet voorkomt chaos en beperkt het risico dat elke template los van de rest van de site wordt ontwikkeld.

De volgende stap is het in kaart brengen van de databronnen. Je moet weten waar de productnaam vandaan komt, waar de update datum vandaan komt, waar de auteurgegevens vandaan komen, waar de organisatiebeschrijving vandaan komt. Als deze informatie uit verschillende systemen komt en geen eenduidige eigenaar heeft, zijn inconsistenties slechts een kwestie van tijd. Dit is geen developersdetail. Dit is een informatiekwaliteitsprobleem.

Tot slot monitoring. Niet alleen een test na implementatie, maar voortdurende controle van wijzigingen. Vooral in grote sites kunnen een wijziging van het template, CMS-migratie, een nieuwe filtermodule of een frontend refactor stilletjes de markup op honderden pagina's beschadigen. Zonder regelmatige review kan zo'n probleem maanden onopgemerkt blijven.

Wat echt de kans vergroot dat AI citeert

Alleen de implementatie van Schema.org zorgt er niet voor dat een model de site gaat citeren. Dat zou een te eenvoudige relatie zijn. Citeerbaarheid neemt toe wanneer gestructureerde gegevens de content ondersteunen die concreet, betrouwbaar en goed in het onderwerp verankerd is. De markup heeft dan een versterkende rol: het vergemakkelijkt de identificatie van de bron, entiteiten, auteur en het onderwerp van de uiting.

De grootste voorsprong komt meestal door drie zaken. Ten eerste, een eenduidige beschrijving van de publicerende entiteit en de competenties van de auteur. Ten tweede, orde in entiteiten over de hele site heen, niet slechts op één pagina. Ten derde, content opgebouwd rond feiten, parameters, operationele definities en relaties tussen objecten, niet rond lege frasen. In zo'n omgeving stopt Schema.org met een SEO-toevoeging te zijn. Het wordt een laag die kennis ordent op een manier die handig is voor zoekmachines en taalmodellen.

Dat is precies wat implementaties die „bestaan” onderscheidt van implementaties die werken. De ene eindigt bij de validator. De andere helpen systemen te begrijpen wat er precies op de pagina staat, wie daarvoor verantwoordelijk is en wanneer het de moeite waard is het materiaal als bron voor een antwoord te gebruiken.

Schema.org i dane strukturalne dla AI: casestudy van een implementatie na een mislukte „groene” audit

Het volgende geval betreft een klant die op papier het onderwerp gestructureerde gegevens afgesloten had. In de praktijk begonnen de problemen pas toen. Het was een middelgrote webwinkel met diagnostische apparatuur en educatieve content rond een paar hoofdgebieden: holters, oximeters en polsmeters, bloeddrukmeting en accessoires, onder andere ECG-elektroden. De site had verkeer, een uitgebreide catalogus en een blog. Wat ontbrak was een consistente gegevenslaag waaruit een betrouwbaar beeld van entiteiten opgebouwd kon worden.

Korte context van de situatie

De klant kwam niet omdat hij „geen schema” had, maar omdat hij ondanks de implementatie geen verbetering zag in de zichtbaarheid van deskundige content en niet vaker zijn materialen terugzag in door AI-systemen gegenereerde antwoorden. Het interne team was ervan overtuigd dat technisch alles in orde was. De plugin genereerde JSON-LD, Google meldde geen massale kritieke fouten en af en toe verschenen er rich results.

Het probleem was meer alledaags. De site was over meerdere jaren in drie losse sporen gegroeid: e‑commerce, blog en een adviesdatabase gemaakt door de klantenservice. Elk van deze gebieden had een ander template, een andere manier van productbeschrijving en eigen redactionele gewoontes. Toen het idee van „optimalisatie voor AI” opkwam, werd er nog een laag markeringen toegevoegd zonder eerdere afhankelijkheden op te ruimen.

Het probleem van de klant

Op zakelijk niveau noemde de klant drie symptomen.

• De adviesartikelen trokken long‑tail verkeer aan, maar leidden de gebruiker zelden door naar categorieën of producten.

• Kategoripagina’s hadden thematisch potentieel, maar werden vooral als lijsten geïnterpreteerd, zonder sterker deskundig kader.

• Na de implementatie van nieuwe gestructureerde gegevens begonnen sommige adressen te rouleren in de resultaten, en een paar belangrijke subpagina’s verloren stabiliteit na een template‑update.

De klant verwachtte een eenvoudige bevestiging dat er „meer schema toegevoegd moest worden”. Na de eerste beoordeling was duidelijk dat dat niet het geval was. Een overvloed aan markeringen was zelfs deel van het probleem.

Analyse van de situatie

We begonnen met een audit, maar niet in de klassieke vorm van een foutlijst van een validator. We analyseerden 80 URL’s van vier types: categorieën, producten, adviesartikelen en auteursprofielen. Het doel was te controleren of de gestructureerde gegevens genoeg hielpen om de logica van de site te reconstrueren zonder de volledige paginatekst te lezen.

Op dat punt kwamen vier problemen aan het licht die bij een oppervlakkige controle niet zichtbaar waren.

1. Verschil tussen redactionele en technische laag

Artikelen hadden bijgewerkte titels en intro’s, maar JSON-LD haalde oudere versies uit een technisch veld in het CMS. Daardoor bestond hetzelfde materiaal in twee varianten van de kop. Voor de gebruiker een kleinigheid. Voor systemen die signalen uit verschillende lagen vergelijken, niet.

2. Valse koppelingen tussen entiteiten

Op enkele kategoriapagina’s koppelde de automatiseringsmodule een willekeurige blogauteur als auteur van de hele subpagina. De reden was banaal: het categorie‑template had een deel van de logica van het artikelmodule geërfd. Hierdoor leek de verkoop‑informatiepagina in de data op een publicatie van een auteur die die pagina in werkelijkheid niet had gemaakt.

3. Duplicatie van productobjecten

Productkaarten haalden gegevens uit het winkelbestand, terwijl de front‑end tegelijkertijd een tweede Product‑object genereerde met uitgeklede gegevens beschikbaar tijdens renderen. Twee namen, twee beschrijvingen, soms twee model‑identificaties. Geen enkele validator zag dit als een ramp, maar semantisch was het een typische botsing van bronnen van waarheid.

4. Geen consistentie tussen ondersteunende content en kategoriapagina’s

Het meest interessante probleem betrof de kennislaag. De klant had goede vergelijkende en instructieve artikelen, maar in de gestructureerde gegevens was geen spoor dat deze materialen specifieke catalogusgebieden ondersteunden. Content over het monitoren van vitale parameters bestond naast productcategorieën in plaats van samen te werken aan een gemeenschappelijk thema.

Wat eerder misging

Het was geen implementatie die vanaf het begin slecht was uitgevoerd. Eerder een implementatie die zonder controle gegroeid was. Eerst verscheen een SEO‑plugin, daarna een reviewmodule, vervolgens een productextensie en uiteindelijk een handmatig toegevoegd script voor geselecteerde deskundige content. Elk van die lagen maakte op zichzelf zin. Samen vormden ze een lappendeken.

De klant had eerder ook een snelle technische audit laten doen. Hij kreeg een rapport met de mededeling dat de meeste pagina’s „correct” waren en dat de rest cosmetisch te verbeteren viel. Formeel was dat waar. Alleen controleerde de audit niet of de markeringen overeenkwamen met de daadwerkelijke informatiearchitectuur en of ze AI‑systemen hielpen feiten uit verschillende delen van de site te koppelen.

Hoe we het hebben aangepakt

We begonnen niet met code. Eerst maakten we een kaart van entiteiten en relaties voor de hele site. Niet om een academisch document te creëren, maar om vast te stellen welke entiteiten echt belangrijk waren vanuit zichtbaarheid en citeerbaarheid.

We kwamen tot drie werkende lagen:

1. Statische entiteiten: organisatie, auteurs, thematische secties.

2. Operationele entiteiten: categorieën, producten, artikelen, aankoopgidsen.

3. Gebruikrelaties: wat verklaart wat, wat hoort bij welk gebied, welk materiaal ondersteunt welke categorie en waar redactionele koppelingen moeten verschijnen.

Dit was een belangrijk moment in de samenwerking, want voor het eerst keken contentteam, SEO en developers naar de site in dezelfde taal. Voorheen begreep iedereen „structuur” anders. De redactie zag thema’s, ontwikkelaars templates en SEO specialisten types tags.

Stappenplan

Stap 1. Eén bron van waarheid voor data vaststellen

We begonnen met het uitschakelen van duplicerende generators. Het was geen spectaculaire wijziging, maar wel cruciaal. Voor producten werd het catalogussysteem de bron van waarheid, voor auteurs de toegewijde profielen in het CMS, en voor publicatie‑ en wijzigingsdatums de redactionele velden in plaats van de technische fallback uit het template.

Dat vereiste een paar ongemakkelijke beslissingen. Bijvoorbeeld: sommige historische posts hadden onvolledige auteursprofielen. In plaats van het „voor later” te laten, vulde de klant die handmatig aan, want zonder dat was het niet mogelijk publicaties consequent te koppelen aan de personen die verantwoordelijk zijn voor de content.

Stap 2. Herbouw van de logica van kategoriapagina’s

In dit project ging de meeste inspanning niet naar productpagina’s, maar naar categorieën. Daar zat de grootste kloof tussen potentieel en uitvoering. Pagina’s zoals bloeddrukmeting of oximeters en polsmeters hadden relevant verkeer, maar bouwden geen duidelijke brug tussen informatieve en transactionele intentie.

We breidden ze niet uit met kunstmatige tekstblokken. In plaats daarvan ordenen we de secties: korte beschrijving van toepassingen, het scala aan verschillen tussen apparaattype, antwoorden op veelgestelde vragen en natuurlijke verwijzingen naar handleidingen. Pas daarna pasten we de manier van markeren aan zodat uit de data bleek dat het geen louter productlijst was.

Stap 3. Koppeling van educatieve laag met de catalogus

De klant had al materiaal dat echte vragen van gebruikers beantwoordde. Het probleem was dat het naast de catalogus bestond, niet erin verweven. We voerden daarom de regel in dat elk sterk artikel duidelijk context moet aangeven, product‑ en thematisch. Niet door agressief linken, maar als een zinvolle overgang.

Bijvoorbeeld: content over het monitoren van hartfunctie leidde naar de holtersectie, en materialen over verbruiksaccessoires naar relevante pagina’s, zoals ECG‑elektroden. Vanuit SEO verbeterde dit de thematische clustering. Vanuit AI‑perspectief was belangrijker dat de site meer logisch aangrenzende informatie begon te creëren.

Stap 4. Beperken van automatisch gegenereerde velden

Hier was weerstand, omdat de eerdere benadering ervan uitging dat hoe meer attributen, hoe beter. In de praktijk verwijderden we een deel van de semi‑automatische beschrijvingen en velden die werden gevuld op basis van uitgeklede feedgegevens. We lieten minder staan, maar dan nauwkeuriger.

Dit was vooral belangrijk bij technische producten. Als de modelbeschrijving erg mager was, probeerden we die niet met een automatische invulling in de gestructureerde data te „redden”. Eerst verbeterden we de tekst op de pagina, pas daarna ordenden we de technische laag.

Stap 5. Implementatie van post‑publicatie controles

De meest praktische verandering was organisatorisch. In plaats van een eenmalige implementatie ontstond een eenvoudige checklist voor de redactie en de developer die wijzigingen aan templates publiceert. Die omvatte overeenstemming van titel, auteur, datums, aanwezigheid van koppelingen naar bovenliggende pagina’s en controle of een nieuw front‑module geen extra objecten genereert.

Dat klinkt niet spectaculair, maar juist dit stadium beperkte latere regressies. Voorheen kwam het probleem na elke grotere frontend‑update terug.

Moelijkheden onderweg

Het project verliep niet vlekkeloos. Twee gebieden gaven de meeste problemen.

Oude content met onduidelijk auteurschap

Sommige gidsen waren in teamverband gemaakt, andere jaren later door andere personen bewerkt. De klant wilde orde bewaren, maar tegelijk geen expertise toekennen aan iemand die alleen technisch de post had bijgewerkt. Uiteindelijk kozen we voor een model waarin de inhoudelijke auteur en de redactionele update in het publicatieproces gescheiden worden, in plaats van het alleen met een tag te proberen te „repareren”.

Conflict tussen sales en content

De verkoopafdeling wilde dat categorieën commerciëler werden. De redactie verdedigde het informatieve deel. Toen we content met de catalogus begonnen te koppelen, bestond de vrees dat gidsen in aanbodpagina’s zouden veranderen. Er moest een grens worden vastgesteld. In de praktijk werkte het beste de aanpak waarbij elke categorie een paar basisvragen van de gebruiker beantwoordt, maar niet pretendeert een artikel te zijn. Dat stelde beide partijen gerust.

Oplossingen die echt werkten

Na een paar weken werd duidelijk dat niet alle veranderingen evenveel gewicht hadden. Drie elementen hadden het sterkste effect.

• Het verwijderen van conflicterende datagenerators en het ordenen van bronnen.

• Het versterken van kategoriapagina’s als thematische knooppunten in plaats van louter lijsten.

• De nauwe koppeling van educatieve content met catalogusgebieden, zonder kunstmatig volplaatsen van links.

De klant was verrast dat een deel van het effect voortkwam uit redactionele wijzigingen en niet uitsluitend uit technische aanpassingen. De gestructureerde gegevens begonnen pas te werken toen ze iets getrouw konden beschrijven.

Resultaten

Er was geen enkele spectaculaire sprong van de ene op de andere dag. De effecten kwamen geleidelijk, wat ik betrouwbaarder vind dan een plotselinge „x3 na implementatie”.

In ongeveer drie maanden na het ordenen van de belangrijkste templates zag de klant:

• stabilisatie van de zichtbaarheid voor sommige artikelen die eerder na elke grote wijziging in de site roteerden,

• betere overgangen van informatieve content naar productcategorieën, vooral op het gebied van holters en bloeddrukmeting,

• toename van bezoeken aan kategoriapagina’s vanuit mixed‑intent zoekopdrachten, waar de gebruiker niet alleen een product zocht maar ook uitleg over verschillen of toepassingen,

• minder anomalieën in de indexering na frontend‑implementaties, omdat nieuwe fouten sneller werden opgemerkt.

Op kwalitatief vlak merkte de klant nog iets op: materialen verschenen vaker in overzichten en antwoorden van AI‑tools als ondersteunende bronnen bij vragen over toepassingen, verschillen tussen apparaattype en basisparameters voor keuze. Dat is niet zo precies te meten als klikken in Search Console, maar je kon een duidelijke verandering zien in de manier waarop content werd aangehaald.

Praktische conclusies

Dit project liet goed zien dat bij werk aan gestructureerde gegevens voor AI de grootste fout is alleen naar de markup te kijken. Het probleem zit vaak eerder: in de informatiearchitectuur, verspreide gegevensbronnen, inconsistent auteurschap en zwakke koppeling van content met de catalogus.

Een tweede observatie is nog alledaagser. Kategoriapagina’s worden onderschat. In dit geval gaven niet de productpagina’s of de blog de grootste semantische verbetering, maar het ordenen van de kategoriereeksen en hun relaties met handleidingen. Zij werden het contactpunt tussen informatieve en koopintentie.

Een derde punt: een groene score in een validator zegt weinig over de kwaliteit van de implementatie. Je kunt syntactisch correct zijn en tegelijk systemen een tegengesteld beeld van de site geven. In projecten gericht op citeerbaarheid door AI is het beter de vraag te stellen of je aan de hand van de data en structuur kunt begrijpen wie publiceert, waarover wordt gepubliceerd en hoe individuele bronnen zich tot een groter thema verhouden.

In dit geval luidde het antwoord voor de implementatie: niet helemaal. Na de wijzigingen werd het: ja, en dat zonder kunstmatige lagen toe te voegen. Daarom zie ik dit project meer als het ordenen van een informatiemodel dan als een klassieke „schema‑implementatie”. Code was slechts de laatste stap.

FAQ: Schema.org en gestructureerde gegevens voor AI

Helpen gestructureerde gegevens AI-modellen ook als een pagina geen rich results krijgt in Google?

Ja. En vaker dan veel website-eigenaren denken. Rich results zijn slechts het zichtbare effect voor sommige paginatypes en sommige zoekopdrachten. Het ontbreken van een uitgebreid resultaat betekent niet dat de semantische laag nutteloos is.

Antwoordgenererende systemen beoordelen een pagina niet alleen op basis van of deze sterren, FAQ's of kruimelpad in de resultaten heeft. Voor hen is het belangrijker of snel kan worden vastgesteld wie de uitgever is, wat het onderwerp van het document is, op welk object de inhoud betrekking heeft en of feiten aan andere signalen op de site kunnen worden gekoppeld. Dat is precies wat goed ontworpen gestructureerde gegevens doen.

In de praktijk is dit vooral zichtbaar bij specialistische content. Een artikel dat diagnostische oplossingen vergelijkt, krijgt misschien geen visueel effect in de SERP, maar kan desondanks makkelijker door AI worden gebruikt als hulpmiddel bij vragen over verschillen, toepassingen of het kiezen van een apparaat. Hetzelfde geldt voor productcategorieën. Secties zoals Holter‑apparaten of oksymeters en polsmeters kunnen semantisch winnen, zelfs als ze geen spectaculaire rich snippets laten zien.

De meest voorkomende fout is de effectiviteit van schema uitsluitend te meten aan de hand van het rapport „wyników z elementami rozszerzonymi”. Dat is een te smal perspectief. Als na implementatie de consistentie van indexering verbetert, het aantal verkeerde interpretaties van het paginatype afneemt en inhoud vaker in synthese‑antwoorden verschijnt, vervult de markup zijn functie, zelfs zonder visueel effect in het klassieke Google.

Hoe implementeer je Schema.org op een meertalige site zodat je entiteiten niet door elkaar haalt tussen taalversies?

Dit is een van die gebieden waar een technisch correcte site semantisch kan instorten. Het probleem gaat niet over het vertalen van eigenschappen. Het gaat om de identiteit van entiteiten.

Als een organisatie, auteur, product of artikel in meerdere taalversies bestaat, moet je twee zaken scheiden: het wezen en de lokale weergave ervan. Het object zelf kan hetzelfde zijn, maar de pagina waarop het beschreven staat niet. In de praktijk betekent dit dat je geen willekeurige, onafhankelijke identifiers moet aanmaken alleen omdat de taal in de URL is veranderd. Zo'n beslissing leidt vaak tot kunstmatige vermenigvuldiging van auteurs, producten en publicaties.

Voor globale entiteiten werkt een model met één vast logisch identifier en lokale pagina‑URLs goed. Voor documentpagina's, zoals concrete artikelen of categorielandingpages, moet je echter aparte URL's voor taalversies behouden en duidelijke relaties ertussen. Dat is vooral belangrijk wanneer het aanbod in verschillende landen niet identiek is of wanneer productbeschrijvingen inhoudelijk onafhankelijk worden ontwikkeld.

Een andere kwestie is automatische vertalingen. Als je content massaal vertaalt en de schema oude of gedeeltelijk onvertaalde waarden oppikt, krijgt het systeem een signaal van chaos. Je komt sites tegen waar de kop in het Pools is, de meta description in het Engels en de organisatienaam in drie varianten voorkomt. Zo'n rommeltje ondermijnt de betrouwbaarheid van het hele document.

Bij internationale implementaties werken aparte validatieregels voor elk marktsegment goed. Anders is het moeilijk situaties op te sporen waarin de Poolse versie van de categorie bloeddrukmeting een correcte beschrijving heeft, terwijl het equivalent in een andere taal een leeg of fout object erft. Dit is geen vertaalkwestie, maar een kwestie van de integriteit van de kennisgrafiek in de gehele site.

Kun je overdrijven met het gebruik van @id en linked data? Wanneer begint een uitgebreid netwerk van relaties schadelijk te worden?

Ja. Het idee om relaties op te bouwen is terecht, maar overmatig datamodelleren verandert heel gemakkelijk in een structuur die later door niemand wordt beheerd. In theorie is alles verbonden. In de praktijk is een deel van de relaties kunstmatig, een deel heeft geen grondslag in de content en een deel leidt naar entiteiten die nooit goed zijn beschreven.

Drie situaties zijn het meest problematisch. Ten eerste het creëren van entiteiten alleen omdat schema het toelaat. Als een pagina een fabrikant van een apparaat in één zin noemt, heeft het niet altijd zin om op elke subpagina een apart uitgebreid object voor dat merk op te bouwen. Ten tweede het automatisch linken van alles met alles. Artikel, product, categorie, tag, auteur, afdeling, subafdeling, FAQ, afbeelding, organisatie, kruimelpad — je kunt het allemaal koppelen, maar de vraag is waarom. Ten derde relaties zonder onderhoud. Een URL verandert, een auteursprofiel verdwijnt, een template wordt herbouwd en plots wijzen de helft van de verwijzingen naar verouderde entiteiten.

De goede praktijk is eenvoudiger: modelleer alleen die relaties die daadwerkelijk helpen het document te begrijpen. Als een handleiding gaat over de compatibiliteit van accessoires, kan het logisch zijn deze te koppelen aan de sectie over ECG‑elektroden. Als de productpagina een monitoringapparaat beschrijft, is het zinvol deze te plaatsen binnen een overkoepelend thematisch domein. Als je echter tientallen extra objecten begint te bouwen zonder controleproces, wordt schema moeilijker te onderhouden dan de content zelf.

De beste implementaties imponeren niet door het aantal entiteiten. Ze imponeren doordat de relaties echt, reproduceerbaar en bestand tegen veranderingen in de site zijn.

Hoe test je gestructureerde gegevens met het oog op AI, aangezien klassieke validators de semantische kwaliteit niet tonen?

Je moet verder gaan dan de simpele test „czy kod jest poprawny”. Dat is niet genoeg. Een zinvolle beoordeling moet technische, redactionele en contextuele controle combineren.

Begin met een omgekeerde test: kan iemand die de site niet kent op basis van alleen de JSON-LD beantwoorden wat het document is, wie het heeft gepubliceerd, wanneer het is bijgewerkt, welke entiteit wordt beschreven en met welk deel van de site het is verbonden. Als dat niet lukt, heb je het eerste signaal dat de markup formeel maar weinig bruikbaar is.

Het tweede niveau is het vergelijken van lagen. Kop, intro, H2‑secties, SEO‑titel, kruimelpad, interne linking en gestructureerde gegevens zouden hetzelfde verhaal moeten vertellen. Als het artikel over de keuze van een apparaat gaat, maar de schema een meer algemene informatiesite suggereert zonder duidelijk onderwerp, kan AI het document te breed of te oppervlakkig interpreteren.

Het derde niveau is testen met vragen. Het is nuttig te controleren bij welke vragen een bepaalde inhoud daadwerkelijk door AI‑tools wordt opgehaald of samengevat. Het gaat niet om een eenmalig experiment, maar om een reeks queries met verschillende intenties: definitievragen, vergelijkingsvragen, aankoopvragen en procedurele vragen. Als een pagina over medische producten begint te verschijnen bij vragen over toepassing, verschillen of compatibiliteit, betekent dat dat de semantische laag beter werkt dan voorheen.

De meest praktische audits combineren daarnaast loganalyse, screenshots van de gerenderde DOM en monitoring van veranderingen na frontend‑deploys. In grote sites komen daar de echte problemen aan het licht: vertraagde scriptlading, velden die verdwijnen na componentwijziging, verouderde waarden na data‑import. Dat laat het groene lampje in een testtool niet zien.

Zijn gestructureerde gegevens die via JavaScript worden gegenereerd even goed als die in de HTML vanaf het begin zijn ingebed?

Dat hangt af van de rendermethode en de stabiliteit van de implementatie. Het feit dat JSON-LD via JavaScript wordt toegevoegd is op zich geen fout. Het probleem ontstaat wanneer het script met vertraging laadt, wordt geblokkeerd, afhankelijk is van onstabiele front‑enddata of andere waarden genereert dan de server‑laag.

In content‑ en katalogsites zijn oplossingen het meest betrouwbaar waarbij sleutelentiteiten aan de serverzijde worden aangemaakt of in een voorspelbare hybride render worden opgebouwd. Daardoor krijgen zowel crawler als tussenliggende systemen direct een compleet beeld. Als alles berust op het dynamisch samenstellen van componenten, neemt het risico toe dat één verandering in de applicatie de gestructureerde gegevens op honderden URL's beschadigt.

Bijzonder kwetsbaar zijn subpagina's met uitgebreide filters, varianten en voorraadstatussen. De front-end kan de gebruiker één productversie tonen, terwijl de schema op basis van een verouderde app‑state een andere genereert. Dit is een veelvoorkomend probleem in winkels die in fases zijn gegroeid. Daarna rijst de vraag waarom het systeem de productomschrijving niet vertrouwt.

Als je de keuze hebt, houd de belangrijkste objecten zo dicht mogelijk bij de data‑bron en zo ver mogelijk van fragiele interface‑logica. Dit geldt vooral voor producten, auteurs en pagina's met hoge zakelijke waarde. Voor secties zoals Holters of bloeddrukmetingen betekent stabiliteit meer dan „sprytne” alles in de browser genereren.

Hoe ga je met schema om voor content die snel veroudert, zoals modelvergelijkingen, ranglijsten en seizoenspagina's?

Het grootste probleem ligt hier niet in het soort schema, maar in het beheer van actualiteit. Vergelijkende en rangschikkende content worden snel een historisch spoor van de vroegere staat van het aanbod, en gestructureerde gegevens versterken dat probleem nog als niemand ze bijwerkt.

Eerst moet je bepalen welke elementen duurzaam zijn en welke variabel. Het onderwerp van de vergelijking kan evergreen zijn, maar apparaatmodellen, specificaties, beschikbaarheid en aanbevelingen niet. In de praktijk is het verstandig het skelet van de content te scheiden van secties die regelmatige revisie vereisen. In de schema moeten alleen die informatie terechtkomen die daadwerkelijk wordt onderhouden.

Als je vergelijkingen publiceert over diagnostische apparaten, probeer dan niet alles te modelleren alsof elke pagina eeuwig actueel is. Het is beter duidelijk de datum van de laatste inhoudelijke update te tonen en verklaringen te beperken tot zekere elementen. Dit geldt ook voor pagina's die naar specifieke categorieën verwijzen, bijvoorbeeld oksymeters en polsmeters. Wanneer het aanbod verandert, moet de relatie tussen content en catalogus nog steeds logisch zijn.

Een goede praktijk is het invoeren van een redactioneel SLA voor updates van productafhankelijke content. Niet elk bedrijf doet dat, en dan zegt de schema het één, de ranking iets anders en de productpagina weer iets anders. Bij vergelijkend materiaal bouw je vertrouwen niet op door het aantal properties, maar door onderhoudsdiscipline. In expertprojecten is dat vaak belangrijker dan de initiële implementatie zelf.

Meest voorkomende fouten bij het implementeren van Schema.org en gestructureerde gegevens voor AI

De meeste problemen ontstaan niet door het ontbreken van markeringen, maar door verkeerde implementatiebeslissingen. In de praktijk zie ik zelden sites die „helemaal geen schema” hebben. Vaker kom ik implementaties tegen die formeel wel bestaan, maar semantisch meer schade dan nut opleveren. Hieronder staan fouten die het vaakst leiden tot verloren tijd, verlies van datavertrouwen of simpelweg tot slechter gebruik van content door zoekmachines en AI-systemen.

1. Schema behandelen als een aparte laag, losgekoppeld van de informatiearchitectuur

Dit is een van de duurste fouten, omdat het meestal pas na maanden aan het licht komt. Het team implementeert gestructureerde gegevens aan het einde van het proces, pas nadat templates, content en categorie-logica klaar zijn. Daardoor beschrijft het schema wat „technisch beschikbaar is”, en niet wat daadwerkelijk als een zinvol kennismodel beschreven zou moeten worden.

Waarom gebeurt dit zo vaak? Omdat veel bedrijven verantwoordelijkheden scheiden. Content werkt aan onderwerpen, SEO aan zichtbaarheid, developers aan componenten, en gestructureerde gegevens worden afgevinkt als een technische checklist. In zo’n model waakt niemand erover of entiteiten en relaties overeenkomen met de werkelijke logica van de site.

De consequenties zijn heel praktisch. Een categorie lijkt voor een mens op een belangrijk thematisch knooppunt, maar in de data blijft het een gewone lijstpagina. Een vergelijkend artikel is inhoudelijk sterk, maar het schema toont niet met welk deel van het aanbod het verbonden is. Daarna vraagt de site-eigenaar zich af waarom content de verkoopsecties niet versterkt en geen samenhangend thema opbouwt.

Hoe voorkom je dit? Schrijf eerst uit welke type pagina’s echt zakelijke en semantische betekenis hebben: categorieën, handleidingen, vergelijkingen, productpagina’s, auteursprofielen. Ontwerp pas daarna de markup. Niet andersom.

Uit ervaring: als de informatiearchitectuur zwak is, onthult schema dat alleen maar. Het lost de chaos niet op. In enkele projecten leverde niet „het toevoegen van nieuwe properties” de grootste verbetering, maar het ordenen van de relaties tussen handleidingen en catalogussecties, bijvoorbeeld rond gebieden zoals holters.

2. Schema-typen kiezen op basis van de naam van de tag, niet op basis van de feitelijke functie van de pagina

Deze fout komt meestal voort uit overijverigheid of het kopiëren van andermans implementaties. Iemand ziet dat een concurrent content aanmerkt als FAQPage, HowTo, TechArticle of Product, en doet hetzelfde, hoewel het document een andere functie heeft. Formeel is dat soms nog te verdedigen. Semantisch echter niet.

Het komt veel voor omdat teams op zoek zijn naar eenvoudige antwoorden: „welk schema-type geeft het beste resultaat?”. Maar zo’n denksprong leidt tot slechte beslissingen. Een categoriepagina begint zich voor te doen als een handleiding, een redactioneel artikel gaat eruitzien als een productpagina, en een vergelijking wordt zo algemeen aangeduid dat het zijn specificiteit verliest.

Gevolgen? AI en zoekmachines krijgen een onduidelijk signaal over wat het document eigenlijk is. Dat verkleint de kans dat de pagina gebruikt wordt voor meer concrete zoekopdrachten: vergelijkend, procedureel of aankoopgericht met informatieve componenten. In de praktijk wordt zo’n document vaak te breed geclassificeerd en verliest het van content met minder uitgebreide code maar een beter gekozen type.

Hoe voorkom je deze fout? Begin met de vraag: wat is de primaire rol van deze pagina vanuit het perspectief van de gebruiker en de zoekmachine? Kies pas daarna het type en de properties. Als je twijfelt tussen een „ambitieuzer” en een „juistiger” type, wint meestal het tweede.

Praktische observatie: de slechtste implementaties zijn niet die met eenvoudige schema’s, maar die overgeïnformeerd zijn. Beter een sober maar waarheidsgetrouw model dan een indrukwekkende set klassen zonder dekking in de content.

3. Het markeren van gegevens die het bedrijf niet operationeel beheert

Dit probleem komt vooral vaak voor in e-commerce, catalogi en vergelijkingssites. Het team wil „schema maximaal benutten” en labelt parameters, beschikbaarheid, technische kenmerken, compatibiliteit, soms zelfs elementen die uit meerdere bronnen komen en geen eenduidige eigenaar hebben.

Waarom gebeurt dit? Omdat de implementatie als een technische taak wordt gezien, en niet als een proces van datamanagement. Niemand vraagt wie deze informatie gaat bijhouden na wijzigingen in het ERP, CMS, de leveranciersfeed of na een update van de productbeschrijving.

Het resultaat is voorspelbaar. Na enkele weken gaat het schema zijn eigen leven leiden. Een andere versie van het model in de content, weer een andere in de specificatietabel, en nog een andere in JSON-LD. In gespecialiseerde sectoren is dit bijzonder risicovol, want afwijkingen op het niveau van technische parameters ondermijnen de betrouwbaarheid van de hele pagina.

Hoe voorkom je dit? Geef in de gestructureerde data alleen aan wat je redactioneel of systematisch onder controle hebt. Als een attribuut instabiel is, met vertraging wordt bijgewerkt of afhankelijk is van handmatige toevoegingen in meerdere systemen, beperk dan het bereik in plaats van iets te publiceren dat je later niet kunt waarborgen.

Uit de praktijk: veel problemen ontstaan bij uitgebreide medische en diagnostische categorieën. Teams willen erg veel markeren omdat het onderwerp parametrisch is. Zonder onderhoudsdiscipline ontstaat snel een rommel die de gebruiker niet meteen ziet, maar systemen wel.

4. Het negeren van conflicten tussen het SEO-team, de redactie en de developers

Dit is geen fout in de code, maar het saboteert implementaties regelmatig. Elke afdeling werkt volgens zijn eigen logica. SEO wil meer entiteiten en relaties, de redactie wil een eenvoudig publicatieproces, developers willen uitzonderingen en handmatige velden beperken. Als niemand gemeenschappelijke regels vastlegt, wordt schema het compromis van de slechtste soort.

Waarom gebeurt dit vaak? Omdat gestructureerde data eruitziet als een technisch element, denken bedrijven dat een ticket naar development volstaat. Later blijkt dat auteurs velden niet invullen, de redactie titels verandert zonder invloed op JSON-LD, en de frontend na een refactor bepaalde afhankelijkheden wegknipt.

De consequenties zijn organisatorisch kostbaar. Er ontstaat brandjes blussen na de implementatie, handmatige correcties, snelle omwegen en situaties waarin niemand weet waar een waarde precies vandaan komt. Dat verzwakt niet alleen de kwaliteit van de markup, maar vertraagt ook elke volgende wijziging op de site.

Hoe voorkom je dit? Stel een dataverantwoordelijke vast voor elke belangrijke eigenschap. Niet algemeen, maar concreet: wie is verantwoordelijk voor de auteur, wie voor de update-datum, wie voor de productnaam, wie voor de relaties tussen content en categorie. Zonder dat blijft schema altijd „iemand z’n en niemand z’n”.

Uit ervaring: de beste implementaties hebben een eenvoudige verantwoordelijkheidsmatrix, niet de meest uitgebreide code. Als dat ontbreekt, eindigt zelfs een goede start in regressie na de eerste grote templatewijziging.

5. Overmatig vertrouwen op plugins en "all-in-one" generators

Plugins helpen, maar maken vaak ook roekeloos. De site-eigenaar ziet de gegenereerde JSON-LD, de test slaagt en beschouwt het onderwerp als afgerond. Het probleem is dat automatische tools werken volgens een gemiddelde logica, terwijl een site die ambitie heeft om door AI citeerbaar te worden zelden een gemiddeld geval is.

Dit is een veelvoorkomende fout omdat plugins een reëel probleem oplossen: ze versnellen de start en nemen een deel van het technische werk weg. Het probleem ontstaat wanneer ze complexere contentmodellen, niet-standaard paginatypen of relaties tussen content en catalogus moeten afhandelen.

De gevolgen zijn subtiel maar ernstig. Alles lijkt syntactisch correct, maar belangrijke pagina’s krijgen een generiek model dat niets versterkt. Dit geldt vooral voor sites met sterke adviessecties rond onderwerpen zoals pulse- en zuurstofmeters, maar de generator behandelt ze als gewone listings of gewone posts.

Hoe voorkom je dit probleem? Gebruik plugins als basis, niet als strategie. Audit vervolgens welke paginatypen de standaardlogica moeten overschrijven, extra relaties nodig hebben of juist minder automatisering vereisen.

Praktische conclusie van audits: de meeste schade wordt niet door de plugin zelf veroorzaakt, maar door het ontbreken van besluitvorming over waar de plugin ophoudt nuttig te zijn. Op een gegeven moment moet je overstappen van „alles genereren” naar een gecontroleerd model.

6. Markeren van inhoud die inhoudelijk dun is in de hoop dat schema de waarde verhoogt

Dit is een zeer menselijke reflex. Een pagina scoort niet, verschijnt niet in AI-antwoorden, dus het team zoekt een technische manier om te verbeteren. Er worden gestructureerde gegevens toegevoegd, properties uitgebreid, relaties vastgelegd. Het probleem is dat zwak materiaal zwak blijft, maar nu beter beschreven.

Waarom gebeurt dit steeds weer? Omdat het implementeren van schema sneller is dan het herwerken van content. Het is makkelijker om markup toe te voegen dan om een deskundige alinea te verfijnen, een vergelijkingssectie uit te breiden of bronnen en context aan te vullen.

De gevolgen zijn teleurstellend. Het bedrijf investeert tijd in de technische laag, maar ziet geen evenredige verbetering. Er ontstaat de foute conclusie dat „schema niet werkt”, terwijl het echte probleem in de kwaliteit van de informatie ligt, niet in de markup zelf.

Hoe voorkom je dit? Beoordeel eerst of de pagina daadwerkelijk iets concreets bijdraagt: feiten, verschillen, parameters, instructies, een antwoord op een specifiek vraagstuk. Zo niet, dan heeft het markeren met een steeds rijker model meestal weinig zin.

Uit de praktijk: bij audits gericht op AI blijkt vaak dat de beste vooruitgang wordt geboekt door pagina’s die al redactionele waarde hadden. Schema ordent die voorsprong. Het creëert die niet uit het niets.

7. Geen prioritering van pagina's voor implementatie

Veel teams willen meteen volledige schema’s op „de hele site” uitrollen. Dat klinkt ambitieus, maar eindigt vaak in versnippering van het werk. In plaats van de belangrijkste templates en entiteiten af te ronden, rolt het bedrijf een gemiddelde oplossing uit over alles: archieven, tags, oude posts, dunne productpagina’s en pagina’s met marginale relevantie.

Dit gebeurt veel omdat schaal een gevoel van vooruitgang geeft. Het is makkelijk te laten zien dat „schema al op 12.000 URL’s draait”. Alleen is het aantal adressen geen maat voor semantische kwaliteit.

Het gevolg is eenvoudig: de belangrijkste zakelijke pagina’s blijven gaten houden, en het team verliest tijd aan het verfijnen van subpagina’s die weinig waarde hebben voor SEO of AI Search. Daarna ontbreken de middelen om sleutelcategorieën, producten en aankoopondersteunende content te vervolmaken.

Hoe voorkom je deze fout? Kies eerst pagina’s met de hoogste waarde: hoofdcategorieën, belangrijkste handleidingen, flagship-producten, auteursprofielen en secties die informatie-intentie met transactionele intentie kunnen verbinden. Schaal pas breder nadat deze zijn afgewerkt.

In reële projecten levert precies die volgorde het beste rendement op. Niet de meest omvangrijke implementatie, maar de best geprioriteerde.

8. Het niet detecteren van regressies na redesign, migratie of frontendwijzigingen

Dit is een klassiek probleem bij grote en middelgrote sites. Gestructureerde gegevens waren ooit correct geïmplementeerd, maar daarna komt een verandering in het framework, een nieuw listingcomponent, CMS-migratie of een herbouw van templates. Niemand plant semantische tests na de wijzigingen, omdat „schema toch al gedaan was”.

Waarom gebeurt dit zo vaak? Omdat post-implementatietests zich meestal richten op UX, performance en uiterlijk. De semantische laag zakt naar de achtergrond, vooral als die niet direct zichtbaar is voor de gebruiker.

De consequenties kunnen pijnlijk zijn. Relaties verdwijnen, objecten dupliceren, sommige velden stoppen met renderen, en sommige pagina’s krijgen lege of beschadigde JSON-LD. Wat erger is: het probleem blijft soms weken onopgemerkt omdat klassieke verkeersindicatoren traag reageren.

Hoe voorkom je dit? Neem gestructureerde data op in de QA-checklist bij elke grotere technische wijziging. Het gaat niet alleen om de validator. Je moet de overeenstemming met de content, de volledigheid van belangrijkste objecten en het ontbreken van nieuwe duplicaten controleren.

Uit ervaring: de meeste schade wordt niet aangericht door aanvankelijk slechte implementaties, maar door goede implementaties die later niet meer worden bewaakt. Na een half jaar ziet de site er moderner uit, maar is de datalaag semantisch zwakker dan voor de redesign.

9. Het bouwen van een te breed entiteitenmodel zonder reële toepassing

Deze fout is typisch voor teams die de theorie van linked data goed begrijpen, maar in de praktijk overdrijven. Als je entiteiten, relaties en identifiers kunt modelleren, ontstaat de verleiding om alles te beschrijven: elke afdeling, elke afbeelding, elke tag, elk module, elke microrelatie.

De reden is simpel: bij meer geavanceerde implementaties is het makkelijk volwassenheid te verwarren met omvang. Een uitgebreider model is niet altijd beter. Vaak is het alleen moeilijker te onderhouden.

Gevolgen? Het team verliest grip op welke entiteiten echt belangrijk zijn. Relaties worden kunstmatig, sommige objecten bestaan alleen omdat ze ooit toegevoegd zijn, en het bijwerken van één template vereist controle van tientallen afhankelijkheden. Dit verhoogt snel de onderhoudskosten en het fout risico.

Hoe voorkom je dit? Modelleer alleen die entiteiten en koppelingen die daadwerkelijk helpen het onderwerp van de pagina, de auteur, het beschreven object en de plaats in de site te begrijpen. Als een relatie niets bijdraagt aan de interpretatie van de pagina, is het meestal niet de moeite waard om die te onderhouden.

Praktische conclusie: de beste AI-gerichte implementaties zijn niet de grootste. Ze zijn het meest gedisciplineerd. Ze bevatten minder elementen, maar elk element heeft een reden.

10. Het meten van effecten uitsluitend via rich results en foutrapporten

Tot slot is er een analytische fout die de beoordeling van de hele implementatie vervormt. Het bedrijf kijkt alleen of er rich results verschijnen en of het aantal fouten in tools is gedaald. Als er geen spectaculaire verandering is, wordt het project als weinig succesvol gezien.

Dit gebeurt vaak omdat die metrics gemakkelijk beschikbaar zijn en zich goed laten presenteren in rapporten. Het probleem is dat ze te smal zijn, vooral als het doel betere interpretatie door AI, stabieler entiteitenherkenning en sterkere koppeling van content aan gebruikersintenties is.

De consequenties zijn beslissingsgewijs riskant. Een goede implementatie wordt ondergewaardeerd omdat het geen „zichtbaar vuurwerk” opleverde, of omgekeerd: een slechte implementatie krijgt een positieve beoordeling omdat formeel geen fouten zichtbaar zijn. In beide gevallen trekt het bedrijf de verkeerde conclusie en neemt het verdere misplaatste beslissingen.

Hoe ga je hier verstandiger mee om? Beoordeel ook: stabiliteit van paginatypes na technische wijzigingen, consistentie van gegevens tussen templates, kwaliteit van de overgangen tussen content en transactionele secties, zichtbaarheid voor gemengde zoekopdrachten, frequentie van aanhalingen in synthetische antwoorden en samenhang in de interpretatie van belangrijke sitegebieden, bijvoorbeeld secties die met bloeddrukmetingen te maken hebben.

Uit auditpraktijk: als na implementatie het aantal semantische afwijkingen daalt, de stabiliteit van sleutel-URL’s toeneemt en het logische „buurschap” van content verbetert, is dat meestal een beter signaal dan een enkele stijging van rich results.

Wat de meeste mislukte implementaties gemeen hebben

De gemeenschappelijke deler is eenvoudig: bedrijven proberen betekenis met code op te lossen. Gestructureerde gegevens werken echter goed alleen als ze de laatste stap zijn van een geordend informatiemodel, en niet een pleister op redactionele, technische en organisatorische chaos.

Als ik één praktische regel uit klantprojecten moest aanwijzen, zou het deze zijn: vraag niet eerst „welke schema moet ik toevoegen”. Controleer eerst of de site echt één stem spreekt op het niveau van content, entiteiten, auteurschap, categorieën en databronnen. Pas dan begint de markup ten voordele van SEO, GEO en citeerbaarheid door AI te werken.

Mythen over Schema.org en gestructureerde data voor AI die regelmatig goede implementaties verpesten

Het grootste probleem bij gestructureerde data is niet het gebrek aan tools of documentatie. Het probleem is dat er rond Schema.org veel vereenvoudigingen zijn ontstaan. Een deel daarvan komt voort uit vroegere SEO-praktijken, een deel uit beloften van plugins, en een deel uit het foutief overdragen van de logica 'voor rich results' naar het domein van AI Search. Daardoor implementeren bedrijven vaak syntactisch correcte markup, maar gebaseerd op foutieve aannames.

Hieronder staan de mythen die ik het vaakst tegenkom bij projecten gericht op zichtbaarheid in Google, AI Overview, Perplexity, Gemini of ChatGPT. Elk ervan betreft een ander gebied en leidt tot een ander type beslissingsfout.

Mythe 1. „Hoe meer schema‑typen op de pagina, hoe beter voor AI”

Deze overtuiging komt meestal voort uit een zeer eenvoudige associatie: als gestructureerde data de machine helpen de pagina te begrijpen, zou een groter aantal types en eigenschappen een beter resultaat moeten geven. Zo'n denkwijze is comfortabel, omdat het semantisch werk reduceert tot het mechanisch toevoegen van steeds meer objecten.

In de praktijk is dit een van de meest voorkomende redenen waarom een site overladen raakt met onnodige markup. De site begint alles tegelijk te beschrijven: de pagina, het artikel, de organisatie, meerdere varianten van ondersteunende entiteiten, afgeleide entiteiten en soms zelfs elementen die niets toevoegen aan de interpretatie van het document. AI beloont niet de hoeveelheid data op zich. Het werkt beter met een compact maar eenduidig model.

De realiteit van de sector is veeleisender. Het gaat minder om de breedte van de implementatie en meer om de informatieve bruikbaarheid. Als je op één subpagina vijf slecht onderbouwde objecten plaatst, neemt het risico op conflicten, duplicatie en vervaging van de hoofdboodschap toe. Dit geldt vooral voor secties die content en verkoop combineren, waar je snel kunt doorslaan in het beschrijven van relaties alleen omdat het technisch mogelijk is om ze te genereren.

Uit ervaring: de beste implementaties zijn zelden de meest uitgebreide. Meestal winnen die waarbij iemand bewust van de helft van de ideeën afzag. Als een object niet helpt beter te beantwoorden op de vraag "wat is deze pagina en wat is de primaire entiteit", is het meestal niet de moeite waard om het te behouden.

Mythe 2. „AI begrijpt de tekst toch al, dus schema is tegenwoordig ondergeschikt”

De oorsprong van deze mythe is vrij duidelijk: taalmodellen imponeren door hun begrip van natuurlijke taal, dus veel mensen veronderstellen dat expliciet gedefinieerde data minder relevant worden. Dat klinkt modern, maar is in de praktijk een te verstrekkende vereenvoudiging.

Een model kan tekst interpreteren, maar dat betekent niet dat het ambiguïteit waardeert. Hoe specialistischer het onderwerp, hoe meer vergelijkbare begrippen, naamsvarianten, parameters en afhankelijkheden, des te groter de waarde van expliciete ordening van informatie. Gestructureerde data vervangen geen content, maar verkleinen het risico op verkeerde interpretatie.

In echte implementaties is dit vooral zichtbaar waar een site met technische of specialistische entiteiten werkt. Als een document een apparaat, procedure, deskundige auteur en organisatie beschrijft, is de narratieve tekst niet altijd voldoende om snel vast te stellen wat het hoofdonderwerp van de pagina is en wat slechts context is. Goed ontworpen markup ordent dit probleem.

Praktische observatie: waar bedrijven afzien van het verfijnen van gestructureerde data met het argument "AI leest het er zelf wel bij", neemt meestal het aantal inconsistenties tussen secties van de site toe. En juist die inconsistentie, niet het ontbreken van een enkele markup, verlaagt meestal de kans dat content als antwoordbron wordt gebruikt.

Mythe 3. „Schema.org is vooral voor Google, niet voor ChatGPT, Gemini of Perplexity”

Deze overtuiging is een overblijfsel uit de tijd dat gestructureerde data vooral met uitgebreide zoekresultaten werden geassocieerd. Veel site-eigenaren kijken nog steeds naar schema door de klassieke SEO‑bril: sterren, breadcrumbs, prijzen, FAQ. Omdat er geen garantie is voor een zichtbaar effect in de modelinterface, beschouwen ze het onderwerp als minder relevant.

Dat is een vergissing, want het verwart twee verschillende niveaus. Het ene niveau is de presentatie van een resultaat. Het andere niveau is de kwaliteit van het inkomende signaal waaruit het systeem entiteiten en relaties opbouwt. Generatieve modellen hoeven 'schema niet te tonen' om te profiteren van gestructureerde data. Ze gebruiken de beter beschreven kennisstructuur over de site en de entiteit.

De marktrealiteit is dat AI-systemen op meerdere lagen steunen: content, links, reputatie van de bron, consistentie van entiteiten, documentstructuur en semantische signalen. Schema is niet het enige element, maar vaak een van de schoonste. Zeker wanneer een site geïnterpreteerd moet worden als een betrouwbare kennisbron binnen een specifieke specialisatie, en niet als een verzameling losse artikelen.

In content‑en‑salesprojecten is dit heel duidelijk zichtbaar. Als een site de relaties tussen educatieve bronnen en productsecties ordent, kunnen modellen vaker niet alleen één document lezen, maar het hele domein van expertise begrijpen. Dat is belangrijker dan kortetermijndenken of er een bepaald versiersel in de resultaten verschijnt.

Mythe 4. „Elke pagina moet het meest precieze, meest gespecialiseerde type hebben”

Deze mythe ontstaat meestal in meer gevorderde teams. Na de eerste fase van volwassenheid, wanneer een bedrijf stopt met alleen de eenvoudigste types te gebruiken, ontstaat de verleiding om koste wat kost steeds 'slimmere' classes te zoeken. In theorie klinkt dat goed. In de praktijk leidt het vaak tot overinterpretatie.

Het probleem is dat het meest gedetailleerde type niet altijd het meest passend is. Als de content geen voldoende inhoudelijke dekking biedt voor een bepaalde klasse, wordt de aanduiding aspiratief. Het systeem krijgt een signaal dat te ambitieus is ten opzichte van de feitelijke inhoud van het document.

De realiteit is minder spectaculair maar effectiever: veiliger is een eenvoudiger type dat overeenkomt met de functie van de pagina, dan een verfijnder type dat alleen maar de indruk wekt beter te passen. Dit geldt vooral voor deskundige publicaties, vergelijkingen en hybride pagina's, waar het gemakkelijk is het formaat van het document te verwarren met de intentie ervan.

Uit de praktijk: veel sites winnen door het model te vereenvoudigen, niet door het te compliceren. Als het team van exotische klassen terugkeert naar logisch gekozen basistypes, neemt het aantal semantische afwijkingen af en wordt het makkelijker orde te houden bij volgende updates.

Mythe 5. „Schema regelt de geloofwaardigheid van auteur en merk”

Deze mythe is erg verleidelijk, vooral in expertisegebieden en YMYL. Een bedrijf veronderstelt dat als het een Person-, Organization-entiteit, specialisaties, profielen en enkele reputatie-attributen toevoegt, het automatisch het vertrouwen versterkt. Helaas werkt het zo niet.

De bron van de foutieve overtuiging is simpel: technisch gezien kun je veel verklaren. Het probleem is dat een verklaring geen bewijs vervangt. Als het auteursprofiel summier is, er geen sporen van bekwaamheid op de site zelf zijn, publicaties anoniem zijn of het merk geen consistente redactionele verantwoordelijkheid toont, zal de markup dat niet 'repareren'.

In de sector helpen gestructureerde data de geloofwaardigheid te bevestigen, maar ze produceren die niet. Dat is een belangrijk verschil. Als een entiteit daadwerkelijk experts heeft, een publicatieproces, vaste auteursprofielen en consequent ontwikkelde themagebieden, versterkt schema dat beeld. Als dat ontbreekt, worden de aanduidingen lege verklaringen.

Praktische conclusie is vrij hard: het heeft geen zin een auteursentiteit op te blazen waarvan de aanwezigheid ophoudt bij een naam onder de kop. Beter een bescheidener maar eerlijke modellering dan een uitgebreide registratie zonder dekking. Systemen worden steeds beter in het herkennen van het verschil tussen beschreven identiteit en een reëel spoor van expertise op de site.

Mythe 6. „Op categoriepagina's verandert schema weinig, het is toch maar een listing”

Dit stereotype is diepgeworteld in e‑commerce. Categorieën werden jarenlang uitsluitend als navigatie-element en plaats voor assortimentfilters gezien. Daaruit volgt de conclusie dat alleen artikelen en productpagina's echte semantische waarde hebben.

Die benadering is achterhaald. In veel sites zijn categorieën juist het belangrijkste contactpunt tussen brede informatie-intentie en de aankoopbeslissing. Als een gebruiker zoekt naar verschillen, toepassingen, soorten apparaten of hoe te kiezen, kan een goed opgebouwde categorie voor zoekmachines en AI een van de sterkste thematische bronnen zijn.

De marktrealiteit toont dat een categorie stopt met een 'slechts listing' te zijn zodra het de functie van een redactionele knoop krijgt: het ordent het onderwerp, plaatst producten in context en beantwoordt basisvragen vóór de transactie. Dan hebben gestructureerde data iets te beschrijven. In gespecialiseerde sites is dit vaak een sterker semantisch punt dan een gemiddelde productpagina met een magere beschrijving.

Uit ervaring: waar bedrijven de categorie negeren, missen ze een enorm potentieel voor gecombineerde queries en AI Overview. Waar de categorie is uitgewerkt als thematische bron, is het veel makkelijker logische overgangen tussen kennis en aanbod te bouwen. Dat is vooral zichtbaar in secties die van nature de aankoopbeslissing structureren, zoals bloeddrukmetingen of oximeters en hartslagmeters.

Mythe 7. „Gestructureerde data implementeer je één keer en het is klaar”

Deze overtuiging komt vaak voort uit de projectmatige aanpak van technische SEO. Er is een ticket, er is een implementatie, er is acceptatie, er is validatie. Organisatorisch is dat handig, maar in de praktijk behoudt schema zijn waarde niet als het niet mee onderhouden wordt met de site.

Waarom is deze mythe zo schadelijk? Omdat hij dagelijkse veranderingen negeert: CMS‑updates, aanpassingen van componenten, titelwijzigingen, rotatie van auteurs, correcties van beschrijvingen, feedimplementaties, herbouw van productpagina's. Elk van deze kan stilletjes de datalaag breken, zelfs als de front-end er correct uitziet.

De sectorrealiteit is simpel: gestructureerde data moeten behandeld worden als onderdeel van informatie‑kwaliteitsbeheer. Niet als een eenmalige developer‑toevoeging. In volwassen teams wordt schema opgenomen in QA, redactionele wijzigingsprocessen en checklists bij de introductie van nieuwe modules.

Praktische observatie uit audits: veel sites hebben geen probleem met de eerste implementatie. Het probleem begint drie maanden later, wanneer een nieuw component sommige velden overschrijft of de sjabloonlogica verandert. Dan denkt het bedrijf 'we hebben schema', terwijl het in werkelijkheid vaak alleen nog de historische versie heeft.

Mythe 8. „Eerst rollen we schema over de hele site uit, later verbeteren we details”

Deze denkwijze ontstaat meestal door druk om schaal. Een grote site wil snel duizenden URL's dekken met markup, omdat dat er goed uitziet in planning en rapportage naar het management. Het probleem is dat schaal van implementatie gemakkelijk verward wordt met kwaliteit van implementatie.

Het is een verkeerde verwachting, omdat schema niet lineair werkt. Er zit weinig waarde in het automatisch dekken van honderden zwakke of marginale pagina's als de belangrijkste bronnen nog steeds een generiek of onnauwkeurig datamodel hebben. In projecten die inzetten op citeerbaarheid door AI, tellen eerst de plekken die het hoofdbeeld van het domein vormen: centrale thematische hubs, belangrijkste deskundige content, auteursprofielen, geselecteerde producttypes.

De operationele realiteit is dat een smalle maar verfijnde uitrol effectiever kan zijn. Eerst de pagina's met de hoogste informatie‑ en zakelijke waarde, en pas daarna het uitbreiden van het model naar andere gebieden. Deze aanpak ondersteunt topical authority beter en laat sneller zien of de gekozen logica daadwerkelijk werkt.

Uit de praktijk: massale uitrol zonder prioritering leidt er vaak toe dat het team maandenlang secundaire gebieden verbetert, terwijl de belangrijkste pagina's semantisch nog steeds vlak zijn. Bij AI‑gerichte implementaties is dat tijdsverspilling, omdat systemen toch vooral de centrale bronnen van het domein beoordelen.

Mythe 9. „Schema is een zaak voor developers; de redactie hoeft het niet te begrijpen”

Dit is een van de kostbaarste organisatorische stereotypen. Het komt voort uit het feit dat de markup uiteindelijk in de code terechtkomt, dus bedrijven schuiven de verantwoordelijkheid vanzelf naar de technische afdeling. Op papier lijkt dat logisch. In de praktijk leidt het ertoe dat mensen die content maken niet begrijpen welke informatie kritisch is voor de semantische laag.

Waarom werkt dat niet? Omdat de meeste cruciale problemen niet in de code ontstaan, maar eerder: bij de titel, de documentstructuur, toekenning van de auteur, contentupdates, relaties tussen materialen, manier van het beschrijven van entiteiten en het onderhoud van bronvelden. Een developer kan de data correct renderen, maar kan voor de redactie geen consistente inhoudslogica bedenken.

De realiteit in goed functionerende teams is anders: de redactie weet welke velden belangrijk zijn, SEO bewaakt het semantische model en development zorgt voor correcte generatie en onderhoud. Pas zo ontstaat stabiliteit. Zonder die rolverdeling verandert schema snel in een technische laag los van de content.

Praktische conclusie: als auteurs en editors niet begrijpen waarom het wijzigen van een kop, auteur of beschrijving ook de datalaag beïnvloedt, ontstaan er na enkele sprints inconsistenties. Dat is geen probleem van het hulpmiddel. Het is een probleem van het publicatieproces.

Mythe 10. „Als de content goed is, hoef je niet over entiteiten en relaties na te denken”

Deze mythe komt vooral voor bij sterke contentteams. Als materiaal deskundig, actueel en goed geschreven is, ontstaat de gedachte dat de entiteitenlaag secundair is. In zekere zin is dat begrijpelijk — goede content is inderdaad de basis. Maar tekstkwaliteit op zich lost het interpretatieprobleem op domeinniveau niet op.

De fout zit in het kijken naar een enkel artikel in plaats van naar het hele domein. AI en zoekmachines beoordelen niet alleen een document in isolatie. Ze kijken ook hoe een stuk samenhangt met andere bronnen, of het een bepaald onderwerp versterkt, of het past in een consistent specialisatiegebied en of de plaatsing binnen de site logisch is.

De realiteit is dat zelfs een uitstekend stuk semantisch geïsoleerd kan zijn. Als onduidelijk is met welk aanbodgebied het verbonden is, welke relaties het heeft met andere documenten en in welk kenniscluster het functioneert, versnippert een deel van het potentieel. Dit is vooral belangrijk bij content die aankoopbeslissingen ondersteunt rond specialistische producten, ook zoals ECG‑elektroden.

Uit ervaring: de beste resultaten ontstaan niet wanneer een bedrijf 'enkele goede artikelen' publiceert, maar wanneer het een consistent netwerk van documenten, entiteiten en contexten bouwt. Dan is schema geen bijkomstigheid. Het wordt de laag die helpt dat voordeel te ordenen en beter aan AI‑systemen te communiceren.

Mythe 11. „De effecten van schema zouden snel en makkelijk meetbaar moeten zijn”

Deze valse verwachting komt voort uit de gewoonte aan eenvoudige KPI's. Een site‑eigenaar wil direct meer zichtbaarheid zien, meer rich results of een simpel signaal van 'implementatie werkte'. Intussen is de impact van gestructureerde data vaak indirect en gespreid over tijd.

Schema werkt zelden als een schakelaar. Het verbetert vaker de manier waarop een pagina wordt geïnterpreteerd, de stabiliteit van documentclassificatie, de consistentie van entiteiten en de kwaliteit van afstemming op complexere intenties. Dat vertaalt zich in resultaten, maar niet altijd als één spectaculaire sprong.

In de praktijk ziet volwassen evaluatie van een implementatie er anders uit. Men kijkt of belangrijke URL's beter worden geclassificeerd, of materiaal zijn betekenis niet verliest na technische wijzigingen, of themaclusters sterker werken, of de aanwezigheid in synthetische antwoorden en gecombineerde queries toeneemt. Die effecten zijn waardevoller dan een tijdelijke toename van versiersels in de SERP.

Praktische observatie: bedrijven die een direct 'schema‑effect' verwachten, nemen vaak foutieve beslissingen. Of ze geven goede implementaties te snel op, of ze betalen te veel voor cosmetische verbeteringen, zonder te begrijpen dat de echte waarde in de lange termijnconsistentie van het informatiemodel zit.

Wat uit deze mythen volgt in de praktijk

Het meest schadelijke zijn niet de technische fouten zelf, maar de foutieve aannames waarmee een project begint. Als een bedrijf gelooft dat schema 'een beetje SEO toevoegt', 'gebrek aan kwaliteit kan verhullen' of 'op zichzelf genoeg is voor AI', eindigt het bijna altijd met een formeel correcte maar strategisch zwakke implementatie.

Een volwassen aanpak ziet er anders uit. Eerst ordening van betekenissen, verantwoordelijkheid voor data, rol van de belangrijkste paginatypes en zinvolle relaties tussen bronnen. Pas daarna de markup. Juist dan begint Schema.org daadwerkelijk niet alleen klassieke SEO te ondersteunen, maar ook GEO, AI Search Optimization en de kans op citeren door taalmodellen.

Vergelijking van benaderingen voor gestructureerde data voor AI: wat verschilt er echt in de praktijk

Moet de implementatie van Schema.org alleen de basisinterpretatie van de site door de zoekmachine ondersteunen, of moet het een leesbaar kennismodel voor systemen die antwoorden genereren opbouwen? Dit onderscheid bepaalt meestal het hele project. Op papier lijken veel oplossingen op elkaar. In de praktijk verschillen ze in onderhoudskosten, veerkracht tegen wijzigingen in de site en of ze helpen bij citeerbaarheid, of slechts 'bestaan'. Hieronder de belangrijkste vergelijkingen die daadwerkelijk invloed hebben op het resultaat.

Minimale schema-implementatie vs semantisch model opgebouwd voor AI Search

De eerste benadering komt neer op het markeren van de basistypen pagina's: artikel, product, organisatie, breadcrumbs. Deze oplossing is redelijk waar de site klein en eenvoudig is en er geen uitgebreide afhankelijkheden zijn tussen content en aanbod. In veel bedrijven is zo'n niveau voldoende in het begin, omdat het technische fouten beperkt en het mogelijk maakt snel de belangrijkste bronnen te ordenen.

De tweede benadering gaat verder. Het stopt niet bij de aanwezigheid van markup, maar behandelt die als een laag die entiteiten en relaties in de hele site beschrijft. Dat betekent consistente identifiers, logische koppeling van auteurs aan publicaties, producten aan categorieën en educatieve content aan aankoopgebieden. Voor sites die handleidingen en een catalogus combineren, vooral rond secties zoals holters of bloeddrukmeting, maakt dit verschil echt uit.

Voor wie is het minimum? Voor kleine bedrijfswebsites, eenvoudige blogs en projecten die net de technische laag ordenen. Voor wie het semantische model? Voor e-commerce, expertplatforms, gespecialiseerde catalogi en merken die herkend willen worden als een bron van kennis, niet alleen als een verzameling URL's.

De beperking van de eerste benadering is eenvoudig: het werkt correct, maar bouwt zelden een voordeel op. De beperking van de tweede is ook eerlijk aan te geven: het vereist betere redactionele processen, meer developerdiscipline en geeft meestal geen snel resultaat na één iteratie.

Uit marktpraktijk: bedrijven proberen vaak te springen van chaos naar een 'volledige entity graph'. Meestal eindigt dat in vorm boven inhoud. Als de informatiefundamenten zwak zijn, is het beter het implementatieproces in fasen te doen dan vanaf de eerste sprint een te ambitieus model te ontwerpen.

JSON-LD vs Microdata vs RDFa

Op standaardeniveau kunnen alle drie de formaten vergelijkbare informatie overdragen, maar hun praktische bruikbaarheid verschilt soms. JSON-LD werkt het beste waar SEO, content en development gelijktijdig aan de gestructureerde data werken. Het is eenvoudiger te auditen, makkelijker te versioneren en sneller om afwijkingen tussen paginatypes te ontdekken.

Microdata kan zinvol zijn in projecten waar contentlaag en datalaag erg dicht bij elkaar moeten zitten, bijvoorbeeld in gesloten productieve systemen of bij oudere implementaties gebaseerd op kant-en-klare templates. Het probleem ontstaat bij opschaling. Wanneer er nieuwe modules, filtering, dynamisch gerenderde elementen en redactionele uitzonderingen bijkomen, wordt Microdata moeilijker te onderhouden dan het in eerste instantie leek.

RDFa komt minder vaak voor in contentmarketing- en e-commerceprojecten. Het heeft zin in meer technische of academische omgevingen of waar een organisatie breder met linked data werkt. Voor een gemiddelde commerciële site is het organisatorisch meestal gewoon zwaarder, niet per se beter qua business.

Als iemand vraagt welk formaat vandaag te kiezen voor implementatie onder SEO en AI Search, luidt het antwoord in de meeste gevallen: JSON-LD. Niet omdat de anderen slecht zijn, maar omdat het de minste operationele wrijving oplevert.

Een branche-observatie is tamelijk repetitief: problemen komen zelden door de keuze van het formaat zelf. Vaker doordat een site meerdere formaten tegelijk mengt en elk iets andere waarden levert. Dan verandert zelfs een technisch goed uitgangspunt in chaos die moeilijk te onderhouden is.

SEO-plugin of automatische generator vs dedicated implementatie

Een automatische generator is een goede oplossing waar snelheid van starten en basisdekking van paginatypes telt. In eenvoudige blogs, kleine webshops en dienstensites kan het 70 procent van het werk afhandelen zonder grote technische middelen te betrekken. Dat moet je eerlijk toegeven.

Een dedicated implementatie krijgt de overhand wanneer de site ongewone templates heeft, educatieve functies met transactionele combineert of meerdere databronnen bezit. In dergelijke omstandigheden produceert een generator vaak formeel correcte markup, maar te algemeen. Hij begrijpt niet welke categorieën thematische hubs zijn, welke artikelen verkoop ondersteunen en welke pagina's anders beschreven moeten worden dan de rest.

Voor een winkel met een simpel catalogus is een generator vaak voldoende. Voor een site die tegelijk educateert en verkoopt, bijvoorbeeld door context te bouwen rond oximeters en hartslagmeters of accessoires zoals ECG-elektroden, biedt een dedicated implementatie doorgaans veel betere controle over de relaties tussen bronnen.

De beperking van generators is voorspelbaar: ze middelen logica. De beperking van dedicated implementaties is ook reëel: zonder onderhoudsproces veranderen ze snel in een verzameling uitzonderingen die niemand bijhoudt.

Uit de praktijk: veel bedrijven stoppen te vroeg met automatisering of blijven er te lang aan vasthouden. Een verstandige aanpak zit meestal in het midden. De kern systemisch genereren, en sleutelpaginasoorten overschrijven waar het echt invloed heeft op de zakelijke interpretatie van belangrijke URL's.

Één bron van waarheid voor data vs data uit meerdere modules

Deze vergelijking is minder spectaculair dan de keuze van een schema-type, maar in de praktijk belangrijker. Als data over auteur, product, organisatie en publicatie uit één gecontroleerde bron komt, is de markup stabieler. Het is makkelijker consistentie te bewaren bij titelwijzigingen, productupdates of herstructureringen van categorieën.

Het multi-bronmodel ontstaat meestal vanzelf: wat data uit het CMS, wat uit de productfeed, wat uit het reviewmodule, wat uit de frontendlaag. In het begin is dat handig. Later ontstaan subtiele conflicten. Een andere productnaam in de content, een andere in JSON-LD, een andere beschrijving in de listing, weer iets anders in de data voor de crawler.

Voor kleine sites kan het verschil gering zijn. Voor middelgrote en grote projecten is het al een kwestie van de veerkracht van de hele implementatie. Hoe meer product- en expertpagina's, hoe hoger de kosten van chaos. Dit geldt vooral in sectoren waar technische specificaties interpretatiebelangrijk zijn, niet alleen verkoopgericht.

In de praktijk is het niet altijd mogelijk één bron absoluut voor alles te hebben. Soms beheert het productsysteem commerciële attributen en het CMS de expertlaag. Het belangrijkste is dan niet 'vereenvoudigen voor elke prijs', maar duidelijke toewijzing van een eigenaar voor elk belangrijk attribuut.

Observatie uit projecten: bedrijven waarderen dit onderwerp meestal pas na een redesign of migratie. Dan blijkt dat het probleem niet het gebrek aan gestructureerde data was, maar het gebrek aan orde in de data die gestructureerd gepubliceerd moesten worden.

Markeren van losse pagina's vs bouwen van relaties tussen paginatypes

De puntbenadering focust erop dat elke pagina 'zijn schema' heeft. Artikel als Article, product als Product, auteurspagina als Person. Dat is een zinnig basisniveau en nog steeds beter dan geen markup. Het werkt goed wanneer het doel is individuele documenten te ordenen zonder grote ingrepen in de site-architectuur.

De relationele benadering gaat ervan uit dat niet alleen de omschrijving van de pagina telt, maar ook de plaats ervan in een grotere structuur. Een artikel moet een bepaald themagebied ondersteunen, een auteur moet herkenbaar zijn in meer dan één post en een categoriepagina moet meer zijn dan een simpele listing. Zo'n model sluit beter aan bij hoe AI Search antwoorden uit meerdere signalen en kennisfragmenten samenstelt.

Voor een expertblog zonder verkoopfunctie kan het puntmodel voldoende zijn. Voor hybride sites is het relationele model meestal rendabeler, omdat het niet alleen de interpretatie van een enkele pagina verbetert, maar ook hele themaclusters versterkt.

Het nadeel van de puntbenadering is beperkte schaal van het effect. Het nadeel van de relationele benadering is dat het betere interne linking, consistente auteurprofielen en meer redactionele samenhang afdwingt. Dat kun je niet goed oplossen met alleen code.

In de praktijk zie je hier vaak het verschil tussen een 'afgewerkt' implementatie en een implementatie die daadwerkelijk zichtbaarheid ondersteunt in samengestelde, vergelijkende en expertvragen.

Schema gebaseerd op volledige automatisering vs hybride model met redactionele controle

Volledige automatisering wint op schaal. Als een site honderden of duizenden URL's per maand publiceert, wordt het handmatig invullen van veel velden snel onhaalbaar. Automatisering verwerkt goed datums, URLs, basisrelationele templategegevens, organisatiegegevens en een deel van productparameters.

Het hybride model gaat ervan uit dat sommige elementen automatisch worden gegenereerd, maar dat sleutelvelden onder redactionele controle blijven of in ieder geval redactioneel worden goedgekeurd. Dat is een betere oplossing voor expertcontent, vergelijkingen, categorieën met groot thematisch belang en specialistische producten waarbij een gebruiksbeschrijving zwaarder weegt dan alleen een catalogusnummer.

Voor grote marktplaatsen kan volledige automatisering de enige reële operationele keuze zijn. Voor expert-, medische, technologische of B2B-sites leidt volledige automatisering vaak tot nivellering van betekenis. Alles begint op elkaar te lijken, terwijl de gebruikersintentie totaal anders kan zijn.

De beperking van automatisering is evident: minder mate van detail en hogere proceskosten. De beperking van het hybride model moet ook eerlijk worden benoemd: zonder goed ingericht CMS en redactionele checklist verandert het snel in halfslachtige chaos.

Uit implementatiepraktijk werkt de vuistregel het beste: automatiseer wat stabiel en meetbaar is, en verfijn handmatig wat de zingeving van de pagina beïnvloedt. Juist daar ontstaat later het kwaliteitsverschil in de interpretatie door modellen.

Schema voor een expertblog vs schema voor specialistische e-commerce

In een blogsite zijn doorgaans auteurschap, publicatiecontext, specialisatie en thematische consistentie prioriteit. Daar draait het om orde rond entiteiten als Organization, Person, Article, WebPage. Aanbiedings- of cataloguselementen zijn veel minder relevant omdat ze er gewoon niet zijn of slechts een marginale rol spelen.

In specialistische e-commerce verschuift het zwaartepunt naar de relatie tussen content en aanbod. Producten alleen zijn niet genoeg als de gebruiker verschillen, toepassingen of keuzetips zoekt. Omgekeerd zijn handleidingen alleen niet genoeg als ze niet leiden naar logisch beschreven aankoopsecties. In zulke sites moeten gestructureerde data tegelijk op informatie- en transactieniveau werken.

Voor een winkel die technisch of medisch assortiment verkoopt, zijn niet alleen de productpagina's praktisch van belang, maar ook categorieën die probleemgebieden beschrijven. Dit geldt bijvoorbeeld voor secties als bloeddrukmeting of holters, waar de gebruiker vaak niet eindigt bij één eenvoudig productzoekopdracht.

Het nadeel van naar e-commerce kijken alleen via Product en Offer is dat de site semantisch plat wordt. Het nadeel van een winkel te veel op een expertportal te laten lijken is het vervagen van de verkoopfunctie. Je moet de verhoudingen afstemmen op de gebruikersintentie per paginatype.

Branchesignalen tonen één regelmaat: hoe specialistischer het product, hoe minder zinvol het is content en catalogus volledig te scheiden. In dergelijke projecten levert niet 'meer schema' maar een betere koppeling van kennis aan het aanbod de beste resultaten op.

Categoriepagina's als gewone listings vs categoriepagina's als thematische hubs

Als een categorie alleen als listing wordt behandeld, beperken gestructureerde data zich meestal tot technische beschrijving van de pagina en breadcrumbs. Deze aanpak volstaat waar de gebruiker precies weet wat hij zoekt en de catalogus simpel is en vergelijkingen geen grote rol spelen.

Als een categorie de functie van thematische hub vervult, heeft die een andere logica nodig. Het gaat niet om kunstmatige uitbreiding, maar om zo'n positionering dat ze ook informatieve vragen beantwoordt en het onderwerp ordent. In de praktijk werkt dit goed in gebieden waar gebruikers nadenken over verschillen tussen oplossingen, toepassingen van apparaten of de keuze van accessoires.

Wie profiteert van een gewone listing? Winkels met eenvoudige, laag betrokkenheidsgoods en een korte aankooptraject. Wie wint met een thematische hub? Specialistische merken, B2B-distributeurs, winkels met assortiment dat uitleg vereist en sites die topical authority opbouwen.

De beperking van de listing is duidelijk: het beantwoordt slecht samengestelde vragen. De beperking van de hub moet ook eerlijk worden genoemd: het vereist beter redactioneel werk en een goed gevoel om de categorie niet te veranderen in een overbeladen miniartikel.

Uit ervaring zijn categorieën vaak de meest onderschatte semantische bron op een site. Niet omdat ze het grootste technische potentieel hebben, maar omdat ze informatie- en aankoopintentie het beste verbinden.

Implementatie gericht op rijke resultaten vs implementatie gericht op citeerbaarheid en AI Overview

Een implementatie voor rijke resultaten concentreert zich op wat snel en direct in de zoekresultaten zichtbaar kan zijn. Deze benadering heeft nog steeds zin, vooral wanneer de organisatie tastbare resultaten nodig heeft en werkt met paginatypes die ondersteund worden door specifieke uitgebreide features.

Een implementatie voor citeerbaarheid en synthetische antwoorden gaat een andere kant op. Het vraagt niet eerst welke SERP-elementen 'ontgrendeld' kunnen worden, maar of de pagina voldoende ondubbelzinnig is als kennisbron om door het systeem als ondersteunend antwoord te worden gebruikt. Hier zijn entiteitsconsistentie, specialisatie van auteurs, feitelijke overeenstemming en goede thematische positionering belangrijker.

Voor eenvoudige lokale projecten kan focus op rijke resultaten volstaan. Voor expertplatforms en merken die zichtbaarheid in AI Search willen opbouwen is het te smal. Niet omdat het verkeerd is, maar omdat het een te klein fragment van het effect meet.

De praktische consequentie van de keuze is belangrijk. Als het team alleen naar rijke-resultatenrapporten kijkt, kan het de implementatie als succes beschouwen ondanks zwakke semantische kwaliteit. Als het alleen naar citeerbaarheid door AI kijkt, kan het het technische ordeningswerk onderschatten dat als fundering nodig is.

De meest verstandige aanpak die in volwassen projecten werkt, combineert beide perspectieven. Rijke resultaten als bijproduct van een goede implementatie, niet als enige doel. Citeerbaarheid als richting, maar geen voorwendsel om het model onnodig complex te maken.

Eigen implementatie in-house vs samenwerking met externe partner

Een in-house team heeft een groot contextvoordeel. Het kent het CMS, de technologische beperkingen, de wijzigingshistorie en weet welke paginatypes echt zakelijk belangrijk zijn. Als er binnen het bedrijf volwassen samenwerking is tussen SEO, content en development, kan interne implementatie het meest effectief zijn.

Een externe partner is vaak de betere keuze wanneer de organisatie een frisse blik, een semantische audit of ervaring met verschillende sitestructuren nodig heeft. Goede uitvoerders herkennen sneller foutpatronen die een intern team niet meer ziet omdat ze 'normaal' zijn geworden in het systeem.

Het nadeel van het in-house model is het risico op blinde vlekken en het uitstellen van moeilijke beslissingen omdat ze botsen met dagelijkse productie. Het nadeel van een externe partner is vaak minder kennis van zakelijke nuances en de verleiding een te theoretisch model te ontwerpen dat later moeilijk te onderhouden is.

In de praktijk levert een gemengde opzet de beste resultaten: externe strategie en semantische architectuur, en intern onderhoud en doorontwikkeling. Dit werkt vooral goed in projecten waar de site voortdurend groeit en templates, aanbod en categoristructuur verandert.

Op de markt is duidelijk dat technische competentie alleen niet meer voldoende is. Een goede Schema.org-implementatie voor AI vereist begrip van informatie, gebruikersintentie en bedrijfsstructuur. Zonder dat blijft zelfs correcte code maar de helft van de oplossing.

Dit zeggen de meeste bedrijven niet over Schema.org voor AI

Het meest misleidende aan gestructureerde gegevens is dat ze er heel snel “klaar” uitzien. De code wordt gerenderd, de validator klaagt niet, in de audit verschijnt een groene status en het project kan formeel worden afgesloten. Het probleem begint later. Bij werk voor SEO en AI Search ontstaan echte problemen zelden door het ontbreken van de markup zelf. Meestal komen ze voort uit processen, verantwoordelijkheden en de kwaliteit van de informatie die die markup moet vertegenwoordigen. Dat is niet zichtbaar tijdens de presentatie van de implementatie. Dat zie je pas na een paar maanden, na een migratie, na een redactionele wijziging of wanneer de site probeert content op te schalen.

„Technisch correct” betekent niet „semantisch betrouwbaar”

Dit is een van die problemen waar nauwelijks iemand openlijk over praat, omdat het mooie post-implementatierapporten ondermijnt. In de praktijk kun je een volledig syntactisch correcte schema hebben en tegelijkertijd weinig bruikbaar zijn voor systemen die proberen te bepalen of een pagina werkelijk een goede bron voor een antwoord is. Meestal gebeurt dit wanneer gestructureerde gegevens trouw het sjabloon beschrijven, maar niet meer de betekenis van het document.

Waarom trekt bijna niemand dit aan de bel? Omdat het makkelijker is om een implementatie te verkopen als een set schematypen dan als werk aan de samenhang van het hele informatiemodel. Tools versterken die illusie ook. Ze tonen formele fouten, maar niet of entiteiten zo eenduidig beschreven zijn dat ze zinvol gebruikt kunnen worden in AI Overview, Perplexity of conversatieantwoorden.

In de praktijk ziet het er zo uit: een categoriepagina heeft gestructureerde gegevens, maar daar blijft niets van over behalve dat het een pagina is. Een artikel heeft Article, maar bouwt geen sterke thematische context op. Een product heeft Product, maar beschrijft alleen catalogusgegevens, zonder signaal waarom dat object gebruikt zou moeten worden als bron voor een specifiek gebruikersvraag. Dat komt vaker voor dan je denkt.

De meeste schade ontstaat bij implementaties zonder eigenaar na de start

Bedrijven gaan er meestal van uit dat Schema.org een implementatietaak is. Eenmaal opgezet, zou het moeten werken. In echte projecten werkt het bijna nooit zo eenvoudig. Gestructureerde gegevens zijn afhankelijk van redactie, CMS, feeds, productbeschrijvingen, auteurspagina’s, wijzigingen in layouts en categorielogica. Als na de implementatie niemand deze laag als proces bewaakt, begint er een langzame degradatie.

Weinig bureaus leggen hier veel nadruk op, omdat het minder spectaculair klinkt dan een “volledige schema-implementatie”. Uit ervaring is juist het onderhoud de plek waar projecten ofwel rijpen, ofwel uit elkaar vallen. Na een paar weken verandert de redactie titels, iemand overschrijft de auteurstekst, de frontend verwijdert een deel van een component, een nieuwe pluginversie verandert de generatielogica en plotseling bestaat alles nog wel, maar is het niet meer consistent.

Consistentie is niet altijd spectaculair. Zelden zie je een dramatische daling van de ene op de andere dag. Meestal ontstaat erosie: mindere stabiliteit in de interpretatie van paginatypen, minder duidelijke koppeling tussen content en aanbod, zwakkere verankering van belangrijke URL’s in synthetische antwoorden. Daarom kunnen schijnbaar “goed gelabelde” sites verliezen van bescheidener, maar beter onderhouden projecten.

Het moeilijkste zijn niet de voor de hand liggende pagina’s, maar de grensgevallen

Er wordt veel gesproken over artikelen, producten en organisaties omdat dat makkelijke voorbeelden zijn. Het echte probleem ontstaat op pagina’s die meerdere functies combineren. Vergelijkingen, rankings, aankoopgidsen, uitgebreide categorieën, landingspagina’s voor specifieke toepassingen, pagina’s met gefilterde catalogi en een educatieve laag — juist daar worden vaak beslissingen genomen die later de interpretatie van de hele site beïnvloeden.

De meeste bedrijven vereenvoudigen deze gevallen tot één sjabloon omdat dat operationeel eenvoudiger is. Alleen kijkt AI Search niet naar ze als “nog een template”. Het kijkt of het document daadwerkelijk de rol vervult van vergelijking, uitleg, navigatie of aanbod. Als alles hetzelfde generieke model krijgt, vervagen de verschillen tussen intentietypen sneller dan SEO-teams verwachten.

In de praktijk zie je dit het duidelijkst bij categorieën die zowel naar aankoop moeten leiden als het onderwerp moeten ordenen. Als zo’n sectie commercieel belangrijk is, maar in de gestructureerde gegevens slechts een technische productlijst blijft, verliest de site een deel van haar semantische voorsprong. Dit geldt vooral voor specialistische domeinen, waar een gebruiker niet alleen komt voor het productmodel, maar voor het begrijpen van verschillen, toepassingen en beperkingen.

Problemen beginnen waar de organisatie niet kan beslissen wat feit is en wat marketingbeschrijving

Dit is een zeer praktisch en ondergewaardeerd onderwerp. Gestructureerde gegevens verdragen bedrijfsjargon slecht dat verkoopclaims met operationele informatie vermengt. Voor een mens kan een slogan op een pagina neutraal lijken. Voor systemen die entiteiten en attributen interpreteren wordt het een probleem, omdat de markup niet de realiteit beschrijft maar een door interne “oppoetsing” verkregen versie van de realiteit.

Weinig mensen bespreken dit openlijk, omdat dit probleem op het snijvlak van SEO, content en merk ligt. Niemand wil de afdeling zijn die zegt: “dit kan niet eerlijk worden gemapped in schema, want het is geen harde informatie”. Toch ontstaat hier veel semantische ruis. Het betreft beschrijvingen van auteurscompetenties, productcategorieën, toepassingsgebieden van apparaten en zelfs sectienamen die vanuit zakelijk oogpunt goed klinken maar informatief vaag zijn.

In de praktijk betekent dit dat je heel nuchter moet filteren wat echt geschikt is voor structurele beschrijving. Hoe specialistischer de branche, hoe belangrijker het onderscheid wordt tussen wat de organisatie wil communiceren en wat ze stabiel en eenduidig kan verklaren als data.

Auteurs zijn vaak de zwakste schakel in de hele implementatie, zelfs als iedereen denkt dat het de code is

Bij specialistische content denken veel bedrijven dat het genoeg is een auteurspagina, foto en korte bio toe te voegen. Op presentatievlak lijkt dat logisch. In de praktijk zijn auteurprofielen vaak semantisch leeg. Ze bevatten te weinig content, zijn niet consistent tussen afdelingen, bouwen geen specialisatie op en handhaven geen uniform identiteitsmodel over de hele site.

Waarom wordt hier weinig over gesproken? Omdat het ongemakkelijk werk is. Het vereist samenwerking met de redactie, vaak het opschonen van historische publicaties, het vaststellen van inhoudelijke verantwoordelijkheid en het afzien van fictieve of gezamenlijke auteurs. Het is geen aantrekkelijk onderdeel van een implementatieaanbod, maar vanuit AI-perspectief kan het belangrijker zijn dan het toevoegen van nog een property in JSON-LD.

Uit ervaring: wanneer een site veel specialistische content heeft maar auteurschap wordt verwaarloosd, krijgen modellen een zwakker signaal van verantwoordelijkheid en continuïteit van kennis. Dat leidt niet altijd tot problemen bij indexering. Het zorgt er vaker voor dat een site minder vaak wint als bron voor synthetische antwoorden, vooral bij onderwerpen die een zorgvuldige interpretatie vereisen.

Sommige schema-velden lijken slim, maar in de praktijk doen ze vaker schade dan goed

Dit is een onderwerp dat velen vermijden omdat het intuïtie tegenspreekt: “meer data = beter”. In de praktijk worden sommige properties misbruikt of mechanisch ingevuld zonder echte cognitieve waarde. Daarna heeft de site een rijke markup, maar veel van die informatie is semantische ruis.

Dit gebeurt het meest bij velden die strategisch klinken maar geen goede gegevensbron hebben: te breed ingevulde kennisgebieden, automatisch gegenereerde beschrijvingen, zoekwoorden overgenomen uit metadata, relaties “voor het geval dat”. Weinig mensen geven dat openlijk toe, omdat zulke markup er goed uitziet in documentatie. Het probleem is dat AI niet de omvang van de declaraties beloont. Het waardeert consistentie en eenduidigheid meer.

In de praktijk werkt een spaarzamer maar gecontroleerd model beter. Als een property niet betrouwbaar en consequent gevoed wordt, is het vaak veiliger om die niet te ontwikkelen dan schijnbare precisie te handhaven. Dit is een van die beslissingen die je pas goed begrijpt na enkele audits van sites met “rijke” maar weinig nuttige markup.

De grootste discrepanties ontstaan na redesign, niet na de eerste implementatie

Tijdens de implementatiefase zijn teams meestal gefocust. Er is een specificatie, tests, checklist. Na een redesign of frameworkwisseling ziet alles er anders uit. Prioriteit krijgt snelheid, visuele overeenstemming, Core Web Vitals, nieuwe modules, filters, componenten. De semantische laag zakt lager op de prioriteitenlijst omdat je die niet meteen op het scherm ziet.

Juist dan ontstaan problemen die je zonder volwassen QA moeilijk opvangt: de volgorde van gegevens verandert, delen van entiteiten verdwijnen, objecten dupliceren, nieuwe componenten genereren andere waarden dan oude. Weinig bedrijven spreken daar luid over voordat het project start, want dat zou betekenen dat je moet toegeven dat schema voortdurende kwaliteitscontrole vereist en niet slechts een eenmalig “afvinken”.

Uit ervaring is dit een van de vaakste oorzaken van regressie in middelgrote en grote sites. Niet het initiële concept is fout, maar het ontbreken van semantische tests na technische wijzigingen. De site loopt visueel vooruit, terwijl de datalaag een stap terug zet.

In specialistische e‑commerce is het probleem niet het ontbreken van Product, maar het ontbreken van zinvolle context rond het product

Bij winkels en catalogi is het makkelijk te denken dat het verfijnen van productpagina’s het belangrijkst is. Dat is natuurlijk relevant, maar in de praktijk winnen producten zelden op zichzelf in complexere zoekvragen. Zeker waar gebruikers verschillen, toepassingen, beperkingen of keuzes tussen oplossingsklassen zoeken.

Daarom bouwen veel sectoren de meeste semantische waarde niet met de kaarten zelf, maar met het netwerk van tussenliggende pagina’s: gidsen, vergelijkingen, categorie-hubs, secties die pre-purchase vragen beantwoorden. En hier komt iets naar voren wat veel uitvoerders niet zeggen: schema op het product compenseert niet dat de hele besluitvormingscontext rond het product pover of inconsistent is.

In de praktijk zie je dit vooral waar het aanbod interpretatie van parameters of toepassingskeuze vereist. Als een site educatieve content heeft maar die semantisch niet aan aanbodgebieden kan koppelen, gaat een deel van het potentieel verloren. In zulke gevallen levert het ordenen van relaties tussen content en aankoopsecties meer op dan het toevoegen van nog meer velden aan de productpagina.

Schema is soms gegijzeld door het beleid van het CMS

Dit is een heel alledaags onderwerp en tegelijk een van de meest reële. In theorie kun je een uitstekend entiteitmodel ontwerpen. In de praktijk valt alles of staat met de vraag of het CMS toelaat data voorspelbaar te onderhouden. Als een auteur geen gestructureerd profiel heeft, een categorie geen plek voor een duurzame semantische omschrijving en contenttypes redactioneel gemixt worden, dan lopen zelfs goede aannames snel vast in systeembeperkingen.

Waarom benadrukken weinig bedrijven dit sterk? Omdat dat vooraf een gesprek over proces- en technische veranderingen zou vereisen, en niet elke klant wil dat aan het begin horen. Het is makkelijker te praten over een “schema-implementatie” dan over het feit dat het CMS mogelijk herbouw van datamodellen, aparte velden, erfregels of nieuwe bewerkingsregels nodig heeft.

Uit de praktijk: de meeste problemen geven niet projecten die volledig verouderd zijn, maar die “half modern” zijn. Ze hebben wat automatisering, wat handmatige uitzonderingen, enkele modules van verschillende leveranciers en geen enkele centrale plaats waar de waarheid over entiteiten echt woont. Dan wordt JSON-LD slechts een laag van onderhandelingen tussen systemen.

Niet elk paginatype is het waard even ambitieus te worden gelabeld

Dat klinkt voor de hand liggend, maar in de praktijk zie ik regelmatig het tegenovergestelde. Als een bedrijf in gestructureerde gegevens investeert, wil het gevoel van volledige dekking. Het gevolg is dat veel energie naar URL’s gaat met geringe semantische waarde en te weinig naar pagina’s die echt werken voor zichtbaarheid, conversie en citatie.

Weinig uitvoerders zeggen dit hardop omdat de klant graag hoort over de schaal van de implementatie. Een volwassen aanpak betekent echter vaak bewust sommige adressen loslaten. Niet omdat ze technisch onbelangrijk zijn, maar omdat ze niet genoeg content dragen om uitgebreide modellering te rechtvaardigen.

In de praktijk is het beter een paar cruciale gebieden goed uit te werken dan alles gelijkmatig en middelmatig te labelen. Vooral wanneer de site belangrijke transactionele- en educatieve secties heeft, naast veel archieven, varianten en dunne subpagina’s. Prioritering is minder spectaculair dan volledige dekking, maar levert een beter operationeel resultaat.

Bij AI telt voorspelbaarheid van informatie meer dan de ‘slimheid’ van de implementatie

De verleiding is groot om een heel ambitieuze markup te ontwerpen, bijna als een mini knowledge graph. Soms heeft dat zin. Vaak leveren minder opvallende maar voorspelbare implementaties de beste resultaten. Vaste identificatoren, consequent nomenclatuur, herhaalbare relaties, schone auteurprofielen, geordende themapagina’s. Niet-spectaculaire zaken die het vertrouwen van het systeem in de site opbouwen.

Waarom wordt hier zelden over gesproken? Omdat het niet klinkt als innovatie. Toch is het vaak juist dit dat sites onderscheidt die geciteerd en goed geïnterpreteerd worden van sites met indrukwekkende implementatiedocumentatie maar middelmatig resultaat. Modellen belonen creativiteit op zich niet. Ze reageren beter op consistentie, vermindering van ambiguïteit en goed onderhouden entiteiten.

In de praktijk betekent dit meestal minder “exotische” oplossingen en meer discipline in weinig glansrijke gebieden. Juist die maken na verloop van tijd het verschil, wanneer de site groeit, meer content publiceert en begint een eigen kennislayer op te bouwen in plaats van slechts een verzameling pagina’s.

De meest onderschatte kostenpost is niet development, maar organisatorische ordening

Aan het begin van samenwerking verwachten klanten meestal dat de technische implementatie het moeilijkst zal zijn. Vaak blijkt iets anders lastig: het vastleggen van definities van contenttypes, het opschonen van auteurs, het ordenen van categorienamen, het oplossen van conflicten tussen CMS en feed, het aanwijzen van een dataverantwoordelijke en het beslissen welke informatie echt stabiel is.

Weinig mensen benadrukken dit omdat het minder “verkoopbaar” werk is dan development. Toch worden daar de meeste beslissingen genomen die de duurzaamheid van de implementatie bepalen. Als de organisatie het niet eens is over hoe ze haar entiteiten beschrijft, wordt schema slechts een elegante deklag boven chaos.

Uit ervaring: de beste projecten hebben niet altijd de meest uitgebreide code. Ze hebben wel beslissingsorde. Iedereen weet wie verantwoordelijk is voor auteurgegevens, wie over de naamgeving van themagebieden gaat, wie de naleving na wijzigingen bewaakt en welke pagina’s echt strategisch zijn. Zonder dit begint zelfs een correcte implementatie na verloop van tijd te drijven.

Wat betekent dit in de praktijk voor sites die door AI geciteerd willen worden

Het minst sexy antwoord is meestal het eerlijkste: het voordeel komt niet van de implementatie van schema zelf, maar van het vermogen om een samenhangend informatiemodel langdurig te onderhouden. Systemen die antwoorden genereren zijn zeer gevoelig voor ambiguïteit, inconsistentie en dunne context. Gestructureerde gegevens kunnen helpen ordenen, maar verhullen geen chaos in de bron.

Als een site de ambitie heeft zichtbaarheid op te bouwen niet alleen in klassieke Google Search, maar ook in AI Overview, ChatGPT, Gemini, Claude of Perplexity, moet schema meer behandeld worden als kennisinfrastructuur dan als SEO-toevoeging. Het gaat niet om alles beschrijven. Het gaat erom duidelijk te beschrijven wat echt belangrijk is en wat zonder voortdurende afwijkingen onderhouden kan worden.

Juist dat stadium onderscheidt meestal implementaties die na een jaar nog werken van die waarvan na een jaar alleen de documentatie overblijft.

Checklist voor de implementatie van Schema.org en gestructureerde gegevens voor AI

Deze checklist is niet bedoeld om „het schema af te vinken”, maar om te controleren of de implementatie systemen daadwerkelijk helpt om de pagina, de entiteiten en de context van de publicatie te begrijpen. Elk punt heeft betrekking op een ander gebied dat in de praktijk vaak bepaalt of gestructureerde gegevens werken ten gunste van SEO, GEO en citeerbaarheid door AI, of alleen maar correct lijken in de validator.

1. Controleer of er voor elk paginatype een aparte semantische specificatie bestaat

   Het gaat niet om een algemeen document „we hebben Article, Product en Organization”, maar om het uitschrijven van wat precies op een gidspagina, een categoriepagina, een productpagina, een auteurspagina en een bedrijfs-/firmapagina moet staan. Dat is belangrijk, want twee URL's kunnen er visueel vergelijkbaar uitzien maar een geheel andere informatieve functie hebben.

   Als je dit overslaat, eindig je al snel met één gemiddeld markup voor alles. Dan kan een uitgebreide categorie, zoals holters, net zo vlak beschreven worden als een gewone lijst, terwijl die in werkelijkheid een belangrijk thematisch knooppunt vormt. AI zal het verschil tussen een educatieve, een transactionele en een navigatiepagina minder goed herkennen.

   Uit de praktijk: een eenvoudige tabel met de kolommen „paginatype”, „hoofdentiteit”, „hulpentiteiten”, „gegevensbron”, „veld-eigenaar” werkt het beste. Zo'n document onthult snel leemtes nog voordat de ontwikkeling begint.

2. Controleer of elk belangrijk veld in het schema één concrete gegevensbron heeft

   Bij implementaties ontstaan de meeste problemen niet door de keuze van het schema-type, maar door chaos in de bronnen. Productnaam uit het ERP, beschrijving uit het CMS, auteur uit een handmatig ingevuld veld, update-datum uit de frontend en publisher uit plugin-instellingen. Formeel kan alles renderen, maar na wijzigingen ontstaan er afwijkingen.

   Dat is belangrijk, omdat AI en zoekmachines beter werken met pagina's die informatief voorspelbaar zijn. Als op één pagina dezelfde entiteit meerdere naamvarianten of andere beschrijvingen heeft afhankelijk van de datalaag, neemt het vertrouwen in het document af. Dat zie je niet altijd in een foutrapport, maar meestal merk je het later aan minder stabiele interpretatie.

   Praktische tip: voordat je nieuwe velden implementeert, doe een mini-audit van 20 URL's en noteer waar elke waarde daadwerkelijk vandaan komt. In veel projecten laat dit stadium al zien dat het probleem niet het schema is, maar het ontbreken van een „source of truth”.

3. Beoordeel of de markup bestand is tegen inhoudsbewerking door de redactie zonder tussenkomst van een developer

   Dit is een zeer praktische, maar zelden uitgevoerde test. Stel jezelf de vraag: wat gebeurt er met de gestructureerde data als een redacteur de titel, lead, volgorde van secties, co-auteur of de categoriebeschrijving wijzigt? Als elke dergelijke wijziging tot afwijkingen dreigt te leiden, is de implementatie fragiel.

   Waarom is dit belangrijk? Omdat inhoud op een echte site leeft. Updates zijn normaal, vooral bij vakartikelen, aankoopgidsen en categoriepagina's. Als het datamodel niet bestand is tegen het dagelijkse redactiewerk, ontstaan er na enkele maanden inconsistenties die niet meteen opvallen.

   Het overslaan van deze stap leidt er meestal toe dat het schema alleen op de dag van implementatie correct is. Daarna werkt de redactie sneller dan de kwaliteitscontrole. Uit ervaring werkt de regel het beste: semantisch kritieke velden moeten ofwel automatisch overgenomen worden van zichtbare paginacomponenten, of een duidelijke workflow in het CMS hebben.

4. Controleer of categoriepagina's hun eigen entiteitslogica hebben, en niet alleen een technische beschrijving van een productlijst

   Dit is vooral belangrijk waar een categorie niet alleen moet dienen voor het indexeren van producten, maar ook voor het ordenen van het onderwerp. In de praktijk verwaarlozen veel sites juist deze URL's, terwijl zij vaak topical authority opbouwen en gemengde zoekopdrachten bedienen: informatief met een koopcomponent.

   Neem een pagina als saturatiemeters en polsmeters of bloeddrukmeting. Als zo'n categorie inleidende tekst, secties die het gebruik uitleggen, productindelingen en logische ingangen naar subonderwerpen heeft, zou het schema dit moeten ondersteunen. Niet door overbelasting van tags, maar door een zinnig paginamodel als thematische bron.

   Als dit element wordt overgeslagen, zullen categorieën voor systemen slechts verzamelingen links zijn. Dat beperkt hun rol in het bouwen van context voor producten en gidsen. Praktisch: bekijk de vijf belangrijkste categorieën en beantwoord of hun markup hen onderscheidt van gewone filterlijsten. Zo niet, heb je ruimte voor verbetering.

5. Controleer of technische productgegevens alleen worden gemapt wanneer ze te onderhouden zijn zonder handmatig brandjes te blussen

   In theorie geldt: hoe meer productparameters in het schema, hoe beter. In de praktijk niet altijd. Als gegevens over model, compatibiliteit, meetbereik of accessoires uit meerdere bronnen komen en regelmatig wijzigen, is het makkelijk iets te publiceren dat over twee weken niet meer actueel is.

   Dit is een bijzonder gevoelig gebied bij specialistische en medische apparatuur. Het geldt ook voor categorieën zoals ECG-elektroden, waar varianten, compatibiliteit en specificaties vaker kunnen veranderen dan het contentteam verwacht. Als je de controle over dit proces overslaat, ontstaat er snel een discrepantie tussen de productpagina, de specificatietabel en de JSON-LD.

   Uit ervaring is het beter minder maar zeker te beschrijven. Een goede test is: weet iemand in de organisatie na wijziging van een parameter precies waar het bijgewerkt moet worden en wie daarvoor verantwoordelijk is? Als het antwoord onduidelijk is, moet het veldbereik worden beperkt.

6. Stel een procedure vast voor grensgevallen content: vergelijkingen, ranglijsten, aankoopgidsen en hybride landingspagina's

   De meeste fouten ontstaan niet bij klassieke artikelen of eenvoudige producten, maar bij pagina's die meerdere intenties tegelijk combineren. Een aankoopgids kan bijvoorbeeld tegelijk informeren, vergelijken en naar een aanbod leiden. Als zo'n paginatype geen aparte annotatielogica heeft, eindigt het met een generiek model dat niets goed communiceert.

   Waarom is dit belangrijk? Omdat juist deze pagina's vaak het grootste potentieel hebben voor AI Search: ze beantwoorden concrete vragen, synthetiseren verschillen en verbinden feiten met de aankoopbeslissing. Als ze te algemeen worden gemarkeerd, verliezen ze een deel van hun semantische voordeel, zelfs als de redactionele kwaliteit goed is.

   In de praktijk is het zinvol een lijst te maken van alle „niet-typische” templates en niet toe te staan dat ze automatisch in de BlogPosting-bak vallen. Dit is een van die gebieden waar een handmatige architectonische beslissing meer oplevert dan het blijven toevoegen van velden.

7. Controleer of afbeeldingen, grafieken en multimedia een zinvolle koppeling met de hoofdentiteit van de pagina hebben

   Veel implementaties richten zich op de tekst en negeren het feit dat systemen ook ondersteunende bronnen interpreteren. Als je een grafiek, productfoto, werkschema of vergelijkende afbeelding publiceert, is het goed om te controleren dat deze geen anonieme toevoegingen zijn zonder relatie tot het hoofdbeschreven object.

   Dit is vooral belangrijk bij technische en gidsachtige inhoud, waar een visueel element vaak drager is van concrete informatie. Als een afbeelding alleen in de layout bestaat, zonder zinvolle attributie en zonder ingebed te zijn in de datastructuur, krijgt het systeem minder context dan mogelijk zou zijn.

   Het gevolg van verwaarlozing is eenvoudig: de pagina wordt slechts gedeeltelijk correct geïnterpreteerd en belangrijke inhoudelijke elementen versterken de interpretatie van het document niet. Uit de praktijk: je hoeft niet alles te modelleren. Het volstaat de belangrijkste pagina's door te nemen en te controleren of de hoofdafbeelding, grafiek of ondersteunend materiaal daadwerkelijk de hoofdentiteit ondersteunt en niet ernaast bestaat.

8. Test de overeenstemming tussen de canonieke versie, de gerenderde versie en de na JavaScript zichtbare versie

   Dit is een technisch punt, maar zeer praktisch. In sommige sites ziet het schema er goed uit in de broncode van één versie van de pagina, maar anders na renderen, bij lazy-loading of op varianten met parameters. Voor het team is dit vaak onzichtbaar, omdat de test slechts op één weergave van het document is uitgevoerd.

   Waarom is dit kritiek? Omdat bij moderne frontends gemakkelijk de situatie ontstaat dat een bot een andere set gegevens ziet dan de gebruiker of validator. Dan wordt de diagnose moeilijk en komt het probleem pas naar voren na een grotere daling van de datakwaliteit of na een migratie.

   Als je deze stap overslaat, kun je lange tijd op een foutieve veronderstelling werken dat de implementatie stabiel is. Uit ervaring werkt het het beste om niet alleen de hoofdpagina van het template te testen, maar ook varianten met paginering, filters, AMP indien aanwezig, de mobiele versie en de cache na het doorvoeren van wijzigingen.

9. Controleer of de gestructureerde data de logica van interne linking ondersteunen, in plaats van ernaast te bestaan

   Markup mag niet los functioneren van de linkarchitectuur. Als een pagina een onderwerp beschrijft maar niet logisch leidt naar gerelateerde categorieën, producten, auteurs of aanvullende content, krijgt het systeem een zwakker contextsignaal. Gestructureerde data helpen, maar vervangen geen zinvolle relaties binnen de site.

   Dit is vooral belangrijk waar je educatie met aanbod wilt verbinden. Bijvoorbeeld: als een gids gaat over monitoringparameters en natuurlijk leidt naar secties over saturatiemeters en polsmeters of bloeddrukmeting, zouden semantische en linkrelaties hetzelfde moeten communiceren.

   Als je dit verwaarloost, krijg je het klassieke probleem: goede individuele pagina's maar een zwakke kennisgrafiek binnen de site. Praktische tip: open tijdens de audit 10 sleutel-URL's en controleer of hun verbanden consistent zijn in content, links en markup tegelijk. Zo niet, ligt het probleem dieper dan alleen in de JSON-LD.

10. Stel een set semantische regressietests vast vóór elke redesign en templatewijziging

    De meeste teams hebben een checklist voor UX, performance en visuele fouten. Weinig teams hebben een aparte checklist voor de semantische laag. En juist na redesigns verdwijnen vaak relaties, raken identifiers kapot, veranderen auteuradressen of dupliceren objecten.

    Dit punt is belangrijk omdat zelfs een zeer goede implementatie waarde verliest als niemand die controleert na grote technische wijzigingen. Het probleem is niet altijd spectaculair. Vaak is er een paar weken niets te zien en blijkt later dat een deel van de sleutel-URL's een armer of beschadigd markup heeft.

    Uit de praktijk werkt een vaste set controleadressen het beste: 3–5 URL's per belangrijk paginatype. Die set is het waard om te draaien na elke grote wijziging van de frontend, CMS-logica of feedintegraties. Dat bespaart later veel tijd.

11. Controleer of profielen van auteurs en experts klaar zijn voor hergebruik in verschillende contexten

    Het gaat niet alleen om dat een auteur een bio-pagina heeft. Je moet controleren of het profiel voldoende compleet is om op zinvolle wijze aan verschillende content gekoppeld te worden zonder compromitterende leemtes. Als een auteur technische artikelen, categoriebeschrijvingen en gidsen publiceert, moet zijn entiteit dat semantisch kunnen dragen.

    Waarom is dit belangrijk? Omdat in expert-sites auteurs vaak de enige echte dragers van inhoudelijke verantwoordelijkheid zijn. Als het profiel pover, verouderd of inconsistent met publicaties is, verzwakt dat niet alleen E-E-A-T. Het bemoeilijkt ook dat AI herkent wie en vanuit welke positie over een onderwerp spreekt.

    Het gevolg van het overslaan van dit gebied is vaak een vreemde asymmetrie: uitstekend uitgewerkte contentpagina's en zeer zwakke persoonsentiteiten. Praktische conclusie uit audits: een goed voorbereid auteurprofiel moet als een apart strategisch bezit worden gecontroleerd, niet als een redactionele voettekst.

12. Controleer of het schema antwoorden ondersteunt op vragen die daadwerkelijk in AI Search voorkomen

    Dit is een strategisch punt. Bekijk je eigen content en controleer welke ervan antwoord geven op vergelijkings-, definities-, procedure- of diagnostische vragen. Beoordeel vervolgens of de gestructureerde data het systeem helpen snel onderwerp, auteur, onderwerp van beschrijving en de context van de pagina te identificeren.

    Waarom is dit belangrijk? Omdat citeerbaarheid door AI zelden alleen uit de aanwezigheid van een tag voortkomt. Het neemt meestal toe waar de inhoud een concrete vraag beantwoordt en het schema ambiguïteit vermindert. Als een document inhoudelijk goed is maar semantisch te algemeen, kan het worden overgeslagen ten gunste van eenvoudigere, maar beter ingebedde bronnen.

    Als je deze stap overslaat, blijft de implementatie technisch maar wordt hij niet afgestemd op reële zoekscenario's. Uit ervaring is het zinvol 10 vragen uit PAA, AI Overview of Perplexity te nemen en handmatig te beoordelen of de aangegeven pagina's er echt uitzien als bronnen die klaar zijn voor gebruik in synthetische antwoorden.

Een korte tip tot slot

Als je na het doorlopen van de checklist ineens een dozijn tekortkomingen tegelijk ziet, verbeter dan niet alles tegelijkertijd. Werk eerst de pagina's met de grootste waarde bij: hoofdcategorieën, belangrijke gidsen, auteurprofielen en de belangrijkste producten. In de praktijk zijn het juist die pagina's die het snelst laten zien of het datamodel echt zichtbaarheid en citeerbaarheid ondersteunt, of alleen de hoeveelheid code vergroot.

Trends, marktveranderingen en de richting van de ontwikkeling van gestructureerde data voor AI

De interessantste veranderingen rond Schema.org gaan niet meer over de vraag of je gestructureerde data moet implementeren, maar over hoe nauwkeurig je ze koppelt aan systemen die verantwoordelijk zijn voor hybride zoekresultaten: klassieke resultaten, AI-overzichten, conversationele antwoorden en engines die bronnen citeren. De markt beweegt duidelijk weg van de benadering „markup voor rich results” en richting het modelleren van informatie die gemakkelijk te verifiëren, te citeren en in te passen is in een breder entiteiten‑graph.

Vanuit SEO‑perspectief zijn GEO en AI Search een belangrijke verschuiving. Nog niet zo lang geleden zagen veel bedrijven schema als een technisch extraatje bovenop een kant en klare pagina. Nu wordt het steeds vaker een onderdeel van contentontwerp, informatiearchitectuur en de entiteitenlaag vanaf het eerste begin. De reden is simpel: systemen die antwoorden genereren hebben niet alleen het document nodig, maar ook een duidelijke context wie er spreekt, waarover en op welke basis.

1. Verplaatsing van „zichtbaarheid in de SERP” naar „leesbaarheid voor antwoordsystemen”

Dit is tegenwoordig een van de sterkste marktveranderingen. Gestructureerde data worden niet langer uitsluitend beoordeeld op de vraag of een pagina een uitgebreid resultaat genereert. Steeds vaker wordt hun waarde gemeten aan de hand van of ze systemen helpen een entiteit, relatie en de reikwijdte van een antwoord te begrijpen. De bron van deze verschuiving is de manier waarop content wordt geconsumeerd. Gebruikers krijgen steeds vaker een kant en klaar samenvatting, een lijst aanbevelingen of een synthetisch antwoord nog vóór ze doorklikken.

Voor bedrijven heeft dat harde consequenties: alleen aanwezigheid in de index is niet genoeg. Je moet informatie leveren in een vorm die eenduidig te mappen is. Dat geldt vooral voor expertcontent, vergelijkingen, categoriepagina's en productkaarten, waar dubbelzinnigheid snel kan optreden. Als een site specialistische apparatuur of meetprocedures beschrijft, zal AI vaker bronnen kiezen die duidelijke entiteiten, stabiele naamgeving en consistente attributen hebben.

In de praktijk is dat vooral zichtbaar in projecten waar content en catalogus als één kennisl laag worden behandeld. Een goed georganiseerde thematische sectie over bloeddrukmeting kan tegenwoordig niet alleen werken op klassieke categorietermen, maar ook op vragen in conversatiestijl, als de semantische laag voldoende leesbaar is.

Uit marktobservatie: winnen doen niet de sites met „het meeste schema”, maar die welke dubbelzinnigheid beperken. Dat is een subtiel maar zeer reëel voordeel.

2. Toenemend belang van entiteiten en relaties boven een enkele URL

Een andere trend is het loslaten van het denken in pagina's als geïsoleerde eenheden. In de praktijk wordt steeds meer belangrijk of een organisatie herhaalbare entiteiten door de hele site kan beschrijven: auteurs, producten, themagebieden, merken, toepassingen, parameters. Dat komt door de volwassenheid van algoritmes gebaseerd op begrip van entiteiten en door de groeiende rol van systemen die informatie uit meerdere documenten combineren in plaats van een enkele tekst in isolatie te beoordelen.

Voor de gebruiker is het effect eenvoudig: sites die consequent een onderwerp opbouwen worden beter geïnterpreteerd dan sites die losstaande content publiceren. Voor bedrijven betekent dit dat men op clusterniveau moet werken, niet op het niveau van een individuele blogpost. Heeft een merk aparte educatieve content, categorieën, vergelijkingen en productkaarten, dan moeten gestructureerde data deze elementen aan elkaar koppelen in één kennismodel.

Praktische consequentie? Een schema‑audit begint steeds meer op een audit van een entiteiten‑graph te lijken, en niet alleen op een controle van JSON‑LD‑syntaxis. Je moet controleren of hetzelfde product, dezelfde auteur of hetzelfde onderwerp niet onder verschillende naamvarianten voorkomt en of het systeem geen relaties tussen secties van de site verliest.

In sector‑projecten is dit goed zichtbaar bij aanbiedingen rondom apparaten zoals holters. De productcategorie an sich bouwt nog geen volledige betekenis. Pas de koppeling met uitlegcontent over toepassingen, parameters en diagnostische context levert een laag op die AI beter kan benutten.

Uit ervaring: bedrijven die hun eigen entiteiten het eerst ordenden, schalen content voor AI Search nu makkelijker. De rest ontdekt dat het probleem niet in het artikeltemplate zit, maar in de inconsistentie van de hele site.

3. Gestructureerde data dichter bij bron­systemen, verder weg van handmatige „SEO‑overlays”

Enkele jaren geleden functioneerden veel implementaties als een laag bovenop het CMS: een plugin, module of externe generator. Dat model heeft op eenvoudige sites nog steeds zin, maar op een meer ontwikkelde markt is verandering zichtbaar. Schema wordt steeds vaker gevoed direct vanuit datamodellen, PIM‑systems, headless CMS’en, entiteitsrepositories en productcomponenten. De reden is praktisch: handmatig onderhoud houdt geen gelijke tred met het tempo van veranderende content, catalogi en templates.

Dat raakt het businessmodel concreet. Sites met geordende bronnen van waarheid voor namen, parameters, auteurs en relaties reageren veel sneller op veranderingen in zoekmachines. Sites die op semi‑automatische omwegen vertrouwen produceren vaker semantische afwijkingen bij migraties en redesigns.

Voor de gebruiker is dat niet direct zichtbaar, maar de effecten zijn voelbaar: betere consistentie van informatie tussen secties, minder tegenstrijdige data en een grotere kans dat gegenereerde antwoorden accuraat zijn. Voor marketing‑ en SEO‑teams betekent dit ook een wijziging van competenties. Het draait steeds minder om het louter „toevoegen van een tag” en steeds meer om samenwerking met development, content design en data‑eigenaren.

Markttechnisch een belangrijk signaal: bedrijven die investeren in informatiearchitectuur en datamodellen zullen een duurzamer voordeel hebben dan bedrijven die zich uitsluitend richten op snelle plugin‑implementaties.

4. Groeiende rol van vergelijkende, instructieve en beslissingsondersteunende content als brandstof voor AI Search

De gedragsverandering van gebruikers is hier duidelijk zichtbaar. Zoekopdrachten worden langer, probleemgerichter en vaker meerstaps. De gebruiker typt niet langer alleen een categorienaam, maar vraagt naar verschillen, gebruiksscenario's, beperkingen en afstemming op een specifiek geval. Dat heeft invloed op hoe gestructureerde data eruit moeten zien en welke rol ze vervullen.

De bron van deze trend is een combinatie van twee fenomenen: het gemak van conversatie met AI en de dalende tolerantie voor het doorklikken door veel vergelijkbare pagina's. Daardoor neemt de waarde toe van documenten die besluitvorming structureren. Het gaat niet alleen om klassieke handleidingen. Sites zoals „hoe kies je”, vergelijkingen tussen productklassen, parameter‑gidsen en secties die toepassingen uitleggen werken ook heel goed.

Voor bedrijven betekent dit dat informatie beter gemodelleerd moet worden op het snijvlak van content en aanbod. Verkooppagina's zonder context zullen het vaker afleggen in de synthetische antwoordfase tegen materiaal dat verschillen duidelijk uitlegt. Als het aanbod apparaten omvat zoals pulsoximeters en hartslagmeters, volstaat een productlisting zelden bij vragen over selectie, interpretatie van parameters of huishoudelijk versus professioneel gebruik.

De praktische consequentie voor SEO en GEO is dat de relevantie van clusters die op mixed intenties inspelen — informatief, vergelijkend en pre‑aankoop — toeneemt. Deze content wordt het vaakst „geplukt” door taalmodellen omdat het besluitvormend materiaal bevat, niet slechts assortimentbeschrijvingen.

Uit de markt: waar content helpt een keuze te maken, stijgt de citeerbaarheid duidelijker dan waar een site alleen opties presenteert.

5. Minder tolerantie van systemen voor onnauwkeurige beweringen en semantische overdaad

Veel site‑eigenaren gaan er nog steeds van uit dat het uitbreiden van schema met extra eigenschappen altijd voordelig is. De markt laat iets anders zien. Naarmate systemen beter lagen data en content met elkaar vergelijken, stijgt de kost van semantische overbelasting: te brede claims, automatische omschrijvingen, onbevestigde relaties en velden gevuld „omdat het kan”.

Dit verschijnsel vloeit voort uit de volwassenwording van kwaliteitsbeoordelingsmechanismen. Als een systeem meer bronnen ziet, detecteert het makkelijker inconsistenties en baseert het minder snel een antwoord op een pagina die te veel claimt vergeleken met de daadwerkelijke inhoud. Voor het bedrijfsleven is de eenvoudige conclusie: schema zal meer op een bewijslayer gaan lijken dan op een declaratieve laag.

Praktisch resultaat? In audits zal het belang van het reduceren van lage‑kwaliteitsvelden toenemen, niet alleen het toevoegen van nieuwe. Dat is misschien weinig spektaculair, maar operationeel zeer verstandiger. Sommige teams zullen moeten overschakelen van een aanpak van „volledige dekking van eigenschappen” naar „een gecontroleerde set van de meest betrouwbare data”.

Uit eigen observatie: de meest toekomstbestendige implementaties zijn meestal zuiniger dan indrukwekkend. Ze claimen minder, maar doen dat wel consequent over de hele site.

6. Integratie van gestructureerde data in het content‑updateproces

Ook operationeel is een verandering steeds duidelijker. Gestructureerde data stoppen met een eenmalig project te zijn. Ze worden onderdeel van content governance. Dat is een natuurlijke consequentie in een markt waar versheid, conformiteit en het vermogen om informatie snel te corrigeren na een wijziging van een product, parameter, auteur of redactionele richtlijn tellen.

Voor teams betekent dat de noodzaak om eenvoudigere maar regelmatige processen in te voeren: entiteitreviews, controle van identificatoren, tests na publicatie en monitoring na technologische wijzigingen. Het gaat niet om het opzetten van zware corporate procedures. Het gaat erom dat schema samen met content leeft.

Voor gebruikers is dat goed nieuws omdat het de consistentie van materiaal verbetert en situaties beperkt waarin de ene sectie van de site iets anders beweert dan de andere. Voor bedrijven is het ook een bescherming tegen verlies van zichtbaarheid na ogenschijnlijk onschuldige wijzigingen in het CMS, template of productintegraties.

De markt zal organisaties belonen die content‑ops met semantiek weten te verbinden. In de praktijk betekent dat dat redactie, SEO en development dichter moeten samenwerken dan twee jaar geleden.

7. De groeiende rol van E‑E‑A‑T in een machineleesbare laag

Het gaat er niet om dat Schema.org de kwaliteitsbeoordeling van een auteur of organisatie „zal vervangen”. Het gaat erom dat systemen steeds meer gebruikmaken van signalen die makkelijk te vergelijken en te aggregeren zijn op grote schaal. Daarom zullen gegevens over auteurschap, organisatie, specialisatie, publicatie en updates aan belang winnen als elementen die vertrouwen ordenen.

De bron van deze verandering is helder: met het toenemende volume van snel en massaal geproduceerde content hebben systemen eenvoudigere methoden nodig om te beoordelen wie achter materiaal staat en hoe stabiel het profiel van een bron is. Voor bedrijven betekent dat praktisch de noodzaak om auteursprofielen, een sectie over de organisatie en duidelijke relaties tussen uitgever en content uit te bouwen. Niet als versiering in de footer, maar als een samenhangend onderdeel van het informatiemodel.

Voor gebruikers zal het effect indirect maar belangrijk zijn: materialen die toe te wijzen zijn aan concrete vakverantwoordelijkheid worden vaker zichtbaar en geciteerd. In specialistische sectoren is dit al geen optie meer; het wordt een voorwaarde voor concurrentiekracht.

Vanuit de markt voor expertisecontent: de voorsprong groeit voor merken die competenties kunnen aantonen niet alleen in taal van de content, maar ook in datastructuur, auteursrelaties en publicatiestabiliteit.

Wat dit verder in de praktijk betekent

De meest waarschijnlijke ontwikkelingsrichting is niet spectaculair, maar zeer concreet. Er komt minder ruimte voor toevallige schema‑implementaties en meer voor semantisch beheerde sites. Het belang zal toenemen van:

• het ontwerpen van entiteiten al in de fase van informatiearchitectuur,

• het koppelen van gestructureerde data aan CMS, PIM en productiesystemen,

• content die antwoord geeft op vergelijkende en beslissingsgerichte vragen,

• gecontroleerde reductie van lage‑kwaliteitsvelden,

• het behouden van consistente signalen over auteurschap en organisatie,

• het meten van effecten ook buiten rich results, gericht op citeerbaarheid en gebruik in AI Search.

Als ik één realistische prognose voor de nabije toekomst zou moeten geven, is het deze: gestructureerde data zullen steeds minder worden beschouwd als een op zichzelf staande SEO‑tactiek en steeds meer als contentinfrastructuur voor zoekmachines, antwoordsystemen en engines die bronnen citeren. Bedrijven die dit eerder begrijpen, bouwen sneller topical authority op, bedienen zero‑click search beter en vergroten de kans om in AI‑antwoorden aanwezig te zijn zonder volledig afhankelijk te zijn van klassieke klikken vanuit Google.

Eindconclusies

Goed ontworpen gestructureerde data zijn tegenwoordig minder een kwestie van „de pagina markeren”, en meer een toets of de organisatie haar kennis beheerst. Als inhoud, auteurschap, categorieën, producten, databronnen en interne links een coherent systeem vormen, wordt Schema.org een natuurlijke verlenging van die architectuur. Als er daarentegen informatiechaos op de site heerst, onthult de markup meestal juist die chaos — soms op een manier onzichtbaar voor een validator, maar zeer duidelijk voor algoritmen die documenten classificeren.

De meest praktische conclusie is eenvoudig: een effectieve implementatie begint niet met de keuze van het schema-type, maar met de beslissing wat een bepaalde subpagina werkelijk representeert. Een deskundige gids moet anders worden beschreven dan een productcategorie, en weer anders dan een productpagina of een auteurprofiel. Op sites die verkoop met educatie combineren is dit verschil bijzonder belangrijk. Een categorie zoals holters is niet louter een productlijst als zij tegelijk de gebruiker helpt het gebruik van de apparaten, de verschillen tussen modellen en de diagnostische context te begrijpen. Evenzo kunnen secties over EKG-elektroden, oximeters en hartslagmeters of apparaten voor bloeddrukmeting fungeren als semantische knooppunten, mits ze adequaat verbonden zijn met handleidingsinhoud, producten en een betrouwbaar deskundig fundament.

In de praktijk hebben niet de sites die het meest uitgebreide schema implementeren de voorkeur, maar diegene die precisie over jaren kunnen behouden. Het is het verschil tussen een eenmalige optimalisatie en volwassen informatiebeheer. AI-modellen, hybride zoekmachines en systemen die antwoorden genereren beoordelen betrouwbaarheid steeds vaker niet op basis van één signaal, maar op basis van consistentie: bestaat de auteur als een herkenbare entiteit, heeft het product stabiele gegevens, is de categorie logisch ingebed in de sitestructuur, en zorgen inhoudsupdates niet voor discrepanties tussen wat de gebruiker ziet en wat de machine leest.

Vanuit het perspectief van projecten op grotere sites is ook zichtbaar dat de grootste problemen zelden voortkomen uit JSON-LD zelf. Vaker zijn processen de bron van fouten: geen eigenaar van de data, inconsistente velden in het CMS, automatiseringen die verouderde informatie kopiëren, migraties uitgevoerd zonder controle van de semantische laag. Daarom zou een goede audit van gestructureerde data niet alleen de code moeten omvatten, maar ook de manier waarop content tot stand komt, de informatievoorziening tussen teams en de veerkracht van het hele systeem tegen technische veranderingen.

Zoeken beweegt richting synthetische antwoorden, vergelijkingen, aanbevelingen en het interpreteren van de intentie van de gebruiker zonder dat men door veel resultatenpagina's hoeft te gaan. In zo'n omgeving is alleen aanwezigheid in de index niet voldoende. De site moet voor algoritmen gemakkelijk te begrijpen, betrouwbaar en semantisch consistent zijn. Gestructureerde data zullen geen degelijke inhoud of de ervaring van experts vervangen, maar ze kunnen ervoor zorgen dat die kennis correct wordt herkend, gekoppeld aan de juiste entiteiten en gebruikt in de juiste context.

De meest verstandige aanpak is het bouwen van een eenvoudig, gecontroleerd model dat je kunt uitbreiden zonder kwaliteitsverlies. Beter minder gemarkeerde velden te hebben, maar volledig in overeenstemming met de inhoud en regelmatig onderhouden, dan een uitgebreid graf dat later door niemand kan worden overzien. Schema.org werkt het beste wanneer het een stille, stabiele kennisinfrastructuur is — onzichtbaar voor de gebruiker, maar ordenend voor de hele site op een manier die begrijpelijk is voor zoekmachines, AI-systemen en de mensen die er verantwoordelijk voor zijn.