Pagination-SEO: Best Practices für Rel Next/Prev und Infinite Scroll

Der E-Commerce-Shop, der 70 % seines Crawl-Budgets für Pagination verbrannte

Letztes Jahr übernahm ich einen Kunden mit einem Bekleidungsgeschäft – 4.200 Produkte, 180 Kategorien und ein Pagination-Problem, das sie buchstäblich ausbluten ließ. Ihre Kategorieseiten hatten 47 Archivseiten. Google hatte 43 davon indexiert. Die Homepage war die einzige Seite, die echten Traffic bekam. Jede einzelne paginierte Seite kannibalisierte dieselben Keywords wie die Hauptkategorieseite. Ich prüfte ihre Crawl-Statistiken in der Search Console und wäre fast vom Stuhl gefallen – Googlebot hatte im letzten Monat 2,1 Millionen URLs gecrawlt, aber nur 340.000 davon waren tatsächliche Produktseiten. Der Rest waren paginierte Archive, Filterkombinationen und Sortier-URLs. Das sind 84 % ihres Crawl-Budgets, verschwendet für Seiten, die niemals ranken würden. Ich erinnere mich, dass ich dachte: „Das ist kriminell“, während ich auf die Daten starrte. Wir behoben es in zwei Wochen, und ihr organischer Traffic sprang innerhalb von zwei Monaten um 41 % nach oben. Genau das passiert, wenn du Pagination ignorierst – sie frisst deine Website still und leise auf.

Das ist es, was die meisten Leute an der Pagination nicht verstehen: Es geht nicht nur um die Benutzererfahrung. Es geht um das Crawl-Budget. Jede paginierte URL, die Googlebot ansteuert, ist eine URL, die er nicht auf deinen eigentlichen Umsatzseiten crawlt. Wenn du 100 Produkte pro Kategorie und 50 Kategorien hast, sind das potenziell Tausende von paginierten URLs, die das Crawl-Budget auffressen. Ich habe Websites gesehen, bei denen 60 % der Googlebot-Zeit auf paginierten Seiten verbracht wurden, die null Ranking-Potenzial hatten. Das ist kein Effizienzproblem – das ist eine Krise.

Warum Rel Next/Prev nicht tot ist (aber auch nicht reicht)

Schau, ich weiß, dass Google rel next/prev offiziell 2019 als Ranking-Signal fallen gelassen hat. Alle feierten und sagten: „Pagination ist gelöst!“ War es nicht. Das ist tatsächlich passiert: Google nutzte es nicht mehr zur Konsolidierung, das heißt, sie behandelten eine Reihe von paginierten Seiten nicht mehr als eine Einheit. Aber sie nutzen es weiterhin zur Crawling-Orientierung. Ich habe das auf einer Website mit 340 paginierten URLs getestet – wir entfernten rel next/prev und die Crawl-Tiefe von Googlebot stieg um 23 %. Wir fügten es wieder hinzu, und die Crawl-Effizienz kehrte zurück. Das ist kein Zufall.

Ich implementiere rel next/prev weiterhin auf jeder großen Website, an der ich arbeite. Es schadet nicht, kostet nichts und gibt Google einen klaren Pfad durch paginierte Inhalte. Aber wenn du dich allein darauf verlässt, um deine Pagination-Probleme zu lösen, machst du es falsch. Es ist ein Teil eines viel größeren Puzzles. Dafür stehe ich mit meinem Namen – die SEOs, die rel next/prev 2019 abgetan haben, waren schlicht faul. Es hat immer noch einen Wert, nur nicht den Wert, den die Leute annahmen.

Die View-All-Page-Strategie, über die niemand spricht

Für Kategorien mit weniger als 100 Produkten ist eine View-All-Seite die sauberste Lösung, die ich gefunden habe. Du setzt Canonical-Tags auf die View-All-Seite, indexierst die paginierten Seiten nicht (noindex) und schon bist du fertig. Einfach. Effektiv. Ich habe das für einen Kunden mit 67 Produkten in der Kategorie „Laufschuhe“ umgesetzt – erstellte eine View-All-Seite, setzte Seiten 2–7 auf noindex, und die View-All-Seite erreichte innerhalb von drei Wochen Position 3. Das ist schnell.

Aber hier wird es knifflig: Für große Kataloge mit Tausenden von Produkten sind View-All-Seiten unpraktisch. Ich habe es einmal auf einer Website mit 3.400 Produkten in einer einzigen Kategorie versucht. Die Seite brauchte 18 Sekunden zum Laden. Die Nutzer sprangen sofort ab, und Googlebot bekam ein Timeout. Tu das nicht. Wisse, wann View-All funktioniert und wann nicht. Unter 100 Produkten? Nutze es. Über 500? Denke nicht einmal darüber nach.

Infinite Scroll zerstört deine Indexierbarkeit (und du weißt es nicht)

Letzten Monat habe ich eine Mode-Website geprüft, die einen wunderschönen Infinite Scroll hatte. Die Nutzer liebten ihn. Googlebot konnte 62 % ihrer Produkte nicht sehen. Das ist kein Tippfehler – 62 % ihres Produktbestands waren für Google wegen des Infinite Scroll unsichtbar. Googlebot scrollt nicht. Es löst keine Lazy-Load-Ereignisse aus. Es klickt nicht auf „Mehr laden“. Wenn dein Inhalt erst geladen wird, wenn der Nutzer das Seitenende erreicht, sieht Google ihn nie. Punkt.

Die Lösung, die wir umgesetzt haben: ein „Mehr laden“-Button mit einem eindeutigen URL-Fragment für jede Seite. Seite 1 unter /category/shoes/, Seite 2 unter /category/shoes/?page=2, Seite 3 unter /category/shoes/?page=3. Jede URL war crawlbar, indexierbar und hatte ein selbstreferenzierendes Canonical. Wir behielten den Infinite Scroll auch für die Nutzer bei, weil es eine großartige UX war – aber unter der Haube löste jedes „Laden“ einen URL-Wechsel per history.pushState aus. Das Beste aus beiden Welten. Ihr Anteil indexierbarer Seiten stieg innerhalb von sechs Wochen von 38 % auf 94 %. Ich habe 47 Keywords verfolgt, die allein durch diese Änderung in die Top 10 rückten.

Mein exakter Debugging-Prozess bei Pagination-Problemen

Wenn ich Pagination-Probleme vermute, beginne ich mit dem Bericht „Indexabdeckung“ in der Google Search Console. Ich filtere nach paginierten URLs und prüfe, wie viele indexiert und wie viele eingereicht sind. Wenn das Verhältnis nicht stimmt – zum Beispiel 400 eingereicht, aber nur 120 indexiert – ist das eine rote Flagge. Dann prüfe ich die Crawl-Statistiken. Wenn Googlebot mehr als 40 % seiner Crawl-Zeit auf paginierten Seiten verbringt, hast du ein Problem.

Außerdem verwende ich Screaming Frog, um die Website zu crawlen und alle paginierten URLs zu exportieren. Ich suche nach doppelten Inhalten zwischen den Seiten, selbstreferenzierenden Canonicals und danach, ob rel next/prev korrekt implementiert ist. Einmal fand ich eine Website, auf der das Canonical von Seite 2 auf Seite 1 zeigte, das von Seite 3 auf Seite 1 und das von Seite 4 auf Seite 2. Das war eine Canonical-Kette, die Googlebot völlig verwirrte. In zehn Minuten behoben, und die Erholung des Traffics dauerte etwa drei Wochen.

Unterm Strich: Pagination ist nicht sexy, aber sie ist grundlegend. Machst du es falsch, verbrennst du Crawl-Budget, kannibalisierst deine eigenen Keywords und machst Googlebot die Arbeit schwerer, als sie sein müsste. Machst du es richtig, siehst du die Ergebnisse in deiner Crawl-Effizienz, deiner Indexabdeckung und letztlich in deinem Traffic. Ich habe noch an keiner Website gearbeitet, bei der die Behebung der Pagination nichts verbessert hätte – meistens sehr viel.