Rich Snippets testen (en fouten in de schema-opmaak oplossen)

TL;DR: Test of je in aanmerking komt voor rich results met Google’s Rich Results Test. Gebruik de URL-modus voor de gepubliceerde pagina, los elke fout op en behandel waarschuwingen als optionele verbeteringen. Controleer daarna het bijbehorende rapport in Google Search Console. Een test die “geslaagd” is betekent dat de pagina in aanmerking komt voor een rich result—niet dat die ook gegarandeerd verschijnt.

De toolkeuze doet ertoe. Google beschrijft de Rich Results Test als: “The official Google tool for testing your structured data to see which Google rich results can be generated by the structured data on your page,” in zijn Search Central documentatie over structured data.

Daar begin ik wanneer iemand mij vraagt om de geschiktheid voor rich results te testen. Dus niet met een browserextensie, een groen vinkje van een plugin, of de inmiddels verouderde Structured Data Testing Tool die in oude tutorials werd genoemd.

Even een terminologie-update: Google noemt dit nu rich results. “Rich snippet” is de oudere term die mensen nog steeds gebruiken. Beide verwijzen naar verrijkte zoekvermeldingen die onder meer ratings, prijzen, afbeeldingen, breadcrumbs, datumvelden voor events, details voor recepten en andere informatie kunnen bevatten—naast de standaard titel en beschrijving.

De structured data is niet het zoekresultaat zelf. Het is een door machines leesbare beschrijving van de pagina, die vaak als JSON-LD wordt geschreven. Google kan ook microdata en RDFa parsen, maar JSON-LD is doorgaans eenvoudiger om te genereren, inspecteren en onderhouden zonder de markup te verstrengelen in zichtbare HTML.

Geldige structured data creëert geschiktheid. Google beslist nog steeds of een verrijking verschijnt voor een specifieke pagina en zoekopdracht. Dat onderscheid verklaart een groot deel van de meldingen: “de test slaagt, maar ik zie geen rich snippet”.

Zo test je een rich result goed

De Rich Results Test heeft modi voor URL en Code. Ze overlappen, maar ze bewijzen niet hetzelfde.

1. Open Google’s Rich Results Test.
2. Kies URL voor een gepubliceerde pagina of Code voor HTML of JSON-LD die nog niet is uitgerold.
3. Start de test en laat Google de input ophalen, renderen of verwerken.
4. Open elk gedetecteerd type rich result—niet stoppen bij de samenvatting.
5. Bekijk de errors, warnings en geparseerde properties van elk item.
6. Corrigeer elke error en voer de test opnieuw uit.
7. Deploy de wijziging, wis relevante caches en test de live URL opnieuw.
8. Nadat Google de getroffen pagina’s opnieuw heeft gecrawld: open het bijpassende Search Console-rapport en valideer daar de fix.

Begin met URL-modus voor productiepagina’s

URL-modus beantwoordt de praktische productie-vraag: Wat kan Google op dit moment ophalen van deze URL?

Je JSON-LD kan perfect zijn in een CMS-veld, maar ontbreken op de gepubliceerde pagina. Een template-voorwaarde kan hem onderdrukken, een cache kan nog de vorige versie serveren, een JavaScript-fout kan injection blokkeren, of de productie-deployment kan de component volledig weglaten. De editor is bewijs van intentie. De live URL is bewijs van output.

URL-modus rendert ook pagina’s, dus het kan structured data detecteren die via JavaScript is ingevoegd. Toch geef ik de voorkeur aan server-rendered JSON-LD wanneer dat praktisch is, omdat het nog één faalpunt wegneemt (niet elke implementatie heeft nog een extra moving part nodig).

Tijdens onze migratie in januari 2026 van seojuice.io naar seojuice.com zaten representatieve live-URL tests in de release-checklist. Een migratie kan de schematemplate behouden terwijl canonicals, productie-paden, caches en de pagina-output eromheen veranderen. Alleen het JSON-LD snippet testen had het grootste deel van het migratierisico genegeerd.

Gebruik Code-modus vóór publicatie

Code-modus is handig tijdens het bouwen of bewerken van markup. Plak de relevante HTML of JSON-LD, draai de test en herstel de structuur voordat je aan productie komt.

Plak een rauw snippet zoals dit Article-markup en test het voordat de pagina live gaat:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Test Rich Snippets",
  "author": { "@type": "Person", "name": "Vadim Kravcenko" },
  "datePublished": "2026-07-19"
}
</script>

Voor hardnekkige problemen: test beide. Code-modus vertelt je of de voorgestelde markup acceptabel is. URL-modus vertelt je of die versie de pagina ook daadwerkelijk heeft bereikt. Die resultaten lopen vaak uiteen—en dat is eerder een aanwijzing dan een ongemak.

Als je de JSON-LD eerst moet opbouwen, gebruik onze Schema markup generator en voer de output vervolgens door Google’s test. Een generator kan fouten in brackets, nesting en properties verminderen. Maar hij kan niet verifiëren dat je CMS de juiste data heeft aangeleverd, of dat productie het uiteindelijke blok correct heeft gerenderd.

Errors blokkeren de geschiktheid; warnings doen dat meestal niet

Dit is het onderscheid dat je moet bewaren bij het lezen van de testoutput.

Met een item bedoelen we een specifiek structured-dataobject dat op de pagina is gedetecteerd. Eén URL kan meerdere items en meerdere schematypes bevatten, elk met een eigen status.

Ik heb teams gezien die een dozijn warnings opruimden terwijl ze één error met required-property niet oplosten. Dat zet je prioriteiten op zijn kop. Los eerst blockers op, draai de test opnieuw en zet echt nuttige warnings in een optimalisatie-backlog.

Een warning kan nog steeds zwakke brondata blootleggen. Een optioneel image- of identifier-veld kan bijvoorbeeld helpen om een Product beter te begrijpen en vollediger te presenteren. Maar “aanbevolen” betekent niet “stiekem vereist” (en fictieve waarden toevoegen om een warning te dempen is slechter dan hem gewoon te laten staan).

Zo los je terugkerende schema-errors op

Ontbrekende vereiste properties

De Rich Results Test noemt normaal gesproken de ontbrekende property. Begin daarmee in plaats van plugins om te wisselen of JSON-LD van een andere site te kopiëren.

Een Product-item mist mogelijk zijn naam of de benodigde offers, review- of aggregate-ratinginformatie. Een Recipe kan een afbeelding missen. De vereisten verschillen per rich-resulttype, dus open Google’s documentatie voor de gedetecteerde feature en vergelijk de verwachte structuur met het geparseerde item.

Volg daarna de ontbrekende property stroomopwaarts. Als een template een prijs-, auteur-, afbeeldings- of dataveld verwacht en de CMS-record is leeg, dan behandel je met het bewerken van de gegenereerde JSON-LD vooral het symptoom. Repareer liever het contentmodel, de validatieregel of de template-fallback.

Op basis van wat we bij SEOJuice over meerdere sites zien, ontstaan de ongemakkelijke failures meestal in de overdracht tussen geldige schema-logica en onvolledige paginadata. De generator weet waar een waarde hoort; hij kan geen echte prijs of zichtbare review verzinnen die de pagina niet bevat. En dat moet hij ook niet kunnen.

Verkeerde types en waardeformaten

Niet alle schema-properties accepteren plain text. Een property kan een number, URL, Offer, PostalAddress of een ander genest object vereisen. Een waarde kan er voor een lezer logisch uitzien, maar toch het verkeerde machine-leesbare type hebben.

Open het betreffende item in de test, vind de precieze property en vergelijk de waarde met het verwachte type. Als de template dezelfde fout genereerde voor één URL, test dan ook meerdere andere pagina’s die die template gebruiken. Eén fout is vaak een steekproef van een groter probleem, niet een geïsoleerde pagina.

De efficiënte stap is om de template één keer te fixen. 80 gegenereerde pagina’s handmatig corrigeren is 80 kansen om dezelfde fout opnieuw te maken (of 79, als geluk de eerste edit al draagt).

Ongeldige datums

Properties zoals datePublished, dateModified en startDate vereisen machine-leesbare ISO 8601-waarden. Een CMS kan “19 juli 2026” correct tonen aan lezers, terwijl er tegelijkertijd een gelokaliseerde of dubbelzinnige string in de schema komt.

Corrigeer de datumformatter op template-niveau. Controleer ook tijdzones voor events en offers; een syntactisch geldige timestamp kan nog steeds de verkeerde start- of vervaltijd communiceren.

Schema aanwezig in de editor, maar afwezig op de pagina

Laat de productie-URL door de Rich Results Test lopen. Als het verwachte type niet wordt gedetecteerd, inspecteer dan de daadwerkelijke output in plaats van telkens opnieuw het schemaobject te bewerken.

• Bevestig dat de JSON-LD zichtbaar is in de geleverde of gerenderde pagina.
• Controleer CMS- en thema-voorwaarden die bepalen waar het wordt ingevoegd.
• Bekijk plugininstellingen en uitsluitingen.
• Wis relevante page-, CDN- en applicatiecaches.
• Check of JavaScript faalt vóórdat de schema-injectie plaatsvindt.
• Bevestig dat consent- of personalisatielogica het niet verbergt voor crawlers.

Onze SEOJuice automatiseert het genereren van schema op de pagina’s die we beheren, maar Lida en ik testen nog steeds representatieve output. We zijn een team van twee, dus automatisering is essentieel. Automatisering behandelen als feilloos zou alleen maar onze blinde vlek automatiseren.

Dubbele of conflicterende markup

Een pagina kan gelijktijdig schema krijgen vanuit zijn thema, een SEO-plugin, een commerce-plugin, een specialistische schema-plugin en custom JSON-LD. De Rich Results Test maakt gedetecteerde items los van elkaar, waardoor incompleet of onverwacht gekopieerde blokken makkelijker te herkennen zijn.

Vier niet één geldig Product-item terwijl je een tweede kapotte Product-block negeert. Identificeer welk systeem elk object uitstoot en kies één eigenaar voor dat schematype. Het uitschakelen van redundante output is meestal veiliger dan proberen om meerdere generators gesynchroniseerd te houden.

Wees wel voorzichtig voordat je ogenschijnlijk gedupliceerde Organization- of WebSite-markup verwijdert. Soortgelijke objecten kunnen verschillende entiteiten beschrijven of verschillende doelen op paginaniveau dienen. Vergelijk eerst hun identifiers, types en relaties (dit is één plek waar “verwijder duplicates” te bot is).

Je markup moet overeenkomen met zichtbare paginacontent

Technisch geldige markup kan nog steeds in strijd zijn met Google’s structured-data policies. Een validator checkt of data kan worden geparsed; hij certificeert niet dat de claims waarheidsgetrouw zijn.

“Markeer geen content die niet zichtbaar is voor lezers van de pagina.”

Google’s structured-data algemene richtlijnen voegen toe: “Je structured data moet een daadwerkelijke weergave zijn van de paginacontent.” Het gevolg is ook expliciet: “Een handmatige actie voor structured data betekent dat een pagina zijn geschiktheid verliest om als rich result te verschijnen.”

Voeg geen aggregate review-sterren toe als gebruikers die reviews niet op de pagina kunnen vinden. Markup een event-datum niet als de pagina die nooit weergeeft. Zet een doorsnee artikel niet om naar een Recipe-object omdat het recipe-resultaat er opvallender uitziet.

Dit geldt ook voor verouderde waarden. Als de zichtbare productprijs verandert maar gecachte JSON-LD de oude prijs blijft bevatten, dan representeert de markup de pagina niet meer. De syntax kan perfect zijn en toch fout.

De oude Structured Data Testing Tool is weg

Google heeft zijn oude Structured Data Testing Tool in 2020 uitgefaseerd. Generieke schema.org-validatie gaat nu verder via de Schema Markup Validator, terwijl Google rich-result geschiktheid testen richt op de Rich Results Test.

• Rich Results Test: checkt of Google één van zijn ondersteunde zoekfeatures kan genereren op basis van de pagina of code.
• Schema Markup Validator: checkt markup tegen de bredere schema.org-woordenschat, inclusief types die Google niet rendert als rich results.

Een schema.org-type kan dus geldig zijn zonder dat het een Google-verrijking oplevert. Geen tegenstelling: schema.org beschrijft veel meer entiteiten en relaties dan Google’s zoekgalerij ondersteunt.

Gebruik de validator voor “Is dit geldige schema.org-markup?” Gebruik Google’s tool voor “Is dit geschikt voor een Google rich result?” Als je de diepere nuance nodig hebt, legt onze Schema.org 2026 guide uit wat Google momenteel leest en gebruikt.

Jacht niet op FAQ- of HowTo-rich results

Veel schema-tutorials die nog redelijk in orde leken, zijn nu verouderd.

Google’s live structured-data search gallery blijft de bron om te checken vóórdat je een type implementeert voor zichtbaarheid in de zoekresultaten. Ondersteunde features zijn onder andere Article, Breadcrumb, Dataset, Discussion forum, Event, Job posting, Local business, Organization, Product, Profile page, Q&A, Recipe, Review snippet, Software app, Vacation rental en Video—en nog meer.

FAQ en HowTo ontbreken.

Google heeft HowTo als zoekfeature verwijderd in 2023. In de changelog van de documentatie staat: “Removed the How-to structured data documentation, as this rich result is no longer shown in search results, on both desktop and mobile devices.”

FAQ overleefde langer in een beperkte vorm, maar dat hield ook op. Barry Schwartz meldde in Search Engine Land dat Google FAQ-rich results stopte met ingang van 7 mei 2026. Google’s documentatienotice zei:

“FAQ rich results are no longer appearing in Google Search. We will be dropping the FAQ search appearance, rich result report, and support in the Rich results test in June 2026.”

FAQPage blijft onderdeel van schema.org, en andere systemen kunnen het verwerken. Het levert geen Google FAQ rich result op. HowTo-markup kan nog steeds instructieve content beschrijven in een algemeen semantisch zin, maar het levert niet langer een HowTo-verrijking op in Google Search.

Houd nuttige FAQ’s en stap-voor-stap instructies voor lezers. Maar reserveer geen implementatietijd op de aanname dat deze twee schematypes Google rich snippets gaan opleveren. Die strategie is verlopen.

Van één-pagina testing naar sitebrede monitoring

De Rich Results Test is een diagnostische tool op paginaniveau. Search Console rapporteert wat Google aantrof over gecrawlde pagina’s heen.

Open het relevante rapport, zoals Breadcrumbs, Product-snippets of Merchant listings. Bekijk de getroffen URL’s, vind de gedeelde template of databrond, implementeer de correctie en kies Validate fix wanneer beschikbaar. Google moet de URL’s opnieuw crawlen en verwerken voordat het rapport wordt bijgewerkt.

Search Console is langzamer dan het testen van geplakte code, omdat het het crawlcycle van Google reflecteert in plaats van je laatste lokale edit. Die vertraging kan irritant zijn (ik heb die rapporten ververst terwijl ik precies wist dat er niets zou veranderen), maar juist dat maakt de data bruikbaar: het representeert productiepagina’s op schaal.

Onze gratis SEO-audit kan helpen om bredere site-issues te identificeren voordat je de scope verkleint tot individuele URL’s. Verifieer daarna de rich-result geschiktheid in Google’s eigen test; een third-party audit hoort niet de eindautoriteit te zijn op een Google-feature.

Waarom een test die slaagt toch geen rich result oplevert

Een geldige uitkomst betekent geschiktheid, niet gegarandeerde weergave.

Google beslist per zoekopdracht en resultaat of het een verrijking toont. De weergave in de zoekresultaten kan ook worden beïnvloed door paginakwaliteit, misleidende of niet-passende markup, niet-ondersteunde feature types en handmatige structured-data acties.

Als de test slaagt maar er verschijnt geen verrijking:

1. Bevestig dat je de uiteindelijke canonical URL hebt getest.
2. Check of de gemarkeerde informatie zichtbaar is en actueel is.
3. Bekijk het bijbehorende Search Console-rapport.
4. Check Search Console op handmatige acties.
5. Verifieer dat het schematype nog steeds voorkomt in Google’s search gallery.
6. Monitor meerdere relevante zoekopdrachten in plaats van één handmatige zoekactie als beslissend te behandelen.

Ik ben ervan overtuigd dat deze diagnostische volgorde werkt. Exact voorspellen wanneer Google een in aanmerking komend resultaat gaat “decoreren” is minder zeker, omdat Google geen weergavegarantie geeft. Telkens opnieuw al geldige JSON-LD herschrijven wanneer een rich result verdwijnt kan nieuwe fouten introduceren zonder dat de onderliggende beslissing verandert.

Geschiktheid en presentatie zijn gescheiden over meer dan alleen schema. Onze guide naar SERP snippets en AI visibility legt uit waarom indexering en snippet-control nog steeds tellen, zelfs wanneer zoekplatformen de uiteindelijke presentatie kiezen.

Veelgestelde vragen

Hoe test ik of mijn pagina in aanmerking komt voor rich results?

Plak de gepubliceerde URL in Google’s Rich Results Test. Gebruik Code-modus voor HTML of JSON-LD die nog niet is gepubliceerd. De tool identificeert ondersteunde rich-result types en geeft errors, warnings en geparseerde properties weer. Gebruik Search Console voor samengevoegde informatie over gecrawlde pagina’s.

Wat is er gebeurd met de Structured Data Testing Tool?

Google heeft de oude Structured Data Testing Tool uitgefaseerd. Gebruik de Rich Results Test voor Google rich-result geschiktheid en de Schema Markup Validator op validator.schema.org voor bredere schema.org-validatie.

Wat is het verschil tussen de Rich Results Test en Schema Markup Validator?

De Rich Results Test controleert of markup kan resulteren in een Google-ondersteund rich result. De Schema Markup Validator controleert algemene schema.org-validiteit, inclusief vocabulaire dat Google niet gebruikt voor zoekverrijkingen. Dat de laatste “slaat” bewijst niet dat Google het rich result ook echt geschikt vindt.

Wat is het verschil tussen een schema-error en een warning?

Een error betekent dat een vereiste property ontbreekt of ongeldig is, waardoor het betreffende item niet in aanmerking komt. Een warning betekent meestal dat een aanbevolen property ontbreekt, terwijl het item wel in aanmerking blijft komen. Los eerst alle errors op en beoordeel daarna warnings op basis van hun nut en de data die daadwerkelijk op de pagina te zien is.

Genereren FAQ-schema’s nog rich results in 2026?

Nee. Google heeft FAQ-rich results volledig verwijderd op 7 mei 2026 en daarna ook de bijbehorende support voor testen en rapporteren stopgezet. FAQPage blijft een geldige schema.org-woordenschat, maar het levert niet langer een Google FAQ rich result op.

Waarom wordt er geen schema gedetecteerd op mijn live pagina?

De markup is mogelijk niet op productie terechtgekomen, wordt mogelijk onderdrukt door een template-voorwaarde, staat mogelijk achter verouderde caching of is afhankelijk van JavaScript dat faalde tijdens het renderen. Vergelijk Code-modus met URL-modus, inspecteer vervolgens de gerenderde productie-output en alle systemen die schema kunnen injecteren.

Waarom verschijnt mijn rich result niet, ook al slaagt de test?

Slaag betekent dat de pagina in aanmerking komt, niet dat Google gegarandeerd een verrijkte vermelding toont. Controleer of de markup overeenkomt met zichtbare content, bekijk het relevante Search Console-rapport, verifieer dat de feature nog steeds wordt ondersteund en zorg dat de site geen structured-data handmatige actie heeft.

Als je JSON-LD genereert of repareert: begin met één representatieve pagina, test die in Code-modus, implementeer, en test daarna de live URL. Zodra die pagina schoon is, pas je de template-level fix toe op de hele site en laat Search Console het resultaat op schaal bevestigen.