Pagination und Facetten: Wie bleibt der Index sauber?

Warum erzeugen Listen- und Filterseiten so viele URLs?

Eine Übersicht mit 400 Einträgen, aufgeteilt in Zwanzigerschritte, ergibt zwanzig Adressen. Kommen vier Filter mit je fünf Werten hinzu, sind rechnerisch schon über tausend Kombinationen erreichbar — und jede davon multipliziert sich erneut mit den Blätterschritten. Aus einem überschaubaren Katalog wird so ein Adressraum, den niemand mehr überblickt.

Diese Kombinatorik ist kein theoretisches Problem. Ein Crawler folgt jedem Anker, den er im ausgelieferten HTML findet. Wenn Ihre Filterleiste jede Kombination als Link ausgibt, entdeckt er sie auch — und verbringt seine Zeit dort statt auf den Seiten, die Ihnen Anfragen bringen.

• Blätterschritte: Jede Seite einer Liste ist eine eigene Adresse mit eigenem Inhalt.
• Facettenkombinationen: Werkstoff, Norm, Hersteller und Abmessung lassen sich frei mischen.
• Reihenfolge derselben Parameter: norm=iso&material=stahl und material=stahl&norm=iso sind für einen Crawler zwei verschiedene Adressen.
• Sortierung und Ansicht: aufsteigend, absteigend, Liste, Kachel — vier Varianten desselben Inhalts.
• Sitzungs- und Kampagnenparameter, die versehentlich in interne Links geraten und sich dann vererben.

Bei einem Großhändler für Befestigungstechnik mit einigen tausend Artikeln erreicht die Zahl der theoretisch erreichbaren Adressen so den sechsstelligen Bereich, während der tatsächliche Bestand aus wenigen tausend Produktseiten besteht. Das Verhältnis von Adressen zu Inhalten ist die Kennzahl, auf die es hier ankommt.

Ermitteln lässt sich dieses Verhältnis mit einem Crawl der eigenen Website und einem Blick in die Sitemap. Steht dort eine vierstellige Zahl echter Seiten, der Crawler findet aber eine sechsstellige Menge Adressen, ist die Ursache immer dieselbe: eine Filterleiste, die jede denkbare Kombination verlinkt.

Soll Seite 2 einer Blätterstrecke indexiert werden?

Ja — als eigenständige Seite mit einem Canonical auf sich selbst. Der verbreitetste Fehler in Blätterstrecken ist der Canonical von Seite 2, 3 und 4 auf Seite 1. Damit sagen Sie Google: Diese Seiten sind Dubletten. Google folgt der Aussage und behandelt sie entsprechend.

Die Folge trifft nicht die Listenseite, sondern die verlinkten Inhalte. Ein Produkt, das nur auf Seite 6 auftaucht, verliert damit seinen einzigen internen Verweis aus der Kategorie. Es wird seltener abgerufen, langsamer aktualisiert und rutscht mit der Zeit aus dem Index.

Für jede paginierte Seite gilt deshalb: eigener Canonical, kein noindex, ein Titel, der die Position kenntlich macht — etwa mit dem Zusatz Seite 3 —, und eine Beschreibung, die sich nicht auf allen Seiten wortgleich wiederholt. Sonst meldet die Search Console bald doppelte Titel und Beschreibungen.

Der einleitende Fließtext einer Kategorie gehört dagegen nur auf Seite 1. Sie ist die Landingpage, sie steht in der Navigation und in der Sitemap. Die Folgeseiten sind Durchreiche zu den Detailseiten, nicht eigenständige Einstiegspunkte.

Was ist aus rel=prev/next geworden?

Google hat 2019 öffentlich bestätigt, die Auszeichnungen rel=prev und rel=next schon seit Jahren nicht mehr für die Indexierung auszuwerten. Sie schaden nicht, ersetzen aber keine sichtbare Verlinkung. Andere Suchmaschinen berücksichtigen sie teilweise weiterhin, weshalb sie in vielen Systemen einfach stehen bleibt.

Was an ihre Stelle tritt, ist unspektakulär: gewöhnliche Links im HTML. Vor, zurück, dazu einige Sprungziele — Seite 1, die direkten Nachbarn, die letzte Seite. So erreicht ein Crawler das Ende einer langen Strecke in wenigen Schritten statt in fünfzig, und dieselbe Logik hilft auch Menschen.

Wann sich eine Alles-anzeigen-Seite lohnt

Wenn sich die vollständige Liste in vertretbarer Zeit ausliefern lässt — bei Referenzlisten und Blog-Archiven mit bis zu etwa zweihundert Einträgen ist das realistisch —, kann diese Gesamtansicht die kanonische Variante sein. Die paginierten Seiten zeigen ihren Canonical dann auf sie.

Bei einem Katalog mit tausenden Artikeln ist das keine Option. Dort bleibt die Blätterstrecke die saubere Lösung. Eine Alles-anzeigen-Seite mit fünftausend Zeilen funktioniert weder auf dem Telefon noch beim Rendern durch eine Suchmaschine.

Wie übersteht Infinite Scroll die Suchmaschine?

Nachladen beim Scrollen ist angenehm zu bedienen und für einen Crawler ein blinder Fleck. Er scrollt nicht, er löst kein Scroll-Ereignis aus und wartet nicht darauf, dass der nächste Block eintrifft. Alles, was erst durch diese Interaktion erscheint, existiert für ihn nicht.

• Hinterlegen Sie jedem nachgeladenen Abschnitt eine echte Adresse und aktualisieren Sie die Adresszeile beim Scrollen.
• Liefern Sie zusätzlich eine klassische Blätterstrecke aus, die ohne JavaScript funktioniert.
• Ein Mehr-laden-Schalter sollte ein Anker mit href auf die nächste Seite sein, kein reiner Klick-Handler.
• Verlinken Sie mindestens Seite 2 im ausgelieferten HTML, damit der Einstieg in die Strecke überhaupt existiert.
• Bauen Sie das Nachladen als Komfortschicht über die funktionierende Grundvariante, nicht als deren Ersatz.

Prüfen lässt sich das in wenigen Minuten: Rufen Sie die Liste mit deaktiviertem JavaScript auf oder sehen Sie sich in der URL-Prüfung der Search Console das gerenderte HTML an. Was dort nicht steht, wird auch nicht indexiert.

Welche Filterkombinationen gehören in den Index?

Der Maßstab ist die Nachfrage, nicht die technische Machbarkeit. Eine Facettenseite verdient nur dann einen Platz im Index, wenn Menschen genau nach dieser Einschränkung suchen — und wenn die Seite dann mehr liefert als eine gefilterte Tabelle.

• Einzelne Facette mit erkennbarer Nachfrage, etwa ein Werkstoff, eine Norm oder eine Baugröße: in der Regel indexierbar.
• Zweierkombination nur dann, wenn Search Console oder Recherche eine reale Nachfrage belegen.
• Drei und mehr Facetten gleichzeitig: praktisch nie.
• Sortierung, Ansicht, Seitengröße, Verfügbarkeit und Preisspannen: grundsätzlich nicht.
• Ergebnislisten mit weniger als einer Handvoll Treffer: außen vor lassen, sie wirken wie leere Seiten.

Eine indexierbare Facettenseite ist keine gefilterte Liste, sondern eine Landingpage. Sie braucht eine eigene Überschrift, zwei bis drei Absätze Einordnung, einen eigenen Titel und idealerweise eine sprechende Adresse statt einer Parameterkette. Ein Maschinenbauer, der Bauteile nach Werkstoff anbietet, gewinnt mit einer redaktionell betreuten Seite je Werkstoff mehr als mit tausend automatisch erzeugten Kombinationen.

Eine Filterkombination verdient nur dann eine eigene indexierbare Seite, wenn jemand genau danach sucht — und wenn Sie ihm mehr als eine Tabelle bieten.

Mit welchen Mitteln steuern Sie Crawling und Indexierung?

Zwei Hebel werden regelmäßig verwechselt. Ein Disallow in der robots.txt verhindert das Abrufen, nicht die Indexierung: Eine gesperrte Adresse kann trotzdem in den Ergebnissen erscheinen, weil Google die Sperre respektiert und deshalb das noindex im Quelltext gar nicht erst zu sehen bekommt. Beides gleichzeitig zu setzen, ist der Klassiker unter den Fehlkonfigurationen.

• robots.txt: Sperren Sie Parametermuster, die nie eigenen Wert tragen — Sortierung, Ansicht, Sitzung.
• noindex, follow: für erreichbare, aber nicht suchrelevante Kombinationen, deren Links weiterverfolgt werden sollen.
• Link-Maskierung: Filter, die niemand entdecken soll, gar nicht erst als Anker ausliefern — als Schalter, per POST oder über Daten-Attribute.
• Canonical: Parametervarianten desselben Inhalts zeigen auf die normalisierte Adresse.
• Normalisierung: Parameter serverseitig alphabetisch sortieren, leere Werte entfernen, abweichende Reihenfolgen per 301 auf die kanonische Form leiten.

Das Werkzeug zur Parametersteuerung in der Search Console hat Google 2022 abgeschaltet. Die Steuerung liegt seither vollständig in Ihrer Anwendung — unbequemer, aber verlässlicher, weil sie in der Auslieferung liegt und nicht in einer Oberfläche, die niemand pflegt.

Interne Links sollten ausschließlich auf kanonische Adressen zeigen. Nach unserer Projekterfahrung stammt der größere Teil des Parametermülls nicht von fremden Seiten, sondern aus der eigenen Navigation, aus Sortier-Schaltflächen und aus Breadcrumbs, die den aktiven Filter mitschleppen.

Woran erkennen Sie, dass das Crawl-Budget leidet?

Für einen Auftritt mit einigen hundert Seiten ist Crawl-Budget kein Thema. Relevant wird es dort, wo die Zahl der erreichbaren Adressen die Zahl der echten Inhalte um ein Vielfaches übersteigt — also genau bei Katalogen, Objektlisten und großen Archiven.

• Im Serverprotokoll: Welcher Anteil der Crawler-Zugriffe entfällt auf Parameter-Adressen statt auf Produkt- oder Beitragsseiten?
• In der Crawling-Statistik der Search Console: steigende Zugriffszahlen bei gleichbleibender Zahl indexierter Seiten.
• Im Indexierungsbericht: eine wachsende Gruppe unter der Meldung Gecrawlt, zurzeit nicht indexiert.
• Im Alltag: Neue Artikel oder Beiträge tauchen erst nach Wochen in der Suche auf, obwohl die Sitemap sie längst führt.

Treten zwei oder drei dieser Signale gleichzeitig auf, lohnt sich der Aufwand für Normalisierung und Maskierung. Rechnen Sie mit einigen Tagen Entwicklungsarbeit, verteilt auf Auslieferung, Verlinkung und Sitemap-Erzeugung.

Und rechnen Sie mit Geduld: Ein aufgeblähter Adressraum baut sich nicht über Nacht ab. Google braucht Wochen, bis die gesperrten Muster aus dem Abrufverhalten verschwinden. Sichtbar wird der Erfolg zuerst im Protokoll, dann im Indexierungsbericht, zuletzt in der Aktualität neuer Seiten.

Halten Sie den Zustand danach fest. Eine kurze Notiz darüber, welche Parameter gesperrt sind, welche Facetten indexierbar bleiben sollen und wer das entscheidet, verhindert, dass die nächste Erweiterung der Filterleiste die Arbeit wieder zunichtemacht. Erfahrungsgemäß entsteht der Wildwuchs nicht beim Aufbau, sondern beim dritten oder vierten Ausbau des Katalogs.