Pagination und Faceted Navigation — Crawl-Fallen sauber lösen
Faceted Navigation — die Filter- und Facetten-Navigation in Shops und Listen — ist die mit Abstand größte Crawl-Falle, die ein technisches SEO kennen muss. Ein einziger Kategorie-Baum mit Filtern für Farbe, Größe, Marke, Preis und Sortierung kann Millionen crawlbarer URL-Kombinationen erzeugen, die alle fast denselben Inhalt zeigen. Wer das nicht bändigt, verbrennt Crawl-Budget, bläht den Index auf und produziert Duplicate Content im großen Stil. Dieser Artikel zeigt, wie die Falle entsteht — und mit welchen Mustern du sie sauber entschärfst.
Warum Facetten exponentiell URLs erzeugen
Das Problem ist Kombinatorik. Hast du fünf Filter mit je vier Optionen, ergeben sich allein daraus 4⁵ = 1024 Kombinationen — pro Kategorie. Kommen Sortier-Parameter, Paginierung und Mehrfachauswahl dazu, explodiert die Zahl. Jede dieser URLs sieht für den Crawler neu aus, und er kann erst nach dem Abruf entscheiden, ob sie nützlich ist. Genau das ist Googles eigene Beschreibung des Problems: Crawler greifen typischerweise auf eine sehr große Zahl von Facetten-URLs zu, bevor ihre Prozesse feststellen, dass die URLs nutzlos sind.
Drei Schäden entstehen parallel:
- Crawl-Budget-Falle — der Googlebot verschwendet seine Abruf-Kapazität auf Filter-Varianten, statt echte neue Inhalte zu entdecken. Die Folge: Neue Produkte und Artikel werden langsamer indexiert.
- Index-Bloat — dünne, fast identische Kombi-Seiten landen im Index und verwässern die Signale der eigentlich starken Kategorieseiten.
- Duplicate Content — dutzende URLs mit nahezu gleichem Inhalt konkurrieren um dieselben Rankings und zersplittern die Relevanz.
Die Kernentscheidung: welche Facetten sollen ranken?
Bevor du an Technik denkst, triff eine inhaltliche Entscheidung: Für welche Filter-Kombinationen gibt es echten Such-Demand? „Laufschuhe Herren” oder „rote Sneaker” haben Suchvolumen — solche Kombinationen verdienen eine indexierbare, optimierte Landingpage. „Laufschuhe Größe 43 Farbe Blau Preis 80–90 € sortiert nach Beliebtheit” hat keines und gehört konsequent aus dem Index gehalten.
Die Faustregel: Wenige bewusst gewählte Facetten indexierbar, alle anderen gesperrt. Diese Liste pflegst du redaktionell, nicht nach Gefühl — idealerweise auf Basis von Keyword-Recherche. Alles, was nicht auf dieser Liste steht, wird mit den folgenden Mustern gebändigt.
Die Lösungsmuster im Detail
robots.txt-Disallow für Filter-Parameter
Der stärkste Hebel, wenn Indexierung gar nicht erwünscht ist: Sperre die Filter-Parameter per robots.txt-Disallow, sodass der Crawler sie erst gar nicht abruft. Beispiel: Disallow: /*?*color= blockt alle URLs mit color-Parameter, während die Basis-Kategorie crawlbar bleibt. Das ist die effektivste Methode gegen Overcrawling, weil sie das Budget schützt, bevor es ausgegeben wird. Wichtig: Eine per robots.txt gesperrte URL kann Google nicht crawlen — also auch ihren noindex nicht sehen. Beide Mittel schließen sich gegenseitig aus.
noindex für dünne Kombi-Seiten
Sollen die Seiten crawlbar bleiben (etwa damit Produktlinks erreichbar sind), aber nicht im Index landen, setzt du noindex auf die dünnen Kombinationen. Der Crawler darf die Seite besuchen, nimmt sie aber nicht in den Index auf. Das kostet mehr Crawl-Budget als ein Disallow, hält aber den internen Link-Fluss intakt.
Canonical auf die Basis-Kategorie
Für Varianten, die denselben Inhalt unter Parametern zeigen (Sortierung, Sicht-Umschalter), zeigt der Canonical-Tag auf die saubere Basis-Kategorie ohne Parameter. Google bündelt die Signale dort. Achtung: Canonical ist ein Hinweis, kein Befehl — Google darf ihn ignorieren, wenn die Seiten zu unterschiedlich sind. Für echte Duplikate funktioniert er gut, für nur ähnliche Seiten weniger zuverlässig. Google selbst nennt Canonical und nofollow langfristig weniger wirksam als robots.txt-Disallow.
JavaScript-Filter ohne URL-Änderung oder URL-Fragmente
Der sauberste Trick: Filter, die den Inhalt per JavaScript austauschen, ohne eine neue crawlbare URL zu erzeugen — oder die den Zustand in einem URL-Fragment (#color=red) ablegen. Fragmente werden vom Crawler ignoriert und haben weder positiven noch negativen Einfluss auf das Crawling. Damit existiert für nicht-indexierbare Filter schlicht keine eigene URL, die Budget kosten könnte.
Konsistente Parameter-Reihenfolge gegen Duplikate
Wenn indexierbare Facetten als URL-Parameter umgesetzt sind, halte die logische Reihenfolge der Filter immer gleich und verhindere doppelte Filter. Sonst erzeugt dieselbe Auswahl mehrere URL-Varianten (color=red&size=43 vs. size=43&color=red), die wieder als Duplikate gelten. Nutze den Standard-Separator und liefere bei leeren Filter-Kombinationen einen 404 statt einer leeren Seite.
Pagination heute: rel=next/prev ist Geschichte
Lange galt rel="next" und rel="prev" als Pflicht-Best-Practice für paginierte Serien. Das ist vorbei: Google hat 2019 öffentlich bestätigt, diese Tags nicht mehr für die Indexierung zu nutzen — und tat es schon Jahre davor nicht. Heute gilt:
- Jede paginierte Seite ist self-canonical. Seite 2 zeigt mit Canonical auf sich selbst, nicht auf Seite 1. Wer alle Seiten auf Seite 1 canonicalisiert, versteckt die Produkte der Folgeseiten vor Google.
- Echte, klickbare Links zwischen den Seiten. Google folgt sichtbaren Anker-Links, nicht reinen
rel-Attributen. Eine Paginierung, die nur per JavaScript ohne crawlbare Links funktioniert, kann dazu führen, dass tiefe Seiten gar nicht entdeckt werden. - rel=next/prev nicht entfernen, wenn schon da. Bing nutzt die Tags weiterhin, und sie helfen der Barrierefreiheit. Schaden tun sie nicht — Google ignoriert sie nur.
FAQ
FAQ
- Nein. Google hat 2019 bestätigt, die Tags nicht mehr für die Indexierung zu verwenden — und tat es schon Jahre davor nicht. Bing nutzt sie weiterhin und sie helfen der Barrierefreiheit, also schadet es nicht, vorhandene Tags zu behalten. Verlass dich für Google aber nicht darauf.
- Nein. Jede paginierte Seite bekommt einen self-referencing Canonical auf sich selbst. Wer alle auf Seite 1 zeigen lässt, versteckt die Produkte der Folgeseiten vor Google und riskiert, dass tiefe Inhalte nicht indexiert werden.
- Disallow, wenn die Seiten weder gecrawlt noch indexiert werden sollen — das schützt das Crawl-Budget am stärksten. noindex, wenn sie crawlbar bleiben müssen (etwa für interne Links), aber nicht in den Index sollen. Beides zusammen geht nicht: Eine per robots.txt gesperrte Seite kann Google den noindex gar nicht lesen.
- Nur die mit echtem Such-Demand, idealerweise per Keyword-Recherche bestimmt — etwa Marke oder Kernattribut. Tiefe Kombinationen aus vier oder fünf Filtern haben fast nie Suchvolumen und gehören konsequent aus dem Index. Wenige bewusst gewählte Facetten indexierbar, der Rest gesperrt.
- Halte die logische Reihenfolge der Filter in der URL immer gleich und verhindere doppelte Filter, damit dieselbe Auswahl nicht mehrere URL-Varianten erzeugt. Nutze den Standard-Separator und liefere bei leeren Filter-Kombinationen einen 404 statt einer dünnen leeren Seite.
Nutzt Google rel=next und rel=prev noch?
Soll ich paginierte Seiten auf Seite 1 canonicalisieren?
robots.txt-Disallow oder noindex für Filter-Seiten?
Welche Facetten sollten indexierbar sein?
Wie verhindere ich Duplikate durch unterschiedliche Parameter-Reihenfolge?
Fazit
Faceted Navigation ist nicht per se schädlich — schlecht gemanagte Faceted Navigation ist es. Der Schlüssel liegt in einer bewussten Entscheidung: wenige Facetten mit echtem Such-Demand indexierbar machen und alle anderen Kombinationen mit dem passenden Mittel bändigen — robots.txt-Disallow gegen Overcrawling, noindex für crawlbare-aber-nicht-indexierbare Seiten, Canonical für echte Duplikate, JavaScript oder URL-Fragmente, um gar keine URL erst entstehen zu lassen. Bei der Pagination gilt: self-canonical pro Seite, echte klickbare Links, und rel=next/prev als nettes Extra ohne Google-Wirkung. Wer das sauber aufsetzt, schützt sein Crawl-Budget und hält den Index schlank.
Wie das Crawl-Budget insgesamt funktioniert und sich steuern lässt, vertieft der Schwesterartikel zum Crawl-Budget.
Entdecke mehr
Crawl-Budget verstehen und steuern
Was Crawl-Budget ist, wann es überhaupt zählt — und mit welchen Hebeln große Sites Googlebots Zeit auf die richtigen URLs lenken.
Glossar301-Weiterleitung
Eine 301-Weiterleitung ist ein HTTP-Statuscode, der eine URL dauerhaft auf eine andere weiterleitet — der Standard für URL-Änderungen, Domain-Umzüge und Site-Migrationen.
LexikonTechnisches SEO — was Google wirklich crawlen, rendern und indexieren muss
Wie Crawl-Budget, Robots, Sitemap, JS-Rendering, Indexierung, Canonical und Core Web Vitals zusammenspielen — der vollständige Bogen für produktive Sites.