Schema markup technisch implementeren

Schema markup klinkt vaak simpel.

Je voegt wat structured data toe.
Je test de pagina.
De tool geeft groen.
Klaar.

Maar zo werkt het in de praktijk zelden.

Zeker niet op grotere websites.

Schema markup is geen los codeblokje dat je ergens in de pagina plakt en daarna vergeet. Het is een technische laag die moet kloppen met je content, templates, CMS, databronnen, rendering en monitoring.

Een productpagina moet actuele prijsinformatie tonen.
Een artikel moet de juiste auteur en publicatiedatum hebben.
Een breadcrumb moet overeenkomen met de zichtbare structuur.
Een LocalBusiness-schema moet geen oude openingstijden bevatten.
Een FAQ-schema moet passen bij FAQ-content die gebruikers ook echt kunnen zien.

Anders krijg je geen verduidelijking.

Maar ruis.

Technisch goede schema markup doet drie dingen:

het beschrijft de zichtbare content, gebruikt betrouwbare data en blijft op schaal correct.

Dat maakt implementatie belangrijk.

Niet alleen de keuze voor het juiste schema type.

Maar vooral de vraag:

komt de juiste structured data op de juiste pagina terecht, op het juiste moment, met de juiste waarden?

🧭 Waarom technische implementatie van schema markup belangrijk is

Structured data kan zoekmachines helpen om een pagina beter te begrijpen.

Maar alleen als de implementatie klopt.

Een website kan schema markup hebben en toch technische problemen veroorzaken.

Bijvoorbeeld:

• verkeerde waarden
• verouderde data
• dubbele schema’s
• conflicterende markup
• onvolledige velden
• schema dat niet past bij de zichtbare content
• structured data die alleen op sommige templates staat
• schema dat via JavaScript soms niet verschijnt
• productprijzen die niet worden bijgewerkt
• breadcrumbs die afwijken van de zichtbare navigatie
• reviewschema dat niet aan richtlijnen voldoet
• validatie die maar op één voorbeeldpagina is gedaan

Dat laatste gebeurt vaak.

Iemand test één productpagina.

Die is goed.

Dus men denkt:

“Product schema staat goed.”

Maar misschien klopt alleen die ene URL.

Andere productpagina’s missen availability.
Varianten tonen verkeerde prijzen.
Uitverkochte producten blijven op InStock staan.
Reviewdata wordt niet overal geladen.
Een plugin voegt extra Product schema toe.
En categoriepagina’s krijgen per ongeluk ook Product markup.

Bij schema markup zit de echte uitdaging dus niet alleen in toevoegen.

Maar in betrouwbaar beheren.

Op template-niveau.
Met dynamische velden.
Met consistente databronnen.
Met monitoring na livegang.

Want één technische fout in een template kan honderden of duizenden pagina’s raken.

🧱 Wat schema markup technisch is

Schema markup is gestructureerde data in je HTML.

Je geeft zoekmachines daarmee expliciet informatie over wat er op een pagina staat.

Bijvoorbeeld:

dit is een artikel.
Dit is de auteur.
Dit is de publicatiedatum.
Dit is een product.
Dit is de prijs.
Dit is de beschikbaarheid.
Dit is een breadcrumb.
Dit is een organisatie.
Dit is een lokale vestiging.
Dit is een video.
Dit is een afbeelding.

Zonder structured data moet een zoekmachine die informatie vooral uit de normale pagina afleiden.

Met structured data maak je bepaalde informatie explicieter.

Maar let op:

schema markup vervangt de pagina niet.

Het beschrijft de pagina.

Dat verschil is belangrijk.

Je gebruikt schema markup dus niet om informatie toe te voegen die gebruikers niet kunnen zien. Je gebruikt het om bestaande, zichtbare en relevante informatie beter te structureren.

Een zwakke pagina wordt niet ineens sterk door schema markup.

Een lege productpagina wordt geen goede productpagina omdat er Product schema op staat. Een artikel zonder duidelijke inhoud wordt niet waardevoller door Article schema. En een bedrijf zonder zichtbare lokale informatie moet niet via LocalBusiness markup ineens allerlei claims maken.

Schema markup is ondersteuning.

Geen truc.

🧩 JSON-LD, Microdata en RDFa

Structured data kan technisch op meerdere manieren worden toegevoegd.

De drie bekende formaten zijn:

• JSON-LD
• Microdata
• RDFa

Google ondersteunt ze alle drie.

Maar in de meeste SEO-implementaties is JSON-LD de beste keuze.

Niet omdat Microdata of RDFa nooit werken.

Wel omdat JSON-LD meestal makkelijker te beheren, testen en schalen is.

🟨 JSON-LD

JSON-LD staat voor JavaScript Object Notation for Linked Data.

In gewone taal:

een los scriptblok met gestructureerde data.

Bijvoorbeeld:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema markup technisch implementeren",
  "author": {
    "@type": "Organization",
    "name": "PEAK Online Marketing"
  },
  "publisher": {
    "@type": "Organization",
    "name": "PEAK Online Marketing"
  }
}
</script>

JSON-LD staat meestal los van de zichtbare HTML.

Dat maakt het overzichtelijk.

Je hoeft niet door de hele pagina heen schema-attributen te verweven. Je kunt de markup per template genereren en dynamische velden vullen vanuit je CMS, productdatabase of contentmodel.

Daarom is JSON-LD vaak sterk bij:

• blogs
• kennisbanken
• webshops
• lokale vestigingspagina’s
• productpagina’s
• vacaturepagina’s
• recepten
• video’s
• organisaties
• breadcrumbs

Wel moet je zorgen dat de data klopt met de zichtbare content.

Dat JSON-LD technisch los staat, betekent niet dat het inhoudelijk los mag staan.

🧬 Microdata

Microdata wordt direct in de HTML-elementen verwerkt.

Bijvoorbeeld:

<article itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">Schema markup technisch implementeren</h1>
  <p itemprop="author">PEAK Online Marketing</p>
</article>

Dit kan werken.

Maar het wordt al snel minder overzichtelijk.

Vooral bij grotere websites, complexe templates of component-based frontends. De structured data zit dan verweven door je HTML, waardoor beheer en debugging lastiger kunnen worden.

Microdata kan nog voorkomen in oudere thema’s, plugins of legacy-implementaties.

Maar als je opnieuw begint, zou ik meestal JSON-LD kiezen.

🧷 RDFa

RDFa lijkt op Microdata in de zin dat structured data in de HTML zelf wordt verwerkt.

Het wordt vaker gezien in semantische webcontexten en minder vaak als eerste keuze in praktische SEO-implementaties.

Ook RDFa kan technisch geldig zijn.

Maar voor de meeste marketingwebsites, webshops en kennisbanken is JSON-LD eenvoudiger te beheren.

De praktische keuze is dus meestal:

gebruik JSON-LD, tenzij je een goede reden hebt om iets anders te doen.

🏗️ Waar plaats je schema markup in de pagina?

JSON-LD wordt vaak in de <head> geplaatst.

Maar het kan ook in de body staan.

Belangrijker dan de exacte plek is dat Google de structured data kan vinden, verwerken en koppelen aan de juiste pagina-inhoud.

Een simpele implementatie ziet er zo uit:

<head>
  <title>Schema markup technisch implementeren</title>

  <script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Schema markup technisch implementeren"
  }
  </script>
</head>

Bij moderne websites wordt schema markup meestal per template gegenereerd.

Bijvoorbeeld:

• Article schema op artikeltemplates
• Product schema op producttemplates
• BreadcrumbList op pagina’s met breadcrumbs
• Organization schema op bedrijfsbrede pagina’s
• LocalBusiness schema op vestigingspagina’s
• VideoObject op pagina’s met belangrijke video’s

Vermijd handmatig kopiëren en plakken.

Dat lijkt snel.

Maar het gaat bijna altijd ergens mis.

Iemand vergeet een datum aan te passen.
Een auteur blijft verkeerd staan.
Een prijs raakt verouderd.
Een image-URL klopt niet meer.
Een pagina gebruikt markup van een andere pagina.

Schema markup moet zoveel mogelijk uit dezelfde databron komen als de zichtbare content.

Dus als de prijs op een productpagina uit je productdatabase komt, moet de prijs in je Product schema ook uit diezelfde bron komen. Als je breadcrumb zichtbaar uit je sitestructuur komt, moet BreadcrumbList niet handmatig een andere hiërarchie verzinnen.

Dat voorkomt mismatch.

En mismatch is een van de grootste structured data-risico’s.

🧠 Schema markup moet kloppen met zichtbare content

Structured data moet overeenkomen met wat gebruikers op de pagina kunnen zien.

Dat is geen detail.

Dat is de basis.

Schema markup is niet bedoeld om extra claims te verstoppen voor zoekmachines.

Dus niet:

de pagina toont geen reviews, maar schema zegt dat er 4,9 sterren zijn.

Niet:

de pagina toont geen FAQ, maar JSON-LD bevat FAQPage markup.

Niet:

een product is uitverkocht, maar Product schema zegt InStock.

Niet:

de zichtbare breadcrumb is “Home > Blog > Artikel”, maar BreadcrumbList zegt “Home > SEO > Technische SEO > Artikel”.

Niet:

een artikel is twee jaar oud, maar datePublished wordt automatisch elke dag naar vandaag gezet.

Dat soort dingen maken structured data onbetrouwbaar.

En ze kunnen problemen veroorzaken.

Veelvoorkomende mismatches

Let vooral op bij:

• prijs
• voorraad
• reviewscore
• aantal reviews
• auteur
• publicatiedatum
• updatedatum
• breadcrumbpad
• lokale openingstijden
• adresgegevens
• productafbeeldingen
• FAQ-vragen
• vacaturestatus
• evenementdatum
• video-informatie

Deze velden veranderen vaak.

Daarom moeten ze niet los worden beheerd in een statisch schema-blokje.

Ze moeten uit betrouwbare velden komen.

Een goede vuistregel:

als de zichtbare pagina verandert, moet de structured data automatisch mee veranderen.

🔄 Schema markup op template-niveau implementeren

Schema markup wordt pas echt krachtig wanneer je het op template-niveau implementeert.

Niet pagina voor pagina.

Voor een kleine website kun je misschien nog handmatig iets toevoegen.

Maar zodra je werkt met tientallen, honderden of duizenden URL’s, moet schema markup schaalbaar zijn.

Denk aan:

• alle blogartikelen krijgen Article of BlogPosting schema
• alle productpagina’s krijgen Product schema
• alle vestigingspagina’s krijgen LocalBusiness schema
• alle vacaturepagina’s krijgen JobPosting schema
• alle video-landingspagina’s krijgen VideoObject schema

Het voordeel:

je hoeft schema niet per URL te bouwen.

Je bouwt het één keer goed in de template.

Daarna vult het CMS de juiste waarden in.

Bijvoorbeeld:

• titel
• auteur
• datum
• afbeelding
• productnaam
• prijs
• voorraad
• SKU
• categorie
• breadcrumb
• organisatie
• vestiging
• video thumbnail

Maar hier zit ook het risico.

Een templatefout schaalt mee.

Als je Product template een fout bevat, kan die fout op alle productpagina’s staan. Als je Article template de verkeerde auteur gebruikt, kan dat op alle artikelen gebeuren. Als je breadcrumbtemplate een verkeerde URL-opbouw heeft, raakt dat de hele site.

Daarom test je niet één URL.

Je test patronen.

Bijvoorbeeld:

• normaal product
• uitverkocht product
• product met korting
• product zonder review
• product met varianten
• oud artikel
• nieuw artikel
• artikel met auteur
• artikel zonder afbeelding
• vestiging met afwijkende openingstijden
• categorie met meerdere niveaus

Schema markup is templatewerk.

En templatewerk vraagt om representatief testen.

🧰 Schema markup in CMS’en, plugins en platforms

Veel structured data wordt niet met de hand gebouwd.

Het komt uit CMS’en, plugins, thema’s, apps of platformfunctionaliteit.

Denk aan:

• WordPress
• WooCommerce
• Shopify
• Magento
• Webflow
• headless CMS’en
• custom frameworks
• SEO-plugins
• reviewplugins
• productfeedtools
• pagebuilders
• tagmanagers

Dat is niet verkeerd.

Sterker nog: plugins en platformen kunnen veel werk uit handen nemen.

Maar ze kunnen ook rommel veroorzaken.

Vooral wanneer meerdere systemen tegelijk schema markup toevoegen.

Bijvoorbeeld:

SEO-plugin voegt Article schema toe.
Het theme voegt ook Article schema toe.
Een breadcrumbplugin voegt BreadcrumbList toe.
Een reviewplugin voegt AggregateRating toe.
WooCommerce voegt Product schema toe.
Google Tag Manager injecteert nog extra JSON-LD.
Een developer heeft ooit handmatig Organization schema toegevoegd.

Dan heb je niet per se betere structured data.

Je hebt vooral meer structured data.

En meer is niet automatisch beter.

Controleer de output, niet alleen de instelling

Een plugininstelling kan er goed uitzien.

Maar uiteindelijk telt de HTML-output.

Controleer dus:

• welke schema types staan er op de pagina?
• komen ze uit één bron of meerdere bronnen?
• zijn er dubbele blokken?
• spreken blokken elkaar tegen?
• staan dezelfde entiteiten meerdere keren los beschreven?
• komen waarden overeen met zichtbare content?
• zijn verplichte velden aanwezig?
• zijn aanbevolen velden logisch gevuld?
• blijft de markup goed na pluginupdates?

Gebruik plugins dus niet blind.

Gebruik ze als hulpmiddel.

Niet als excuus om de output niet te controleren.

⚙️ Schema markup bij JavaScript-sites

Bij JavaScript-sites moet je extra opletten.

Structured data kan via JavaScript worden gegenereerd of geïnjecteerd.

Dat kan werken.

Maar het voegt afhankelijkheid toe.

Want dan moet rendering goed gaan voordat de structured data zichtbaar wordt voor Google.

Voor SEO-kritieke schema markup is server-side of statisch gegenereerde JSON-LD vaak robuuster.

Bijvoorbeeld via:

• SSR
• SSG
• static rendering
• server components
• template-output
• CMS-rendering

Dan staat de structured data al in de HTML die de server teruggeeft.

Dat is sterker dan schema dat pas na een client-side API-call wordt toegevoegd.

Waar het mis kan gaan

JavaScript-gegenereerde schema markup kan misgaan wanneer:

• de API traag of onbereikbaar is
• rendering faalt
• structured data pas na hydration verschijnt
• een route generieke metadata houdt
• Product schema lege waarden krijgt
• JSON-LD pas na interactie wordt toegevoegd
• Tag Manager niet tijdig laadt
• client-side routing oude schema laat staan
• meerdere routes hetzelfde schema behouden
• crawlers JavaScript beperkt of niet uitvoeren

Dat laatste is extra belangrijk.

Google kan JavaScript vaak renderen.

Maar niet elke crawler doet dat.

En zelfs bij Google wil je SEO-kritieke structured data zo robuust mogelijk aanbieden.

Test met URL, niet alleen met code

Bij JavaScript-sites is URL-testen belangrijk.

Een los codeblok testen zegt alleen of het stukje JSON-LD technisch valide is.

Maar het zegt niet altijd of de echte pagina het schema na rendering correct bevat.

Test daarom de live URL.

Controleer ook de rendered HTML.

En vergelijk eventueel:

• broncode
• rendered DOM
• Rich Results Test
• URL Inspection Tool
• JavaScript-rendered crawl

Zo zie je of structured data echt beschikbaar is.

Niet alleen bedoeld.

🏷️ Welke schema types implementeer je technisch?

Je hoeft niet elk schema type te gebruiken.

En je moet zeker niet elk Schema.org-type toevoegen omdat het bestaat.

Kies schema markup op basis van:

• paginatype
• zichtbare content
• zoekresultaatmogelijkheden
• technische betrouwbaarheid
• onderhoudbaarheid
• strategische waarde

Niet elk schema type levert een rich result op in Google.

En zelfs als een type in aanmerking komt, betekent dat niet dat Google het rich result ook altijd toont.

Daarom moet je schema markup technisch én strategisch kiezen.

🧭 BreadcrumbList

BreadcrumbList is vaak nuttig bij websites met duidelijke hiërarchie.

Bijvoorbeeld:

• webshops
• kennisbanken
• blogs
• categoriepagina’s
• dienstensites
• websites met hubs en modules

Breadcrumb schema helpt zoekmachines de paginalocatie binnen de sitestructuur beter begrijpen.

Let op:

de BreadcrumbList moet overeenkomen met de zichtbare of logische breadcrumbstructuur.

Dus niet willekeurig andere paden maken omdat dat SEO-technisch mooier lijkt.

📰 Article of BlogPosting

Article of BlogPosting schema past bij redactionele content.

Bijvoorbeeld:

• blogartikelen
• kennisbankartikelen
• handleidingen
• longform content

Belangrijke velden zijn vaak:

• headline
• author
• publisher
• datePublished
• dateModified
• image
• mainEntityOfPage

Let vooral op dat datums eerlijk zijn.

Een updatedatum mag veranderen wanneer de content echt is bijgewerkt.

Niet omdat je automatisch elke dag “vandaag” wilt tonen.

🛒 Product

Product schema is belangrijk voor webshops en productpagina’s.

Denk aan:

• productnaam
• afbeelding
• merk
• SKU
• prijs
• valuta
• beschikbaarheid
• reviews
• rating
• aanbiedingen
• verzendinformatie waar relevant
• retourinformatie waar relevant

Dit type is gevoelig omdat productdata vaak verandert.

Prijs en voorraad moeten actueel blijven.

Ook moet Product schema passen bij echte productpagina’s.

Gebruik het niet op categoriepagina’s alsof de hele categorie één product is.

🏢 Organization

Organization schema beschrijft een organisatie.

Bijvoorbeeld:

• bedrijfsnaam
• logo
• URL
• contactgegevens
• social profielen
• oprichtingsinformatie waar relevant
• identificerende gegevens waar zinvol

Gebruik dit vooral consistent.

Vaak hoort Organization schema op de homepage of in een sitebrede entiteitenstructuur.

Voorkom dat elke pagina een andere versie van dezelfde organisatie beschrijft.

📍 LocalBusiness

LocalBusiness schema past bij lokale bedrijven of vestigingen.

Bijvoorbeeld:

• winkels
• kantoren
• praktijken
• restaurants
• lokale dienstverleners
• vestigingspagina’s

Gebruik LocalBusiness vooral wanneer de pagina echt over die locatie gaat.

Let op:

• naam
• adres
• telefoonnummer
• openingstijden
• geo-informatie
• URL
• relevante categorie
• afbeeldingen

Verouderde openingstijden zijn hier een klassiek probleem.

Zeker bij feestdagen, verhuizingen en tijdelijke sluitingen.

🎥 VideoObject

VideoObject is relevant wanneer video een belangrijke rol speelt op de pagina.

Bijvoorbeeld:

• tutorials
• productvideo’s
• webinars
• uitlegvideo’s
• interviews
• demonstraties

Let op velden zoals:

• name
• description
• thumbnailUrl
• uploadDate
• duration
• embedUrl of contentUrl waar relevant

De video moet echt zichtbaar en beschikbaar zijn voor gebruikers.

Niet alleen in structured data bestaan.

❓ FAQPage

FAQPage vraagt extra nuance.

FAQ structured data is niet meer automatisch interessant voor elke website of elk artikel. Google toont FAQ-rich-results veel beperkter dan vroeger en de toepassing is vooral nog relevant in specifieke situaties.

Dat betekent niet dat FAQ’s op je pagina nutteloos zijn.

Integendeel.

FAQ’s kunnen nog steeds sterk zijn voor gebruikers en contentkwaliteit.

Maar voeg FAQPage schema niet blind toe aan elke FAQ-sectie met het idee dat je automatisch extra zichtbaarheid krijgt.

Gebruik het alleen wanneer:

• de FAQ zichtbaar op de pagina staat
• de vragen en antwoorden inhoudelijk nuttig zijn
• de markup past bij de richtlijnen
• het technisch betrouwbaar wordt gegenereerd
• je een goede reden hebt om het te ondersteunen

FAQ-content is dus vaak waardevol.

FAQ-schema is contextafhankelijk.

🧬 Entiteiten, @id en samenhang tussen schema’s

Goede schema markup bestaat niet alleen uit losse blokjes.

Je wilt samenhang.

Daar komt @id om de hoek kijken.

Met @id kun je entiteiten een vaste identificatie geven binnen je structured data.

Bijvoorbeeld je organisatie:

{
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "PEAK Online Marketing",
  "url": "https://www.example.com/"
}

Een artikel kan dan verwijzen naar diezelfde organisatie als publisher:

{
  "@type": "Article",
  "headline": "Schema markup technisch implementeren",
  "publisher": {
    "@id": "https://www.example.com/#organization"
  }
}

Dat voorkomt dat je organisatie op elke pagina als een losse, nieuwe entiteit wordt beschreven.

Je bouwt meer samenhang.

Denk aan relaties tussen:

• website
• organisatie
• auteur
• artikel
• product
• categorie
• breadcrumb
• lokale vestiging
• video
• afbeelding

Dit hoeft niet onnodig complex te worden.

Maar bij grotere websites kan een consistente entiteitenstructuur helpen om schema markup schoner en logischer te maken.

De kern:

beschrijf niet alleen losse dingen.

Beschrijf hoe ze bij elkaar horen.

🧪 Schema markup testen

Schema markup moet je altijd testen.

Niet alleen vóór livegang.

Ook daarna.

Gebruik meerdere tools, omdat elke tool iets anders laat zien.

🔎 Rich Results Test

De Rich Results Test laat zien of Google markup herkent die in aanmerking kan komen voor rich results.

Dat is handig voor Google-specifieke features.

Je ziet bijvoorbeeld:

• welke rich-result-types Google herkent
• welke errors er zijn
• welke warnings er zijn
• of verplichte velden ontbreken
• hoe Google de URL verwerkt

Gebruik bij voorkeur de URL-test voor echte pagina’s.

Zeker bij JavaScript-sites.

Dan test je niet alleen een los codeblok.

Je test de pagina zoals Google hem probeert op te halen en te verwerken.

🧪 Schema Markup Validator

De Schema Markup Validator is breder.

Die kijkt meer naar algemene Schema.org-validatie.

Dat is nuttig omdat niet elk schema type of elke property direct een Google-rich-result oplevert.

Gebruik deze tool om te controleren of je structured data logisch en volgens Schema.org is opgebouwd.

Maar let op:

Schema.org-valid betekent niet automatisch Google-rich-result-eligible.

En Google-valid betekent niet automatisch dat je schema strategisch nuttig is.

Je hebt beide brillen nodig.

🔍 URL Inspection Tool

Met URL-inspectie in Google Search Console controleer je hoe Google een specifieke URL ziet.

Dit is vooral nuttig na livegang.

Je kunt controleren:

• of Google de pagina kan ophalen
• of de pagina indexeerbaar is
• welke canonical Google ziet
• of Google structured data detecteert
• hoe de live URL wordt verwerkt
• of er renderingproblemen zijn
• of resources geblokkeerd zijn

Gebruik URL-inspectie vooral bij belangrijke templates of wanneer Rich Results Test en Search Console verschillende signalen geven.

🕷️ Screaming Frog

Met Screaming Frog kun je structured data op schaal crawlen.

Dat is belangrijk bij grotere websites.

Controleer bijvoorbeeld:

• welke URL’s structured data hebben
• welke URL’s structured data missen
• welke types per template voorkomen
• welke errors terugkomen
• welke warnings vaak voorkomen
• of JSON-LD-blokken dubbel staan
• of markup verschilt tussen paginatypes
• of structured data pas na JavaScript-rendering verschijnt
• of dezelfde pagina meerdere conflicterende schema’s heeft

Voor technische SEO is dit vaak de meest praktische auditstap.

Niet één URL testen.

Maar patronen vinden.

🧰 Handmatige codecheck

Tools zijn handig.

Maar kijk ook zelf.

Vooral bij dynamische velden.

Controleer:

• waar komt de prijs vandaan?
• waar komt de voorraadstatus vandaan?
• waar komt de auteur vandaan?
• waar komt de reviewscore vandaan?
• waar komt de afbeelding vandaan?
• waar komt de breadcrumb vandaan?
• wat gebeurt er als een veld leeg is?
• wat gebeurt er bij uitzonderingen?
• wat gebeurt er bij oude content?
• wat gebeurt er na een templatewijziging?

Veel structured data-fouten zijn geen pure validatiefouten.

Ze zijn datakwaliteitsproblemen.

En die zie je niet altijd met alleen een validator.

🚨 Fouten, waarschuwingen en validatie begrijpen

Structured data-tools geven vaak errors en warnings.

Die moet je goed interpreteren.

Een error is meestal serieus.

Een warning is contextafhankelijk.

Errors

Errors betekenen vaak dat verplichte informatie ontbreekt of dat markup technisch niet voldoet aan de eisen voor een bepaald rich result.

Bijvoorbeeld:

• verplichte property ontbreekt
• waarde heeft verkeerd formaat
• URL is ongeldig
• datum is niet correct geformatteerd
• markup is niet goed parsebaar
• type wordt verkeerd gebruikt

Errors kunnen ervoor zorgen dat een pagina niet in aanmerking komt voor een rich result.

Los ze dus serieus op.

Warnings

Warnings betekenen vaak dat aanbevolen velden ontbreken.

Dat hoeft niet altijd blokkerend te zijn.

Maar het kan wel betekenen dat je markup minder compleet is.

Bijvoorbeeld:

Product schema werkt technisch, maar mist aanbevolen velden zoals review, aggregateRating of shippingDetails.

Dat is niet altijd fout.

Misschien heeft het product geen reviews.

Dan moet je geen nepreview toevoegen om een warning weg te krijgen.

Een warning is dus geen opdracht om blind velden te vullen.

Het is een signaal om na te denken:

hebben we deze informatie echt?

Is die zichtbaar?

Is die betrouwbaar?

Is die nuttig?

Valid betekent niet automatisch zichtbaar

Dit is belangrijk.

Een groene test betekent niet:

je krijgt een rich result.

Een groene test betekent ook niet:

dit helpt rankings.

En een groene test betekent zeker niet:

de implementatie is strategisch perfect.

Het betekent alleen dat de markup technisch voldoet aan bepaalde controles.

Daarna blijven er vragen over:

• past de markup bij de pagina?
• is de data actueel?
• is het type relevant?
• wordt het op alle juiste templates toegepast?
• zijn er geen dubbele of conflicterende schema’s?
• is de content zichtbaar voor gebruikers?
• heeft dit rich result nog echte waarde?
• blijft het goed na updates?

Validatie is het begin.

Niet het eindpunt.

📉 Waarom schema markup geen rankingtruc is

Schema markup is geen magische rankingknop.

Je voegt geen structured data toe en springt ineens naar positie één.

Zo werkt SEO niet.

Structured data helpt zoekmachines vooral om content beter te begrijpen en kan pagina’s in aanmerking laten komen voor bepaalde zoekresultaatweergaven.

Maar het maakt slechte content niet goed.

Een slecht product blijft een slecht product.
Een dun artikel blijft een dun artikel.
Een onduidelijke pagina blijft onduidelijk.
Een trage template blijft traag.
Een zwakke interne linkstructuur blijft zwak.

Schema markup moet dus niet worden gebruikt als truc om meer te beloven dan de pagina waarmaakt.

Gebruik het om sterke, zichtbare content duidelijker te structureren.

Dat is de gezonde rol.

📊 Schema markup monitoren na livegang

Schema markup kan kapotgaan.

Ook als het eerst goed stond.

Een pluginupdate verandert output.
Een developer past een template aan.
Een CMS-veld krijgt een andere naam.
Een productfeed wijzigt.
Een reviewtool laadt anders.
Een prijsveld wordt leeg.
Een voorraadstatus wordt niet meer bijgewerkt.
Een redesign verwijdert breadcrumbs.
Een migratie verandert URL’s.
Een JavaScript-update breekt injectie.

Daarom hoort monitoring bij technische implementatie.

Niet optioneel.

Wat monitor je?

Controleer periodiek:

• structured data-errors in Search Console
• rich-result-rapporten waar beschikbaar
• belangrijke templates
• Product schema op voorraad en prijs
• Article schema op auteur en datums
• BreadcrumbList op URL’s en volgorde
• LocalBusiness op openingstijden en adres
• Organization schema op logo en URL
• VideoObject op thumbnails en video-URL’s
• dubbele schema’s door plugins
• schema na CMS- of pluginupdates
• schema na redesigns of migraties

Voor grote sites kun je structured data meenemen in vaste technische crawls.

Bijvoorbeeld maandelijks.

Of na elke grote release.

Het doel is niet om elke kleine warning obsessief te najagen.

Het doel is om structurele fouten vroeg te zien.

⚠️ Veelgemaakte fouten met schema markup implementeren

Schema markup gaat meestal niet mis omdat mensen helemaal niets doen.

Het gaat mis omdat de implementatie net niet klopt.

❌ Schema toevoegen dat niet overeenkomt met zichtbare content

Dit is de belangrijkste fout.

Structured data moet zichtbare content beschrijven.

Niet extra claims toevoegen.

Geen reviews in schema als ze niet zichtbaar zijn.
Geen FAQPage zonder zichtbare FAQ.
Geen InStock als het product uitverkocht is.
Geen oude openingstijden in LocalBusiness.

❌ Meerdere plugins dubbele schema laten toevoegen

Meer schema is niet automatisch beter.

Als meerdere plugins hetzelfde type toevoegen, kun je dubbele of conflicterende markup krijgen.

Controleer dus altijd de output.

Niet alleen de plugininstellingen.

❌ Product schema niet actueel houden

Product schema is gevoelig.

Prijs, voorraad, reviews en aanbiedingen veranderen vaak.

Als die data niet automatisch uit betrouwbare bronnen komt, wordt schema snel verouderd.

❌ Breadcrumb schema laten afwijken van de structuur

BreadcrumbList moet logisch overeenkomen met de zichtbare of bedoelde hiërarchie.

Gebruik het niet om kunstmatig een andere structuur te suggereren.

❌ Schema handmatig kopiëren

Handmatig kopiëren lijkt snel.

Maar het veroorzaakt vaak verouderde velden.

Voor schaalbare websites hoort schema uit templates en databronnen te komen.

Niet uit losse plakblokken.

❌ Alleen één URL testen

Eén goede test bewijst weinig.

Test meerdere voorbeelden per template.

Ook uitzonderingen.

Zoals uitverkochte producten, oude artikelen, content zonder afbeelding, producten zonder reviews en vestigingen met afwijkende openingstijden.

❌ JavaScript-output niet controleren

Als schema via JavaScript wordt toegevoegd, moet je controleren of het na rendering echt aanwezig is.

Niet alleen in je component.

Niet alleen in je tagmanager.

Maar in de rendered HTML.

❌ Warnings verkeerd oplossen

Een warning betekent niet dat je zomaar data moet verzinnen.

Vul alleen velden die echt bestaan, zichtbaar zijn en betrouwbaar beheerd worden.

Anders maak je de markup misschien completer, maar minder eerlijk.

❌ Denken dat valid schema automatisch rich results oplevert

Valid schema betekent dat je technisch goed zit.

Niet dat Google verplicht is een rich result te tonen.

En ook niet dat het SEO-probleem opgelost is.

Structured data is één laag.

Geen vervanging voor goede content, techniek en autoriteit.

👉 Volgende stap

Je weet nu hoe je schema markup technisch betrouwbaar implementeert.

Niet als los codeblokje.

Maar als onderdeel van je templates, CMS, databronnen, rendering en monitoring.

Daarmee hebben we bijna alle verdiepende onderdelen van technische SEO behandeld.

Nu gaan we door naar het afsluitende artikel van de module:

Technische SEO-audit: problemen vinden en prioriteren.

Daar brengen we alle technische onderdelen samen.

Niet als simpele checklist.

Maar als manier om problemen te herkennen, impact te bepalen en slimme prioriteiten te stellen.

❓ Vragen beantwoord in dit artikel