Gestructureerde gegevens valideren zonder Google-tools

Validatie van gestructureerde gegevens is merkwaardig afhankelijk geworden van tools die op Google zijn gericht. Dat is begrijpelijk: veel teams voegen JSON-LD toe omdat ze rich results willen, en de testtools van Google zijn vertrouwd. Maar gestructureerde gegevens zijn geen Google-formaat. Meestal gaat het om JSON-LD met Schema.org-vocabulaire, ingebed in HTML, geïnterpreteerd door veel verschillende afnemers en onderhouden via je eigen publicatieworkflow.

Als je alleen valideert door de lens van een zoekmachine, kun je basale problemen missen: ongeldige JSON, gegevens die na rendering verdwijnen, verouderde productprijzen, conflicterende canonieke URL’s, of markup die technisch geldig is maar semantisch onzinnig.

Een betere workflow begint bij standaarden. Valideer de gegevens als gegevens, valideer daarna de vocabulaire en valideer vervolgens de pagina zoals die in productie bestaat.

Wat valideer je eigenlijk?

“Gestructureerde gegevens” zijn niet één ding. Op de meeste websites bestaan ze uit vier lagen:

1. JSON-syntaxis — is de code parsebaar?
2. JSON-LD-model — expandeert het naar betekenisvolle linked data?
3. Schema.org-vocabulaire — zijn de typen en eigenschappen plausibel?
4. Waarheid op paginaniveau — komt de markup overeen met wat gebruikers en crawlers kunnen zien?

Google-tools richten zich vooral op de vierde laag plus Google-specifieke geschiktheid voor rich results. Nuttig, ja. Volledig, nee.

Dit kan bijvoorbeeld geldige JSON-LD zijn en toch slechte gestructureerde gegevens opleveren:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Best winter jackets",
  "datePublished": "2026-01-12",
  "author": {
    "@type": "Organization",
    "name": "Editorial Team"
  }
}

Hier is niets stuk. Maar als de zichtbare pagina een andere kop heeft, geen auteursvermelding toont en een datum voor laatst gewijzigd heeft die de markup tegenspreekt, heb je een kwaliteitsprobleem in plaats van een syntaxisprobleem.

Stap 1: Parse de JSON voordat je aan SEO denkt

Begin met de saaie controle: kan de JSON worden geparset?

JSON-LD die in HTML is ingebed, gaat vaak stuk door kleine templatefouten:

• afsluitende komma’s
• niet-geëscapete aanhalingstekens in productnamen
• ongeldige regeleinden binnen strings
• ontbrekende accolades na conditionele velden
• dubbele scriptblokken door layout-overerving
• CMS-plugins die gedeeltelijke objecten uitvoeren

Voor lokale controles heb je geen SEO-platform nodig. Gebruik de tools die al in je ontwikkelstack zitten.

In JavaScript:

const blocks = [...document.querySelectorAll('script[type="application/ld+json"]')];

for (const block of blocks) {
  try {
    JSON.parse(block.textContent);
  } catch (error) {
    console.error('Invalid JSON-LD:', error.message, block);
  }
}

Extraheer in CI de scriptinhoud uit gerenderde HTML en parse die als JSON. Dit vangt veel problemen op voordat ze productie bereiken.

Het belangrijke punt: doe dit vóór elke Schema.org-validatie. Een vocabulairevalidator kan niet helpen als de gegevens geen geldige JSON zijn.

Stap 2: Controleer JSON-LD-gedrag, niet alleen JSON-syntaxis

Geldige JSON is niet automatisch geldige JSON-LD. JSON-LD gebruikt concepten zoals @context, @type, @id en graafrelaties. Als die verkeerd zijn gevormd, kunnen parsers je gegevens anders interpreteren dan je bedoelde.

Bevestig minimaal:

• dat elk blok een passende @context heeft
• dat primaire entiteiten duidelijke @type-waarden hebben
• dat herhaalde entiteiten waar nuttig stabiele @id-waarden gebruiken
• dat geneste entiteiten logisch met elkaar verbonden zijn
• dat arrays worden gebruikt wanneer meerdere waarden mogelijk zijn

Voor grotere sites zijn stabiele identificatoren bijzonder nuttig. Als je organisatie voorkomt in Article-, Product-, BreadcrumbList- en FAQPage-gegevens, helpt het gebruik van dezelfde @id afnemers te begrijpen dat dit verwijzingen zijn naar dezelfde entiteit, en niet vier losstaande organisaties met dezelfde naam.

Een typisch patroon ziet er zo uit:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Ltd",
  "url": "https://example.com/"
}

Je probeert hier geen validator te imponeren. Je maakt je gegevens minder dubbelzinnig.

Stap 3: Valideer tegen de Schema.org-vocabulaire

Zodra de JSON- en JSON-LD-structuur solide zijn, controleer je de vocabulaire.

De Schema.org-validator is nuttig omdat die toetst aan Schema.org-termen in plaats van aan de rich-result-regels van één zoekmachine. Hij kan laten zien of eigenschappen worden herkend, of typen worden geïnterpreteerd zoals verwacht en of je geneste structuren logisch zijn.

Hier vang je fouten op zoals:

• publishingDate in plaats van datePublished
• imageUrl waar image wordt verwacht
• Product-markup op een categorielijst die geen product is
• AggregateRating zonder betekenisvol beoordeeld item
• Person gebruikt voor een merkaccount

Wees voorzichtig met waarschuwingen. Schema.org is bewust flexibel. Een validator kan een eigenschap toestaan die niet nuttig is voor jouw gebruikssituatie, of waarschuwen voor iets dat optioneel is. Behandel validatie als bewijs, niet als vonnis.

Een praktische regel: als een eigenschap een machine helpt de pagina nauwkeuriger te begrijpen, houd die dan. Als die er alleen is omdat iemand hem uit een snippetgenerator heeft gekopieerd, stel er dan vragen bij.

Stap 4: Vergelijk markup met zichtbare content

Zoekmachines en andere data-afnemers hebben de neiging markup te wantrouwen die niet overeenkomt met de pagina. Belangrijker nog: gebruikers verdienen consistentie.

Vergelijk voor elk type gestructureerde gegevens de markup met de zichtbare pagina:

Article en BlogPosting

Controleer of de kop, auteur, publicatiedatum, wijzigingsdatum, afbeelding en uitgever zichtbaar zijn of redelijkerwijs kunnen worden afgeleid. Als je AI-ondersteunde content publiceert, mogen je gestructureerde gegevens niet worden gebruikt om onduidelijk auteurschap wit te wassen. We hebben apart geschreven over eerlijke AI-vermelding op een kleine website, en hetzelfde principe geldt hier: metadata moet verduidelijken, niet verhullen.

Product

Controleer naam, prijs, beschikbaarheid, valuta, varianten, beoordelingen en aantallen reviews. Gestructureerde productgegevens verouderen bijzonder snel, omdat prijzen en voorraadstatus vaak buiten het CMS veranderen.

LocalBusiness

Controleer naam, adres, telefoonnummer, openingstijden en servicegebied. Als je footer het ene zegt en je JSON-LD iets anders, is de JSON-LD niet “beter”. Hij is tegenstrijdig.

BreadcrumbList

Controleer of breadcrumbposities overeenkomen met het zichtbare breadcrumbpad en of URL’s canoniek, crawlbaar en niet onnodig omgeleid zijn.

Dit is geen glamoureus werk. Het is ook precies waar veel problemen met gestructureerde gegevens worden gevonden.

Stap 5: Valideer de gerenderde pagina, niet je template

Veel sites genereren JSON-LD via JavaScript, tagmanagers, personalisatielagen of componenthydratie. Dat betekent dat het templatebestand mogelijk niet weergeeft wat een crawler of browser werkelijk ziet.

Valideer de gerenderde HTML in ten minste drie toestanden:

• lokale ontwikkelbuild
• staging- of preview-URL
• productie-URL

Gebruik browser-DevTools om de uiteindelijke DOM te inspecteren. Zoek naar application/ld+json en kopieer de exacte scriptinhoud die na rendering bestaat. Als servergerenderde markup verschilt van gehydrateerde markup, bepaal dan welke versie je verwacht dat afnemers lezen.

Controleer ook of gestructureerde gegevens worden gedupliceerd. Dubbele Article- of Product-blokken komen vaak voor wanneer een CMS-plugin en een aangepaste component allebei schema uitvoeren. Duplicatie is niet altijd fataal, maar conflicterende duplicatie is een probleem: twee prijzen, twee auteurs, twee publicatiedatums of twee canonieke URL’s.

Dit lijkt op het lezen van prestatie- en diagnoserapporten: de eerste taak is niet om in paniek te raken, maar om signaal van ruis te scheiden. Diezelfde gewoonte helpt wanneer je een Lighthouse-rapport leest zonder in paniek te raken — al moet gestructureerde gegevens zelf niet tot één score worden gereduceerd.

Stap 6: Controleer transportdetails in productie

Gestructureerde gegevens kunnen perfect zijn in je broncode en toch in productie falen omdat de pagina niet toegankelijk is op de manier die je aanneemt.

Controleer:

• dat de uiteindelijke statuscode 200 is, geen soft 404
• dat de canonieke URL overeenkomt met de pagina die je valideert
• dat redirects opzettelijk en stabiel zijn
• dat robots-richtlijnen indexering niet blokkeren waar indexering wordt verwacht
• dat HTML voor sommige user agents niet wordt vervangen door een foutpagina
• dat gecachte pagina’s geen verouderde JSON-LD serveren

Hier is HTTP-inspectie belangrijk. Als een productpagina via drie URL’s omleidt voordat hij een canonieke bestemming bereikt, valideer dan de uiteindelijke pagina, niet de eerste URL die uit het CMS is gekopieerd. Voor de ruwe mechaniek is onze gids over redirects en HTTP-headers debuggen in productie een nuttige aanvulling.

Gestructureerde gegevens bestaan niet in een vacuüm. Ze reizen mee met headers, redirects, caching, canonieke tags en robots-richtlijnen.

Stap 7: Voeg tests voor gestructureerde gegevens toe aan je releaseproces

Handmatige validatie is prima voor één pagina. Ze schaalt niet naar honderden of duizenden URL’s.

Een eenvoudige geautomatiseerde testsuite kan de duurste fouten opvangen:

• haal representatieve URL’s op van elk templatetype
• extraheer alle JSON-LD-blokken
• parse ze met JSON.parse
• controleer verplichte velden voor elk paginatype
• controleer of datums geldige ISO 8601-strings zijn
• controleer of URL’s absoluut en canoniek zijn
• controleer of prijzen en beschikbaarheid bestaan voor productpagina’s
• controleer of dubbele entiteiten niet conflicteren

Je kunt dit in CI draaien voor templates en volgens een schema voor productie-URL’s. Het doel is niet om te bewijzen dat elke rich-result-functie zal verschijnen. Niemand buiten de zoekmachine kan dat beloven. Het doel is om je eigen gegevens accuraat, parsebaar en consistent te houden.

<!-- tool-cta:start -->

💡 Probeer dit: Voordat je de schemalogica valideert, haal je je JSON-LD door de JSON Formatter om syntaxisfouten op te sporen die anders elke downstreamcontrole zouden breken.

<!-- tool-cta:end -->

Een validatiechecklist die bij standaarden begint

Gebruik deze korte checklist voordat je vraagt of een zoekmachine de pagina waardeert:

• Is elk JSON-LD-blok geldige JSON?
• Bevat elk blok de juiste @context en @type?
• Zijn Schema.org-eigenschappen correct gespeld?
• Komt de markup overeen met zichtbare content?
• Zijn datums, prijzen, beoordelingen en beschikbaarheid actueel?
• Zijn URL’s absoluut, canoniek en bereikbaar?
• Is de gerenderde productiepagina dezelfde pagina die je hebt getest?
• Zijn dubbele entiteiten opzettelijk en niet-conflicterend?

Als je die vragen met ja kunt beantwoorden, heb je het duurzame deel van het werk aan gestructureerde gegevens gedaan. Zoekmachinespecifieke tests kunnen later nog steeds nuttig zijn, maar ze moeten de laatste compatibiliteitscontrole zijn, niet de basis van je validatieproces.