Paginierung im SEO: Definition, Umsetzung, Alternativen

Was bedeutet Paginierung und woher kommt der Begriff?

Der Begriff Paginierung bezeichnet die Aufteilung eines zusammenhängenden Inhalts auf mehrere nummerierte Seiten, die über Links miteinander verbunden sind. Er stammt aus dem Verlagswesen, wo er die fortlaufende Seitennummerierung eines Buches oder einer Akte meint. Auf Websites steckt dasselbe Prinzip hinter der Zahlenreihe am Ende einer Produktliste, über die sich von Seite zu Seite blättern lässt. Suchmaschinen sehen jede dieser Seiten als eigenes Dokument mit eigener URL, eigenem Title und eigenem Inhalt. Fachlich fällt das Thema in den Bereich Technisches SEO, weil Canonicals, Crawling und URL-Muster den Ausschlag geben. Am Einsatzgebiet entscheidet sich, ob eine Folgeseite ranken soll, nur Produkte erreichbar halten muss oder gar nicht in den Index gehört.

Kategorieseiten in Onlineshops

Shop-Kategorien mit Dutzenden oder Hunderten Produkten sind der Klassiker unter den paginierten Seiten. Meist trägt die erste Seite Kategorietext, Filter und die stärksten Produkte, während die Folgeseiten nur noch weitere Artikel zeigen. Beim Ranking zählt fast immer diese erste Seite, und den Folgeseiten bleibt vor allem die Aufgabe, Produkte für Crawler erreichbar zu halten. Bei großen Sortimenten sind das schnell Hunderte. Wie stark Seitenzahlen die Sichtbarkeit einzelner Artikel beeinflussen, zeigt sich bei SEO für Online Shops deutlicher als in jedem anderen Website-Typ.

Blog-Archive und Nachrichtenseiten

Übersichtsseiten in Blogs sortieren Beiträge chronologisch und verteilen sie auf nummerierte Archivseiten. Anders als Shop-Kategorien ranken diese Archive selten für Suchbegriffe, weil Leser über die einzelnen Artikel einsteigen. Ihre Funktion liegt darin, ältere Beiträge intern verlinkt zu halten, damit sie nicht aus dem Index fallen. Nachrichtenportale teilen einzelne lange Artikel auf mehrere Seiten auf. Heute dient das vor allem der Anzeige zusätzlicher Werbeflächen und bringt aus SEO-Sicht kaum Vorteile.

Suchergebnisseiten und interne Suche

Auch die Ergebnisliste einer Website-Suche ist paginiert, sobald mehr Treffer vorliegen, als auf eine Seite passen. Diese Listen entstehen erst aus Nutzereingaben und gehören in aller Regel nicht in den Index, weil jeder neue Suchbegriff eine neue URL erzeugt. Google hält seine eigenen Ergebnisseiten aus demselben Grund aus dem Index heraus, und für die interne Suche einer Website gilt dieselbe Logik. Wie viele Seiten die Trefferliste umfasst, spielt dabei keine Rolle.

Foren, Verzeichnisse und Datenbanken

Diskussionsthreads in Foren, Firmenverzeichnisse und Rezeptdatenbanken verteilen ihre Einträge ebenfalls auf viele Seiten. Bei Foren kommt hinzu, dass ein einzelner Thread selbst wieder paginiert sein kann, sobald genügend Antworten vorliegen. Verzeichnisse mit mehreren tausend Einträgen erreichen schnell dreistellige Seitenzahlen, was die Frage der Klicktiefe besonders dringlich macht. Jede dieser Strukturen braucht eine eigene Antwort darauf, welche Seiten indexiert werden sollen und welche nicht.

Abgrenzung: Paginierung ist keine Filternavigation

Filter- und Facettennavigation werden häufig in einem Atemzug mit Seitenzahlen genannt, lösen aber ein anderes Problem. Filter erzeugen neue Teilmengen einer Kategorie, etwa alle roten Schuhe in Größe 42, und vervielfachen die URL-Anzahl mit jeder zusätzlichen Filteroption. Seitenzahlen teilen dagegen eine feste Menge in Abschnitte und wachsen nur linear mit der Produktanzahl. Beide Mechanismen greifen ineinander, sobald ein gefilterter Bereich selbst wieder mehrere Seiten umfasst. Für Crawling und Indexierung brauchen sie trotzdem getrennte Regeln, weil Filterkombinationen fast immer aus dem Index gehören, Seitenzahlen dagegen nicht.

Warum ist Paginierung für SEO ein Problem?

Aus Sicht der Suchmaschine ist jede Folgeseite ein eigenständiges Dokument, das Google erst als Teil einer Serie erkennen muss. Gelingt das nicht, konkurrieren die Seiten miteinander oder werden gar nicht erst gecrawlt, weil der Bot keinen Grund sieht, tiefer zu gehen. Dazu kommt, dass sich die Seiten einer Serie in Aufbau, Überschrift und Navigation stark ähneln und nur in der Produktauswahl unterscheiden. Genau diese Nähe ist der Ausgangspunkt der meisten Probleme, die im Zusammenhang mit Seitenzahlen auftreten, und sie lässt sich mit keinem einzelnen Tag beseitigen. Near Duplicates, Thin Content, Klicktiefe, Linkkraft und Kannibalisierung sind dabei keine getrennten Baustellen, sondern Folgen derselben Struktur, sodass eine Korrektur meist mehrere davon zugleich entschärft.

Rechenbeispiel: 16 gegen 32 Artikel pro Seite und die Folgen für die Klicktiefe

Verursacht Paginierung Duplicate Content?

Nein, jedenfalls keinen echten. Zwei Seiten derselben Kategorie teilen sich Überschrift, Navigation, Footer und oft auch den Kategorietext, nur die Produktkacheln in der Mitte unterscheiden sich. Suchmaschinen sprechen dann von Near Duplicates. Gemeint sind fast identische Dokumente, keine Kopien. Google bewertet die Einzigartigkeit einer Seite über ihren gesamten Inhalt, und je kleiner der unterschiedliche Anteil ausfällt, desto weniger Wert schreibt die Suchmaschine der Folgeseite zu. Zum echten Duplikat wird die Serie erst, wenn die erste Seite unter zwei URLs erreichbar ist oder der Kategorietext auf jeder Seite erscheint.

Thin Content auf hinteren Seiten

Wird der Kategorietext nur auf Seite 1 ausgespielt, bleiben ab Seite 2 lediglich Produktnamen, Preise und Bilder übrig. Dieser dünne Inhalt gilt als Thin Content, weil er ohne die Produktliste keinen eigenständigen Wert bietet. Bei Sortimenten mit hoher Fluktuation ändert sich dieser Inhalt ständig, was die Seiten für Google noch weniger greifbar macht. Damit stehen Shopbetreiber vor einer Abwägung: Kategorietext auf allen Seiten erzeugt Near Duplicates, Kategorietext nur auf Seite 1 lässt die Folgeseiten dünn zurück. Das zweite Problem wiegt weniger, weil die Folgeseiten ohnehin nicht ranken sollen und dünner Inhalt dort weniger schadet als Duplikate auf jeder Seite.

Klicktiefe und Paginierungs-Tunnel

Verlinkt jede Seite nur zur nächsten, entsteht ein Tunnel, den ein Crawler Schritt für Schritt durchlaufen muss. Bei 200 Produkten und 16 Artikeln pro Seite ergeben sich 13 Seiten, bei 30 Artikeln pro Seite sind es noch 7. Jede zusätzliche Seite erhöht die Klicktiefe der dort verlinkten Produkte um eine Ebene, und je tiefer eine Seite liegt, desto seltener besucht der Googlebot sie. Produkte auf den hinteren Seiten bleiben ohne weitere Verlinkung praktisch verwaist. Gegen diesen Effekt hilft eine flache Website Struktur, die jede Zielseite über mehrere Pfade erreichbar macht.

Verteilung der internen Linkkraft

Jede Kategorieseite gibt einen Teil ihrer Autorität, oft Linkjuice genannt, an die Seiten weiter, die sie verlinkt. Liegt ein Produkt erst auf Seite 9, kommt dort nur noch ein Bruchteil dessen an, was die erste Seite erhält. Diese Verwässerung erklärt, warum Artikel auf hinteren Seiten für Longtail-Suchbegriffe schlechter ranken als vergleichbare Artikel weiter vorn. Über die Interne Verlinkung aus Ratgebern, Startseiten-Modulen oder verwandten Produkten lässt sich dieser Effekt abfedern, weil das Produkt dann nicht mehr allein von seiner Position in der Serie abhängt.

Keyword Kannibalisierung zwischen den Komponentenseiten

Bleiben alle Seiten einer Serie indexierbar, entscheidet Google selbst, welche davon zu einem Suchbegriff erscheint. In der Praxis ist das gelegentlich Seite 4 statt der optimierten Startseite der Kategorie, etwa weil dort ein besonders stark verlinktes Produkt liegt. Nutzer landen dann mitten in der Liste ohne Kategorietext und Filter, was die Absprungrate erhöht und Conversions kostet. Diese Form der Keyword Kannibalisierung innerhalb der eigenen Domain lässt sich nur über klare Signale auflösen, welche Seite die Hauptseite ist. Am stärksten wirken dabei das Canonical Tag, die interne Verlinkung und ein Link von jeder Folgeseite zurück auf Seite 1, den Google in seiner Dokumentation als Signal für den Anfang der Serie beschreibt.

Google ignoriert rel=next und rel=prev seit 2019, Bing liest die Attribute weiterhin

Braucht eine Website rel=next und rel=prev noch?

Für Google nicht mehr, für Bing unter Umständen schon. Jahrelang galt es als Standard, im Head jeder Folgeseite mit rel=prev und rel=next auf die vorherige und die nächste Seite zu verweisen, und Google hatte diese Auszeichnung selbst dokumentiert. Im März 2019 räumte das Search-Team dann öffentlich ein, die Attribute bereits seit Jahren nicht mehr auszuwerten, und entfernte die Dokumentation. Seitdem erkennt der Googlebot Serien ausschließlich über die internen Links zwischen den Seiten sowie über Muster in URL und Inhalt.

Heute hält die Dokumentation zur Paginierung fest, dass Google die Tags selbst nicht mehr nutzt, andere Suchmaschinen sie aber nach wie vor auswerten könnten. Vorhandene Tags schaden nicht und müssen nicht entfernt werden, sie bringen bei Google nur keinen Vorteil mehr. Anders sieht es bei Bing aus, dessen Search-Team noch im selben Monat über Frédéric Dubut bestätigte, dass Bing die Attribute nach wie vor zur Strukturerkennung nutzt. Zielgruppen im B2B-Umfeld arbeiten häufig auf Windows-Rechnern mit Edge als Standardbrowser, wo Bing einen deutlich höheren Anteil an Suchanfragen hält als im Privatbereich. Wo diese Nutzer eine Rolle spielen, lohnt es sich, die Tags beizubehalten oder neu einzubauen. Alle anderen investieren Zeit und Budget besser in saubere Links und Canonicals.

Wie setzen Sie das Canonical Tag bei Paginierung richtig?

Jede Folgeseite verweist im Canonical Tag auf sich selbst, denn das ist die einzige Variante ohne Nebenwirkungen. Das Tag teilt Suchmaschinen mit, welche URL bei mehreren ähnlichen Seiten die maßgebliche Version ist, und wird bei Seitenzahlen häufig falsch verstanden, weil Folgeseiten zwar ähnlich, aber eben nicht identisch sind. Laut der Dokumentation zur Kanonisierung behandelt Google das Tag als starkes Signal, nicht als Anweisung, und ignoriert es, sobald die verglichenen Seiten zu unterschiedlich ausfallen. Falsch gesetzt bleibt ein Canonical entweder wirkungslos oder verhindert die Indexierung ganzer Serien. Welche der drei gängigen Varianten in Frage kommt, hängt allein davon ab, ob eine Gesamtansicht existiert oder nicht.

Selbstreferenzierendes Canonical als Standardlösung

Seite 2 verweist im Canonical Tag auf die URL von Seite 2, Seite 3 auf die von Seite 3. Damit signalisiert die Website, dass jede Seite ein eigenständiges Dokument mit eigener Berechtigung ist. Google kann alle Seiten crawlen, alle verlinkten Produkte finden und entscheidet anhand von Links und Inhalt, welche Seite zu einer Suchanfrage passt. Für nahezu alle Shops und Blogs empfehlen wir diese Lösung, weil sie mit jeder weiteren Maßnahme kombinierbar bleibt, vom Load-More-Button bis zur Erhöhung der Artikel pro Seite. Inzwischen setzen die meisten Systeme sie von Haus aus, was ein Blick in den Quellcode einer Folgeseite in Sekunden bestätigt.

Canonical auf Seite 1: der häufigste Fehler

Viele Systeme und noch mehr Anleitungen setzen ab Seite 2 ein Canonical auf die erste Seite der Kategorie. Dahinter steckt der Wunsch, nur diese eine Seite im Index zu haben, doch die Logik des Tags passt nicht, denn Seite 2 zeigt andere Produkte als Seite 1 und ist damit kein Duplikat. Google rät in derselben Paginierungs-Dokumentation ausdrücklich davon ab, die erste Seite als kanonische URL zu verwenden. Meist erkennt die Suchmaschine den Widerspruch und ignoriert die Angabe, womit der gewünschte Effekt ausbleibt. Folgt sie dem Tag dagegen, verschwinden die Folgeseiten samt ihrer Produktlinks aus der Bewertung. So oder so steht die Website schlechter da als ohne das Tag.

Canonical auf eine View-All-Seite

Existiert eine Gesamtansicht, die alle Produkte der Kategorie auf einer einzigen Seite zeigt, darf das Canonical jeder Teilseite dorthin verweisen. In diesem Fall stimmt die Logik, weil die Gesamtansicht den Inhalt aller Teilseiten vollständig enthält. Google bevorzugt dann die View-All-Seite für den Index, während Nutzer bequem in kleineren Abschnitten blättern. Voraussetzung ist, dass die Gesamtansicht trotz vieler Bilder schnell lädt, weil sonst die Core Web Vitals der einzigen indexierten Seite leiden. Ab einigen hundert Produkten scheitert die Variante meist an genau dieser Hürde.

Was bewirken noindex und robots.txt bei paginierten Seiten?

Beide halten Folgeseiten aus dem Index, kosten dafür aber die Links zu den Produkten darauf. Ursprünglich sollte die Kombination noindex,follow bewirken, dass Google die Seite nicht indexiert, den Links darauf aber trotzdem folgt.

John Mueller von Google erklärte bereits 2017 in einem Webmaster-Hangout, dass eine dauerhaft auf noindex gesetzte Seite mit der Zeit komplett aus dem Crawling fällt. Damit wird das follow-Attribut faktisch bedeutungslos, und die Produkte auf den Folgeseiten verlieren ihre internen Links. Noch einen Schritt weiter geht eine Sperre in der robots.txt, die schon das Crawling verhindert. Weder Inhalt noch Links noch ein eventuelles Canonical bekommt Google dann je zu sehen. Laut der Einführung zur robots.txt kann die URL trotzdem ohne Snippet im Index erscheinen, sobald andere Seiten darauf verlinken. Die folgende Übersicht stellt die Wirkung der drei Varianten dem Standard gegenüber.

Anweisung	Crawling der Folgeseite	Indexierung der Folgeseite	Linkkraft an verlinkte Produkte	Sinnvoll bei
index,follow mit Self-Canonical (Standard)	ja, regelmäßig	möglich, Google wählt die passende Seite	fließt vollständig	Shops, Blogs, Verzeichnisse mit stabilem Sortiment
noindex	anfangs ja, nimmt über Monate ab	nein	geht mit sinkendem Crawling verloren	interne Suchergebnisse, Seiten ohne eigenen Wert
Disallow in der robots.txt	nein	URL kann trotzdem ohne Snippet erscheinen	keine, Links werden nie gelesen	praktisch nie bei Kategorien oder Archiven
Canonical auf Seite 1	ja	meist ignoriert, sonst nein	unklar, abhängig von Googles Entscheidung	nie bei Seitenzahlen

Aus der Tabelle wird deutlich, warum der Standard in fast allen Fällen die beste Wahl ist. Nur bei Seiten, die für keinen Nutzer einen Wert haben, etwa Ergebnislisten der internen Suche, ist noindex angebracht. Selbst dann sollten die dort verlinkten Produkte über andere Pfade erreichbar bleiben, damit sie nicht zusammen mit dem Crawling der Folgeseite verschwinden.

URL-Struktur und JavaScript-Paginierung technisch sauber umsetzen

Wie Seitenzahlen in der URL erscheinen und wie die Links dorthin im Quellcode stehen, entscheidet darüber, ob Suchmaschinen die Serie überhaupt erkennen. Seit Google rel=next nicht mehr auswertet, tragen diese beiden Faktoren die gesamte Last der Strukturerkennung. Mit einem lesbaren URL-Muster kann die Suchmaschine Seite 5 als fünften Teil einer Serie einordnen, statt sie für eine beliebige Unterseite zu halten. Zugleich müssen die Links zwischen den Seiten so im HTML stehen, dass ein Crawler ihnen ohne Klick folgen kann. Beide Punkte klingen banal, gehören aber zu den häufigsten Ursachen, wenn Produkte auf hinteren Seiten nicht im Index landen.

Lesbare Seitenzahlen in der URL und echte href-Links gegen kryptische Parameter

Sprechende URLs statt kryptischer Parameter

Pfade wie /schuhe/page/2/ oder Parameter wie /schuhe/?page=2 sind für Menschen und Maschinen lesbar und benennen die Seitenzahl eindeutig. Kryptische Varianten wie ?start=24 oder ?offset=48 funktionieren technisch ebenso, verraten aber nicht, dass es sich um Seite 2 oder 3 handelt. Parameter für Sortierung und Ansicht sollten von der Seitenzahl getrennt bleiben, sonst entstehen für dieselbe Seite mehrere URLs. Seite 1 der Serie gehört auf die Kategorie-URL selbst, nicht auf eine Variante mit /page/1/, weil sonst zwei identische Dokumente existieren. Sprechende URLs erleichtern nebenbei auch die Auswertung in der Search Console, weil sich alle Folgeseiten über einen einzigen Filter auf das Muster page= oder /page/ herausziehen lassen.

AJAX- und JavaScript-Paginierung crawlbar halten

Viele Shops laden weitere Produkte per JavaScript nach, ohne die Seite neu aufzubauen. Für Nutzer ist das angenehm, für Crawler nur dann unproblematisch, wenn die Links zu den Folgeseiten trotzdem als echte href-Angaben im HTML stehen. Der Googlebot klickt keine Buttons und löst keine Scroll-Ereignisse aus, er folgt ausschließlich Links, die er im Quellcode oder im gerenderten DOM findet. Fehlen diese Links, existieren Seite 2 und alle weiteren für die Suchmaschine schlicht nicht. Bewährt hat sich, die nummerierte Navigation im HTML zu behalten und das Nachladen per Script nur als Komfortschicht darüberzulegen. Welche Linkformen Google zuverlässig erkennt, führen die Grundlagen von JavaScript-SEO im Abschnitt zu Links auf.

Für KI-Crawler gilt diese Regel noch strenger. Systeme wie GPTBot oder PerplexityBot führen kein JavaScript aus und sehen nur das rohe HTML, das der Server ausliefert, wie eine Auswertung von Vercel und MERJ aus dem Dezember 2024 über mehrere hundert Millionen Crawler-Anfragen belegt. Produkte, die ausschließlich per Script nachgeladen werden, bleiben für sie unsichtbar, und bei GEO-Prüfungen von Kundenprojekten gehört genau dieses Muster zu den häufigsten Ursachen, warum Sortimente in KI-Antworten fehlen. Sprachmodelle zitieren in aller Regel nicht die Paginierungsseite selbst, wohl aber die Produkt- und Ratgeberseiten, die darüber erreichbar sind.

Alternativen zur klassischen Paginierung

Die nummerierte Seitenfolge ist nicht die einzige Möglichkeit, große Mengen an Inhalten zu strukturieren. Google hat bei der Abschaffung von rel=next selbst darauf hingewiesen, dass Nutzer Inhalte auf einer einzigen Seite bevorzugen, sofern die Menge das zulässt. Daraus ist aber keine pauschale Empfehlung gegen Seitenzahlen abzuleiten, denn bei Hunderten Produkten bleibt die Aufteilung für Nutzer die übersichtlichere Variante. Jede Alternative verschiebt das Problem lediglich an eine andere Stelle, meist in Richtung Ladezeit oder Crawlbarkeit. Welche Lösung passt, hängt von Sortimentsgröße, Technik und Nutzerverhalten ab.

View-All-Seite

Die Gesamtansicht zeigt alle Produkte einer Kategorie auf einer einzigen URL. Sie verflacht die Struktur maximal, weil jedes Produkt nur einen Klick von der Kategorie entfernt liegt. Zugleich erübrigt sich die Frage nach Canonical und Indexierung der Folgeseiten. Der Preis ist die Ladezeit, denn Hunderte Produktbilder, ein großer DOM und schwere Datenbankabfragen belasten die Core Web Vitals. Lazy Loading für Bilder und Caching fangen einen Teil davon auf, ab einigen hundert Artikeln stößt die Variante aber an ihre Grenzen.

Infinite Scroll

Beim endlosen Scrollen laden weitere Produkte automatisch nach, sobald der Nutzer das Ende der Liste erreicht. Auf dem Smartphone fühlt sich das natürlich an, hat aber zwei bekannte Schwächen. Der Footer mit Service-Links wird kaum erreichbar, und die Position in der Liste lässt sich weder speichern noch teilen. Für Suchmaschinen bleibt der nachgeladene Inhalt unsichtbar, sofern nicht parallel echte URLs mit href-Links existieren. Genau für diesen Fall empfiehlt Google in seinen Hinweisen zu Lazy Loading, die Adresszeile beim Scrollen per History API auf die jeweilige Seiten-URL zu aktualisieren, damit jeder Abschnitt eine eigene, verlinkbare Adresse behält.

Load-More-Button

Der Button „Mehr laden” ist die entschärfte Form des Infinite Scroll, weil Nutzer weitere Produkte aktiv anfordern und der Footer jederzeit erreichbar bleibt. Technisch gelten dieselben Anforderungen, denn auch hier existiert ohne href-Links im HTML keine Folgeseite für den Crawler. Zusätzlich vertieft ein reiner Button die Struktur, weil er immer nur zur jeweils nächsten Seite führt und keinen Sprung zu Seite 6 erlaubt. Bei kleinen bis mittleren Kategorien mit wenigen Seiten ist er trotzdem eine gute Wahl.

Hybrid: Load-More kombiniert mit Seitenzahlen

Button und nummerierte Navigation zusammen verbinden den Komfort des Nachladens mit den Vorteilen der Seitenzahlen. Nutzer klicken auf „Mehr laden”, während darunter oder im Quellcode die Links zu Seite 2 bis 6 stehen bleiben. Crawler erreichen so jede Seite mit wenigen Schritten, und Besucher merken von der Technik nichts. Große Shops setzen dieses Muster seit Jahren ein, weil es die Klicktiefe gering hält, ohne die mobile Bedienung zu verschlechtern.

Wie viele Produkte pro Seite sind sinnvoll?

Zwischen 30 und 48 Artikel pro Seite haben sich als Kompromiss bewährt, weil die Ladezeit bei diesem Wert stabil bleibt und die Serie trotzdem kurz ausfällt. Diesen Hebel übersehen viele Betreiber, obwohl er nur eine Einstellung braucht. Schon die Erhöhung von 16 auf 32 Artikel halbiert die Seitenzahl und damit die Klicktiefe aller dahinterliegenden Produkte.

Unter 20 Artikeln entstehen bei mittelgroßen Kategorien schnell zweistellige Seitenzahlen, über 48 Artikeln leidet die Ladezeit selbst mit Lazy Loading. Ergänzend lassen sich umfangreiche Kategorien in Unterkategorien aufteilen, sodass jede Liste kürzer wird und zugleich neue Landingpages für spezifischere Suchbegriffe entstehen. Beide Maßnahmen wirken sofort und sind in jedem Shopsystem über die Einstellungen erreichbar.

Alle Varianten im Vergleich

Vier Kriterien geben in der Praxis den Ausschlag, und nach ihnen bewertet die folgende Tabelle alle Varianten

Variante	SEO-Eignung	Crawlbarkeit	Technischer Aufwand	Nutzerfreundlichkeit
Nummerierte Seitenfolge	hoch	hoch, wenn Links im HTML stehen	gering	gut am Desktop, mittel mobil
View-All-Seite	hoch bei kleinen Kategorien	vollständig	mittel (Performance)	gut bis etwa 100 Artikel
Infinite Scroll	gering ohne Zusatz-URLs	gering ohne History API	hoch	stark mobil, Footer unerreichbar
Load-More-Button	mittel	mittel, nur nächste Seite	mittel	gut
Hybrid Button plus Seitenzahlen	hoch	hoch	mittel bis hoch	stark auf allen Geräten
Mehr Artikel pro Seite	hoch	hoch	minimal	gut bis etwa 48 Artikel

Entscheidungshilfe: Welche Lösung passt zu welcher Website?

Bis etwa 100 Produkte pro Kategorie ist die Gesamtansicht meist die beste Wahl, weil sie die Struktur vollständig verflacht und die Ladezeit noch beherrschbar bleibt. Zwischen 100 und rund 500 Produkten empfehlen wir die nummerierte Seitenfolge mit 30 bis 48 Artikeln pro Seite und selbstreferenzierenden Canonicals, ergänzt um einen Load-More-Button für mobile Nutzer. Ab mehreren hundert Produkten lohnt sich eine Aufteilung in Unterkategorien, weil sonst selbst die beste Navigation zweistellige Seitenzahlen erzeugt. Blogs und Archive kommen fast immer mit der einfachen Seitenfolge aus, da ihre Übersichtsseiten ohnehin nicht ranken sollen. Infinite Scroll ohne parallele URLs bleibt in jedem dieser Fälle die schlechteste Option..

Paginierung in WordPress, Shopify und Co. umsetzen

Wie sich die beschriebenen Regeln umsetzen lassen, hängt stark vom eingesetzten System ab. Jedes CMS und jede Shop-Software bringt ein eigenes URL-Muster mit, setzt Canonicals nach eigener Logik und verwaltet die Anzahl der Artikel pro Seite an einer anderen Stelle. Einige Systeme erzeugen von Haus aus problematische Strukturen, die sich nur mit Erweiterungen oder Entwicklungsarbeit korrigieren lassen. Andere liefern brauchbare Standards und scheitern erst an den Themes, die Entwickler darüberlegen. Vor jeder Optimierung lohnt sich ein Blick in den Quellcode einer Folgeseite, um Canonical, Robots-Angabe und Links zu prüfen. Alle Angaben zu den einzelnen Systemen beziehen sich auf den Stand September 2026 und können sich mit Updates ändern, bei Shopify wegen der halbjährlichen Editions besonders schnell.

01

WordPress und WooCommerce

WordPress erzeugt Archivseiten standardmäßig unter /page/2/, /page/3/ und so weiter, sowohl für Blog-Kategorien als auch für WooCommerce-Produktkategorien. Unter „Einstellungen, Lesen” lässt sich die Anzahl der Beiträge pro Seite festlegen, WooCommerce steuert die Produkte pro Seite über den Customizer. Yoast SEO setzt auf Folgeseiten ein selbstreferenzierendes Canonical und ergänzt rel=next und rel=prev.

Die Option „noindex für Unterseiten von Archiven” hat der Hersteller laut seiner Hilfeseite zu noindex schon mit Version 6.3 entfernt, weil dauerhaftes noindex das Crawling der Folgeseiten mit der Zeit zum Erliegen bringt. Rank Math bietet diese Option nach wie vor an, sie sollte ausgeschaltet bleiben. Über die Variable %%page%% in der Title-Vorlage trägt jede Folgeseite ihre Seitenzahl im Title. Nötig ist das für Google nicht, die Berichte in der Search Console werden damit aber lesbarer. Fast alle Themes geben die Links zu den Folgeseiten als echte href-Angaben im HTML aus, was die Crawlbarkeit sichert.

02

Shopware

Shopware 6 hängt die Seitenzahl als Parameter an die Kategorie-URL, etwa /schuhe/?p=2, und setzt auf jeder Seite ein Canonical auf sich selbst. In den Einstellungen des jeweiligen Verkaufskanals ist die Anzahl der Produkte pro Listing hinterlegt und lässt sich ohne Entwicklungsaufwand erhöhen. Beim Blättern lädt die Produktliste per AJAX nach, die nummerierten Links stehen aber im HTML, sodass der Googlebot die Serie ohne Umweg findet.

Zu prüfen bleibt, ob das Theme den Kategorietext auf allen Seiten ausspielt oder nur auf der ersten. Das hängt vom eingesetzten Template ab, nicht vom Kern. Bei größeren Katalogen stimmt eine Shopware SEO Agentur diesen Wert mit der Ladezeit der Listing-Seiten ab.

03

Shopify

Shopify nutzt den Parameter ?page=2 und liefert in den Standard-Themes selbstreferenzierende Canonicals aus. Über den Liquid-Tag paginate bestimmt das Theme die Anzahl der Produkte pro Seite, wobei die Plattform laut der Liquid-Referenz zu paginate zwischen 1 und 250 Einträgen pro Seite erlaubt. Viele gekaufte Themes stellen einen deutlich niedrigeren Wert ein, der sich im Theme-Code anpassen lässt und nach einem Theme-Update erneut geprüft werden sollte.

Apps für Infinite Scroll sind beliebt, entfernen aber häufig die nummerierten Links und taugen nur, wenn die HTML-Navigation erhalten bleibt. Den Wert im Theme-Code legt eine Shopify SEO Agentur passend zur Sortimentsgröße fest.

07

JTL

JTL-Shop verlinkt in der Standardkonfiguration nur wenige Artikel pro Seite und zeigt in der Navigation lediglich die jeweils vier vorherigen und nächsten Seiten. Beides zusammen erzeugt bei großen Sortimenten lange Serien, die Nutzer und Crawler nur mühsam durchlaufen. In den Einstellungen zur Artikelübersicht lassen sich die Artikel pro Seite erhöhen, die Navigationsdarstellung hängt vom Template ab. Gerade bei JTL-Shops zeigt die Search Console besonders oft Folgeseiten mit dem Status „Gecrawlt, zurzeit nicht indexiert”.

06

Magento

Magento und die Nachfolgeplattform Adobe Commerce verwenden ?p=2 als Seitenparameter und erlauben in der Konfiguration eine Auswahl an Werten für Produkte pro Seite. Das Canonical Tag für Kategorien muss laut der Adobe-Dokumentation zu Metadaten in den Katalogeinstellungen erst aktiviert werden, in der Grundeinstellung fehlt es auf jeder Listing-Seite. Nach der Aktivierung zeigt es auf die Kategorie-URL, weshalb ein Blick in den Quellcode einer Folgeseite klären muss, ob der Seitenparameter darin erhalten bleibt oder alle Seiten auf Seite 1 kanonisiert werden. Sortier- und Limit-Parameter hängen sich an dieselbe URL, was ohne saubere Konfiguration schnell mehrere URLs für dieselbe Seite erzeugt. Hinzu kommt die Filterlogik des Systems, die die Trennung von Facetten und Seitenzahlen zusätzlich erschwert.

05

TYPO3

In TYPO3 gibt es keine einheitliche Seitenzahl-Logik, weil sie von der jeweiligen Extension abhängt, etwa von der News-Erweiterung oder einem Shop-Modul. Häufig erscheint die Seite als Parameter im Muster tx_news_pi1[currentPage]=2, was kryptisch wirkt und sich über die Routing-Konfiguration in lesbare Pfade übersetzen lässt. Laut TYPO3-Dokumentation setzt die Systemerweiterung seo automatisch ein Canonical, das der Basis-URL der Seite entspricht. Parameter einer Extension wie die Seitenzahl fließen nur ein, wenn die Extension sie als kanonisierbare Parameter registriert, andernfalls zeigt das Canonical aller Folgeseiten auf Seite 1, was dem beschriebenen Fehler entspricht.

04

Joomla

Joomla bildet Seitenzahlen über den Parameter ?start=10, ?start=20 ab, wobei der Wert der Anzahl übersprungener Einträge entspricht. Dadurch ist die erste Seite sowohl unter der Kategorie-URL als auch unter ?start=0 erreichbar, was ein klassisches Duplikat erzeugt. Für diese Variante liefert der Kern kein Canonical mit, sodass eine SEO-Erweiterung oder eine Anpassung im Template nötig wird. Über die Menüeinstellungen der Kategorie lassen sich die Einträge pro Seite ändern.

Typische Fehler bei der Paginierung

Fast alle Probleme mit paginierten Seiten gehen auf eine kleine Zahl wiederkehrender Fehler zurück. Auf der Liste der SEO Fehler, die Onlineshops Sichtbarkeit kosten, stehen sie weit oben, obwohl sie selten auffallen. Manche entstehen durch Voreinstellungen des Systems, andere durch gut gemeinte Optimierung nach veralteten Anleitungen. Mit einem Blick in den Quellcode einer Folgeseite und in den Indexierungsbericht der Search Console lassen sich die meisten erkennen. Dabei lohnt es sich, neben Seite 2 auch Seite 1 und die letzte Seite zu betrachten, weil sich Fehler oft nur an den Rändern einer Serie zeigen. Die folgenden acht Muster tauchen in nahezu jeder SEO Analyse eines größeren Shops auf, und jedes davon lässt sich mit überschaubarem Aufwand beheben.

Sortierung und Seitenzahl in einer URL vermischt

Bietet eine Kategorie drei Sortierungen und zehn Seiten, entstehen aus einer einzigen Liste dreißig URLs, sobald Sortier- und Seitenparameter kombiniert werden. Jede davon zeigt dieselben Produkte in anderer Reihenfolge, und Google muss alle crawlen, um das zu erkennen. Sortierte Varianten gehören per Canonical auf die Standardsortierung derselben Seite, während der Seitenparameter unverändert bleibt. Google empfiehlt für Sortier- und Filtervarianten zusätzlich noindex oder eine robots.txt-Sperre des jeweiligen Parameters, wohlgemerkt nur für den Sortierparameter, nie für die Seitenzahl selbst. Lässt sich beides im System nicht steuern, hilft es, die Sortierung per Script ohne eigene URL umzusetzen, damit gar keine Kombinationen entstehen.

noindex,follow als vermeintlicher Kompromiss

Viele Anleitungen empfehlen noch immer, Folgeseiten mit noindex,follow zu versehen, und der Schaden zeigt sich erst mit Verzögerung. Nach einigen Monaten sinkt die Zahl der indexierten Produkte, weil Google die Folgeseiten nicht mehr crawlt und die Links darauf verliert. Die Rückkehr zu index,follow mit selbstreferenzierendem Canonical behebt die Ursache, bringt die Produkte aber nicht sofort zurück. Bis Google die Folgeseiten wieder regelmäßig besucht, hilft ein Eintrag in der Sitemap und eine Verlinkung aus anderen Bereichen.

/page/1/ als Duplikat der Kategorie-URL

Verlinkt die Navigation von Seite 2 zurück auf /schuhe/page/1/ statt auf /schuhe/, existiert die erste Seite doppelt. Beide URLs zeigen denselben Inhalt und konkurrieren miteinander, wobei die Linkkraft sich aufteilt. Die Variante mit Seitenzahl gehört über eine 301 Weiterleitung auf die Kategorie-URL umgeleitet, ergänzt um eine Korrektur der Navigationslinks. Alternativ genügt ein Canonical von /page/1/ auf die Kategorie, sofern das System keine Weiterleitung erlaubt.

Kategorietext auf allen Folgeseiten

Wird der Beschreibungstext der Kategorie auf jeder Seite der Serie ausgespielt, entstehen Near Duplicates mit identischem Textblock. Typisches Symptom ist eine Serie, in der Google willkürlich Seite 3 oder 5 für den Kategoriebegriff anzeigt. Der Text gehört ausschließlich auf Seite 1, während die Folgeseiten sich auf die reine Produktliste beschränken. Wie Kategorietext, Title und Produktliste auf einer Seite zusammenspielen, ist eine Frage des OnPage SEO, und meist ist die Korrektur eine Template-Anpassung von wenigen Zeilen.

Zu wenige Artikel pro Seite

Zwölf oder sechzehn Produkte pro Seite waren einmal Standard, erzeugen heute aber unnötig lange Serien. Zweistellige Seitenzahlen bei mittelgroßen Kategorien fallen dann ebenso auf wie Produkte, die im Indexierungsbericht als „Gefunden, zurzeit nicht indexiert” auftauchen. Mehr Artikel pro Seite, kombiniert mit Lazy Loading für die Bilder, beheben den Fehler in Minuten und wirken auf jede Kategorie gleichzeitig. Je nach System heißt die Einstellung „Beiträge pro Seite”, „Products per Page” oder „Artikel pro Seite” und liegt fast immer in den Grundeinstellungen des Shops.

Paginierung per robots.txt gesperrt

Disallow-Regeln für Muster wie /*?page= in der robots.txt sollen Crawl Budget sparen. Damit bekommt Google aber weder die Folgeseiten noch die Links darauf je zu sehen. Im Index erscheinen dann URLs ohne Snippet, und Produkte werden trotz Sitemap nicht gecrawlt. Statt dieser Regel läuft die Steuerung besser über Canonical und Artikel pro Seite. In die robots.txt gehören ausschließlich Bereiche, die nie in den Index sollen, etwa Warenkorb oder Kundenkonto.

Seiten hinter der letzten Seite antworten mit Status 200

Ruft jemand Seite 99 einer Kategorie auf, die nur acht Seiten hat, liefern viele Systeme eine leere Produktliste mit dem Statuscode 200 aus. Im Indexierungsbericht meldet Google diese Seiten als Soft 404, crawlt sie aber weiter, sobald irgendwo ein alter Link oder ein Sitemap-Eintrag darauf zeigt. Bei schrumpfenden Sortimenten entstehen so Dutzende leere Seiten, die Crawling binden und nichts zurückgeben. Systeme sollten für Seitenzahlen außerhalb des Bereichs einen echten 404-Status liefern oder auf die letzte gültige Seite weiterleiten. Der Aufruf einer Seitenzahl weit jenseits des Sortiments zeigt, ob das eigene System das richtig macht.

Seitenzahl im URL-Fragment statt in der URL

Manche Frontend-Frameworks hängen die Seitenzahl als Fragment an, etwa als page=3 hinter einem Rautezeichen am Ende der Kategorie-URL, weil sich dieser Teil ohne Neuladen ändern lässt. Google ignoriert Fragmente bei der Indexierung vollständig und behandelt alle Varianten als ein und dieselbe URL, sodass die gesamte Serie für die Suche nur als Seite 1 existiert. Findet der Googlebot einen Link, der sich nur hinter dem Rautezeichen unterscheidet, folgt er ihm laut Paginierungs-Dokumentation oft gar nicht, weil er die Seite für bereits abgerufen hält. Abhilfe schafft ein echter Parameter wie ?page=3 oder ein Pfad wie /page/3/, den das Framework über die History API setzen kann, ohne den Komfort des Nachladens aufzugeben. Identische Meta Title und Meta Description auf allen Seiten sind dagegen kein Fehler, Google erlaubt sie für paginierte Serien ausdrücklich.

Woran Sie erkennen, dass Ihre Paginierung Unterstützung braucht

Die meisten der beschriebenen Maßnahmen lassen sich mit Systemkenntnis und etwas Zeit selbst umsetzen, besonders in WordPress oder Shopify. Sobald das System an seine Grenzen stößt oder das Sortiment zu groß wird, steht der Eigenaufwand aber in keinem Verhältnis mehr zum Ergebnis. Typisch ist die Erkenntnis nach einem Relaunch, dass Rankings für Kategorien eingebrochen sind, ohne dass jemand die Seitenzahlen im Verdacht hätte. Ebenso häufig fällt das Problem erst auf, wenn die Search Console über Wochen steigende Zahlen nicht indexierter URLs meldet. Drei Signale lassen sich in wenigen Minuten selbst prüfen und zeigen zuverlässig an, dass externe Hilfe den schnelleren Weg darstellt.

Die Search Console meldet massenhaft „Gecrawlt, zurzeit nicht indexiert”

Steigt die Zahl der URLs mit diesem Status im Indexierungsbericht kontinuierlich und enthalten die betroffenen Adressen Seitenparameter, bewertet Google die Folgeseiten als wenig wertvoll. Ursache ist meist eine Kombination aus zu vielen Seiten, Thin Content und fehlender interner Verlinkung. Zur Behebung braucht es eine Analyse, welche Produkte betroffen sind und über welche Pfade sie erreichbar bleiben. Diese Bestandsaufnahme gehört zum Standardumfang einer SEO Beratung, weil sie das ganze System betrachtet, nicht nur die Seitenzahlen.

Das Shop-System lässt die nötige Einstellung nicht zu

Manche Systeme bieten keine Option, das Canonical umzustellen oder den Kategorietext auf Seite 1 zu beschränken. Dann braucht es Anpassungen im Template oder eine Erweiterung, was Entwicklungszeit und ein Verständnis der SEO-Wirkung erfordert. Ohne diese Kombination bleiben Änderungen entweder liegen oder bringen unerwünschte Nebenwirkungen mit. Bei JTL, Magento und Joomla ist dieser Fall die Regel, bei Shopware und WordPress die Ausnahme.

Ein Website Relaunch oder Systemwechsel ändert das URL-Muster

Wechselt ein Shop das System, ändert sich fast immer auch das Muster der Seitenzahlen, etwa von ?start=20 auf /page/3/. Ohne Weiterleitungen und angepasste Canonicals verlieren die alten URLs ihre Signale, und Google muss die neue Serie von Grund auf verstehen. Planen Sie diese Umstellung vor dem Livegang und beobachten Sie die Rankings danach über Monate. In dieser Phase verhindert eine SEO Betreuung, dass ein an sich gelungener Website Relaunch Kategorie-Rankings kostet, die vorher jahrelang stabil waren.

Häufige Fragen zur Paginierung

Wie erkenne ich, ob Google meine Folgeseiten indexiert hat?

Die Suche nach site:ihre-domain.de inurl:page= zeigt alle indexierten URLs mit dem Seitenparameter. Detaillierter arbeitet der Indexierungsbericht der Search Console, der unter „Warum Seiten nicht indexiert werden” auch die Gründe für ausgeschlossene Folgeseiten nennt. Noch genauer zeigen die Server-Logfiles, bis zu welcher Seite der Googlebot vorgedrungen ist.

Bis zu welcher Seite crawlt Google eine Serie?

Google nennt keine feste Grenze. Erfahrungsgemäß besucht der Googlebot bei langen Serien nur die ersten fünf bis sieben Seiten regelmäßig, weil er sein Crawl Budget nach der Bedeutung einer Seite verteilt und diese mit jeder Ebene sinkt. Wie Google diese Zeit bemisst, beschreibt der Leitfaden zum Crawling-Budget, der ausdrücklich auch Websites mit vielen als „Gefunden, zurzeit nicht indexiert” markierten URLs anspricht. Produkte dahinter brauchen zusätzliche Links aus Ratgebern, verwandten Produkten oder Startseiten-Modulen.

Gehören paginierte Seiten in die XML-Sitemap?

In der Regel nicht. Nur die Kategorie-URL selbst gehört in die Sitemap, die Folgeseiten findet Google über die internen Links. Ausnahmen sind Serien, deren Links nur per JavaScript erreichbar sind, wobei die Sitemap dann ein Notbehelf und keine Lösung ist.

Gehört die Paginierung oben oder unten auf die Seite?

Unten, direkt nach der Produktliste, weil Nutzer erst blättern, wenn sie die sichtbaren Produkte gesehen haben. Große Shops zeigen die Seitenzahlen zusätzlich oben, damit Nutzer nicht scrollen müssen, um zu Seite 5 zu springen. Dem Crawler ist die Position gleichgültig, solange die Links im HTML stehen.

Was ist logarithmische Paginierung?

Bei langen Serien verlinkt die Navigation neben den Nachbarseiten auch Sprungziele in wachsenden Abständen, etwa Seite 2, 5, 10, 25 und 50. Crawler und Nutzer erreichen so jede Seite mit wenigen Klicks statt mit Dutzenden. Das Muster lohnt sich ab etwa 20 Seiten pro Kategorie und ist in den meisten Systemen eine Template-Anpassung.