Zo markeer je je website met JSON-LD volgens Schema.org

JSON-LD uitgelegd
JSON-LD volgens Schema.org: stap voor stap

12 maanden slechts

€ 1

daarna € 6 / mnd.
Setupkosten: € 0

Alle prijzen incl. btw

Hoog op de Google SERP met gestructureerde data op basis van JSON-LD

Gestructureerde data helpen zoekmachines om websites beter te begrijpen. Een semantische annotatie maakt het mogelijk om een betekenissamenhang te markeren, informatie automatisch uit te lezen en op een andere manier weer te geven. Google – de meestgebruikte zoekmachine van dit moment – baseert zich op gestructureerde data om aan gebruikers rich search results en andere SERP-elementen beschikbaar te stellen. Naast het ontwikkelen van een goed werkende website met een aantrekkelijk design, is gestructureerde data dus ook erg belangrijk voor websitebeheerders. Het voordeel: zulke hooggeplaatste zoekresultaten springen in het oog en vergroten de zichtbaarheid van de website.

Voorwaarde daarvoor is dat alle relevante informatie op de juiste wijze wordt gemarkeerd. In de loop der tijd zijn er verschillende standaards ontwikkeld voor het structureren van data. Wij laten zien wat de voordelen zijn van JSON-LD boven alternatieve dataformaten, zoals microformats, RDFa of microdata.

Nog op zoek naar voordelige hosting voor je website?

Hosting aanbiedingen ontdekken

Wat is JSON-LD?

JSON-LD is een methode die is gebaseerd op JSON en waarmee gestructureerde data in een website kunnen worden geïntegreerd. In tegenstelling tot andere datastructureringsformaten, zoals microformats, RDFa en microdata, gebeurt dit markeren niet als brontekstannotatie, maar worden metadata in een scripttag afzonderlijk van de inhoud van de website geïmplementeerd in het head- of body-element van het HTML-document. Daarbij maakt JSON-LD gebruik van de JSON-notatie, uitgebreid met een syntaxis waarmee de data volgens algemeen geldende, wereldwijd gelijke schema’s kunnen worden gemarkeerd.

De JSON-LD-specificatie is afkomstig van de oprichter van Digital Bazaar Manu Sporny en is sinds 16 januari 2014 een officiële W3C-aanbeveling.

Definitie: JSON-LD is een door het W3C aanbevolen syntaxis waarmee gestructureerde data en algemene schema’s voor datastructurering kunnen worden omgezet in het compacte JSON-formaat

JSON uitgelegd

De afkorting JSON staat voor JavaScript Object Notation en houdt een compact, tekstgebaseerd formaat voor het uitwisselen van data in dat zowel door mensen als door machines eenvoudig kan worden verwerkt. JSON is afgeleid van JavaScript, maar kan ook onafhankelijk van die programmeertaal op verschillende platforms worden gebruikt. Als dataformaat voor de serialisatie – het afbeelden van programmeerbare objecten in een sequentiële weergave – wordt JSON gebruikt voor het overdragen en opslaan van gestructureerde data bij webapplicaties en mobiele apps. De syntaxis van een JSON-object bestaat hoofdzakelijk uit naam-waardeparen (name-value pairs) die (met uitzondering van getalwaarden) tussen dubbele hoge aanhalingstekens worden genoteerd en worden gescheiden door een dubbele punt. Elk naam-waardepaar begint gewoonlijk in een nieuwe regel en eindigt met een komma. Uitzondering: het laatste naam-waardepaar voor de afsluitende accolade wordt genoteerd zonder komma.

Voorbeeld van het basisschema van de JSON-syntaxis:

{
        "name": "Manu Sporny",
        "homepage": "https://manu.sporny.org/about/"
}

In het inleidende tekstsegment staat het woordpaar “Manu Sporny”. Een menselijke lezer zal op basis van de context snel begrijpen dat deze lettersequens een naam is en dat de hyperlink die erachter staat verwijst naar de website van de JSON-LD-ontwikkelaar. Programma’s zoals webbrowsers of zoekmachinecrawlers hebben echter metadata nodig om zo’n context te kunnen begrijpen. En dat is precies wat JSON biedt.

Het codevoorbeeld hierboven toont de beide naamelementen “name” en “homepage” met hun respectievelijke waarden. Een programma dat een website met dit JSON-object uitleest, kan daardoor “Manu Sporny” als naam en “https://manu.sporny.org/about/” als homepage identificeren.

Linked data (LD)

Hoewel de betekenisindeling met JSON binnen een website probleemloos werkt, leidt de analyse van JSON-data van verschillende websites al snel tot een ambiguïteitsprobleem. Normaal gesproken parsen programma’s een groot aantal websites en evalueren de ingewonnen informatie in databases. Bij de hierboven afgebeelde JSON-code kan er bijvoorbeeld niet zonder twijfel vanuit worden gegaan dat de naamelementen “name” en “homepage” op verschillende websites zondermeer in dezelfde context worden gebruikt. Om dubbelzinnigheid uit te sluiten, vult JSON-LD de klassieke JSON-notatie daarom aan met elementen die de context aanduiden. Dit gebeurt op basis van linked data: vrij beschikbare data op internet die kunnen worden opgeroepen met uniformed resource identifiers (URI’s).

Om JSON geschikt te maken voor linked data, vult JSON-LD de klassieke naam-waardeparen van de JSON-notatie aan met zogenaamde keywords (sleutelwoorden). Keywords beginnen in de syntaxis van JSON-LD met een @. De keywords @context en @type zijn zeer belangrijk: @context definieert de markering van het fundamentele vocabulaire en @type geeft aan om welk datatype (schema) het gaat.

Het project Schema.org biedt een gestandaardiseerde schemadatabase voor datastructurering. Op de gelijknamige projectwebsite zijn verschillende dataschema’s (types) te vinden en ‘properties’ (eigenschappen) die aan deze datatypes zijn toegewezen en waarmee websites gedetailleerd semantisch kunnen worden gemarkeerd.

Tip: JSON-LD heeft geen specifiek vocabulaire. Het project Schema.org, dat door de zoekmachineproviders Bing, Google en Yahoo! in het leven is geroepen, wordt echter beschouwd als de standaard voor de semantische annotatie van websitecontent.

Aangevuld met de contextelementen ziet de eerdergenoemde voorbeeldcode er als volgt uit:

{
       "@context": "https://schema.org/",
       "@type": "Person",
       "name": "Manu Sporny",
       "url": "https://manu.sporny.org/about/"
}

Het keyword @context in regel 2 definieert het vocabulaire dat ten grondslag ligt aan de code – in dit geval Schema.org. In regel 3 wordt het datatype ‘Person’ met behulp van het keyword @type geïntroduceerd. Dit datatype wordt in de regels 4 en 5 nader gespecificeerd met de eigenschappen “name” en “url”. Een programma dat deze voorbeeldcode parset, kan het als ´name´ gemarkeerde tekstelement ´Manu Sporny´ zodoende identificeren als naam van een persoon dankzij het datatype ´Person´ volgens Schema.org. De naam-waardeparen die door ´name´ en ´url´ zijn ingeleid, worden verwerkt als eigenschappen (properties) van het schema ´Person´. Het vocabulaire dat eraan ten grondslag ligt, bepaalt welke eigenschappen kunnen worden toegewezen aan een schema.

Voordelen van JSON-LD in vergelijking met andere dataformaten

De indeling van schema’s en eigenschappen gebeurt bij JSON-LD op dezelfde manier als bij andere formaten voor de semantische markering van websitecontent. Omgezet in een brontekstannotatie kan het bovengenoemde voorbeeldscript zonder verlies van informatie ook worden gemarkeerd met microdata of RDFa volgens Schema.org.

Microdata-syntaxis volgens Schema.org:

<div itemscope itemtype="https://schema.org/Person">
        <span itemprop="name">Manu Sporny</span>
        <span itemprop="url">https://manu.sporny.org/about/</span>
</div>

RDFa-syntaxis volgens Schema.org:

<div vocab="https://schema.org/" typeof="Person">
        <span property="name">Manu Sporny</span>
        <span property="url">https://manu.sporny.org/about/</span>
</div>

Het grote voordeel van JSON-LD ten opzichte van concurrerende formaten is echter dat metadata niet direct in de HTML-code hoeven te worden geïntegreerd, maar afzonderlijk op een plaats naar keuze kunnen worden geïmplementeerd. Implementatie van JSON-LD in de HTML-code gebeurt met behulp van de scripttag volgens het volgende schema:

<script type="application/ld+json">
        {
        JSON-LD
        }
</script>

Het bovengenoemde voorbeeld wordt volgens Schema.org als volgt gemarkeerd:

<script type="application/ld+json">
        {
        "@context": "https://schema.org/",
        "@type": "Person",
        "name": "Manu Sporny",
        "url": "https://manu.sporny.org/about/"
        }
</script>

Opmerking: Ook als JSON wordt genoteerd in scripttags is er geen sprake van een uitvoerbare code.

De strikte scheiding van HTML en semantische annotatie zorgt niet alleen voor een veel beter leesbare brontekst, maar zo’n implementatie zorgt er ook voor dat de datastructuren onafhankelijk van de zichtbare content dynamisch gegenereerd kunnen worden. Dat betekent dat het met JSON-LD mogelijk is om metadata via het backend in te voeren, uit een database uit te lezen en automatisch te genereren met behulp van een template. Hierdoor is een eenvoudige semantische annotatie mogelijk, ook voor dynamische webcontent die op internet steeds meer ruimte inneemt.

JSON-LD bij zoekmachineoptimalisatie

JSON-LD wordt al sinds juni 2013 door het project Schema.org genoemd als een van de voorkeurs-dataformaten. En ook Google beveelt (zo mogelijk) de scriptgebaseerde insluiting van metadata via JSON-LD aan. Zo’n markering is de basis voor verschillende SERP-elementen die Google inzet om gebruikers uitgebreide zoekresultaten te tonen.

Google gebruikt verschillende weergaven voor zoekresultaten: naast de basic results (eenvoudige zoekresultaten) krijgen gebruikers sinds enkele jaren afhankelijk van de zoekopdracht ook featured results en knowledge graph results te zien. Terwijl basic results (als ze al aanwezig zijn) slechts eenvoudige extensies tonen, zoals breadcrumbs, bieden featured results en knowledge graph results de mogelijkheid voor uitgebreide extensies (door Google ook enhancements of search result features genoemd).

Opmerking: In de Google-terminologie wordt het begrip ‘featured result’ gebruikt voor uitgebreide zoekresultaten, waarbij de afgebeelde content afkomstig is van één enkele bron – de gelinkte website. Andere benamingen van dit soort SERP-elementen zijn rich search result en rich cards. Wanneer een featured result gebruikersinteractie mogelijk maakt, spreekt Google van een enriched search result. Bij knowledge graph results baseert Google zich daarentegen niet op een enkele website, maar op het knowledge graph algoritme dat content van verschillende bronnen op internet verzamelt. Knowledge graph results worden ook wel knowledge graph cards, knowledge graph boxes of knowledge graph displays genoemd. Wanneer Google voor een zoekopdracht meerdere rich cards of knowledge graph cards vindt, worden die als carrousel – een lijstformaat voor verschillende datatypes – op de SERP’s getoond.

Ondersteunde search result features

Op dit moment ondersteunt Google een JSON-LD-mark-up voor de volgende extensies. In de search gallery op developers.google.com biedt de zoekmachineprovider een voorbeeld voor elke search result feature aan.

Breadcrumbs: zogenaamde broodkruimelnavigatie toont de positie van de actuele webpagina in de hiërarchie van de website. Door breadcrumbs semantisch te markeren, zorgen websitebeheerders ervoor dat Google ze op de SERP’s kan tonen. Broodkruimelnavigatie is een van de weinige search result features die ook invloed heeft op basic results bij Google.
Bedrijfscontactinformatie: wanneer bedrijfscontactinformatie semantisch wordt gemarkeerd, kan Google die als knowledge graph display, een weergave van het knowledge graph algoritme, in de SERP’s tonen.
Logo’s: met een logomark-up kunnen websitebeheerders verduidelijken welke afbeelding door de zoekmachine moet worden gebruikt als bedrijfslogo. Zo kan Google zoekresultaten uitbreiden met een logo van het betreffende bedrijf.
Sitelinks search box: wanneer een website een zoekfunctie heeft en deze semantisch wordt gemarkeerd, toont Google zoekresultaten voor de website onder bepaalde voorwaarden met een sitelinks search box.
Social profile links: als een mark-up voor links naar social media-profielen wordt gebruikt, breidt Google de knowledge graph display uit met personen of organisaties, soms met de overeenkomstige buttons. Google ondersteunt momenteel een JSON-LD-mark-up voor Facebook, Twitter, Google+, Instagram, YouTube, LinkedIn, Myspace, Pinterest, SoundCloud en Tumblr.

Datatypes

Websitebeheerders die hun content goed zichtbaar op de Google-SERP’s willen plaatsen, kunnen verschillende datatypes semantisch markeren. Het is daarbij belangrijk om te weten dat alleen Google beslist of een zoekresultaat als basic result of met extensies wordt getoond. Op dit moment ondersteunt Google een JSON-LD-mark-up voor de volgende datatypes en gebruikt die om informatie te verwerken als rich search results, enriched search results of knowledge graph results.

Artikelen: websitebeheerders die nieuwsartikelen of blogs semantisch markeren, geven Google de mogelijkheid om ze in de ‘Top Stories-carrousel’ op te nemen of op de SERP’s door ze met search result features, zoals titels of miniatuurafbeeldingen, aan te vullen.
Boeken: als websitebeheerders een JSON-LD-mark-up voor informatie over boeken aanbieden, maakt Google bij relevante zoekopdrachten een knowledge graph card. Die bevat niet alleen informatie over het boek, maar gebruikers van Google kunnen desgewenst het boek ook direct vanuit de zoekmachine aanschaffen.
Muziek (vermeldingen voor muzikanten en albums): net als informatie over boeken kan ook muziek worden geannoteerd. Daardoor kan Google knowledge graph cards voor muziekcontent maken waarmee gebruikers niet alleen informatie over albums en muzikanten krijgen, maar ook de muziek kunnen afspelen en kopen.
Cursusaanbod: websitebeheerders die cursussen (bijv. taalcursussen) van een JSON-LD-mark-up voorzien waardoor de naam, een korte beschrijving en de aanbieder automatisch worden getoond, kunnen deze informatie ook door Google als uitgebreid zoekresultaat in de SERP’s laten tonen.
Evenementen: aanbieders van openbare evenementen, zoals concerten en festivals, kunnen relevante informatie (bijv. plaats, datum en tijd) via JSON-LD annoteren, zodat Google deze informatie automatisch kan verzamelen en tonen in de lijst op de SERP’s of in andere Google-producten, zoals Maps.
Vacatures: ook vacatures die organisaties op hun website plaatsen, kunnen zo worden gemarkeerd dat Google relevante informatie kan uitlezen voor uitgebreide zoekresultaten.
Vermeldingen van lokale aanbieders: wanneer lokale aanbieders gestructureerde data over hun bedrijf of restaurant aanbieden op hun website, dan kan Google knowledge graph cards maken die bij relevante zoekopdrachten op de SERP’s of in Google Maps worden getoond. Als een gebruiker van Google bijvoorbeeld zoekt naar een Vietnamees restaurant, toont Google een carrousel met overeenkomstige aanbieders in de omgeving.
Gegevensbestanden: ook gegevensbestanden, zoals CSV-tabellen of gegevens in propriëtaire formaten kunnen via een JSON-LD-mark-up toegankelijk worden gemaakt voor de zoekmachine.
Podcasts: Google ondersteunt een JSON-LD-mark-up voor podcastinformatie. Aanbod dat op die wijze is gemarkeerd kan direct in de zoekmachine worden getoond en afgespeeld.
Video’s: aanbieders die op hun website gestructureerde data voor video’s zoals een beschrijving, een link naar een miniatuurafbeelding, de uploaddatum of de afspeelduur beschikbaar stellen, geven Google de mogelijkheid om deze informatie te verzamelen en als rich cards of in de vorm van carrousels op de SERP’s te tonen.
Films en shows: wanneer een website gestructureerde data over films of shows levert, neemt Google die informatie bij relevante zoekopdrachten over als knowledge graph cards op de zoekresultatenpagina’s. Desgewenst kunnen ze worden uitgebreid met interactieve elementen waarmee de consument het aanbod kan kopen.
Recepten: ook recepten biedt Google sinds enkele jaren aan als featured result in de zoekmachine. Voorwaarde is wel dat de aanbieder van de content alle relevante informatie over het recept beschikbaar stelt als gestructureerde data. Op de SERP’s kan het worden weergegeven in een carrousel met passende rich cards.
Reviews: Google ondersteunt reviews voor verschillende Schema.org-datatypes zoals lokale bedrijven, restaurants, producten, boeken, films of creatieve producten. De weergave van dergelijke content gebeurt als snippet. Daarbij maakt Google onderscheid tussen reviews van individuele auteurs en bijdrages op online ratingsites. Als er een semantische annotatie is, worden beide soorten reviews bij relevante zoekopdrachten op de SERP’s getoond als featured results.
Producten: online handelaars die op hun website productinformatie zoals prijzen, beschikbaarheid of reviews aanbieden als gestructureerde data, geven Google de mogelijkheid om deze informatie bij relevante zoekopdrachten te tonen als rich search results.

Voor- en nadelen

Uitgebreide zoekresultaten – ongeacht of het featured results of knowledge graph displays zijn – bieden websitebeheerders een groot voordeel: ze worden boven andere zoekresultaten op de SERP’s getoond.

Google plaatst displays en carrousels voor featured results opvallend boven de basic results en dus op positie nul. Knowledge graph displays verschijnen ook als carrousel aan de bovenrand of in een kader rechts naast de organische zoekresultaten. Uitgebreide zoekresultaten bieden websitebeheerders dus de kans om de polepositie in de zoekresultaten te bereiken, zonder tijd of geld te hoeven investeren in het verbeteren van de organische ranking.

Maar niet alleen de opvallende positie, ook verschillende uitbreidingen zoals miniatuurafbeeldingen, ratings, tekstfragmenten en interactieve elementen trekken de aandacht van de gebruikers en moedigen ze aan om te klikken. Websitebeheerders kunnen ervan uitgaan dat de click-through-rate bij uitgebreide zoekresultaten in vergelijking met basic results beduidend hoger is.

Bovendien wordt gezegd dat uitgebreide zoekresultaten een positief effect hebben op de bounce rate. In tegenstelling tot basic results, die doorgaans slechts de metatitel, een URL en een korte beschrijving bevatten, geven uitgebreide zoekresultaten gebruikers van Google een volledig beeld van welke content zij op de verlinkte website kunnen verwachten. Iemand die zoekt, kan de relevantie van een website voor de eigen zoekopdracht daardoor al vóór het bezoeken van de website nagaan en hoeft alleen te klikken als dat zinvol lijkt. De aanwezigheid of het ontbreken van een semantische markering via JSON-LD is voor de rankingfactor van Google echter geen criterium.

Behalve het gebruik van JSON-LD is ook de crawlbaarheid door het verplaatsen van de mark-ups in afzonderlijke scriptfragmenten een groot pluspunt. In vergelijking met alternatieve annotaties, zoals microdata of RDFa, heeft JSON-LD ondanks de semantische annotatie een slanke broncode die snel doorzocht en eenvoudig geïndexeerd kan worden door de Googlebot en andere crawlers.

Toch heeft het verplaatsen van gestructureerde data ook nadelen. In principe geldt bij Google en andere zoekmachineproviders de stelregel dat alleen de content die ook menselijke bezoekers van de website tot hun beschikking hebben, machineleesbaar gemarkeerd wordt. Met JSON-LD kan echter in theorie elke mark-up worden geïmplementeerd, zelfs als het niet overeenkomt met de aangeleverde metadata in de feitelijke websitecontent. In dat geval wordt zowel de zoekmachine als de gebruiker een mogelijke meerwaarde beloofd die zo’n opgesmukte website niet biedt. Het is voor websitebeheerders onverstandig om zo’n methode te hanteren, omdat ze dan de kans lopen om wegens webspammaatregelen gestraft te worden.

Regels

Om te voorkomen dat websitebezoekers met opzet de grenzen van de zoekmachineconforme semantische annotatie overschrijden, heeft Google een uitgebreid reglement, de structured data general guidelines , waarin de volgende zaken worden voorgeschreven:

Formaat: gestructureerde data moeten beschikbaar zijn in een van de drie vastgestelde formaten: microdata, RDFa of JSON-LD. Google beveelt de laatste aan.
Toegankelijkheid: websites met gestructureerde data moeten toegankelijk zijn voor de Googlebot. Access control methodes (bijv. via robots.txt of noindex) verhinderen het uitlezen van de metadata.
Contentequivalentie: de JSON-LD-mark-up mag alleen entiteiten beschrijven die ook in de HTML-code worden beschreven.
Relevantie: een JSON-LD-mark-up mag alleen betrekking hebben op relevante overeenkomsten van de gebruikte datatypes. Een websitebeheerder die een technische handleiding markeert als recept gaat bijvoorbeeld in tegen de richtlijnen van de relevantie.
Volledigheid: alle in de JSON-LD-mark-up opgevoerde datatypes (types) moeten volledig en inclusief de verplichte eigenschappen (properties) worden gemarkeerd. Datatypes waarbij essentiële eigenschappen ontbreken, zijn niet geschikt voor uitgebreide zoekresultaten.
Specificiteit: linked dataprojecten zoals Schema.org bieden een groot aantal datatypes. Om de eigen content voor een uitgebreide zoekresultatenweergave te kwalificeren, moeten websitebeheerders schema’s zo nauwkeurig mogelijk uitkiezen.

Tip: In principe geldt: hoe meer eigenschappen in de vorm van gestructureerde data beschikbaar worden gesteld, des te groter is de meerwaarde voor de gebruikers van Google. Google houdt daarom bij de ranking van rich cards rekening met de omvang van de beschikbaar gestelde informatie. En ook websitebeheerders profiteren van een zo volledig mogelijke mark-up. Gebruikers geven volgens Google bijvoorbeeld de voorkeur aan vacatures met vermelding van salaris of reviews met sterren.

JSON-LD volgens Schema.org: een stap-voor-staphandleiding

Hieronder laten wij aan de hand van een voorbeeld zien hoe je je website zo efficiënt mogelijk kan verbeteren met relevante metadata. De basis van deze JSON-LD-tutorial is het vocabulaire van het Schema.org-project.

Stap 1: overwegingen vooraf

De hoeveelheid werk die de implementatie van gestructureerde data met zich meebrengt, is afhankelijk van de omvang van de website. Overweeg alvast voor je begint welke doelen je met het semantisch markeren wilt bereiken en hoeveel tijd je in de annotatie wilt investeren.

Doorgaans dient een mark-up voor het structureren van informatie die op de website staat en het aanbieden in een voor zoekmachines leesbare vorm. Het doel is om aan zoekmachineproviders zoals Google te laten zien dat je website p deze wijze is geoptimaliseerd en over de beste bronnen beschikt voor zoekopdrachten naar het kernthema van het project. Stel daarom de volgende vragen:

Wat is de centrale content van je website?
Welke meerwaarde biedt deze aan potentiële bezoekers?
Welke content is voor de focus van je website zo relevant dat hij goed leesbaar voor zoekmachines moet worden gemarkeerd?

Stap 2: relevante content bepalen

Maak een lijst van alle content die meerwaarde heeft. Beslis op welke content potentiële bezoekers al op de zoekresultatenpagina’s moeten worden gewezen.

Google raadt bijvoorbeeld een markering aan met JSON-LD voor informatie die gaat over evenementen (events). In HTML kunnen evenementaankondigingen voor concerten, musicals of theatervoorstellingen volgens het volgende schema worden weergegeven:

<p>
        <a href="https://www.example.org/zambini/2017-11-20-2000">De grote Zambini – een avond vol magie</a>,
        Wederom laat de grote Zambini u een avond lang twijfelen aan uw verstand. 
        Dit keer met: Max de raaf en de elastische Sonja.
        Datum: 20-11-2017,
        Zaal open: 20:00,
        Show: 20:30 tot 23:00,
        <a href="https://www.example.org/events/zambini/2017-11-20-2000/tickets">Tickets</a>
        Prijs: 100 euro,
        Tickets verkrijgbaar,
        <a href="https://www.example.nl">Toverberg</a>,
        Op de Toverberg 1,
        0000 AA Toverplaats,
</p>

Typische informatie van het datatype ´Event´ is de datum en tijd, de prijs, de beschikbaarheid van tickets, het adres waar het evenement plaatsvindt en links naar meer informatie over het evenement of de locatie. Menselijke bezoekers van de site kunnen deze informatie halen uit een tekst, een tabel of andere weergavevormen en daar de samenhang uit opmaken. Programma’s zoals zoekmachinecrawlers hebben daarentegen metadata nodig die instructies bevatten voor hoe de aangeboden informatie moet worden verwerkt. JSON-LD levert die in de vorm van een dataformaat dat afzonderlijk van de content op een plaats naar keuze in de HTML-broncode wordt ingevoegd.

Algemeen geldende regels over hoe je als websitebeheerder een JSON-LD-mark-up maakt en in je website integreert, zijn beschikbaar op Schema.org.

Stap 3: schema’s kiezen

Schema.org biedt websitebeheerders een uitgebreid vocabulaire voor het structureren van data. De database bevat ongeveer 600 types, die met meer dan 860 properties nader kunnen worden gespecificeerd.

Bij de keuze van geschikte datatypes kun je twee strategieën volgen:

Theoretisch staat het je vrij om alle reeds geselecteerde content met de beschikbare datatypes van het Schema.org-vocabulaire te benoemen en steeds het specifieke datatype voor het betreffende contentelement te kiezen. Zo’n methode is tijdrovend en doorgaans onnodig.
In de praktijk beperken websitebeheerders zich meestal tot een deel van de Schema.org-datatypes: wanneer je met de JSON-LD-mark-up alleen maar gestructureerde data beschikbaar wilt stellen voor de zoekmachine is het voldoende om je eerst te beperken tot de datatypes die op dit moment door Google worden ondersteund en in Google Developer uitgebreid worden beschreven.

Wij raden strategie b. aan, en wel hierom: Google biedt voor alle datatypes die door de zoekmachine worden ondersteund een uitgebreide documentatie. Voor elk datatype wordt een mark-upvoorbeeld gegeven.

Tip: Gebruik de voorbeelden die Google Developer geeft als basis voor je eigen JSON-LD-mark-up.

Om je website uit te rusten met gestructureerde data hoef je het wiel niet opnieuw uit te vinden. Vooral als je nog geen ervaring hebt met de syntaxis van JSON-LD bespaar je veel tijd en energie door gebruik te maken van voorbeelden, in plaats van de mark-up voor elk datatype helemaal nieuw te schrijven.

In de documentatie van Google staat het volgende mark-upvoorbeeld voor evenementen:

<script type="application/ld+json">
        {
        "@context": "https://schema.org",
        "@type": "Event",
        "name": "Jan Lieberman Concert Series: Journey in Jazz",
        "startDate": "2017-04-24T19:30-08:00",
        "location": {
        "@type": "Place",
        "name": "Santa Clara City Library, Central Park Library",
        "address": {
        "@type": "PostalAddress",
        "streetAddress": "2635 Homestead Rd",
        "addressLocality": "Santa Clara",
        "postalCode": "95051",
        "addressRegion": "CA",
        "addressCountry": "US"
        }
        },
        "image": [
        "https://example.com/photos/1x1/photo.jpg",
        "https://example.com/photos/4x3/photo.jpg",
        "https://example.com/photos/16x9/photo.jpg"
        ],
        "description": "Join us for an afternoon of Jazz with Santa Clara resident and pianist Andy Lagunoff. 
         Complimentary food and beverages will be served.",
        "endDate": "2017-04-24T23:00-08:00",
        "offers": {
        "@type": "Offer",
        "url": "https://www.example.com/event_offer/12345_201803180430",
        "price": "30",
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock",
        "validFrom": "2017-01-20T16:20-08:00"
        },
        "performer": {
        "@type": "PerformingGroup",
        "name": "Andy Lagunoff"
        }
        }
</script>

De scripttags definiëren het element van de eerste tot en met de laatste regel als script van het type “application/ld+json”. De informatie die eronder staat is dus geschikt voor programma’s die in JSON-formaat linked data kunnen uitlezen.

Op het eerste niveau staan de keywords “@context” en “@type” met de waardes “https://schema.org” en “Event” (regel 03 en 04). Een parsend programma ontvangt hier de aanwijzing dat de volgende informatie moet worden toegewezen aan het schema “Event” volgens Schema.org. Het gaat dus om specifieke eigenschappen van het beschreven evenement die worden weergegeven in de vorm van naam-waardeparen.

Op het eerste niveau staan ook de eigenschappen “name”, “startDate”, “location”, “image”, “description”, “enddate”, “offers” en “performer” die als waarde zijn toegewezen aan de betreffende informatie over het evenement. Een zoekmachinecrawler kan de informatie “Jan Lieberman Concert Series: Journey in Jazz” daardoor meteen identificeren als naam van het evenement (name) en “2017-04-24T19:30-08:00” als exacte starttijd (StartDate).

Net als RDFa en microdata, ondersteunt ook de JSON-LD-syntaxis nesting. Daarbij wordt aan een eigenschap geen waarde, maar een (sub)schema toegewezen dat wederom nader kan worden bepaald met specifieke eigenschappen. Zo’n situatie is te zien op het tweede niveau van het codevoorbeeld in de regels beginnende met: “@type”.

De eerste keer dat dit voorkomt wordt bijvoorbeeld de Event-eigenschap “location” gedefinieerd als (sub)schema van het type “Place” en voorzien van de eigenschappen “name” en “address”. De eigenschap “address” wordt wederom als (sub)schema van het type “PostalAddress” gedefinieerd en met de schemaspecifieke eigenschappen “streetAddress”, “addressLocality”, “postalCode”, “addressRegion” en “addressCountry” gemarkeerd.

Elk nested niveau wordt tussen accolades geplaatst en zo afgegrensd van het bovenliggende niveau.

Fragment:

"location": {
        "@type": "Place",
        "name": "Santa Clara City Library, Central Park Library",
        "address": {
        "@type": "PostalAddress",
        "streetAddress": "2635 Homestead Rd",
        "addressLocality": "Santa Clara",
        "postalCode": "95051",
        "addressRegion": "CA",
        "addressCountry": "US"
        }
},

Schema.org stelt aan websitebeheerders dus datatypes beschikbaar in de vorm van een hiërarchische boomstructuur die, uitgaande van het meest algemene datatype “Thing”, steeds specifieker wordt.

In de volgende stap laten wij zien hoe je het Googlevoorbeeld van het datatype “Event” kan aanpassen aan de hierboven beschreven evenementaankondiging.

Stap 4: JSON-LD-mark-up aanpassen

De documentatie van Google bevat slechts voorbeelden die aangeven hoe de opgevoerde datatypes met JSON-LD kunnen worden gemarkeerd. Wanneer zo’n voorbeeld als model voor een eigen metadata mark-up wordt gebruikt, moet de code individueel worden aangepast. Het kan handig zijn om daarbij gebruik te maken van de documentatie van Schema.org over het betreffende datatype om zo meer te weten te komen over het gebruik van een bepaald schema en de mogelijke eigenschappen. Het volgende voorbeeld laat een individuele aanpassing zien van de voorbeeldcode van Google voor het datatype Event:

<script type="application/ld+json">
        {
        "@context": "https://schema.org",
        "@type": "Event",
        "name": "De grote Zambini – een avond vol magie",
        "startDate": "2017-11-20T20:00",
        "url": "https://www.example.org/zambini/2017-11-20-2000",
        "location": {
        "@type": "Place",
        "sameAs": "https://www.example.org",
        "name": "Toverberg",
        "address": {
        "@type": "PostalAddress",
        "streetAddress": "Op de toverberg 1",
        "addressLocality": "Toverplaats",
        "postalCode": "0000 AA",
        "addressCountry": "Toverland"
        }
        },
        "image": [
        "https://example.com/photos/1x1/zambini.jpg",
        "https://example.com/photos/4x3/zambini.jpg",
        "https://example.com/photos/16x9/zambini.jpg"
        ],
        "description": "Wederom laat de grote Zambini u een avond lang twijfelen aan uw verstand. 
         Dit keer met: Max de raaf en de elastische Sonja.",
        "endDate": "2017-11-20T23:00",
        "doorTime": "2017-11-20T20:30",
        "offers": {
        "@type": "Offer",
        "url": "https://www.example.org/events/zambini/2017-11-20-2000/tickets",
        "price": "100",
        "priceCurrency": "EUR",
        "availability": "https://schema.org/InStock",
        "validFrom": "2017-11-01T20:00"
        },
        "performer": {
        "@type": "Person",
        "name": "De grote Zambini"
        }
        }
</script>

In de eerste stap hebben we alle waardes van de voorbeeldmark-up vervangen door de respectievelijke waarde van de bovengenoemde evenementaankondiging. Daarbij zijn onjuiste (sub)schema’s en eigenschappen vervangen. Wij hebben bijvoorbeeld de eigenschap “addressRegion” weggelaten, omdat die informatie in Nederland niet gebruikelijk is. In plaats van “PerformingGroup” gebruiken wij onder “performer” het (sub)schema “Person”, omdat het hier niet gaat om een groep, maar om een enkele artiest. Ten slotte hebben wij de mark-up aangevuld met informatie die het voorbeeld van Google niet bevat: in een aantal regels staan bijvoorbeeld URL’s van het evenement en de locatie. Nog meer eigenschappen kun je vinden in de documentatie van Schema.org.

Als je je JSON-LD-mark-up helemaal zelf maakt zonder gebruik te maken van een voorbeeld is het ook verstandig om de documentatiesite van Google te raadplegen over het betreffende datatype. Hierin staan zowel de noodzakelijke als de aanbevolen properties voor alle ondersteunde datatypes.

Tip: Let op dat je JSON-LD-mark-up in ieder geval alle noodzakelijke properties bevat. Alleen dan wordt je website opgenomen in de ranking voor uitgebreide zoekresultaten, zoals rich cards. Probeer tevens waardes voor alle aanbevolen properties beschikbaar te maken om je kansen bij de ranking te vergroten.

De voorbeelden in de documentatie van Google bevatten steeds alle noodzakelijke en aanbevolen properties. Met de validatietool van Google kun je testen of er belangrijke properties ontbreken bij je mark-up.

Stap 5: JSON-LD-mark-up testen

Door het nesten van schema’s, (sub)schema’s en eigenschappen zijn complexe JSON-LD-markeringen mogelijk. Het scheiden van de HTML-mark-up en de semantische markering zorgt echter voor een veel betere leesbaarheid dan bij vergelijkbare dataformaten die zijn gebaseerd op een brontekstannotatie. Om fouten bij het programmeren te voorkomen, biedt Google met de structured data testing tool een gratis mogelijkheid om de JSON-LD-code voor datastructurering te valideren.

Dat werkt zo:

1. JSON-LD-code kopiëren en in het daarvoor bestemde veld plakken

Je kunt de mark-up kopiëren of de URL van de website waarvan je de metadata mark-up wilt testen.

2. Valideren starten met een klik op “Run Test”

Tijdens het valideren leest de tool de gestructureerde data van de JSON-LD-mark-up uit en controleert of die volledig is. Gebruikers krijgen de uitgelezen data in een tabel te zien waarin tevens tips en waarschuwingen staan, voor zover de tool syntaxisfouten of ontbrekende data heeft kunnen vaststellen. Zo kunnen ook syntaxisfouten zoals ontbrekende komma’s aan het einde van een naam-waardepaar worden gelokaliseerd.

3. Preview genereren

Naast de testfunctie biedt de Google structured data testing tool een previewmodus. Die geeft websitebeheerders een voorproefje hoe een uitgebreid zoekresultaat op basis van de geteste en gevalideerde mark-up eruit zou kunnen zien.

Fouten bij het implementeren van de JSON-LD-mark-up

Wanneer Google ondanks een JSON-LD-mark-up je website niet plaatst bij de uitgebreide zoekresultaten is er meestal een fout ingeslopen bij het structureren van de data. Controleer in dat geval je code nogmaals en let daarbij op de volgende mogelijke fouten:

Syntaxisfout: de JSON-LD-syntaxis is eenvoudig en overzichtelijk. Toch sluipen er net als bij elke markeringstaal zo nu en dan fouten in. Een veelvoorkomende fout is het verschil tussen coderingstekens/hoge aanhalingstekens ("…") en lage aanhalingstekens (“…”). Coderingstekens worden bij het programmeren gebruikt en lage aanhalingstekens om in geschreven taal iets aan te halen dat letterlijk is gezegd. Omdat tekstverwerkingsprogramma’s hoge aanhalingstekens vaak automatisch veranderen in lage aanhalingstekens kan je voor het maken van je JSON-LD-mark-up het best een editor gebruiken, zoals Notepad. Ook enkele aanhalingstekens die in andere programmacodes vaak worden gebruikt, zijn niet toegestaan in JSON.
Onvolledig, foutief of niet-specifiek vocabulaire: in de hiërarchische boomstructuur van Schema.org is exact beschreven welke properties met welke datatypes kunnen worden gebruikt. Wanneer je een property voor een datatype gebruikt die niet wordt ondersteund, kan de desbetreffende waarde niet door Google worden geïnterpreteerd, waardoor de code zal worden beoordeeld als foutief. Zulke fouten worden ook herkend door Google structured data testing tool.

Tip: Alle types en properties van het Schema.org-vocabulaire zijn case sensitive. Het schrijven van hoofdletters en kleine letters geeft dus een verschil in betekenis.

Maak altijd gebruik van de documentatiepagina’s van Schema.org en valideer je JSON-LD-code met behulp van de structured data testing tool. Lees tevens de structured data general guidelines en de algemene webmaster guidelines van Google om te voorkomen dat je regels schendt, waardoor je mogelijk geen toegang hebt tot de ranking voor uitgebreide zoekresultaten.

Overigens vind je bij STRATO veilige en voordelige hostingpakketten voor je website.

Naar STRATO hosting