Pagination SEO für B2B

Verwenden Sie eine einheitliche URL-Struktur für alle paginierten Seiten: /blog/seite/2/, /produkte?page=2 oder /cases?p=2. Mischen Sie keine Varianten. Konsistenz erleichtert Crawling und die Erstellung von Regeln für robots.txt und Canonicals.

Jede paginierte Seite muss einzigartige Inhalte haben – nicht nur dieselben Produkte oder Artikel in anderer Reihenfolge. Titel, Meta Description und H1 sollten die Seitenzahl enthalten: „Blog – Seite 2 | Brand". Das verhindert Duplicate-Content-Probleme.

Jede Seite der Pagination muss auf die vorherige und nächste Seite verlinken – und idealerweise auf die erste und letzte Seite. „Zurück zur Übersicht"-Links und nummerierte Seitennavigation sind besser als nur „Nächste/Vorherige".

Paginierte Seiten (Seite 2+) sollten in der XML-Sitemap enthalten sein, wenn sie strategischen Content enthalten. Für reine Listen-Seiten ohne eigenständigen Content kann auf die Aufnahme verzichtet werden – sie werden über interne Links gefunden.

Wenn Sie rel prev/next bereits implementiert haben, können Sie es entfernen oder belassen – es hat keinen negativen Effekt. Investieren Sie die Ressourcen stattdessen in Canonical-Strategien und interne Verlinkung. Bing unterstützt rel prev/next noch.

Die gängigste Strategie ist ein Canonical auf Seite 1 für alle paginierten Seiten. Das signalisiert Google, dass nur Seite 1 indexiert werden soll. Nachteil: Deep-Content auf Seite 5+ wird möglicherweise nicht indexiert.

Alternativ kann jede paginierte Seite einen self-referencing Canonical haben. Das erlaubt die Indexierung aller Seiten, erfordert aber einzigartige Titles, Meta Descriptions und H1s. Nutzen Sie diese Strategie, wenn jede Seite eigenständigen Content hat.

Seite 2+ kann mit Meta-Robots noindex versehen werden, während Seite 1 indexiert bleibt. Das verhindert Cannibalization und konzentriert das Ranking-Signal auf die erste Seite. Wichtig: Noindex-Seiten sollten nicht in der XML-Sitemap stehen.

View-All-Seiten eignen sich für Listen mit weniger als 100 Elementen, bei denen die Ladezeit akzeptabel bleibt. Die Seite sollte lazy loading verwenden, um die initiale Ladezeit zu minimieren. Jeder Listeneintrag braucht einen Anker-Link für direkte Verlinkung.

Die größte Herausforderung bei View-All-Seiten ist die Performance. Ohne Lazy Loading und Pagination können Tausende von Bildern und DOM-Elementen die Seite unbrauchbar machen. Core Web Vitals leiden besonders unter LCP- und CLS-Problemen.

Wenn eine View-All-Seite existiert, sollten alle paginierten Seiten auf die View-All-Seite canonicalisieren. Die View-All-Seite selbst hat einen self-referencing Canonical. Das konsolidiert das Ranking-Signal auf der umfassendsten Version.

Bieten Sie Nutzern die Wahl zwischen paginierter und View-All-Ansicht. Ein „Alle anzeigen"-Link auf der ersten Seite und ein „Zurück zur paginierten Ansicht" auf der View-All-Seite erhöht die Zufriedenheit und die Verweildauer.

Die Grundlage für SEO-freundliches Infinite Scroll ist eine funktionierende paginierte Version. JavaScript erweitert die paginierte Seite um Infinite Scroll; ohne JavaScript bleibt die Pagination erhalten. Das garantiert, dass Crawler alle Inhalte finden.

Jedes geladene Content-Bundle sollte die URL aktualisieren (z. B. via History API zu /blog?page=3). Das ermöglicht Deep-Linking, Bookmarking und das Crawlen einzelner Seiten. Ohne URL-Updates sind tiefere Inhalte für Crawler unsichtbar.

Ein „Mehr laden"-Button ist SEO-freundlicher als automatisches Infinite Scroll. Der Nutzer entscheidet aktiv, mehr Inhalte zu laden – und der Button ist ein klickbares Element, das Crawlern signalisiert, dass mehr Content existiert.

Testen Sie Infinite-Scroll-Seiten mit deaktiviertem JavaScript. Wenn die Pagination nicht funktioniert oder Inhalte fehlen, ist die SEO-Grundlage nicht gegeben. Nutzen Sie den URL Inspection Tool in der GSC, um das gerenderte Ergebnis zu prüfen.