Structured data en Schema.org: kiezen, implementeren en controleren

Wat wil je met structured data oplossen?

Deze gids helpt bij drie beslissingen: welk type past bij de pagina, hoe je het beheersbaar invoert en wat je test voordat je publiceert. De codevoorbeelden gebruiken uitsluitend fictieve gegevens. Broncontrole: 11 september 2026.

Wat is structured data?

Structured data zijn gegevens met expliciete namen en relaties. Op een website kun je bijvoorbeeld vastleggen dat een getal een prijs is, bij welk product het hoort en welke valuta geldt. Schema.org levert hiervoor een vocabulaire; JSON-LD is een formaat om dat vocabulaire op te schrijven.

Gewone HTML is niet betekenisloos: koppen, lijsten, links en leesbare tekst helpen bezoekers en zoekmachines ook. Structured data voegt een gestructureerde beschrijving toe, geen vervanging voor de pagina. Google legt dit uit in de introductie over structured data. De implementatie hoort bij technische SEO, maar de brongegevens hebben een inhoudelijke eigenaar nodig.

Een voorbeeld: één prijs, twee weergaven

Voorbeelddata: een fictieve productpagina toont een Demothermos van 500 ml voor € 49,95, op voorraad. De bijbehorende Product-markup moet hetzelfde product, dezelfde prijs en dezelfde beschikbaarheid beschrijven.

Fictieve prijscontrole: syntactisch geldig is niet altijd inhoudelijk juist

Controle	Zichtbare pagina	JSON-LD	Besluit
Juiste koppeling	€ 49,95, op voorraad	price: 49.95; EUR; InStock	Deze gegevens komen overeen; andere controles volgen nog.
Verouderde prijs	€ 49,95, op voorraad	price: 29.95; EUR; InStock	Niet publiceren: de code kan wel geldige JSON zijn.
Verkeerde variant	Thermos 500 ml	Naam of prijs van de literfles	Herstel de productkoppeling in de bron.

Dit is de reden om schema uit dezelfde productgegevens te genereren als de pagina. Als iemand de zichtbare prijs wijzigt maar een los codeblok vergeet, ontstaat een verschil dat een gewone syntaxcontrole niet oplost.

Wat structured data wel en niet kan opleveren

Rich results kunnen klikken beïnvloeden, zonder vast percentage

Uitgebreide zoekresultaten kunnen aanvullende informatie tonen, zoals een productprijs. Dat kan een bezoeker helpen kiezen. Er is hier geen onderbouwde algemene belofte van 20 tot 30 procent meer klikken. Het effect verschilt per zoekvraag, resultaatvorm, apparaat en website. Vergelijk daarom eigen perioden en vergelijkbare pagina’s; corrigeer voor seizoen en andere gelijktijdige wijzigingen voordat je een effect toeschrijft aan schema.

Expliciete gegevens blijven controleerbare beweringen

Een eigenschap maakt duidelijk wat je bedoelt, niet of het waar is. Een onjuiste openingstijd blijft onjuist als je er openingHoursSpecification van maakt. Verwacht geen automatische betere positie, snellere indexatie of foutloze interpretatie. De waarde zit in juiste gegevens en een passende toepassing.

Kijk welke zoekfunctie werkelijk bestaat

De Google-galerij met ondersteunde structured data is het vertrekpunt voor actuele zoekfuncties. Schema.org kent veel meer soorten informatie dan Google als afzonderlijke rich result ondersteunt. Een type kan inhoudelijk passend zijn zonder een eigen opvallende zoekweergave.

Structured data voor AI: ondersteuning, geen toegangsbewijs

Maak geen universele claim over alle AI-systemen

Een AI-dienst kan gegevens uit verschillende bronnen en processen gebruiken. Zonder documentatie of reproduceerbare test kun je niet beweren dat ieder platform jouw JSON-LD verwerkt, laat staan vaker citeert. Houd technische toegang, bronselectie en het uiteindelijke antwoord uit elkaar. Onze platformgids behandelt de verschillen in toegang.

Geen speciaal verplicht schema voor Google AI

Google vermeldt expliciet dat structured data niet verplicht is voor generatieve zoekfuncties en dat er geen speciaal Schema.org-type voor nodig is. Correcte markup kan wel blijven bijdragen aan geschiktheid voor bestaande rich results. Een claim als “40 procent vaker geciteerd door schema” volgt daar niet uit. Zie de Google-richtlijn voor generatieve zoekfuncties en de praktische GEO-aanpak.

Schema.org: woorden en relaties, geen Google-contract

Types, eigenschappen en herkenbare ID’s

Volgens de Schema.org-documentatie zijn types hiërarchisch georganiseerd en hebben ze eigenschappen. Denk aan Organization, Person en Product. Een Product kan een Offer hebben; een Article kan een Person als auteur aanwijzen. Je beschrijft relaties tussen dingen, niet alleen een lijst zoekwoorden.

Gebruik voor dezelfde organisatie of auteur steeds dezelfde @id. Geef een andere entiteit een eigen ID. Zo kun je een artikel aan de bestaande auteur en uitgever koppelen zonder drie afwijkende beschrijvingen van hetzelfde bedrijf te onderhouden. Een @id is een identificatiemiddel, geen verificatiebadge.

JSON-LD, Microdata of RDFa?

Drie ondersteunde formaten; kies vooral een onderhoudbare implementatie

Formaat	Plaats van gegevens	Praktisch aandachtspunt
JSON-LD	Een apart gegevensblok in een script-element	Goed uit CMS-data te genereren, maar voorkom afwijkingen van de zichtbare pagina.
Microdata	Attributen bij HTML-elementen	Gegevens zitten dicht bij de zichtbare inhoud; wijzigingen aan templates kunnen de relaties beïnvloeden.
RDFa	Attributen in HTML met vocabulaireverwijzingen	Past bij bepaalde bestaande systemen; onderhoud vereist kennis van die structuur.

Google ondersteunt alle drie en beveelt meestal JSON-LD aan vanwege beheer en implementatie. Een correct werkende bestaande Microdata-implementatie hoeft niet uitsluitend voor een vermeende rankingwinst herschreven te worden. Zie de formaten in de Google-introductie.

Kies het type op inhoud, niet op maximale hoeveelheid

Organization en LocalBusiness

Organization beschrijft de organisatie, bijvoorbeeld naam, logo en identificerende gegevens. LocalBusiness beschrijft een werkelijk lokaal bedrijf of een vestiging. Voeg niet voor iedere bediende stad een fictief kantoor toe. Bij meerdere echte locaties leg je per locatie de juiste gegevens vast. Een vermelding leidt niet automatisch tot een Knowledge Panel.

FAQPage: nuttige vragen zijn geen FAQ-rich-result

Google toont sinds 7 mei 2026 geen FAQ-rich-results meer. De documentatie is daarna verwijderd; dit staat in het Google-wijzigingslog. Behoud nuttige vragen en antwoorden voor bezoekers. Besteed geen implementatiebudget aan de belofte dat FAQPage je zoekresultaat laat uitklappen. Zie ook de FAQ-schema-gids.

Article en BlogPosting

Beschrijf een echt artikel met passende titel, afbeelding, auteur en oorspronkelijke datum. De Article-richtlijn heeft aanbevolen eigenschappen, geen universele lijst verplichte velden. Koppel de echte auteur aan een profiel. Een technische databasewijziging is geen nieuwe publicatie of bewijs van menselijke review.

Product en Offer

Voor Product-snippets vraagt Google een naam en ten minste offers, review of aggregateRating. Dat betekent niet dat je beoordelingen moet verzinnen om een waarschuwing weg te krijgen. Aanbiedingen moeten de echte prijs en voorwaarden volgen. Merchant listings hebben aanvullende eisen; verwissel die niet met een geslaagde eenvoudige Product-test.

BreadcrumbList

Een BreadcrumbList beschrijft de plek van een pagina in de sitehiërarchie. De paden moeten logisch zijn voor bezoekers. Het vervangt geen echte navigatielinks en garandeert niet dat Google ieder onderdeel klikbaar toont op elk apparaat.

HowTo: geen Google-stappencarrousel meer

HowTo-rich-results zijn in september 2023 volledig beëindigd. Het Google-bericht met septemberupdate maakt dat expliciet. Maak handleidingen met begrijpelijke stappen en relevante beelden, niet om een verdwenen carousel te activeren.

Review en AggregateRating

Echte reviews alleen zijn niet voldoende voor ieder reviewtype. Google sluit zelfbediende bedrijfsreviews bij Organization en LocalBusiness uit van reviewsterren, ook wanneer een externe reviewwidget op de eigen site staat. Beoordelingen moeten zichtbaar en bij het juiste item horen; verzonnen of niet duidelijk bekendgemaakte beloonde reviews zijn niet toegestaan. Controleer de reviewrichtlijn voordat je een beoordeling markeert.

Welke gegevens verdienen prioriteit in jouw branche?

Startpunten per paginatype, geen garantie op een zoekfunctie

Pagina of organisatie	Passende inhoud	Eerst controleren
Bureau of zakelijke dienst	Organization, Service, WebPage	Aanbod, echte aanbieder en verantwoordelijkheden; geen aparte algemene Service-rich-result beloven.
Webshopproduct	Product en werkelijke Offer	Prijs, valuta, voorraad en variant vanuit dezelfde bron als de productpagina.
Restaurant of echte vestiging	Passend subtype van LocalBusiness	Adres en openingstijden; geen vestiging of reviewsterren suggereren die niet bestaan.
Blog of redactionele publicatie	Article of BlogPosting, auteur en uitgever	Wie schreef het, wanneer verscheen het en wat is werkelijk aangepast?
Evenement of opleiding	Type dat bij het concrete aanbod past	Actuele Event- of Course-list-documentatie en deelnamevoorwaarden; geen generieke verkoopactie als evenement.
SaaS of softwarepagina	SoftwareApplication als de pagina werkelijk software beschrijft	Productgegevens en ondersteunde Google-functie; geen HowTo-carousel beloven.

Gebruik voor de laatste drie gevallen ook de relevante handleiding in de actuele galerij. De tabel is een keuzehulp, niet een complete implementatiespecificatie. Voor lokale vindbaarheid blijven echte bedrijfsinformatie en een bruikbare lokale SEO-aanpak nodig.

Van één gecontroleerde template naar de rest van de site

Stap 1: inventariseer bestaande uitvoer

Noteer per representatieve pagina welke JSON-LD-blokken en HTML-attributen al worden uitgevoerd. Leg vast welke plugin, template of tagmanager die aanmaakt. Test een gewone pagina én een uitzondering, zoals een uitverkocht product of een artikel zonder afbeelding. Kijk eerst naar conflicten voordat je nog een generator toevoegt.

Stap 2: maak een gegevensafspraak

Leg voor ieder belangrijk veld vier dingen vast: bron, inhoudelijke eigenaar, verversmoment en controle. Bijvoorbeeld: productprijs uit de catalogus, beheerd door e-commerce, bijgewerkt bij een prijswijziging, gecontroleerd tegen de zichtbare productpagina. Zonder zo’n afspraak kan een technisch correcte implementatie morgen alweer achterlopen.

Stap 3: voer de beschrijving uit bij de juiste pagina

JSON-LD staat in een script-element met type application/ld+json. Google kan het in head of body verwerken. Een CMS-template die zichtbare tekst en schema uit dezelfde bron opbouwt is een beheersbare keuze. Geef niet ieder paginatype blind dezelfde Product-, Recipe- of Service-beschrijving mee.

Stap 4: sluit aan op je CMS en bestaande graph

Bij WordPress kan een bestaande SEO-plugin al een samenhangende graph uitvoeren. De integratiedocumentatie van Yoast beschrijft hoe je bestaande onderdelen kunt uitbreiden en ID’s hergebruikt. Controleer dat een thema, plugin en maatwerk niet tegelijk verschillende organisaties, auteurs of prijzen beschrijven.

Voor een eigen applicatie kan de ontwikkelaar de gegevens met de server-HTML meesturen. Google ondersteunt ook JavaScript-gegenereerde structured data. Dat maakt iedere tagmanageroplossing nog niet even geschikt: controleer de werkelijk gerenderde uitvoer, niet alleen de losse code. Google waarschuwt dat dynamisch gegenereerde Product-markup Shopping-crawls minder frequent en betrouwbaar kan maken, vooral bij snel wijzigende prijs of voorraad.

Stap 5: test een bewuste uitzondering

Gebruik naast het normale voorbeeld een ontbrekend veld, gewijzigde prijs en niet-beschikbaar product. Spreek af wat de uitvoer dan moet zijn. Ontbrekende beoordelingen horen geen automatisch ingevulde vijf sterren te worden. Publiceer eerst een beperkte groep en controleer daarna de echte productie-URL’s, inclusief caches.

JSON-LD-voorbeelden met expliciete voorbeelddata

Onderstaande objecten zijn zelfstandig leesbare JSON, bedoeld voor het gegevensgedeelte van een application/ld+json-script. Alle namen, productgegevens, afbeeldingen en datums zijn fictief. example.com is een voorbeeldadres; vervang het niet blind door je domein zonder ook de inhoud en relaties te controleren. De voorbeelden zijn geen bewijs van een geslaagde live Rich Results Test.

LocalBusiness (lokaal bedrijf)

Een lokaal bedrijf vraagt echte vestigingsgegevens. De Google-richtlijn vereist onder meer naam en fysiek adres voor dit type. Kopieer dus geen fictief adres naar je productieomgeving. Gebruik een passende organisatiebeschrijving als dat beter bij de werkelijkheid past en raadpleeg de LocalBusiness-specificatie voor de concrete situatie.

FAQPage (veelgestelde vragen)

Er staat hier bewust geen codeblok dat FAQ-sterren of uitklapresultaten belooft. Schrijf eerst behulpzame vragen en antwoorden. Als een andere toepassing FAQPage gebruikt, documenteer dan die concrete afnemer en controleer de uitvoer daarop. Een type dat nog in een vocabulaire staat, activeert niet vanzelf een Google-functie.

BlogPosting (blogartikel)

Voorbeelddata: “Een thermosfles schoonmaken” is op 1 september 2026 gepubliceerd door Voorbeeldredacteur bij Voorbeelduitgever en op 8 september inhoudelijk gewijzigd. Diezelfde gegevens horen zichtbaar bij dat fictieve artikel. De graph verbindt artikel, auteur en uitgever met vaste ID’s; de data zijn geen reviewgegevens van Pico Yellow.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Voorbeelduitgever",
      "url": "https://example.com/"
    },
    {
      "@type": "Person",
      "@id": "https://example.com/redactie#person",
      "name": "Voorbeeldredacteur",
      "url": "https://example.com/redactie"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/thermos-onderhoud#article",
      "headline": "Een thermosfles schoonmaken",
      "image": "https://example.com/thermos-onderhoud.jpg",
      "datePublished": "2026-09-01T10:00:00+02:00",
      "dateModified": "2026-09-08T10:00:00+02:00",
      "author": {
        "@id": "https://example.com/redactie#person"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": "https://example.com/thermos-onderhoud"
    }
  ]
}

In je eigen implementatie hoort de afbeelding echt bereikbaar en relevant te zijn. Gebruik de oorspronkelijke publicatiedatum en een echte wijzigingsdatum. Bewaar menselijke review apart; dateModified zegt op zichzelf niet wie de inhoud heeft gecontroleerd.

Product met Offer (webshop)

Dit object hoort bij de fictieve Demothermos van € 49,95 uit de prijscontrole hierboven. Er zijn geen reviews opgegeven, dus die worden ook niet gefabriceerd.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/thermos-500#product",
  "name": "Demothermos 500 ml",
  "image": "https://example.com/thermos-500.jpg",
  "description": "Fictieve thermosfles van 500 ml voor dit codevoorbeeld.",
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/thermos-500",
    "price": "49.95",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock"
  }
}

Dit is een eenvoudig Product-snippetvoorbeeld, niet de complete specificatie voor alle Shopping-functies. Een waarschuwing over aanbevolen reviews is geen opdracht om beoordelingen toe te voegen die niet bestaan.

Vier controles die elkaar niet vervangen

Rich Results Test: ondersteunde Google-functies

De Rich Results Test helpt bij de technische geschiktheid voor ondersteunde rich results. Test de echte URL na publicatie; bij JavaScript kunnen de uitkomsten anders zijn dan wanneer je alleen code plakt. Een geslaagde test bewijst geen uiteindelijke vertoning of inhoudelijke juistheid.

Schema Markup Validator: een andere reikwijdte

De Schema Markup Validator extraheert Schema.org-gegevens en helpt bij het onderzoeken van syntax en relaties. Hij is niet simpelweg “strenger dan Google”: de instrumenten beantwoorden verschillende vragen. Een Service kan herkenbare Schema.org-data zijn zonder eigen Google-rich-result.

Search Console: wat heeft Google verwerkt?

Controleer beschikbare rich-resultstatusrapporten en URL-inspectie. Niet ieder type heeft een eigen rapport, en afwezigheid van een rapport bewijst niet dat de code ontbreekt. Maak onderscheid tussen de laatst geïndexeerde versie, een live test en de werkelijke zoekweergave.

Wat de controles opleveren en wat je daarnaast moet beoordelen

Controle	Geeft informatie over	Bewijst niet
JSON-parser	Kan het gegevensblok gelezen worden?	Dat type, eigenschappen of inhoud passend zijn.
Schema Markup Validator	Herkenbare Schema.org-structuur en relaties	Geschiktheid voor iedere Google-functie.
Rich Results Test	Technische voorwaarden van ondersteunde zoekfuncties	Dat het resultaat wordt getoond of dat claims waar zijn.
Pagina- en gegevenscontrole	Overeenkomst tussen bron, zichtbare inhoud en markup	Dat Google de nieuwste versie al verwerkt heeft.
Search Console en zoekwaarneming	Verwerking, gerapporteerde fouten en zichtbare uitkomsten	Een vaste ranking-, CTR- of omzetstijging.

Welk gereedschap gebruik je wanneer?

Begin met de JSON-parser in je ontwikkelomgeving, de Schema Markup Validator en de Rich Results Test. Een sitescan kan helpen dezelfde templatefout op meerdere URL’s terug te vinden. Een plugin of generator maakt gegevens aan; dat is iets anders dan verifiëren dat de gegevens kloppen. Koop geen extra tool voordat duidelijk is welk controleprobleem de huidige middelen niet oplossen.

Bewaar per steekproef URL, testdatum, codeversie, waarneming en vervolgactie. Een screenshot met “geldig” zonder URL en datum is geen bruikbaar opleveringsbewijs. Leg ook vast wie terugkerende prijs-, voorraad- of auteurswijzigingen bewaakt.

Veelgemaakte fouten en een passende correctie

1. Mismatch tussen markup en zichtbare content

Herstel de bronkoppeling, niet alleen de tekst in één los script. Hertest vervolgens zowel de normale situatie als de wijziging die de fout veroorzaakte.

2. Review-schema misbruik

Verwijder niet-bestaande beoordelingen. Onderzoek bij bedrijfsreviews eerst de uitsluiting voor zelfbediende Organization- en LocalBusiness-reviews. Een echte externe widget heft die uitsluiting niet op.

3. Incomplete of ongeldige schema

Lees de voorwaarden van het specifieke type. “Alle types hebben dezelfde verplichte velden” klopt niet. Maak onderscheid tussen een kritieke fout, een aanbevolen eigenschap en niet-toepasselijke informatie.

4. Verouderde gegevens

Leg vast welke wijziging een verversing vraagt en controleer de gepubliceerde versie. Denk ook aan CDN- en CMS-caches; een correcte database is niet automatisch correcte live-HTML.

5. Te veel irrelevante schema types

Voeg geen Recipe toe aan een bureaudienst en geen vestiging aan een stad waar je alleen klanten bedient. De beschrijving moet bij de echte pagina passen.

6. JSON-syntaxfouten

Gebruik een serializer en test de uiteindelijke uitvoer. Een kommafout is een ander probleem dan een fout productnummer; los beide op met de juiste controle.

7. Schema niet updaten na sitewijzigingen

Neem redirects, auteursprofielen, beeld-URL’s en stabiele ID’s mee bij een migratie. Verifieer bestaande verwijzingen voordat een tweede systeem afwijkende gegevens publiceert.

De algemene richtlijnen vereisen passende, zichtbare en actuele inhoud. Een handmatige structured-data-actie kan geschiktheid voor rich results wegnemen; volgens Google verandert zo’n actie op zichzelf niet de ranking in gewone webresultaten. Andere overtredingen kunnen eigen gevolgen hebben.

Checklist voor een controleerbare oplevering

1. Kies een echte gebruikersvraag en een representatieve pagina.
2. Inventariseer bestaande generators en mogelijke dubbele uitvoer.
3. Selecteer het juiste type en de actuele functievoorwaarden.
4. Leg bron, eigenaar, updategebeurtenis en controle per belangrijk veld vast.
5. Hergebruik organisatie- en auteurs-ID’s consequent.
6. Houd publicatie, inhoudelijke wijziging en menselijke review gescheiden.
7. Controleer namen, adressen, prijzen, beschikbaarheid en beelden tegen de pagina.
8. Test normale én ontbrekende of veranderde gegevens.
9. Valideer syntax en Schema.org-structuur.
10. Test de bedoelde Google-functie met de echte URL.
11. Controleer live-uitvoer en eventuele caches na publicatie.
12. Leg foutstatus, verantwoordelijke en hertest vast.

Onderhoud juiste gegevens, niet een vermeende AI-score

Een nieuw schema of een extra veld is pas nuttig als duidelijk is welke informatie het correct beschrijft en wie die gebruikt. Houd eigen experimenten apart van vastgestelde richtlijnen. Voor onderzoek naar AI-zichtbaarheid kun je de monitoringgids gebruiken; een verandering in citaties bewijst niet zonder meer een oorzaak door structured data.

Ook oudere beloftes over zoekfuncties verdienen onderhoud. Google heeft de sitelinks-zoekbox vanaf 21 november 2024 verwijderd. Dat betekent niet dat alle WebSite-data overbodig zijn: sitenamen zijn een andere toepassing. Houd het doel van ieder onderdeel dus expliciet.

Veelgestelde vragen over structured data

Is structured data verplicht voor een goede website?

Niet ieder paginatype heeft dezelfde behoefte. Begin met informatie waarvoor een duidelijke toepassing bestaat en die je actueel kunt houden. Leesbare inhoud en bruikbare navigatie blijven nodig.

Ga ik door JSON-LD automatisch hoger ranken?

Nee. Een gegevensblok of geslaagde validator geeft geen rankinggarantie. Beoordeel geschiktheid voor een concrete zoekfunctie en meet de eigen uitkomsten zonder een vast groeipercentage te beloven.

Waarom ziet Google mijn schema maar toont het geen rich result?

Technisch herkenbare gegevens en werkelijke weergave zijn verschillende zaken. Controleer functieondersteuning, inhoudelijke voorwaarden, indexatie en de verwerkte versie. Ook bij correcte implementatie is vertoning niet gegarandeerd.

Moet ik FAQPage en HowTo onmiddellijk verwijderen?

Niet uitsluitend omdat Google die rich results heeft beëindigd. Controleer of een andere toepassing de gegevens gebruikt en of ze kloppen. Investeer er niet in vanuit een belofte van verdwenen Google-weergaven.

Kan ik echte Google-reviews op mijn eigen site markeren voor sterren?

Voor Organization en LocalBusiness zijn zelfbediende bedrijfsreviews uitgesloten van reviewsterren, ook via een externe widget. Dat is een andere vraag dan of je echte reviews met toestemming zichtbaar kunt tonen.

Is JSON-LD beter dan werkende Microdata?

Google ondersteunt beide en ook RDFa. JSON-LD is vaak eenvoudiger te beheren. Een omzetting is vooral zinvol als die onderhoud of consistentie verbetert, niet vanwege een gegarandeerde rankingwinst.

Kan een WordPress-plugin dit allemaal automatisch regelen?

Een plugin kan veel structuur genereren, maar kent niet automatisch iedere werkelijke prijs, verantwoordelijkheid of auteur. Controleer instellingen, thema-uitvoer, aanvullende plugins en uitzonderingen. Eén samenhangende gegevensbron voorkomt conflicten.

Heb ik Speakable nodig voor Nederlandse voice search?

Dat is geen algemene Nederlandse vereiste. De Google-documentatie voor Speakable beschrijft een beperkte toepassing voor Engelstalige nieuwsinhoud en gebruikers met Engelstalige Google Home-apparaten in de VS. Daaruit volgt geen universele werking voor Alexa, Siri of Nederlandse bedrijfswebsites.

Wat kost een structured-data-implementatie?

Dat hangt af van templates, beschikbare brongegevens, bestaande conflicten, koppelingen en testwerk. Pico Yellow maakt een offerte op maat. Spreek ook onderhoud en eigenaarschap af; een eenmalige installatie houdt veranderende gegevens niet vanzelf juist.

Wat lever ik aan voor een audit?

Een lijst belangrijke pagina’s, gebruikte CMS-onderdelen, bestaande testmeldingen en de verantwoordelijke voor brongegevens. Deel toegang veilig en alleen waar nodig. Openbare broncode en zichtbare inhoud vormen een eerste controle, geen volledig accountonderzoek.

De reikwijdte van Speakable staat in de officiële documentatie.

Begin met één controleerbaar paginatype

Kies één pagina, vergelijk bron en zichtbare inhoud met de markup, test de juiste functie en leg het resultaat vast. Zo ontdek je of de volgende stap een inhoudelijke correctie, templatewijziging of aanvullend onderzoek is. Wil je hulp bij de uitvoering? Plan een adviesgesprek of vraag een offerte op maat voor een technische SEO-audit en implementatie.