JSON-LD implementeren: van betrouwbare bronvelden tot controle

JSON-LD implementeren begint bij de informatie die werkelijk op je pagina staat. Kies daar een passend schematype bij, laat één systeem de gegevens publiceren en controleer zowel de code als de feiten. Hieronder zie je hoe je dat aanpakt, met een fictief voorbeeld en een werkblad voor beheer.

Wat JSON-LD beschrijft en wat het niet belooft

Met gestructureerde gegevens beschrijf je expliciet waar een pagina over gaat. Je maakt bijvoorbeeld duidelijk dat een titel bij een artikel hoort, dat een organisatie de uitgever is en dat een bepaalde URL het artikel identificeert. Daarvoor gebruik je doorgaans de begrippen en eigenschappen van Schema.org.

JSON-LD zet die beschrijving in een afzonderlijk gegevensblok. Microdata en RDFa verbinden gegevens juist via attributen aan HTML-elementen. Alle drie kunnen gestructureerde informatie uitdrukken. Google noemt JSON-LD het aanbevolen formaat, onder meer omdat het doorgaans gemakkelijker te beheren is. Dat betekent niet dat ieder schema of iedere eigenschap een ondersteunde zoekfunctie heeft.

Maak daarom onderscheid tussen beschrijven en verschijnen. Een correcte beschrijving kan een zoekmachine helpen je inhoud te begrijpen. Ze geeft geen automatische rankingverbetering en geen recht op een uitgebreid zoekresultaat. De introductie van Google over gestructureerde gegevens legt deze voorwaarden uit. Plaats deze werkzaamheden binnen je bredere SEO-strategie, zodat je weet welk probleem je ermee probeert op te lossen.

Begin met een diagnose van de bestaande pagina

Pak eerst één representatieve URL. Noteer het doel van de pagina, de zichtbare informatie en de systemen die deze informatie beheren. Een productpagina vraagt om andere gegevens dan een handleiding of een bedrijfspagina. Kijk ook of er al gestructureerde gegevens worden gepubliceerd.

Controleer daarvoor de HTML die de server terugstuurt én de pagina nadat JavaScript is uitgevoerd. Zoek naar JSON-LD-blokken en naar eventueel aanwezige microdata of RDFa. Een SEO-plugin kan al gegevens toevoegen, terwijl het thema of een webshopapp hetzelfde doet. Zonder deze inventarisatie kun je per ongeluk een tweede, afwijkende beschrijving introduceren.

Leg je bevindingen vast: welke typen bestaan al, welke entiteiten beschrijven ze en welke velden spreken elkaar tegen? Vind je daarnaast problemen met bereikbaarheid, indexeerbaarheid of canonieke URL’s, neem die mee in een SEO-audit. Extra markup lost zulke problemen niet zelfstandig op.

Kies een schematype op basis van de zichtbare paginafunctie

Het juiste type volgt uit de inhoud. Begin niet met een lijst aantrekkelijke zoekresultaten waarvoor je vervolgens gegevens probeert te verzamelen. Gebruik deze beslismatrix om vast te stellen welke beschrijving bij je pagina past.

Een winkelnaam maakt een pagina nog geen LocalBusiness-pagina. Gebruik zo’n specifieker type alleen als het bedrijf en de beschreven gegevens daarbij passen. Verzin geen bezoekadres om lokale relevantie te suggereren. Bij producten vraagt vooral het verschil tussen varianten aandacht; binnen e-commerce SEO moet de beschrijving aansluiten op wat iemand op de betreffende product-URL kan kiezen en kopen.

FAQ-inhoud blijft nuttig zonder Google FAQ-richresult

Een FAQ kan twijfels van bezoekers wegnemen en praktische vragen beantwoorden. Dat is op zichzelf een goede reden om vragen en antwoorden te publiceren. Google toont sinds 7 mei 2026 geen FAQ-richresults meer; de bijbehorende featuredocumentatie is op 15 juni 2026 verwijderd, volgens het wijzigingsoverzicht van Google Search.

Beoordeel FAQ-inhoud daarom op bruikbaarheid voor de lezer. Article combineren met FAQ-markup levert geen dubbele kans op zo’n zoekweergave op. Het bestaan van een Schema.org-type en de ondersteuning van een Google-zoekfunctie zijn afzonderlijke zaken.

Gebruik je eigen domein en stabiele identiteiten

Met @id kun je een entiteit binnen je gegevens herkenbaar maken. Een organisatie kan bijvoorbeeld een vaste identiteit op de homepage krijgen, terwijl ieder artikel een eigen identiteit heeft. Andere objecten verwijzen vervolgens naar dezelfde organisatie in plaats van telkens een los exemplaar met afwijkende gegevens te beschrijven.

Gebruik hiervoor URL’s op je eigen publieke domein. Kies consequent voor de juiste domeinvariant en het URL-patroon van de website. Kopieer geen demo-identiteiten, stagingdomeinen of domeinen van een leverancier naar productie. Een fragment zoals #organization dient als identificatie en hoeft geen afzonderlijke webpagina te zijn.

Een verhuizing naar een ander domein vraagt ook om controle van deze verwijzingen. Leg de gekozen identiteiten vast, zodat een nieuwe plugin of template niet ongemerkt een tweede identiteit voor dezelfde organisatie introduceert.

Een volledig fictief JSON-LD-voorbeeld voor een artikel

Onderstaand voorbeeld beschrijft het fictieve bedrijf Werkplaats Wilgenveer en een fictief artikel over houtopslag. Het domein, de bedrijfsnaam, de titel en de datums zijn uitsluitend demonstratiemateriaal. Dit is geen beschrijving van Niblah en geen kant-en-klaar pakket voor iedere Google-zoekfunctie.

Stel dat de voorbeeldpagina de titel, uitgever, publicatiedatum en wijzigingsdatum zichtbaar vermeldt. Dan laat dit geldige JSON zien hoe je Article en Organization met consequente verwijzingen kunt verbinden. Een auteur is bewust niet ingevuld: het voorbeeld veronderstelt geen bekende auteur.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://werkplaats-wilgenveer.example/#organization",
      "name": "Werkplaats Wilgenveer",
      "url": "https://werkplaats-wilgenveer.example/"
    },
    {
      "@type": "Article",
      "@id": "https://werkplaats-wilgenveer.example/kennis/hout-droog-opslaan/#article",
      "url": "https://werkplaats-wilgenveer.example/kennis/hout-droog-opslaan/",
      "mainEntityOfPage": "https://werkplaats-wilgenveer.example/kennis/hout-droog-opslaan/",
      "headline": "Hout droog opslaan in een kleine werkplaats",
      "inLanguage": "nl-NL",
      "datePublished": "2026-09-10",
      "dateModified": "2026-09-18",
      "publisher": {
        "@id": "https://werkplaats-wilgenveer.example/#organization"
      }
    }
  ]
}

Op een echte website wordt JSON-LD doorgaans gepubliceerd in een script-element met het type application/ld+json. Het bovenstaande codeblok is alleen leesbare uitleg en voert niets uit. Laat je CMS-integratie de uiteindelijke gegevens veilig serialiseren en in de HTML plaatsen. Plak niet blind de HTML-entiteiten uit een zichtbaar codevoorbeeld in een actief gegevensblok.

Een eigen Product-voorbeeld met een afzonderlijk aanbod

Een Product beschrijft wat wordt aangeboden; een Offer beschrijft het betreffende aanbod. Onderstaand zelfstandig voorbeeld hoort bij een fictieve Houtklem 120 van Werkplaats Wilgenveer. Veronderstel dat de pagina precies deze variant toont, met een prijs van €42, valuta EUR en de zichtbare melding dat de klem op voorraad is. De voorbeeldwaarden beschrijven geen Niblah-product.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://werkplaats-wilgenveer.example/winkel/houtklem-120/#product",
  "name": "Houtklem 120",
  "url": "https://werkplaats-wilgenveer.example/winkel/houtklem-120/",
  "sku": "WV-K120",
  "offers": {
    "@type": "Offer",
    "url": "https://werkplaats-wilgenveer.example/winkel/houtklem-120/",
    "priceCurrency": "EUR",
    "price": "42.00",
    "availability": "https://schema.org/InStock"
  }
}

De prijswaarde 42.00 gebruikt de schrijfwijze voor het gegevensveld; de bezoeker mag op de pagina €42 zien. De productidentiteit en SKU horen bij dezelfde variant. Gebruik InStock alleen wanneer de actuele beschikbaarheid dat ondersteunt. Een opgeslagen demonstratieprijs mag geen vaste waarde worden naast een veranderende winkelprijs.

Vergelijk je veldkeuzes met de officiële beschrijvingen van Product en Offer. Dit voorbeeld laat de relatie en de syntaxis zien. Het is geen volledig recept voor iedere Google-productweergave. Lees voor dat afzonderlijke doel de Google-voorwaarden voor product snippets en controleer alle relevante vereiste gegevens en het beleid.

Voeg geen beoordelingen, kortingsperiode of voorraad toe om een test uitgebreider te laten lijken. Controleer bij echte implementatie minstens twee varianten, een prijswijziging en een uitverkochte situatie. Inspecteer telkens zowel de zichtbare productpagina als alle gepubliceerde aanbodobjecten. Zo toets je of de generator echte winkelgegevens volgt.

Vul het contentveldenwerkblad in vóór de bouw

Gebruik dit werkblad om elk veld aan een bron en een eigenaar te koppelen. De waarden hieronder horen bij dezelfde fictieve situatie. Vervang ze door gecontroleerde gegevens van jouw website. Een veld zonder betrouwbare bron blijft leeg totdat je het hebt uitgezocht; controleer daarna of het gekozen doel met de beschikbare velden haalbaar is.

Voeg voor je eigen project ook toe waar het veld technisch wordt opgeslagen. Denk aan een CMS-titelveld, een productvariant of een centrale bedrijfsinstelling. Zo voorkom je dat een redacteur zichtbare tekst bijwerkt terwijl een ontwikkelaar maanden later nog een vaste oude waarde publiceert.

Wijs in WordPress één eigenaar per gegevensbron aan

In WordPress kan een plugin, het thema of een eigen template de markup verzorgen. Inventariseer eerst wat de bestaande combinatie al produceert. Als een plugin de benodigde informatie correct afleidt uit betrouwbare CMS-velden, kan uitbreiding daarvan logischer zijn dan een extra los codeblok. Bij bijzondere inhoud kan een eigen integratie nodig zijn.

Eén eigenaar betekent niet dat er op de hele website maar één JSON-LD-blok mag bestaan. Meerdere blokken kunnen samen een consistente beschrijving vormen. Het probleem ontstaat wanneer systemen dezelfde entiteit tegenstrijdig beschrijven: de plugin noemt een andere uitgever dan het thema, of twee Product-objecten geven verschillende prijzen voor hetzelfde aanbod.

Leg daarom vast welk systeem welk object en welke velden beheert. Pas alleen die generator aan en schakel overlappende output gericht uit wanneer dat nodig is. Dezelfde afweging geldt bij Shopify, waar thema’s en apps beide gegevens kunnen toevoegen. Controleer bij wijzigingen in de technische inrichting ook de samenhang met je technische SEO.

Houd auteur, datum en implementatieversie controleerbaar

Laat een auteursveld verwijzen naar de werkelijke auteur die bij de inhoud hoort. Een beheerdersaccount is niet automatisch de schrijver. Gebruik ook niet zonder controle de naam van degene die een oude tekst heeft geïmporteerd.

Behoud de oorspronkelijke publicatiedatum bij herpublicatie wanneer het om hetzelfde artikel gaat. Werk de wijzigingsdatum bij op basis van een echte inhoudelijke wijziging en laat de zichtbare vermelding daarmee overeenkomen. Een template-update of iedere nieuwe paginaverversing hoort niet automatisch een nieuwe inhoudelijke datum te veroorzaken.

Bewaar daarnaast de versie van de implementatie in je wijzigingsregistratie: welke plugin-, thema- of templateversie is getest en met welke instellingen? Dat is beheerinformatie, geen reden om een verzonnen versieveld aan het artikel toe te voegen. Zo kun je na een update gericht achterhalen waar afwijkende output vandaan komt.

Implementeer van bronveld naar publieke uitvoer

1. Leg de veldkoppelingen vast. Bepaal voor iedere eigenschap welk CMS-veld de waarde levert en wat er gebeurt als dat veld ontbreekt.
2. Bouw eerst voor één paginatype. Gebruik een representatieve testpagina en voorkom dat artikelmarkup onbedoeld op categorieën of productpagina’s verschijnt.
3. Gebruik een JSON-serializer. Laat software aanhalingstekens en bijzondere tekens verwerken. Handmatig strings aan elkaar plakken maakt titels met leestekens foutgevoelig.
4. Verwerk ontbrekende gegevens bewust. Laat onnodige lege eigenschappen weg. Ontbreekt een vereist veld voor je beoogde zoekfunctie, los dan de bron op of heroverweeg die functie.
5. Controleer de integratie in HTML. Geldige JSON moet ook veilig in het uiteindelijke script-element terechtkomen. Gebruik daarvoor de passende CMS-functies of een betrouwbare integratie.
6. Publiceer en controleer opnieuw. Test de openbare URL, inclusief eventuele cachelagen en uitvoer die pas na JavaScript verschijnt.

Controleer JSON-LD op vijf afzonderlijke niveaus

De melding dat iets valid is, krijgt pas betekenis als duidelijk is wat er is getest. Houd de onderstaande controles apart. Daarmee voorkom je dat een technisch geslaagd resultaat een inhoudelijke fout verbergt.

1. Controleer of de JSON syntactisch geldig is

Een parser moet het volledige gegevensblok kunnen lezen. Controleer onder meer dubbele aanhalingstekens, komma’s, accolades en gegevensstructuren. JSON ondersteunt geen gewone codecommentaren of losse komma achter het laatste veld. Deze test beoordeelt alleen de schrijfwijze; een verzonnen prijs kan probleemloos geldige JSON zijn.

2. Controleer typen en eigenschappen binnen Schema.org

Gebruik de Schema Markup Validator om te onderzoeken welke entiteiten en eigenschappen worden herkend. Controleer of waarden het bedoelde gegevenstype hebben en of verwijzingen logisch samenhangen. Een Schema.org-controle en een beoordeling voor een specifieke Google-zoekfunctie beantwoorden verschillende vragen.

3. Controleer de voorwaarden van de bedoelde Google-functie

Gebruik de Rich Results Test voor door Google ondersteunde richresulttypen. Bekijk welke objecten het hulpmiddel herkent en welke vereiste of aanbevolen gegevens ontbreken. Niet ieder geldig Schema.org-type valt binnen de reikwijdte van deze test.

Een fout kan een object ongeschikt maken voor een betreffende zoekfunctie. Een waarschuwing kan wijzen op een aanbevolen verbetering en is niet automatisch een blokkade. Lees daarom de concrete melding. Een geslaagde test garandeert nooit weergave: Google bepaalt uiteindelijk of en hoe het resultaat wordt getoond.

4. Vergelijk ieder belangrijk veld met de zichtbare feiten

Open de pagina alsof je een bezoeker bent. Kloppen titel, auteur, datum en bedrijfsidentiteit? Bij een product controleer je bovendien de geselecteerde variant, valuta, prijs en beschikbaarheid. Een waarde die alleen intern bekend is, vormt niet vanzelf een juiste beschrijving van wat deze pagina aanbiedt.

Controleer ook de redactionele kwaliteit van de pagina zelf. Markup maakt een onduidelijke handleiding niet bruikbaarder. Koppel het beheer daarom aan je proces voor SEO-content, zodat zichtbare uitleg en gestructureerde gegevens samen worden aangepast.

5. Inspecteer de publieke HTML en het opgebouwde DOM

Vergelijk de serverrespons met het DOM: de documentstructuur die de browser na verwerking en uitvoering van JavaScript heeft opgebouwd. Een test van een los codefragment bewijst nog niet dat hetzelfde fragment publiek verschijnt. Een cache kan oude gegevens serveren, terwijl een app later een tweede object toevoegt.

Test de openbare URL zonder ingelogde beheerderssessie. Controleer welke blokken daadwerkelijk worden geparseerd en of identiteiten naar de juiste publieke URL’s verwijzen. Bewaar de geteste URL, datum, bevindingen en relevante uitvoer. Daarmee kan iemand anders je controle reproduceren.

Foutanalyse: een juiste prijs in het verkeerde gegevensblok

Stel dat een fictieve webshop zichtbaar een product voor €42 aanbiedt. De winkelapp publiceert ook €42, maar het thema bevat nog een vaste oude prijs van €49. Beide blokken zijn geldige JSON. Alleen de syntaxis controleren laat het probleem dus ongemerkt bestaan.

De diagnose is hier een conflict tussen twee producenten van productgegevens. Bepaal eerst welk systeem de actuele variant en prijs betrouwbaar uitleest. Laat vervolgens dat systeem de betreffende aanbodvelden beheren en verwijder of corrigeer de overlappende uitvoer. Cache legen komt daarna; zonder broncorrectie keert de fout terug.

Verifieer ten slotte de zichtbare prijs én alle gevonden aanbodobjecten op de openbare URL. Controleer ook een tweede variant als die bestaat. Dit voorbeeld illustreert een controleproces en bevat geen voorspelling over verkeer, omzet of zoekweergave.

Structured data bij ChatGPT en andere AI-zoekvragen

Gestructureerde gegevens maken expliciet welk artikel, bedrijf of product je beschrijft. Dat is geen bewijs dat ChatGPT of een andere AI-dienst jouw pagina kiest of citeert. De benodigde informatie, toegang en verwerking verschillen per product. Controleer de actuele documentatie van het systeem dat je wilt onderzoeken.

Voor Googles AI Overviews en AI Mode gelden volgens de Google-documentatie over AI-functies geen extra structured-data-eisen of speciaal AI-schema. Een bruikbare, geïndexeerde pagina die een snippet mag tonen, kan in aanmerking komen; verschijning is niet gegarandeerd. Die Google-uitleg bewijst niet hoe alle andere AI-engines informatie verwerken.

Beoordeel je markup daarom eerst op de echte feiten en het concrete ondersteunde gebruiksdoel. Houd een waargenomen vermelding apart van de technische implementatie. Eén citaat na een wijziging toont geen oorzakelijk verband of vast selectiepercentage.

Maak onderhoud onderdeel van publiceren

Koppel controles aan wijzigingen die werkelijk risico geven: een nieuwe productprijs, andere beschikbaarheid, herpublicatie, een domeinmigratie of een update van de generator. Test na een templatewijziging meerdere representatieve pagina’s, waaronder een pagina met ontbrekende optionele velden.

Laat je specialist in de SEO-rapportage onderscheid maken tussen geïmplementeerde markup, geconstateerde fouten en daadwerkelijk waargenomen zoekweergaven. Vraag bij oplevering om het ingevulde werkblad, de gekozen generator, testbevindingen en bekende beperkingen. Alleen een screenshot met een groene melding is onvoldoende om het beheer over te nemen.

Veelgestelde vragen over JSON-LD implementeren

Kan ik JSON-LD zelf toevoegen in WordPress?

Ja, als je kunt vaststellen welke gegevens je huidige plugin of thema al publiceert en welke bronvelden nodig zijn. Begin met één pagina en controleer de openbare uitvoer. Laat maatwerk uitvoeren wanneer meerdere systemen elkaar tegenspreken of de veldkoppelingen onduidelijk zijn.

Zijn meerdere JSON-LD-blokken op één pagina verkeerd?

Nee. Meerdere blokken kunnen samen kloppende informatie beschrijven. Controleer wel of dezelfde entiteit consequent wordt geïdentificeerd en of gedeelde velden elkaar niet tegenspreken. Twee verschillende prijzen voor hetzelfde aanbod vragen om onderzoek.

Moet ik iedere waarschuwing in een test oplossen?

Beoordeel eerst wat de melding betekent voor het betreffende object en je doel. Een waarschuwing over aanbevolen informatie is niet hetzelfde als een fout in een vereist veld. Voeg ontbrekende gegevens alleen toe als ze waarheidsgetrouw en passend zijn.

Waarom verschijnt er geen richresult na een geslaagde test?

Een geslaagde test bevestigt alleen de onderdelen die het hulpmiddel heeft gecontroleerd. Weergave hangt ook af van onder meer ondersteuning, beleid, verwerking en Googles keuze voor een zoekopdracht. Controleer de publieke pagina en relevante voorwaarden; geldige markup geeft geen weergavegarantie.

Heeft FAQ-markup nog zin voor Google-richresults?

Google toont sinds 7 mei 2026 geen FAQ-richresults meer. Schrijf vragen en antwoorden wanneer ze bezoekers helpen. Kies eventuele FAQ-markup op basis van een concreet ander gebruiksdoel, niet op basis van een verwachte FAQ-uitbreiding in Google.

Laat één pagina en het beoogde schematype beoordelen

Wil je weten of jouw implementatie klopt of wat een specialist precies moet aanpassen? Stuur via het Niblah-contactformulier één openbare pagina-URL en het schematype dat je gebruikt of overweegt, bijvoorbeeld Article of Product. Vermeld ook of je website op WordPress of Shopify draait en voeg een eventuele testmelding toe. Daarmee maak je je vraag concreet: welke bronvelden, generator en controles zijn voor deze pagina nodig?