Proxys rotieren für Google SERPsSuchergebnisse ohne Sperren scrapen

Das Scraping von Google-Suchergebnissen scheitert aus einem einzigen Grund: Google erkennt einen Strom von Anfragen von einer einzelnen IP-Adresse für das, was er ist, nämlich einen Bot, und beginnt innerhalb weniger Dutzend Anfragen mit CAPTCHAs und 429-Fehlern zu antworten. Die Lösung ist kein cleverer Header und keine längere Verzögerung. Sie besteht darin, jede Anfrage von einer anderen IP-Adresse zu senden, die wie ein echter Mensch aussieht, und genau das leistet die Proxy-Rotation. Wählen Sie das richtige Rotationsmodell und den richtigen IP-Typ, wird das Scraping von Suchergebnisseiten zur Routine; treffen Sie die falsche Wahl, verbringen Sie Ihre Zeit mit dem Lösen von Consent-Seiten statt mit dem Parsen von Ergebnissen.

Dieser Beitrag ist die praktische Variante: warum Google auf diese Weise sperrt, warum die Rotation pro Anfrage bei SERPs der statischen Pool-Rotation überlegen ist, welcher IP-Typ tatsächlich funktioniert, ein lauffähiges Python-Beispiel und der Punkt, ab dem ein verwalteter SERP-Endpunkt schlicht weniger Aufwand bedeutet als eine eigene Rotation. Wer zuerst die Proxy-Grundlagen verstehen möchte, findet in Was ist ein Proxy-Server die eine Indirektionsebene erklärt, auf der alles hier aufbaut.

Warum Google Scraper so aggressiv blockiert

Googles gesamtes Geschäft besteht darin, Menschen zu bedienen, daher sind seine Missbrauchsabwehrmechanismen darauf ausgelegt, alles zu erkennen, was kein Mensch ist. Ein Scraper löst gleich mehrere davon gleichzeitig aus. Das sichtbarste Signal ist das Anfragevolumen von einer einzelnen Adresse: Ein echter Nutzer führt eine Handvoll Suchen pro Stunde durch, während ein naiver Scraper von einer einzigen IP hunderte pro Minute abfeuert. Diese Rate allein reicht aus, um eine sorry/index-Consent-Seite oder ein CAPTCHA auszulösen.

Die IP-Adresse selbst ist das zweite Signal. Google weiß, welche Adressbereiche zu Cloud- und Hosting-Anbietern gehören, sodass Traffic von einer Rechenzentrums-IP mit einem Vertrauensdefizit startet, bevor überhaupt eine einzige Anfrage gesendet wurde. Hinzu kommen Überprüfungen der Anfrageform: fehlende oder roboterhafte Header, ein TLS-Fingerabdruck, der nicht zum angegebenen Browser-User-Agent passt, keine Cookies und identische Abstände zwischen Anfragen. Die Rotation von IP-Adressen beseitigt die ersten beiden Signale, löst den Rest jedoch nicht, weshalb Rotation zwar notwendig, aber nicht ausreichend ist, ein Punkt, auf den wir zurückkommen.

Warum die Rotation pro Anfrage das richtige Modell für SERPs ist

Rotation bedeutet, die Ausgangs-IP zu wechseln, sodass aufeinanderfolgende Anfragen nicht alle von derselben Adresse stammen. Es gibt zwei Bereitstellungsmodelle, und der Unterschied ist für Google besonders wichtig.

Eine Sticky Session hält eine IP für eine Folge von Anfragen, was bei eingeloggten Abläufen sinnvoll ist, bei denen ein plötzlicher IP-Wechsel verdächtig wirkt. Die Rotation pro Anfrage tauscht die IP bei jedem Aufruf. Google Search hat kein Login und keine Session, die bewahrt werden müsste, also gibt es keinen Grund, eine IP zu behalten, aber viele Gründe, Anfragen über viele Adressen zu verteilen. Die Rotation pro Anfrage ist das Modell, das zu SERPs passt: Tausend Anfragen über tausend Adressen verteilt wirken jeweils wie ein einzelner neugieriger Nutzer statt wie eine Maschine. Für die Mechanik des Einbaus von Rotation in einen Scraper geht Wie man rotierende Proxys verwendet tiefer, und rotierende IP-Adresse behandelt das Konzept für sich.

Die Pool-Größe hinter der Rotation ist die andere Hälfte. Über zehn IPs bei hohem Volumen zu rotieren bremst diese zehn IPs nur langsamer aus. Ein großer Pool hält jede einzelne Adresse unter Googles Per-IP-Radar, weshalb Rotation und Pool-Größe eigentlich eine einzige Entscheidung sind.

Der IP-Typ entscheidet, ob Rotation überhaupt hilft

Rotation bringt nur etwas, wenn die rotierten IPs vertrauenswürdig sind. Tausend Rechenzentrums-IPs zu rotieren, und Google blockiert alle tausend am gleichen ASN-Signal, nur über mehr Anfragen verteilt. Die IP-Typ-Wahl ist die tragende Entscheidung beim SERP-Scraping.

Für Google Search lautet die praktische Antwort Residential: IPs, die Internetdienstanbieter echten Haushalten zugewiesen haben, sodass eine rotierte Anfrage wie ein gewöhnlicher Besucher und nicht wie ein Server wirkt. Rechenzentrums-IPs sind für tolerante Ziele geeignet, werden bei SERPs aber schnell markiert, und Mobil bietet mehr Vertrauen (und Kosten) als Suchergebnisse meist erfordern. Das vollständige Kosten-Nutzen-Verhältnis steht in Rechenzentrum vs. Residential Proxys, und der statisch-residential Mittelweg in ISP vs. Residential Proxys. Die hier genannten Zahlen beschreiben den typischen Fall; Ihre genaue Blockierungsrate variiert je nach Anfragevolumen, Region und Absicherung der jeweiligen Ergebnisseiten.

Proxy-Rotation in Python einrichten

Der sauberste Weg zu rotieren besteht darin, Ihren Client auf einen einzigen rotierenden Endpunkt zu richten und diesen die Ausgangs-IP pro Anfrage wechseln zu lassen, anstatt selbst eine rohe IP-Liste zu pflegen und zu überwachen. Für Ihren Code ist es einfach ein Proxy: ein Host, ein Port, Ihr Token als Anmeldeinformation. Crawlbase Smart AI Proxy funktioniert so, sodass die Integration nur wenige Zeilen umfasst.

Installieren Sie die einzige Abhängigkeit:

pip install requests

Leiten Sie dann Anfragen durch den rotierenden Endpunkt. Das Beispiel sucht mehrere Anfragen, variiert die Verzögerung zwischen ihnen und gibt aus, ob jede sauber zurückgekommen ist:

import requests
import random
import time
from urllib.parse import quote_plus

# One rotating endpoint swaps the exit IP per request.
proxy_url = "http://[email protected]:8012"
proxies = {"http": proxy_url, "https": proxy_url}

headers = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
}

queries = ["web scraping", "residential proxies", "serp api"]

for query in queries:
    url = "https://www.google.com/search?q=" + quote_plus(query)
    resp = requests.get(url, proxies=proxies, headers=headers, verify=False)
    print(query, resp.status_code, "blocked" if "/sorry/" in resp.url else "ok")

    # Vary timing so requests do not arrive on a fixed clock.
    time.sleep(random.uniform(2, 5))

Ersetzen Sie _USER_TOKEN_ durch das Token aus Ihrem Crawlbase-Konto. Beachten Sie, was der Code über die Rotation hinaus tut: Er sendet einen realistischen User-Agent, randomisiert die Pause zwischen Anfragen und prüft auf die /sorry/-Weiterleitung, die Google für Herausforderungsseiten verwendet. Diese Details sind der Unterschied zwischen einer Rotation, die funktioniert, und einer Rotation, die still Consent-Seiten zurückgibt, die dann fälschlicherweise als Ergebnisse geparst werden.

Best Practices, die die Rotation dauerhaft zum Laufen bringen

Einige Gewohnheiten halten einen rotierenden SERP-Scraper über die Zeit gesund, nicht nur in der ersten Stunde.

• Drosseln Sie pro IP, nicht nur insgesamt. Ein großer Pool ermöglicht hohen Gesamtdurchsatz, während keine einzelne Adresse mehr als ein Tröpfchen sieht. Der Pool absorbiert das Volumen; die Per-IP-Rate bleibt menschlich.
• Randomisieren Sie Timing und Header. Feste Verzögerungen und ein statischer User-Agent sind ein Fingerabdruck. Variieren Sie beides. Das Rotieren von User-Agents neben IPs wird in Wie man Websites scrapt, ohne gesperrt zu werden behandelt.
• Erkennen Sie Sperren, parsen Sie nicht durch sie hindurch. Achten Sie auf die /sorry/-Weiterleitung, CAPTCHA-Markup und leere Ergebnis-Container. Behandeln Sie diese als Fehler, die auf einer neuen IP wiederholt werden müssen, nicht als Daten.
• Verlangsamen Sie bei Herausforderungen. Wenn die Sperr-Raten steigen, verlangsamen Sie und vergrößern Sie den Pool, statt aggressiver vorzugehen. Aggression nach einer Markierung vertieft die Markierung.
• Verwenden Sie einen Browser nur, wenn die Seite ihn benötigt. Einfaches HTTP ist schneller und günstiger; reservieren Sie das Headless-Rendering für Ergebnistypen, die clientseitig laden. Web-Scraping mit Python und Selenium zeigt diesen Weg.

Wenn Ihr Ziel speziell Rankings und Keyword-Recherche ist, behandelt SEO-Proxys den Geo-Targeting-Aspekt, da sich SERPs nach Land unterscheiden und die Standort der Ausgangs-IP entscheidet, welche Ergebnisse Sie sehen.

Wann ein verwalteter SERP-Endpunkt besser ist als eine eigene Lösung

Alles oben Genannte ist umsetzbar, und bei niedrigem Volumen lohnt es sich, es selbst zu bauen. Die Kosten zeigen sich erst bei Skalierung. Alleine die Rotation lässt Ihnen den Rest des Kampfes: Pool-Gesundheit pflegen, TLS-Fingerabdrücke abgleichen, CAPTCHAs lösen oder umleiten, clientseitig rendernde Ergebnisseiten verarbeiten und bei jeder Herausforderung wiederholen. Das ist der Großteil eines SERP-Scraping-Stacks, und Rotation war nur die erste Schicht davon.

Ein verwalteter Endpunkt fasst diese Arbeit in einer einzigen Anfrage zusammen. Sie senden eine URL oder eine Anfrage; er wählt eine vertrauenswürdige Residential-IP, sendet einen glaubwürdigen Fingerabdruck, rendert wenn die Seite einen Browser benötigt, wiederholt serverseitig bei einer Sperre und gibt das fertige Ergebnis zurück. Die Crawling API ist genau dafür gebaut: Wo ein roher rotierender Proxy Ihnen eine saubere IP gibt und sich zurückzieht, übernimmt die API die Sperren und liefert den Erfolg. Der Kompromiss zwischen beiden wird in Backconnect Proxy vs. Crawling API dargelegt.

Häufig gestellte Fragen

Warum blockiert Google Scraper so schnell?

Google stimmt seine Missbrauchsabwehr darauf ab, alles zu erkennen, was kein Mensch beim Surfen ist. Eine einzelne IP, die viele Suchen pro Minute abfeuert, löst ein Per-IP-Rate-Limit aus, und Traffic aus einem bekannten Rechenzentrums-Bereich startet mit geringem Vertrauen vor der ersten Anfrage. Fügen Sie roboterhafte Header, keine Cookies und identisches Timing hinzu, ist das Ergebnis ein CAPTCHA oder eine /sorry/-Consent-Seite nach wenigen Dutzend Anfragen.

Wie viele Proxys benötige ich, um Google zuverlässig zu scrapen?

Genug, damit keine einzelne IP bei Ihrem Zielvolumen eine menschlich wirkende Anfragerate überschreitet. Es gibt keine feste Zahl: sie skaliert mit der Anzahl der Anfragen pro Minute. Über zehn IPs bei hohem Volumen zu rotieren bremst diese zehn IPs nur langsamer aus, daher hält ein großer rotierender Pool, keine Handvoll statischer Adressen, jede IP unter Googles Radar.

Welcher Proxy-Typ ist am besten für das Scraping von Google-Suchergebnissen?

Residential Proxys. Sie verlassen IPs, die ISPs echten Haushalten zugewiesen haben, sodass eine rotierte Anfrage wie ein gewöhnlicher Besucher und nicht wie ein Server wirkt. Rechenzentrums-IPs werden per ASN erkannt und bei SERPs schnell gesperrt, und Mobil bietet meist mehr Vertrauen (und Kosten) als Suchergebnisse erfordern. Starten Sie mit Residential und skalieren Sie nur hoch, wenn spezifische Ergebnisseiten Sie weiterhin herausfordern.

Sollte ich Sticky Sessions oder Rotation pro Anfrage für SERPs verwenden?

Rotation pro Anfrage. Sticky Sessions existieren, um eine Identität über einen eingeloggten Ablauf zu halten, und Google Search hat kein Login oder keine Session zu bewahren. Die Ausgangs-IP bei jeder Anfrage zu tauschen verteilt Ihre Anfragen über den Pool, sodass jede Adresse wie ein gelegentlicher Nutzer und nicht wie eine Maschine aussieht.

Reicht die Rotation von Proxys aus, um Google CAPTCHAs zu vermeiden?

Nicht allein. Rotation überwindet das Per-IP-Rate-Limit und die Rechenzentrum-ASN-Prüfung, ändert jedoch nichts an einem roboterhaften TLS-Fingerabdruck, fehlenden Cookies oder festem Anfrage-Timing. Eine saubere Residential-IP an einer offensichtlich automatisierten Anfrage zieht immer noch ein CAPTCHA an. Kombinieren Sie Rotation mit realistischen Headern, variierter Verzögerung und einem echten Browser-Fingerabdruck, wenn Seiten clientseitig rendern.

Wann ist ein SERP- oder Crawling-API besser als eine eigene Rotation?

Sobald das Volumen einige Tausend Anfragen übersteigt, oder wenn Ergebnisseiten clientseitig rendern. Rotation ist nur die erste Schicht; Sie besitzen weiterhin Pool-Gesundheit, Fingerabdrücke, CAPTCHA-Behandlung, Rendering und Wiederholungen. Ein verwalteter Endpunkt fasst all das in einer Anfrage zusammen: Sie senden eine Anfrage und erhalten ein gepartes Ergebnis, mit Rotation und Anti-Bot-Behandlung serverseitig.

HR

Hassan Rehan

Softwareentwickler · Crawlbase

Softwareentwickler bei Crawlbase, der praxisnahe Anleitungen zu rotierenden Proxys, Scraping und den praktischen Details schreibt, Proxys in echten Code einzubinden.