Paginierte Seiten nicht indexiert: Moderne Pagination-Strategien für Google
Google hat rel=prev/next abgeschafft, und deine paginierten Inhalte sind aus dem Index gefallen. Lerne moderne Pagination-Strategien kennen, die mit Googles aktuellem Indexierungs-Verhalten funktionieren.
In dieser Anleitung
Pagination ist überall im Web. Blog-Archive, E-Commerce-Kategorieseiten, Suchergebnis-Listings, Forum-Thread-Indizes, News-Archive und Bildergalerien nutzen Pagination, um große Content-Sets in handhabbare Seiten zu unterteilen. Jahrelang war der Standard-Ansatz, rel=prev- und rel=next-Tags zu implementieren, um Google zu sagen, dass eine Reihe von Seiten eine paginierte Serie bildet. Google würde dann die Beziehung verstehen und Indexierungs-Signale angemessen konsolidieren.
Im März 2019 bestätigte Google, dass es rel=prev/next seit Jahren nicht mehr als Indexierungs-Signal genutzt hat. Diese Ankündigung erwischte die SEO-Branche auf dem falschen Fuß, weil viele Sites ihre gesamte Pagination-Strategie um diese Tags herum gebaut hatten. Die praktische Auswirkung war sofort: Ohne rel=prev/next behandelt Google jede paginierte Seite als unabhängige, eigenständige Seite statt als Teil einer verbundenen Serie.
Diese Änderung heißt, dass Seite 2 deines Blog-Archivs von Google ausschließlich anhand ihrer eigenen Verdienste bewertet wird. Zeigt Seite 2 eine Liste von Blogbeitrags-Auszügen ohne einzigartigen einleitenden Content, ohne einzigartige Überschrift und ohne Kontext, der erklärt, worum es auf der Seite geht, sieht Google eine dünne Seite mit recycelten Content-Snippets. Es sollte nicht überraschen, dass Google diese Seiten oft nicht indexiert.
Die Konsequenzen reichen über die paginierten Seiten selbst hinaus. Content, der nur auf tieferen Pagination-Seiten erscheint, wird für Google schwerer zu entdecken. Wird ein Produkt oder Blogbeitrag nicht auf Seite 1 irgendeines Listings gezeigt und ist auch sonst nirgendwo verlinkt, kann er effektiv zu einem Waisen werden, den Google nie crawlt. Das macht Pagination nicht nur zu einem Problem von Listing-Seiten, sondern zu einem Content-Discovery-Problem für deine gesamte Site.
Dieser Guide behandelt moderne Pagination-Strategien, die mit Googles aktuellem Indexierungs-Verhalten funktionieren, adressiert die spezifischen Herausforderungen von Infinite-Scroll- und Load-More-Mustern und bietet konkrete Fixes, um Content zurückzugewinnen, der verloren ging, als rel=prev/next nicht mehr funktionierte.
Was sich änderte, als Google rel=prev/next abschaffte
Um den aktuellen Stand der Pagination-Indexierung zu verstehen, hilft es zu wissen, was rel=prev/next bewirken sollte und was Google tatsächlich jetzt tut.
Rel=prev/next war ein Satz von HTML-Link-Elementen, die Google sagten, dass eine Reihe von Seiten als paginierte Sequenz verbunden ist. Die Absicht war, dass Google die Seiten konsolidiert und versteht, dass Seite 1, Seite 2, Seite 3 und so weiter ein zusammenhängendes Set bilden. Theoretisch würde Google die Serie als einzelne logische Einheit behandeln, Link-Equity konsolidieren und möglicherweise nur die erste Seite in Suchergebnissen zeigen, während es versteht, dass der Inhalt über nachfolgende Seiten fortgesetzt wird.
Als Google offenbarte, dass es diese Signale seit Jahren nicht mehr nutzte, war die Implikation klar: Google verließ sich auf andere Signale, um Pagination zu verstehen. Diese Signale umfassen URL-Muster (Google kann gängige Pagination-Muster wie ?page=2 oder /page/2/ erkennen), interne Link-Strukturen (sequenzielle Links zwischen Seiten suggerieren Pagination) und Content-Analyse (Seiten mit ähnlichen Templates und verschiedenen Content-Untergruppen suggerieren eine paginierte Liste).
Die praktische Verhaltensänderung ist, dass Google jetzt jede paginierte Seite unabhängig bewertet. Seite 1 deiner Kategorie mit einem einzigartigen einleitenden Absatz, starken internen Links und 20 vorgestellten Produkten kann indexiert werden. Seite 2, die die nächsten 20 Produkte ohne einzigartigen Content zeigt, wird als eigenständige Seite bewertet und kann nicht indexiert werden, weil sie eigenständig nicht genug einzigartigen Mehrwert bietet.
Diese unabhängige Bewertung heißt, dass paginierte Seiten nach Seite 1 selten indexiert werden, es sei denn, sie haben ein einzigartiges Wert-Angebot. Die Items, die auf Seite 2 gelistet sind, unterscheiden sich von Seite 1, aber das Template, die Navigation, die Meta-Informationen und die Gesamtstruktur sind identisch. Aus Googles Sicht ist Seite 2 eine dünne Variation von Seite 1.
Der Verlust der rel=prev/next-Konsolidierung heißt auch, dass Link-Equity nicht mehr über paginierte Seiten konsolidiert wird. Früher konnte ein Backlink, der auf Seite 3 deiner Kategorie zeigt, der gesamten paginierten Serie zugutekommen. Jetzt bleibt diese Link-Equity allein auf Seite 3. Ist Seite 3 nicht indexiert, ist die Link-Equity effektiv verschwendet.
Googles aktuelle Empfehlung für Pagination ist, sicherzustellen, dass wichtige einzelne Content-Seiten (Produkte, Artikel, Beiträge) direkt aus deiner Sitemap und von anderen Seiten deiner Site verlinkbar sind, statt von Pagination als einzigem Discovery-Pfad abhängig zu sein. Pagination ist jetzt primär ein User-Experience-Feature statt eines SEO-Features.
Infinite Scroll: Das Problem unsichtbaren Contents
Infinite Scroll ersetzt traditionelle Pagination durch ein Muster, bei dem neuer Content automatisch lädt, sobald der Nutzer nach unten scrollt. Nutzer erleben einen nahtlosen, endlosen Feed. Aus SEO-Sicht ist Infinite Scroll eines der problematischsten Pagination-Muster, weil Googles Crawler nicht scrollt.
Wenn Googlebot eine Seite mit Infinite Scroll lädt, verarbeitet er das initiale HTML und jeden JavaScript-gerenderten Content, der beim ersten Laden erscheint. Er löst keine Scroll-Events aus, was heißt, dass jeder Content, der beim Scrollen über eine bestimmte Schwelle hinaus lädt, für Google komplett unsichtbar ist. Zeigt deine Kategorieseite 20 Produkte beim initialen Laden mit Infinite Scroll für die verbleibenden 200 Produkte, sieht Google nur 20 Produkte.
Das hat schwerwiegende Konsequenzen für die Content-Discovery. Produkte oder Beiträge, die nur über Infinite Scroll erscheinen, haben keinen Crawl-Pfad von der Kategorieseite. Sind sie nicht von anderen Seiten verlinkt oder in der Sitemap enthalten, kann Google sie nie entdecken. Selbst wenn sie in der Sitemap sind, bietet die Kategorieseite selbst keinen internen Link zu diesen Items, was ihre wahrgenommene Wichtigkeit schwächt.
Der empfohlene Fix ist, Infinite Scroll zusammen mit traditionellen paginierten URLs zu implementieren. Dieser hybride Ansatz bietet das reibungslose Nutzererlebnis von Infinite Scroll, während er Google crawlbare paginierte Seiten mit echten URLs gibt. Die Implementierung funktioniert so: Erstelle traditionelle paginierte URLs (/kategorie/page/2/, /kategorie/page/3/), die dieselben Content-Sets wie jedes Infinite-Scroll-Segment anzeigen. Wenn ein Nutzer scrollt und neuer Content lädt, nutze die History API, um die Browser-URL auf die entsprechende paginierte URL zu aktualisieren. Aktualisiert oder teilt der Nutzer die URL, sieht er die paginierte Version mit dem Content, zu dem er gescrollt hatte.
Google empfiehlt diesen pushState-Ansatz für Infinite Scroll ausdrücklich. Die paginierten URLs dienen als Ankerpunkte, die Google crawlen kann, während Infinite Scroll das von deinen Besuchern erwartete Nutzererlebnis bietet. Ohne die zugrunde liegenden paginierten URLs verbirgt Infinite Scroll allen Content jenseits des ersten sichtbaren Sets vollständig vor Google.
Ein alternativer Ansatz für kleinere Content-Sets ist, allen Content auf einer einzigen Seite ohne jegliche Pagination oder Scroll-basiertes Laden zu laden. Hat deine Kategorie 50 Produkte oder weniger, eliminiert das Rendern aller auf einer einzelnen Seite das Pagination-Problem vollständig. Dieser Ansatz ist für Kategorien mit Hunderten oder Tausenden Items wegen Performance-Beschränkungen nicht praktikabel, funktioniert aber gut für kleinere Sammlungen.
Load-More-Buttons: Besser als Infinite Scroll, aber immer noch problematisch
Load-More-Buttons sind ein Mittelweg zwischen traditioneller Pagination und Infinite Scroll. Der Nutzer sieht ein initiales Content-Set und klickt einen Button, um zusätzlichen Content auf dieselbe Seite zu laden. Aus User-Experience-Sicht wird Load More oft gegenüber traditioneller Pagination bevorzugt, weil es den Nutzer auf derselben Seite hält und die Scroll-Position beibehält.
Load-More-Buttons haben jedoch dasselbe grundlegende SEO-Problem wie Infinite Scroll: Google klickt keine Buttons. Content, der von einem Load-More-Button geladen wird, wird durch ein Klick-Event ausgelöst, und Googles Renderer simuliert keine Klick-Interaktionen. Der Content hinter dem Load-More-Button ist für Google unsichtbar, es sei denn, es werden spezifische Maßnahmen ergriffen.
Der Fix spiegelt die Infinite-Scroll-Lösung: Implementiere traditionelle paginierte URLs zusammen mit der Load-More-Funktionalität. Jedes Load-More-Segment sollte einer crawlbaren paginierten URL entsprechen. Nimm Links zu diesen paginierten URLs irgendwo im HTML auf (sie können per CSS aus dem visuellen Design ausgeblendet sein), damit Google sie entdecken und crawlen kann. Manche Implementierungen platzieren die paginierten Links in einem noscript-Tag, sodass sie für Crawler verfügbar sind, die kein JavaScript ausführen, während der Load-More-Button für JavaScript-fähige Browser erscheint.
Ein weiterer Ansatz ist, den Load-More-Content im initialen HTML-Response zu rendern, ihn aber visuell mit CSS auszublenden. Klickt der Nutzer auf Load More, enthüllt JavaScript den versteckten Content, statt ihn vom Server abzurufen. Dieser Ansatz sorgt dafür, dass Google allen Content im initialen HTML sieht, ohne mit Buttons interagieren zu müssen. Allerdings funktioniert das nur für moderate Mengen versteckten Contents (das Laden von 200 Produkten in verstecktem HTML erhöht das Seiten-Gewicht und die Ladezeit erheblich).
Ein dritter Ansatz ist, Load More mit progressiv ladenden paginierten URLs zu implementieren. Die initiale Seite lädt mit dem ersten Content-Set und einem Load-More-Button. Das Klicken des Buttons nutzt AJAX, um das nächste Content-Set abzurufen und anzuzeigen, und aktualisiert gleichzeitig die URL auf die nächste paginierte Seite (/page/2/). Jede paginierte URL rendert ihr spezifisches Content-Set serverseitig, sodass Google /page/2/ direkt crawlen und diesen Content sehen kann, ohne irgendwelche Buttons klicken zu müssen. Der Load-More-Button ist eine progressive Verbesserung für Nutzer, während die zugrunde liegende paginierte URL-Struktur das crawlbare Fundament für Google ist.
Canonical-Tag-Strategie für paginierte Serien
Canonical-Tags auf paginierten Seiten sind eines der am meisten diskutierten Themen in der technischen SEO. Die Frage ist, ob Seite 2, Seite 3 und nachfolgende Seiten Canonical-Tags haben sollten, die auf Seite 1 zeigen, oder ob jede Seite einen selbstreferenzierenden Canonical haben sollte.
Alle paginierten Seiten als Canonical auf Seite 1 zeigen zu lassen, sagt Google, dass Seite 1 die definitive Version ist und andere Seiten sekundär sind. Dieser Ansatz ist passend, wenn du die tieferen Seiten nicht indexiert haben willst oder brauchst und wenn alle einzelnen Items auf andere Weise auffindbar sind (Sitemap, direkte Links). Der Vorteil ist Einfachheit: Google indexiert nur Seite 1, und du sorgst dich nicht um Thin-Content-Probleme auf tieferen Seiten. Das Risiko ist, dass Items, die nur auf tieferen Seiten erscheinen, interne Link-Signale vom paginierten Listing verlieren können.
Selbstreferenzierende Canonicals auf jeder paginierten Seite sagen Google, dass jede Seite eine eigene distinkte Entität ist. Dieser Ansatz ist passend, wenn jede paginierte Seite unterschiedlichen Content anvisiert oder wenn du willst, dass Google alle Seiten der Serie indexiert. Der Vorteil ist, dass jede Seite ihre eigene Link-Equity behält und potenziell in Suchergebnissen erscheinen kann. Das Risiko ist, dass Google tiefere Seiten unabhängig davon als Thin Content sehen und sich entscheiden kann, sie nicht zu indexieren.
Die pragmatische Empfehlung für die meisten Sites ist ein hybrider Ansatz. Seite 1 bekommt einen selbstreferenzierenden Canonical und deinen Optimierungs-Einsatz (einzigartiger einleitender Content, ordentliche Meta-Tags, vorgestellte Items). Seiten 2 bis 5 bekommen selbstreferenzierende Canonicals, werden aber als sekundär behandelt (niedrigere Optimierungs-Priorität, akzeptiere, dass manche nicht indexiert werden). Seiten 6 und tiefer bekommen Canonical-Tags, die auf Seite 1 zeigen, weil Content in dieser Tiefe unwahrscheinlich aus eigenem Verdienst indexiert wird und das Crawl-Budget anderswo besser eingesetzt ist.
Unabhängig von der Canonical-Strategie sorge dafür, dass jede einzelne Item-Seite (Produkt, Beitrag, Artikel) mit einer direkten URL in deine XML-Sitemap aufgenommen ist. Die Sitemap bietet einen unabhängigen Discovery-Pfad, der nicht von Pagination abhängt. Selbst wenn Google Seite 7 deiner Kategorie nie indexiert, können die Produkte, die auf Seite 7 erscheinen, immer noch über die Sitemap entdeckt und indexiert werden.
Crawl-Budget-Auswirkung tiefer Pagination
Tiefe Pagination, bei der ein Content-Listing Dutzende oder Hunderte Seiten umfasst, ist einer der bedeutendsten Crawl-Budget-Abflüsse auf content-lastigen Websites. Jede paginierte Seite ist eine URL, die Google möglicherweise zu crawlen, zu bewerten und potenziell zu indexieren versucht. Eine Site mit 100 Kategorien, jede mit 20 Seiten Pagination, erzeugt 2.000 paginierte Listing-URLs zusätzlich zu den eigentlichen Content-Seiten-URLs.
Googles Crawl-Scheduler muss entscheiden, wie er seine begrenzten Crawl-Ressourcen über all diese URLs verteilt. Übersteigen paginierte Listing-Seiten die Anzahl der tatsächlichen Content-Seiten, kann Google den Großteil seines Crawl-Budgets mit Listing-Seiten statt mit dem Content verbringen, den du tatsächlich indexiert haben willst. Das ist besonders problematisch für E-Commerce-Sites, wo die Produktseiten der umsatzbringende Content sind, Google aber seine Zeit mit dem Crawlen und Re-Crawlen der Kategorie-Listing-Pagination verbringt.
Das diagnostische Signal für Pagination-Crawl-Budget-Verschwendung ist in den Crawl-Statistiken der Google Search Console. Siehst du eine hohe Menge gecrawlter Seiten, aber einen niedrigen Prozentsatz indexierter Seiten, kann Pagination-Aufblähung die Ursache sein. Exportiere die URLs, die Google am häufigsten crawlt, und prüfe, welcher Prozentsatz paginierte Listing-URLs gegenüber tatsächlichen Content-Seiten sind.
Mehrere Strategien reduzieren die Crawl-Budget-Auswirkung tiefer Pagination. Erstens: Begrenze die Tiefe crawlbarer Pagination. Nutze robots.txt, um das Crawlen paginierter Seiten ab einer bestimmten Tiefe zu blockieren (zum Beispiel, blockiere /page/6/ und tiefer). Alternativ ergänze noindex,follow-Tags auf tiefen Seiten, sodass Google sie nicht indexiert, aber weiterhin Links zu einzelnen Items folgen kann. Zweitens: Reduziere die Anzahl der Items pro Seite, um die Gesamt-Pagination-Tiefe zu reduzieren. Statt 20 Items pro Seite 50 zu zeigen, verwandelt eine 20-Seiten-Kategorie in eine 8-Seiten-Kategorie. Drittens: Implementiere eine View-All-Seite für Kategorien, in denen das Seiten-Gewicht es erlaubt, und eliminiere die Pagination ganz.
Für dynamische Pagination, die sich häufig ändert (täglich neue Produkte hinzugefügt, trendige Items neu gemischt), behalte deine Sitemap als primären Discovery-Mechanismus, statt dich auf Pagination zu verlassen. Die Sitemap bietet eine vollständige Liste aller einzelnen Content-URLs, die Google in seinem eigenen Tempo crawlen kann, unabhängig davon, wie diese URLs an einem bestimmten Tag in paginierten Listings erscheinen.
Eine weitere Technik ist, das Crawl-Budget in Richtung Seite 1 jeder Kategorie zu priorisieren, indem du interne Links zu Seite 1 stärkst und Links zu tieferer Pagination schwächst. Deine Site-Navigation verlinkt zu Seite 1 jeder Kategorie. Interne Links aus Blogbeiträgen und anderen Inhalten zeigen auf Seite 1. Bereiche mit vorgestellten Produkten oder Beiträgen auf der Startseite verlinken zu Seite 1. Diese starken internen Links signalisieren Google, dass Seite 1 die Listing-URL höchster Priorität für jede Kategorie ist.
Schritt-für-Schritt-Anleitung
Auditiere die aktuelle Pagination-Implementierung über deine Site hinweg
Crawl deine Site und identifiziere alle paginierten URL-Muster. Gängige Muster umfassen /page/2/, ?page=2, /p2 und ?start=20. Zähle die Gesamtzahl paginierter Listing-URLs gegenüber tatsächlichen Content-Seiten-URLs. Prüfe, welche paginierten Seiten aktuell indexiert sind, indem du den „site:“-Operator mit Pagination-URL-Mustern nutzt. Identifiziere, welche Kategorien oder Bereiche die tiefste Pagination haben. Dokumentiere das aktuelle Canonical-Tag-Verhalten, robots.txt-Regeln und den noindex-Status für paginierte Seiten. Dieses Baseline-Audit zeigt den Umfang deines Pagination-Problems und leitet die Priorisierung.
Verifiziere Content-Discovery-Pfade jenseits von Pagination
Sorge dafür, dass jede einzelne Content-Seite (Produkt, Artikel, Beitrag) über mindestens einen anderen Pfad als Pagination auffindbar ist. Prüfe, dass alle Content-URLs in deiner XML-Sitemap sind. Verifiziere, dass Content-Seiten interne Links von anderen Inhalten erhalten (Bereiche mit verwandten Produkten, verwandten Beiträgen). Führe eine Orphan-Page-Analyse durch, um Content-Seiten zu finden, die nur über tiefe Pagination auffindbar sind und keine anderen internen Links haben. Ergänze für verwaisten Content interne Links aus verwandten Seiten oder vorgestellten Bereichen, um alternative Discovery-Pfade zu schaffen.
Implementiere crawlbare URLs für Infinite Scroll oder Load More
Nutzt deine Site Infinite Scroll oder Load-More-Buttons, implementiere zugrunde liegende paginierte URLs, die jedem Content-Segment entsprechen. Nutze die History API, um die Browser-URL zu aktualisieren, sobald Nutzer scrollen oder Load More klicken. Sorge dafür, dass jede paginierte URL ihren Content serverseitig rendert, ohne JavaScript-Interaktion zu erfordern. Teste, indem du /page/2/ direkt in einem Browser aufrufst und verifizierst, dass das korrekte Content-Set angezeigt wird. Nimm diese paginierten URLs in dein HTML auf (als Pagination-Links im Footer oder in einem noscript-Block), damit Google sie ohne JavaScript-Ausführung entdecken kann.
Konfiguriere Canonical-Tags auf paginierten Seiten
Implementiere deine gewählte Canonical-Strategie. Für die meisten Sites: Nutze selbstreferenzierende Canonicals auf den Seiten 1 bis 5 und Canonicals, die für die Seiten 6 und tiefer auf Seite 1 zeigen. Verifiziere Canonical-Tags, indem du den Quelltext paginierter Seiten in verschiedenen Tiefen ansiehst. Sorge dafür, dass Canonical-URLs das korrekte Protokoll (HTTPS) und Domain-Format (www oder non-www, passend zu deinem bevorzugten URL-Format) nutzen. Generiert dein CMS Canonical-Tags automatisch, verifiziere, dass die automatischen Tags für paginierte Seiten korrekt sind, da manche CMS-Plattformen alle paginierten Seiten unabhängig von der Tiefe fälschlicherweise selbst-referenzieren.
Optimiere Seite 1 jeder paginierten Serie
Da Seite 1 die Pagination-Seite mit der höchsten Indexierungs-Wahrscheinlichkeit ist, investiere darin, sie so stark wie möglich zu machen. Ergänze einzigartigen einleitenden Content (Kategorie-Beschreibung, Kaufberatung, Themen-Überblick), der nur auf Seite 1 erscheint. Sorge dafür, dass Seite 1 einen einzigartigen, keyword-optimierten Title-Tag und eine Meta-Description hat. Präsentiere deine wichtigsten Items auf Seite 1 durch manuelle Kuration oder algorithmische Sortierung. Ergänze Structured Data (ItemList-Schema) auf Seite 1, damit Google das Listing-Format versteht. Stärke interne Links, die von Navigation, Breadcrumbs und Content-Seiten auf Seite 1 zeigen.
Kontrolliere das Crawl-Budget, das für tiefe Pagination ausgegeben wird
Implementiere Crawl-Budget-Kontrollen für tiefe Pagination. Ergänze noindex,follow-Tags auf paginierten Seiten ab Seite 5 (oder deiner gewählten Schwelle). Das erlaubt Google, Links auf tiefen Seiten zu folgen, um einzelne Content-Items zu entdecken, und verhindert gleichzeitig, dass die tiefen Seiten selbst Index-Kontingent verbrauchen. Für sehr tiefe Pagination (Seite 20+) erwäge das Hinzufügen von robots.txt-Disallow-Regeln, um das Crawlen ganz zu verhindern, und verlasse dich auf deine Sitemap für die Content-Discovery jenseits dieser Tiefe. Beobachte nach Implementierung der Kontrollen die Crawl-Statistiken in der Search Console, um zu verifizieren, dass sich das Crawl-Budget von Listing-Seiten zu Content-Seiten verlagert.
Reiche Schlüssel-paginierte Seiten und einzelnen Content zur Indexierung ein
Reiche nach Umsetzung der Pagination-Fixes Seite 1 jeder wichtigen Kategorie oder jedes wichtigen Bereichs über das URL-Prüftool der Google Search Console ein. Reiche einzelne Content-Seiten, die zuvor nur über tiefe Pagination auffindbar waren, über IndexBolt ein, um sicherzustellen, dass Google sie unabhängig von ihrer Pagination-Position indexiert. Beobachte die Indexierung sowohl von Listing-Seiten als auch von einzelnen Content-Seiten über die folgenden Wochen. Bleiben Content-Seiten unindexiert, obwohl sie in der Sitemap sind und direkte interne Links haben, untersuche, ob die Seiten selbst Qualitäts- oder technische Probleme jenseits des Pagination-Kontexts haben.
Häufige Probleme und wie du sie behebst
Produkte/Beiträge auf Seite 2+ werden nicht indexiert, obwohl Items auf Seite 1 indexiert sind
Ursache: Items auf Seite 1 erhalten starke interne Link-Signale von der Kategorieseite (die selbst gut aus der Navigation verlinkt ist). Items auf tieferen Seiten erhalten schwächere Signale, weil die paginierten Seiten, auf denen sie erscheinen, weniger Autorität haben und seltener gecrawlt werden. Außerdem entdeckt Google Items auf paginierten Seiten nach Seite 1 weniger häufig als Items auf Seite 1, wenn diese tieferen paginierten Seiten nicht indexiert sind.
Lösung: Sorge dafür, dass alle einzelnen Content-Seiten-URLs in deiner XML-Sitemap sind und so einen pagination-unabhängigen Discovery-Pfad bieten. Ergänze interne Links zu wichtigen Items aus nicht-paginierten Kontexten: Bereiche mit verwandten Produkten, Erwähnungen in Blogbeiträgen, vorgestellte Items auf der Startseite und Cross-Sell-Widgets. Erwäge, vorgestellte Items zu rotieren, sodass mit der Zeit verschiedene Produkte auf Seite 1 erscheinen. Nutze IndexBolt, um einzelne Item-URLs einzureichen, die auf tiefen Seiten festsitzen und nicht organisch indexiert werden.
Infinite-Scroll-Site hat nur den ersten Batch von Items indexiert
Ursache: Google kann nicht scrollen, also sind nur die Items sichtbar, die beim initialen Seiten-Laden gerendert werden. Items, die durch scroll-ausgelöste JavaScript-Anfragen geladen werden, sind unsichtbar. Ohne zugrunde liegende paginierte URLs hat Google keinen Weg, auf Content jenseits des ersten sichtbaren Batches zuzugreifen. Die Items jenseits des ersten Scroll-Loads existieren aus Googles Sicht effektiv nicht.
Lösung: Implementiere paginierte URLs zusammen mit Infinite Scroll über den History-API-pushState-Ansatz. Jedes Scroll-Segment sollte einer crawlbaren paginierten URL entsprechen. Nimm paginierte Navigations-Links ins HTML auf, damit Google sie folgen kann. Verifiziere, dass jede paginierte URL ihr Content-Set serverseitig rendert. Reiche nach der Implementierung die paginierten URLs über IndexBolt oder Search Console ein, um Googles Entdeckung der neuen URL-Struktur zu beschleunigen.
Alle paginierten Seiten in der Search Console als „Duplikat, Google wählte andere kanonische URL“ markiert
Ursache: Google behandelt paginierte Seiten als Duplikate voneinander oder von Seite 1. Das passiert, wenn paginierte Seiten identische Title-Tags, identische Meta-Descriptions, identischen einleitenden Content haben und sich nur darin unterscheiden, welche Items gelistet sind. Google sieht sie als Variationen derselben Seite statt als distinkte Seiten und wählt eine (meist Seite 1) als kanonisch.
Lösung: Willst du paginierte Seiten unabhängig indexiert haben, differenziere sie. Ergänze Seitenzahlen in Title-Tags („Laufschuhe – Seite 2 von 8“). Erstelle einzigartige Meta-Descriptions für jede paginierte Seite oder entferne Meta-Descriptions von den Seiten 2+, damit Google sie aus dem Content generiert. Zeige einleitenden Content nur auf Seite 1. Brauchst du tiefe Seiten nicht indexiert, setze auf den Seiten 2+ explizit Canonical-Tags, die auf Seite 1 zeigen, und akzeptiere, dass nur Seite 1 indexiert wird.
Content hinter Load-More-Buttons verschwindet im Laufe der Zeit aus Googles Index
Ursache: Content hinter Load-More-Buttons, der zuvor über alternative Pfade (alte Sitemap, direkte Links) zugänglich war, kann an Indexierung verlieren, wenn Google die Site neu bewertet. Ist der Load-More-Content ohne JavaScript-Interaktion nicht zugänglich und werden die alternativen Pfade nicht mehr gepflegt, hat Google keinen aktuellen Weg, auf den Content zuzugreifen, und kann zuvor indexierte Items deindexieren, deren Existenz es nicht mehr verifizieren kann.
Lösung: Implementiere serverseitig gerenderte paginierte URLs, die Google direkt crawlen kann. Sorge dafür, dass diese URLs in deiner Sitemap sind und aus dem HTML der Listing-Seite verlinkt werden. Verifiziere, dass das Entfernen von JavaScript von der Seite immer noch Zugang zu allem Content über paginierte URLs ermöglicht. Reiche nach dem Fix betroffene Item-URLs über IndexBolt ein, um die Indexierung für zuvor deindexierten Content wiederherzustellen.
Profi-Tipps
Pagination sollte nicht bestimmen, ob dein Content indexiert wird. IndexBolt reicht einzelne Content-Seiten-URLs direkt bei Google ein und umgeht den Pagination-Discovery-Pfad komplett. Egal ob deine Produkte auf Seite 1 oder Seite 50 sind: IndexBolt sorgt dafür, dass sie alle indexiert werden. Reiche deine vollständige Content-URL-Liste ein und lass jede Seite Google erreichen, unabhängig von ihrer Pagination-Position.
100 Gratis-Credits. Keine Kreditkarte nötig. Ergebnisse in unter 24 Stunden.
Häufig gestellte Fragen
Unterstützt Google rel=prev/next überhaupt noch?+
Nein. Google bestätigte im März 2019, dass es rel=prev/next seit mehreren Jahren nicht mehr als Ranking- oder Indexierungs-Signal genutzt hat. Diese Tags in deinem HTML zu behalten, schadet nicht, bringt aber für Google keinen Nutzen. Andere Suchmaschinen (Bing) nutzen diese Tags möglicherweise noch, sodass es nicht schadet, sie zu behalten, aber du solltest dich für die Google-Indexierung nicht darauf verlassen. Deine Pagination-Strategie für Google muss auf Canonical-Tags, noindex-Direktiven, Sitemap-Aufnahme und Content-Qualität basieren statt auf rel=prev/next-Signalen.
Sollte ich eine „View All“-Seite erstellen statt Pagination zu nutzen?+
Eine View-All-Seite, die jedes Item auf einer einzigen Seite listet, ist die einfachste Lösung für Google, weil sie Pagination ganz eliminiert. Google hat gesagt, dass es View-All-Seiten generell bevorzugt, wenn sie technisch machbar sind. Allerdings sind View-All-Seiten nur für kleinere Content-Sets praktikabel (unter 100 Items). Für Kategorien mit Hunderten oder Tausenden Items wäre eine View-All-Seite zu langsam zu laden, zu ressourcenintensiv zu rendern und für Nutzer zu überwältigend. Nutze für große Content-Sets den hybriden Ansatz aus traditioneller Pagination kombiniert mit einer umfassenden XML-Sitemap.
Wie tief sollte ich Google in meine Pagination crawlen lassen?+
Es gibt keine universelle Antwort, aber eine praktische Richtlinie ist, die Indexierung der ersten drei bis fünf Seiten zu erlauben und tiefere Seiten zu noindexen (bei Erlaubnis von follow). Die genaue Schwelle hängt von der Qualität deiner paginierten Seiten und vom Crawl-Budget deiner Site ab. Hat deine Site starke Autorität und Google crawlt aggressiv, kannst du tiefere Indexierung erlauben. Hat deine Site begrenztes Crawl-Budget, beschränke die Indexierung auf Seite 1 und verlasse dich für die Content-Discovery auf deine Sitemap. Die Schlüssel-Metrik ist, ob tiefere paginierte Seiten tatsächlich Such-Impressionen generieren. Prüfe die Search Console, ob URLs ab Seite 5+ Impressionen erhalten. Wenn nicht, spart das Setzen auf noindex Crawl-Budget ohne Traffic-Auswirkung.
Mein Infinite Scroll nutzt AJAX, um Content zu laden. Kann Google AJAX-geladenen Content sehen?+
Google kann JavaScript-geladenen Content rendern, einschließlich AJAX-Responses, aber nur wenn das Laden des Inhalts durch das initiale Seiten-Rendering ausgelöst wird statt durch Nutzer-Interaktion (Scrollen, Klicken). AJAX-Content, der automatisch beim Seiten-Laden lädt, ist für Google sichtbar. AJAX-Content, der als Reaktion auf ein Scroll-Event lädt, ist es nicht, weil Googles Renderer nicht scrollt. Löst dein Infinite Scroll AJAX-Anfragen basierend auf der Scroll-Position aus, ist dieser Content für Google unsichtbar. Implementiere zugrunde liegende paginierte URLs mit serverseitig gerendertem Content als Fundament und lagere das Infinite-Scroll-AJAX-Erlebnis für Nutzer darüber.
Ist die Reihenfolge der Items in der Pagination für SEO wichtig?+
Die Reihenfolge der Items ist primär wichtig, weil Items auf Seite 1 deutlich mehr Crawl-Aufmerksamkeit und internen Link-Wert erhalten als Items auf tieferen Seiten. Google crawlt und indexiert Content auf Seite 1 mit höherer Wahrscheinlichkeit als Content auf Seite 10. Hast du hochpriorisierte Items, die du indexiert und sichtbar haben willst, sorge dafür, dass sie durch manuelle Kuration, Pinning oder Sortier-Algorithmen, die wichtige Items zuerst nach oben holen, auf Seite 1 erscheinen. Für E-Commerce holt das Sortieren nach Bestseller, Top-Bewertung oder Neuheit oft natürlich die relevantesten Produkte auf Seite 1. Vermeide zufälliges Sortieren, das sich bei jedem Seiten-Laden ändert, da Google Schwierigkeiten haben kann, inkonsistenten Seiten-Content zu bewerten.
Sollte ich jeder paginierten Seite einzigartigen Content hinzufügen, damit sie indexiert wird?+
Einzigartigen Content jeder paginierten Seite hinzuzufügen ist für die meisten Sites weder praktikabel noch nötig. Konzentriere deinen Content-Optimierungs-Einsatz auf Seite 1, die am wahrscheinlichsten indexiert wird und am wichtigsten für Such-Traffic ist. Für die Seiten 2 bis 5 reichen differenzierte Title-Tags mit Seitenzahlen. Für tiefere Seiten setze sie auf noindex und sorge dich nicht um einzigartigen Content. Die einzelnen Items, die auf diesen Seiten gelistet sind, sollten je ihren eigenen einzigartigen Content auf ihren eigenen URLs haben. Die paginierte Listing-Seite ist ein Navigations-Mechanismus, kein Content-Ziel. Investiere deinen Content-Erstellungs-Einsatz in die einzelnen Items statt in die Listing-Seiten.