BreadcrumbList Schema

Was BreadcrumbList wirklich ist

BreadcrumbList ist der Schema.org-Typ, mit dem eine Seite ihre eigene Position in einer Hierarchie deklariert: eine geordnete Liste von ListItem-Objekten, jedes mit position, name und item. Praktisch heißt das, die Seite erklärt der Maschine den Weg von der Startseite bis zu sich selbst, unabhängig davon, ob dieser Weg im sichtbaren HTML als Navigationselement existiert oder nicht.

Genau in dieser Entkopplung liegt der Denkfehler, den wir in Audits am häufigsten sehen. Viele Teams behandeln das Markup als Dekoration der sichtbaren Brotkrumen-Leiste. Es ist aber umgekehrt: Die sichtbare Leiste ist für Menschen da, das Markup ist eine Aussage gegenüber dem Crawler. Wenn beide auseinanderlaufen, weil die Leiste die Kategorie A zeigt und das JSON-LD die Kategorie B ausgibt, hat man keine doppelte Absicherung, sondern eine widersprüchliche Quelle. Google entscheidet dann selbst, was es glaubt, und meistens ist das die Struktur, die durch interne Links und Canonicals gestützt wird.

Der zweite Punkt, den man beim Einordnen braucht: BreadcrumbList beschreibt keine Beziehung zwischen Dokumenten im Sinne von Linkkraft. Es ist eine Beschreibung, kein Transportmittel. Wer es als billigen Ersatz für eine saubere Verlinkung innerhalb der eigenen Struktur einsetzt, bekommt eine Beschreibung ohne die Substanz, die sie beschreiben soll.

Mechanik und Messung 2026

Die Implementierung ist unspektakulär und sollte es bleiben. In der Praxis liefert man den Typ als JSON-LD-Block im Head aus, mit einer position-Nummerierung, die bei 1 beginnt und lückenlos läuft, und einer item-Angabe, die auf die kanonische URL zeigt. Das letzte Element, also die aktuelle Seite, darf die item-Angabe weglassen. Mikrodaten oder RDFa funktionieren weiter, aber es gibt 2026 kein Argument mehr dafür, sich diese Wartungslast anzutun.

Interessanter ist die Frage, was man daraus messen kann. Der Breadcrumbs-Bericht in der Search Console und der Rich Results Test stehen weiter zur Verfügung, und das ist keine Selbstverständlichkeit: Bei der Ausdünnung vom 12. Juni 2025 hat Google sieben wenig genutzte Rich-Result-Typen eingestellt, darunter Book Actions, Course Info, Claim Review und Vehicle Listing. Die Berichterstattung für die betroffenen Typen endete laut Search Engine Land am 9. September 2025, ab dem 1. Oktober 2025 lieferten die entfallenen Darstellungsfelder in Massenexporten NULL. Am 5. November 2025 folgte die Ankündigung, Practice Problem ab Januar 2026 zu entfernen. Breadcrumbs waren in keiner dieser Wellen dabei. Das ist das eigentliche Signal an Praktiker: Google dünnt aus, behält aber den kleinen Satz robuster, inhaltsnaher Typen, und BreadcrumbList gehört dazu.

Bei der Messung gibt es eine Sperrfrist, die man kennen muss, bevor man einem Kunden eine Vorher-Nachher-Kurve zeigt. Google hat eingeräumt, dass Impressionen in der Search Console vom 13. Mai 2025 bis zum 27. April 2026 ungenau berichtet wurden. Das Problem gilt als behoben, die historischen Daten werden aber nicht rekonstruiert. Jeder Jahresvergleich, der diesen Zeitraum kreuzt, braucht also eine Fußnote. Klicks waren nach Googles Darstellung nicht betroffen, was bedeutet: Wer in diesem Fenster einen Effekt belegen will, argumentiert über Klicks, nicht über Impressionen oder daraus abgeleitete CTR-Werte.

Der Mobile-Schnitt und was davon bleibt

Am 23. Januar 2025 hat Google die Brotkrumen-Pfade weltweit aus den mobilen Suchergebnissen entfernt, weil sie dort wenig nützten und häufig abgeschnitten wurden. Sichtbar bleibt auf Mobil nur noch die Domain, auf Desktop läuft die Pfadanzeige weiter. Das ist die wichtigste Einzelinformation zu diesem Markup, und sie wird in Angeboten und Audit-Berichten immer noch verschwiegen.

Die Konsequenz ist unbequem, aber klar: Der Anzeigenutzen von BreadcrumbList wurde auf das Endgerät reduziert, das in den meisten Verticals die Minderheit der Sitzungen stellt. Die häufig zitierten Zahlen von zwei bis drei Prozentpunkten CTR-Gewinn, fünf Prozent mehr organischem Traffic oder fünf bis zehn Prozent CTR-Verbesserung stammen ohnehin aus Agentur- und Anbieter-Fallstudien und nicht aus einem unabhängig replizierten Experiment. Sie als Branchen-Benchmark zu präsentieren, war schon vor dem Update fahrlässig. Nach dem Update ist es schlicht falsch, weil die Messgrundlage sich verschoben hat.

Was bleibt, ist der strukturelle Teil, und der ist nicht wenig. Das Markup kommuniziert Hierarchie, stützt konsistente Navigation und hilft der Maschine, eine Detailseite einem Themenbereich zuzuordnen. In einer Architektur mit sauberem thematischem Zuschnitt der Rubriken ist BreadcrumbList die maschinenlesbare Bestätigung dessen, was die interne Linkstruktur ohnehin behauptet. Als Ranking-Faktor oder als Ersatz für Backlinks darf es niemandem verkauft werden.

Die KI-Frage lässt sich ebenso nüchtern beantworten. Seit dem 3. Juni 2026 gibt es in der Search Console eigene Performance-Berichte für generative KI-Funktionen, also Sichtbarkeit in AI Overviews, AI Mode und generativen Funktionen in Discover, mit Impressionen und Dimensionen wie Seiten, Ländern, Geräten und Datum. Das ist ein Messinstrument, kein Kausalitätsbeweis. Googles eigener Leitfaden zur Optimierung für generative KI-Funktionen sagt ausdrücklich, dass strukturierte Daten für die Aufnahme in die generative Suche nicht erforderlich sind. Eine Anbieter-Auswertung von 5.000 Produktivseiten, veröffentlicht am 26. April 2026, berichtet zwar eine Korrelation von +0,34 zwischen validem Schema und KI-Zitierrate sowie eine um 47 Prozent höhere Zitierfrequenz in AI Overviews für redaktionelle Seiten mit validem Article- plus BreadcrumbList-Markup gegenüber der genannten Vergleichsgruppe ohne Schema. Das ist eine Beobachtungsstudie eines Anbieters, die BreadcrumbList mit Article-Auszeichnung und Validierungsstatus vermischt. Als Hypothese brauchbar, als Kausalaussage nicht.

Wo es in einer Netlinking-Operation zählt

In der Linkarbeit ist BreadcrumbList selten der Punkt, an dem eine Kampagne gewinnt oder verliert. Es zählt an zwei Stellen, und die sind operativ.

Erstens bei der Bewertung von Zielmedien. Wenn man prüft, ob ein Medium einen Artikel überhaupt strukturell tragen kann, sagt ein sauberes Brotkrumen-Markup mehr über die redaktionelle Hygiene aus als jede Autoritätskennzahl. Ein Medium, dessen Kategorieseiten im Markup andere Pfade behaupten als in der Navigation, hat in der Regel auch bei Canonicals, Paginierung und Kategoriearchitektur Baustellen. Bei uns im Eigenbetrieb, über den gesamten Bestand der Redaktionsmedien hinweg, ist das Markup deshalb Teil der Deploy-Prüfung und nicht ein nachträglicher SEO-Zusatz: Wer den Bestand nachträglich sanieren muss, zahlt ein Vielfaches. Wer die technische Grundlage der Medien vor einer Platzierung sehen will, findet sie im öffentlich einsehbaren Medienkatalog, ohne Registrierung.

Zweitens bei der Ablage von gekauften oder redaktionell gesetzten Beiträgen. Ein Artikel, der in einer Rubrik landet, die thematisch nicht zum Zielanker passt, wird durch das Markup in dieser falschen Zuordnung zusätzlich verfestigt. Das Markup ist hier ein Verstärker: Es macht die Ablageentscheidung explizit und maschinenlesbar. Für die redaktionelle Praxis heißt das, die Rubrikwahl vor der Veröffentlichung zu treffen und nicht danach.

Was wir in Audits regelmäßig kaputt sehen

Der mit Abstand häufigste Fehler ist die Lücke zwischen Ausspielung und Gültigkeit. Die bereits genannte Auswertung von 5.000 Produktivseiten vom 26. April 2026 beziffert BreadcrumbList-Präsenz mit 38 Prozent der Seiten, nur 8 Prozent setzen fünf oder mehr Schema-Typen korrekt um, und sie misst eine Lücke von 49 Prozentpunkten zwischen Ausspielung und Validierung. Das deckt sich mit dem, was wir aus eigener Audit-Erfahrung sehen: Markup ist fast immer irgendwie vorhanden, es ist nur oft nicht korrekt.

Die konkreten Muster wiederholen sich. Positionen, die bei 0 anfangen oder Lücken haben. Relative statt absoluter URLs in item, was der Validator toleriert und Google trotzdem uneindeutig lässt. Der Name des letzten Elements, der nicht dem H1 der Seite entspricht, weil er aus dem Title-Tag samt Markensuffix generiert wird. Paginierte Archive, die auf Seite 4 denselben Pfad ausgeben wie auf Seite 1, was für sich genommen tolerierbar ist, aber im Zusammenspiel mit fehlerhaften Canonicals zu einer Kategorie führt, die sich selbst kannibalisiert. Und die Klassiker aus der WordPress-Welt, in denen zwei Plugins gleichzeitig BreadcrumbList ausgeben und die Seite zwei widersprüchliche Graphen liefert.

Die zweite Fehlerklasse ist prozessual: Niemand prüft das Markup nach einem Theme- oder Template-Wechsel. Strukturierte Daten sind eine Ausgabe der Templates, nicht des Inhalts, und Template-Änderungen sind genau die Ereignisse, bei denen sie still verschwinden. Ein Crawl im Quartal reicht, um das zu erwischen. Der Screaming Frog SEO Spider, für den 2026 rund 259 US-Dollar pro Jahr berichtet werden, extrahiert JSON-LD im Bestand und beantwortet die Frage in einer Stunde. Wer solche wiederkehrenden Werkzeugkosten gegen die laufenden Kosten einer Sichtbarkeitsstrategie stellen will, findet unsere Konditionen offen ausgewiesen, ohne versteckte Provision.

Taktisches für die Umsetzung

Der pragmatische Umgang mit BreadcrumbList 2026 sieht so aus: implementieren, validieren, danach in Ruhe lassen und nur bei Template-Änderungen erneut prüfen. Es ist eine Hygiene-Maßnahme mit geringen Kosten und geringem, aber realem Nutzen, kein Projekt, das ein eigenes Budget verdient.

Drei Regeln, die in der Praxis den Unterschied machen. Die Pfadtiefe an der tatsächlichen Struktur ausrichten und nicht künstlich verlängern, um Keywords unterzubringen: Eine Ebene, die es in der Navigation nicht gibt, ist eine Behauptung, die nichts stützt. Die Namen der Elemente exakt aus den Kategorienamen ziehen, die auch im sichtbaren HTML und in den internen Ankertexten stehen. Und bei mehrsprachigen Setups die Pfade pro Sprachversion lokalisieren, statt die Ausgangssprache durchzureichen, sonst widerspricht das Markup den hreflang-Angaben.

Was man nicht tun sollte: BreadcrumbList in ein Angebot schreiben, in dem es als Sichtbarkeits- oder KI-Hebel firmiert. Die Anzeige ist auf Desktop beschränkt, die CTR-Zahlen sind Fallstudien, und für generative Ergebnisse sagt Google selbst, dass kein spezielles Markup nötig ist. Ehrlicher und in der Sache stärker ist die Formulierung, die stimmt: Es macht die Architektur maschinenlesbar, und eine Architektur, die die Maschine versteht, verwertet eingehende Links besser.