Is structured data een rankingfactor?

Niet direct. Google zegt dat structured data helpt om een pagina te begrijpen en dat het rich results mogelijk maakt, maar dat het op zichzelf geen hogere positie oplevert. De waarde zit in eenduidigheid: zoekmachines en AI-systemen hoeven niet te raden wie je bent, wat je aanbiedt en wie een tekst heeft geschreven.

Lezen ChatGPT en Perplexity JSON-LD?

Dat is niet bevestigd. Microsoft heeft in 2025 gezegd dat schema-markup hun taalmodellen helpt content te begrijpen, en Google gebruikt structured data voor zijn Knowledge Graph, waar AI Overviews en AI Mode op leunen. Van OpenAI en Perplexity is niet bekend of ze JSON-LD meenemen. Zorg daarom dat alles wat in je schema staat ook gewoon leesbaar op de pagina staat.

Welke schema-types heeft een dienstverlener minimaal nodig?

Organization (naam, url, logo, sameAs), Person voor de mensen achter de expertise, en per pagina het type dat past: Service of ProfessionalService voor een dienst- of vestigingspagina, Article voor uitleg en blogs, en BreadcrumbList voor de structuur. Verbind ze met @id, zodat het één geheel wordt in plaats van losse blokjes.

Heeft FAQ-schema nog zin?

Voor rich results nauwelijks: sinds 2023 toont Google FAQ-uitklapblokken alleen nog voor gezaghebbende overheids- en zorgsites. Als machineleesbare vraag-en-antwoordparen kan het nog steeds helpen, mits de vragen en antwoorden echt zichtbaar op de pagina staan. Voeg geen FAQ toe alleen om schema te hebben.

Hoe test ik mijn structured data?

Met de Schema Markup Validator (validator.schema.org) controleer je of je JSON-LD klopt volgens Schema.org. Met de Rich Results Test van Google zie je of een pagina in aanmerking komt voor rich results. In Search Console zie je onder 'Verbeteringen' fouten over de hele site.

Structured data voor AI: JSON-LD en Schema.org uitgelegd

Wat structured data wel en niet doet voor AI

Eerst de eerlijke versie, want over schema wordt veel beweerd. Google gebruikt structured data om pagina's te begrijpen, voor rich results en om entiteiten te koppelen aan zijn Knowledge Graph, de database waar ook AI Overviews en AI Mode op leunen. Microsoft heeft in 2025 gezegd dat schema-markup hun taalmodellen helpt content te begrijpen. Van OpenAI en Perplexity is niet bekend of ze JSON-LD meenemen wanneer ze een pagina ophalen.

Wat structured data dus níet is:

Geen rankingfactor op zichzelf. Een zwakke pagina met perfecte markup blijft een zwakke pagina.
Geen vervanging van zichtbare tekst. Wat alleen in je JSON-LD staat en niet op de pagina, telt voor een AI-model dat alleen de tekst leest niet mee. En volgens de richtlijnen van Google hoort markup te beschrijven wat de bezoeker ook ziet.

Wat het wel is: de goedkoopste manier om misverstanden over wie je bent weg te nemen. En voor een AI-zoekmachine die moet kiezen welk merk hij vertrouwt, is eenduidigheid precies wat telt.

Denk in een graph, niet in losse blokjes

De meeste sites plakken per pagina een los schema-blokje: hier een Organization, daar een Article met een auteursnaam als tekst. Voor een machine zijn dat losse feiten zonder verband. Het verschil maak je met @id: een vaste identificatie per entiteit, waar andere blokken naar verwijzen.

Op deze site ziet dat er in de kern zo uit. Het sitebrede schema staat op elke pagina, en elk artikel verwijst ernaar in plaats van de gegevens te herhalen:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://on-mind.nl/#organization",
      "name": "On Mind",
      "url": "https://on-mind.nl",
      "founder": { "@id": "https://on-mind.nl/#koen-de-wit" }
    },
    {
      "@type": "Person",
      "@id": "https://on-mind.nl/#koen-de-wit",
      "name": "Koen de Wit",
      "worksFor": { "@id": "https://on-mind.nl/#organization" },
      "sameAs": ["https://www.linkedin.com/in/koen-de-wit-23243821/"]
    },
    {
      "@type": "Article",
      "headline": "Structured data voor AI",
      "author": { "@id": "https://on-mind.nl/#koen-de-wit" },
      "publisher": { "@id": "https://on-mind.nl/#organization" }
    }
  ]
}

Zo wordt het voor een zoekmachine één verhaal: dit artikel is geschreven door deze persoon, die werkt bij deze organisatie, die op LinkedIn te vinden is. Hoe meer pagina's naar dezelfde @id verwijzen, hoe steviger die entiteit staat.

De types die ertoe doen

Schema.org kent honderden types. Voor een dienstverlener zijn er zes die het werk doen:

Organization: naam, url, logo, contact, adres en vooral sameAs, de links naar je profielen elders (LinkedIn, Wikidata, vakverenigingen). Via sameAs koppelt een zoekmachine jouw site aan wat de rest van het web over je zegt.
Person: de mensen achter de expertise, met functie, worksFor, knowsAbout en sameAs. Dit is de machineleesbare kant van E-E-A-T: wie schrijft dit, en waarom zou je die persoon geloven?
Service of ProfessionalService: voor een dienst- of vestigingspagina, met areaServed en een verwijzing naar de organisatie.
Article: voor uitleg en blogs, met headline, auteur (als @id), publicatie- en wijzigingsdatum.
BreadcrumbList: laat zien waar een pagina in je site hangt. Voor een cluster als deze gids maakt dat de hub-en-spoke-structuur expliciet.
FAQPage: vraag-en-antwoordparen. Rich results zijn sinds 2023 beperkt tot overheids- en zorgsites, maar als machineleesbare Q&A kan het nog nuttig zijn, zolang de vragen echt op de pagina staan.

Drie fouten die we op onze eigen site vonden

Bij het schrijven van deze gids heb ik de structured data van on-mind.nl nagelopen. Die was met zorg opgezet en bevatte toch fouten die je met het blote oog niet ziet.

1. De headline van elk artikel was de categorie

Het Article-schema op de kennispagina's gaf als headlinehet categorielabel (‘AI SEO’) in plaats van de titel van het artikel. De auteur stond erin als losse naam, zonder verwijzing naar de Person in het sitebrede schema. En de publicatiedatum was altijd gelijk aan de datum van de laatste wijziging. Voor een systeem dat wil weten wie wat wanneer schreef, drie keer ruis. Nu verwijst elk artikel via @id naar auteur en uitgever, met een eigen BreadcrumbList.

2. Elke pagina claimde de lokale vestiging

Het sitebrede schema beschreef On Mind als zowel Organization als ProfessionalService, met een adres in Haarlem. Daarmee zei elke pagina, ook de homepage, ‘ik ben de lokale dienstverlener in Haarlem’. Tegelijk rankte de homepage beter op ‘seo advies haarlem’ (gemiddeld positie 10,3) dan de pagina die daarvoor bedoeld is (17,7). Of het schema daar de oorzaak van is, weten we niet zeker. Het droeg in elk geval niet bij aan de juiste boodschap. Nu is het sitebrede schema alleen een Organization, en is de Haarlem-pagina de enige ProfessionalService, met parentOrganization naar de organisatie. Het effect meten we vanaf oktober.

3. Te weinig sameAs

De persoon had één sameAs-link (LinkedIn), de organisatie geen enkele. Dat is de zwakste plek van ons eigen schema, en de reden is simpel: sameAs heeft alleen zin als er elders een profiel is om naar te verwijzen. Een bedrijfspagina op LinkedIn, vermeldingen bij vakverenigingen, een Wikidata-item als je daarvoor in aanmerking komt: dat bouw je buiten je site op, niet in je code.

Zo pak je het aan

Begin sitebreed. Eén Organization, de Person(s) erachter en de WebSite, onderling verbonden met @id. Zet het in je layout, zodat het op elke pagina staat.
Voeg per paginatype het juiste schema toe, dat naar de sitebrede entiteiten verwijst in plaats van ze te herhalen.
Houd markup en pagina gelijk. Staat er een prijs, een adres of een FAQ in je schema, dan staat die ook zichtbaar op de pagina.
Valideer. Eerst in de Schema Markup Validator, dan in de Rich Results Test, en daarna periodiek in Search Console.
Werk sameAs bij zodra er een nieuw profiel of een nieuwe vermelding bijkomt. Dit is het onderdeel dat met je autoriteit meegroeit.

Structured data is één bouwsteen van GEO. Hoe het samenvalt met citeerbare content, toegang voor AI-crawlers en vermeldingen elders, lees je in de complete gids over GEO optimalisatie.

Structured data voor AI: zo begrijpen zoekmachines wie je bent