Paginierung und SEO: Serien richtig indexieren

Paginierung bezeichnet die Aufteilung einer langen Liste oder eines langen Inhalts auf mehrere Seiten – Seite 1, Seite 2, Seite 3 und so weiter. Aus SEO-Sicht ist die zentrale Frage nicht, ob Paginierung vorkommt (das tut sie fast überall), sondern ob jede einzelne Seite dieser Serie für Suchmaschinen erreichbar, crawlbar und indexierbar bleibt. Genau an diesem Punkt scheitern die meisten Umsetzungen: entweder durch einen veralteten technischen Rat, der seit Jahren wirkungslos ist, oder durch eine Canonical-Konfiguration, die versehentlich den halben Katalog aus dem Index wirft.

Bevor es um Details geht, eine Klarstellung, die viele Altlasten in bestehenden Setups erklärt: rel="next" und rel="prev" – die Attribute, die früher als Standardlösung für paginierte Serien galten – werden von Google seit Jahren nicht mehr als Signal verwendet, weder für die Indexierung noch für das Ranking. Wer heute noch danach sucht, wie er diese Attribute richtig implementiert, optimiert für ein System, das es so nicht mehr gibt. Was tatsächlich zählt, sind vier andere Dinge: crawlbare Links zwischen den Seiten, ein korrekt gesetztes Canonical pro Seite, erreichbare Inhalte bis zur letzten Seite der Serie und ein bewusster Umgang mit Crawl-Budget bei großen Serien.

Wo Paginierung in der Praxis auftaucht

Paginierte Serien tauchen an vier Stellen regelmäßig auf, und jede hat eigene SEO-Implikationen.

In Kategorie- und Produktlisten von Onlineshops ist Paginierung der Normalfall: Eine Kategorie mit 400 Produkten wird nicht auf einer Seite ausgeliefert, sondern auf 10, 20 oder 40 Seiten zu je 20 bis 40 Produkten. Hier ist die Erreichbarkeit der hinteren Seiten geschäftskritisch – Produkte, die nur auf Seite 8 auftauchen, verkaufen sich schlecht, wenn Seite 8 nie indexiert wird.

Blog- und News-Archive funktionieren ähnlich: eine Übersichtsseite pro Kategorie oder Tag, aufgeteilt nach Datum. Hier ist der eigenständige SEO-Wert der einzelnen paginierten Seite oft gering – kaum jemand sucht gezielt nach "Blog Seite 12" – aber die Seiten dienen als Crawl-Pfad, über den Google ältere Artikel überhaupt erst findet und regelmäßig erneut besucht.

Interne Suchergebnisseiten der eigenen Website sind ein Sonderfall: Sie sind fast immer paginiert, sollten aber in den meisten Fällen ohnehin nicht indexiert werden, denn echte Suchergebnisseiten mit beliebigen Nutzeranfragen erzeugen sonst endlose Mengen an dünnen, sich stark ähnelnden URLs, die keinem eigenständigen Sucheinstieg dienen.

Und lange Einzelartikel – Rezeptsammlungen, Testberichte, Ratgeber, die redaktionell in mehrere Teile aufgeteilt werden – sind der vierte Fall. Hier ist Paginierung oft weniger eine technische Notwendigkeit als eine Entscheidung, die primär zusätzliche Werbeeinblendungen pro Seitenaufruf ermöglicht, was Nutzer zunehmend als störend wahrnehmen und was auch von Suchmaschinen kritisch bewertet wird, wenn der Inhalt dadurch künstlich zerstückelt wirkt, statt einem echten inhaltlichen Grund zu folgen.

Der veraltete Rat: rel="next" und rel="prev"

2011 führte Google die Attribute rel="next" und rel="prev" im Kopfbereich paginierter Seiten ein, um Suchmaschinen mitzuteilen, dass eine Reihe von URLs logisch zusammengehört und Teil derselben Serie ist. Über Jahre war das die Standardempfehlung in praktisch jedem SEO-Leitfaden zum Thema Paginierung, und viele bestehende Websites tragen diese Implementierung bis heute mit sich herum.

2019 bestätigte Google offiziell, was Crawling-Analysen schon vorher nahelegten: Das Attribut wird seit Jahren nicht mehr verwendet, weder als Indexierungs- noch als Ranking-Signal. Google entscheidet stattdessen anhand von Linkstruktur, Inhalt und Canonical-Tags, wie es mit einer Serie umgeht – unabhängig davon, ob rel="next"/rel="prev" vorhanden ist oder nicht.

Praktisch bedeutet das zweierlei. Wer die Attribute bereits implementiert hat, muss sie nicht entfernen – sie schaden nicht, sie bewirken bei Google schlicht nichts mehr. Wer noch keine hat, muss sie nicht nachrüsten, egal was ein älterer Leitfaden behauptet. Entwicklungszeit, die in die korrekte Implementierung von rel="next"/rel="prev" fließt, ist Zeit, die nicht in die Dinge fließt, die tatsächlich einen Unterschied machen: crawlbare interne Links und eine saubere Canonical-Strategie pro Seite.

Der teuerste Fehler: Canonical auf Seite 1

Der mit Abstand häufigste Fehler bei paginierten Serien ist, jede Seite 2, 3, 4 und so weiter per Canonical-Tag auf Seite 1 zu verweisen. Die Logik dahinter klingt zunächst plausibel: Alle Seiten gehören zur selben Kategorie, also soll die Autorität auf einer einzigen URL gebündelt werden, um Duplicate Content zu vermeiden.

Das Problem: Ein Canonical-Tag ist keine Bündelungs-Funktion, sondern eine Aussage gegenüber der Suchmaschine, dass diese URL nicht die zu indexierende Version ist, sondern eine andere. Wenn Seite 2 auf Seite 1 kanonisiert wird, sagt die Website Google im Grunde: Ignoriere diese Seite, die eigentliche Version ist Seite 1. Google folgt dieser Aussage in den allermeisten Fällen. Die Konsequenz: Seite 2 mit ihren eigenen, einzigartigen Produkten oder Artikeln wird gar nicht erst regulär als eigenständige Seite indexiert.

Ein konkretes Beispiel macht den Effekt greifbar. Ein Shop mit 500 Produkten in einer Kategorie, aufgeteilt auf 25 Seiten zu je 20 Produkten. Werden Seite 2 bis 25 auf Seite 1 kanonisiert, behandelt Google effektiv nur die rund 20 Produkte auf Seite 1 als eigenständig indexierten, rankingfähigen Inhalt. Die übrigen 480 Produkte sind zwar technisch weiterhin crawlbar, sofern sie verlinkt sind, aber ihre eigene Listenseite – die URL, über die sie tatsächlich in der Kategorieübersicht erscheinen und die als Sprungbrett zur einzelnen Produktseite dient – gilt gegenüber Google als nicht indexierungswürdig. Das schwächt genau die interne Linkstruktur, über die Google neue und tief liegende Produkte regelmäßig erneut crawlt, und in der Praxis werden diese hinteren Produkte spürbar seltener neu gecrawlt und seltener über die Kategorieseite selbst gefunden.

Wichtig für die Einordnung: Das ist kein Rand-, sondern ein Kernfehler, weil er meist aus einer vermeintlichen SEO-Vorsichtsmaßnahme heraus eingebaut wird, nicht aus reiner Unwissenheit – jemand hat "Duplicate Content vermeiden" gehört und dabei die falsche Lösung gewählt.

Was jede paginierte Seite stattdessen braucht

Statt Seite 1 zur einzigen "echten" Seite der Serie zu erklären, sollte jede Seite so behandelt werden, als stünde sie eigenständig für sich:

• Self-referencing Canonical: Seite 2 kanonisiert auf sich selbst, Seite 3 auf sich selbst, und so weiter. Kein Verweis auf Seite 1.
• Crawlbarkeit und Indexierbarkeit: kein noindex "vorsorglich" auf hinteren Seiten, keine Sperrung über robots.txt, nur weil eine Seite "nur eine Liste" ist.
• Eindeutige Title-Tags und Meta-Beschreibungen: nicht identisch mit Seite 1. Eine einfache, konsistente Ergänzung wie die Seitenzahl im Title reicht meist aus, etwa "Damenschuhe – Seite 3", solange sie sich von Seite zu Seite unterscheidet und nicht rein generisch wirkt.
• Echte, crawlbare Links zur nächsten und vorherigen Seite: reguläre Links mit einem echten href-Attribut und einer echten URL, nicht ausschließlich ein per JavaScript ausgelöster Klick-Handler ohne href. Googlebot folgt Links, keinen Onclick-Events.
• Erreichbarkeit bis zur letzten Seite: Jede Seite der Serie sollte über einen kurzen, konsistenten Klickpfad erreichbar sein, nicht nur über "Weiter, Weiter, Weiter" vierzig Mal hintereinander, sondern idealerweise über direkte Seitenzahlen-Links oder Sprungmarken.

Diese fünf Punkte lösen das Problem, das rel="next"/rel="prev" nie gelöst hat, weil sie auf denselben Mechanismen beruhen, die Google für jede andere URL ohnehin nutzt: Links, Canonicals und Inhalt.

View-All: wann die Alternative die bessere Wahl ist

Neben der klassischen Paginierung gibt es eine zweite Option: eine einzelne "Alle anzeigen"-Seite, die den kompletten Inhalt der Serie auf einer URL bündelt. Wenn diese Seite in akzeptabler Ladezeit funktioniert, hat sie einen strukturellen Vorteil gegenüber Paginierung – es gibt nur eine URL, auf die sich Links, Bewertungssignale und Crawling konzentrieren, ganz ohne den Canonical-Balanceakt zwischen mehreren Seiten.

View-All eignet sich vor allem, wenn die Gesamtmenge überschaubar bleibt: Bei ein paar hundert Elementen ist eine Seite mit allem oft technisch problemlos und für Nutzer sogar angenehmer, etwa wenn sie mit der Browser-Suchfunktion gezielt etwas finden wollen. Auch bei langen redaktionellen Inhalten, die künstlich in mehrere Teile zerlegt wurden, ist eine "Alles auf einer Seite"-Option häufig die bessere Nutzererfahrung und wird entsprechend positiv aufgenommen.

Bei sehr großen Katalogen mit mehreren Tausend Elementen in einer Kategorie kippt die Rechnung. Eine View-All-Seite mit 5.000 Produkten wird schwer, langsam und schadet den Core Web Vitals, was den Vorteil der Konsolidierung wieder auffrisst. In diesem Fall ist die pragmatische Lösung nicht "entweder oder", sondern beides parallel anzubieten: paginierte Seiten für die normale Navigation, jede sauber self-referencing kanonisiert, plus eine optionale View-All-Seite für Nutzer, die sie wollen – ebenfalls auf sich selbst kanonisiert, nicht als Canonical-Ziel der paginierten Seiten missbraucht, es sei denn, es ist bewusst gewollt, dass ausschließlich die View-All-Seite indexiert wird.

Infinite Scroll: das Problem mit unsichtbarem Inhalt

Infinite Scroll ersetzt Seitenzahlen durch automatisches Nachladen: Der Nutzer scrollt nach unten, JavaScript lädt per Fetch-Request weitere Elemente nach und hängt sie an die bestehende Liste an. Für Nutzer fühlt sich das oft flüssiger an als Klicks auf "Nächste Seite". Für Crawler ist es ein verlässlicher Weg, Inhalt zu verlieren.

Googlebot rendert JavaScript, aber der Rendering-Prozess simuliert kein menschliches Scrollverhalten und wartet nicht beliebig lange auf Nachlade-Ereignisse, die erst nach einem Scroll-Trigger oder einem Intersection-Observer-Event feuern. Inhalte, die ausschließlich durch einen solchen Trigger nachgeladen werden, existieren für den Crawler schlicht nicht – er sieht die ersten geladenen Elemente und geht davon aus, dass dort die Seite endet.

Der Fix ist nicht, auf Infinite Scroll zu verzichten, sondern ihn mit echten paginierten URLs zu unterfüttern. Jeder Abschnitt, den der Scroll-Mechanismus nachlädt, sollte gleichzeitig unter einer eigenen, direkt aufrufbaren URL existieren, etwa über die History API per pushState beim Nachladen aktualisiert, die bei direktem Aufruf denselben Inhalt liefert wie beim Scrollen erreicht wird. Praktisch heißt das: ein klassisches "Weitere laden"-Muster mit echten Links im Hintergrund, kombiniert mit Infinite Scroll als Komfortfunktion für Nutzer, statt Infinite Scroll als einzigem Zugriffsweg zum Inhalt. Websites, die ausschließlich auf reines Scroll-Nachladen ohne URL-Unterbau setzen, sehen in der Regel eine harte Indexierungsgrenze kurz hinter dem initial ausgelieferten Inhalt – alles, was erst durch Scrollen nachgeladen wird, bleibt für die Suche unsichtbar, unabhängig davon, wie viele Produkte oder Artikel tatsächlich insgesamt vorhanden sind.

Paginierung und Crawl-Budget bei großen Katalogen

Crawl-Budget – die Menge an URLs, die eine Suchmaschine in einem gegebenen Zeitraum auf einer Website crawlt – wird erst ab einer gewissen Größenordnung zum echten Engpass, meist bei Websites mit mehreren Zehntausend URLs oder mehr. Für solche Seiten ist Paginierung einer der größten stillen Budgetfresser, weil jede paginierte Seite eine eigene URL ist, die gecrawlt, bewertet und in Abständen erneut gecrawlt werden will.

Kritisch wird es, wenn Paginierung sich mit Filtern und Sortierungen kombiniert und sich dadurch vervielfacht: Eine Kategorie mit 30 paginierten Seiten wird durch drei Filteroptionen und zwei Sortierreihenfolgen schnell zu Hunderten faktisch unterschiedlicher URLs, von denen die meisten nahezu identischen Inhalt in nur leicht anderer Reihenfolge zeigen. Google crawlt diese Kombinationen trotzdem, sofern sie intern verlinkt sind, und verbraucht dabei Budget, das sonst für neue oder aktualisierte Seiten zur Verfügung stünde.

Der praktische Umgang damit hat drei Teile. Erstens, Paginierung so schlank wie möglich halten und nicht für jede Filter-Sortier-Kombination eine eigene paginierte Serie erzeugen, wenn diese Kombination selbst keinen eigenständigen Suchwert hat. Zweitens, wo solche Kombinations-URLs aus funktionalen Gründen existieren müssen, sie über robots.txt oder noindex aus dem crawlbaren beziehungsweise indexierbaren Bereich fernhalten, statt sie unreguliert wachsen zu lassen. Drittens dafür sorgen, dass wichtige, tief in der Paginierung liegende Seiten nicht ausschließlich über zwanzig Klicks auf "Nächste Seite" erreichbar sind – über eine XML-Sitemap, über zusätzliche Unterkategorien oder über gezielte Querverlinkung, etwa zu besonders relevanten Produkten, lässt sich der Klickpfad zu wichtigen Inhalten deutlich verkürzen, unabhängig davon, wie tief sie in der reinen Paginierungsreihenfolge liegen.

Praktische Checkliste für eine saubere Paginierungsserie

• Jede Seite hat einen self-referencing Canonical – keine Seite kanonisiert auf Seite 1.
• Keine Seite ist per robots.txt oder noindex vorsorglich gesperrt.
• Title und Meta-Description unterscheiden sich zwischen den Seiten, auch wenn nur minimal.
• Weiter- und Zurück-Links sind echte Links mit href-Attribut, keine reinen JavaScript-Handler.
• rel="next"/rel="prev" ist optional und ohne Wirkung bei Google – die Zeit lieber in die anderen Punkte investieren.
• Bei überschaubaren Katalogen: eine View-All-Seite als zusätzliche, eigenständig kanonisierte Option prüfen.
• Infinite Scroll ist mit echten, direkt aufrufbaren paginierten URLs unterfüttert, nicht nur mit Scroll-Events.
• Bei großen Katalogen: Filter-Sortier-Kombinationen werden nicht unkontrolliert paginiert und verlinkt.
• Wichtige, tief liegende Seiten sind auch über Sitemap oder zusätzliche interne Links erreichbar, nicht nur über die reine Klick-Kette.