Crawl-Fallen im SEO: Wenn der Bot nie ankommt

Eine Crawl-Falle ist kein klassischer Fehler: Die Seiten laden, der Server antwortet mit Status 200, technisch ist alles sauber. Das Problem ist die Menge. Ein einzelner Bereich der Website erzeugt eine praktisch unbegrenzte Zahl neuer URLs, und jede dieser URLs verweist wieder auf weitere URLs. Ein Kalender-Widget mit endlosem „nächster Monat“-Link, ein Filter, der sich mit jedem zusätzlichen Parameter selbst vervielfacht, oder ein relativer Link, der sich in seinen eigenen Unterordner verlinkt – all das sind Räume, aus denen ein Crawler nie wieder herausfindet, weil es dort schlicht kein natürliches Ende gibt.

Für Google und jeden anderen Bot ist das keine Verwirrung, sondern reine Erschöpfung: Er folgt Links, solange sein Budget für die Domain reicht, und wenn dieses Budget in einer Endlosschleife verbrennt, bleibt für die eigentlichen Produktseiten, Artikel oder Kategorien nichts mehr übrig. Crawl-Fallen sind deshalb kein Problem, das nur riesige Websites betrifft – sie entstehen aus gewöhnlichen Komfortfunktionen, die niemand absichtlich als Falle gebaut hat.

Warum eine Crawl-Falle sich von einem normalen Crawling-Fehler unterscheidet

Ein defekter Link, ein 404 oder ein 500er-Fehler ist für einen Crawler ein klares Signal: Hier gibt es nichts zu holen, weiter geht's. Genau deshalb sind diese Fälle vergleichsweise harmlos – der Bot merkt sich das Muster und reduziert seinen Aufwand für diesen Bereich von selbst.

Eine Crawl-Falle liefert dagegen bei jeder einzelnen Anfrage eine gültige Antwort. Die Seite existiert, der Inhalt lädt, der Statuscode ist einwandfrei. Es gibt kein Fehlersignal, an dem der Crawler erkennen könnte, dass er sich in einer Schleife oder einem endlosen Raum befindet – aus seiner Sicht sieht jede neue URL wie eine weitere, potenziell wertvolle Seite aus. Genau diese Unauffälligkeit macht Crawl-Fallen so hartnäckig: Niemand bekommt eine Fehlermeldung, die zum Handeln zwingt.

Die klassischen Generatoren von Crawl-Fallen

Fast jede Crawl-Falle lässt sich auf eine Handvoll wiederkehrender Muster zurückführen. Sie wirken auf den ersten Blick harmlos, weil sie in der Regel als Komfortfunktion für menschliche Nutzer gebaut wurden – nicht als Hindernis für Bots gedacht:

• Kalender ohne Enddatum: Ein Buchungs- oder Veranstaltungskalender, der für jeden Monat eine eigene URL erzeugt und stets einen Link auf den folgenden Monat setzt, kennt kein Ende. Der Crawler kann Jahr für Jahr in die Zukunft klicken, ohne dass dort jemals neuer Inhalt auftaucht.
• Filter- und Sortier-Kombinationen: Sobald sich Farbe, Größe, Preisspanne und Sortierung frei miteinander kombinieren lassen, wächst die Zahl möglicher URLs multiplikativ. Schon fünf Filter mit je vier Werten ergeben rechnerisch über tausend Kombinationen für eine einzige Kategorie.
• Facettennavigation ohne Obergrenze: Wenn jede Facette – Marke, Material, Bewertung, Verfügbarkeit – frei mit jeder anderen kombinierbar ist und jede Kombination eine eigene, intern verlinkte URL erhält, wächst der URL-Raum mit jedem neuen Attribut im Katalog automatisch weiter, ohne dass irgendwer bewusst eine Grenze gezogen hat.
• Session-IDs in der URL: Wird eine Sitzungskennung als URL-Parameter statt als Cookie übergeben, erzeugt jeder einzelne Bot-Besuch eine scheinbar neue, eindeutige URL für exakt dieselbe Seite. Der Crawler erkennt kein Duplikat – er sieht eine echte neue Adresse.
• Fehlerhafte relative Links: Ein falsch gesetzter relativer Link kann einen Pfad an sich selbst anhängen, statt ihn zu ersetzen. Aus /a/b/ wird /a/b/a/b/, daraus wird /a/b/a/b/a/b/ – und so weiter, endlos verschachtelt. Jede Ebene ist eine technisch gültige, neue URL, die wieder auf die nächste Ebene verweist. Hier hat niemand eine Obergrenze vergessen, die Struktur selbst ist defekt.
• Suchergebnisseiten, die auf weitere Suchergebnisseiten verlinken: Die interne Suche erzeugt für jede Anfrage eine eigene URL. Verlinken diese Ergebnisseiten wiederum verwandte Suchen oder „ähnliche Anfragen“, wandert der Crawler von Suche zu Suche, ohne je bei redaktionellem Inhalt anzukommen.
• Paginierung ohne echtes Ende: Eine Liste, die technisch immer eine weitere Seite anbietet, selbst wenn dort längst keine Ergebnisse mehr stehen, führt in dieselbe Leere – ein Sonderfall des gleichen Grundproblems.

Ein Beispiel, wie so eine Falle in der Praxis entsteht

Manche dieser Muster, etwa Paginierung oder URL-Parameter, verdienen wegen ihrer eigenen Regeln eine gesonderte Betrachtung; hier zählt vor allem, wie aus einem einzigen übersehenen Element ein URL-Raum entsteht, der die Website um Größenordnungen übersteigt. Nimm einen Online-Shop mit einer internen Terminbuchung für Beratungsgespräche. Die Kalenderansicht zeigt jeweils einen Monat und verlinkt oben rechts auf „nächster Monat“. Niemand hat dabei über ein Enddatum nachgedacht – wozu auch, ein menschlicher Nutzer klickt vielleicht zwei, drei Monate voraus und bucht dann einen Termin. Ein Crawler klickt nicht so. Er folgt dem Link systematisch, Monat für Monat, und findet auf jeder dieser Seiten wieder denselben Link zum nächsten Monat. Nach wenigen hundert Schritten liegt der Crawler rechnerisch Jahrzehnte in der Zukunft, ohne dass sich der Inhalt der Seite auch nur ein einziges Mal verändert hätte.

Kombiniert dieser Kalender zusätzlich noch einen Filter, etwa „nur verfügbare Termine“ oder „nach Berater sortieren“, multipliziert sich der Kalender-URL-Raum mit jeder Filterkombination erneut. Aus einem einzelnen, übersehenen „nächster Monat“-Link wird so, ohne dass irgendwo bewusst Code dafür geschrieben wurde, ein URL-Raum, der die eigentliche Website um ein Vielfaches übersteigt – und der bei jeder neuen Filteroption weiter wächst, ohne dass jemand das als Entscheidung getroffen hätte.

Der Schaden: Wohin das Crawl-Budget wirklich verschwindet

Crawl-Budget ist keine feste Zahl, aber es ist endlich: Es ergibt sich aus der Kapazität, die ein Server für Bot-Anfragen verträgt, und aus der Einschätzung des Crawlers, wie lohnend weiteres Crawlen dieser Domain ist. Jede Anfrage, die in eine Crawl-Falle fließt, ist eine Anfrage, die nicht in eine reale Produktseite, einen Artikel oder eine Kategorie geflossen ist. Bei einer großen Website mit Millionen Kalender- oder Filter-URLs kann das bedeuten, dass neue oder aktualisierte Inhalte tagelang gar nicht erst entdeckt werden.

Der zweite Schaden ist Indexblähung. Nicht jede Trap-URL wird indexiert, aber ein Teil davon meistens schon – vor allem, wenn die generierten Seiten technisch einzigartigen Inhalt zeigen, etwa eine leicht andere Filterkombination. Das Ergebnis sind tausende dünne, nahezu identische Seiten im Index, die die wahrgenommene Gesamtqualität der Domain aus Sicht der Suchmaschine senken – ein Effekt, der auch auf gute Seiten derselben Domain zurückwirkt.

Drittens verwässert sich die interne Verlinkung. Interne Links verteilen Relevanzsignale durch die Website; wenn ein erheblicher Teil aller internen Links auf Kalender-, Filter- oder Session-URLs zeigt, teilt sich dieses Signal auf eine praktisch unbegrenzte Zahl von Zielen auf, statt sich auf die Seiten zu konzentrieren, die tatsächlich ranken sollen.

Wie man eine Crawl-Falle überhaupt findet

Crawl-Fallen sind unsichtbar, solange man nur die eigene Sitemap oder die Hauptnavigation betrachtet – dort tauchen sie selten auf. Sichtbar werden sie erst, wenn man sich ansieht, wo der Crawler tatsächlich war, nicht wo er hätte hingehen sollen. Am aussagekräftigsten ist dabei die Kombination mehrerer Quellen, nicht eine einzelne Kennzahl:

• Logfile-Analyse: Die Rohlogs des Servers, gefiltert auf bestätigte Bot-User-Agents, zeigen jede einzelne Anfrage. Aggregiert man diese nach URL-Pfad oder -Muster, fällt jeder Bereich auf, der einen unverhältnismäßig hohen Anteil der Bot-Anfragen bindet, gemessen an der Zahl seiner tatsächlich relevanten Seiten.
• Crawl-Tiefe-Reports, die nie terminieren: Lässt man einen eigenen Crawler mit hohem URL- oder Tiefenlimit über die Website laufen und der Lauf erreicht dieses Limit, statt von selbst zu enden, ist das ein starkes Warnsignal – besonders in Kombination mit URLs, die sich wiederholende Pfadsegmente zeigen.
• Plötzliches Wachstum der indexierten URL-Zahl: Springt die Anzahl indexierter oder gecrawlter, aber nicht indexierter Seiten in der Search Console um mehrere tausend, ohne dass ein entsprechender Content-Launch stattgefunden hat, lohnt sich ein Blick auf die neu aufgetauchten URL-Muster. Die Logs zeigen dabei, wo der Bot seine Zeit verbringt, der Crawl-Report zeigt die Struktur dahinter, und die Indexzahlen zeigen, welcher Teil davon tatsächlich im Index landet – erst zusammen ergeben die drei Quellen ein verlässliches Bild.

Die Werkzeuge zum Stopfen – und ihre Kompromisse

Für jede Crawl-Falle gibt es mehrere mögliche Werkzeuge, aber keines davon ist in jeder Situation die richtige Wahl. Wer das falsche Werkzeug für das falsche Muster einsetzt, löst das eigentliche Problem nicht, sondern verschiebt es nur.

• robots.txt-Sperre für das gesamte Muster: Schnell umgesetzt und wirksam gegen weiteres Crawling des Pfads. Der Kompromiss: Google kann gesperrte URLs nicht mehr besuchen, um zu prüfen, ob sie noch existieren oder sich geändert haben – und, wie im nächsten Abschnitt beschrieben, kann eine bereits indexierte URL dadurch nicht mehr entfernt werden.
• Nofollow auf den erzeugenden Links: Reduziert die Wahrscheinlichkeit, dass der Crawler die Falle über die Navigation überhaupt entdeckt, und verlangsamt den internen Linkfluss in ihre Richtung. Der Kompromiss: Moderne Crawler behandeln nofollow als Hinweis, nicht als verbindliche Anweisung – und ein einziger Link ohne dieses Attribut irgendwo auf der Website öffnet die Falle wieder.
• Canonical-Tag auf die echte Zielseite: Sinnvoll, wenn die generierten Seiten tatsächlich nahezu identisch mit einer bereits existierenden Seite sind, etwa eine Sortier-Variante derselben Kategorie. Der Kompromiss: Google muss die Duplikat-URL trotzdem erst crawlen, um das Canonical-Tag überhaupt zu sehen – Crawl-Budget spart das Verfahren also nicht, es bündelt nur die Rankingsignale nachträglich.
• Die zugrunde liegende URL-Erzeugung reparieren: Der Kalender bekommt einen Horizont von etwa zwölf oder vierundzwanzig Monaten und danach keinen weiteren „nächster Monat“-Link mehr. Filterlinks werden nur für Kombinationen erzeugt, die tatsächlich Treffer liefern. Relative Links werden durch korrekte absolute Pfade ersetzt. Session-IDs wandern aus der URL ins Cookie. Paginierung und interne Suche bekommen einen echten Endzustand ohne weiteren „weiter“-Link. Das ist der einzige Fix, der die Ursache beseitigt statt nur ihre Symptome zu verwalten – alle anderen Werkzeuge sind Schadensbegrenzung, keine Heilung.

Der Punkt, den viele übersehen: robots.txt entfernt nichts aus dem Index

Eine Sperre in der robots.txt verhindert künftiges Crawling – sie entfernt aber keine einzige bereits indexierte URL. Das liegt am Mechanismus selbst: Um eine URL aus dem Index zu nehmen, muss Google sie erneut besuchen und dort ein noindex, einen 404 oder ein anderes Entfernungssignal vorfinden. Genau diesen erneuten Besuch verbietet die robots.txt-Sperre. In der Search Console zeigt sich das häufig als „indexiert, obwohl durch robots.txt blockiert“ – die URL bleibt im Index, weil Google sie nicht mehr prüfen darf, nicht weil sie noch relevant wäre.

Um bereits indexierte Trap-URLs tatsächlich zu entfernen, braucht es ein anderes Werkzeug: das Crawling für diese URLs vorübergehend wieder zulassen und stattdessen ein noindex ausliefern, oder einen echten 404 beziehungsweise 410, bis Google beim nächsten Besuch die Entfernung erkennt und die Seite fallen lässt. Für dringende Fälle beschleunigt das URL-Entfernungstool der Search Console diesen Vorgang temporär, allerdings nur vorübergehend – die endgültige Entfernung erfordert weiterhin den erneuten Besuch mit dem echten Signal. Erst wenn diese Bereinigung abgeschlossen ist, ergibt eine robots.txt-Sperre wieder Sinn: jetzt als Schutz gegen künftige Crawl-Verschwendung, nicht als Werkzeug zur Index-Bereinigung.