Was ist Paginierung?

Paginierung ist die Aufteilung einer langen Liste auf mehrere Bildschirme: die Produkte einer Kategorie, die Artikel eines Blogs, die Treffer einer Suche. Jeder Abschnitt hat meist eine eigene Adresse, und zwischen ihnen liegen Verweise, mit denen man weiterkommt.

Es gibt sie aus zwei Gründen zugleich. Der eine ist Leistung: zehntausend Produkte auf einem Bildschirm zu laden ruiniert jede Ladegeschwindigkeit und macht die Seite unbedienbar. Der andere ist Orientierung: Eine Liste ohne Ende lässt nicht erkennen, wo man ist — und genau dort fehlt eine Brotkrume.

Für eine Suchmaschine kommt die Entdeckung dazu. Haben die Seiten zwei, drei und folgende keine eigene, verlinkte Adresse, erreicht der Crawler nie, was auf ihnen steht, so gut es auch sein mag. Die Hälfte des Katalogs kann unsichtbar bleiben, ohne dass etwas kaputt aussieht.

Sie gehört von zwei Dingen getrennt, mit denen sie vermischt wird. Filtern ist etwas anderes: Ein Filter ändert, WAS gezeigt wird, die Paginierung ändert, WIE VIEL auf einmal gezeigt wird. Und Sortieren ist etwas anderes: Eine andere Reihenfolge verteilt dieselben Einträge auf dieselben Seiten, nur in anderer Folge.

Die Verwechslung zählt, weil alle drei meist auf demselben Bildschirm sitzen und gleichzeitig Adressen erzeugen. Lassen sich Filter, Sortierung und Seite frei in der URL kombinieren, vervielfacht sich die Zahl möglicher Adressen — und das ist genau der Weg zum Index Bloat.

In der Praxis gibt es drei Arten, eine Liste zu verteilen, und sie unterscheiden sich weniger im Aussehen als in dem, was sie hinterlassen. Die nützliche Frage ist immer dieselbe: Gibt es eine eigene Adresse, die sich mit einem Verweis erreichen lässt?

Bei Seitenzahlen lautet die Antwort ja, und mehr ist dazu nicht zu sagen. Bei einem Knopf zum Nachladen hängt es davon ab, wie er gebaut ist: Ist der Knopf nur ein Stück JavaScript, gibt es nichts zu folgen; liegt zusätzlich ein echter Verweis darunter, funktioniert er so gut wie die Zahlen. Beim unendlichen Scrollen gibt es überhaupt keine Adresse.

Und alle drei vertragen sich ohne Widerspruch: die bequeme Ansicht für den, der stöbert, und die nummerierten URLs darunter, so verlinkt, dass der Crawler sie abläuft. Man muss sich nicht zwischen Nutzererfahrung und Entdeckung entscheiden.

Ein Baudetail entscheidet mehr, als es scheint: ob die Verweise zwischen den Seiten echte Verweis-Elemente sind oder Elemente, die per Programmierung auf einen Klick reagieren. Nur das Erste ist ein Weg; das Zweite kann für den Besucher einwandfrei arbeiten und für den, der die Website im Code abläuft, nicht existieren.

Und eine praktische Folge für die Prüfung: nachgesehen wird im ausgelieferten HTML, nicht am Bildschirm. Eine Zahlenleiste kann tadellos aussehen und ohne einen einzigen echten Verweis dahinter gebaut sein — dann wird die Hälfte des Katalogs zur verwaisten Seite, ohne dass irgendetwas warnt.

Die am häufigsten falsch getroffene Entscheidung betrifft das Canonical. Seite zwei ist keine Fassung von Seite eins: Sie enthält andere Produkte, ihr Canonical gehört also auf sie selbst. Alle auf die erste zeigen zu lassen sagt Google, dass es den Rest nicht gibt, und der Katalog verschwindet aus dem Index, ohne dass jemand darum gebeten hätte.

Die zweite betrifft die Auszeichnung rel=next und rel=prev, die jahrelang empfohlen wurde. Google wertet sie seit 2019 nicht mehr aus, und die aktuelle Dokumentation zur Paginierung erwähnt sie nicht mehr; sie zu setzen schadet nicht, löst aber auch nichts und ersetzt keinesfalls die normalen Verweise zwischen den Seiten.

Die dritte betrifft die Titel. Teilen sich die fünfzig Seiten einer Kategorie Titel und Beschreibung, liegt kein technischer Fehler vor, aber für den, der die SERP liest, sieht es aus wie doppelter Content. Die Nummer in den Titel zu schreiben ist das Mindeste, und auf der ersten Seite zu sagen, was die anderen nicht wiederholen, ist das Vernünftige.

Eine vierte Entscheidung wird selten besprochen und wirkt unmittelbar auf das, was indexiert wird: was mit der ersten Seite geschieht, wenn es sie mit und ohne Parameter gibt. In vielen Systemen bestehen die saubere Adresse der Kategorie und dieselbe mit einem Seite-eins-Anhang nebeneinander, beide mit demselben Inhalt. Dieses Paar ist ein echtes Duplikat, und dort gehört das Canonical auf die saubere Fassung.

Und eine Empfehlung zur internen Verlinkung: Es braucht nicht von jeder Seite aus einen Verweis auf alle fünfzig. Die vorige, die nächste und ein paar Ankerpunkte genügen; eine Leiste, die alle auflistet, verteilt das Gewicht auf zu viele Ziele und füllt den Code mit Verweisen, die niemand benutzt.

Eine richtige Zahl gibt es nicht, es gibt ein Gleichgewicht zwischen zwei Kosten. Bei wenigen Einträgen je Seite zerfällt die Liste in viele URLs, und alles rückt weiter weg, was die Klicktiefe verschlechtert. Bei vielen lädt jede Seite länger und wiegt auf dem Mobilgerät schwerer.

Ein vernünftiger Einstieg ist die Frage, wie viele Seiten die Aufteilung erzeugt. Wird eine Kategorie mit tausend Produkten in Zwanzigerschritten geteilt, entstehen fünfzig Seiten, und die letzten liegen zu viele Klicks vom Anfang entfernt. In Hunderterschritten sind es zehn, und die läuft man ab.

Außerdem sollte die Entscheidung nicht allein an der Liste hängen. Eine gute interne Suche, durchdachte Filter und thematische Blöcke, die in die Tiefe des Katalogs springen, machen die Paginierung zum Nebenweg — und das senkt zugleich die Tiefe und das Crawl-Budget, das ihr Ablaufen verbraucht.

Ein Hinweis zur Prüfung, ob die gewählte Aufteilung trägt: Sieh in der Search Console nach, wie viele dieser Seiten Impressionen bekommen. Üblich und gesund ist, dass die erste fast alles auf sich zieht und die folgenden selten erscheinen; bedenklich wird es, wenn ab einer bestimmten Nummer gar keine mehr auftaucht — das heißt, der Crawler kommt dort nicht mehr hin.

Und eine ergänzende Prüfung im Serverprotokoll: Werden die hinteren Seiten nie angefordert, bringen sie nicht wenig, sondern werden nicht besucht. Zwei verschiedene Befunde mit verschiedenen Lösungen, und nur die Logfile-Analyse trennt sie mit Tatsachen.

Der teuerste ist das Canonical auf die erste Seite, oben schon genannt, weil es genau das aus dem Index nimmt, was man ordnen wollte.

Der zweite ist, den Seiten zwei und folgende ein Noindex zu geben. Es sieht aufgeräumt aus und bewirkt das Gegenteil: Produkte, die nur dort erscheinen, werden nicht mehr entdeckt, weil der Crawler eine Seite seltener besucht, von der ihm gesagt wurde, sie nicht zu indexieren.

Und der dritte ist eine schlecht gebaute Ansicht „alles anzeigen“. Als Angebot für den Nutzer ist sie gut; als einzige indexierbare URL einer Kategorie mit tausend Produkten ist sie eine riesige Seite, die niemand zu Ende lädt. Wenn es sie gibt, dann als Ergänzung der nummerierten Seiten und nicht als deren Ersatz.

Ein vierter Fehler taucht bei Migrationen auf: die Zahl der Einträge je Seite zu ändern, ohne an die alten Adressen zu denken. Von zwanzig auf hundert umgestellt, gibt es die Seiten dreißig bis fünfzig nicht mehr, und ohne vorbereiteten Umzug bleiben sie als 404-Fehler zurück, von außen verlinkt. Eine 301-Weiterleitung auf den entsprechenden Abschnitt erledigt den ganzen Fall.

Und der letzte, der leiseste: die Standardsortierung sich selbst überlassen. Wird eine Kategorie nach Neuheit sortiert und kommt täglich Ware dazu, steht auf Seite drei jede Woche etwas anderes. Das ist für sich kein Fehler, erklärt aber, warum solche Seiten selten Positionen festigen — und das gehört gewusst, bevor man eine andere Ursache sucht.