JSON-LD implementatie: van rommelig naar gestructureerd in één dag
- Meeste websites dupliceren Organization schema onnodig. Dit kan leiden tot inconsistenties tussen pagina's en onduidelijke signalen naar zoekmachines.
- Site-wide script definieert 3 entiteiten één keer. WebSite, Organization en Person hoeven maar op één plek te staan.
- Page-level JSON-LD blijft beperkt en overzichtelijk. WebPage + Service/BlogPosting + optioneel BreadcrumbList en FAQ.
- Stabiele @id strategie voorkomt linking errors. Gebruik [URL]#webpage, [URL]#service, [URL]#blogpost als consistent fragment pattern.
- 10 veelgemaakte fouten die rich results kunnen breken. Van self-referencing loops tot trailing comma's en smart quotes in JSON strings.
- Implementatie vraagt grondige planning en testing. Site-wide script toevoegen, page template aanpassen, valideren en geleidelijk uitrollen.
Veel websites hebben een JSON-LD implementatie die langzaam is verworden tot een lappendeken. Organization schema op elke pagina. Inconsistente @id's. Service nodes gemengd met BlogPosting waar dat niet hoort. FAQ's die verwijzen naar content die niet op de pagina staat.
Het resultaat: validation errors in Search Console, structured data die onduidelijke signalen geeft, en markup die moeilijk te onderhouden is.
Dit artikel legt uit hoe je JSON-LD implementeert op een manier die schaalt en consistent blijft. Structured data is geen vervanging voor technische SEO, maar wel een essentiële bouwsteen om zoekmachines je pagina-intentie duidelijk te maken.
Waarom bijna alle JSON-LD implementaties rommelig worden
JSON-LD implementaties starten meestal goed. Een developer voegt Organization schema toe op de homepage. Dan komt er een productpagina, en die krijgt ook Organization schema. En een Service node. Dan komen blogartikelen, en die krijgen Organization + BlogPosting. Voor je het weet staat dezelfde Organization definitie op honderden pagina's, maar met subtiele verschillen omdat ze op verschillende momenten zijn toegevoegd.
5 concrete symptomen van drift:
Organization schema met verschillende waardes. Op pagina A staat het logo op 200x200px, op pagina B op 400x400px, op pagina C ontbreekt het helemaal.
Inconsistente @id fragmenten. Sommige pagina's gebruiken #organization, andere #company, weer andere geen @id.
Mixed types zonder logica. Een contactpagina heeft zowel Service als AboutPage als ContactPage schema.
FAQ content die niet bestaat. De FAQ schema bevat vragen die niet op de pagina staan, omdat ze gekopieerd zijn van een template.
Self-referencing loops. WebPage.mainEntityOfPage verwijst naar zichzelf in plaats van naar de Service of BlogPosting.
Deze problemen ontstaan omdat er geen duidelijke scheiding is tussen wat site-wide hoort (altijd hetzelfde) en wat page-level hoort (uniek per pagina). Voor wie een grondige technische SEO audit doet: dit is vaak één van de eerste technische knelpunten die naar boven komt.
“Pagina’s met structured data krijgen 30% meer clicks dan standaard zoekresultaten.”
De kernprincipes die alles oplossen
Google raadt JSON-LD aan omdat het gemakkelijker te implementeren en te onderhouden is dan Microdata of RDFa. Maar alleen als je het op de juiste manier doet.
Vijf principes:
1. Eén page-level JSON-LD script per pagina
Plaats alle page-specific structured data in één <script type="application/ld+json"> blok met een @graph array. Niet vier losse scripts voor WebPage, Service, BreadcrumbList en FAQ. Eén script, één graph, alle nodes erin.
2. Stabiele @id strategie
Elke node krijgt een uniek @id gebaseerd op de canonical page URL plus een fragment. Bijvoorbeeld: https://example.com/seo#webpage, https://example.com/seo#service, https://example.com/blog/artikel#blogpost. Dit patroon gebruik je consequent door de hele site.
3. Strikte scheiding: site-wide vs page-level
Site-wide entities (WebSite, Organization, Person) definieer je één keer in een apart script dat op elke pagina wordt ingeladen. Page-level entities (WebPage, Service, BlogPosting, BreadcrumbList, FAQPage) staan in het page-specific script en verwijzen naar de site-wide entities via hun @id.
4. Match URLs exact met canonical
Gebruik exact dezelfde URL als je canonical URL op de pagina. Als je canonical tag <link rel="canonical" href="https://example.com/over-ons"> is, gebruik dan exact https://example.com/over-ons in je @id en url properties. Match www/non-www en trailing slashes exact met je canonical strategie.
5. Preserve unless invalid (bij het opschonen van bestaande implementaties)
Als je een bestaande JSON-LD implementatie aan het sanitizen bent: verander content niet tenzij die feitelijk onjuist is. Heeft je BlogPosting.description 180 karakters? Laat dat zo. Staat er een werkende image URL? Laat die staan. Verander alleen wat echt fout is. Dit voorkomt onbedoelde ranking impact tijdens het opschonen. Voor nieuwe implementaties: start direct met correcte data volgens de templates hieronder.
“Structured data zorgt niet dat je website beter rankt. Het wordt gebruikt om zoekfuncties weer te geven. Gebruik het als je pagina’s geschikt zijn voor deze functies.”
Wat hoort site-wide (en waarom)
Site-wide entities zijn gegevens die voor de hele website hetzelfde zijn. Deze definieer je één keer in een script dat op elke pagina wordt ingeladen, meestal via je CMS template of header include.
Welke entities hoort site-wide:
WebSite (één website, één WebSite entiteit)
Bevat: name, url, publisher (verwijst naar Organization @id), inLanguage, optioneel potentialAction voor site search
Organization (één bedrijf, één Organization)
Bevat: name, url, logo, sameAs (social profiles), optioneel contactPoint, address, areaServed
Person (consistent auteur of founder, optioneel)
Bevat: name, url, sameAs (LinkedIn, Twitter), worksFor (verwijst naar Organization @id)
Wat NIET site-wide hoort:
Service nodes (uniek per service pagina)
BlogPosting (uniek per artikel)
BreadcrumbList (uniek per pagina)
FAQPage (uniek per pagina waar FAQ staat)
Product (uniek per product)
Minimal vs expanded guidance:
Start minimal. WebSite met name, url, publisher. Organization met name, url, logo. Dat is genoeg. Voeg pas meer toe als je kunt valideren dat het klopt en relevant is.
Voorbeeld: voeg contactPoint alleen toe als je daadwerkelijk een apart klantenservice nummer hebt. Voeg address alleen toe als je een fysieke locatie hebt die relevant is voor je bedrijf. Niet omdat het "compleet" lijkt.
Overzichtstabel: wat hoort waar
Site-wide JSON-LD template (copy-paste)
Dit script plaats je in de <head> van elke pagina, of via een global template include in je CMS.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com",
"name": "[WEBSITE_NAME]",
"inLanguage": "nl-BE",
"publisher": {
"@id": "https://example.com/#organization"
}
},
{
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "[ORGANIZATION_NAME]",
"url": "https://example.com",
"logo": {
"@type": "ImageObject",
"url": "[LOGO_URL]"
},
"sameAs": [
"[SOCIAL_URL_1]",
"[SOCIAL_URL_2]",
"[SOCIAL_URL_3]"
]
},
{
"@type": "Person",
"@id": "https://example.com/#founder",
"name": "[FOUNDER_NAME]",
"url": "https://example.com/over-ons",
"sameAs": [
"[LINKEDIN_URL]"
],
"worksFor": {
"@id": "https://example.com/#organization"
}
}
]
}
</script>Vervang de placeholders:
[WEBSITE_NAME]: "ClickForest" of je bedrijfsnaam[ORGANIZATION_NAME]: Formele bedrijfsnaam[LOGO_URL]: Volledige URL naar je logo (min. 112x112px, bij voorkeur vierkant)[SOCIAL_URL_1/2/3]: LinkedIn, Facebook, Instagram URLs[FOUNDER_NAME]: Naam van de founder/CEO indien relevant[LINKEDIN_URL]: Persoonlijke LinkedIn van founder
Note over Person: Voeg dit blok alleen toe als je een personal brand component hebt in je bedrijf (founder-led, thought leadership). Anders verwijder je dit volledige blok.
“Het helpt hun content om begrepen te worden. Of het nu gaat om details over hun bedrijf, de diensten die ze aanbieden, of de content waar ze zoveel tijd in investeren.”
Page-level JSON-LD voor gewone pagina's (services, locaties, etc.)
Voor gewone pagina's (diensten, over ons, contact, locatie pagina's) gebruik je een beperkte node set.
Minimal baseline checklist:
WebPage (altijd verplicht)
Service (alleen als het echt een service pagina is)
BreadcrumbList (optioneel, alleen als je breadcrumbs consistent doorvoert)
FAQPage (optioneel, alleen als FAQ daadwerkelijk op pagina staat)
Linking regels:
WebPage.isPartOf verwijst naar site-wide WebSite @id
WebPage.mainEntity verwijst naar Service @id
Service.provider verwijst naar site-wide Organization @id
Service.mainEntityOfPage verwijst naar WebPage @id
Linking cheatsheet per pagetype
Canonical template voor service pagina:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://example.com/seo#webpage",
"url": "https://example.com/seo",
"name": "SEO diensten",
"description": "SEO optimalisatie voor bedrijven in België.",
"isPartOf": {
"@id": "https://example.com/#website"
},
"mainEntity": {
"@id": "https://example.com/seo#service"
}
},
{
"@type": "Service",
"@id": "https://example.com/seo#service",
"serviceType": "SEO optimalisatie",
"name": "SEO diensten",
"description": "Technische SEO, content optimalisatie en linkbuilding.",
"provider": {
"@id": "https://example.com/#organization"
},
"areaServed": {
"@type": "Country",
"name": "België"
},
"mainEntityOfPage": {
"@id": "https://example.com/seo#webpage"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://example.com/seo#breadcrumbs",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://example.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "SEO",
"item": "https://example.com/seo"
}
]
}
]
}
</script>Note over BreadcrumbList: Voeg alleen breadcrumbs toe als je ze ook daadwerkelijk toont op de pagina, of als je site een duidelijke hiërarchie heeft die je consistent kan aanhouden. Niet ad hoc op sommige pagina's wel en andere niet.
Note over Product pages: Product pagina's vereisen Product schema met extra properties (offers, availability, reviews, aggregateRating, etc.). Dat valt buiten scope van dit artikel.
Page-level JSON-LD voor blogartikels
Voor blogartikels gebruik je een iets andere set nodes.
Minimal baseline checklist:
WebPage (verplicht)
BlogPosting (verplicht)
BreadcrumbList (sterk aanbevolen)
FAQPage (optioneel, alleen als FAQ op pagina staat)
Linking regels:
BlogPosting.mainEntityOfPage verwijst naar WebPage @id
BlogPosting.author verwijst naar site-wide Person @id (indien gedefinieerd)
BlogPosting.publisher verwijst naar site-wide Organization @id
WebPage.isPartOf verwijst naar site-wide WebSite @id
Canonical template voor blog post:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "WebPage",
"@id": "https://example.com/blog/seo-tips#webpage",
"url": "https://example.com/blog/seo-tips",
"name": "SEO tips voor 2026",
"description": "Overzicht van praktische SEO tips.",
"isPartOf": {
"@id": "https://example.com/#website"
}
},
{
"@type": "BlogPosting",
"@id": "https://example.com/blog/seo-tips#blogpost",
"headline": "SEO tips voor 2026",
"description": "Overzicht van praktische SEO tips.",
"image": "https://example.com/images/seo-tips-header.jpg",
"datePublished": "2026-01-15T10:00:00+01:00",
"dateModified": "2026-01-20T14:30:00+01:00",
"author": {
"@id": "https://example.com/#founder"
},
"publisher": {
"@id": "https://example.com/#organization"
},
"mainEntityOfPage": {
"@id": "https://example.com/blog/seo-tips#webpage"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://example.com/blog/seo-tips#breadcrumbs",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://example.com"
},
{
"@type": "ListItem",
"position": 2,
"name": "Blog",
"item": "https://example.com/blog"
},
{
"@type": "ListItem",
"position": 3,
"name": "SEO tips voor 2026",
"item": "https://example.com/blog/seo-tips"
}
]
}
]
}
</script>Belangrijk voor dateModified: Voeg altijd dateModified toe als je een artikel update. Dit helpt zoekmachines wijzigingen beter interpreteren en kan bijdragen aan duidelijkere freshness-signalen, wat ook relevant is voor GEO optimalisatie (Generative Engine Optimization).
“Schema markup structureert je content zodat machines én mensen exact vinden wat ze nodig hebben. En wanneer LLM’s jou beter begrijpen, citeren ze je vaker”
ID en URL strategie die bulk-proof is
Een consistente @id strategie is essentieel om je structured data schaalbaar te houden. Dit wordt vooral cruciaal bij sites met honderden product pagina's of blog artikelen.
Strikte pattern voor @id fragmenten:
WebPage:
[CANONICAL_URL]#webpageService:
[CANONICAL_URL]#serviceBlogPosting:
[CANONICAL_URL]#blogpostBreadcrumbList:
[CANONICAL_URL]#breadcrumbsFAQPage:
[CANONICAL_URL]#faqImageObject (primary):
[CANONICAL_URL]#primaryimage
Belangrijke regels:
Gebruik exact je canonical URL. Kopieer de href uit je
<link rel="canonical">tag.Match www/non-www exact. Als canonical
https://www.example.comis, gebruik dat ook in JSON-LD.Match trailing slash exact. Als canonical eindigt op
/, gebruik dat ook in @id.Gebruik lowercase fragments.
#webpageniet#WebPageof#WEBPAGE.Consistent door hele site. Niet op pagina A
#serviceen op pagina B#dienst.
Voorbeeld bulk implementatie:
Als je 200 product pagina's hebt, genereer je de @id's programmatisch met exact dezelfde logica als je canonical URL generatie. Voor Shopify sites: dit kan je automatiseren via je theme's liquid templates.
Veelgemaakte fouten (met fixes)
Quick reference: 10 fouten overzicht
Uitgebreide uitleg per fout
1. Organization schema op elke pagina dupliceren
Wat je ziet: Elke pagina heeft zijn eigen Organization definitie in de page-level JSON-LD.
Waarom het problematisch is: Inconsistenties tussen pagina's kunnen onduidelijke signalen geven.
Fix: Verplaats Organization naar je site-wide script. Laat page-level scripts verwijzen via {"@id": "https://example.com/#organization"}.
2. BlogPosting en Service op dezelfde URL mixen
Wat je ziet: Een pagina heeft zowel @type: "BlogPosting" als @type: "Service".
Waarom het problematisch is: Een pagina kan niet tegelijk een blog artikel en een service zijn. Dit kan tot ambiguïteit leiden.
Fix: Kies één primair type. Is het een artikel dat een service beschrijft? BlogPosting. Is het een landingspagina voor een service? Service + WebPage.
3. WebPage.mainEntityOfPage verwijst naar zichzelf
Wat je ziet:
{
"@type": "WebPage",
"@id": "https://example.com/seo#webpage",
"mainEntityOfPage": {
"@id": "https://example.com/seo#webpage"
}
}Waarom het fout is: mainEntityOfPage is bedoeld om te verwijzen van een entity (Service, BlogPosting) naar de WebPage waar het op staat. Niet andersom.
Fix: Verwijder mainEntityOfPage uit WebPage. Gebruik mainEntityOfPage alleen IN de Service/BlogPosting node om terug te verwijzen naar WebPage.
4. FAQ content die niet op de pagina staat
Wat je ziet: FAQPage schema met vragen die letterlijk niet in de zichtbare HTML staan.
Waarom het fout is: Google's richtlijnen vereisen dat structured data matched met zichtbare content. Dit kan leiden tot manual action.
Fix: Voeg alleen FAQ schema toe als de vragen EN antwoorden daadwerkelijk op de pagina staan. Copy-paste niet FAQ's van een template.
5. Description met claims die je niet kunt staven
Wat je ziet: "description": "Wij zijn het beste SEO bureau van België met 500+ tevreden klanten"
Waarom het problematisch is: Als je geen 500+ klanten hebt, is dit misleading markup.
Fix: Gebruik alleen feiten die je kunt bewijzen. Heb je 50 klanten? Zeg dat. Heb je geen klanten data? Laat het weg of houd het algemeen.
6. URL formats halverwege site wijzigen
Wat je ziet: Homepage gebruikt https://example.com, subpagina's gebruiken https://example.com/, weer andere https://www.example.com.
Waarom het problematisch is: Inconsistente @id's breken de linking tussen entities.
Fix: Kies één canonical URL format en gebruik die overal. Als je canonical tag https://example.com is (zonder trailing slash), gebruik dat ook consequent in JSON-LD.
7. Over-gevulde sameAs met willekeurige bronnen
Wat je ziet: "sameAs": ["https://facebook.com/bedrijf", "https://linkedin.com/company/bedrijf", "https://random-directory.com/bedrijf123", "https://spam-linkfarm.org/bedrijf"]
Waarom het problematisch is: SameAs is bedoeld voor official, authoritative sources. Niet voor elke plek waar je bedrijf vermeld staat.
Fix: Gebruik alleen official social profiles (LinkedIn, Facebook, Twitter, Instagram) en officiële sources zoals Wikipedia (als relevant). Max 3-5 URLs die je daadwerkelijk controleert en onderhoudt.
8. Meerdere JSON-LD scripts zonder reden
Wat je ziet: Vier aparte <script type="application/ld+json"> blokken op één pagina voor WebPage, Service, BreadcrumbList en Organization.
Waarom het problematisch is: Onnodig complex, moeilijk te onderhouden, vergroot kans op duplicatie en inconsistentie.
Fix: Consolideer naar twee scripts: één site-wide (WebSite, Organization, Person) en één page-level (WebPage, Service/BlogPosting, BreadcrumbList, FAQ) met @graph.
9. Broken JSON door syntax fouten
JSON is strict in zijn syntax requirements. Drie veelvoorkomende fouten:
A. Trailing comma's
Wat je ziet:
{
"name": "Test",
"url": "https://example.com",
}Waarom het fout is: JSON staat geen trailing comma na de laatste property toe.
Fix: Verwijder de comma na de laatste property in elk object.
B. Smart quotes (typografische aanhalingstekens)
Wat je ziet:
{
"name": "Test's Service"
}(Let op de typografische apostrof in plaats van rechte quote)
Waarom het fout is: JSON vereist rechte dubbele aanhalingstekens (") voor keys en string values. Typografische quotes (" " ' ') breken parsing.
Fix: Vervang alle typografische quotes met rechte quotes. Check dit vooral als je JSON kopieert uit Word, Google Docs of sommige WYSIWYG editors.
C. Quotes binnen strings escapen
Wat je ziet (invalid):
{
"name": "Test "Premium" Service"
}Waarom het fout is: Quotes binnen een string moeten ge-escaped worden met backslash.
Fix correct voorbeeld:
{
"name": "Test \"Premium\" Service"
}Algemene fix: Gebruik een JSON validator zoals JSONLint voor publicatie om al deze syntax fouten te detecteren.
10. Andere scripts in pagina wijzigen bij JSON-LD edit
Wat je ziet: Developer voegt JSON-LD toe en wijzigt per ongeluk een bestaand Google Analytics script of andere functionaliteit.
Waarom het problematisch is: JSON-LD scripts moeten standalone zijn. Wijzigingen aan andere scripts kunnen tracking, ads, of andere functionaliteit breken.
Fix: Behandel JSON-LD als read-only zone. Voeg toe, maar raak niks anders aan. Test altijd na deployment of andere scripts nog werken.
“Voorheen waren zoekmachines vooral indexen van documenten. Nu wordt Google steeds meer een index van ‘dingen’ en feiten die daarmee verband houden”
Checklist voor publicatie
Voor je JSON-LD live zet:
JSON syntax gevalideerd met JSONLint
Schema types gematched met page intent (Service voor service pagina, BlogPosting voor artikel)
Alle @id verwijzingen gecontroleerd (Organization @id klopt, WebSite @id klopt)
Getest met Google Rich Results Test
Getest met Schema Markup Validator
Geen errors of critical warnings in validators
Content in structured data matched met zichtbare pagina content
URLs exact zoals canonical URLs (match www/non-www en trailing slash)
DateModified toegevoegd indien artikel geüpdatet is
Changelog bijgehouden van welke pagina's welk schema hebben
Batch process: eerst 5 pagina's live, monitor 48u, dan uitrollen naar meer pagina's
Structured data vervangt geen keyword research, maar helpt zoekmachines de pagina-intent sneller begrijpen.
Structured data is geen eenmalige klus, maar een systeem dat je opzet en onderhoudt. Begin met de site-wide entities, voeg daarna page-level markup toe volgens de templates hierboven, valideer grondig, en monitor je Search Console voor errors.
De sites die dit goed doen, hebben één ding gemeen: een duidelijke scheiding tussen wat site-wide hoort en wat page-level hoort, met een consistente @id strategie die schaalt.
Structured data werkt het best in combinatie met technische SEO, conversie optimalisatie en GEO strategieën die ervoor zorgen dat je content vindbaar is in zowel traditionele zoekmachines als AI-systemen. Als je hulp nodig hebt bij het auditen of implementeren van je structured data, kan een website audit inzicht geven in je huidige situatie.
Gerelateerde artikelen:
Voor wie dieper wil graven in de technische kant van SEO:
🚀 Meer leads, hogere conversie, betere ROI
Dit artikel gaf je inzichten. Nu is het tijd voor actie. Of je nu een winstgevende webshop wil bouwen, meer omzet wil halen uit performance marketing of SEO, of wil groeien met AI-marketing - we helpen je concreet vooruit.
💬 Bespreek je uitdaging direct met Frederiek: Plan een gratis strategiegesprek of stuur ons een berichtje
📧 Liever mailen? Stuur je vraag naar frederiek@clickforest.com of bel +32 473 84 66 27
Strategie zonder actie blijft theorie. Laten we je volgende stap samen zetten.
Veelgestelde vragen over JSON-LD
Moet ik BreadcrumbList altijd opnemen?
Wat als ik meerdere auteurs heb?
Is FAQ schema nog zinvol?
Hoeveel Things in about is ideaal?
Kan ik prijzen vermelden in Service structured data?
Wat is het verschil tussen WebPage en Article?
Bronnen en referenties
Officiële Google & Schema.org documentatie:
Google Search Central - Structured data introductie - https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
Google Search Central - General structured data guidelines - https://developers.google.com/search/docs/appearance/structured-data/sd-policies
Schema.org - Getting started met Schema.org - https://schema.org/docs/gs.html
Schema.org - Organization type specificatie - https://schema.org/Organization
Validation Tools:
Google Rich Results Test - https://search.google.com/test/rich-results
Schema Markup Validator - https://validator.schema.org/
JSONLint - https://jsonlint.com
Implementatie-inspiratie:
Yoast Developer Portal - Schema functional specification - https://developer.yoast.com/features/schema/functional-specification/
