Zurück zum Blog

Web-Scraping eingeschränkt? Fingerprinting, IP-Sperren, CAPTCHAs und Mehrfach-Logins lösen

Ausgehend von 403/429, Fingerprinting, CAPTCHAs, dynamischen Seiten und Login-Sitzungen erklärt dieser Artikel die tatsächlichen Ursachen eingeschränkter Datenerhebung und zeigt einen Ansatz, der autorisierte APIs, Ratenbegrenzung, Backoff, inkrementelles Caching und konforme Konto-Umgebungen in den Vordergrund stellt.

Wenn ein Scraping-Job auf 403, 429, ein CAPTCHA oder wiederholt fehlschlagende Logins stößt, ist es nicht der richtige Schritt, IPs zu rotieren, Fingerabdrücke zu verschleiern oder zu versuchen, einen „echten Menschen" vorzutäuschen. Diese Signale bedeuten in der Regel, dass die Anfragefrequenz, der Zugriffsbereich, die Authentifizierung oder das automatisierte Verhalten eine Grenze überschritten haben, die die Website bereit ist zu akzeptieren. Wer weiter versucht, die Sperre zu umgehen, riskiert eine Eskalation der Einschränkung und kann zudem gegen Nutzungsbedingungen, Verträge, Urheberrecht oder Datenschutzregeln verstoßen.

Ein stabilerer Weg besteht darin, zunächst Autorisierung und verfügbare Schnittstellen zu prüfen, dann den Datenverkehr zu reduzieren, gezielt zu cachen und bei Bedarf zurückzuschalten. Browserautomatisierung sollte nur dort zum Einsatz kommen, wo Seiten wirklich JavaScript-Rendering oder menschliche Logins erfordern. Behandeln Sie ein CAPTCHA als Signal zum Anhalten, nicht als technisches Hindernis, das es zu durchbrechen gilt.

Vom Symptom zur Ursache

SymptomHäufige UrsacheKonforme Reaktion
429 Too Many RequestsAnfragen zu schnell, zu parallel oder wiederholtRate senken, Retry-After beachten, exponentielles Backoff nutzen
403 ForbiddenUnautorisierter Pfad, Policy-Block, fehlende SitzungBerechtigungen, Bedingungen, robots.txt und Authentifizierung prüfen
CAPTCHA erscheintSeite verlangt menschliche Bestätigung oder blockiert AutomatisierungAufgabe pausieren, manuell lösen oder API anfragen
Login schlägt wiederholt fehlCookies abgelaufen, Sitzungen überschrieben, Authentifizierung fehlgeschlagenOffizielle OAuth oder Service-Konten nutzen, Sitzungsübergaben sauber regeln
Seite hat Inhalt, Skript liest ihn nichtJavaScript-Rendering, asynchrones API-LadenOffizielle API nutzen; mit Erlaubnis im Browser rendern und dann das DOM lesen
Selektoren funktionieren plötzlich nichtDOM-Umstellung, A/B-Test, SprachwechselSemantische Locators, Strukturtests und Warnungen verwenden, keine hartcodierten Hierarchien
Doppelte oder fehlende DatenPaginierung, Cursor, Zeitzonen, Update-Fenster falschEindeutige Schlüssel, inkrementellen Wasserstand und Re-Run-Mechanismen einführen

Ändern Sie immer nur eine Variable und protokollieren Sie. Wenn Sie IP, User-Agent, Konto und Parser gleichzeitig austauschen, mögen Sie zufällig Erfolg haben, können aber nicht zuordnen, welche Änderung tatsächlich geholfen hat.

Schritt 1: Stellen Sie fest, ob Sie diese Daten erheben dürfen

Beantworten Sie vorab vier Fragen:

  1. Sind die Daten öffentlich oder erst nach Login, Zahlung oder nur für bestimmte Rollen verfügbar?
  2. Bietet die Website eine API, einen Export, einen Feed, einen Webhook oder eine Partner-Datenschnittstelle?
  3. Erlauben Nutzungsbedingungen, robots.txt, Verträge und lokales Recht den geplanten Verwendungszweck?
  4. Enthalten die Daten personenbezogene Informationen, urheberrechtlich geschützte Inhalte oder andere sensible Felder?

robots.txt ist der Standardweg, auf dem eine Website automatisierten Clients erlaubte und verbotene Pfade mitteilt. RFC 9309 definiert die Syntax und die Abgleichsregeln des Robots Exclusion Protocol und stellt klar, dass robots.txt keine Zugriffsberechtigung ist. Eine Erlaubnis in robots.txt bedeutet also nicht, dass Sie alle Rechte zur Vervielfältigung, Verarbeitung oder kommerziellen Nutzung der Daten haben; verbotene Pfade sollten nicht über andere Eingänge umgangen werden.

Unternehmensprojekte sollten Datenquellen, Zugriffsgrundlage, Zweck, Felder, Aufbewahrungsdauer und Löschmechanismus dokumentieren. Wenn aggregierte Daten das Problem lösen, vermeiden Sie das Sammeln personenbezogener Daten.

Schritt 2: Bevorzugen Sie stabile Dateneingänge

Die übliche Priorität ist:

  1. Offizielle APIs, Webhooks oder Daten-Exporte;
  2. Öffentliche Feeds, Sitemaps oder Massendateien;
  3. Erlaubte gewöhnliche HTTP-Seiten;
  4. Browserautomatisierung nur, wenn JavaScript wirklich gerendert werden muss;
  5. Seiten, die ein menschliches Konto und Interaktion erfordern, zuletzt.

APIs liefern in der Regel Felddefinitionen, Paginierung, Ratenbegrenzungen und Fehlercodes mit, was günstiger zu warten ist als das Parsen einer Benutzeroberfläche. Eine Webseite ist eine Oberfläche für menschliche Augen; sie kann sich jederzeit ändern und sollte nicht als stabile Datenbank behandelt werden.

Wenn eine passende Schnittstelle fehlt, kontaktieren Sie zuerst den Dateneigentümer und erläutern Sie Zweck, Frequenz, Felder und kommerziellen Umfang. Eine klare Datenlizenz ist in der Regel günstiger als ein langwieriger Kampf gegen Beschränkungen.

Schritt 3: 429 und IP-Sperren durch Lastreduktion lösen, nicht durch Quellenverschleierung

Geschwindigkeits- und Parallelitätsobergrenzen setzen

Starten Sie mit einem einzigen Worker und großzügigem Intervall und beobachten Sie Antwortzeit und Fehlerquote. Liefert der Server Retry-After, warten Sie genau diese Zeit. Liefert er nichts, verwenden Sie exponentielles Backoff mit zufälligem Jitter, damit nicht mehrere Aufgaben gleichzeitig erneut anfragen.

Eine einfache Regel:

Wartezeit = min(Obergrenze, Basis × 2^Wiederholungen) + zufälliger_Jitter

Erreichen Sie die maximale Wiederholungszahl, brechen Sie ab und lösen Sie eine Warnung aus. Kein endloses Wiederholen.

Caching und inkrementelle Aktualisierung

Cachen Sie dieselbe URL und nutzen Sie, wo unterstützt, konditionale Anfragen mit ETag oder Last-Modified. Halten Sie die letzte Aktualisierungszeit oder einen Cursor fest, damit Sie nur neue oder geänderte Inhalte abrufen. Die Trennung von vollständigen Aktualisierungen und täglichen inkrementellen Jobs reduziert das Anfragevolumen deutlich.

Ihren Klienten ehrlich identifizieren

Ein konformer Crawler verwendet einen stabilen, echten User-Agent, nennt seinen Zweck und stellt eine Kontaktseite oder E-Mail bereit. Sich als gewöhnlicher Browser auszugeben und häufig die Identität zu wechseln, erschwert der Website die Unterscheidung zwischen gutem und schlechtem Traffic und erhöht die Sperrwahrscheinlichkeit.

Wird eine bestimmte IP gesperrt, pausieren Sie die Aufgabe und prüfen Sie die Ursache. Proxys zu rotieren, um den Zugriff aufrechtzuerhalten, kann als Umgehung von Zugriffskontrollen gewertet werden und ist keine Lösung.

Schritt 4: Mit Fingerprinting und Verhaltensanalyse umgehen

Browser-Fingerabdrücke kombinieren Signale wie User-Agent, Betriebssystem, Sprache, Zeitzone, Auflösung, Canvas und WebGL. Eine Website kann zusätzlich Anfragefrequenz, Navigationspfade und Sitzungsverhalten analysieren. OWASP listet Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing und ähnliche Muster als eigenständige Kategorien automatisierter Bedrohungen auf – daher kombiniert eine Site häufig mehrere Signale, um das Automatisierungsrisiko zu beurteilen.

Bei autorisierten Aufgaben geht es nicht darum, massenhaft „menschlich wirkende" Identitäten zu erzeugen, sondern darum, die Umgebung stabil und erklärbar zu halten:

  • Für dasselbe Geschäftskonto eine feste Umgebung und reguläre Authentifizierung verwenden;
  • Browserparameter zur tatsächlichen Region und zum tatsächlichen Gerät passend halten;
  • Fingerabdrücke nicht zufällig verändern, um Sperren zu umgehen;
  • Erfassungsfrequenz, Aufgaben-ID und Verantwortlichen in Logs festhalten;
  • Mit der Seite erlaubte Kontenzahl, Parallelität und Datenumfang vereinbaren.

Wird eine autorisierte Aufgabe dennoch fälschlich eingestuft, teilen Sie der Seite Zeitstempel, User-Agent, Ausgangs-IP und Anfragebeispiele mit und bitten Sie um Aufnahme in eine Whitelist oder Bereitstellung einer dedizierten Schnittstelle.

Schritt 5: Automatisierung stoppen, sobald ein CAPTCHA erscheint

Ein CAPTCHA dient der Bestätigung eines Menschen oder der Blockierung verdächtiger Automatisierung. Verwenden Sie keine OCR, keine CAPTCHA-Lösungsdienste, keine CAPTCHA-Knacker-Plugins und keine anderen Mittel zur automatischen Umgehung.

Der korrekte Ablauf ist:

  1. Aktuelles Konto und Aufgabenwarteschlange sofort pausieren;
  2. Anfragefrequenz, Pfade und Fehlerlog direkt vor dem Auftreten sichern;
  3. Eine berechtigte Person führt die notwendige Prüfung auf der offiziellen Seite durch;
  4. Prüfen, ob Anfragen zu schnell waren, die Sitzung abgelaufen ist oder ein nicht erlaubter Pfad verwendet wurde;
  5. Für langfristige Automatisierung bei der Seite API, Service-Konto oder Whitelist beantragen.

Auch wenn ein Mensch ein CAPTCHA einmal löst, berechtigt das nicht zu unbegrenzten automatischen Anfragen. Beheben Sie zuerst die Ursache.

Schritt 6: Logins und Mehrfach-Konten mit korrekten Berechtigungen betreiben

Hinter einem Login stehende Daten sind sensibler als öffentliche Seiten. Bevorzugen Sie OAuth, Service-Konten, API-Tokens oder von der Plattform offiziell erteilte Berechtigungen. Lassen Sie Skripte keine persönlichen Hauptpasswörter speichern.

Ist eine Browser-Sitzung wirklich nötig:

  • Ein berechtigtes Geschäftskonto erhält eine stabile Umgebung;
  • Cookies verschlüsselt speichern, mit Ablauf und Widerruf;
  • MFA aktivieren, Automatisierung darf die Zwei-Faktor-Prüfung nicht umgehen;
  • Passwortzurücksetzungen und Cookie-Duplikation durch mehrere Personen gleichzeitig verbieten;
  • Festhalten, wer wann welche Aufgabe gestartet hat;
  • Bei Austritt, Projektende oder Rollenwechsel den Zugriff sofort widerrufen.

Mehrere Konten sind nur erlaubt, wenn Sie sie tatsächlich besitzen oder zur Nutzung berechtigt sind. Wenn eine Seite pro Entität nur ein Konto erlaubt, darf die Umgebungstrennung nicht dazu missbraucht werden, diese Grenze zu durchbrechen.

Schritt 7: Dynamische Seiten robuster gegenüber Redesigns machen

Semantische und stabile Attribute nutzen

Bevorzugen Sie Titel, Überschriften, Barrierefreiheitsattribute und öffentliche Test-IDs der Seite. Vermeiden Sie brüchige Hierarchien wie div:nth-child(7). Lesen Sie das DOM nach einer Seitenaktualisierung neu und gehen Sie nicht davon aus, dass der alte Knoten noch existiert.

Extraktion von Geschäftslogik trennen

Die Sammelschicht wandelt Seiten nur in strukturierte Felder um. Die Validierungsschicht prüft Typen, Bereiche, eindeutige Schlüssel und Pflichtfelder. So müssen Sie bei einem Redesign nur den Parser anpassen, nicht die nachgelagerte Analyse.

Stichproben und Warnungen einrichten

Speichern Sie eine kleine Zahl konformer HTML- oder Strukturschnappschüsse als Testmuster. Vollständige Konto-Seiten oder sensible Daten dürfen nicht gespeichert werden. Überwachen Sie Feldverlustraten, Datensatzanzahl, Duplikate und Seitentitel. Stoppen Sie das Schreiben in Produktivdaten, wenn die Werte abweichen.

Wo PurpleMark beim autorisierten Scraping sinnvoll ist

Wenn ein Team mehrere autorisierte Konten, unterschiedliche Kunden- oder Regionsumgebungen gleichzeitig pflegt, kann es im PurpleMark-Web-App für jedes Geschäftskonto eine unabhängige Browser-Umgebung anlegen und die zugehörigen Cookies, die Seite, die nach dem Login geöffnet werden soll, und die normale Netzwerkkonfiguration gemeinsam speichern. Wird diese Umgebung später erneut geöffnet, kehrt der Browser zur letzten Sitzung und Arbeitsseite zurück. So teilen sich mehrere Personen nicht einen einzigen Cookie-Satz und das Team muss sich nicht jedes Mal neu anmelden.

Müssen Konten nach Kunde, Plattform oder Region getrennt werden, lassen sich Umgebungsgruppen einsetzen, um Geschäftskonten in unterschiedlichen Ordnern zu führen. Mit Mitgliederrechten, Freigabe und Übergabe wird festgelegt, wer welche Umgebung öffnen darf. Das Operationsprotokoll vermerkt, wann und von wem eine Umgebung geöffnet oder verändert wurde. Bei Rückfragen zu autorisiertem Scraping lässt sich so schnell auf ein bestimmtes Konto und einen konkreten Verantwortlichen zurückführen.

PurpleMark hilft einem Team, Konten, Umgebungen, Sitzungen und Verantwortung dauerhaft in einem Arbeitsbereich zu bündeln. Es ist jedoch nicht dazu gedacht, IP-Sperren, CAPTCHAs, Kontolimits oder die Anti-Automatisierungsmaßnahmen einer Website zu umgehen. Holen Sie zuerst die Berechtigung ein, dann sprechen Sie über Automatisierung.

Eine wartbare Scraping-Architektur

Eine sinnvolle Aufteilung in fünf Schichten:

  1. Planung: Frequenz, Parallelität, Aufgabenpriorität und Pause steuern;
  2. Zugriff: API, HTTP oder autorisierte Browser-Sitzung;
  3. Parsing: Antworten in strukturierte Felder überführen;
  4. Qualität: Deduplizierung, Typprüfung, Warnungen bei fehlenden Feldern, Versionsprotokoll;
  5. Governance: Rechte, Quellen, Zweck, Aufbewahrungsdauer, Löschung.

Jeder Datensatz speichert Quell-URL, Erfassungszeit und Parser-Version. Tritt ein Fehler auf, lässt sich gezielt nachvollziehen und neu ausführen, statt die gesamte Website erneut zu crawlen.

Häufige Fragen

Löst das Rotieren von Proxys eine IP-Sperre?

Es ändert vielleicht kurz die Ausgangsadresse, behebt aber nicht das Frequenz-, Berechtigungs- oder Verhaltensproblem. Proxys zu rotieren, um den Zugriff aufrechtzuerhalten, kann als Umgehung zählen. Stoppen Sie zuerst die Aufgabe, reduzieren Sie die Anfragen und kontaktieren Sie die Seite.

Kann ein CAPTCHA automatisch gelöst werden?

Nein. Ein CAPTCHA ist ein Signal, zu pausieren oder einen Menschen einzubinden. Für dauerhafte Automatisierung beantragen Sie API, Service-Konto oder Whitelist.

Darf ich eine Seite immer scrapen, wenn robots.txt es erlaubt?

Nicht unbedingt. robots.txt ist keine Zugriffsberechtigung; Nutzungsbedingungen, Urheberrecht, Datenschutz, Verträge und Verwendungszweck müssen ebenfalls berücksichtigt werden.

Macht ein Fingerprint-Browser Scraping „unauffindbar"?

Das lässt sich nicht garantieren, und es sollte auch nicht das Ziel sein. Er eignet sich besser dafür, legitime Kontositzungen und Teamrechte zu trennen und Cookie-Verwechslungen sowie Fehlbedienung zu reduzieren.

Abschluss

Beschränkungen beim Web-Scraping sind nicht nur ein „technisches Anti-Bot-Problem". 403, 429, Fingerprinting, CAPTCHAs und Mehrfach-Konto-Limits verweisen allesamt auf Berechtigungen, Last und Identitätsverwaltung.

Ein stabiler Ansatz bedeutet immer: APIs zuerst, klare Autorisierung, zurückhaltende Anfragen, inkrementelles Caching, testbares Parsing und überprüfbare Konten. Taucht ein CAPTCHA oder eine Sperre auf, halten Sie an und reparieren Sie den Prozess, anstatt die Quelle der Automatisierung weiter zu verschleiern.