Wat gestructureerde data zoekmachines vertelt
Op een webpagina kan een prijs eruitzien als gewone tekst, net als een datum of bedrijfsnaam. Een bezoeker begrijpt vaak uit de context wat die informatie betekent, maar een zoekmachine moet die context afleiden. Gestructureerde data beschrijft onderdelen van een pagina in een afgesproken formaat. Zo kan een website expliciet aangeven dat een bedrag de prijs van een product is, dat een datum bij een evenement hoort of dat een naam een organisatie aanduidt.
De bekendste vocabulaire hiervoor is schema.org. Een schema beschrijft entiteiten en hun eigenschappen, zoals een product met een naam, merk en prijs. Zoekmachines kunnen die gegevens gebruiken om pagina’s beter te interpreteren en komen soms in aanmerking om extra informatie in zoekresultaten te tonen. Denk aan productbeoordelingen, evenementdata of informatie over een recept. Dat is geen garantie: zoekmachines bepalen zelf of ze een verrijkt resultaat tonen en kunnen hun presentatie aanpassen.
Gestructureerde data is dus geen truc om een bepaalde positie te kopen of af te dwingen. De inhoud moet ook voor bezoekers zichtbaar en relevant zijn. Markeer je bijvoorbeeld een beoordeling die nergens op de pagina te vinden is, dan ontstaat een verschil tussen de technische beschrijving en de daadwerkelijke inhoud. Gebruik schema daarom als nauwkeurige annotatie van wat er al staat, niet als vervanging voor goede informatie of een heldere pagina-opbouw.
Schema.org-types kiezen die bij de pagina passen
Schema.org bevat veel types, van Organization en Product tot Event, Article en LocalBusiness. De juiste keuze begint niet bij de vraag welk type het meeste zoekresultaatfuncties lijkt op te leveren, maar bij de inhoud van de pagina. Een productdetailpagina beschrijft een concreet artikel dat gekocht kan worden; een categoriepagina toont doorgaans meerdere artikelen en is daarom niet automatisch zelf een product. Een pagina over een voorstelling kan een evenement beschrijven, terwijl een nieuwsbericht daarover eerder een artikel is.
Schema.org is breder dan de eigenschappen die Google of een andere zoekmachine gebruikt voor verrijkte resultaten. Een type kan dus geldig zijn volgens schema.org, maar geen zichtbare uitbreiding in Google opleveren. Controleer daarom twee dingen afzonderlijk: of het type inhoudelijk klopt en of de beoogde zoekmachine er een ondersteunde functie aan koppelt. De documentatie van de zoekmachine beschrijft doorgaans ook verplichte en aanbevolen eigenschappen.
Types kunnen relaties tussen entiteiten uitdrukken. Een Article kan bijvoorbeeld een auteur en uitgever hebben; een Product kan gekoppeld zijn aan een merk en aanbiedingen. Voeg zulke relaties alleen toe wanneer ze op de pagina te onderbouwen zijn. Een brede keuze zoals Thing is technisch mogelijk, maar geeft weinig betekenis. Een specifiek type is nuttiger zolang het de werkelijkheid beschrijft. Kies dus niet meer detail dan de beschikbare en zichtbare informatie rechtvaardigt.
JSON-LD, Microdata en RDFa vergelijken
Er zijn meerdere manieren om schema.org-data in HTML te verwerken. JSON-LD staat meestal in een scriptblok en houdt de gegevens gescheiden van de zichtbare opmaak. Dat maakt het voor ontwikkelaars vaak eenvoudiger om de markup te beheren en aan te passen. Een producttemplate kan bijvoorbeeld de actuele naam, prijs en beschikbaarheid uit de productdatabase opnemen in JSON-LD, zonder dat elk tekstonderdeel in de HTML zelf extra attributen nodig heeft.
Microdata en RDFa voegen eigenschappen juist toe aan HTML-elementen. Dat kan een directe relatie leggen tussen de zichtbare tekst en de markup, maar de code wordt er vaak ingewikkelder van. Bij wijzigingen in templates kan een attribuut ongemerkt verdwijnen of aan het verkeerde element gekoppeld raken. Deze methoden kunnen passend zijn in bestaande systemen of wanneer een team al een betrouwbare implementatie heeft. Meerdere methoden door elkaar gebruiken voor dezelfde gegevens vergroot echter de kans op tegenstrijdigheden.
JSON-LD is voor veel nieuwe implementaties een praktische keuze, maar het lost inhoudelijke problemen niet vanzelf op. De gegevens moeten nog steeds overeenkomen met wat bezoekers zien, en de output moet geldig zijn. Dynamische websites vragen extra aandacht: controleer of de markup ook beschikbaar komt wanneer content via JavaScript wordt geladen. Houd daarnaast rekening met caching. Als een prijs op de pagina is bijgewerkt maar in een gecachte JSON-LD-blok oud blijft, ontvangen zoekmachines tegenstrijdige signalen. Kies de methode die past bij de techniek van de site en maak het genereren ervan onderdeel van dezelfde gegevensbron als de zichtbare inhoud.
Productgegevens en aanbiedingen correct markeren
Voor webshops is Product een veelgebruikt schema.org-type. Op een productdetailpagina kunnen eigenschappen staan zoals naam, afbeelding, merk, beschrijving en artikelnummer. Een aanbieding kan onder meer een prijs, valuta en beschikbaarheid bevatten. Welke combinatie nodig is, hangt af van de functie waarvoor de pagina in aanmerking moet komen en de actuele richtlijnen van de zoekmachine. Het is daarom verstandig om niet alleen een generiek voorbeeld over te nemen, maar de product- en aanboddocumentatie te raadplegen.
De markup moet aansluiten op het aanbod dat een bezoeker daadwerkelijk kan kopen. Als een product in verschillende maten of kleuren wordt verkocht, bepaal dan hoe varianten op de site worden aangeboden. Een variant met een eigen URL en eigen voorraad kan andere gegevens nodig hebben dan één productpagina met selecteerbare opties. Ook prijzen vragen zorgvuldigheid: vermeld de valuta, gebruik de actuele verkoopprijs en zorg dat eventuele korting niet wordt verward met de oorspronkelijke prijs. Markeer een product niet als beschikbaar wanneer het niet te bestellen is.
Bij beoordelingen geldt dat de score en het aantal beoordelingen op de pagina zichtbaar en controleerbaar moeten zijn. Een webshop hoort geen beoordelingen te verzinnen, samen te voegen op een manier die de herkomst verhult of beoordelingen van een andere website als eigen reviews te presenteren. Een technisch geldige markup maakt misleidende informatie niet acceptabel. Controleer bovendien hoe productdata wordt bijgewerkt wanneer een voorraad- of prijsfeed vertraagd is. Een kleine fout in één template kan zich over duizenden productpagina’s verspreiden, dus test verschillende situaties: op voorraad, uitverkocht, tijdelijke aanbieding en producten met varianten.
Organisaties, bedrijven en lokale vestigingen beschrijven
Een organisatie kan worden beschreven met Organization; voor een bedrijf met een fysieke, lokaal relevante vestiging kan een specifieker type onder LocalBusiness passen. Welke keuze logisch is, hangt af van de aard van de organisatie en de informatie op de website. Een landelijke dienstverlener zonder publiekslocatie is niet automatisch een lokaal bedrijf. Een winkel met bezoekadres, openingstijden en lokale dienstverlening heeft juist eigenschappen die voor bezoekers en zoekmachines betekenisvol kunnen zijn.
Gebruik consistente gegevens voor de naam, URL, logo en contactinformatie. Als er meerdere vestigingen zijn, beschrijf dan niet alle adressen alsof ze bij één locatie horen. Een vestigingspagina kan de gegevens van die vestiging bevatten, terwijl een overkoepelende organisatiepagina de bredere organisatie beschrijft. Een stabiele identifier, zoals een eigen URL in een @id-veld, kan helpen om dezelfde organisatie op verschillende pagina’s herkenbaar te maken. Gebruik die identificatie consequent en verwijs niet willekeurig naar verschillende entiteiten voor hetzelfde bedrijf.
Eigenschappen zoals openingstijden, telefoonnummer en adres moeten overeenkomen met de informatie die bezoekers op de site aantreffen. Verouderde openingstijden zijn niet alleen een datakwaliteitsprobleem; ze kunnen ook leiden tot een slechte ervaring wanneer iemand voor een gesloten deur staat. Neem alleen sociale profielen op die daadwerkelijk bij de organisatie horen en wees terughoudend met eigenschappen die geen betrouwbare bron hebben. Structured data vervangt bovendien geen bedrijfsprofiel of lokale SEO-inspanningen. Het is een manier om bestaande, controleerbare informatie op de website machineleesbaar te maken, niet om ontbrekende bedrijfsgegevens te fabriceren.
Evenementen met datum, locatie en status markeren
Een evenementpagina kan zoekmachines helpen begrijpen wat er plaatsvindt, wanneer dat gebeurt en waar bezoekers moeten zijn. Het schema.org-type Event past bij een concrete gebeurtenis, zoals een concert, congres of voorstelling. Relevante eigenschappen kunnen de naam, begin- en einddatum, locatie, organisator en ticketinformatie beschrijven. Een terugkerende activiteit kan ingewikkelder zijn: behandel afzonderlijke edities niet achteloos als één evenement wanneer de data, locaties of beschikbaarheid verschillen.
Datums moeten ondubbelzinnig zijn en overeenkomen met de informatie op de pagina. Neem waar nodig de tijdzone mee, vooral bij online evenementen of bijeenkomsten met deelnemers uit verschillende landen. Maak ook duidelijk of een evenement fysiek, online of in een hybride vorm plaatsvindt. Een locatie hoort bij de daadwerkelijke bijeenkomst; zet niet alleen het kantoor van de organisator in de markup omdat er geen locatie bekend is. Ticketprijzen en beschikbaarheid moeten de actuele situatie weerspiegelen.
De status verandert vaak: een evenement kan worden verplaatst, geannuleerd of uitverkocht raken. Laat de schema-markup meebewegen met die status en pas ook de zichtbare pagina aan. Een geannuleerd evenement dat nog als actief wordt gemarkeerd, kan bezoekers op het verkeerde been zetten. Verwijder een pagina niet per se direct als de informatie nog nuttig is, maar maak duidelijk wat er is veranderd en zorg dat de gegevens niet suggereren dat tickets nog beschikbaar zijn. Test zowel een normale evenementpagina als de uitzonderingen, omdat juist wijzigingen en oude edities in templates of CMS-workflows vaak verkeerd worden verwerkt.
Gestructureerde data toevoegen aan een website
Een betrouwbare implementatie begint met een inventarisatie van paginatypen en databronnen. Breng bijvoorbeeld productdetailpagina’s, organisatiepagina’s en evenementpagina’s in kaart en bepaal welke gegevens per type beschikbaar zijn. Zo voorkom je dat een team één JSON-LD-blok op iedere URL plaatst, ongeacht de inhoud. Maak vervolgens afspraken over de bron van elk veld: komt de prijs uit het commerceplatform, de locatie uit het CMS of de auteursnaam uit het publicatiesysteem?
Bij een maatwerkwebsite wordt JSON-LD vaak in de template opgebouwd vanuit dezelfde gegevens die de zichtbare pagina vullen. Dat verkleint de kans op afwijkingen, al blijft controle nodig op lege velden, uitzonderingen en afwijkende content. Voeg geen eigenschap toe met een lege waarde of een generieke placeholder. Als een waarde onbekend is, is weglaten meestal beter dan een verzonnen invulling. Bij een headless architectuur kan de front-end de markup genereren vanuit een API, maar controleer dan of de uiteindelijke HTML voor crawlers beschikbaar en correct gerenderd is.
Plugins kunnen een snelle start bieden, vooral bij een standaard CMS. Controleer wel of ze geen dubbele markup toevoegen naast de theme- of platformoutput. Ook moeten instellingen aansluiten op de echte structuur van de site; een plugin kan niet automatisch weten dat een bepaalde pagina een lokale vestiging beschrijft. Leg vast wie schema aanpast wanneer templates, velden of platformen veranderen. Neem de markup mee in code reviews en tests, zodat een wijziging aan een productveld niet ongemerkt de zoekmachinegegevens breekt. Een implementatie is pas robuust wanneer zij niet alleen vandaag valide is, maar ook met de dagelijkse contentprocessen blijft kloppen.
Gestructureerde data testen en veelgemaakte fouten voorkomen
Test markup voordat die breed wordt uitgerold. Een schema-validator kan controleren of de gebruikte termen en relaties technisch herkenbaar zijn. Een testtool voor zoekresultaten kan daarnaast aangeven of een pagina voldoet aan de eisen voor specifieke verrijkte resultaten. Die controles beantwoorden niet precies dezelfde vraag: geldige schema.org-syntax betekent niet automatisch dat een zoekmachine de gewenste functie ondersteunt. Controleer daarom ook de officiële richtlijnen voor het type dat je gebruikt en test meerdere URL’s, niet alleen één voorbeeldpagina.
Veel fouten ontstaan door verschillen tussen markup en zichtbare inhoud. Voorbeelden zijn een oude prijs in JSON-LD, een beoordeling die niet op de pagina staat of een datum die door een template verkeerd wordt geïnterpreteerd. Andere veelvoorkomende problemen zijn ontbrekende verplichte velden, ongeldige datumformaten, dubbele schema-blokken en een verkeerd gekozen type. Een pagina over een categorie producten als één Product markeren maakt de beschrijving inhoudelijk onjuist, ook als de code geen syntaxfout bevat.
Controleer na publicatie ook de gerenderde pagina en de rapportages in zoekmachinehulpmiddelen. Een tool kan een fout tonen die alleen op bepaalde varianten voorkomt, bijvoorbeeld bij uitverkochte artikelen of evenementen zonder eindtijd. Houd rekening met verwerkingstijd: een aanpassing verschijnt niet noodzakelijk meteen in zoekresultaten. Als een fout terugkomt, zoek dan naar de bron in template, plugin, feed of CMS-data in plaats van losse URL’s handmatig te repareren. Documenteer welke velden verplicht zijn en wie ze beheert. Daarmee voorkom je dat een toekomstige wijziging de markup opnieuw laat afwijken van de werkelijkheid.