Google-Suche scrapen, ohne blockiert zu werden: was wirklich passiert

“Google blockiert Scraper” stimmt, ist aber zu vage, um daraus zu handeln. Hier ist, was tatsächlich passiert, der Reihe nach, wenn ein Skript anfängt, automatisierte Queries zu schicken, und warum die übliche erste Lösung (mehr Proxys) das Problem nur hinauszögert.

Rate-Limiting ist pro IP, und strenger als du denkst

Google drosselt basierend auf dem Anfragevolumen von einer einzelnen IP-Adresse in einem kurzen Zeitfenster. Datacenter-IP-Bereiche bekommen ein merklich engeres Limit als residentielle, weil Google erkennen kann, dass eine Anfrage von AWS, Google Cloud oder einem Hosting-Anbieter kommt statt von jemandes Heimanschluss. Eine Handvoll schneller Anfragen von einer Datacenter-IP reicht oft, um eine Challenge auszulösen. Das ist die erste Wand, an die fast jeder stößt, und deshalb funktioniert “einfach eine Verzögerung einbauen” genau so lange, wie dein Anfragevolumen trivial bleibt.

CAPTCHA und die Consent-Wand

Nach dem Rate-Limit ist Googles nächste Antwort kein Fehler, sondern eine andere Seite: eine CAPTCHA-Challenge, oder bei EU-/UK-Traffic ein Cookie-Consent-Interstitial, das akzeptiert werden muss, bevor überhaupt Suchergebnisse rendern. Beides bricht ein Skript, das organic_results oben im HTML erwartet. Keins von beidem lässt sich durch erneutes Versuchen lösen: Ein CAPTCHA braucht einen Menschen (oder einen bezahlten Solving-Service, der sein eigenes Kosten- und Zuverlässigkeitsproblem ist), und eine Consent-Wand braucht eine Session, die sie bereits akzeptiert hat, was Cookie-Handling bedeutet, das die meisten Scraper nicht implementieren.

Fingerprinting geht über die IP hinaus

Die IP-Adresse ist das erste Signal, nicht das einzige. Googles Anti-Automatisierungssysteme schauen auch auf TLS-Handshake-Eigenschaften, Reihenfolge und Vollständigkeit der HTTP-Header, browserseitige Signale, wenn ein Headless-Browser im Spiel ist (Viewport-Größe, installierte Fonts, WebGL-Renderer-String, ob navigator.webdriver gesetzt ist), und Verhaltensmuster wie Anfragen, die in verdächtig regelmäßigen Abständen eintreffen. Eine Anfrage, die das Rate-Limit übersteht, aber nur einen nackten User-Agent-Header trägt und keinen der Header, die eine echte Chrome-Anfrage schicken würde, liest sich trotzdem als automatisiert. Deshalb bringt das Austauschen von Proxys allein, ohne den Rest des Anfrage-Fingerprints zu fixen, sehr wenig.

Die Pagination-Mathematik, die niemand einkalkuliert

Google respektiert den Parameter num=100 nicht mehr, der früher 100 Ergebnisse in einer einzigen Anfrage lieferte. “Die Top 100 Ergebnisse” für eine Query zu bekommen, bedeutet jetzt zehn separate paginierte Anfragen, zehn Ergebnisse pro Seite. Wenn deine Rank-Tracking-Tabelle um die alte Annahme herum gebaut wurde, ist dein echtes Anfragevolumen, und deine echte Exposition gegenüber den Rate-Limit- und Fingerprinting-Problemen oben, das 10-Fache dessen, was die Tabelle sagt. Allein das hat Kostenschätzungen und Infrastrukturpläne kaputtgemacht, die vor der Änderung geschrieben und nie überarbeitet wurden.

Warum Proxys allein es nicht lösen

Rotierende residentielle Proxys beheben genau eins der vier Probleme oben: das IP-basierte Rate-Limit. Sie tun nichts gegen CAPTCHA-Seiten, die bereits ausgelöst wurden, nichts gegen TLS- und Header-Fingerprinting, und nichts gegen die Pagination-Mathematik. Ein Proxy-Pool kombiniert mit einem naiven requests.get und Standard-Headern wird trotzdem eine Challenge bekommen, nur von einer rotierenden Menge an IPs statt von einer. Alle vier Probleme selbst zu lösen bedeutet, eine echte Browser-Engine zu betreiben (für TLS- und JS-Fingerprint-Parität), Header-Profile zu pflegen, die echtem Traffic entsprechen, Consent-Flows zu handhaben und laufend für Proxy-Bandbreite zu zahlen, während sich Googles Erkennung ändert. Das ist eine dauerhafte Infrastrukturverpflichtung, kein einmaliges Skript.

Der API-Weg

Die Alternative ist, nichts davon selbst zu betreiben:

import requests

API_KEY = "faf_live_..."  # dein FastAF-Key

resp = requests.get(
    "https://api.fastaf.co/v1/serp",
    params={"query": "web scraping api", "country": "us"},
    headers={"Authorization": f"Bearer {API_KEY}"},
    timeout=60,
)
resp.raise_for_status()

for result in resp.json()["organic_results"]:
    print(result["rank"], result["title"], result["link"])

Die Anfrage läuft über Infrastruktur, die gebaut ist, um mit Rate-Limiting, Fingerprinting und Consent-Wänden umzugehen, und du bekommst geparstes JSON zurück: organic_results, und people_also_ask, knowledge_graph, ads oder related_searches, wenn die Query sie hergibt. Eine Suche kostet 5 Credits, und fehlgeschlagene Anfragen werden nie berechnet, da Credits beim Start der Anfrage reserviert und zurückgegeben werden, wenn kein Ergebnis kommt.

Kurzversion

Vier separate Mechanismen stapeln sich gegen einen rohen Scraper: IP-Rate-Limits, CAPTCHA- und Consent-Wände, Fingerprinting jenseits der IP, und Pagination-Kosten, die das 10-Fache dessen sind, was auf dem Papier aussieht. Ein Proxy-Pool adressiert eins von vieren. Ob sich das zu bauen lohnt, hängt davon ab, wie viel von deiner Engineering-Zeit du in Such-Infrastruktur stecken willst statt in das Produkt, das die Ergebnisse konsumiert. Die Kreditkosten für dein Volumen findest du unter Preise.