Gestructureerde data:wat zoekmachines en AI ervan begrijpen

Wat schema.org is en wat JSON-LD is

schema.org is een gemeenschappelijke woordenlijst voor het beschrijven van dingen op het web. Ze legt types vast zoals Organization, Service en Question. Bij elk type hoort een reeks eigenschappen zoals name, url en address. Het is geen product van Google. De grote zoekmachines hebben de woordenlijst samen opgezet en ze staat open. Daarom werkt dezelfde opmaak ook voor andere partijen die uw pagina lezen.

JSON-LD is de notatie waarin u die woordenlijst opschrijft. Een blok JSON in een scriptelement met type="application/ld+json", los van uw zichtbare HTML. Dat losstaan is het praktische voordeel: u voegt het toe, wijzigt het of haalt het weg zonder één regel aan uw ontwerp te raken. Er bestaan twee oudere notaties, microdata en RDFa, die attributen door uw HTML weven. Beide werken nog. Voor nieuw werk neemt u JSON-LD, want dat is wat Google aanraadt en het is de enige vorm die u op één plaats beheert.

Eén regel geldt altijd. Wat u opmaakt moet zichtbaar op de pagina staan. Google eist in zijn richtlijnen voor gestructureerde data dat de opmaak overeenkomt met wat de bezoeker te zien krijgt. Een FAQ-blok met vijf vragen die alleen in de JSON-LD bestaan is een overtreding en geen slimmigheid.

Waarom het voor GEO zwaarder weegt dan voor SEO

Voor klassieke zoekresultaten is de winst beperkt en goed af te bakenen. Google kan een extra element tonen: een kruimelpad in plaats van een kale URL, een datum bij een evenement, prijsinformatie bij een product. Gestructureerde data is geen rankingfactor. Google zegt dat publiek. Een pagina zonder één regel schema kan probleemloos op positie één staan.

Bij een AI-antwoordmachine ligt de rekening anders. Dat systeem moet in korte tijd bepalen waar uw pagina over gaat, van welke organisatie ze is, wie ze schreef en of er een passage in staat die de gestelde vraag beantwoordt. Uit lopende tekst moet het dat allemaal afleiden. In JSON-LD staat het er gewoon. Precies daar zit de winst: u haalt de stap weg waar het misgaat.

In onze eigen GEO-scoreformule weegt gestructureerde data 0,25. Dat is het zwaarste van zes onderdelen. Het is onze operationalisatie en geen sectornorm. We geven het dat gewicht omdat het de enige factor is die volledig binnen uw eigen muren ligt en die u op een namiddag repareert.

Wees eerlijk over wat we niet weten. Niemand publiceert hoeveel schema precies oplevert aan citaties. Wat wel vaststaat is dat een pagina zonder schema het systeem dwingt te raden. Een gok valt soms fout uit.

De types die er voor een kmo toe doen

Daarnaast is er SpeakableSpecification, een klein onderdeel waarmee u aanwijst welk stuk van de pagina zich leent om voorgelezen of overgenomen te worden. Zet het op uw antwoordblok bovenaan. Het kost twee regels.

Kiest u Organization of LocalBusiness? Neem LocalBusiness als klanten naar uw adres komen of als u een afgebakend werkgebied bedient. Neem Organization in alle andere gevallen. LocalBusiness is een ondersoort van Organization, dus alles wat in het ene kan, kan ook in het andere. Zet ze nooit allebei als aparte knopen op dezelfde pagina, want dan staan er twee bedrijven op uw site.

Kant-en-klare voorbeelden om te kopiëren

Vervang overal uwdomein.be en de voorbeeldgegevens. De rest kan blijven staan.

Uw organisatie, één keer opgezet en op elke pagina herhaald:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://uwdomein.be/#organization",
  "name": "Voorbeeld bv",
  "url": "https://uwdomein.be/",
  "logo": "https://uwdomein.be/assets/logo.png",
  "email": "info@uwdomein.be",
  "telephone": "+32 3 123 45 67",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Voorbeeldstraat 1",
    "postalCode": "2000",
    "addressLocality": "Antwerpen",
    "addressCountry": "BE"
  },
  "sameAs": [
    "https://www.linkedin.com/company/voorbeeld-bv"
  ]
}

Het veld sameAs is uw machineleesbare koppeling naar dezelfde onderneming elders. Dat is de brug naar hoofdstuk 10.

Een dienstpagina:

{
  "@context": "https://schema.org",
  "@type": "Service",
  "name": "Onderhoud van verwarmingsinstallaties",
  "serviceType": "Onderhoud en keuring",
  "url": "https://uwdomein.be/onderhoud.html",
  "provider": { "@id": "https://uwdomein.be/#organization" },
  "areaServed": [
    { "@type": "Country", "name": "Belgium" }
  ],
  "description": "Eén zin die letterlijk zegt wat de dienst is en voor wie."
}

Een vraag met haar antwoord:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "nl-BE",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Hoe vaak moet een gasketel onderhouden worden?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Schrijf hier hetzelfde antwoord dat zichtbaar op de pagina staat, in twee tot vier zinnen die los van de rest leesbaar zijn."
      }
    }
  ]
}

Let op bij FAQPage. Google beperkte de zichtbare FAQ-resultaten in 2023 tot overheids- en gezondheidssites. Uw kmo krijgt er dus geen uitklapblok meer mee in de zoekresultaten. De kernupdate van maart 2026 bracht de rich results voor FAQPage, Review en HowTo op pagina's die niet de hoofdinhoud zijn nog verder terug. Toch blijft het de duidelijkste manier om een vraag aan een antwoord te koppelen voor elk systeem dat uw tekst verwerkt, en Gemini gebruikt schema in AI Mode net om claims te toetsen en de betrouwbaarheid van een bron in te schatten. Daar zit voor GEO de hele waarde.

Een artikel met een auteur en een kruimelpad, samen in één blok:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "@id": "https://uwdomein.be/blog/artikel.html#article",
      "headline": "De titel van het artikel, kort gehouden",
      "datePublished": "2026-08-03",
      "dateModified": "2026-08-03",
      "inLanguage": "nl-BE",
      "author": {
        "@type": "Person",
        "name": "Voornaam Achternaam",
        "url": "https://uwdomein.be/over-ons.html"
      },
      "publisher": { "@id": "https://uwdomein.be/#organization" },
      "speakable": {
        "@type": "SpeakableSpecification",
        "cssSelector": [".antwoordblok"]
      }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uwdomein.be/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uwdomein.be/blog/" }
      ]
    }
  ]
}

De @graph-val waar scanners op stuklopen

Het laatste voorbeeld gebruikt @graph. Daarmee zet u meerdere entiteiten in één blok onder één @context en geeft u elke entiteit een @id zodat ze naar elkaar kunnen verwijzen. Het is de nette manier en Google leest het zonder probleem.

Toch loopt hier veel mis, om drie redenen.

Uw scanner ziet niets. Veel SEO-controleurs lezen alleen de sleutel @type bovenaan het blok. In een @graph staat die sleutel daar niet, want de types zitten een niveau dieper. Het rapport meldt dan dat u geen gestructureerde data heeft terwijl alles er staat. Wat daarna gebeurt is voorspelbaar: iemand schrikt van het rode vinkje en plakt er een tweede blok bij. Nu staan er twee organisaties op uw pagina en mag Google kiezen. Controleer daarom altijd in de officiële validators en niet in de scanner. Zijn die groen, dan is de scanner fout en verandert u niets.

Uw @id verschilt per pagina. De verwijzing { "@id": "..." } werkt alleen als de tekenreeks overal exact hetzelfde is. Één keer met www ervoor en één keer zonder levert twee bedrijven op in plaats van één. Kies één schrijfwijze zoals https://uwdomein.be/#organization en gebruik die op elke pagina in elke taal.

U verwijst naar iets dat er niet staat. Een provider die naar #organization wijst werkt alleen als die knoop op diezelfde pagina aanwezig is. Zet de organisatieknoop dus in elke @graph mee, ook op de dienstpagina.

Onze werkregel is eenvoudig: per pagina en per taal precies één JSON-LD-blok met een @graph erin, waarin de organisatieknoop altijd aanwezig is. Voor een meertalige site betekent dat vier blokken waarvan alleen de tekstvelden verschillen. De URL's en de @id-waarden blijven identiek.

De regel die uw bedrijf kan redden

Verzin nooit Review- of AggregateRating-markup voor beoordelingen die niet bestaan. Dit is het enige onderwerp in deze hele gids waarop Google u actief kan straffen.

Wat er gebeurt: iemand zet 4,8 sterren uit 137 beoordelingen in de JSON-LD omdat het mooi staat in het zoekresultaat. Er zijn geen 137 beoordelingen. Google noemt dat spam in gestructureerde data en de gevolgen zijn een handmatige maatregel, het verlies van alle uitgebreide resultaten en werk om er weer af te raken. Bovendien mag u geen sterren tonen die u over uzelf schrijft. Beoordelingen die de eigenaar zelf plaatst komen sowieso niet in aanmerking voor weergave.

Er is nog een misverstand dat vaker voorkomt dan het verzinnen zelf. Ook met echte beoordelingen levert eigen review-markup u geen sterren op. Google toont sinds 2019 geen sterrenfragment meer wanneer de beoordeelde partij de beoordelingen zelf beheert, en dat geldt voor LocalBusiness en voor elk ander Organization-type. Het maakt niet uit of u de teksten zelf intypt of een widget gebruikt die ze bij een beoordelingssite ophaalt. Voor Product ligt het anders: beoordelingen van een product dat u verkoopt mag u wel markeren.

Er is een tweede reden, los van Google. Verzonnen beoordelingen vallen onder de regels rond oneerlijke handelspraktijken. Dat is geen SEO-probleem meer.

Wat wel mag en wat wel werkt: echte beoordelingen verzamelen op uw Google Bedrijfsprofiel. Die toont Google zelf, zonder dat u er één regel schema voor nodig heeft. Zie hoofdstuk 10.

Hoe u controleert of het klopt

Vier gratis controles, in deze volgorde.

De twee validators verschillen en dat verwart mensen. De Rich Results Test toont alleen wat Google visueel kan gebruiken. Uw Service- of Organization-blok komt daar dus niet in voor terwijl het perfect in orde is. De Schema Markup Validator toont alles. Gebruik de Schema Markup Validator voor de vraag of uw opmaak klopt en de Rich Results Test voor de vraag of Google er iets zichtbaars mee doet.

Wat u zelf kan en wat niet

Zelf te doen, zonder ontwikkelaar:

• Het organisatieblok hierboven overnemen, invullen en in de <head> van elke pagina zetten. Dit is een halfuur werk voor een site van twintig pagina's.
• sameAs aanvullen met uw profielen elders. Alleen profielen die u ook echt onderhoudt.
• Een Service-blok per dienstpagina maken. Het sjabloon is telkens hetzelfde en alleen de naam, de URL en de beschrijving veranderen.
• FAQPage toevoegen op pagina's waar de vragen ook zichtbaar staan.
• De twee validators draaien en het resultaat lezen.

Waarvoor u hulp nodig heeft:

• Een webshop met honderden producten, waar Product en Offer uit uw voorraadgegevens gegenereerd moeten worden.
• Een plugin die zelf een @graph uitstuurt die botst met wat u toevoegt. Dan is het uitzoeken wat er al staat voor u iets bijzet.
• De vier taalvarianten van hetzelfde blok, waarbij alleen de tekst mag verschillen en de identificatoren gelijk moeten blijven.
• Een site die volledig in JavaScript wordt opgebouwd, waar het schemablok pas na het laden ontstaat. Niet elk systeem dat uw pagina ophaalt voert JavaScript uit.

Onze volgorde: eerst Organization op alles, dan Service op de dienstpagina's, dan FAQPage en Article waar het van toepassing is. Het eerste punt levert het grootste deel van de winst en het kost het minste tijd.

Wenst u dit niet zelf te doen: SEMANU voert de volledige SEO- en GEO-audit uit voor 1.450 euro, inclusief rapport en werksessie. Wat erin zit staat op de gidspagina.