Was ist Index Bloat?

Index Bloat heißt die Lage, in der Google von einer Website weit mehr URLs indexiert hat, als diese Website braucht. Es ist kein bestimmter Fehler, den man auf einer Seite zeigen könnte, sondern ein Missverhältnis: Der Index füllt sich mit Adressen, die nichts beitragen, und der Inhalt, auf den es ankommt, verdünnt sich darin.

Die Zahl allein sagt nichts. Eine Zeitung mit zweihunderttausend indexierten URLs ist in Ordnung; ein Shop mit dreihundert Produkten und zwanzigtausend nicht. Es zählt nicht, wie viele es sind, sondern welcher Anteil davon jemals gesucht wird.

Und die gegenteilige Vorstellung gehört gleich zu Anfang aus dem Weg geräumt, weil sie sich hält: Mehr indexierte Seiten verbessern von allein gar nichts. Google verteilt Sichtbarkeit nicht nach Menge, und eine indexierte URL, die niemand besucht, ist kein Guthaben, sondern verbrauchtes Crawling.

Der Name kommt aus dem Englischen und beschreibt gut, was geschieht: Etwas schwillt an, ohne an Substanz zu gewinnen. Es gibt keinen Schwellenwert, ab dem es beginnt, und keine Warnung in irgendeinem Werkzeug; erkennbar wird es beim Vergleich zweier Zahlen, die kaum jemand nebeneinanderlegt — die der Seiten, die man zu haben glaubt, und die der URLs, die Google zu haben angibt.

Außerdem gehört es von einem benachbarten Problem getrennt, mit dem es verwechselt wird. Dass eine Seite indexiert ist und keine Besuche bekommt, kann normal sein: Es gibt saisonale Inhalte, rechtliche Seiten, Produktseiten für Seltenes. Index Bloat ist das nicht — es ist der Fall, in dem solche URLs nach Tausenden zählen und keine davon geplant war.

Angelegt hat sie fast nie jemand mit Absicht. Sie entstehen von selbst, erzeugt vom System, das die Website baut, und wachsen deshalb unbemerkt, bis der Abdeckungsbericht eine Zahl zeigt, die nicht zusammenpasst.

Die ergiebigste Quelle sind Varianten: Jeder Filter, jede Sortierung und jeder GET-Parameter erzeugen eine neue Adresse mit demselben Inhalt dahinter. Danach kommen die von Haus aus leeren Seiten mit dünnem Inhalt, und zuletzt die Reste aus Migrationen und Kampagnenseiten, die niemand zurückgezogen hat.

Es lohnt der Blick auf die Verteilung statt auf die Summe, denn das Verhältnis dieser Teile entscheidet, ob ein Problem vorliegt. Zwei Websites mit derselben Zahl können in entgegengesetzter Lage sein, je nachdem, woraus sie besteht.

Eine fünfte Quelle verdient einen eigenen Namen, weil sie überraschend schnell wächst: die Facettennavigation. Lassen sich Marke, Größe, Farbe und Preis frei kombinieren und hat jede Kombination eine URL, wächst die Zahl möglicher Adressen multiplikativ. Ein überschaubarer Katalog erzeugt so hunderttausende URLs, ohne dass ein einziges Produkt hinzukommt.

Und eine stille Quelle, die kaum jemand nachsieht: die Ergebnisseiten der internen Suche. Es genügt, dass jemand eine Suche verlinkt, damit der Crawler sie entdeckt, und von da an ist jede andere Anfrage eine weitere URL — meist mit einem Soft 404 dahinter, wenn es keine Treffer gibt.

Der unmittelbarste Preis ist Crawling. Jede indexierte URL wird von Zeit zu Zeit erneut angefordert, tausende Varianten verbrauchen also Crawl-Budget, das die Seiten nicht erreicht, die sich ändern und oft nachgesehen werden sollten.

Der zweite betrifft die Signale. Zeigen fünf Adressen dasselbe, verteilen sich Verweise und Aufmerksamkeit darauf, statt sich auf einer zu sammeln — genau das Problem, das ein gut gesetztes Canonical löst. Das Ergebnis ähnelt dem von doppeltem Content, denn im Kern ist es dasselbe.

Und der dritte betrifft die Diagnose und wird am meisten unterschätzt: Ein Abdeckungsbericht voller belangloser URLs taugt nicht mehr dazu, echte Probleme zu finden. Taucht ein wirklicher Fehler auf, liegt er begraben unter tausenden Zeilen, die niemand ansieht.

Ein vierter Preis wird außerhalb des SEO gezahlt: im Maschinenraum. Jede Anfrage des Crawlers an eine dieser URLs ist eine Datenbankabfrage und eine erzeugte Seite, und in einem Katalog mit Facetten kann das ein merklicher Teil der Serverlast sein. Der TTFB, den die Besucher erleben, verschlechtert sich durch Anfragen, die von keinem Besucher kommen.

Und noch einer, schwer zu messen und trotzdem wirklich: das Rauschen in den Berichten der Web-Analyse. Bekommen tausende wertlose URLs etwas Restverkehr, verschieben sich die Mittelwerte der ganzen Website, und Entscheidungen auf dieser Grundlage zielen auf die falsche Stelle.

Der Einstieg ist einfach: Vergleiche die Zahl indexierter URLs, die die Search Console meldet, mit der Zahl der Seiten, die es wirklich geben soll. Ist die erste doppelt so hoch, gibt es etwas nachzusehen; ist sie zehnmal so hoch, liegt das Problem offen.

Danach wird nach Mustern gruppiert, bevor irgendetwas entschieden wird. Zwanzigtausend überzählige URLs sind fast nie zwanzigtausend Fälle: Meist sind es drei oder vier falsch gesetzte Regeln, und sie zu korrigieren erledigt die ganze Liste, während Seite für Seite nie endet.

Zum Abbauen gibt es drei Werkzeuge, und sie gehören auseinandergehalten. Das Canonical fasst Varianten desselben Inhalts zusammen; das Noindex nimmt das aus dem Index, was für Nutzer weiter bestehen soll; und die robots.txt verhindert das Crawlen, was nicht dasselbe ist wie Deindexieren. Das falsche zu wählen lässt das Problem, wo es war.

Eine Genauigkeit zur Ausgangszahl: Der Abdeckungsbericht trennt Indexiertes von Ausgeschlossenem, und beide Listen sagen Verschiedenes. Ein Haufen ausgeschlossener URLs ist für sich kein Problem — oft ist es das System bei der Arbeit —, aber der Grund gehört angesehen. „Gecrawlt, zurzeit nicht indexiert“ bei tausenden Adressen ist ein deutliches Zeichen, dass etwas erzeugt wird, das es nicht geben sollte.

Und eine Empfehlung zur Reihenfolge: Bevor Regeln angefasst werden, prüfe in der internen Verlinkung, ob diese URLs von der eigenen Website aus verlinkt sind. Sind sie es, beginnt die Korrektur dort, denn eine Regel, die etwas deindexiert, worauf hunderte Seiten weiter verweisen, ist ein Pflaster auf einer Struktur, die das Problem weiter erzeugt.

Der erste ist der Klassiker dieser Familie: in der robots.txt sperren, was aus dem Index verschwinden soll. Die Sperre verhindert, dass die Anweisung gelesen wird, die URL kann also weiter erscheinen. Zum Deindexieren muss man crawlen lassen.

Der zweite ist das Löschen im Stapel. Viele dieser überzähligen URLs sind für Besucher nützlich, auch wenn sie nicht in den Index gehören: ein Filter nach Größe, eine Sortierung nach Preis. Man nimmt sie aus dem Index, nicht von der Website; sie zu löschen zerlegt die Navigation und erzeugt 404-Fehler für nichts.

Und der dritte ist, sofortige Wirkung zu erwarten. Die Deindexierung geschieht, wenn die Suchmaschine jede URL erneut besucht, und bei selten besuchten Adressen dauert das Wochen. Eine Zahl, die am nächsten Donnerstag nicht gesunken ist, heißt nicht, dass die Korrektur misslungen ist.

Ein vierter Fehler ist, die Zahl zum Ziel zu machen. Von zwanzigtausend indexierten URLs auf zweitausend zu kommen bringt nichts, wenn beim Schnitt Produktseiten mitgingen, die verkauft haben. Bevor eine Regel im Stapel greift, gehört in der Search Console nachgesehen, ob dieses Muster Klicks bekommt; ein paar Stichproben von Hand verhindern, dass genau das aus dem Index fliegt, was funktionierte.

Und der letzte, auf Dauer teuerste: aufräumen, ohne den Hahn zuzudrehen. Erzeugt das System weiter eine URL je Filterkombination, füllt sich der Index in wenigen Monaten erneut, und die Arbeit beginnt von vorn. Die dauerhafte Korrektur liegt in der Entscheidung, welche URLs es geben soll, nicht im Deindexieren derer, die es schon gibt.