Webseiten scrapen ohne blockiert zu werdenDie Lösungen, die funktionieren, in Reihenfolge

Ein Scraper wird blockiert, weil er nicht wie der Traffic aussieht, den das Ziel erwartet. Echte Browser tragen eine konsistente Menge an Signalen: eine plausible IP, einen vollständigen Header-Satz, einen TLS-Fingerprint, der zum behaupteten User-Agent passt, und einen Anfragerhythmus, der kein Metronom ist. Fehlt eines davon, fällt es einem modernen Anti-Bot-System auf. Der Großteil der Arbeit beim Scrapen ohne Blockierungen besteht darin, diese Signale zurückzubringen, in der richtigen Reihenfolge, und nur für die schweren zu bezahlen, wenn das Ziel sie tatsächlich verlangt.

Dieser Artikel geht die Techniken in etwa der Reihenfolge durch, in der sie sich auszahlen: IP rotieren, eine glaubwürdige Anfrage senden, die Rate glätten, was die Seite deklariert respektieren, JavaScript rendern, wenn die Seite es benötigt, und das Ganze an einen verwalteten Endpunkt übergeben, wenn ein paar Header nicht mehr ausreichen. Keine davon ist ein Allheilmittel. In der richtigen Reihenfolge gestapelt bringen sie Sie bei den meisten Zielen, die meiste Zeit, von einer 403-Wand zu einem stabilen 200.

Die schnellsten Gewinne, in Reihenfolge

Beginnen Sie oben, messen Sie Ihre Blockierungsrate und steigen Sie nur auf, wenn das Ziel es erfordert. Einen Headless-Browser-Flotte zu verwenden, um eine statische Preisseite zu scrapen, ist verschwendeter Aufwand; einfaches requests gegen eine gesicherte Login-Wand zu verwenden, sind verschwendete Anfragen.

Ihre IP rotieren

Die häufigste Blockierung ist die einfachste: zu viele Anfragen von einer Adresse. Eine Seite zählt Anfragen pro IP und beginnt, 429s oder eine Blockseite zurückzugeben, sobald Sie ihre Schwelle überschreiten. Diese Anfragen auf viele IPs zu verteilen bedeutet, dass keine einzelne Adresse je das Limit auslöst. Das ist der ganze Grund, warum Scraping-Infrastruktur hauptsächlich Proxy-Infrastruktur ist: Der Proxy stellt die Anfrage für Sie, sodass das Ziel seine IP sieht, nicht Ihre.

Die IP, durch die Sie rotieren, ist genauso wichtig wie die Rotation selbst. Datacenter-IPs sind schnell und günstig, sitzen aber in bekannten Hosting-Bereichen, sodass ein Ziel, das eine ASN-Abfrage durchführt, sie sofort erkennt. Residential-IPs gehen von echten Consumer-Verbindungen aus und werden als gewöhnliche Besucher gelesen, zu höheren Kosten und geringerer Geschwindigkeit. Den vollständigen Kompromiss finden Sie in Datacenter- vs. Residential-Proxys, und den statisch-residentiellen Mittelweg in ISP- vs. Residential-Proxys. Kaufen Sie genau so viel Vertrauen, wie das Ziel verlangt, und keine Stufe mehr.

IPs von Hand zu rotieren bedeutet, eine Liste zu pflegen und sie pro Anfrage zu durchlaufen. Ein rotierendes Proxy-Gateway verbirgt das hinter einem Endpunkt und tauscht die Exit-IP für Sie aus, entweder pro Anfrage oder klebrig pro Sitzung, wenn Sie eine Identität halten müssen.

# Rotate exits through a single gateway endpoint.
# The gateway picks a fresh IP; your logic stays here.
import requests

proxies = {
    "http": "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012",
    "https": "http://_USER_TOKEN_:@smartproxy.crawlbase.com:8012",
}
resp = requests.get("https://example.com/product/123", proxies=proxies, verify=False)
print(resp.status_code)

Eine Anfrage senden, die ein echter Browser senden würde

Ein Standard-HTTP-Client verrät sich in der ersten Zeile. Die Python-requests-Bibliothek sendet User-Agent: python-requests/2.x und fast keine anderen Header; ein echter Browser sendet ein Dutzend, in einer bestimmten Reihenfolge. Seiten, die nichts weiter tun als diese Header lesen, blockieren die erste und lassen die zweite durch.

Setzen Sie einen aktuellen, echten Browser-User-Agent und rotieren Sie durch einen kleinen Pool davon, statt einen String zu hämmern. Senden Sie dann die Header, die immer damit reisen: Accept, Accept-Language, Accept-Encoding und einen plausiblen Referer. Das Ziel ist kein einzelner magischer Header, es ist innere Konsistenz: Ein Chrome-User-Agent gepaart mit Firefox-artigen Accept-Headern ist verdächtiger als gar keine Fälschung.

import requests

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) "
        "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)

Ihren TLS-Fingerprint an Ihren User-Agent anpassen

Header sind die offensichtliche Schicht; TLS ist diejenige, die Scraper erwischt, die die Header behoben und dort aufgehört haben. Bevor ein einziges HTTP-Byte gesendet wird, öffnet Ihr Client einen TLS-Handshake, und die genaue Form dieses Handshakes (Cipher-Reihenfolge, Erweiterungen, unterstützte Gruppen) bildet einen Fingerprint, der üblicherweise als JA3-Hash zusammengefasst wird. Ein echter Chrome erzeugt einen bekannten Fingerprint. Pythons requests erzeugt einen völlig anderen. Wenn Sie einen Chrome-User-Agent über einen Python-TLS-Stack senden, widersprechen sich die beiden, und eine Fingerprint-Prüfung erkennt den Widerspruch, egal wie perfekt Ihre Header sind.

Die Lösung besteht darin, den Handshake selbst wie einen Browser aussehen zu lassen. Verwenden Sie einen Client, der das TLS-Profil eines echten Browsers imitiert (in Python ist curl_cffi mit seiner impersonate-Option die gängige Wahl), oder steuern Sie eine echte Browser-Engine, die einen echten Handshake kostenlos erzeugt. Hier beginnt das DIY-Scraping teuer zu werden, und hier beginnt ein verwalteter Endpunkt, der bereits Fingerprints behandelt, attraktiv auszusehen.

Drosseln und zurückschalten

Selbst über viele IPs liest sich ein Scraper, der Anfragen schneller abfeuert, als ein Mensch klicken könnte, als automatisiert. Fügen Sie eine randomisierte Verzögerung zwischen Anfragen hinzu statt einer festen (eine feste 500ms-Lücke ist selbst ein Fingerprint), und halten Sie die Parallelität auf einem Niveau, das das Ziel absorbieren kann, ohne es zu bemerken.

Wichtiger als die Steady-State-Verzögerung ist, wie Sie auf Gegendruck reagieren. Wenn ein Server 429 oder 503 zurückgibt, sagt er Ihnen, langsamer zu werden. Respektieren Sie das: Exponentiell zurückschalten, den Retry-After-Header respektieren, wenn vorhanden, und einen Schwall von 429s als Signal behandeln, Ihre Gesamtrate zu senken, nicht härter zu wiederholen. Ein ratenbegrenzten Endpunkt bei voller Geschwindigkeit zu wiederholen, ist, wie aus einer weichen Drosselung ein hartes Verbot wird.

import time, random, requests

def fetch(url, headers, tries=4):
    for attempt in range(tries):
        resp = requests.get(url, headers=headers)
        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")

Wenn Sie Schwierigkeiten haben zu entschlüsseln, was ein Statuscode bedeutet, erläutert Proxy-Statuscodes die häufigen und was jeder Ihnen tatsächlich sagt.

robots.txt respektieren und bei öffentlichen Daten bleiben

Vor den Umgehungstechniken eine Disziplin, die Sie aus Schwierigkeiten heraushält: Lesen Sie die robots.txt der Seite, respektieren Sie ihre Crawl-Delay- und Disallow-Pfade, und scrapen Sie öffentliche Seiten statt allem hinter einem Login. Das ist teils Höflichkeit und teils Selbsterhaltung. Authentifiziertes Scraping bindet jede Anfrage an ein Konto, das die Seite mit einem Klick sperren kann, und erklärte Regeln zu ignorieren ist sowohl der schnellste Weg, markiert zu werden, als auch die Linie, wo rechtliche Fragen beginnen.

Eine verwandte Falle ist der Honigtopf: ein Link, der für menschliche Augen durch CSS verborgen ist (display:none, Nullgröße, außerhalb des Bildschirms), aber im HTML vorhanden ist. Ein naiver Crawler, der jedem <a> folgt, läuft direkt hinein und entlarvt sich als Bot. Folgen Sie nur Links, die ein gerenderter Browser tatsächlich anzeigen würde, und überspringen Sie alles, was visuell verborgen ist.

JavaScript rendern, wenn die Seite es benötigt

Viele Seiten geben nahezu leeres HTML zurück und bauen ihren eigentlichen Inhalt nach dem Laden mit JavaScript auf. Rufen Sie eine davon mit einem einfachen HTTP-Client ab und Sie erhalten eine Hülle ohne Daten. Schlimmer noch, einige Seiten liefern eine JavaScript-Herausforderung: ein kleines Skript, das ausgeführt werden und bestehen muss, bevor die echte Seite geliefert wird, was ein Nicht-Browser-Client niemals bestehen kann.

Für beide Fälle benötigen Sie eine echte Browser-Engine. Ein Headless-Browser (Playwright, Puppeteer oder Selenium mit Chrome) lädt die Seite, führt ihre Skripte aus und gibt Ihnen das DOM, das der Benutzer sehen würde. Er erzeugt auch einen echten Browser-TLS-Fingerprint und ein echtes navigator-Objekt, sodass er eine Klasse von Prüfungen besteht, die ein roher Client nicht kann. Der Preis ist Schwere: Ein Headless-Browser verbraucht weit mehr CPU und Speicher pro Seite als eine HTTP-Anfrage, also reservieren Sie ihn für Seiten, die wirklich Rendering benötigen. Für eine tiefere Anleitung lesen Sie Web-Scraping mit Python und Selenium.

Ein Vorbehalt: Ein Standard-Headless-Browser ist erkennbar. Das navigator.webdriver-Flag, fehlende oder merkwürdige Plugin-Listen und headless-spezifische Eigenheiten lecken alle. Stealth-Plugins decken die häufigen Anzeichen ab, aber es ist ein Wettrüsten, und bei einem gesicherten Ziel ist es oft der Moment, aufzuhören, die eigene Flotte zu pflegen.

Wann an eine verwaltete API übergeben

Jede der oben genannten Techniken ist eine Schicht, die Sie aufbauen und pflegen: ein Proxy-Pool, ein Header-Rotator, ein TLS-imitierender Client, eine Backoff-Richtlinie, eine Headless-Flotte mit Stealth-Patches. Bei toleranten Zielen benötigen Sie vielleicht nur die ersten beiden. Bei einem gesicherten müssen Sie alle zusammenstellen und beaufsichtigen, und ein CAPTCHA oder eine neue JS-Herausforderung kann die gesamte Pipeline über Nacht brechen.

Eine Crawling API kollabiert diesen Stack in eine einzige Anfrage. Sie senden eine URL; der Anbieter wählt den IP-Ursprung, sendet einen konsistenten Fingerprint, rendert die Seite, wenn ein Browser erforderlich ist, wiederholt bei Blockierungen serverseitig und gibt das fertige HTML zurück. Der Kompromiss ist ehrlich: Sie zahlen pro Anfrage und geben etwas Low-Level-Kontrolle auf, im Austausch dafür, keine Anti-Bot-Infrastruktur als zweiten Job zu betreiben.

# Send the URL; rotation, fingerprint, rendering,
# and retries are handled server-side.
import requests

resp = requests.get(
    "https://api.crawlbase.com/",
    params={
        "token": "_YOUR_TOKEN_",
        "url": "https://example.com/product/123",
        "javascript": "true",  # render the page in a browser
    },
)
print(resp.text)

Ob Sie selbst aufbauen oder kaufen, die Proxy-Frage darunter geht nicht weg. Wenn Sie noch die IP-Schicht wählen, ordnet die besten Proxys für Web-Scraper Zieltypen dem passenden Proxy-Typ zu, und wie man rotierende Proxys verwendet behandelt das Einbinden von Rotation in Ihren Code.

Häufig gestellte Fragen

Was ist der häufigste Grund, warum ein Scraper blockiert wird?

Zu viele Anfragen von einer IP-Adresse. Seiten zählen Anfragen pro IP und beginnen, 429s oder Blockseiten zurückzugeben, sobald Sie eine Schwelle überschreiten. Anfragen auf einen Pool von IPs zu rotieren, sodass keine einzelne Adresse das Limit auslöst, ist die einzige wirkungsvollste Lösung, weshalb IP-Rotation meist die erste anzuwendende Technik ist.

Reicht das Ändern des User-Agents aus, um Blockierungen zu vermeiden?

Bei den am wenigsten geschützten Seiten manchmal. Bei irgendetwas Ernsthaftem, nein. Ein realistischer User-Agent muss mit dem vollständigen Header-Set, das ein Browser sendet, einem TLS-Fingerprint, der zu diesem Browser passt, und einer glaubwürdigen Anfragerate gepaart werden. Ein gefälschter User-Agent über einem Standard-HTTP-Client-TLS-Stack ist ein Widerspruch, den Fingerprint-Prüfungen leicht erkennen.

Benötige ich immer einen Headless-Browser zum Scrapen?

Nein. Ein Headless-Browser wird nur benötigt, wenn die Seite ihren Inhalt nach dem Laden mit JavaScript aufbaut oder eine JavaScript-Herausforderung liefert, die ein Nicht-Browser-Client nicht bestehen kann. Für statisches HTML ist eine einfache HTTP-Anfrage weit schneller und günstiger. Reservieren Sie den Headless-Browser für Seiten, die wirklich Rendering benötigen, da er weit mehr CPU und Speicher pro Seite kostet.

Wie gehe ich mit einer 429 Too Many Requests-Antwort um?

Verlangsamen statt härter wiederholen. Exponentiell zurückschalten, den Retry-After-Header respektieren, wenn der Server einen sendet, und einen Schwall von 429s als Signal behandeln, die Gesamtanfragerate zu senken. Einen ratenbegrenzten Endpunkt bei voller Geschwindigkeit zu hämmern, ist, wie aus einer vorübergehenden Drosselung ein hartes Verbot wird.

Soll ich Daten hinter einem Login scrapen?

Vermeiden Sie es, wo möglich. Authentifizierte Anfragen binden jeden Aufruf an ein Konto, das die Seite sofort sperren kann, und sie werfen rechtliche und Nutzungsbedingungsfragen auf, die das Scrapen öffentlicher Seiten nicht tut. Lesen Sie die robots.txt der Seite, bleiben Sie bei öffentlichen Daten und überspringen Sie Honigtopf-Links, die vor echten Benutzern verborgen sind.

Wann macht eine verwaltete Scraping-API mehr Sinn als das Selbstbauen?

Wenn das Ziel gleichzeitig auf mehreren Schichten zurückschlägt. Einen Proxy-Pool, Header-Rotation, einen TLS-imitierenden Client, Backoff-Logik und eine Headless-Flotte mit Stealth-Patches zu pflegen, ist eine echte Engineering-Last, und ein neues CAPTCHA oder eine Herausforderung kann es über Nacht brechen. Eine Crawling API absorbiert das alles hinter einer Anfrage, sodass Sie pro Anfrage bezahlen und etwas Kontrolle aufgeben, um nicht selbst Anti-Bot-Infrastruktur zu betreiben.

FQ

Farah Qadeer

Content-Visualisierung · Crawlbase

Spezialistin für Content-Visualisierung bei Crawlbase, die dichte Themen rund um Proxys und Web Scraping in klare Grafiken und Schritt-für-Schritt-Anleitungen verwandelt.