Willem Nales logo
Technical SEO

Schema markup voor AI-zichtbaarheid: wat het wel doet en wat niet bewezen is

30 juni 2026

Willem Nales werkt aan structured data en schema markup op zijn laptop

Schema markup wordt vaak verkocht als dé manier om in AI-antwoorden te komen. Dat is niet aangetoond. Structured data maakt duidelijk wie je bent en wat je pagina is. Dat moet gewoon goed staan, maar zie het als hygiëne en entiteit, niet als citatiegroei.

Dit artikel laat zien wat de tests zeggen, welke types je inricht en hoe je ze koppelt, met een voorbeeld dat je kunt kopiëren.

Schema markup is gestructureerde code (meestal JSON-LD) die expliciet maakt wat er op je pagina staat: wie de auteur is, welke organisatie erachter zit en waar de pagina over gaat. Het maakt entiteiten, auteurs en feiten machineleesbaar. Dat het meer citaties in AI-antwoorden oplevert, is niet bewezen.

Levert schema meer citaties op?

Dat is niet bewezen. Het effect verschilt per engine. Eén experiment liet een groot effect zien voor Google AI Overviews, en niets voor ChatGPT en Gemini. Een andere expert vond geen bewijs dat schema meer doet dan waarvoor het bedoeld is.

Behandel een effect op citaties dus als hypothese. Er bestaat nog geen onafhankelijke testset voor AI-zoeken, dus niemand kan dit hard maken.

Onderzoek wijst bovendien een andere factor aan: merkbekendheid verklaart meer van AI-zichtbaarheid dan techniek. Een goed gebouwde site van een onbekend merk blijft vaak onzichtbaar. Perfect schema verandert dat niet.

Levert schema meer verkeer op?

Zelden. In 121 gepubliceerde SEO-tests leverde schema in 2 van de 13 tests verkeer op. Article-schema, JSON-LD in plaats van microdata en dateModified gaven geen effect of zelfs verlies.

Schema werkt wel als er een zichtbaar rich result aan hangt. Review- en prijsschema gaven +20%. Breadcrumbs die zichtbaar werden in de zoekresultaten gaven +5%.

Een kanttekening: dit zijn vooral grote sites, en de testaanbieder kiest zelf wat hij publiceert. Gebruik het om te prioriteren, niet als garantie.

Waarom doe je het dan wel?

Omdat het duidelijk maakt wie er spreekt. Een mens leest een pagina en begrijpt dat er een datum, een auteur en een onderwerp zijn. Schema zet dat onomwonden neer: dit is een artikel, geschreven door deze persoon, over dit onderwerp, en deze persoon hoort bij deze organisatie.

Daarmee voorkom je verwarring over wie je bent. Of een engine dat ook meeweegt bij het kiezen van bronnen, weten we niet. Dat hoeft ook niet: de reden om het te doen is correctheid.

Welke schema-types richt je in?

Je hoeft niet alles te markeren. Begin bij je entiteit.

Organization en Person: je entiteit

Dit is de basis. Eén Organization met een vaste @id, altijd dezelfde. Werk je als persoon, voeg dan een Person toe en koppel die aan de organisatie. Zet in sameAs alleen profielen die echt van hetzelfde merk zijn. Heb je regionale vestigingen, laat die dan terugwijzen naar de moeder.

Article: bron en datum

Geef per artikel de auteur en de uitgever mee als verwijzing naar die @id’s, plus de datum van publicatie en wijziging. Laat die kloppen met wat op de pagina staat. Reken er niet op voor verkeer: auteursinformatie en een ‘laatst gewijzigd’-datum waren in de tests neutraal. Doe het voor vertrouwen en duidelijkheid.

FAQPage en HowTo: eerst de zichtbare tekst

Zet vragen en stappen vooral zichtbaar op de pagina. Dat is wat telt: een zichtbare FAQ gaf +9,7% op categoriepagina’s, en een H2 als vraag won in tests. De opmaak eromheen levert zelden iets los op.

Heb je FAQ-schema al staan, haal het dan niet zomaar weg: dat gaf in tests geen effect of zelfs verlies. Markeer alleen echte vragen met echte antwoorden die op de pagina staan.

Product en Review: hier kan wel verkeer zitten

Dit is de categorie met een zichtbaar rich result. Review- en prijsschema gaven in de tests +20%. Markeer alleen wat daadwerkelijk op de pagina staat. Verzonnen reviews zijn een directe weg naar verlies van vertrouwen.

Hoe implementeer je het zonder fouten?

Kies JSON-LD voor het onderhoud

Gebruik JSON-LD. Het staat als één blok los van je HTML, dus het breekt minder snel als je je template aanpast. Dat is een keuze voor onderhoud: JSON-LD in plaats van microdata gaf in de tests geen effect op verkeer.

Een compacte @graph die een artikel aan zijn auteur en organisatie koppelt, ziet er zo uit:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Person",
      "@id": "https://jouwsite.nl/#auteur",
      "name": "Voornaam Achternaam",
      "jobTitle": "SEO Consultant",
      "worksFor": { "@id": "https://jouwsite.nl/#organization" }
    },
    {
      "@type": "Organization",
      "@id": "https://jouwsite.nl/#organization",
      "name": "Jouw Merk",
      "url": "https://jouwsite.nl/",
      "sameAs": ["https://www.linkedin.com/company/jouw-merk"]
    },
    {
      "@type": "BlogPosting",
      "headline": "Titel van je artikel",
      "datePublished": "2026-06-28",
      "author": { "@id": "https://jouwsite.nl/#auteur" },
      "publisher": { "@id": "https://jouwsite.nl/#organization" },
      "inLanguage": "nl"
    }
  ]
}

Die @id-verwijzingen doen het werk. Je definieert de auteur en de organisatie één keer, en elke pagina verwijst daarnaar in plaats van een losse kopie te maken.

De fouten die je wilt voorkomen

  • Markup die niet klopt met de pagina. Dit is het grootste risico. Een breadcrumb-link weghalen zonder de schema aan te passen kostte in een test 5,5%. Haal breadcrumbs in HTML en schema dus uit één bron en wijzig ze samen.
  • Ontbrekende verplichte velden. Voor een rich result moeten de verplichte velden er staan.
  • Losse blokken zonder koppeling. Staan auteur en organisatie nergens aan elkaar vast, dan is niet duidelijk dat ze bij elkaar horen.
  • Datums en types door elkaar. Kleine formaatfouten die je markup stil ongeldig maken.

Testen en monitoren

Valideer elk type dat je publiceert, en doe dat opnieuw na elke grote template- of platformwijziging. Schema sneuvelt makkelijk bij een migratie, dus houd het in je vaste controles. Meer over dat risico lees je in SEO-migratie zonder verkeersverlies.

Checklist voor implementatie

  • Eén Organization met een vaste @id, sitebreed.
  • sameAs alleen naar profielen van hetzelfde merk.
  • Person voor je auteurs, gekoppeld aan de organisatie.
  • Article of BlogPosting met auteur en datums die kloppen met de pagina.
  • FAQPage alleen waar echte vragen en antwoorden zichtbaar staan.
  • Breadcrumbs in HTML en schema uit één bron.
  • Gevalideerd, en opnieuw gecontroleerd na elke grote wijziging.

Conclusie en next step

Schema is hygiëne en entiteit. Doe het goed, houd het kloppend en wijzig het nooit zonder de HTML mee te nemen. Verwacht er alleen verkeer van als er een zichtbaar rich result aan hangt, en verkoop het niet als citatiegroei.

Wil je weten of jouw structured data klopt en je entiteit goed neerzet? Vraag een technische schema-audit aan.

Verder met AI

Neem dit artikel mee naar een AI

Wil je dit toepassen op jouw situatie? Neem het artikel mee naar een AI en stel je vervolgvragen. Opent in een nieuw tabblad, deze pagina blijft gewoon openstaan.

Lees ook

Verder met dit onderwerp

Wil je weten waar de techniek van je site groei tegenhoudt? De audit zet het op een rij, op volgorde van impact.

Gratis SEO-scan

Inzicht in je huidige SEO-fundament

Benieuwd waar de grootste groeikansen liggen? Ik analyseer je website en deel mijn eerste bevindingen.

Je ontvangt een korte analyse, vrijblijvend en zonder verplichtingen.