Gestructureerde data (schema.org): waarom AI sommige sites citeert en andere niet

Wat gestructureerde data zijn

Een machine die je site leest, ziet tekst, maar begrijpt niet altijd wat elk ding is. Gestructureerde data plakken er labels op: dit is een product, dit is zijn prijs, dit is een veelgestelde vraag, dit is de auteur. Het standaardvocabulaire heet schema.org en wordt zowel door zoekmachines als door AI-modellen gebruikt. Deze gids legt uit waarom ze helpen om geciteerd te worden, welke types op welke pagina horen met complete voorbeelden, welke fouten geloofwaardigheid kosten en hoe je controleert of alles klopt.

JSON-LD, de makkelijke manier

Er zijn meerdere manieren om schema te schrijven, maar de aanbevolen is JSON-LD: een scriptblok in JSON-formaat dat je in de head of body van de pagina zet. Het verandert niets aan wat de gebruiker ziet en blijft gescheiden van de zichtbare HTML, dus het is makkelijk te genereren en na te kijken. Gebruik je Cursor, Bolt of Lovable, dan is je AI vragen om het JSON-LD voor een specifieke pagina te genereren een kwestie van één prompt. Het alternatief, microdata ingebed in de HTML-tags, werkt net zo goed maar is lastiger te onderhouden.

Waarom het helpt om geciteerd te worden

Wanneer een model je pagina moet samenvatten, vermindert schema de dubbelzinnigheid. In plaats van af te leiden dat een getal een prijs is, weet het dat. In plaats van te raden wie het artikel schreef, leest het dat. In plaats van te concluderen dat "Scanaris" een bedrijf is en geen persoon, staat het gedeclareerd. Minder raden betekent meer vertrouwen, en meer vertrouwen betekent meer kans om als bron gebruikt te worden. Bovendien verbindt schema je site met de rest van het internet: het veld sameAs linkt naar je profielen en het model begrijpt dat alles over dezelfde entiteit gaat.

Welke types je toevoegt en met welke eigenschappen

Organization op de homepage: naam, logo, URL, beschrijving in één zin en sameAs met je publieke profielen.
SoftwareApplication (of Product) op de product- of prijzenpagina: naam, beschrijving, categorie, besturingssysteem of platform, en offers met prijs en valuta.
FAQPage waar echte, zichtbare vragen en antwoorden staan.
Article of BlogPosting bij posts, met auteur, publicatie- en wijzigingsdatum.
BreadcrumbList om context te geven over waar elke pagina past.
WebSite op de homepage, met de naam van de site, wat helpt om correct in de resultaten te verschijnen.

Voeg ze niet allemaal zomaar toe. Markeer alleen wat echt op de pagina staat.

Een compleet voorbeeld voor een app

Zo ziet het blok van de homepage van een softwareproduct eruit, met de organisatie en de applicatie in één graaf:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://jouwdomein.com/#org",
      "name": "Jouw Product",
      "url": "https://jouwdomein.com",
      "logo": "https://jouwdomein.com/logo.png",
      "description": "Jouw Product is een [wat het is] voor [wie] dat [wat het oplevert].",
      "sameAs": [
        "https://github.com/jouwproduct",
        "https://www.linkedin.com/company/jouwproduct",
        "https://x.com/jouwproduct"
      ]
    },
    {
      "@type": "SoftwareApplication",
      "name": "Jouw Product",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Web",
      "url": "https://jouwdomein.com",
      "description": "Jouw Product is een [wat het is] voor [wie] dat [wat het oplevert].",
      "publisher": { "@id": "https://jouwdomein.com/#org" },
      "offers": {
        "@type": "Offer",
        "price": "24",
        "priceCurrency": "EUR",
        "url": "https://jouwdomein.com/pricing"
      }
    }
  ]
}
</script>

Let op dat de beschrijving in beide blokken dezelfde zin is, en het zou dezelfde moeten zijn die op de homepage, in de metabeschrijving en in llms.txt staat. Die exacte herhaling is wat de modellen uiteindelijk citeren.

En een voor veelgestelde vragen

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Wijzigt Jouw Product mijn site?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Nee. Het doet alleen-lezen controles op publieke informatie."
      }
    }
  ]
}
</script>

Elke vraag in de JSON moet, met dezelfde tekst, in het zichtbare deel van de pagina staan.

De meest voorkomende fouten

Markeren wat niet zichtbaar is. Veelgestelde vragen die niet op de pagina staan, verzonnen reviews, een prijs in de JSON die afwijkt van die op de pagina. Het kost geloofwaardigheid en kan je een handmatige actie van Google opleveren.
Verouderde data. Je wijzigt de prijs op de pagina en vergeet het schema. Genereer het JSON-LD uit dezelfde databron als de pagina, niet met de hand.
Inconsistente naam. "Jouw Product" op de homepage, "JouwProduct" in het schema, "jouw-product" op de profielen. Kies één schrijfwijze en gebruik die overal.
Verkeerd type. Een fysiek Product voor een webdienst, of een Article op een prijzenpagina.
Ongeldige JSON. Eén komma te veel en het hele blok wordt stilzwijgend genegeerd.

Waar je het plaatst, afhankelijk van je framework

In Next.js een script-element met type="application/ld+json" in de layout of de pagina, met de JSON geserialiseerd vanuit een object. In Nuxt met useHead en een script van hetzelfde type. In een Vite-SPA in index.html als het blok statisch is, of geïnjecteerd bij het prerenderen als het per pagina varieert. Belangrijk is dat het in de initiële HTML aankomt: een JSON-LD dat pas bestaat na het uitvoeren van JavaScript, wordt niet gelezen door bots die niet renderen.

Hoe je controleert of het klopt

Vraag je pagina op met curl en zoek het blok:

curl -s https://jouwdomein.com/ | grep -o 'application/ld+json' | wc -l

Komt er nul uit, dan komt het niet in de HTML aan. Valideer daarna de inhoud met de test voor rich results van Google of met de validator van schema.org, die syntaxfouten en onbekende eigenschappen aangeven. En lees het zelf: zegt het hetzelfde als de pagina? Zo niet, dan liegt een van de twee.

Scanaris controleert je schema

De pijler AI-zichtbaarheid van Scanaris detecteert of je gestructureerde data hebt, van welk type, of ze zonder JavaScript in de HTML aankomen en of ze zinvol zijn voor de pagina, en geeft je een fix prompt met het voorgestelde JSON-LD om in je AI te plakken. Het is een alleen-lezen controle op de publieke HTML van je site. Het maakt deel uit van de AEO-gids en van de bespreking van SEO en AEO op dezelfde pagina.

Veelgestelde vragen

Bestraft Google onjuist schema?

Schema met syntaxfouten wordt simpelweg genegeerd. Misleidend schema (reviews of vragen markeren die niet bestaan) kan een handmatige actie opleveren die je rich results wegneemt. Markeer alleen het zichtbare.

JSON-LD of microdata?

JSON-LD. Dat raden Google en schema.org aan, het wordt gegenereerd uit data zonder de zichtbare HTML aan te raken en is veel makkelijker te onderhouden.

Is het op elke pagina nodig?

Op de publieke pagina's die begrepen moeten worden: home, product, prijzen, blog, veelgestelde vragen. Het privédashboard heeft het niet nodig, omdat niemand van buiten het leest.