Nederlands
Analyseer je website

Gestructureerde gegevens: 2 JSON-LD-voorbeelden om te kopiëren

Door SEOgrinder · Gepubliceerd · 9 min leestijd

Kort antwoord: Gestructureerde gegevens beschrijven de inhoud van een pagina in een vorm die zoekmachines direct kunnen uitlezen. Google beveelt daarvoor het formaat JSON-LD aan: een JSON-blok in een <script type="application/ld+json">-tag. Kopieer een van de twee voorbeelden hieronder, vervang de waarden met example.com door gegevens die op je pagina zichtbaar zijn en test het resultaat in de Rich Results Test van Google. Geldige code zorgt dat een pagina in aanmerking komt voor rich results; dat ze verschijnen, garandeert Google niet.

Wat zijn gestructureerde gegevens en wat doet Google met JSON-LD?

Google definieert gestructureerde gegevens (in het Engels structured data, in de volksmond ook “gestructureerde data”) als “a standardized format for providing information about a page and classifying the page content” (Google), dus als een gestandaardiseerde manier om informatie over een pagina te geven en de inhoud te classificeren. Het grootste deel van het vocabulaire komt van schema.org. Je kunt het op drie manieren opschrijven: JSON-LD, Microdata en RDFa. De laatste twee voegen attributen toe aan de zichtbare HTML. JSON-LD staat daarentegen in één apart blok, dat je kunt toevoegen of herstellen zonder de opmaak aan te raken.

Volgens Google zijn “all 3 formats are equally fine for Google”, zolang de markup geldig is en juist wordt toegepast. Toch beveelt het JSON-LD aan als je opzet dat toelaat, omdat het “the easiest solution for website owners to implement and maintain at scale” is (Google).

Wat het je kan opleveren: Google schrijft dat gestructureerde gegevens “can enable search results that are more engaging to users”; dat noemt het rich results. Google onderhoudt een overzicht van ondersteunde functies, waaronder Article, Breadcrumb, Event, Organization, Product en Recipe. Nog een punt uit Googles inleiding: voor hoe Zoeken zich gedraagt, vertrouw je op Googles eigen documentatie en niet op schema.org, dat meer attributen en objecten kent dan Google Zoeken nodig heeft.

Drie regels uit Googles algemene richtlijnen voor gestructureerde gegevens gelden voordat je een regel code schrijft:

  • Beschrijf de pagina waarop de markup staat, en alleen wat bezoekers daar kunnen zien.
  • Blokkeer pagina’s met gestructureerde gegevens niet voor Googlebot, niet met robots.txt, niet met noindex en niet op een andere manier.
  • Vul elke verplichte eigenschap in van het type dat je gebruikt. Items waar er een ontbreekt, “are not eligible for rich results”.

Voorbeeld 1: Organization-markup voor je homepage

Google raadt aan Organization-markup op je homepage te zetten of op één pagina die de organisatie beschrijft, zoals een Over ons-pagina. Op elke pagina heb je hem niet nodig (Google). Het type heeft geen verplichte eigenschappen; Google raadt aan de eigenschappen toe te voegen die van toepassing zijn. Vervang elke waarde:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Voorbeeld Fietsenbouw",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "Voorbeeld Fietsenbouw maakt fietsen op maat.",
  "email": "contact@example.com"
}
</script>

Wat de eigenschappen doen, volgens Googles pagina:

  • name: gebruik dezelfde naam als je als sitenaam gebruikt.
  • url: het adres van je website, dat Google helpt de organisatie uniek te identificeren.
  • logo: minstens 112 × 112 px, crawlbaar en indexeerbaar. Het kan Google helpen te beslissen welk logo in zoekresultaten en kennispanelen verschijnt.
  • description en email: optionele gegevens. Voeg address, contactPoint of sameAs (een profielpagina op een andere site) alleen toe als ze op jou van toepassing zijn.

Past een specifieker subtype, dan raadt Google dat aan, bijvoorbeeld OnlineStore voor een webwinkel of een subtype van LocalBusiness voor een restaurant.

Voorbeeld 2: Article en broodkruimels op een blogartikel

Google begrijpt meerdere items op één pagina, of je ze nu nest of apart opsomt (Google). Dit voorbeeld somt twee items op in een JSON-array, elk met een eigen @context, het patroon dat Google voor afzonderlijke items toont:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Een fietshelm kiezen: waar je op let",
    "image": [
      "https://www.example.com/photos/helm-16x9.jpg",
      "https://www.example.com/photos/helm-4x3.jpg",
      "https://www.example.com/photos/helm-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "Jan Jansen",
        "url": "https://www.example.com/team/jan-jansen"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "Fietsen", "item": "https://www.example.com/blog/fietsen" },
      { "@type": "ListItem", "position": 3, "name": "Een fietshelm kiezen: waar je op let" }
    ]
  }
]
</script>

Article. Google accepteert Article, NewsArticle en BlogPosting. Het noemt geen verplichte eigenschappen en raadt author, datePublished, dateModified, headline en image aan, zodat Google “show better title text, images, and date information” kan tonen (Google). Geef datums in ISO 8601 met een tijdzone; zonder tijdzone gebruikt Google de tijdzone van Googlebot. Zet elke auteur als eigen vermelding met type, naam en url. Houd de kop kort, want “long titles may be truncated on some devices”. Voor afbeeldingen raadt Google meerdere bestanden met een hoge resolutie aan in de verhoudingen 16x9, 4x3 en 1x1 die relevant zijn voor het artikel, geen logo’s.

Broodkruimels. Hier zijn de regels streng. Een BreadcrumbList heeft minstens twee ListItem-vermeldingen nodig en elke vermelding heeft normaal position, name en item (het adres) nodig. Alleen de laatste mag item weglaten; Google gebruikt dan het adres van de pagina zelf (Google). Google raadt een typisch gebruikerspad aan in plaats van een kopie van de URL-structuur en noemt de functie beschikbaar op desktop. Onze lezing van de richtlijnen: toon hetzelfde pad ook zichtbaar op de pagina, want markup voor dingen die lezers niet zien, is niet toegestaan.

Hoe test je JSON-LD voor en na het publiceren?

  1. Rich Results Test (search.google.com/test/rich-results). Google noemt hem “the official Google tool for testing your structured data”. De toolpagina accepteert een adres of geplakte code, dus je kunt een voorbeeld testen voordat het live gaat. Los eerst kritieke fouten op; niet-kritieke hints zijn volgens Google optioneel voor de geschiktheid.
  2. Schema Markup Validator (validator.schema.org). Googles testpagina beschrijft hem als een controle van alle markup op basis van schema.org “without Google feature specific warnings”. Gebruik hem als geen Google-functie bij je type past.
  3. URL-inspectie in Search Console nadat je een paar pagina’s hebt gepubliceerd. Google vraagt je te bevestigen dat de pagina niet wordt geblokkeerd door robots.txt, noindex of een login; het crawlen van een nieuwe pagina kan enkele dagen duren.
  4. Rapporten over rich results in Search Console. Google merkt op dat markup na de livegang kan breken door sjablonen of problemen bij het uitleveren, dus kijk na elke wijziging aan een sjabloon opnieuw (Google).

Zo hebben we de twee voorbeelden hierboven op 4 november 2026 gecontroleerd: beide blokken zijn als JSON te lezen (de json-module van Python), en de eigenschappen volgen Googles pagina’s over Organization, Article en Breadcrumb (laatst bijgewerkt op 8 september 2026). In Googles tool hebben we ze niet geplakt, dus je eerste plakpoging is de echte test.

Wat JSON-LD niet doet

  • Het garandeert geen rich result. Google schrijft: “Google does not guarantee that your structured data will show up in search results” (Google). Tot de redenen behoren dat het algoritme kan besluiten dat een gewoon tekstresultaat beter past, en dat markup op een manier fout kan zijn die de test niet opvangt.
  • Het is geen belofte voor je ranking. We vonden op deze Google-pagina’s geen uitspraak dat gestructureerde gegevens rankings verbeteren. Google beschrijft het voordeel als geschiktheid voor rich results. Een handmatige maatregel voor gestructureerde gegevens, voegt Google toe, haalt die geschiktheid weg en “doesn't affect how the page ranks in Google web search”.
  • AI-antwoorden hebben het niet nodig. Googles gids over generatieve AI-functies zegt: “Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add” (Google). Voor de geschiktheid voor rich results noemt Google gestructureerde gegevens nog wel een goed idee. SEOgrinder meet niet of een AI-systeem je site noemt.
  • FAQ-markup heeft bij Google geen resultaat meer. Googles changelog zegt: “This feature will no longer appear in Google Search starting May 7, 2026” (Google). Voeg FAQPage-markup daarom niet meer toe met dat doel.

Veelgemaakte fouten: 5 JSON-LD-fouten

1. Markup voor wat niemand ziet

Googles richtlijn: “Don't mark up content that is not visible to readers of the page.” Googles eigen voorbeeld: beschrijft de markup een artiest, dan moet de paginatekst diezelfde artiest beschrijven.

2. Kapotte JSON

Eén syntaxfout maakt het hele blok onbruikbaar. Googles rapport over niet-uitleesbare gestructureerde gegevens in Search Console (Engels “Unparsable structured data report”) noemt fouttypen zoals een ontbrekende komma of sluitende accolade, een ontbrekende dubbele punt en een ongeldige escape-reeks in een tekenreeks, bijvoorbeeld een verdwaalde backslash zoals \q in een tekstwaarde. Googles tip om de fout te vinden: begin met een leeg object en voeg je code stukje voor stukje weer toe.

3. Ontbrekende verplichte eigenschappen

Volgens Google komen items zonder hun verplichte eigenschappen niet in aanmerking voor rich results. Het gebruikelijke geval zijn broodkruimelvermeldingen zonder position, name of item.

4. Een type dat niet bij de pagina past

Google vraagt om het meest specifieke toepasselijke type. Zijn voorbeelden van irrelevante markup: een sportstreamingsite die uitzendingen als lokale evenementen markeert, en een houtbewerkingssite die instructies als recepten markeert.

5. De pagina of haar afbeeldingen blokkeren

Pagina’s met gestructureerde gegevens moeten open blijven voor Googlebot, en afbeeldings-URL’s in de markup moeten crawlbaar en indexeerbaar zijn. Een Disallow-regel voor je afbeeldingenmap kan zorgvuldige markup tenietdoen.

Hoe controleert SEOgrinder gestructureerde gegevens?

SEOgrinder is ons hulpmiddel, en wij bouwen het. Scan een pagina, open het tabblad “Pagina bij Google” en kijk naar twee kaarten. “Gestructureerde gegevens” toont de typen die in JSON-LD en Microdata zijn gevonden. “Veldcontrole” telt de entiteiten en toont hoeveel er “Ongeldig” zijn (een verplicht veld ontbreekt) of “Onvolledig” (alleen aanbevolen velden ontbreken), met de namen van de ontbrekende velden. In de takenlijst verschijnen ze als “Gestructureerde gegevens missen verplichte velden”, “Gestructureerde gegevens onvolledig”, “Geen gestructureerde gegevens” en, voor code die niet kan worden gelezen, “Eén kapot blok structured data”. Klik na een oplossing op Opnieuw controleren.

Vier beperkingen. SEOgrinder leest de HTML die je server uitlevert, dus JSON-LD dat pas een script in de browser toevoegt, ziet het niet, terwijl Google het wel kan lezen. Het leest JSON-LD en Microdata, geen RDFa. Het kent de verplichte velden van een lijst veelgebruikte typen, niet van elk type. En het bepaalt niet of Google een rich result toont; die voorvertoning geeft de Rich Results Test.

Onze eigen pagina’s hebben we op 4 november 2026 op dezelfde manier gelezen. Deze opdracht geeft 1 terug voor een artikel en 0 voor de homepage:

curl -sS https://seogrinder.com/nl/blog/seo-audit-checklist-uitvoeren | grep -c 'application/ld+json'

Het enige blok in het artikel bevat een BlogPosting en een BreadcrumbList met drie vermeldingen (SEOgrinder, Blog, het artikel). Op de homepage hebben we geen gestructureerde gegevens.

Veelgestelde vragen

Is JSON-LD beter dan Microdata?

Voor Google zijn alle drie de formaten gelijkwaardig als de markup geldig is. Het beveelt JSON-LD aan omdat het zich het makkelijkst laat inbouwen en op grote schaal laat onderhouden.

Heb ik gestructureerde gegevens op elke pagina nodig?

Nee. Voeg een type alleen toe waar het bij de pagina past: Organization op de homepage of Over ons-pagina, Article bij berichten. Voor veel pagina’s bestaat er geen passend type, en dat is prima.

Kan ik JSON-LD met een plugin of met JavaScript toevoegen?

Ja. Google schrijft dat je in een CMS vaak een instellingenpagina of plugin voor gestructureerde gegevens vindt en dat Google JSON-LD kan lezen dat via scripts is ingevoegd (Google). Controleer het resultaat met de Rich Results Test en bedenk dat SEOgrinder alleen ziet wat de server uitlevert.

Verbetert JSON-LD mijn ranking?

Googles pagina’s beschrijven de geschiktheid voor rich results, geen betere posities. Een positie kan niemand beloven.

Je volgende stap

Kies de pagina die jij het belangrijkst vindt. Plak voorbeeld 1 of 2 met je eigen waarden in de Rich Results Test en los op wat hij meldt. Publiceer, scan de pagina dan met SEOgrinder, open “Pagina bij Google” en lees de kaart “Veldcontrole”. Waar gestructureerde gegevens in het grotere geheel passen, laat onze SEO-audit checklist zien.

Lees ook

Meer uit de blog