Schema-nestingsdiepte

Schema nesting depth is het aantal ouder-kindlagen binnen je gestructureerde data. In praktische SEO-termen is dit belangrijk omdat diepere markup lastiger te debuggen is, makkelijker verkeerd verzonden kan worden op schaal, en vrijwel nooit de geschiktheid voor rich results verbetert zodra de vereiste velden al aanwezig zijn.

In één zin: de meeste sites maken schema onnodig complex. Ze modelleren een ideaal entiteitsdiagram in plaats van de kleinste, geldige implementatie die Google consistent kan parsen.

Wat telt als nesting depth

Als je Product → Offer → AggregateRating markeert, zijn dat drie niveaus. Voeg Review → Author → Organization toe binnen die keten en de diepte groeit snel. Bij enterprise-templates, vooral in e-commerce- en publishers-stacks, vermenigvuldigt die complexiteit zich over duizenden URL’s.

Google ondersteunt geneste gestructureerde data. Dat deel is niet controversieel. Het probleem is dat SEO-teams vaak vinden dat meer detail automatisch beter is. Dat is niet zo. Googles rich result-systemen geven veel meer om geschiktheid, consistentie en vereiste velden dan om je fraai gemodelleerde interne ontologie.

Waarom SEOs hier rekening mee moeten houden

Er is geen officiële Google-limiet zoals “depth 4 faalt”. Wees voorzichtig met iedereen die zo’n getal beweert. Google heeft nooit een harde afkappingsgrens gepubliceerd, en John Mueller heeft herhaaldelijk gezegd dat gestructureerde data overeen moet komen met de zichtbare inhoud op de pagina en schoon geïmplementeerd moet worden, niet maximaal. Dat is de echte regel.

Het operationele probleem is eenvoudiger: diep geneste structuren vergroten het aantal faalpunten. Eén kapot object kan een bovenliggende entiteit ongeldig maken, waarschuwingen activeren in Google’s Rich Results Test, of rommelige exports veroorzaken in Screaming Frog’s structured data-rapporten. Op een catalogus van 100.000 URL’s wordt dat een QA-probleem, geen theoretisch probleem.

Gebruik Google Search Console (GSC) Enhancements-rapporten om geldige items te monitoren en crawl daarna representatieve templates in Screaming Frog. Als je competitieve benchmarks zoekt, kunnen Ahrefs en Semrush helpen om rich result-eigenaarschap per queryset te identificeren, maar ze vertellen je niet of die depth zélf de oorzaak is. Die toeschrijving is rommelig.

Hoe een goede implementatie eruitziet

• Houd de kernentiteiten voor rich results ondiep: meestal zijn 2 tot 3 niveaus voldoende.
• Gebruik @id-referenties voor herhaalde entiteiten zoals Organization of Person in plaats van overal volledige objecten in te sluiten.
• Geef prioriteit aan vereiste en aanbevolen properties uit de Google-documentatie boven een uitputtende Schema.org-dekking.
• Valideer eerst met Google’s Rich Results Test en gebruik daarna Screaming Frog voor checks op schaal.
• Beoordeel de template-output na releases van je CMS. Schema-bloat komt vaak van developers, plugins of app-blocks, niet van SEO-tickets.

Een praktische benchmark: als je Product-markup 25+ properties bevat en 4+ geneste objectniveaus, is de kans groot dat je modellt voor volledigheid in plaats van voor zoekprestaties.

De kanttekening die de meeste glossaries overslaan

Diep genest is niet per definitie slecht. Slechte implementatie is slecht. Een nette structuur met 4 niveaus kan prima werken, terwijl een slordige structuur met 2 niveaus nog steeds geschiktheid kan missen. Bovendien is schema depth geen directe rankingfactor. Het zal een pagina niet op eigen kracht van plek 8 naar plek 1 duwen.

Daarom is dit concept minder relevant als zelfstandige metriek en meer als een governance-check. Als je markup diep, gedupliceerd en lastig te testen is, vereenvoudig het. Als het geldig, stabiel en rich results oplevert in GSC, maak het dan niet platter alleen omdat een checklist zegt “maximaal 3 niveaus”.