Facettennavigation ist im E-Commerce unverzichtbar und gleichzeitig der größte Einzelverursacher von Crawling-Problemen: Rund 50% aller Crawling-Probleme gehen auf Facettennavigation zurück, zusammen mit Action-Parametern sind es rund 75% (Google Search Central). Der Grund ist Kombinatorik. Aus einem Katalog mit ein paar tausend Produkten entstehen durch Filter, Sortierung und Paginierung Millionen theoretisch aufrufbarer URLs. Dieser Artikel liefert eine Entscheidungsmatrix statt Bauchgefühl: welche Facetten eine indexierbare Landingpage mit eigener Suchnachfrage verdienen, welche komplett aus dem Crawl gehören, und warum robots.txt-Disallow und noindex in der Suchmaschinenoptimierung nicht austauschbar sind.
Wie aus 5.000 Produkten Millionen Filter-URLs werden
Facettennavigation bedeutet: Nutzer grenzen ein Sortiment über mehrere unabhängige Dimensionen ein - Marke, Farbe, Größe, Preisspanne, Bewertung, Verfügbarkeit - und bestimmen zusätzlich Sortierung, Ansicht und Seitengröße. Für die Nutzerführung ist das ein Gewinn, und ohne diese Filter wäre ein großer Katalog praktisch unbedienbar. Für Suchmaschinen entsteht daraus ein Problem, das sich nicht linear, sondern multiplikativ verhält: Jede Kombination erzeugt in der Regel eine eigene, abrufbare URL.
Ein realistisches Rechenbeispiel: Ein Shop führt 5.000 Produkte in 120 Kategorien. Angeboten werden Filter für 40 Marken, 12 Farben und 8 Größen sowie 5 Sortierungen. Allein diese Dimensionen ergeben rechnerisch 2,3 Millionen URL-Varianten. Kommt eine Paginierung mit durchschnittlich zehn Seiten je Ergebnisliste hinzu, sind es rund 23 Millionen URLs - aus einem Katalog, der 5.000 Produkte enthält. Das Verhältnis von nützlichen zu nutzlosen URLs kippt damit ins Absurde.
Das bedeutet häufig eine sehr große Zahl möglicher Filterkombinationen, was sich in einer sehr großen Zahl möglicher URLs niederschlägt.
Google Search Central, Managing crawling of faceted navigation URLs
Entscheidend ist der zweite Teil der Mechanik: Ein Crawler kann einer neuen URL nicht ansehen, ob sie nützlich ist. Er muss sie abrufen, um das zu entscheiden. Google beschreibt genau diesen Effekt: Weil die Filter-URLs neuartig wirken, greifen Crawler typischerweise auf eine sehr große Zahl von Facetten-URLs zu, bevor die nachgelagerten Prozesse feststellen, dass diese URLs tatsächlich nutzlos sind (Google Search Central). Die Verschwendung passiert also, bevor irgendeine Bewertung greifen kann.
Sobald ein Crawler eine Menge von URLs entdeckt hat, kann er nicht entscheiden, ob dieser URL-Raum gut ist oder nicht, ohne einen großen Teil dieses URL-Raums gecrawlt zu haben.
Illyes, Google-Analyst, Search Off the Record (Google Search Central)
Ein verbreiteter Irrtum lautet: Crawl-Budget sei nur ein Thema für Marktplätze mit Millionen Artikeln. Die Kombinatorik funktioniert aber unabhängig von der Katalogtiefe. Ein Shop mit 800 Produkten und sechs Filterdimensionen erzeugt problemlos sechsstellige URL-Mengen. Relevant ist nicht die Anzahl der Produkte, sondern die Anzahl der erreichbaren URL-Varianten - und die hängt an der Facettenlogik, nicht am Sortiment. Wie stark Filter und Suche ineinandergreifen, zeigt der Beitrag zur Suchrelevanz im Shop und OpenSearch-Tuning.
Warum Google Facetten als größten Crawl-Verursacher benennt
Google hat die Ursachen von Crawling-Problemen quantifiziert und im Jahresrückblick zum Crawling für 2025 aufgeschlüsselt. Das Ergebnis ist eindeutig: Facettennavigation ist mit Abstand der größte Einzelposten, und zusammen mit Action-Parametern deckt sie rund drei Viertel aller gemeldeten Probleme ab (Google Search Central).
| Ursache von Crawling-Problemen | Anteil (Google Search Central) |
|---|---|
| Facettennavigation | 50% |
| Action-Parameter (Warenkorb, Sortierung, Druckansicht) | 25% |
| Irrelevante Parameter | 10% |
| Plugins und Widgets | 5% |
| Sonstige Ursachen | 2% |
Zwei Größen bestimmen laut Google, wie viel gecrawlt wird: das Crawl-Kapazitätslimit - die maximale Zahl paralleler Verbindungen plus die Wartezeit zwischen Abrufen - und die Crawl-Nachfrage, die sich aus Größe, Aktualisierungsfrequenz, Seitenqualität und Relevanz einer Website ergibt (Google Search Central). Beide Größen sind endlich. Was in Filter-Kombinationen fließt, fehlt bei neuen Produkten, aktualisierten Preisen und überarbeiteten Kategorietexten.
Google nennt konkrete Schwellen, ab denen sich aktives Crawl-Budget-Management lohnt: große Websites ab rund 1 Million einzigartiger Seiten mit wöchentlich wechselnden Inhalten sowie mittlere und größere Websites ab rund 10.000 einzigartigen Seiten mit täglich wechselnden Inhalten (Google Search Central). Als drittes Signal nennt Google einen hohen Anteil an URLs mit dem Status Gefunden - zurzeit nicht indexiert in der Search Console (Google Search Central). Genau dieser Statuswert ist in der Praxis der zuverlässigste Frühindikator: Er zeigt, dass Google URLs kennt, ihnen aber keine Abrufe mehr widmet. Wie sich solche Signale systematisch auswerten lassen, beschreibt unser SEO-Audit-Leitfaden für Online-Shops.
Die Entscheidungsmatrix: Welche Facette verdient eine Landingpage
Die häufigste Fehlentscheidung ist eine pauschale: entweder alles indexieren lassen oder alles sperren. Beides verschenkt Potenzial. Manche Facetten decken echte, eigenständige Suchnachfrage ab und verdienen eine indexierbare Landingpage. Die große Mehrheit deckt keine ab und gehört aus dem Crawl. Die Zuordnung sollte nicht nach Bauchgefühl erfolgen, sondern nach drei prüfbaren Kriterien.
Eigene Suchnachfrage
Wird die Kombination tatsächlich gesucht? Laufschuhe Marke X ja, Laufschuhe schwarz Größe 44 sortiert nach Preis nein. Belege liefern Keyword-Daten und die Auswertung der internen Shop-Suche.
Ausreichende Sortimentstiefe
Eine Landingpage braucht stabile Ergebnisse. Als Richtwert arbeiten wir mit einem Mindestbestand an Produkten je Facette und einem Sortiment, das nicht wöchentlich auf null fällt (Projekterfahrung).
Eigenständiger Inhalt
Gibt es über die gefilterte Liste hinaus etwas zu sagen - Einleitung, Beratung, FAQ? Ohne das bleibt die Seite eine Dublette. Der Weg dorthin ist in Programmatic SEO für Kategorie-Seiten beschrieben.
Angewendet auf typische Shop-Facetten ergibt sich daraus eine belastbare Matrix. Sie ist ein Ausgangspunkt, kein Dogma: In einem Modeshop kann Farbe durchaus Nachfrage haben (schwarzes Abendkleid), in einem Ersatzteilshop dagegen kaum.
| Facette | Eigene Suchnachfrage | Empfehlung |
|---|---|---|
| Kategorie (Pfad-URL) | Hoch | Indexieren, in der Navigation verlinken |
| Marke innerhalb Kategorie | Hoch | Indexierbare Landingpage als Pfad-URL |
| Größe / Passform | Mittel | Selektiv indexieren, nur bei belegter Nachfrage |
| Farbe | Branchenabhängig | Selektiv, im Zweifel Disallow |
| Preisspanne | Gering | Disallow |
| Bewertung / Verfügbarkeit | Keine | Disallow |
| Sale- und Rabattfilter | Gering | Disallow, Aktionen über redaktionelle Seiten |
| Zwei oder mehr Facetten kombiniert | Keine | Disallow |
| Sortierung / Ansicht / Seitengröße | Keine | Disallow (Action-Parameter) |
Der Sale-Filter verdient eine Zusatzbemerkung: Rabatt-Facetten sind nicht nur SEO-seitig unattraktiv, weil sie täglich andere Ergebnisse liefern - sie sind auch rechtlich heikel, wenn Preisreduktionen unsauber ausgewiesen werden. Welche Anforderungen dabei gelten, ordnet der Beitrag zu Streichpreisen und Rabattwerbung nach PAngV ein. Aktionen gehören auf gepflegte redaktionelle Seiten, nicht in einen Filterparameter.
Wenn eine Facette eine Landingpage verdient, sollte sie eine sprechende Pfad-URL bekommen: /laufschuhe/marke-x/ statt /laufschuhe/?marke=marke-x. Das hat drei Vorteile: Die Seite ist von Parameter-Disallow-Regeln in der robots.txt nicht betroffen, sie lässt sich sauber intern verlinken, und sie signalisiert Eigenständigkeit statt Filterzustand. Die Parameter-Variante bleibt für alles andere reserviert.
Für Filterkombinationen ohne Treffer empfiehlt Google ausdrücklich den HTTP-Status 404 statt einer Weiterleitung oder einer 200er-Seite mit Nulltreffer-Text (Google Search Central). Das ist kontraintuitiv, aber wirksam: Ein 404 signalisiert dem Crawler, dass dieser Ast des URL-Raums nichts hergibt. Eine 200er-Seite ohne Ergebnisse sagt ihm das Gegenteil - und lädt zum Weitercrawlen ein.
robots.txt oder noindex: warum das kein Entweder-oder ist
Hier liegt der teuerste Denkfehler im Umgang mit Facetten. robots.txt-Disallow und noindex werden oft als zwei Wege zum gleichen Ziel behandelt. Sie wirken aber an unterschiedlichen Stellen der Verarbeitungskette. Disallow verhindert das Crawling. Noindex verhindert die Indexierung - setzt aber voraus, dass die Seite zuvor abgerufen wurde. Genau das macht noindex für Crawl-Budget wertlos.
Verwenden Sie kein noindex, da Google die Seite trotzdem anfordert und sie erst dann verwirft, wenn es das noindex-Meta-Tag sieht.
Google Search Central, Crawl-Budget-Management für große Websites
Umgekehrt gilt: Ein Disallow ist kein Indexierungsverbot. Google formuliert das in der robots.txt-Spezifikation unmissverständlich - der Inhalt einer gesperrten Seite kann nicht indexiert werden, die URL selbst kann aber weiterhin indexiert und ohne Snippet in den Suchergebnissen angezeigt werden (Google Search Central). Wer beide Werkzeuge verwechselt, erzeugt genau das Ergebnis, das er vermeiden wollte.
| Maßnahme | Crawling | Indexierung | Spart Crawl-Budget |
|---|---|---|---|
| robots.txt-Disallow | Blockiert | URL kann ohne Snippet erscheinen | Ja |
| noindex (Meta-Tag) | Erlaubt und nötig | Verhindert | Nein |
| rel=canonical | Erlaubt | Signal, keine Anweisung | Langfristig kaum |
| rel=nofollow | Reduziert Entdeckung | Kein Indexierungssignal | Nur teilweise |
| Facette gar nicht verlinken | Keine Entdeckung | Keine | Ja |
Die Kombination ist ein Selbstwiderspruch: Wenn die robots.txt das Crawling verbietet, bekommt Google das noindex im Quelltext nicht zu sehen - die Anweisung bleibt wirkungslos. Für bereits indexierte Filter-URLs gilt daher eine Reihenfolge: erst noindex ausliefern und crawlen lassen, bis die URLs aus dem Index verschwinden, danach das Disallow in der robots.txt setzen. Wer beides gleichzeitig scharf schaltet, friert den Ist-Zustand ein.
Für die Sperrung selbst reicht ein kompaktes Regelwerk. Google unterstützt in robots.txt die Wildcard * für beliebige Zeichenfolgen und $ für das URL-Ende; die Datei wird bis zu einer Größe von 500 KiB ausgewertet, darüber hinausgehender Inhalt wird ignoriert, und Google cacht sie in der Regel bis zu 24 Stunden (Google Search Central). Änderungen wirken also nicht sofort - das ist bei Rollouts einzuplanen.
user-agent: *
# Filter-Facetten ohne eigene Suchnachfrage: nicht crawlen
disallow: /*?*farbe=
disallow: /*?*groesse=
disallow: /*?*preis=
disallow: /*?*bewertung=
# Reine Darstellungsparameter (Sortierung, Ansicht, Seitengröße)
disallow: /*?*sort=
disallow: /*?*view=
disallow: /*?*limit=
# Action-Parameter: nicht für Crawler gedacht
disallow: /*?*add-to-cart=
disallow: /*?*merkliste=
disallow: /*?*vergleich=
disallow: /*?*print=
# Indexierbare Facetten laufen über Pfad-URLs und bleiben crawlbar:
# /laufschuhe/marke-x/ ist von keiner Regel oben betroffenSaubere Parameter-Konventionen statt gewachsenem Chaos
Wenn Filter-URLs crawlbar bleiben sollen, müssen sie maschinenlesbar sein. Google nennt dazu eine klare Konvention: Als Trennzeichen ist das kaufmännische Und zu verwenden. Zeichen wie Komma, Semikolon und eckige Klammern sind für Crawler schwer als Parametertrenner zu erkennen (Google Search Central). Wer eigene Filter-Serialisierungen erfindet, erschwert genau die Analyse, auf die er angewiesen ist - und macht zugleich robots.txt-Regeln unpräzise, weil sie an Parameternamen ansetzen.
# Empfohlen: Standard-Trennzeichen, stabile Reihenfolge, ein Parameter je Facette
https://beispiel.de/laufschuhe/?marke=marke-x&farbe=schwarz&groesse=44
# Problematisch: Komma, Semikolon oder Klammern als Trennzeichen
https://beispiel.de/laufschuhe/?filter=marke-x,schwarz,44
https://beispiel.de/laufschuhe/?filter[marke]=marke-x;farbe=schwarz
# Problematisch: Fragment statt Parameter - wird nicht gecrawlt
https://beispiel.de/laufschuhe/#marke=marke-x&farbe=schwarz
# Problematisch: wechselnde Reihenfolge erzeugt Dubletten derselben Auswahl
https://beispiel.de/laufschuhe/?farbe=schwarz&marke=marke-xDer letzte Fall ist der unterschätzte: Wenn dieselbe Filterauswahl je nach Klickreihenfolge unterschiedliche URLs erzeugt, vervielfacht sich der URL-Raum ein weiteres Mal - ohne jeden Nutzen. Ein Punkt verdient besondere Beachtung: URL-Fragmente hinter # werden von der Google-Suche beim Crawling und Indexieren in der Regel nicht unterstützt (Google Search Central). Als Versteck für Filter taugen sie, als Träger indexierbarer Zustände nicht.
- Ein Parameter je Facette, keine verschachtelten Sammelparameter
- Feste, logische Reihenfolge der Parameter - serverseitig normalisiert
- Konsistente Klein-/Großschreibung und stabile Kodierung der Werte
- Keine Session-IDs, Tracking- oder Zufallswerte in crawlbaren URLs
- Standardwerte weglassen statt mitschreiben (
?sort=standarderzeugt eine Dublette) - Parameternamen sprechend halten, damit
robots.txt-Regeln präzise greifen
In der Praxis ist die serverseitige Normalisierung der wirksamste Einzelhebel: Der Shop sortiert Parameter in eine feste Reihenfolge, entfernt Standardwerte und leitet abweichende Schreibweisen per 301 auf die kanonische Form. Damit schrumpft der URL-Raum, bevor irgendein Crawler ihn sieht. In Shopware-Projekten setzen wir das üblicherweise in der Routing- und Listing-Schicht um - mehr dazu auf unserer Seite zur Shopware-Entwicklung.
Canonicals ohne Selbstwiderspruch
Das rel=canonical-Element ist beliebt, weil es sich anfühlt wie eine Lösung. Es ist aber ein Hinweis, keine Anweisung - und es löst das Crawl-Problem nicht, sondern höchstens das Dubletten-Problem. Google stuft Canonical und rel=nofollow als Mittel zur Crawl-Steuerung ausdrücklich als langfristig weniger wirksam ein als das Blockieren des Crawlings (Google Search Central). Ein Canonical wirkt erst, nachdem die Seite abgerufen wurde - das Budget ist zu diesem Zeitpunkt bereits ausgegeben.
- Selbstreferenzierend auf indexierbaren Seiten: Jede Landingpage, die ranken soll, zeigt per Canonical auf sich selbst - nicht auf die übergeordnete Kategorie.
- Paginierung kanonisiert sich selbst: Seite 2 einer Liste zeigt auf Seite 2, nicht auf Seite 1. Ein Canonical von Seite 2 auf Seite 1 erklärt Inhalte für identisch, die es nicht sind.
- Filterzustände auf die Basis-Kategorie: Nur dort sinnvoll, wo der Inhalt weitgehend deckungsgleich ist - etwa bei Sortiervarianten derselben Liste.
- Nicht in Kombination mit Disallow: Eine gesperrte URL wird nicht abgerufen, ihr Canonical also nicht gelesen - die Anweisung läuft ins Leere.
- Kein Widerspruch zu internen Signalen: Eine Seite, die per Canonical auf eine andere zeigt, aber gleichzeitig prominent verlinkt und in der Sitemap geführt wird, sendet gegenläufige Signale.
Der letzte Punkt ist der häufigste Befund in unseren Audits: Canonicals, die einer Struktur widersprechen, die das Gegenteil sagt. Suchmaschinen gewichten das Gesamtbild. Wenn Sitemap, interne Verlinkung und Canonical unterschiedliche Seiten als die richtige markieren, entscheidet die Suchmaschine selbst - und oft anders als gewünscht (Projekterfahrung).
Interne Verlinkung statt Parameter-Chaos
Crawler entdecken URLs über Links. Das ist die günstigste Stellschraube überhaupt: Was nicht verlinkt ist, wird typischerweise gar nicht erst gefunden - es muss also auch nicht nachträglich gesperrt werden. Google weist darauf hin, dass rel=nofollow als Steuerungsmittel nur greift, wenn jeder einzelne Anker auf eine URL das Attribut trägt (Google Search Central). Genau daran scheitert es in gewachsenen Shops regelmäßig: Ein vergessener Link in einem Footer-Modul oder einer Sitemap-Seite reicht, um den ganzen Ast wieder zu öffnen.
- Indexierbare Facetten als Pfad-URLs prominent verlinken - aus Kategorie, Navigation und redaktionellem Content.
- Nicht indexierbare Filter über Bedienelemente ausliefern, die keine crawlbaren
<a href>-Links erzeugen. - Filter-Links nicht in XML-Sitemaps aufnehmen - die Sitemap ist eine Empfehlungsliste, keine Vollständigkeitsliste.
- Paginierung mit echten Links versehen, aber die Seitengröße nicht zusätzlich als Parameter variieren lassen.
- Nach jedem Template-Release prüfen, ob neue Links in gesperrte URL-Räume zeigen.
Die interne Verlinkung entscheidet damit gleich doppelt: Sie steuert, was überhaupt entdeckt wird, und sie verteilt Link-Equity auf die Seiten, die ranken sollen. Wie sich das systematisch aufbauen lässt, beschreibt der Beitrag zur internen Verlinkung im Online-Shop; die übergeordnete thematische Struktur dahinter behandelt der Artikel zur Content-Cluster-Architektur.
Action-Parameter: Warenkorb, Sortierung, Druckansicht
Der zweitgrößte Posten in Googles Auswertung sind mit 25% die Action-Parameter (Google Search Central). Gemeint sind URLs, die keine Inhalte abbilden, sondern Aktionen auslösen oder Darstellungen variieren: In-den-Warenkorb, Merkliste, Vergleichsliste, Druckansicht, Sortierung, Ansichtsumschaltung. Sie haben eine Gemeinsamkeit: Für Suchmaschinen sind sie ohne jeden Wert, und trotzdem sind sie oft als normale Links im Quelltext hinterlegt.
Besonders unangenehm sind Warenkorb-Aktionen als GET-Links. Ein Crawler folgt ihnen und löst damit eine Zustandsänderung aus, die nicht für ihn gedacht war - Sessions, Warenkörbe und Statistiken werden verfälscht, und der Shop produziert Last ohne Gegenwert. Aktionen, die etwas verändern, gehören hinter ein POST-Formular.
<!-- Problematisch: Crawler folgen dem Link und lösen die Aktion aus -->
<a href="/warenkorb/?add-to-cart=12345">In den Warenkorb</a>
<!-- Besser: Zustandsändernde Aktion über POST, kein crawlbarer GET-Link -->
<form method="post" action="/warenkorb/hinzufuegen">
<input type="hidden" name="produkt" value="12345">
<button type="submit">In den Warenkorb</button>
</form>Für Darstellungsparameter wie Sortierung und Ansicht gilt dieselbe Logik in abgeschwächter Form: Sie dürfen als Links existieren, weil Nutzer sie brauchen, sollten aber per robots.txt gesperrt sein. Der Aufwand ist gering, der Effekt groß - ein Viertel aller Crawling-Probleme hängt an dieser Kategorie (Google Search Central). Die saubere Trennung von zustandsändernden und darstellenden Requests ist am Ende eine Frage der Implementierung; wir setzen sie in Projekten der individuellen Programmierung standardmäßig um.
KI-Crawler machen Crawl-Verschwendung wirtschaftlich teurer
Bis vor wenigen Jahren war Crawl-Budget vor allem ein SEO-Thema: Verschwendete Abrufe kosteten Sichtbarkeit. Inzwischen kosten sie zusätzlich Geld. Der Anteil automatisierten Traffics ist hoch und die Zusammensetzung hat sich verschoben. Bei den Verified Bots entfielen 2025 rund 40% auf Suchmaschinen-Crawler und bereits 20% auf KI-Crawler, weitere 13% auf SEO-Bots (Cloudflare Radar). Gemessen an HTML-Anfragen stammten Anfang Dezember 2025 rund 44% von Nicht-KI-Bots, während menschliche Zugriffe bei rund 47% lagen und KI-Bots im Jahresmittel auf 4,2% kamen; Googlebot allein lag bei 4,5% (Cloudflare Radar).
Der entscheidende Punkt ist aber nicht das Volumen, sondern das Verhältnis von Aufwand zu Gegenleistung. Cloudflare misst dieses als Crawl-to-Refer-Ratio: wie viele Seiten ein Anbieter crawlt, bevor er einen einzigen Besucher zurückschickt. Die Spanne ist dramatisch.
| Plattform | Crawl-to-Refer Januar 2025 | Crawl-to-Refer Juli 2025 |
|---|---|---|
| Anthropic | 286.930:1 | 38.065:1 |
| OpenAI | 1.217:1 | 1.091:1 |
| Perplexity | 54:1 | 195:1 |
| 3,8:1 | 5,4:1 |
Alle Werte stammen aus dem Zeitraum Januar bis Juli 2025 (Cloudflare Radar). Die Lesart ist unbequem: Wo klassische Suche im einstelligen Bereich crawlt, bevor ein Besuch zurückkommt, liegen KI-Crawler drei bis fünf Größenordnungen darüber. Hinzu kommt Dynamik: KI-Crawling, das durch konkrete Nutzeraktionen ausgelöst wird, wuchs 2025 um mehr als das 15-Fache (Cloudflare Radar). Ein aufgeblähter Filter-URL-Raum wird damit gleich mehrfach abgegrast - von Suchmaschinen, von Trainings-Crawlern und von nutzergetriebenen KI-Abrufen.
Jede unnötige Filter-URL wird nicht einmal, sondern von vielen Bot-Typen abgerufen - und jeder Abruf erzeugt Datenbanklast, weil gefilterte Listen selten aus dem Cache kommen. Das schlägt auf Antwortzeiten durch, die wiederum die Core Web Vitals und damit echte Nutzer betreffen. Wer den URL-Raum eindampft, senkt Serverkosten und stabilisiert die Performance in einem Schritt. Zur Auslegung der passenden Infrastruktur beraten wir im Rahmen von Hosting und Wartung.
Die strategische Konsequenz ist nicht, KI-Crawler pauschal auszusperren - das kann Sichtbarkeit in generativen Antworten kosten. Sie lautet: Den crawlbaren Raum auf das reduzieren, was tatsächlich Substanz hat, damit jeder Abruf auf eine sinnvolle Seite trifft. Wie sich Sichtbarkeit in KI-gestützten Suchoberflächen aufbauen lässt, behandelt der Beitrag zur Traffic-Strategie im Google AI Mode.
Umsetzung: eine Reihenfolge, die funktioniert
Facetten-Aufräumen ist ein Eingriff in die Indexierung und sollte nicht in einem Schritt scharf geschaltet werden. Diese Reihenfolge hat sich in unseren Projekten bewährt (Projekterfahrung):
- Inventur: Vollständigen Crawl des Shops fahren und die real erreichbaren URL-Muster erfassen - nicht die geplanten, sondern die tatsächlichen.
- Abgleich mit Logfiles: Auswerten, welche Parameter-Muster Crawler tatsächlich abrufen und wie viel Budget dort versickert.
- Nachfrage prüfen: Je Facette belegen, ob eigene Suchnachfrage besteht - Keyword-Daten und interne Suchanfragen gegeneinanderlegen.
- Matrix festlegen: Jede Facette genau einer Klasse zuordnen - indexierbare Pfad-URL, gesperrter Parameter oder Action-Parameter.
- Indexierbare Facetten bauen: Pfad-URLs, eigenständiger Inhalt, interne Verlinkung, selbstreferenzierendes Canonical.
- Bereits indexierte Filter-URLs bereinigen: Erst
noindexausliefern, Deindexierung abwarten, dannrobots.txt-Disallow setzen. - Verlinkung schließen: Sicherstellen, dass keine internen Links und keine Sitemap-Einträge mehr in gesperrte Räume zeigen.
- Nachmessen: Crawl-Statistiken und den Status Gefunden - zurzeit nicht indexiert über mehrere Wochen beobachten.
Realistisch ist ein Zeithorizont von mehreren Wochen bis Monaten, bis sich Crawl-Verteilung und Indexbestand neu einpendeln - abhängig von Shop-Größe, Crawl-Frequenz und Ausgangslage. Ein belastbarer Ausgangsbefund gehört an den Anfang. Für Shops mit gewachsener Filterlogik lohnt zudem der Blick auf die gesamte E-Commerce-Architektur, weil Facetten selten isoliert entstehen; den übergreifenden Rahmen liefern die Ranking-Faktoren für Online-Shops.
Filter-URLs als Wachstumshebel statt als Ballast
Facettennavigation ist kein Problem, das man wegsperrt. Sie ist eine Ressource, die man sortiert. Der Katalog enthält bereits die Antworten auf hochspezifische Suchanfragen - sie stecken nur in einem URL-Raum, der zu 99,9% aus Rauschen besteht. Die Aufgabe besteht darin, das Signal herauszulösen: die wenigen Kombinationen mit echter Nachfrage zu eigenständigen Landingpages zu machen und den Rest konsequent aus dem Crawl zu nehmen.
Der wirtschaftliche Hebel ist dabei größer geworden, nicht kleiner. Solange nur Googlebot crawlte, war ein aufgeblähter URL-Raum vor allem eine verpasste Chance. Heute, bei einem Verified-Bot-Traffic mit 20% KI-Crawler-Anteil (Cloudflare Radar) und Crawl-to-Refer-Verhältnissen im vier- bis fünfstelligen Bereich (Cloudflare Radar), ist er zusätzlich ein laufender Kostenblock. Beide Effekte zeigen in dieselbe Richtung - und sie lassen sich mit derselben Maßnahme adressieren.
Wer die Entscheidungsmatrix einmal sauber aufsetzt, gewinnt doppelt: Suchmaschinen finden schneller, was zählt, und die Infrastruktur trägt weniger sinnlose Last. Bei der Analyse und Umsetzung unterstützen wir Sie im Rahmen unserer SEO-Leistungen - von der Inventur des URL-Raums bis zum Rollout der Facetten-Architektur. Sprechen Sie uns an, wenn Sie wissen möchten, wie viel Crawl-Budget Ihr Shop aktuell in Filterkombinationen verliert.
Dieser Artikel basiert auf Daten aus: Google Search Central - Managing crawling of faceted navigation URLs (Kombinatorik der Filter-URLs, Übercrawling-Mechanik, robots.txt als empfohlener Weg, Canonical und nofollow als weniger wirksame Mittel, Trennzeichen-Konvention, 404 bei leeren Kombinationen), Google Search Central - Crawl-Budget-Management für große Websites (Schwellen von 1 Mio. bzw. 10.000 Seiten, Crawl-Kapazitätslimit und Crawl-Nachfrage, Hinweis gegen noindex zur Budget-Steuerung), Google Search Central - robots.txt-Spezifikation (Indexierung der URL trotz Disallow, Wildcards, 500 KiB Größenlimit, 24 Stunden Cache), Google Search Central - Search Off the Record, Jahresrückblick Crawling 2025 (Aufschlüsselung der Crawling-Probleme: 50% Facettennavigation, 25% Action-Parameter, 10% irrelevante Parameter, 5% Plugins und Widgets, 2% Sonstige) sowie Cloudflare Radar (Bot- und KI-Crawler-Traffic, Crawl-to-Refer-Ratios Januar bis Juli 2025, Anteile am Verified-Bot-Traffic 2025). Die genannten Zahlen beziehen sich auf die jeweiligen Erhebungszeiträume und können je nach Branche, Shop-Größe und Zeitpunkt abweichen.
In der Regel ja - aber nicht ausnahmslos. Der weit überwiegende Teil der Filterkombinationen deckt keine eigenständige Suchnachfrage ab und gehört typischerweise per robots.txt aus dem Crawl. Facetten mit belegter Nachfrage, ausreichender Sortimentstiefe und eigenständigem Inhalt - meist Marke innerhalb einer Kategorie, branchenabhängig auch Größe oder Farbe - profitieren dagegen erfahrungsgemäß von einer indexierbaren Landingpage mit sprechender Pfad-URL. Die Entscheidung sollte je Facette anhand von Keyword-Daten getroffen werden, nicht pauschal.
Weil noindex erst wirkt, nachdem die Seite abgerufen wurde. Google formuliert das explizit: Man solle kein noindex verwenden, da Google die Seite trotzdem anfordere und sie erst dann verwerfe, wenn es das Meta-Tag sehe (Google Search Central). Der Abruf - und damit die Kosten für Crawl-Kapazität und Serverlast - fällt in jedem Fall an. Zum Sparen von Crawl-Budget eignet sich in der Regel nur, was das Crawling selbst verhindert: ein robots.txt-Disallow oder das Weglassen crawlbarer Links.
Google nennt als Orientierung große Websites ab rund 1 Million einzigartiger Seiten mit wöchentlich wechselnden Inhalten sowie mittlere und größere Websites ab rund 10.000 einzigartigen Seiten mit täglich wechselnden Inhalten (Google Search Central). Wichtig ist die Lesart: Gezählt werden erreichbare URLs, nicht Produkte. Ein Shop mit wenigen tausend Artikeln kann diese Schwelle durch Facettenkombinationen typischerweise deutlich überschreiten. Ein praktischer Indikator ist ein hoher Anteil an URLs mit dem Status Gefunden - zurzeit nicht indexiert in der Search Console (Google Search Central).
Sie verschwinden dadurch nicht zuverlässig aus dem Index. Laut robots.txt-Spezifikation kann Google den Inhalt einer gesperrten Seite zwar nicht indexieren, die URL selbst aber weiterhin indexieren und ohne Snippet in den Suchergebnissen anzeigen (Google Search Central). Für bereits indexierte URLs empfiehlt sich deshalb erfahrungsgemäß eine Reihenfolge: zuerst noindex ausliefern und crawlen lassen, bis die URLs aus dem Index fallen, und erst danach das Disallow setzen. Beides gleichzeitig zu aktivieren, verhindert typischerweise genau die Deindexierung, die beabsichtigt war.
Zwei Datenquellen genügen für eine erste Einschätzung. Erstens die Crawl-Statistiken in der Search Console: Zeigen sie viele Abrufe auf Parameter-URLs, während neue Produkte nur langsam indexiert werden, ist das ein deutliches Signal. Zweitens die Server-Logfiles: Sie zeigen, welche URL-Muster Bots tatsächlich anfordern. Als Faustregel gilt erfahrungsgemäß: Wenn ein erheblicher Teil der Bot-Abrufe auf URLs mit Filter-, Sortier- oder Action-Parametern entfällt, besteht Handlungsbedarf. Der SEO-Audit-Leitfaden beschreibt das Vorgehen im Detail.
Gerade dann - allerdings mit anderer Begründung. Die Crawl-to-Refer-Ratios lagen im Juli 2025 je nach Anbieter zwischen rund 5:1 und über 38.000:1 (Cloudflare Radar), während KI-Crawler rund 20% des Verified-Bot-Traffics ausmachten (Cloudflare Radar). Ein aufgeblähter Filter-URL-Raum verursacht dadurch Last, der typischerweise kein Gegenwert gegenübersteht. Ein pauschales Aussperren von KI-Crawlern ist selten die beste Antwort, weil es Sichtbarkeit in generativen Antworten kosten kann. Wirksamer ist in der Regel, den crawlbaren Raum auf Seiten mit Substanz zu reduzieren.