Gestructureerde data: welke een bedrijfswebsite werkelijk nodig heeft

Gestructureerde data zijn geen rankingfactor. Ze zijn een vertaling: ze vertellen machines wat een tekstblok betekent in plaats van ze te laten raden. Precies dat bepaalt steeds meer of een pagina überhaupt in antwoorden voorkomt.

Een zachte lichtgevende vorm wordt gedragen door een fijn, nauwelijks zichtbaar geraamte dat haar geometrie zichtbaar maakt

Het belangrijkste kort

  • Vier typen volstaan voor vrijwel elke bedrijfssite: Organization, WebPage respectievelijk Article, BreadcrumbList en FAQPage.
  • Uitgeleverd wordt JSON-LD in de <head> – niet als opmaak in de lopende tekst.
  • De meest voorkomende fout is stilzwijgend en duur: gegevens in de gestructureerde data die op de pagina zelf niet staan.
  • Drie veelbesproken typen kan een dienstverlenend bedrijf zich besparen – ze werken alleen bij een passend aanbod of echte beoordelingen.

Een machine die een pagina leest, ziet in eerste instantie alleen tekst. Dat «Emma Woelk» een mens is, «TEISENDA GmbH» een bedrijf en «22 augustus 2026» een publicatiedatum, moet ze raden – of het staat er uitdrukkelijk.

Gestructureerde data zijn dat uitdrukkelijke. Ze verbeteren geen positie. Ze bepalen of een pagina überhaupt in aanmerking komt voor uitgebreide weergaven en voor gegenereerde antwoorden.

De vier die volstaan

1. Organization – één keer, op de startpagina

Wie jullie zijn: naam, adres, logo, oprichtingsjaar, profielen in andere netwerken. Dat is het record dat ervoor zorgt dat er een logo naast het zoekresultaat kan verschijnen – de meest voorkomende reden dat het ontbreekt, is domweg het ontbreken van dit record.

Belangrijk: het logo moet als rasterafbeelding beschikbaar zijn. Een SVG wordt op deze plek niet uitgelezen.

2. WebPage of Article – op elke pagina

Wat deze pagina is: titel, beschrijving, taal, datum van publicatie en van de laatste herziening. Bij artikelen daarnaast Article respectievelijk BlogPosting met de auteur als eigen Person-record – met rol, niet alleen met naam.

Belangrijk: de wijzigingsdatum moet kloppen. Een datum die bij elke paginaopbouw opnieuw wordt gezet, is een signaal dat zichzelf waardeloos maakt.

3. BreadcrumbList – op alle subpagina's

Waar deze pagina in de structuur staat. Zichtbaar als pad bovenaan de pagina, machineleesbaar in de kopsectie. Beide horen bij elkaar – een pad in de data dat op de pagina niet bestaat, is een onjuiste opgave.

4. FAQPage – waar er echte vragen zijn

Het vragenblok aan het eind van een artikel. Voor antwoordmachines het waardevolste type dat er is, omdat het vraag en antwoord al als paar aanlevert – precies de vorm waarin er wordt geciteerd.

Belangrijk: alleen voor vragen die daadwerkelijk zichtbaar op de pagina staan. Verzonnen vragen die alleen in de data staan, zijn een overtreding van de richtlijnen.

Vier duidelijk gescheiden vaten met licht van verschillende dichtheid, daarachter drie lege grijze
Vier gevulde typen dragen meer dan zeven half onderhouden typen.

Drie die je je kunt besparen

Product en Offer. Voor diensten met een offerte op aanvraag leveren ze niets op – zonder prijs en beschikbaarheid worden ze toch niet uitgespeeld. Pas zinvol bij een echte webwinkel.

AggregateRating. Sterren in het zoekresultaat zijn verleidelijk en aan strenge voorwaarden gebonden: de beoordelingen moeten echt, controleerbaar en op de pagina zichtbaar zijn. Zelf toegekende beoordelingen zijn een richtlijnovertreding met een reëel risico.

HowTo. Is in de weergave duidelijk teruggeschroefd en loont het onderhoudswerk voor de meeste bedrijfssites niet meer.

Wist je dat?

Gestructureerde data zijn geen rankingfactor – dat heeft Google meermaals verduidelijkt. Ze bepalen de weergave, niet de positie.

Voor antwoordmachines ligt het iets anders. Een model dat uit een pagina een antwoord moet bouwen, gebruikt bij voorkeur wat eenduidig is gemarkeerd: vraag-antwoordparen, auteur met rol, datum van de laatste toetsing. Het hoeft dan niet te raden wat bij elkaar hoort. Het nut ligt dus minder in de ranking dan in de citeerbaarheid.

Hoe ze worden ingebouwd

Drie regels die de meeste problemen voorkomen.

  1. JSON-LD, in de <head>. Niet als attributen in de lopende tekst. JSON-LD is los van de vormgeving te onderhouden en gaat bij ontwerpwijzigingen niet verloren.
  2. Eén blok per pagina, geen vijf. Meerdere records horen in één @graph en worden via @id aan elkaar gekoppeld. Zo verwijst het artikel naar dezelfde organisatie die op de startpagina staat, in plaats van haar te herhalen.
  3. Uit dezelfde bron genereren als de zichtbare inhoud. Als titel, datum en auteur uit dezelfde velden komen als de pagina zelf, kunnen ze helemaal niet uiteenlopen. Dat is verreweg de werkzaamste preventie.
Uit de praktijk

De duurste fout is de stilste: de gestructureerde data zeggen iets dat op de pagina niet staat. Een wijzigingsdatum van gisteren bij een tekst uit 2023. Een auteur die in het zichtbare deel niet voorkomt. Vragen in de data die op de pagina niet bestaan.

Dat valt geen enkel testgereedschap op – de data zijn formeel geldig. Het valt bij een handmatige toetsing op, en dan betreft het gevolg niet alleen de betrokken markering. Daarom is de regel «uit dezelfde bron genereren» belangrijker dan elke volledigheid.

Toetsen – in deze volgorde

StapWaarmeeWat jullie zien
1. SyntaxisSchema Markup Validatorof de JSON geldig en het type correct is
2. Weergaafbaarheidtest voor rijke zoekresultatenof een uitgebreide weergave mogelijk zou zijn
3. WerkelijkheidSearch Console, onderdeel Verbeteringenwat er daadwerkelijk is herkend, over alle pagina's
4. Overeenstemmingzelf lezenof elke opgave ook zichtbaar op de pagina staat

Stap vier is de enige die geen enkel gereedschap overneemt – en de enige waarbij de ernstige fouten opvallen.

Tip Het onderdeel «Verbeteringen» in de Search Console is de enige bron die laat zien wat er over alle pagina's heen daadwerkelijk is herkend – en niet alleen wat er op één voorbeeldpagina werkt. Bij meertalige sites legt het betrouwbaar bloot dat er bij de laatste verbouwing een taalversie is vergeten.
Prompt
Toets de gestructureerde data van deze pagina op volledigheid en
op overeenstemming met de zichtbare inhoud.

Zichtbare pagina-inhoud:
[tekst van de pagina invoegen]

JSON-LD van de pagina:
[blok invoegen]

Opdrachten:
1. Noem elke opgave in de JSON-LD die in de zichtbare inhoud niet
   voorkomt. Dat is het belangrijkste punt – wees hier grondig.
2. Noem elke zichtbare opgave die gemarkeerd zou moeten worden,
   maar ontbreekt (auteur met rol, wijzigingsdatum, vragen, pad).
3. Toets of de vier basistypen zinvol zijn ingevuld:
   Organization, WebPage/Article, BreadcrumbList, FAQPage.
4. Noem typen in het blok die voor een dienstverlenend bedrijf
   zonder webwinkel en zonder controleerbare beoordelingen geen
   nut hebben.
5. Wijs op elke schending van de richtlijnen, in het bijzonder
   zelf toegekende beoordelingen en vragen die op de pagina niet
   bestaan.

Geef de gecorrigeerde JSON-LD aan het eind volledig uit. Verzin geen
waarden – markeer ontbrekende zaken als [aan te vullen].

Conclusie

Gestructureerde data worden snel overschat en even snel verkeerd gedaan. Vier typen dekken de behoefte van een bedrijfssite af, en hun nut ligt minder in de positie dan in het citeerbaar zijn.

De ene regel die alles draagt: niets markeren wat op de pagina niet staat. Wie de data uit dezelfde bron genereert als de zichtbare inhoud, heeft dat probleem structureel opgelost – en kan de nacontroles grotendeels achterwege laten.

Veelgestelde vragen

Welke gestructureerde data heeft een bedrijfswebsite nodig?

Vier typen volstaan: Organization één keer op de startpagina, WebPage respectievelijk Article op elke pagina, BreadcrumbList op alle subpagina's en FAQPage overal waar er echte, zichtbare vragen zijn. Product, AggregateRating en HowTo lonen voor dienstverlenende bedrijven in de regel niet.

Verbeteren gestructureerde data de ranking?

Nee. Ze zijn geen rankingfactor, maar bepalen de weergave – bijvoorbeeld of er een logo, een pad of uitklapbare vragen in het zoekresultaat kunnen verschijnen. Voor antwoordmachines verhogen ze de citeerbaarheid, omdat vraag-antwoordparen, auteur en datum eenduidig zijn gemarkeerd in plaats van geraden te moeten worden.

Waarom toont Google ons logo niet?

De meest voorkomende reden is een ontbrekend of onvolledig Organization-record op de startpagina. Op één na meest voorkomende reden: het opgegeven logo bestaat alleen als SVG – op deze plek is een rasterafbeelding nodig. Ook bij een correcte markering bestaat er geen recht op weergave.

Wat is de meest voorkomende fout bij gestructureerde data?

Gegevens die in de data staan, maar niet in de zichtbare inhoud: een verkeerde wijzigingsdatum, een niet genoemde auteur, verzonnen vragen. Testgereedschap meldt dat niet, omdat de data formeel geldig zijn. Je voorkomt het door de markering uit dezelfde bron te genereren als de zichtbare tekst.

JSON-LD of microdata?

JSON-LD in de <head>. Het is de door Google aanbevolen vorm, is los van de vormgeving te onderhouden en gaat bij ontwerpwijzigingen niet verloren. Microdata verspreidt de markering over de lopende tekst en breekt bij elke verbouwing van de pagina.

Marketing die zichzelf opzet

De bèta van de Studio Engine is open. Reserveer je plek en denk vanaf het begin mee.

Deelnemen aan de bèta →
← Terug naar het overzicht