Website scrapen, ohne blockiert zu werden: Leitfaden 2026

Wer eine Website scrapen will, ohne blockiert zu werden, sollte – meine kurze Antwort als Web-Engineer – robots.txt und die Nutzungsbedingungen respektieren, Anfragen auf ein menschlich plausibles Tempo mit exponentiellem Backoff drosseln, vollständige und realistische Browser-Header senden, Cookies innerhalb von Sessions konsistent halten und legitimen Traffic mit hohem Volumen über rotierende Residential-IPs verteilen – bei laufender Überwachung der Statuscodes auf frühe Blockierungssignale.

Blockiert zu werden ist kein Pech. Es ist der Anti-Bot-Stack einer Website, der Traffic korrekt als etwas identifiziert, das nicht wie ein browsender Mensch aussieht – oder als Traffic, den die Website ausdrücklich weggeschickt hat. Dieser Leitfaden behandelt die Engineering-Praktiken, mit denen legitime Scraping-Projekte (Preis-Monitoring, SEO-Tracking, Ad-Verification, KI-Trainingsdaten, Marktforschung) zuverlässig laufen – und er benennt klar die Grenzen, bei deren Überschreitung wir niemandem helfen. Das Gesamtbild, wie Scraping von Anfang bis Ende funktioniert, liefert unser Web-Scraping-Guide.

Erst die Regeln: robots.txt und Nutzungsbedingungen

Bevor Sie irgendetwas Technisches optimieren, klären Sie, ob Sie das Ziel überhaupt scrapen sollten.

1. Rufen Sie robots.txt ab und werten Sie sie aus. Die Datei im Root der Website erklärt, welche Pfade für Crawler tabu sind, und enthält oft eine Crawl-delay-Direktive. Sie zu respektieren ist das deutlichste Signal, dass Ihr Projekt in gutem Glauben operiert – die meisten ausgereiften Scraping-Frameworks können das automatisch durchsetzen.
2. Lesen Sie die Nutzungsbedingungen. Manche Websites untersagen automatisierte Zugriffe komplett, andere beschränken bestimmte Nutzungen. Ob AGB-Klauseln durchsetzbar sind, hängt von Rechtsordnung und Einzelfall ab – unser Überblick zur Frage, ob Web Scraping legal ist, behandelt die wichtigsten Urteile. Zu wissen, was die Website verlangt, ist aber eine Grundpflicht, kein optionales Extra.
3. Bevorzugen Sie offizielle Kanäle. Bietet die Website eine API, einen Datenfeed oder ein Lizenzprogramm für Ihren Anwendungsfall, nutzen Sie diese. Das ist stabiler als Scraping und beseitigt das Blockierungsproblem vollständig.
4. Begrenzen Sie den Umfang Ihrer Erhebung. Sammeln Sie nur die Felder, die Sie brauchen, nur von öffentlichen Seiten – und schließen Sie alles aus, was Einzelpersonen identifiziert. Unter der DSGVO gilt: Sobald personenbezogene Daten im Spiel sind, brauchen Sie eine Rechtsgrundlage, müssen Informations- und Betroffenenrechte bedienen und tragen Rechenschaftspflichten – Anforderungen, für die die meisten Scraping-Projekte schlicht nicht ausgestattet sind. Die sauberste DSGVO-Strategie ist, personenbezogene Daten gar nicht erst zu erheben.

Unsere Compliance-Haltung, klar ausgesprochen: ProxyFacts gibt keine Anleitungen zum Umgehen von Paywalls oder Login-Schranken, zum massenhaften Aushebeln von CAPTCHAs über Solver-Farmen, zum Scrapen personenbezogener Daten oder zur Kaufautomatisierung (Sneaker-Bots, Ticket-Scalping, Kontoerstellung). Anti-Blocking-Engineering, wie es hier behandelt wird, macht legitimen Zugriff zuverlässig – es verschafft keinen Zugriff, der Ihnen nie gestattet war. Für Projekte mit EU-Bezug heißt das auch: DSGVO-Konformität ist keine Kür, sondern Ausgangsbedingung.

Verstehen, warum Websites Scraper blockieren

Anti-Bot-Systeme suchen nach Mustern, die kein Mensch erzeugt. Wer die Erkennungsebenen kennt, weiß, was zu beheben ist:

Daraus folgen zwei Dinge. Erstens: IP-Rotation allein behebt nur eine Ebene – ein Scraper mit rotierender IP, aber Python-Standard-User-Agent scheitert weiterhin an Ebene zwei. Zweitens: Die Ebenen verstärken sich gegenseitig – konsistente Header mit inkonsistenten Sessions wirken verdächtiger als jeder der beiden Fehler allein. Wirksame Anti-Blocking-Arbeit bedeutet, dass jede Ebene dieselbe, wahrheitsgemäße Geschichte erzählt: ein vernünftiger Client, der eine vernünftige Anzahl von Anfragen stellt.

Rate Limiting und Backoff: der wirksamste Hebel

Der schnellste Weg zur Blockierung ist, Anfragen so schnell zu senden, wie die Leitung es erlaubt. Die Abhilfe kostet fast nichts:

• Wählen Sie eine konservative Basisrate. Ein Request alle paar Sekunden pro Domain ist für die meisten Websites ein vernünftiger Startpunkt. Deklariert robots.txt einen Crawl-delay, behandeln Sie ihn als Untergrenze, nicht als Vorschlag.
• Bauen Sie Jitter ein. Randomisieren Sie die Pause zwischen Anfragen (zum Beispiel eine Basisverzögerung multipliziert mit einem Zufallsfaktor zwischen 0,5 und 1,5). Perfekt regelmäßige Intervalle sind eine Maschinensignatur.
• Implementieren Sie exponentielles Backoff. Bei HTTP 429 oder 503 warten und mit sich verdoppelnder Verzögerung erneut versuchen: 1 Sekunde, 2, 4, 8 und so weiter, gedeckelt bei einem sinnvollen Maximum. Enthält die Antwort einen Retry-After-Header, befolgen Sie ihn exakt.
• Budgetieren Sie Parallelität pro Domain, nicht global. Zwanzig parallele Worker verteilt auf zwanzig Websites sind unproblematisch; zwanzig Worker auf einer Website sind ein Burst, der wie ein Angriff aussieht.
• Planen Sie um Lastspitzen herum. Wer einen Online-Händler während seiner Traffic-Spitze crawlt, konkurriert mit echten Kundinnen und Kunden um Serverressourcen. Crawling in Nebenzeiten ist höflicher und löst lastbasierte Abwehrmechanismen seltener aus.

Ein Scraper, der diese Regeln respektiert, braucht bei kleinen und mittleren Jobs oft gar keine weitere Anti-Blocking-Arbeit. Müsste ich einen blockierten Scraper debuggen, würde ich deshalb immer zuerst die Rate prüfen – sie ist der billigste Fix mit der größten Wirkung. Alles Folgende wird vor allem mit wachsendem Volumen relevant.

Realistische, konsistente Header senden

Die Standard-Header von HTTP-Clients verraten exakt, was Sie sind. Beheben Sie die offensichtlichen Verräter:

1. Setzen Sie einen echten Browser-User-Agent – einen aktuellen Chrome- oder Firefox-String, keinen Library-Standard und keine Browserversion, die Jahre veraltet ist.
2. Senden Sie das vollständige Header-Set, das dieser Browser senden würde: Accept, Accept-Language, Accept-Encoding sowie die Sec-CH-UA-Client-Hint-Header, die moderner Chrome mitschickt. Ein Chrome-User-Agent ohne Client Hints ist ein Widerspruch, den Fingerprinting-Systeme erkennen.
3. Halten Sie Header in sich konsistent. Accept-Language sollte zu der Geografie passen, die Ihre IP behauptet. Eine deutsche Residential-IP kombiniert mit einem einsamen en-US-Sprachheader ist ein Mismatch.
4. Setzen Sie den Referer plausibel. Seiten tief in einer Website werden normalerweise von irgendwoher erreicht, nicht aus dem Nichts herbeigerufen.
5. Rotieren Sie User-Agents sparsam und korrekt. Wenn Sie rotieren, rotieren Sie stets das komplette konsistente Header-Bündel zusammen – mischen Sie nie den User-Agent des einen Browsers mit den Client Hints eines anderen.

Rendert das Ziel Inhalte per JavaScript und fordert Nicht-Browser-Clients heraus, reicht Header-Arbeit allein nicht; Sie brauchen einen echten Headless-Browser – und an diesem Punkt ist eine gemanagte Scraping-API oft sinnvoller, als den Stack selbst zu bauen. Ich sage das als jemand, der Systeme lieber selbst baut: Ein eigener Headless-Stack ist wegen Browser-Updates und Fingerprint-Drift ein Dauerprojekt, kein einmaliges Setup. Wo die Abwägung kippt, zeigt unser Vergleich Scraping-APIs versus reine Proxys.

Sessions und Cookies bewusst verwalten

Websites nutzen Cookies, um die Kontinuität eines Besuchers zu verfolgen. Scraper werden auffällig, wenn diese Kontinuität bricht:

• Akzeptieren und persistieren Sie Cookies innerhalb einer logischen Session. Ein Client, der ein Session-Cookie erhält und nie zurücksendet, wirkt kaputt oder feindselig.
• Halten Sie IP und Cookie-Jar gepaart. Ein Session-Cookie, das binnen zehn Minuten aus drei Ländern eintrifft, ist ein unmöglicher Reisender. Wenn Sie IPs rotieren, rotieren Sie die Cookie-Jars mit.
• Passen Sie den Session-Typ an den Job an. Zustandslose Aufgaben – Tausende unabhängige Produktseiten abrufen – passen zu IP-Rotation pro Request ohne persistente Cookies. Zustandsbehaftete Abläufe – durch eine Suchergebnisliste blättern, ein mehrseitiges Listing durchgehen – brauchen eine Sticky Session, bei der IP und Cookies für die Dauer fixiert bleiben.
• Lassen Sie Sessions auslaufen wie ein Mensch. Niemand browst 72 Stunden ununterbrochen auf einer Website. Setzen Sie Session-Identitäten nach einer plausiblen Lebensdauer außer Dienst und beginnen Sie frisch.

Große Residential-Proxy-Anbieter stellen genau deshalb Session-Steuerung bereit. Laut ihren Produktseiten (abgerufen im Juli 2026): Oxylabs bietet rotierende plus Sticky Sessions bis zu 24 Stunden; Decodo (ehemals Smartproxy) bietet Rotation pro Request und Sticky Sessions von Minuten bis zu Tagen; IPRoyal unterstützt Sticky-Intervalle bis zu 7 Tagen; Bright Data bietet sowohl Sticky- als auch Rotationsmodus. Welches Zeitfenster Sie brauchen, hängt allein davon ab, wie lange Ihr längster zustandsbehafteter Ablauf dauert.

Rotierende Residential-IPs für legitimes Volumen

Wenn ein Projekt legitim Skalierung braucht – etwa täglich 100.000 Produktseiten überwachen oder Suchrankings aus 20 Ländern prüfen –, kann eine einzelne IP die Last nicht tragen, ohne jede vernünftige Rate pro IP zu sprengen. Die Verteilung der Anfragen über einen Pool von Residential-IPs hält die Request-Rate pro IP menschlich plausibel, während der Gesamtjob rechtzeitig fertig wird. Residential-IPs tragen zudem normale Verbraucherreputation – anders als Rechenzentrums-Bereiche, die viele Websites pauschal sperren. Die Grundlagen erklärt unser Beitrag dazu, was ein Residential Proxy ist.

Die vier Anbieter, die wir beobachten, veröffentlichen folgende relevante Fähigkeiten (alle Angaben von ihren Produkt- und Richtlinienseiten, abgerufen im Juli 2026; Pool-Größen sind Herstellerangaben, nicht unabhängig verifiziert):

Aus Entwicklersicht (Hinata): Die Pool-Größe wäre mein letztes Auswahlkriterium – sie ist Marketing, kein Engineering. Zuerst würde ich rechnen: erwartetes Monatsvolumen mal Preis pro Gigabyte, und zwar mit dem realen Seitengewicht inklusive Fehlversuchen und ungefilterten Assets – bei 4 bis 7,35 US-Dollar pro Gigabyte bestimmt dieser Posten die Monatsrechnung stärker als der Listenpreis. Danach würde ich prüfen, ob das Sticky-Fenster den längsten zustandsbehafteten Ablauf abdeckt: Ein zu kurzes Fenster erzwingt Workarounds im Code, die am Ende teurer sind als jeder Preisunterschied pro Gigabyte.

Beachten Sie die letzte Zeile. Jeder seriöse Anbieter überprüft seine Kunden, weil sein Geschäft davon abhängt, Missbrauch aus dem Netz fernzuhalten. Bright Data beschränkt den Zugang zum Residential-Netz auf verifizierte Unternehmen, die einen manuell geprüften KYC-Prozess bestehen, laut seiner KYC-FAQ. Oxylabs verlangt bei der Anmeldung ein KYC-Formular von jedem Kunden mit risikobasierter Eskalation, laut seiner KYC- und Sicherheitsrichtlinie. Decodo führt bei jeder Registrierung automatisierte Betrugsprüfungen und KYC durch und blockiert aktiv Hochrisiko-Ziele wie Banking und Ticketing, laut seiner Seite zu Sicherheit und Compliance. IPRoyal wickelt KYC über den Drittanbieter iDenfy ab, laut seiner KYC-Richtlinie. Wenn Ihr Anwendungsfall die Compliance-Prüfung eines Anbieters nicht übersteht, liegt das Problem beim Anwendungsfall, nicht beim Anbieter.

Praktische Rotationsempfehlungen für legitimes Volumen:

• Dimensionieren Sie den Pool nach der Rate, nicht nach dem Ego. Entscheidend ist, dass die Requests pro IP und Stunde auf Ihrem konkreten Ziel menschlich plausibel bleiben – nicht die Pool-Zahl im Marketing. Proxyways Proxy Market Research 2026 (Daten erhoben März–April 2026) beziffert den Median der beworbenen Residential-Pools auf 54 Mio. IPs – jeder große Anbieter hat mehr Adressen, als irgendein legitimer Job braucht.
• Setzen Sie Geo-Targeting zweckgebunden ein. Wenn Sie deutsche Preise beobachten – etwa auf Amazon.de, Otto oder Idealo –, fordern Sie deutsche IPs an und senden Sie durchgängig deutsche Header. Geo-Targeting dient dazu, zu sehen, was echte lokale Nutzer sehen – nicht dazu, regionale Sperren zu umgehen.
• Halten Sie Rotations- und Session-Strategie im Einklang, wie im Abschnitt zu Sessions beschrieben.

Auswahlkriterien jenseits des Blockings – Preisstrukturen, Testphasen, Support – finden Sie in unserem Überblick der besten Residential Proxies.

Warum kostenlose Proxys Blockierungen verschlimmern statt verhindern

Die verlockende Abkürzung scheitert an der Faktenlage. Eine 30-monatige akademische Langzeitstudie zu mehr als 640.600 kostenlosen Proxys von 11 Anbietern, vorgestellt auf der NDSS MADWeb 2024, fand heraus, dass nur 34,5 % überhaupt jemals aktiv waren, identifizierte 4.452 verschiedene Schwachstellen auf Proxy-IPs – darunter 1.755, die Remote Code Execution erlaubten – und ertappte 16.923 Proxys dabei, Inhalte während der Übertragung zu manipulieren.

Speziell fürs Anti-Blocking sind kostenlose Proxys kontraproduktiv: Die IPs werden von jedem anderen Gratis-Scraper geteilt, der dieselben Ziele ansteuert, und kommen daher auf den Blocklisten großer Websites bereits verbrannt an. Sie erben die schlechte Reputation anderer – zusätzlich zu Ihrem eigenen Risiko. Das vollständige Argument liefert unsere Gegenüberstellung kostenlose versus bezahlte Proxys.

Blockierungssignale kontinuierlich überwachen

Blockierungen kommen selten auf einen Schlag; sie eskalieren. Instrumentieren Sie Ihren Scraper so, dass Sie die Eskalation früh sehen:

1. Statuscode-Verteilung pro Domain. Ein steigender Anteil von 403-, 429- oder 503-Antworten ist der erste Alarm. Alarmieren Sie auf Trends, nicht auf einzelne Fehlschläge.
2. CAPTCHA- und Challenge-Seiten-Erkennung. Viele Websites liefern HTTP 200 mit einer Challenge-Seite statt des Inhalts. Fingerprinten Sie Challenge-Seiten (Titelmuster, bekanntes Markup) und zählen Sie sie als Fehlschläge – sonst lügen Ihre Erfolgsmetriken. Für mich ist das die tückischste Lücke: ein grünes Dashboard über einer Pipeline, die längst Challenge-Seiten statt Daten einsammelt.
3. Anomalien bei Antwortgröße und Inhalt. Eine Produktseite, die plötzlich 5 KB statt 80 KB liefert oder beim Parsen null extrahierte Felder ergibt, ist wahrscheinlich eine Sperrseite oder Köderdaten.
4. Latenzverschiebungen. Progressives Throttling – Antworten, die sich von 300 ms auf 5 Sekunden verlangsamen – ist ein weiches Blockierungssignal, das harten Sperren vorausgeht.
5. Erfolgsquote pro Proxy-Subnetz und pro Session. Häufen sich Fehlschläge auf bestimmten IP-Bereichen, ziehen Sie diese Bereiche aus dem Verkehr; häufen sie sich auf langlebigen Sessions, verkürzen Sie die Session-Lebensdauer.

Wenn Signale anschlagen, lautet die richtige Reaktion: verlangsamen und diagnostizieren – nicht die Aggression erhöhen. Halbieren Sie Ihre Request-Rate, prüfen Sie, ob Ihre Header noch zu einem aktuellen Browser passen, klären Sie, ob die Website ihre Struktur oder ihre Bedingungen geändert hat – und setzen Sie erst dann fort. Scraper, die auf Blockierungen mit mehr Druck reagieren, verwandeln temporäres Throttling in dauerhafte Sperren.

Was wir bewusst nicht behandeln

Manche Anti-Blocking-Fragen haben Antworten, die wir nicht veröffentlichen, weil die Technik ausschließlich dazu existiert, Zugangskontrollen auszuhebeln:

• Umgehen von Paywalls oder Login-Schranken. Inhalte hinter einer Authentifizierung sind bewusst zugangsbeschränkt. Diese Kontrolle automatisiert zu umgehen ist unbefugter Zugriff – egal mit welchem Werkzeug.
• CAPTCHA-Solver-Farmen. Ein CAPTCHA ist das Nein einer Website zur Automatisierung. Industrielles Lösen existiert nur, um dieses Nein zu übergehen.
• Scrapen personenbezogener Daten. Namen, E-Mail-Adressen, Profile und Kontaktdaten unterliegen rechtlichen Pflichten (DSGVO, CCPA) und bergen reales Schadenspotenzial – in der EU drohen bei DSGVO-Verstößen empfindliche Bußgelder. Seriöse Anbieter schließen diese Anwendungsfälle in ihren Acceptable-Use-Richtlinien aus gutem Grund aus.
• Kaufautomatisierung. Sneaker-Bots, Ticket-Scalping und Konto-Farming sind die Anwendungsfälle, die Proxys ihren schlechten Ruf eingebracht haben – und die KYC-Programme der Anbieter existieren, um sie herauszufiltern.

Wenn ein Projekt eines davon braucht, hat es kein Blockierungsproblem, sondern ein Erlaubnisproblem – und das behebt kein Engineering.

Checkliste: ein ethisches, DSGVO-konformes Anti-Blocking-Setup

• robots.txt und Nutzungsbedingungen lesen; bestätigen, dass die Daten öffentlich und nicht personenbezogen sind
• Eine offizielle API oder einen Feed bevorzugen, wo es sie gibt
• Rate Limiting pro Domain mit Jitter; Retry-After befolgen; exponentiell zurückweichen
• Ein vollständiges, in sich konsistentes, aktuelles Browser-Header-Set senden
• Cookies innerhalb von Sessions persistieren; Cookie-Jars mit IPs paaren; Sessions plausibel auslaufen lassen
• Rotierende Residential-IPs eines KYC-durchsetzenden Anbieters nutzen, wenn das Volumen es wirklich erfordert
• Sticky-Session-Fenster am längsten zustandsbehafteten Ablauf ausrichten
• Statuscodes, Challenge-Seiten, Inhaltsanomalien und Latenz pro Domain überwachen
• Auf Blockierungssignale mit Verlangsamen und Diagnose reagieren – niemals mit Eskalation

So betrieben ist Anti-Blocking kein Wettrüsten, sondern grundlegende Höflichkeit, in Engineering übersetzt. Websites blockieren Traffic, der sich schlecht benimmt; die dauerhafte Lösung ist Traffic, der sich gut benimmt. Den größeren Kontext zu Tools, Rechtslage und Architektur liefert unser vollständiger Web-Scraping-Guide.