So vermeiden Sie blockierte Scraping-Anfragenim großen Maßstab unblockiert bleiben

Ein Scraper wird blockiert, wenn sein Datenverkehr nicht dem entspricht, was die Zielseite von einem echten Besucher erwartet. Die Anfrage kommt von einer Adresse mit schlechtem Ruf, trägt einen dünn besetzten oder widersprüchlichen Satz von Headern, sendet Anfragen schneller als ein Mensch klicken könnte, oder ruft eine Seite ab, die die Website nie an Bots ausliefert. Jedes dieser Merkmale reicht für ein modernes Anti-Bot-System aus, um statt der gewünschten Daten einen 403-Fehler, ein CAPTCHA oder eine leere Seite zurückzuliefern.

Dieser Leitfaden behandelt die praktischen Taktiken, die einen Scraper wie einen Browser aussehen lassen: rotierende Residential-IPs, realistische Header und User-Agents, Drosselung und Zufälligkeit beim Timing, Berücksichtigung der robots.txt, JavaScript-Rendering bei entsprechenden Seiten, Umgang mit CAPTCHAs, Verwaltung von Sessions und Cookies sowie das Beobachten von Statuscodes, damit Sie sich zurückziehen, bevor eine weiche Drosselung zu einem vollständigen Bann wird. Keine Methode ist ein Allheilmittel, aber in der richtigen Reihenfolge kombiniert, verwandeln sie die meisten Ziele von einer Wand aus Blockierungen in einen gleichmäßigen Strom von 200-Antworten.

Warum Scraper blockiert werden

Bevor wir zu den Taktiken kommen, hilft es zu wissen, womit Sie es zu tun haben. Anti-Bot-Systeme kennzeichnen automatisierten Datenverkehr anhand von drei übergeordneten Signalen, und fast jede Blockierung lässt sich auf eines davon zurückführen.

• Fingerabdruck. Ein echter Browser trägt ein konsistentes Bündel von Signalen: einen vollständigen Header-Satz, einen TLS-Handshake, der zum angegebenen User-Agent passt, eine JavaScript-Laufzeitumgebung und Cookies, die über Anfragen hinweg bestehen. Ein Standard-HTTP-Client trägt davon fast nichts, und ein halb gefälschter trägt Signale, die sich gegenseitig widersprechen. In beiden Fällen fällt er auf.
• Rate. Websites zählen Anfragen pro IP und pro Session über die Zeit. Datenverkehr, der schneller eingeht, als ein Mensch ihn erzeugen könnte, oder in einem völlig gleichmäßigen Intervall, wird als Skript erkannt, egal wie sauber jede einzelne Anfrage aussieht.
• IP-Reputation. Adressen in bekannten Datacenter-Bereichen, auf gemeinsamen Blocklisten oder mit einer Geschichte von Missbrauch werden bereits bei der ersten Anfrage mit Misstrauen behandelt. Die IP, von der Sie kommen, bestimmt Ihre Ausgangskredibilität, bevor Sie auch nur einen Header gesendet haben.

Jede der nachfolgenden Taktiken zielt darauf ab, eines dieser Signale zu verbessern. Wenden Sie zuerst die günstigen Methoden an, messen Sie Ihre Blockierungsrate, und greifen Sie erst dann zu schwereren Mitteln, wenn ein Ziel Sie tatsächlich dazu zwingt.

Rotierende Residential-IPs verwenden

Die häufigste Blockierung ist auch die einfachste: zu viele Anfragen von einer Adresse. Eine Website zählt Treffer pro IP und beginnt, 429-Antworten oder eine Blockierungsseite zurückzuliefern, sobald Sie deren Schwellenwert überschreiten. Verteilen Sie dasselbe Anfragevolumen auf viele IPs, und keine einzelne Adresse überschreitet je den Grenzwert. Deshalb ist Scraping-Infrastruktur vor allem Proxy-Infrastruktur: Der Proxy stellt die Anfrage in Ihrem Namen, sodass das Ziel seine Adresse statt Ihrer sieht.

Die Art der IP ist genauso wichtig wie die Rotation. Datacenter-IPs sind schnell und günstig, befinden sich jedoch in Hosting-Bereichen, die jedes Ziel mit einer einfachen Nachschau identifizieren kann, und werden daher auf gut gesicherten Websites als automatisiert eingestuft. Residential-IPs verlassen das Netz über echte Verbraucherverbindungen und sehen wie normale Besucher aus, allerdings zu höheren Kosten und mit geringerer Geschwindigkeit. Den vollständigen Kompromiss finden Sie unter Datacenter vs. Residential-Proxies. Kaufen Sie genau so viel Vertrauen, wie das Ziel verlangt, und nicht eine Stufe mehr: Residential für strenge Seiten, Datacenter für tolerante.

Eine manuelle Rotation bedeutet, einen Pool von Adressen zu verwalten und diese pro Anfrage zu wechseln, wobei verbrannte IPs ausgesondert werden müssen. Ein rotierendes Gateway verbirgt das hinter einem einzigen Endpunkt und tauscht die Exit-IP für Sie aus, entweder frisch pro Anfrage oder als Sticky-Session, wenn Sie über mehrere Seiten hinweg eine Identität aufrechterhalten müssen.

Realistische Header und User-Agents senden

Ein Standard-HTTP-Client verrät sich bereits in der ersten Zeile, die er sendet. Pythons requests-Bibliothek kündigt sich mit User-Agent: python-requests/2.x an und sendet kaum weitere Header, während ein echter Browser ein Dutzend in einer bestimmten Reihenfolge schickt. Websites, die nichts weiter tun, als diesen Header zu lesen, blockieren die erste Anfrage und lassen die zweite durch.

Setzen Sie einen aktuellen, echten Browser-User-Agent, und rotieren Sie durch einen kleinen Pool davon, anstatt immer dieselbe Zeichenkette zu verwenden. Senden Sie dann die Header, die stets zusammen mit ihm übermittelt werden: Accept, Accept-Language, Accept-Encoding und ein plausibler Referer. Das Ziel ist nicht ein einzelner magischer Header, sondern innere Konsistenz. Ein Chrome-User-Agent gepaart mit Firefox-artigen Accept-Werten ist verdächtiger als gar kein Spoofing.

import requests

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.9",
    "Accept-Encoding": "gzip, deflate, br",
    "Referer": "https://www.google.com/",
}
resp = requests.get("https://example.com", headers=headers)

Eine Ebene tiefer liegt der TLS-Fingerabdruck. Bevor ein einzelnes HTTP-Byte gesendet wird, öffnet Ihr Client einen TLS-Handshake, dessen genaue Form eine Signatur bildet, die oft als JA3-Hash zusammengefasst wird. Ein echter Chrome erzeugt eine bekannte Signatur; ein Python-Client erzeugt eine völlig andere. Wenn Sie einen Chrome-User-Agent über einen Python-TLS-Stack senden, stimmen die beiden nicht überein, und eine Fingerabdruck-Prüfung erkennt den Widerspruch unabhängig davon, wie perfekt Ihre Header sind. Diesen Abstand zu schließen bedeutet, einen Client zu verwenden, der den Handshake eines Browsers imitiert, oder eine echte Browser-Engine zu nutzen, die von Natur aus einen genuinen Handshake erzeugt.

Timing drosseln und zufällig variieren

Selbst verteilt über viele IPs wirkt ein Scraper, der Anfragen in einem fixen Rhythmus sendet, automatisiert. Ein perfekt gleichmäßiger Abstand von 500 ms zwischen Anfragen ist selbst ein Fingerabdruck, denn Menschen klicken nicht wie ein Metronom. Fügen Sie stattdessen eine zufällige Verzögerung zwischen den Anfragen ein, anstatt eine konstante zu verwenden, und halten Sie die Gleichzeitigkeit auf einem Niveau, das das Ziel ohne merkbare Spitzen verarbeiten kann.

Der altbewährte Rat, ein unregelmäßiges, menschenähnliches Scraping-Muster zu verwenden, gilt nach wie vor: Variieren Sie Ihre Intervalle, crawlen Sie Seiten nicht in starrer Reihenfolge, und vermeiden Sie es, viele Anfragen gleichzeitig gegen denselben Host zu senden. Die andere Hälfte des Timings besteht darin, Last zu reduzieren, die Sie gar nicht erzeugen müssen. Zwischenspeichern Sie bereits abgerufene Seiten, damit Sie sie nie zweimal anfordern, und scrapen Sie nur die Inhalte, die Sie tatsächlich benötigen, statt die gesamte Website.

robots.txt respektieren und Honeypots vermeiden

Bevor Sie irgendeine Umgehungstechnik anwenden, lesen Sie die robots.txt der Website. Dort wird angegeben, welche Pfade der Betreiber zum Crawlen freigegeben hat, und häufig auch eine Crawl-delay, die Ihnen das von ihm erwartete Mindestintervall zwischen Anfragen mitteilt. Diese Regeln zu respektieren ist teils Höflichkeit, teils Selbstschutz: Erklärte Regeln zu ignorieren ist der schnellste Weg, markiert zu werden, und es ist die Grenze, ab der Fragen zu Nutzungsbedingungen beginnen. Prüfen Sie auch die Nutzungsbedingungen der Website; wenn dort das Scraping ausdrücklich verboten ist, ist das ein Signal, das Ziel zu überdenken.

Eine verwandte Falle ist der Honeypot: ein Link, der durch CSS (display:none, Null-Größe oder Positionierung außerhalb des Bildschirms) vor menschlichen Augen verborgen, aber noch im HTML vorhanden ist. Ein naiver Crawler, der jedem <a>-Tag folgt, tappt sofort hinein und entlarvt sich als Bot, denn kein echter Nutzer hätte auf einen Link klicken können, den er nicht sieht. Folgen Sie nur den Links, die ein gerenderter Browser tatsächlich anzeigen würde, und überspringen Sie alles, was visuell verborgen ist.

JavaScript wie ein Browser rendern

Viele Seiten liefern nahezu leeres HTML und bauen ihren eigentlichen Inhalt nach dem Laden mit JavaScript auf. Rufen Sie eine solche Seite mit einem einfachen HTTP-Client ab, erhalten Sie eine Hülle ohne Daten. Einige Websites gehen noch weiter und liefern eine JavaScript-Challenge: ein kleines Skript, das ausgeführt werden und bestanden werden muss, bevor die eigentliche Seite ausgeliefert wird, was ein Nicht-Browser-Client niemals bewältigen kann.

Für beide Fälle benötigen Sie eine echte Browser-Engine. Ein Headless-Browser wie Playwright, Puppeteer oder Selenium, der Chrome steuert, lädt die Seite, führt ihre Skripte aus und gibt Ihnen das DOM zurück, das ein Nutzer sehen würde. Er erzeugt außerdem einen echten Browser-TLS-Fingerabdruck und ein echtes Navigator-Objekt, sodass er eine Klasse von Prüfungen besteht, die ein roher Client nicht bestehen kann. Der Nachteil ist das Gewicht: Ein Headless-Browser verbraucht pro Seite weitaus mehr CPU und Arbeitsspeicher als eine einfache Anfrage, also reservieren Sie ihn für Seiten, die tatsächlich Rendering erfordern. Einen ausführlicheren Überblick finden Sie unter JavaScript-Websites crawlen und im Python-spezifischen Leitfaden zum Scrapen von JavaScript-Seiten mit Python.

CAPTCHAs behandeln

Ein CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) ist eine Herausforderung, die eine Website anzeigt, wenn sie eine Anfrage als automatisiert vermutet. Viele Websites integrieren Algorithmen, die jeden Besucher bewerten und ein CAPTCHA auslösen, wenn der Score roboterhaft wirkt. Sobald Sie auf eines stoßen, verschafft kein Header-Tuning Ihnen die Daten aus dieser Anfrage.

Die nachhaltige Lösung besteht darin, sie erst gar nicht auszulösen: Eine saubere Residential-IP, ein konsistenter Fingerabdruck und ein menschenähnliches Tempo halten Ihren Robot-Score niedrig genug, dass die Challenge nie ausgelöst wird. Wenn ein Ziel sie dennoch anzeigt, ist ein verwalteter Scraping-Endpunkt, der CAPTCHAs serverseitig löst oder umgeht, weit zuverlässiger als das Einbinden eines Solvers in Ihren eigenen Stack. Ausführliche Informationen dazu finden Sie unter CAPTCHAs beim Web-Scraping umgehen.

Sessions und Cookies verwalten

Viele Websites setzen beim ersten Besuch ein Cookie und erwarten es bei jeder nachfolgenden Anfrage. Verwerfen Sie Cookies zwischen den Anfragen, wirken Sie jedes Mal wie ein frischer, verdächtig zustandsloser Besucher, was Verhaltensüberprüfungen auslöst, die davon ausgehen, dass ein echter Nutzer beim Browsen Zustand ansammelt. Verwenden Sie eine Session, die Cookies über Anfragen hinweg beibehält, damit ein mehrstufiger Ablauf (Suche, Paginierung, Aufruf einer Detailseite) durchgehend dieselbe Identität trägt.

Sessions interagieren mit der IP-Rotation, also koordinieren Sie beides. Wechseln Sie mitten in einer Session zu einer neuen IP, kommt das Cookie, das Ihrer alten Adresse ausgestellt wurde, nun von einer anderen an, was selbst ein Warnsignal ist. Halten Sie eine Sticky-IP für die Dauer einer logischen Session aufrecht und rotieren Sie erst, wenn Sie eine neue beginnen. Das Beispiel unten verwendet eine requests.Session, um Cookies und Header konsistent über alle Aufrufe hinweg zu halten.

import requests

session = requests.Session()
session.headers.update(headers)

# Cookies set on the first call ride along on the rest.
session.get("https://example.com/search?q=phones")
session.get("https://example.com/search?q=phones&page=2")

Statuscodes beobachten und zurückrudern

Ihr Scraper sollte HTTP-Statuscodes als Live-Feedback behandeln, nicht nur als Erfolg oder Misserfolg. Eine Reihe von 429- (Too Many Requests) oder 503-Antworten ist das Signal des Servers, langsamer zu werden. Respektieren Sie es: Wenden Sie exponentielles Backoff an, beachten Sie den Retry-After-Header, wenn der Server ihn sendet, und betrachten Sie einen Schwall von 429-Fehlern als Signal, die Gesamtrate zu senken, statt es härter zu versuchen. Ein ratenbegrenzten Endpunkt mit voller Geschwindigkeit zu bombardieren ist genau der Weg, wie aus einer weichen Drosselung ein dauerhafter Bann wird.

Andere Codes haben ihre eigene Bedeutung. Ein 403 bedeutet in der Regel eine Blockierung wegen Fingerabdruck oder IP-Reputation, sodass eine Änderung der Anfragerate nicht hilft; Sie benötigen eine bessere IP oder einen überzeugenderen Fingerabdruck. Ein plötzlicher 200, der statt des Inhalts eine CAPTCHA-Seite zurückgibt, ist eine verkleidete Blockierung; validieren Sie also den Inhalt, nicht nur den Code.

import time, random

def fetch(session, url, tries=4):
    for attempt in range(tries):
        resp = session.get(url)
        if resp.status_code == 200:
            return resp
        if resp.status_code in (429, 503):
            wait = int(resp.headers.get("Retry-After", 2 ** attempt))
            time.sleep(wait + random.uniform(0, 1))
            continue
        resp.raise_for_status()
    raise RuntimeError("exhausted retries")

Verantwortungsvolles Scraping

Unblockiert zu bleiben und verantwortungsvoll zu scrapen sind dieselbe Disziplin, aus zwei Blickwinkeln betrachtet. Lesen Sie die Nutzungsbedingungen und die robots.txt jeder Website und respektieren Sie, was dort angegeben ist; beschränken Sie sich auf öffentliche Seiten statt auf alles hinter einem Login, und halten Sie Ihre Anfragerate auf einem Niveau, das das Ziel ohne Belastung bedienen kann. Zwischenspeichern Sie bereits abgerufene Daten, damit Sie sie nicht erneut anfordern, und holen Sie nur die Daten, die Sie tatsächlich benötigen. Ein Scraper, der sich wie ein rücksichtsvoller Besucher verhält, wird mit weit geringerer Wahrscheinlichkeit blockiert und verursacht weit weniger Probleme, die eine Blockierung rechtfertigen würden.

Häufig gestellte Fragen

Warum wird mein Web-Scraper immer blockiert?

Weil sein Datenverkehr auf mindestens einer von drei Achsen nicht wie ein echter Browser wirkt: Fingerabdruck, Rate oder IP-Reputation. Die Anfrage kommt vielleicht von einer markierten Datacenter-IP, trägt einen dünnen oder widersprüchlichen Header-Satz, oder sie kommt schneller und regelmäßiger an, als ein Mensch klicken könnte. Anti-Bot-Systeme brauchen nur eines dieser Merkmale, um einen 403, ein CAPTCHA oder eine leere Seite zurückzugeben.

Was ist die wirkungsvollste Methode, um blockierte Web-Scraping-Anfragen zu vermeiden?

Das Rotieren über einen Pool guter IPs, idealerweise Residential-IPs für strenge Ziele. Die häufigste Blockierung ist ein per-IP-Ratenlimit, und das Verteilen desselben Anfragevolumens auf viele Adressen stellt sicher, dass keine einzelne Adresse je den Schwellenwert überschreitet. Es ist die günstigste Maßnahme mit der größten Wirkung, weshalb sie in der Regel die erste Technik ist, die vor der Optimierung von Headern oder Timing angewendet wird.

Reicht es aus, den User-Agent zu ändern, um Blockierungen zu verhindern?

Bei den am wenigsten gesicherten Websites manchmal; bei allem Ernstzunehmenden nein. Ein realistischer User-Agent muss mit dem vollständigen Header-Satz kombiniert werden, den ein Browser sendet, einem TLS-Fingerabdruck, der zu diesem Browser passt, persistenten Cookies und einer glaubwürdigen Anfragerate. Ein gefälschter User-Agent über einem Standard-HTTP-Client-TLS-Stack ist ein Widerspruch, den Fingerabdruck-Prüfungen leicht erkennen.

Wie sollte ich mit einer 429-Antwort "Too Many Requests" umgehen?

Verlangsamen statt härter zu versuchen. Wenden Sie exponentielles Backoff an, beachten Sie den Retry-After-Header, wenn der Server ihn sendet, und betrachten Sie eine Reihe von 429-Fehlern als Signal, die Gesamtanfragerate zu senken. Ein ratenbegrenzten Endpunkt mit voller Geschwindigkeit zu bombardieren ist der Weg, wie eine vorübergehende Drosselung zu einem dauerhaften Bann wird.

Benötige ich einen Headless-Browser, um Blockierungen zu vermeiden?

Nur wenn die Seite ihren Inhalt nach dem Laden mit JavaScript aufbaut oder eine JavaScript-Challenge bereitstellt, die ein einfacher Client nicht bestehen kann. Ein Headless-Browser rendert die Seite und erzeugt einen echten Browser-Fingerabdruck, der Prüfungen besteht, die eine rohe Anfrage nicht bestehen kann, verbraucht jedoch pro Seite weitaus mehr CPU und Arbeitsspeicher. Bei statischem HTML ist eine gut konfigurierte HTTP-Anfrage schneller, günstiger und genauso unblockiert.

Wann ist eine verwaltete Scraping-API sinnvoller als eine eigene Lösung?

Wenn ein Ziel auf mehreren Ebenen gleichzeitig zurückschlägt. Einen Residential-Proxy-Pool, Header- und TLS-Rotation, Cookie-Sessions, Backoff-Logik, eine Headless-Flotte und einen CAPTCHA-Pfad zu verwalten ist echter Engineering-Aufwand, und eine neue Herausforderung kann das über Nacht zunichte machen. Eine Crawling API oder ein Smart AI Proxy nimmt all das hinter einer einzigen Anfrage ab, sodass Sie per-Anfrage-Kosten und etwas Kontrolle gegen das Nicht-Betreiben von Anti-Bot-Infrastruktur eintauschen.

BA

Bilal Ahmed

Softwareentwickler · Crawlbase

Softwareentwickler, der einige der meistgelesenen Beiträge im Crawlbase-Blog verfasst hat, über Web Scraping, Proxys und Daten-Tooling.