Je structured data is stuk en je validator zegt van niet

Structured data die een validator goedkeurt, kan alsnog stuk zijn: een validator controleert syntaxis, niet of de inhoud klopt of zichtbaar op de pagina staat. Op onze eigen site meldde Search Console één ontbrekend mainEntity-veld; bij het narekenen zaten er twee grotere fouten in waar geen enkele tool over klaagt. Eén script over je gebouwde HTML vangt ze alle drie.

De melding zelf was klein: drie profielpagina’s, opgelost in tien minuten. Daarna ben ik gaan narekenen of de rest wel klopte. Dat had ik beter meteen kunnen doen.

Waarom je dit niet ziet

Een validator controleert of je JSON-LD geldig is. Of de haakjes kloppen, of de types bestaan, of de verplichte velden gevuld zijn. Dat is een syntaxcontrole, en die zegt niets over de vraag of er zinnige inhoud in staat.

Concreet: de Schema Markup Validator van schema.org keurt een FAQ-antwoord goed waarin letterlijk [SEO Maastricht](/seo-maastricht) staat. Geldige JSON, gevuld tekstveld, groen vinkje. Google’s eigen Rich Results Test doet hetzelfde voor de types die het nog ondersteunt: het controleert of je markup in aanmerking komt, niet of de tekst klopt (Google Search Central). Dat de bezoeker daar rauwe markdown ziet en Google een kapotte zin, merkt geen enkele tool.

Zolang je pagina voor pagina in een validator plakt, blijf je dit soort dingen missen. Je test op de verkeerde vraag.

Fout 1: blokken die je met @id aan elkaar dénkt te knopen

Dit was de melding. Onze profielpagina’s zetten twee losse ld+json-blokken neer. Eén ProfilePage met de paginagegevens, en daarnaast een Person met naam, functie, foto en socials. Die twee waren verbonden via een @id-verwijzing, netjes volgens het boekje.

Google leest een ProfilePage alleen als profielpagina wanneer mainEntity naar de persoon wijst; het is het enige verplichte veld van dat type (Google Search Central). Dat veld stond er niet. De Person stond er wel, twee regels verderop, met een @id dat naar dezelfde pagina wees. Voor mij duidelijk. Voor de parser niet.

Google merget nodes over meerdere scripts heen meestal wel op @id, maar bij de rich-result-controles is dat geen zekerheid. De veilige vorm is nesten:

{
  "@type": "ProfilePage",
  "@id": "https://synflow.nl/overons/chris#webpage",
  "mainEntity": {
    "@type": "Person",
    "@id": "https://synflow.nl/overons/chris#person",
    "name": "Chris Kettmann",
    "jobTitle": "Oprichter"
  }
}

Zelfde informatie, één blok, geen aanname over hoe slim de parser is. Het kost je niets om het zo te doen.

Fout 2: markdown in een veld dat geen markdown leest

Deze was groter. Onze landingspagina’s hebben allemaal een FAQ, en die vragen en antwoorden staan in de frontmatter van het contentbestand. In een aantal van die antwoorden staan interne links, want dat was het hele idee: vanuit een antwoord doorverwijzen naar de stadspagina of de dienst waar het over gaat.

Alleen gaat zo’n frontmatterveld nergens door een markdown-renderer. Het is een string, en die string werd rechtstreeks in de pagina gezet en rechtstreeks in de JSON-LD. Resultaat op beide plekken:

Voor stad-specifieke pagina's: [SEO Maastricht](/seo-maastricht),
[SEO Roermond](/seo-roermond) en meer.

De omvang bleek groter dan ik had gegokt. Over de hele site staan 389 FAQ-antwoorden. Daarvan hadden er 54 dit probleem, samen goed voor 88 links, verspreid over 30 pagina’s. Die 88 interne links bestonden dus niet. Ze stonden er als tekst, ze telden nergens mee, en de bezoeker las de haakjes gewoon mee.

Dat laatste is het pijnlijkste deel. Dit was geen technisch detail diep in de broncode. Dit stond zichtbaar in de tekst op dertig pagina’s, en niemand van ons had het gezien. Ook ik niet, en ik heb die pagina’s zelf opgeleverd.

Wat je in dat veld wél kwijt kunt: de FAQ-documentatie die Google tot juni 2026 online had, stond in het antwoordveld een kleine set HTML toe. Daaronder <a>, <p>, <br>, lijsten en de gebruikelijke nadrukken. Alleen wilde het daar volledige URL’s zien, geen relatieve paden. Die documentatie is inmiddels verwijderd (Google Search Central), maar het schema.org-type FAQPage bestaat gewoon nog (schema.org) en andere lezers dan Google hanteren dezelfde regel: een link is pas een link als hij absoluut is. De oplossing was één helper die de tekst escapet en [tekst](/pad) omzet naar een echte link, met absolute URL voor de JSON-LD en relatief voor de pagina zelf.

Na de fix stonden er 89 zichtbare interne links op de site die er de dag ervoor niet waren. Dat is geen SEO-tactiek, dat is een bug die sinds mei meeliep.

Fout 3: schema dat iets anders beweert dan de pagina

Deze zat er bij ons niet in, maar ik kom hem bij vrijwel elke audit tegen, dus hij hoort in dit rijtje.

Een plugin of een template zet een FAQ-blok in de JSON-LD dat nergens op de pagina staat. Soms omdat iemand vond dat de vragen de opmaak verpestten, vaker omdat de plugin een apart invulveld heeft en de bouwer niet doorhad dat die inhoud ook zichtbaar moet zijn.

Google is daar expliciet over: structured data moet een waarheidsgetrouwe weergave van de pagina zijn, en je markeert geen inhoud die de lezer niet ziet (Google Search Central). Verborgen FAQ-markup is geen slordigheid maar een overtreding van de richtlijnen, en het is precies het soort ding waar een handmatige maatregel op volgt. Zo’n maatregel kost je de rich results van die pagina, niet je ranking, zegt diezelfde richtlijn.

Zelfde categorie: Product-markup met een prijs die niet meer klopt, AggregateRating op reviews die nergens staan, LocalBusiness met openingstijden uit 2023. Allemaal geldige JSON.

Hoe je het dan wel controleert

Niet met een validator, of in elk geval niet alleen. Wat werkt is één script over je gebouwde HTML dat elk ld+json-blok uit elke pagina trekt, parst, en op patronen zoekt. Bij ons was dat twintig regels Python en een minuut werk.

Waar je op zoekt:

1. Markdown in tekstvelden. Zoek op [...](...) en op losse sterretjes in elk stringveld. Als je content uit frontmatter of een CMS-veld komt, is de kans groot dat er ergens opmaak in zit die nooit gerenderd wordt.
2. Verplichte en aanbevolen velden per type. Voor elk type dat je gebruikt: staat mainEntity erin bij FAQPage en ProfilePage. Bij Article en BlogPosting verplicht Google niets, maar author, datePublished, headline en image staan op de aanbevolen lijst (Google Search Central); controleer of ze gevuld zijn.
3. Verwijzingen die nergens heen gaan. Elk @id waarnaar je verwijst, moet ook echt als node bestaan. Een verwijzing naar een #organization die je op die pagina niet meestuurt, is een dood eind.
4. Schema tegen zichtbare tekst. Strip de scripts uit de HTML en controleer of de vragen uit je FAQPage ook in de body voorkomen. Dit vangt fout 3 in één keer voor je hele site.

De winst zit hem erin dat je dit over alle pagina’s tegelijk draait, en dat je het na elke build opnieuw kunt draaien. Wij hebben 114 pagina’s, dus handmatig controleren was nooit gebeurd. Nu is het een commando.

Waarom dit meer gaat tellen dan het lijkt

Als je nu denkt dat een kapotte FAQ-markup weinig kost, heb je voor Google gelijk. Vanaf augustus 2023 toonde Google FAQ-rich-results alleen nog bij overheids- en gezondheidssites, en op 7 mei 2026 stopte het er helemaal mee; in juni verdwenen ook het rapport in Search Console en de ondersteuning in de Rich Results Test (Google Search Central). Dat blok levert in de SERP niets meer op.

Dat is precies waarom het de moeite is om er nu naar te kijken, en niet waarom het niet hoeft.

Die JSON-LD wordt namelijk nog steeds gelezen, alleen niet meer alleen door de zoekmachine. Een taalmodel dat jouw pagina samenvat, pakt liever een schoon machineleesbaar blok dan een pagina vol HTML. En anders dan Google’s parser, die jarenlang op rommelige input is getraind en veel stilzwijgend rechttrekt, neemt zo’n model letterlijk over wat er staat. Als jouw prijs, werkgebied of dienstomschrijving daar verkeerd in staat, is dat wat er wordt naverteld.

Rich results waren de zichtbare beloning voor nette markup. Die beloning is voor de meeste sites weggevallen, en het gevolg is dat bijna niemand zijn structured data nog controleert. Ondertussen is het publiek dat ernaar kijkt groter geworden.

Meer over hoe die verschuiving werkt staat in Waarom AEO het nieuwe SEO is, en het bestand dat daar vaak in één adem bij genoemd wordt behandel ik in Wat is llms.txt.

Waar ik zou beginnen

Draai dat script over je eigen site voordat je iets anders aanpakt. Niet omdat het spannend is, maar omdat je binnen een minuut weet of je hier een probleem hebt. Bij ons was het antwoord ja, op een site die we zelf gebouwd hebben en waarvan ik dacht dat hij op orde was.

Kom je er niet uit, of wil je dat iemand meekijkt: het hoort bij SEO & AEO, en wat er verder bij komt kijken staat op AEO bureau.

Bronnen

1. General structured data guidelines, Google Search Central, 2025
2. Introduction to structured data markup in Google Search, Google Search Central, 2025
3. Profile page (ProfilePage) structured data, Google Search Central, 2025
4. Article (Article, NewsArticle, BlogPosting) structured data, Google Search Central, 2025
5. Google Search Central documentation updates (FAQ rich result deprecation, mei en juni 2026), Google Search Central, 2026
6. Rich Results Test, Google, 2026
7. Schema Markup Validator, schema.org, 2026
8. FAQPage, schema.org, 2026