Structured data testen: Rich Results Test of Validator
Analysis Tools Leestijd: ~7 minuten

Structured data testen: Rich Results Test of Validator

Structured data testen met de Rich Results Test en de Schema Markup Validator: welke tool wanneer en de fouten die het vaakst voorkomen.

Voor structured data testen heb je twee tools nodig: de Rich Results Test van Google checkt of je pagina in aanmerking komt voor rich results, en de Schema Markup Validator controleert of de markup zelf klopt. De oude Structured Data Testing Tool van Google bestaat niet meer; deze twee hebben die plaats ingenomen.

Welke structured data testing tools zijn er?

Vandaag de dag zijn dit de tools die je gebruikt: de Rich Results Test van Google (voor eligibility) en de Schema Markup Validator van Schema.org (voor de syntax). Voor Lighthouse-gebruikers zit er ook in Google's eigen tooling een structured-data-controle die fouten in de markup rapporteert. Degene die je op oude blogs vindt, de Structured Data Testing Tool, is al lang buiten gebruik.

Wat is structured data en waarom test je het?

Structured data is JSON-LD in je pagina die beschrijft wat er op de pagina staat: dit is een artikel, dit is de auteur, dit is een product met deze prijs. Testen is om twee redenen nodig. EÊn: een syntaxfout maakt de hele markup waardeloos; Google leest haar dan niet in. Twee: markup die iets beweert wat niet op de pagina staat, is een risico volgens het structured data beleid van Google: de inhoud moet voor bezoekers zichtbaar en controleerbaar zijn.

De drie formats: json-ld, microdata en rdfa

JSON-LD is het formaat dat Google aanbeveelt: een scriptblok in de pagina, los van de zichtbare html, en het makkelijkst te onderhouden. Microdata zet de markup als attributen rechtstreeks in de html-elementen en rdfa beschrijft bronnen via attributen in de markup; beide worden nog ondersteund, maar maken templates onleesbaarder en zijn foutgevoeliger bij een redesign. Voor nieuwe implementaties kies je in de praktijk json-ld, zodat content en markup onafhankelijk van elkaar kunnen veranderen.

Wat doet de Rich Results Test?

De Google Rich Results Test controleert per URL of per codeblok welke rich result-types mogelijk zijn: FAQ, review, product, how-to enzovoort. Hij toont per type of de pagina eligible is, welke velden ontbreken en welke waarschuwingen er zijn. Eligibility is geen belofte: de test zegt dat je aan de voorwaarden voldoet, niet dat Google het resultaat ook toont.

Wat doet de Schema Markup Validator?

De Schema Markup Validator kijkt puur naar de markup zelf: kloppen de types, de verplichte en aanbevolen eigenschappen, en is de JSON-LD goed opgebouwd? Hij zegt niets over rich results. Gebruik hem naast de Rich Results Test: eerst de syntax, dan de eligibility.

Rich snippets testen: wat kun je verwachten?

Rich snippets (of rich results) zijn de uitgebreide weergaven in Google: sterren, FAQ-uitklapjes, prijsinformatie. De testtools zeggen of je pagina eraan kan voldoen; of Google ze toont hangt van de zoekopdracht en het algoritme. Verkoop daarom geen rich result, en zet geen markup in de pagina voor claims (zoals reviews of prijzen) die bezoekers daar niet kunnen zien.

Welke soorten rich results bestaan er?

De meest voorkomende weergaven: sterren en beoordelingen bij producten, prijzen en voorraadstatus in shoppingresultaten, uitklapbare vragen bij faq-markup, genummerde stappen bij how-to-inhoud, datums en locaties bij events en de sitenaam met route bij organisatie- en breadcrumbmarkup. Welke weergave Google toont, verschilt per type en per zoekvraag; valide markup is de voorwaarde, de weergave zelf blijft de keuze van de zoekmachine. Vul de aanbevolen velden in en niet alleen de verplichte, houd waarden actueel bij contentwijzigingen en test zowel de desktop- als de mobiele weergave.

Welke fouten vang je met een structured data check?

Dit zijn de fouten die het vaakst uit een structured data check rollen:

  • verplichte velden die ontbreken, waardoor het type niet eligible is;
  • markup die iets claimt dat niet zichtbaar is op de pagina;
  • waarden in het verkeerde formaat, zoals een datum of URL die niet aan het verwachte patroon voldoet;
  • verouderde of dubbele types op ÊÊn pagina;
  • JSON-LD die na een thema-update is verdwenen en dus alleen nog op oude versies bestond.
Veelvoorkomende fouten en wat eraan te doen is
FoutGevolgOplossing
verplichte velden ontbrekenhet type komt niet in aanmerking voor een rich resultcheck de documentatie van het type en vul de verplichte velden aan
markup komt niet overeen met de zichtbare inhoudrisico volgens het structured-data-beleidmarkeer alleen wat bezoekers op de pagina kunnen zien
onjuiste json-syntaxde hele markup wordt niet gelezenvalideer de syntax en let op komma's en aanhalingstekens
dubbele markup voor dezelfde entiteittegenstrijdige waardenéén blok per entiteit, de rest verwijderen
verouderde propertieswarnings en achterblijvende waardenupdate naar de actuele schema.org-definities

Wat je sowieso niet doet: onzichtbare content markeren, sterren of beoordelingen aanmerken die niet op de pagina staan, en misleidende prijs- of voorraadinformatie in de markup zetten. Gebruik natuurlijke beschrijvingen zonder zoekwoorden op te stapelen.

Implementatie stap voor stap

  1. Kies het schema-type op de zichtbare inhoud: blogpost wijst richting een artikeltype, een productpagina naar een product met prijs en voorraad, een vraag-antwoordblok naar een faq-type.
  2. Schrijf de JSON-LD: handmatig of met een generator, met alleen waarden die ook echt op de pagina staan.
  3. Plaats het scriptblok in de head of body van de pagina, of laat je cms-plugin dat doen: controleer daarna of het blok de update overleeft.
  4. Test in beide tools: de validator voor de syntax, de Rich Results Test voor de eligibility, en daarna URL-inspectie in Search Console om te zien of Google de bijgewerkte pagina ophaalt.

Houd de dekking daarna bij via de structured-data-rapporten in Search Console; daar komen fouten naar boven zodra een templatewijziging de markup breekt.

Wanneer test je structured data?

Op vaste momenten, niet alleen bij de eerste implementatie: na elke template- of plugin-update (markup verdwijnt daar het vaakst), na een migratie of domeinverhuizing, wanneer Search Console nieuwe fouten of waarschuwingen meldt en vooraf aan een campagne die op de pagina mikt. Een fout die maanden blijft staan, heeft in die maanden ook geen rich result opgeleverd; wie pas achteraf test, weet niet wanneer de weergave is weggevallen.

Wat vindt de validator dat de test mist?

De schema markup validator controleert het volledige schema.org-vocabulaire, inclusief types en eigenschappen waar Google geen uitgebreide weergave aan koppelt. Een definitie kan daar dus gewoon valide zijn terwijl de test van Google niets rapporteert, en andersom kan een blok door de validator komen maar voor rich results onvoldoende bevatten. Beide uitkomsten horen bij elkaar: de validator over de syntax en de definities, de test over wat Google ondersteunt.

Welke schema-types leveren rich results op?

Alleen types die Google voor uitgebreide zoekresultaten ondersteunt, kunnen zo'n weergave opleveren. De meest gebruikte: Product met prijs en voorraad, FAQPage voor vraag-antwoordblokken, HowTo voor instructies, Event met datum en locatie, BreadcrumbList voor de routeweergave en Organization of LocalBusiness voor bedrijfsgegevens. Ondersteuning en voorwaarden veranderen; kies het type dat echt bij de zichtbare inhoud past en controleer de actuele documentatie van Google voordat je implementeert. Een type dat niet bij de pagina past, levert geen weergave op en kan waarschuwingen opleveren.

Hoe test je structured data in WordPress of een ander CMS?

In WordPress doen plugins het grootste deel van de markup, en dat is precies waar testen belangrijk blijft: een plugin-update kan velden toevoegen, hernoemen of laten vervallen. Hetzelfde geldt voor een themawissel, waarna de JSON-LD soms volledig uit de pagina verdwijnt. De routine is daardoor simpel: test de homepage en ÊÊn artikel-type direct na elke update, en vertrouw niet op wat de plugin zegt dat hij doet. In een eigen CMS geldt hetzelfde voor template-wijzigingen: de markup hoort bij het template, niet bij het CMS. Voeg ook nieuwe taal- of landingspagina's direct aan de testroutine toe; juist nieuwe pagina's worden zelden meteen meegenomen in de check.

Hoe past dit in je SEO-toolkit?

Structured data is ÊÊn onderdeel van de techniek; een pagina test je verder met dezelfde discipline. Hoe de koppen op zo'n pagina horen, staat bij de uitleg over H1, H2 en H3 tags, de snelheids- en kernvitaliteit-testen bij de Lighthouse SEO-gids, en de bredere toolvergelijking bij de beste linkbuilding tools. Bewaar ten slotte elke uitslag met datum en gebruikte tool: de geschiedenis van je markup is anders achteraf niet meer te reconstrueren, en juist die geschiedenis laat zien wanneer een fout je weergave kostte.

Websites, prijzen en pakketten vergelijken

Bekijk beschikbare websites op categorie, DR en prijs bij backlinks kopen. Zoek je hulp bij selectie en planning, bekijk dan linkbuilding uitbesteden.

Meer Leren Over SEO & Linkbuilding?

Ontdek alle artikelen in onze uitgebreide kennisbank

Structured data testen op inhoud Ên syntax

Controleer eerst of de JSON-LD valide is en daarna of de entiteit, eigenschappen en tekst echt op de pagina staan. Een groene test maakt onjuiste of verborgen claims niet correct.

Test na templatewijzigingen een echte URL en vergelijk de rich-result-preview met wat bezoekers zien. Voeg geen FAQ- of reviewvelden toe om alleen extra zoekruimte te krijgen.