Schema-Einbettungstiefe

Schema-Nesting-Tiefe ist die Anzahl der übergeordneten-zu-nachgeordneten Ebenen (Parent-Child-Layer) innerhalb deiner strukturierten Daten. In praktischen SEO-Begriffen ist das relevant, weil tiefer verschachteltes Markup schwerer zu debuggen ist, bei großen Rollouts leichter fehlerhaft ausgeliefert wird und selten die Berechtigung für Rich Results verbessert, sobald die erforderlichen Felder bereits vorhanden sind.

Die klare Version: Die meisten Websites machen Schema unnötig kompliziert. Sie modellieren stattdessen einen idealen Entitätsgraphen, statt die kleinste valide Implementierung abzubilden, die Google konsistent verarbeiten kann.

Was zählt als Nesting-Tiefe

Wenn du Product → Offer → AggregateRating auszeichnest, sind das drei Ebenen. Fügst du in dieser Kette Review → Author → Organization hinzu, wächst die Tiefe schnell. In Enterprise-Templates – insbesondere in E-Commerce- und Publisher-Setups – vervielfacht sich diese Komplexität über tausende URLs.

Google unterstützt verschachtelte strukturierte Daten zwar. Dieser Teil ist nicht umstritten. Das Problem ist, dass SEO-Teams häufig mehr Detail automatisch als besser behandeln. Das ist nicht so. Die Rich-Result-Systeme von Google kümmern sich viel stärker um Berechtigung (Eligibility), Konsistenz und erforderliche Felder als um deine elegant modellierte interne Ontologie.

Warum SEOs das beachten sollten

Es gibt keine offizielle Google-Grenze wie „Tiefe 4 schlägt fehl“. Seien vorsichtig bei jedem, der so etwas behauptet. Google hat nie einen harten Cutoff veröffentlicht, und John Mueller hat wiederholt gesagt, dass strukturierte Daten zum sichtbaren Seiteninhalt passen und sauber implementiert werden sollten – nicht maximal.

Das operative Problem ist einfacher: Tiefe Verschachtelung erhöht die Fehleranfälligkeit. Ein kapptes Objekt kann eine übergeordnete Entität ungültig machen, Warnungen in Googles Rich Results Test auslösen oder in den strukturierten Daten-Reports von Screaming Frog zu unruhigen (noise) Exports führen. Bei einem Katalog mit 100.000 URLs wird das zu einem QA-Problem, nicht zu einer Theoriefrage.

Nutze die Enhancements-Berichte in der Google Search Console (GSC), um gültige Elemente zu überwachen, und crawle dann repräsentative Templates in Screaming Frog. Wenn du wettbewerbsfähige Benchmarks brauchst, können Ahrefs und Semrush helfen, Ownership für Rich Results nach Query-Set zu identifizieren – aber sie sagen dir nicht, ob die Tiefe selbst die Ursache ist. Diese Zuordnung ist unübersichtlich.

Wie eine gute Implementierung aussieht

• Halte die Kern-Entitäten für Rich Results flach: meist reichen 2 bis 3 Ebenen.
• Nutze @id-Referenzen für wiederverwendete Entitäten wie Organization oder Person, statt überall vollständige Objekte einzubetten.
• Setze Prioritäten auf erforderliche und empfohlene Eigenschaften aus der Google-Dokumentation statt auf eine erschöpfende Schema.org-Abdeckung.
• Validiere zuerst mit Googles Rich Results Test, nutze danach Screaming Frog für Checks im großen Maßstab.
• Prüfe die Template-Ausgabe nach CMS-Releases. Schema-Bloat entsteht oft durch Entwickler, Plugins oder App-Blocks – nicht durch SEO-Tickets.

Ein praktischer Richtwert: Wenn dein Product-Markup 25+ Eigenschaften umfasst und 4+ verschachtelte Objekt-Ebenen hat, besteht eine gute Chance, dass du auf Vollständigkeit statt auf Suchperformance modellierst.

Der Haken, den die meisten Glossare auslassen

Eine tiefe Verschachtelung ist nicht per se schlecht. Schlechte Implementierungen sind schlecht. Eine saubere 4-Ebenen-Struktur kann problemlos funktionieren, während eine schlampige 2-Ebenen-Struktur die Berechtigung trotzdem verfehlen kann. Außerdem ist Schema-Tiefe kein direkter Ranking-Faktor. Sie wird eine Seite nicht allein von Position 8 auf Position 1 bringen.

Darum ist dieses Konzept weniger als eigenständige Kennzahl wichtig und mehr als Governance-Check. Wenn dein Markup tief, dupliziert und schwer zu testen ist, vereinfache es. Wenn es gültig, stabil und in der GSC treibend für Rich Results ist, flach es nicht nur deshalb zusammen, weil eine Checkliste „max. 3 Ebenen“ sagt.