Skip to main content
Die Paginierung ist die Navigationsebene eines Scrapers. Nachdem er eine Seite abrufen, rendern und extrahieren kann, muss er eine praktische Frage beantworten: Wo befindet sich der nächste Datensatzstapel und woran erkenne ich, dass es keinen weiteren gibt? Die meisten Paginierungsfehler entstehen, weil jede Website wie eine nummerierte Seitenliste behandelt wird. Tatsächlich kann ein Katalog URL-Parameter, eine Weiter-Schaltfläche, unendliches Scrollen, eine Mehr-laden-Schaltfläche, einen API-Offset oder ein undurchsichtiges Cursor-Token verwenden. Manche Websites kombinieren mehrere Muster.

Mit der Anfrage beginnen, nicht mit der Benutzeroberfläche

Öffnen Sie vor dem Schreiben der Paginierungslogik die DevTools und beobachten Sie, was sich beim Wechsel zum nächsten Stapel ändert.
  1. Öffnen Sie die Registerkarte „Network“ und filtern Sie nach Fetch/XHR.
  2. Wählen Sie die nächste Seite aus, scrollen Sie nach unten oder klicken Sie auf „Mehr laden“.
  3. Untersuchen Sie Anfrage-URL, Abfrageparameter, Anfrageinhalt und Antwort.
  4. Entscheiden Sie, ob der Scraper Links folgen, mit der Seite interagieren oder einen API-Endpunkt direkt aufrufen sollte.
Nutzen Sie die Benutzeroberfläche als Hinweis, vertrauen Sie jedoch der Netzwerkanfrage. Eine „Mehr laden“-Schaltfläche könnte eine einfache API mit offset=40 aufrufen. Ein Seitenlink könnte Ergebnisse nach der URL-Änderung tatsächlich per JavaScript laden.

Nummerierte Seiten

Nummerierte Paginierung ist der einfachste Fall, weil der nächste Ort in der URL sichtbar ist:
Der Scraper kann die Seitennummer erhöhen und anhalten, wenn die Antwort keine Elemente, weniger Elemente als erwartet oder eine bekannte 404-/Leerzustandsseite enthält.
Achten Sie auf Seitenindizes, die bei 0 beginnen, Parameternamen wie p oder start und Websites, die bei einer ungültigen Seitennummer erneut Seite eins zurückgeben. Eine wiederholte erste Seite ist problematischer als eine leere, weil sie unbemerkt Duplikate erzeugen kann. Manche Websites zeigen keine Seitennummern, sondern nur einen „Weiter“-Link oder Pfeil. Handelt es sich um einen normalen Anker, behandeln Sie die Paginierung als Verfolgung von Links:
Die Absicherung mit seen_urls ist wichtig. Fehlerhaft konfigurierte Websites verweisen mit dem letzten „Weiter“-Link manchmal auf die aktuelle oder erste Seite. Prüfen Sie außerdem deaktivierte Zustände wie aria-disabled="true", disabled oder eine disabled-Klasse, bevor Sie dem Link vertrauen.

Unendliches Scrollen

Unendliches Scrollen wirkt wie ein reines Browserproblem, verwendet darunter aber meist eine API. Scrollen Sie bei geöffneten DevTools einmal und suchen Sie nach einer Anfrage, die den nächsten Datensatzstapel abruft. Relevante Parameter heißen häufig offset, page, after, cursor oder limit. Ist der Endpunkt nutzbar, rufen Sie ihn direkt auf:
Verwenden Sie einen Browser nur, wenn sich die API wegen Authentifizierung, signierter Parameter oder komplexem clientseitigem Zustand außerhalb der Seite nur schwer aufrufen lässt.
Verlassen Sie sich bei unendlichem Scrollen nicht nur auf die Seitenhöhe. Werbung, Bilder oder virtualisierte Listen können sie fortlaufend verändern. Elementanzahl, Netzwerkleerlauf und eine maximale Scrollzahl bilden eine sicherere Kombination.

Mehr-laden-Schaltflächen

Eine Mehr-laden-Schaltfläche ist gesteuertes unendliches Scrollen. Die Seite wartet auf einen Klick, bevor sie den nächsten Stapel anfordert. Das erleichtert die Taktung, weil der Scraper warten, die neue Elementanzahl prüfen und eine fehlgeschlagene Anfrage wiederholen kann. Ruft die Schaltfläche eine klar strukturierte API auf, verwenden Sie diese. Andernfalls klicken Sie in einer Browserschleife:
Die wichtige Prüfung lautet nicht nur „Schaltfläche angeklickt“, sondern „neue Datensätze erschienen“. Schaltflächen können still fehlschlagen, deaktiviert werden oder nach dem letzten Stapel sichtbar bleiben.

Offset- und Cursor-APIs

Moderne Websites paginieren Daten häufig auf API-Ebene. Offset-Paginierung fragt eine numerische Position ab:
Cursor-Paginierung fragt nach dem nächsten undurchsichtigen Token aus der vorherigen Antwort:
Cursor-Paginierung ist stabiler, wenn während des Scrapings Datensätze hinzukommen oder entfernt werden. Statt „die ersten 40 Zeilen überspringen“ bedeutet der Cursor „nach dieser bekannten Position fortfahren“.
Behandeln Sie Ratenbegrenzungen bei API-Paginierung bewusst. Beachten Sie Retry-After, wiederholen Sie temporäre Fehler mit Backoff und speichern Sie den Fortschritt, wenn ein Neustart ab Seite eins bei großen Aufträgen teuer wäre.

Hybride Paginierung

Echte Websites kombinieren häufig mehrere Muster:
  • Eine Kategorie besitzt nummerierte Seiten, auf denen nach dem Scrollen jeweils weitere Produkte nachgeladen werden.
  • Eine Suchseite beginnt mit „Mehr laden“ und wechselt dann zu nummerierten Links.
  • Eine Oberfläche mit Registerkarten besitzt getrennte Paginierung für „Neu“, „Beliebt“ und „Sale“.
  • Eine Listenseite paginiert Ergebnis-URLs; jede Detailseite besitzt wiederum eigene paginierte Rezensionen oder Kommentare.
Behandeln Sie dies als verschachtelte Schleifen. Die äußere Schleife ist für die größere Navigationseinheit zuständig, jede innere für eine wiederholte Aktion. Verfolgen Sie eindeutige IDs über den gesamten Lauf, damit keine Duplikate in die Ausgabe gelangen.

Praktische Schutzmaßnahmen

  • Stoppsignal definieren. Leere Ergebnismengen, fehlende Weiter-Links, deaktivierte Schaltflächen, hasNextPage: false, wiederholte Cursor und maximale Iterationszahlen sind gültige Stoppsignale.
  • Duplikate erkennen. Unendliches Scrollen und Cursor-APIs können Datensätze wiederholen, wenn sich Daten während eines Laufs ändern. Speichern Sie stabile IDs oder kanonische URLs.
  • Navigation drosseln. Fügen Sie zwischen Stapeln kleine zufällige Pausen ein. Browser-Automatisierung sollte auf Inhaltsänderungen warten, nicht nur auf feste Timeouts.
  • Fehler protokollieren. Scheitert eine Seite nach mehreren Versuchen, speichern Sie URL oder Cursor und fahren Sie möglichst fort.
  • Legitime und stabile APIs bevorzugen. Direkte API-Paginierung ist meist schneller und leichter zu validieren als Browsersteuerung.
  • Ein visuelles Tool verwenden, wenn Geschwindigkeit wichtiger als eigener Code ist. In Octoparse lässt sich Paginierung für übliche Weiter-, Mehr-laden- und Infinite-Scroll-Abläufe visuell konfigurieren und anschließend lokal oder in der Cloud ausführen.
Paginierung bedeutet nicht nur „zur nächsten Seite gehen“. Sie ist die Steuerschleife des Scrapers. Mit eindeutiger Logik für den nächsten Schritt, einer zuverlässigen Stoppbedingung und Duplikatschutz kann der Scraper eine Website durchlaufen, ohne unbemerkt auf Seite eins anzuhalten oder endlos weiterzulaufen.