Structured data voor websites, vaak schema markup genoemd, is een machineleesbare manier om te beschrijven wat er al op een pagina staat: een organisatie, artikel, product, video, evenement of persoon.<\/p>\n
Dat verschil is belangrijk. Goede schema markup beschrijft de echte pagina. Ze maakt van een algemene dienst geen product, van een verkoopdeadline geen evenement en van een korte gids geen cursus.<\/p>\n
Google ondersteunt een beperkte set rich results voor structured data, terwijl Schema.org veel breder is. Stel daarom v\u00f3\u00f3r je een type toevoegt twee vragen: beschrijft het de pagina nauwkeurig en ondersteunt Google het rich result dat je verwacht?<\/p>\n
\nSchema werkt het best wanneer het de pagina beschrijft en niet wanneer het de pagina belangrijker probeert te laten klinken.<\/p>\n<\/blockquote>\n
Correcte structured data kan systemen helpen een pagina te begrijpen en kan ervoor zorgen dat ze in aanmerking komt voor een rich result. Het uiterlijk daarvan, een hogere ranking, meer verkeer of een vermelding in een AI-resultaat zijn nooit gegarandeerd. Het nuttige doel is eenvoudiger: maak het echte bedrijf, de content en de navigatie makkelijker herkenbaar.<\/p>\n
Welke structured data staat al op je website?<\/h2>\n
De meeste bedrijfswebsites hebben niet ieder mogelijk type nodig. Een klein aantal correcte schema-types dat goed wordt onderhouden is meestal waardevoller.<\/p>\n
Organization<\/code> beschrijft de organisatie achter de website, met onder meer de openbare naam, het logo, de URL en relevante identiteitsverwijzingen.WebSite<\/code> hoort bij een duidelijke en consistente site-identiteit. Geen van beide vervangt zichtbare branding. De gegevens moeten ermee overeenkomen.<\/p>\n
BreadcrumbList<\/code> kan de echte route door de website beschrijven, bijvoorbeeld Diensten, Onderhoudsplannen en de pagina die iemand leest. Die route moet logisch zijn voor een bezoeker en niet simpelweg de URL-structuur kopi\u00ebren.<\/p>\nVoor redactionele content beschrijft
Article<\/code> ofBlogPosting<\/code> de titel, een openbare auteur wanneer die er is en de publicatie- en wijzigingsdatums uit WordPress. De belangrijkste vraag is niet hoeveel labels een pagina kan dragen, maar welk systeem eigenaar is van de data en de updates bijhoudt.<\/p>\nKies alleen Schema.org-types die echt bij de pagina passen<\/h2>\n
Sommige typen structured data zijn waardevol, maar alleen wanneer de website precies bevat wat ze beschrijven.<\/p>\n
\n
LocalBusiness<\/code> past bij een echte, klantgerichte locatie met correcte openbare gegevens. Alleen een stad bedienen is geen reden om een bezoekadres te claimen.<\/li>\nVideoObject<\/code> hoort op een pagina waar de gemarkeerde video werkelijk bekeken kan worden. Een decoratieve clip of een link naar een losstaand platform is niet voldoende.<\/li>\nEvent<\/code> is bedoeld voor \u00e9\u00e9n echt evenement met een eigen pagina, datum, tijd en locatie. Het is niet bedoeld voor een aanbieding, dienstenpakket of normale openingstijden.<\/li>\nCourse<\/code> past bij een echt onderwijsprogramma met lessen, leeruitkomst, docenten en deelnemers. Een korte gids of eenmalig webinar is geen cursuscatalogus.<\/li>\nDataset<\/code> is bedoeld voor een gepubliceerde dataset met een duidelijke afbakening, bron en manier om de data te openen. Het vervangt geen gewone paginamarkup.<\/li>\nJobPosting<\/code> hoort bij een echte openstaande vacature met een duidelijke manier om te solliciteren. De data moeten worden bijgewerkt of verwijderd zodra de vacature sluit.<\/li>\nSoftwareApplication<\/code> is voor een echte openbare applicatie met correcte informatie over de app en het aanbod, niet voor een priv\u00e9portal of maatwerkdienst.<\/li>\nProduct<\/code> en merchant listings passen bij werkelijk verkoopbare, gestandaardiseerde artikelen met actuele prijs, beschikbaarheid en informatie over het aanbod. Een maatwerktraject wordt geen product alleen omdat een prijsweergave aantrekkelijk lijkt.<\/li>\n<\/ul>\nFAQPage en HowTo leveren geen Google rich results meer<\/h2>\n
QAPage<\/code> is voor een vraag waarop gebruikers alternatieve antwoorden kunnen insturen. Een FAQ met \u00e9\u00e9n antwoord van de uitgever is geen Q&A-platform. Reviews en beoordelingen moeten echt, zichtbaar en gericht zijn op het gemarkeerde onderwerp. Een bedrijf kan geen geldig reviewresultaat maken door zichzelf te beoordelen.<\/p>\n
FAQPage<\/code> kan zichtbare en onderhouden FAQ\u2019s nog steeds machineleesbaar beschrijven, maar Google toont sinds 7 mei 2026 geen FAQ rich results meer. Gebruik FAQ-markup daarom voor een consistente kennisstructuur, niet voor extra ruimte in Google.<\/p>\nGoogle toont ook geen HowTo rich results meer. De volgorde blijft daarom simpel: eerst nuttige content, daarna een waarheidsgetrouwe beschrijving en nooit een schema-type toevoegen voor een zoekresultaat dat niet bestaat.<\/p>\n
Voorkom dubbele schema markup en bepaal \u00e9\u00e9n bron<\/h2>\n
De betrouwbaarste manier om schema te onderhouden is ieder gegeven dicht bij het systeem te houden dat er eigenaar van is. Artikeldatums komen uit het publicatiesysteem. Prijzen en beschikbaarheid komen uit het echte aanbod. Een vacature sluit in de vacatureadministratie. FAQ\u2019s blijven in de beheerde knowledge base en worden niet gekopieerd naar een tweede plugin of los JSON-LD-blok.<\/p>\n
Zo voorkom je ook een veelvoorkomend technisch probleem: twee tools die dezelfde pagina verschillend beschrijven. E\u00e9n duidelijke en complete schema graph is makkelijker te valideren dan meerdere concurrerende fragmenten die elk maar een deel van de waarheid kennen.<\/p>\n
Controleer v\u00f3\u00f3r publicatie of de markup past bij het hoofdonderwerp van de pagina, of ieder belangrijk gegeven zichtbaar en actueel is en of de specifieke Google-documentatie het gebruikte type ondersteunt. Test de gerenderde pagina en controleer daarna Search Console.<\/p>\n
Nauwkeurige structured data maakt een website niet indrukwekkender. Ze maakt het echte bedrijf, de content en het aanbod makkelijker herkenbaar. Zo blijft je schema ook op de lange termijn betrouwbaar.<\/p>\n","protected":false},"excerpt":{"rendered":"
Een praktische gids over structured data die zoekmachines helpt je website te begrijpen, zonder schema-types toe te voegen die niet bij de pagina passen.<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[28],"class_list":["post-202","post","type-post","status-publish","format-standard","hentry","category-eviri-notes-nl","tag-eviri-build-nl"],"_links":{"self":[{"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/posts\/202","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/comments?post=202"}],"version-history":[{"count":2,"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/posts\/202\/revisions"}],"predecessor-version":[{"id":218,"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/posts\/202\/revisions\/218"}],"wp:attachment":[{"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/media?parent=202"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/categories?post=202"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.evirisystems.com\/nl\/wp-json\/wp\/v2\/tags?post=202"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}