Web Scraping ohne Sperren: Daten regelkonform erfassen

Ein Skript zur Preisbeobachtung läuft am ersten Tag problemlos, liefert am zweiten halb leere Seiten und erhält am dritten auf jede Anfrage ein 403. Fast jeder, der Scraper schreibt, erlebt das, und die erste Reaktion ist meist die Suche nach „mehr IPs" oder „besserem Verstecken". Die meisten Sperren haben eine gewöhnlichere Ursache: Dutzende Anfragen pro Sekunde, Header, die nie zu einem echten Browser passen, die gesamte Last auf einer einzigen IP-Adresse und Regeln, die die Website offen nennt, die aber niemand gelesen hat.

In diesem Artikel erklären wir, warum Web-Scraping-Tools gesperrt werden, woran Sie eine Sperre erkennen und welche Ursachen dahinterstehen. Danach behandeln wir das Anpassen der Anfragegeschwindigkeit, konsistente Header, wann IP-Rotation wirklich nötig ist, eine feste IP dort, wo eine Sitzung gebraucht wird, sowie robots.txt und die Bedingungen der Website. Dies ist keine Anleitung zum „Umgehen von Schutzmaßnahmen": „ohne Sperren" im Titel bedeutet, nicht in Sperren zu laufen, weil Sie der Website nicht schaden und ihre Regeln befolgen.

Warum sperren Websites Scraper?#

Hinter der Begrenzung automatisierten Verkehrs stehen meist konkrete Kosten und keine Unterstellung böser Absicht:

• Serverlast. Ein einziges Skript mit Hunderten Anfragen pro Sekunde kann die Ressourcen aufbrauchen, die ein kleiner Onlineshop für echte Besucher bereithält. Bei Such- und Filterseiten, die die Datenbank abfragen, vervielfacht sich der Effekt.
• Bandbreite und Infrastrukturkosten. Jede Anfrage erscheint auf der Server- und CDN-Rechnung der Website.
• Schutz von Inhalten und Geschäftsdaten. Werden Preise, Bestände und Angebotsdaten massenhaft von Wettbewerbern abgezogen, will der Betreiber das womöglich einschränken.
• Sicherheit. Brute-Force-Anmeldungen, Kartentests und das Horten von Beständen laufen ebenfalls über automatisierten Verkehr. Auf den ersten Blick können Schutzsysteme diesen Verkehr nicht von einem legitimen Scraper unterscheiden.

Die meisten dieser Entscheidungen fallen nicht im Code der Website selbst, sondern in der Bot-Management-Schicht davor. CDNs und Sicherheitsdienste bewerten jede Anfrage anhand von Signalen wie Geschwindigkeit, IP-Reputation, Header-Konsistenz und Verhalten. Ein Beispiel dafür, wie diese Schicht Bot-Verkehr einordnet, finden Sie in Cloudflare Precursor.

Woran erkennen Sie eine Sperre?#

Sperren kommen nicht immer mit einer klaren Fehlermeldung. Sehen Sie eines dieser Symptome in den Daten Ihres Scrapers, ist eine Sperre die wahrscheinliche Ursache:

• 403 Forbidden: Die Anfrage wurde verstanden, aber abgelehnt. Mögliche Gründe sind IP-Reputation, fehlende Header oder eine geografische Beschränkung.
• 429 Too Many Requests: Sie haben das Rate-Limit überschritten. Oft sagt ein Retry-After-Header, wie lange Sie warten sollen.
• 503 Service Unavailable: Der Server ist vielleicht wirklich ausgelastet, oder ein Bot-Schutzsystem liefert diese Antwort vorübergehend.
• 200, aber eine Prüfseite: Der Statuscode wirkt erfolgreich, doch der Seiteninhalt ist statt einer Produktliste ein Prüfbildschirm.
• 200, aber leerer oder unvollständiger Inhalt: Ihre Selektoren finden nichts. Das kann an einer Sperre liegen oder daran, dass die Seite ihren Inhalt mit JavaScript lädt.
• Weiterleitung zur Anmeldeseite: Ihre Sitzung wurde beendet, oft wegen eines IP-Wechsels mitten in der Sitzung.
• Immer langsamere Antworten: Manche Systeme verzögern die Antwort absichtlich, statt die Anfrage abzulehnen.

Jeden HTTP-Statuscode und die Frage, bei welchen Sie wiederholen sollten, erklären wir in HTTP-Statuscodes beim Web Scraping. Ob leerer Inhalt eine Sperre oder eine dynamische Seite ist, klären Sie mit Statische und dynamische Seiten.

Anfragegeschwindigkeit: Wie beachten Sie Rate-Limits?#

Die häufigste und am leichtesten vermeidbare Ursache für Sperren ist die Geschwindigkeit. Ein Mensch öffnet in einem Onlineshop alle paar Sekunden eine Seite; ein mit asyncio geschriebener Scraper kann in derselben Zeit Hunderte Anfragen senden. RFC 6585 definiert den Code 429 Too Many Requests genau für diese Situation und hält fest, dass der Server mit einem Retry-After-Header angeben kann, wie lange zu warten ist.

Die Grundregeln, um die Geschwindigkeit im Griff zu behalten:

1. Setzen Sie eine Nebenläufigkeitsgrenze pro Website. Halten Sie die Zahl offener Anfragen an dieselbe Domain klein. Die Gesamt-Nebenläufigkeit darf hoch sein, doch der Anteil pro Website sollte gering bleiben.
2. Fügen Sie zufällige Pausen zwischen Anfragen ein. Eine Anfrage exakt alle 2 Sekunden fällt stärker auf als unregelmäßige Abstände und verhindert kurze Spitzen nicht.
3. Werden Sie bei 429 und 503 langsamer, nicht schneller. Eine fehlgeschlagene Anfrage sofort erneut zu senden, verschärft das Problem. Nutzen Sie exponentiellen Backoff.
4. Beachten Sie den Header Retry-After. Der Wert kann eine Anzahl Sekunden oder ein HTTP-Datum sein; die MDN-Erklärung zeigt beide Formen.
5. Senden Sie keine unnötigen Anfragen. Um unveränderte Seiten nicht erneut herunterzuladen, speichern Sie ETag- und Last-Modified-Werte und senden bedingte Anfragen mit If-None-Match und If-Modified-Since; hat sich die Seite nicht geändert, antwortet der Server mit 304 ohne Body.
6. Nutzen Sie die Sitemap. Beginnen Sie mit den Adressen aus der sitemap.xml der Website, statt die ganze Website Link für Link zu durchsuchen.
7. Meiden Sie Stoßzeiten. Führen Sie keine Massenerfassung durch, wenn die Zielgruppe der Website am aktivsten ist.

Die folgende Python-Funktion beachtet bei 429-, 502-, 503- und 504-Antworten den Header Retry-After; fehlt er, nutzt sie exponentiellen Backoff mit Zufallskomponente. Antworten wie 403 und 404 wiederholt sie nicht, weil erneutes Senden das Ergebnis nicht ändert:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests

RETRY_STATUS = {429, 502, 503, 504}


def retry_after_seconds(value):
    """Retry-After kann Sekunden oder ein HTTP-Datum sein."""
    if not value:
        return None
    if value.isdigit():
        return int(value)
    try:
        when = parsedate_to_datetime(value)
    except (TypeError, ValueError):
        return None
    return max(0.0, (when - datetime.now(timezone.utc)).total_seconds())


def polite_get(session, url, max_attempts=5, base=1.0, cap=60.0):
    for attempt in range(max_attempts):
        try:
            response = session.get(url, timeout=20)
        except (requests.ConnectionError, requests.Timeout):
            response = None

        if response is not None and response.status_code not in RETRY_STATUS:
            return response  # Antworten wie 200, 404 und 403 werden nicht wiederholt

        wait = None
        if response is not None:
            wait = retry_after_seconds(response.headers.get("Retry-After"))
        if wait is None:
            wait = min(cap, base * 2**attempt) * random.uniform(0.5, 1.0)
        time.sleep(min(wait, cap))

    raise RuntimeError(f"{url}: nach {max_attempts} Versuchen keine Antwort")

Es genügt, diese Funktion über eine Liste von Seiten mit Pausen zwischen den Anfragen zu nutzen:

session = requests.Session()
session.headers.update({
    "User-Agent": "ExamplePriceBot/1.0 (+https://example.com/about-our-bot)",
    "Accept-Language": "de-DE,de;q=0.9",
})

for url in urls:
    response = polite_get(session, url)
    if response.status_code == 403:
        print("Zugriff verweigert, anhalten und Ursache prüfen:", url)
        break
    process(response.text)
    time.sleep(random.uniform(2, 5))

Wie Sie die Nebenläufigkeit einstellen und was die Geschwindigkeit wirklich begrenzt, erklären wir in Concurrency und Parallelism.

Header und eine konsistente Client-Identität#

Die Header einer HTTP-Anfrage sagen, wer der Client ist und was er akzeptiert. Die Standard-Header von Bibliotheken unterscheiden sich stark von denen eines Browsers. Python Requests sendet standardmäßig einen User-Agent wie python-requests/2.x; viele Websites lehnen diesen Wert direkt ab.

Hier gibt es zwei Ansätze mit unterschiedlichem Zweck:

Sich vorstellen. Legitime Crawler schreiben in den User-Agent den Namen des Bots und eine Adresse mit Informationen über ihn: ExamplePriceBot/1.0 (+https://example.com/about-our-bot). Sieht der Websiteadministrator den Verkehr, weiß er, wer ihn sendet und wie er Sie erreicht; bei Problemen kann er Kontakt aufnehmen, statt zu sperren. Er kann auch robots.txt-Regeln speziell für diesen Namen schreiben.

Konsistenz. Welche Identität Sie auch nutzen, sie muss über die Anfrage hinweg konsistent sein. Beispiele für Inkonsistenz:

• Ein User-Agent, der sich bei jeder Anfrage zufällig ändert, aber mit denselben Cookies und derselben IP.
• Ein User-Agent, der Chrome behauptet, aber ohne die Header Accept, Accept-Language und Sec-CH-UA, die Chrome bei jeder Anfrage sendet.
• Eine Website in der Türkiye mit Accept-Language: en-US und einer IP aus den USA besuchen und türkische Preise erwarten.

Welche Signale neben Headern Browser identifizieren, erklären wir in Browser-Fingerprinting. Diese Signale zu fälschen, um Bot-Schutz zu umgehen, empfiehlt dieser Artikel nicht; Ziel ist, dass Ihr Client konsistent angibt, was er ist.

IP-Vielfalt: Wann ist Rotation nötig?#

Starker Verkehr von einer einzigen IP-Adresse ist die Einheit, auf die Rate-Limits am leichtesten angewendet werden. Deshalb ist „Ich wurde gesperrt, ich wechsle die IP" ein so verbreiteter Reflex. Rotation hat aber zwei legitime Zwecke und eine falsche Verwendung.

Legitimer Zweck 1: Last verteilen. Eine Aufgabe, die öffentliche Preisseiten von Hunderten verschiedener Websites sammelt und den gesamten Verkehr über eine IP schickt, verschafft dieser IP schnell einen schlechten Ruf und lässt sie womöglich auf allgemeinen Reputationslisten markieren, auch ohne das Limit einer einzelnen Website zu überschreiten. Verkehr auf verschiedene Adressen zu verteilen, hält die Last pro Adresse auf einem realistischen Niveau.

Legitimer Zweck 2: Inhalte nach Standort sehen. Preise, Bestände und Suchergebnisse ändern sich mit Land und Stadt des Besuchers. Von verschiedenen Standorten aus ins Netz zu gehen, ist der einzige Weg, die echte Ansicht jedes Marktes zu erfassen.

Falsche Verwendung: eine ausdrückliche Sperre umgehen. Hat die Website Sie mit einem Rate-Limit gewarnt, den Pfad in robots.txt gesperrt oder automatisierten Zugriff in ihren Bedingungen ausdrücklich untersagt, löst ein IP-Wechsel bei gleicher Geschwindigkeit nichts; er bedeutet, eine klar geäußerte Präferenz des Betreibers zu ignorieren.

Rotation richten Sie mit einem Rotierender Proxy ein, der über eine einzige Adresse bei jeder Verbindung eine andere Ausgangs-IP liefert. Für Aufgaben, die Adressen echter Privatanschlüsse brauchen, wird ein Residential-Proxy bevorzugt. Einen rotierenden Aufbau in Python zeigen wir Schritt für Schritt in Proxys in Python rotieren.

Eine Sticky-IP, wo eine Sitzung nötig ist#

Die IP bei jeder Anfrage zu wechseln, passt nicht zu jeder Aufgabe. Bei diesen Aufgaben muss die IP-Adresse eine Weile fest bleiben:

• Angemeldete Seiten. Ziehen Sie Berichte aus dem Panel Ihres eigenen Kontos, löst ein IP-Wechsel mitten in der Sitzung Sicherheitsprüfungen aus, und die Sitzung wird geschlossen.
• Mehrstufige Abläufe. Abläufe mit serverseitigem Zustand wie Warenkorb, Filterauswahl oder Seitenblättern.
• Cookie-gebundene Besuche. Anfragen mit demselben Cookie aus verschiedenen Ländern ergeben ein widersprüchliches Besucherbild.

Für diese Aufgaben behält ein Sticky-Proxy dieselbe Ausgangs-IP für einen festgelegten Zeitraum. Die Grundregel: eine Sitzung = eine IP; nach Ende der Sitzung darf sich die IP ändern.

robots.txt und die Bedingungen der Website#

Bevor Sie Daten von einer Website erfassen, sollten Sie zwei Dokumente prüfen.

robots.txt ist die Datei, in der eine Website angibt, welche Pfade Bots nicht crawlen sollen, und ihr Format ist in RFC 9309 standardisiert. Mit Disallow gesperrte Pfade nicht zu crawlen, bedeutet, eine ausdrücklich geäußerte Präferenz der Website zu respektieren. Wie Sie die Datei lesen und mit Python prüfen, erklären wir in Was ist robots.txt und wie liest man die Datei?.

Nutzungsbedingungen können Regeln zum automatisierten Zugriff enthalten. Manche Websites verbieten Scraping ganz, manche begrenzen es auf eine bestimmte Geschwindigkeit, manche bieten eine offizielle API für die Daten. Gibt es eine offizielle API, ist sie fast immer der bessere Weg: Die Daten kommen strukturiert, Ihr Code bricht bei Designänderungen nicht, und Ihr Zugriff beruht auf einer Vereinbarung.

Seiten mit personenbezogenen Daten verlangen besondere Sorgfalt; Pflichten nach KVKK in der Türkiye und DSGVO in Europa gelten unabhängig davon, wie Sie die Daten erfassen. Den rechtlichen Rahmen behandeln wir in Ist Web Scraping legal?.

Manche Websites platzieren außerdem versteckte Links, die Besucher nicht sehen, in denen sich Bots aber verfangen. Ein Crawler, der sichtbaren Links folgt und seinen Umfang eng hält, bleibt diesen Fallen von selbst fern; den Mechanismus erklären wir in Honeypot-Fallen.

Was tun, wenn ein CAPTCHA erscheint?#

Ein Prüfbildschirm vor einem Scraper bedeutet, dass die Website Ihren Verkehr für verdächtig hält. An diesem Punkt werden weder CAPTCHA-Lösedienste noch Plugins zur Umgehung der Erkennung empfohlen; sie bedeuten, eine ausdrückliche Kontrolle der Website zu umgehen, und verdecken meist die Ursache. Gehen Sie stattdessen in dieser Reihenfolge vor:

1. Stoppen Sie den Scraper. Weitere Anfragen an den Prüfbildschirm verschlechtern die Reputation von IP und Sitzung zusätzlich.
2. Messen Sie die Geschwindigkeit. Prüfen Sie, wie viele Anfragen Sie in der letzten Minute an dieselbe Website gesendet haben.
3. Vergleichen Sie die Header mit einem echten Browser. Fehlen Header oder widersprechen sie sich?
4. Überprüfen Sie den Umfang. Crawlen Sie Pfade, die robots.txt sperrt, oder Seiten, die Sie nicht brauchen?
5. Suchen Sie nach Alternativen. Eine offizielle API, eine Exportoption oder direkter Kontakt zum Websitebetreiber.
6. Erst dann versuchen Sie es mit geringerer Geschwindigkeit und konsistenter Client-Identität erneut.

Warum Prüfbildschirme bei der Browserautomatisierung erscheinen, erklären wir mit derselben Diagnoselogik in Puppeteer und CAPTCHA.

Was tun bei einer Sperre? Diagnoseliste#

• Wissen Sie, wann die Sperre begann und wie hoch die Anfragerate in diesem Moment war?
• Welcher Antwortcode kommt: 403, 429, 503 oder 200 mit Prüfseite?
• Kam ein Retry-After-Header, und haben Sie ihn beachtet?
• Öffnet sich dieselbe Adresse in einem echten Browser mit derselben IP?
• Sind Ihre Header konsistent, oder ist der User-Agent der Standardwert der Bibliothek?
• Sind die gecrawlten Pfade in robots.txt gesperrt?
• Was sagen die Bedingungen der Website zu automatisiertem Zugriff?
• Ändert sich die IP in einem Ablauf, der eine Sitzung braucht?
• Stammt der leere Inhalt von einer Seite, die mit JavaScript lädt?
• Gibt es eine offizielle API, die dieselben Daten liefert?

Anwendungsfälle#

• Preisbeobachtung: einige Male am Tag, Produktadressen aus der Sitemap, nur geänderte Seiten per bedingter Anfrage. Den Aufbau beschreibt unsere Seite zur Preisüberwachung.
• Marktforschung und Katalogerfassung: öffentliche Seiten vieler verschiedener Websites, geringe Nebenläufigkeit pro Website, Rotation zur Lastverteilung. Den allgemeinen Aufbau zeigt unsere Seite zur Datenerfassung.
• Breites Crawling: ein Crawler, der Links folgt, robots.txt beachtet und pro Domain eine Warteschlange führt. Die Skalierung beschreibt unsere Seite zur Web-Crawler-Lösung.
• Suchergebnisse nach Standort verfolgen: zuerst die offizielle API, dann Ausgangspunkte auf Stadtebene. Details finden Sie in SEO-Ranking-Tracking automatisieren.
• Robuste Selektoren: Auch ohne Sperre kommen Daten leer zurück, wenn sich die Seitenstruktur ändert. Wie Sie Selektoren schreiben, die nicht brechen, erklären wir in CSS-Selektor oder XPath.

Häufige Fehler#

• Hunderte Anfragen auf einmal mit Promise.all oder asyncio.gather starten. Die Gesamtgeschwindigkeit wirkt hoch, doch die Last pro Website wird untragbar.
• Bei 429 sofort wiederholen. Wiederholungen ohne Backoff verlängern das Rate-Limit.
• Den Standard-User-Agent der Bibliothek nutzen. Viele Websites sperren diesen Wert direkt.
• Bei jeder Anfrage einen zufälligen User-Agent erzeugen. Eine wechselnde Identität mit derselben IP und denselben Cookies ist ein Inkonsistenzsignal.
• Bei einer Aufgabe mit Sitzung die IP bei jeder Anfrage wechseln. Die Sitzung schließt sich, und Sie werden zur Anmeldeseite weitergeleitet.
• Einen erfolgreichen Statuscode für erfolgreiche Daten halten. Eine mit 200 gelieferte Prüfseite erzeugt stillschweigend fehlerhafte Daten, weil die Selektoren leer zurückkommen. Prüfen Sie, ob ein erwartetes Element im Antwortinhalt vorhanden ist.
• robots.txt nicht lesen. Ohne Kenntnis der Präferenz der Website zu crawlen, ist ethisch wie rechtlich ein schwacher Anfang.

Entscheidungshilfe#

Häufig gestellte Fragen#

Verhindert ein Proxy Sperren vollständig?#

Nein. Ein Proxy verteilt den Verkehr auf verschiedene IP-Adressen und zeigt standortabhängige Inhalte, doch Anfragen, die zu schnell gesendet werden, widersprüchliche Header tragen oder gesperrte Pfade aufrufen, werden unabhängig von der IP gesperrt. Ein Proxy wirkt zusammen mit der richtigen Geschwindigkeit und einem konsistenten Client.

Wie viele Anfragen pro Sekunde sind unbedenklich?#

Einen einzigen unbedenklichen Wert für jede Website gibt es nicht; er hängt von Infrastruktur, Seitengewicht und Tageszeit ab. Nennt robots.txt ein Crawl-delay, halten Sie sich daran. Wenn nicht, beginnen Sie niedrig, erhöhen langsam unter Beobachtung von 429-Antworten und Antwortzeiten und fahren sofort zurück, wenn der Server langsamer wird.

Browserwert oder Bot-Name als User-Agent?#

Für einen legitimen Crawler wird empfohlen, den Namen des Bots und eine Kontaktadresse anzugeben. Der Websiteadministrator sieht, wer Sie sind, und kann Sie bei Problemen erreichen. Manche Websites sperren unbekannte Bots standardmäßig; dann ist eine Anfrage um Erlaubnis oder die Suche nach einer offiziellen API solider, als wie ein Browser aussehen zu wollen.

Verringert ein Headless-Browser das Sperrrisiko?#

Er macht Daten auf Seiten sichtbar, die mit JavaScript laden, verringert das Sperrrisiko aber nicht von selbst. Im Gegenteil erzeugt jede Seite Dutzende zusätzliche Anfragen (Bilder, Skripte, Stylesheets) und belastet die Website stärker. Die API-Anfrage zu finden, die die Seite im Hintergrund stellt, ist meist effizienter.

Meine IP wurde gesperrt. Wie lange dauert das?#

Das variiert je nach Website: vom minutenlangen Rate-Limit bis zur tagelangen Sperrliste. Gibt es einen Retry-After-Header, nennt er die Dauer. Wenn nicht, warten Sie eine Weile und senden Sie mit sehr geringer Geschwindigkeit eine einzelne Anfrage zur Prüfung; fahren Sie nicht mit derselben Geschwindigkeit fort, bevor die Sperre aufgehoben ist.

Brauche ich all diese Maßnahmen für eine kleine einmalige Aufgabe?#

Für eine einmalige Aufgabe mit einigen Dutzend Seiten reicht es meist, einige Sekunden zwischen Anfragen zu warten, einen aussagekräftigen User-Agent zu nutzen und robots.txt zu prüfen. Die übrigen Maßnahmen werden wichtig, wenn die Aufgabe regelmäßig und umfangreich wird.

Fazit#

Die meisten Scraper werden nicht gesperrt, weil sie sich nicht verstecken können, sondern weil sie die Website belasten und widersprüchlich wirken. Begrenzen Sie die Anfragegeschwindigkeit pro Website, beachten Sie 429-Antworten und Retry-After, laden Sie unveränderte Seiten nicht erneut, nutzen Sie eine konsistente, sich vorstellende Client-Identität und lesen Sie robots.txt sowie die Bedingungen der Website. IP-Rotation dient der Lastverteilung und standortabhängigen Inhalten, eine Sticky-IP Aufgaben mit Sitzung; keines davon ist ein Mittel, eine ausdrückliche Sperre zu umgehen. Proxy-Typen für Ihre Datenerfassung finden Sie in unseren Proxy-Diensten.