Je hoort iemand zeggen dat schema markup goed is voor SEO. Misschien zag je ergens een voorbeeld met sterren, prijzen, openingstijden of veelgestelde vragen in Google. Dan voelt het alsof je website iets technisch mist.
Dat kan kloppen. Maar vaak komt de vraag op een vreemd moment. De pagina zelf is nog vaag, het aanbod is niet scherp, de lokale informatie staat verspreid en toch gaat de aandacht naar een stukje code dat Google extra uitleg moet geven.
Wanneer rich snippets belangrijker lijken dan ze zijn
Wat zichtbaar misloopt, is meestal niet de code zelf. Je zoekt op je bedrijfsnaam of dienst en ziet dat concurrenten rijkere zoekresultaten hebben. Zij tonen misschien reviews, producten, evenementen of bedrijfsinformatie. Jouw resultaat oogt kaal. Dan lijkt schema markup de ontbrekende schakel.
Bij een lokale zaak kan dat gaan over openingstijden en adresgegevens. Bij een webshop over productinformatie. Bij een dienstverlener over diensten, reviews of vragen rond het aanbod. Het zichtbare verschil is concreet: het zoekresultaat van iemand anders lijkt meer vertrouwen te geven dan dat van jou.
Toch is dat zelden een los incident. Schema markup werkt alleen goed wanneer de onderliggende informatie klopt en logisch op de pagina staat. Als je pagina zelf niet duidelijk maakt wie je helpt, wat je aanbiedt en waarom dat relevant is, geef je zoekmachines vooral gestructureerde onduidelijkheid.
De laag onder de code
Schema markup is eigenlijk een manier om betekenis explicieter te maken. Je zegt tegen zoekmachines: dit stukje tekst is een bedrijfsnaam, dit is een product, dit is een prijs, dit is een review, dit is een vraag met antwoord. Dat kan helpen, vooral wanneer de pagina al netjes is opgebouwd.
Het probleem ontstaat wanneer schema wordt gezien als een reparatielaag. Alsof je met technische labels kunt goedmaken dat de inhoud niet helder genoeg is. Dat zie ik vaker bij ondernemers die al veel aan hun website hebben laten doen: er is een mooi ontwerp, er zijn teksten, er is misschien zelfs SEO-content, maar de samenhang blijft dun.
Dan wordt er gezocht naar iets concreets om aan te draaien. Structured data voelt prettig, omdat het technisch en afgebakend klinkt. Alleen zit de echte spanning vaak eerder in volgorde. Eerst moet duidelijk zijn welke informatie belangrijk is voor de bezoeker en voor de zoekintentie. Daarna kun je bepalen of schema die informatie beter helpt interpreteren.
Bij een restaurant heeft local business schema weinig waarde als de openingsuren, menukaart en reservatiemogelijkheid op de site elkaar tegenspreken. Bij een B2B-dienstverlener helpt FAQ schema niet veel als de vragen vooral bedacht zijn om een blokje te vullen.
Signalen dat schema niet het eerste probleem is
Je herkent dit aan een paar gewone signalen. Je wilt schema toevoegen, maar je weet niet goed welke informatie je zou markeren. Je pagina noemt wel je dienst, maar legt niet concreet uit voor wie die bedoeld is. Je reviews staan ergens los van de pagina waarop iemand moet beslissen. Je productinformatie is technisch aanwezig, maar mist context die een klant nodig heeft.
Een ander signaal is dat je vooral naar Google kijkt en minder naar de bezoeker. Als de vraag is: `Hoe krijg ik sterren in Google?`, maar niemand vraagt: `Waarom zou iemand deze pagina vertrouwen?`, dan wordt de volgorde scheef.
Logische aannames die te weinig oplossen
`Als ik schema toevoeg, begrijpt Google mijn pagina beter.` Dat kan, maar alleen als er iets te begrijpen valt. Schema maakt betekenis expliciet. Het verzint geen duidelijke positionering, geen beter aanbod en geen betrouwbaardere informatie.
`Rich snippets zorgen automatisch voor meer klikken.` Soms helpt een rijker zoekresultaat. Maar als de titel, beschrijving en inhoud niet aansluiten op de zoekvraag, blijft het effect beperkt. Een opvallender resultaat dat de verkeerde verwachting wekt, kan zelfs zwakker werken.
`Mijn concurrent heeft schema, dus ik moet dat ook hebben.` Concurrenten kunnen hoger staan om veel redenen: betere inhoud, sterkere autoriteit, duidelijkere structuur, lokale bekendheid, snellere site of simpelweg een betere match met de zoekintentie. Schema kan deel zijn van het plaatje, maar het is zelden het hele verschil.
`Technische SEO is objectiever dan inhoudelijke keuzes.` Dat voelt zo, omdat technische aanpassingen meetbaar lijken. Maar ook schema vraagt inhoudelijke keuzes. Wat noem je een product? Wat is een dienst? Welke vragen zijn echt relevant? Welke informatie verdient een vaste plek op de pagina? Zonder die keuzes blijft het technisch werk aan de oppervlakte.
Hoe je schema markup gebruikt zonder je vindbaarheid eraan op te hangen
Een betere vraag is niet: heb ik schema nodig? De betere vraag is: welke betekenis moet mijn pagina zonder twijfel overbrengen, en waar helpt schema om die betekenis netter door te geven?
Bij een lokale praktijk kan dat betekenen dat naam, adres, regio, openingstijden en soort dienstverlening overal hetzelfde verhaal vertellen. Bij een webshop gaat het eerder over productnaam, beschikbaarheid, prijs, reviews en varianten. Bij een kennisartikel kan het gaan over de relatie tussen vraag, antwoord en expertise.
De beoordeling begint dus bij de pagina zelf. Kan een bezoeker snel begrijpen wat hier wordt aangeboden, voor wie het is en wat hij mag verwachten? Past de informatie bij de zoekvraag? Staat bewijs op de plek waar twijfel ontstaat? Als dat klopt, kan structured data de pagina ondersteunen. Als dat niet klopt, wordt schema een nette sticker op een rommelige doos.
Wat deze manier van kijken niet oplost
Dit maakt schema markup niet onbelangrijk. Het voorkomt alleen dat je het groter maakt dan het is. Je kunt nog steeds technische fouten hebben, ontbrekende velden gebruiken of kansen laten liggen in product-, local business- of artikeldata.
Maar het is geen quick fix voor zwakke SEO. Ook geen vervanging voor betere pagina's, duidelijke informatie of betrouwbare inhoud. Wie te snel naar uitvoering gaat, krijgt vaak een lijst technische aanpassingen zonder antwoord op de vraag waarom die pagina eigenlijk gevonden en gekozen zou moeten worden.
Hoe ik hiernaar kijk
Ik kijk naar schema markup als een gevolg van heldere informatiearchitectuur, niet als een los trucje. Eerst wil ik begrijpen wat de pagina moet betekenen: voor de bezoeker, voor Google en voor het bedrijf achter de pagina.
Daarbij let ik op de verhouding tussen inhoud, structuur en techniek. Als een pagina over een dienst gaat, moet die dienst inhoudelijk scherp genoeg zijn. Als een lokale zaak gevonden wil worden, moeten locatie, vertrouwen en praktische informatie consequent kloppen. Als een productpagina schema krijgt, moet de productinformatie ook echt beslisbaar zijn.
Mijn ervaring is dat technische SEO beter werkt wanneer ze niet wordt losgetrokken van communicatie. De code mag helpen, maar de pagina moet zelf al een helder verhaal dragen.
Wat ik wel en niet doe
Ik help analyseren waar het SEO-probleem echt zit, orden welke informatie belangrijk is en vertaal dat naar keuzes die op een website kunnen werken. Dat kan leiden tot betere paginastructuur, duidelijkere content, technische SEO-aanpassingen of samenwerking met iemand die de implementatie uitvoert.
Wat ik niet zinvol vind, is losse schema markup toevoegen zonder begrip van de pagina, de zoekintentie en het bedrijf. Dan lijkt er iets verbeterd, maar blijft de kernvraag liggen.
Schema markup is dus vooral nuttig wanneer het aansluit op iets dat al klopt. Niet als wonderlaag bovenop onduidelijkheid, wel als versterking van betekenis. Soms is de beste eerste stap daarom niet meer code, maar scherper zien welke informatie je eigenlijk aan Google en aan je bezoeker probeert uit te leggen.
