Web Scraping erkennen: Logs, IP-Abfragen und blinde Flecken

Eine einzelne Anfrage eines Scrapers ist nur ein GET. Sie hat einen Statuscode, einen Pfad und einen User-Agent, wie jede andere Zeile in Ihrem Log. Scraping zeigt sich erst über Hunderte von Zeilen und über ein ganzes Netzwerk hinweg: ein Python-Skript auf einem Cloud-Server, ein Headless-Browser, gesteuert von Puppeteer oder Playwright, ein KI-Trainings-Crawler, ein SEO-Crawler wie AhrefsBot oder eine Scraping-API, die rotierende Proxys pro Gigabyte verkauft.

Wir haben am 08.10.2026 sieben IPs aus Scraper-Klassen durch die GeoIPHub-API geschickt. Vier verifizierte Crawler (Googlebot, CCBot, ClaudeBot, AhrefsBot) kamen alle aus Hosting-Netzwerken und erhielten allow. Ein gewöhnlicher Linode-Cloud-Server erhielt 10, ebenfalls allow, und ein Tor-Exit sowie ein Mullvad-VPN-Server erhielten beide 100, block. Die IP liefert Ihnen das Netzwerk. Das Urteil über Scraping kommt aus Ihren Logs.

Im Folgenden zeigen wir, wie Sie Scraping-Bots in einem Access-Log erkennen, verfolgen eine Log-Zeile zurück, die sich als Googlebot ausgibt, zeigen, wo IP-Daten blind werden, und ordnen Ihre Befunde den Aktionen Zulassen, Rate Limiting, Challenge oder Sperren zu. Wenn Sie die IP-Signale zuerst einzeln kennenlernen möchten, behandelt unser Übersichtsartikel die Bot-Erkennung per IP, Signal für Signal; dieser Beitrag wendet sie auf Scraping an.

Web Scraping erkennen: Rate, Pfad, Client und Netzwerk

Um Web Scraping zu erkennen, prüfen Sie vier Gruppen von Signalen: wie schnell ein Client anfragt (Rate), was er in welcher Reihenfolge anfragt (Pfad), was er über sich selbst sagt (Client) und von wo er sich verbindet (Netzwerk). OWASP führt Scraping als eigene automatisierte Bedrohung, OAT-011, definiert als das Sammeln von „application content and/or other data for use elsewhere“ (Anwendungsinhalten und/oder anderen Daten zur Verwendung an anderer Stelle) (OWASP Automated Threats). Diese Definition bezieht sich auf die Absicht, und die können Sie nicht sehen. Die vier Gruppen sind das, was Sie sehen können.

• Rate. Anfragen pro Minute pro IP und pro Netzwerk. Mit Netzwerk meinen wir die ASN oder für eine feinere Gruppierung das /24 bei IPv4 und das /64 bei IPv6. Scraper laufen oft rund um die Uhr mit konstanter Rate; Menschen kommen in Schüben und schlafen.
• Pfad. Listen- und Paginierungs-URLs, die der Reihe nach abgearbeitet werden, eine Sitemap, die von oben nach unten gelesen wird, nur Produkt- oder Preisseiten und überhaupt keine CSS-, JavaScript- oder Bildanfragen.
• Client. Die Angabe im User-Agent, ein fehlender Accept-Language-Header, keine Cookies, die zwischen Anfragen erhalten bleiben, und Automatisierungsmerkmale. Im Browser ist navigator.webdriver true, wenn Chrome mit --headless oder --enable-automation läuft (MDN), wobei ein entschlossener Scraper das herauspatcht. Am Edge zeigt ein TLS-Fingerprint (JA3 oder JA4) oft eine HTTP-Bibliothek hinter einem User-Agent, der sich als Chrome ausgibt.
• Netzwerk. Was eine IP-Abfrage liefert: eine Rechenzentrums-IP (Hosting), die die API als detection.is_hosting markiert, ein verifizierter Crawler, Tor, ein VPN oder ein Scanner.

Das Schwierige an der Erkennung von Web Scraping ist, dass jedes Signal einen harmlosen Zwilling hat. Ein CDN, das Ihren Origin abruft, ein Uptime-Monitor, ein Büro hinter einer einzigen NAT-Adresse und ein RSS-Reader wirken alle auf einer Achse merkwürdig. Der Nachweis für Scraping ergibt sich aus Signalen, die übereinstimmen.

Erkennen, ob Ihre Website gescrapt wird: Lesen Sie zuerst Ihre Access-Logs

Um zu erkennen, ob Ihre Website gescrapt wird, gruppieren Sie Ihre Access-Logs nach Netzwerk und suchen Sie nach Clients, die viele Seiten abrufen, sie der Reihe nach abrufen und nie die Assets laden, die ein Browser laden würde. Die äußeren Anzeichen kommen meist zuerst: Ihre Produkttexte oder Preise tauchen auf einer anderen Website auf, oder Bandbreite und Serverkosten steigen auf Listenseiten, während die Conversions stagnieren. Um es von außen zu prüfen, suchen Sie nach einem markanten Satz Ihrer Seite in Anführungszeichen und achten Sie darauf, ob Ihre Preise innerhalb weniger Stunden nach einer Änderung auf Vergleichsportalen wieder auftauchen. Die Logs verraten Ihnen, wer es war.

So sieht das in einem Access-Log im Combined-Format aus. Dies sind illustrative Werte, kein echter Traffic. 45.33.32.156 ist der öffentliche Testhost von Nmap bei Linode und hat diese Anfragen nicht gesendet; er steht stellvertretend für „einen Cloud-Server“, weil wir die IP eines echten Besuchers nicht veröffentlichen dürfen.

Drei Dinge fallen auf. Die Seiten steigen eine nach der anderen, im Abstand von 1 bis 2 Sekunden, um 3 Uhr morgens. Es gibt keinen Referrer und keine einzige .css- oder .js-Anfrage dazwischen. Und der Client nennt sich Googlebot, was die nächsten Abschnitte überprüfen.

Sie brauchen keine Log-Plattform, um solche Clients zu finden. Diese Einzeiler funktionieren mit einem Standard-Combined-Log; führen Sie sie zuerst über eine geschäftige Stunde aus:

Arbeiten Sie die Ausgabe mit dieser Liste durch:

• Aufgerufene Seiten. Konzentrieren sich die aktiven Clients auf Listen, Preise, Suchergebnisse oder die Sitemap?
• Rate pro IP, dann pro Netzwerk. Nachdem Sie die IPs angereichert haben, summieren Sie die Anfragen pro ASN; 50 Hosting-Adressen in einer ASN, die dieselben Seiten abarbeiten, sind wahrscheinlich ein einziger Akteur.
• Sitzungstiefe. Hunderte Seiten pro Sitzung, ohne Nutzung von Warenkorb, Login oder Suchfeld.
• Reihenfolge. Paginierungs- oder Sitemap-URLs, die der Reihe nach abgerufen werden.
• Assets. Nur HTML, kein CSS, JavaScript, keine Schriften oder Bilder.
• Crawler-Angaben. Jeder User-Agent von Googlebot, Bingbot, GPTBot oder ClaudeBot kommt auf eine Liste zur Verifizierung per IP.
• Automatisierungsmerkmale. User-Agents von Bibliotheken (python-requests, curl, Go-http-client) und Hinweise auf Headless-Browser.

Scraper-IP-Adressen: was echte GeoIPHub-Abfragen liefern

Scraper-IP-Adressen fallen in einige wenige Netzwerkklassen, und eine Abfrage verrät Ihnen, welche Klasse Sie vor sich haben, nicht, ob die Anfrage von einem Scraper kam. In unseren GeoIPHub-Abfragen erhielten verifizierte Crawler Scores von 0 bis 23 (allow); Tor- und VPN-Exits erhielten 100 (block). Wir haben am 08.10.2026 eine anonyme Abfrage pro Klasse ausgeführt, im Abstand von vier Sekunden:

Dies sind einzelne Abfragen an einem Tag, kein Benchmark, und die Werte ändern sich, wenn sich Bereiche ändern. Eine bekannte Lücke: no_ptr_datacenter in den Zeilen von Googlebot und AhrefsBot liegt an unseren Daten, nicht an ihren. Die API speichert für einige Crawler-Bereiche keinen PTR-Eintrag, obwohl das Reverse DNS auflöst (192.178.4.40 löst zu crawl-192-178-4-40.googlebot.com auf). Bei der IP von ClaudeBot ist das Signal korrekt: Sie hat kein Reverse DNS.

Hier ist die Antwort für CCBot, gekürzt, aber mit echten Werten und der ursprünglichen Verschachtelung:

Der eigene Crawler von Common Crawl läuft auf AWS und erhält trotzdem 0. Die IP liegt in 18.97.14.80/29, einem Bereich, den Common Crawl in seiner Datei ccbot.json veröffentlicht, und die Anpassung für verifizierte Crawler in unserem Scoring (−28,5) hebt das Rechenzentrumssignal auf. GeoIPHub prüft auf diese Weise 19 offizielle Feeds mit Crawler-Bereichen, darunter die von Google, Bing, OpenAI, Anthropic, Common Crawl und Ahrefs. Ob Sie einen Crawler, dessen Daten in KI-Modelle wie bei CCBot oder GPTBot einfließen, Ihre Seiten lesen lassen wollen, ist eine Frage Ihrer Richtlinie. Die Abfrage klärt nur, wer es ist.

AhrefsBot war die Überraschung. Er kam als verifiziert zurück (5.39.1.230 liegt in 5.39.1.224/27 in den veröffentlichten Crawler-Bereichen von Ahrefs), aber auch mit is_abusive: true und abusive_listed in den Methoden, was einen Score von 23 ergab, weiterhin allow. Wir haben nicht nachverfolgt, welche Liste ihn markiert hat. Die Lehre gilt so oder so: „Verifiziert“ sagt Ihnen, wer ein Crawler ist, nicht, ob Sie ihn haben wollen. Ein SEO-Crawler, der Ihre Website für den Backlink-Bericht eines Wettbewerbers kartiert, betreibt trotzdem Scraping, nur eben deklariert.

Crawler-Imitation in Scraping-Logs: eine Zeile, zurückverfolgt

Eine Anfrage, die im User-Agent Googlebot angibt, aber von einem Cloud-Server kommt, ist eine nicht verifizierte Behauptung. GeoIPHub kann Ihnen sagen, dass die IP in keinem Google-Bereich liegt, aber der Abgleich mit dem User-Agent geschieht in Ihrem Code, denn die Abfrage sieht Ihre Header nie. Nehmen Sie die vierte Zeile des illustrativen Logs: 45.33.32.156, GET /products?page=37, User-Agent Googlebot/2.1.

1. Fragen Sie die IP ab. Die echte Abfrage lieferte ASN 63949, Akamai Connected Cloud (Linode), detection.is_hosting: true, threat.crawler.name: "none", verified: false, fraud_score 10, allow, mit den Methoden ["datacenter_ip"].
2. Vergleichen Sie die Behauptung. Ihr Code prüft das User-Agent-Token gegen threat.crawler.verified und threat.crawler.name.
3. Entscheiden Sie. Der UA sagt Googlebot; die IP liegt in keinem Google-Bereich. Damit ist sie „nicht als Googlebot verifiziert“. Setzen Sie ein Rate Limit oder eine Challenge. Eine Challenge (ein CAPTCHA oder eine JavaScript-Prüfung) ist die Art, wie Sie die API-Aktion step_up umsetzen. Nennen Sie es nicht gefälscht: Ein neuer Google-Bereich kann in unseren Daten bis zu etwa zwei Tage brauchen, bis er verifiziert ist, weil die Bereichsdateien täglich abgerufen und die Abfragedatenbank täglich neu aufgebaut wird.
4. Prüfen Sie den Gegensatz. Der echte Googlebot unter 192.178.4.40 lieferte verified: true, name: "Googlebot", verification_method: "ip_range_list", Score 0.

Google dokumentiert zwei Wege, dieselbe Prüfung selbst durchzuführen: Reverse DNS auf die IP, gefolgt von einer Forward-Abfrage des Hostnamens, oder ein Abgleich mit den veröffentlichten Bereichsdateien wie common-crawlers.json (Google Search Central). Der Abgleich im Code sieht so aus:

Das ist der Fall, in dem der Score allow sagt und das Muster Scraper. Allein anhand der IP liegt diese Anfrage bei 10 und allow, denn ein Cloud-Server ist für sich genommen ein schwaches Signal. Das Urteil über Scraping ergibt sich aus drei Dingen, die der Score nicht sehen kann: der UA-Abweichung, der gleichmäßigen Rate und dem Abarbeiten Seite für Seite. Das vollständige Verfahren für Google finden Sie unter Googlebot per Reverse DNS und Googles Bereichsdateien verifizieren; für GPTBot, ClaudeBot und signierte Agenten unter KI-Crawler per IP, Reverse DNS und Web Bot Auth verifizieren.

Was IP-Daten übersehen: Residential Proxys und echte Browser

IP-Daten übersehen Scraper, die über Residential oder Mobile Proxys laufen, und GeoIPHub erkennt keine Residential Proxys; das Feld is_residential_proxy ist eine grobe, ASN-basierte Schlussfolgerung, behandeln Sie es also als kein Signal. Ein Residential-Proxy-Netzwerk leitet jede Anfrage über den Heimanschluss einer Person. Auf IP-Ebene sieht die Anfrage aus wie dieser Haushalt: ein Endkunden-ISP, eine echte Stadt, kein Hosting-Flag, ein sauberer Score.

Rotation macht es schlimmer. Ein Pool kann jeder Anfrage eine neue private IP geben, sodass Zähler pro IP nie ansteigen. Mobile Proxys teilen sich Carrier-IPs mit echten Smartphones, und ein IPv6-Scraper kann ein ganzes /64 durchlaufen, ohne ein neues Netzwerk zu berühren.

Echte Browser sind der zweite blinde Fleck. Ein Playwright-Skript, das Chrome über einen Büro- oder Heimanschluss steuert, sendet dieselbe IP, denselben TLS-Handshake und dieselben Assets wie die Person am Nachbartisch. Manche Headless-Setups geben sich selbst zu erkennen; gut abgestimmte tun das nicht.

Was diese Scraper trotzdem verrät, ist das Muster über die Anfragen hinweg:

Wenn Sie einen versteckten Link setzen, sperren Sie seinen Pfad in robots.txt, damit Crawler, die sich an die Datei halten, ihn nie berühren. Zwei Beiträge gehen tiefer auf die Ebenen ein, die neben der IP stehen. Lesen Sie, warum Device Fingerprinting und IP-Intelligence zusammen am besten funktionieren und was eine Abfrage bei der Erkennung von Betrug über Residential Proxys zeigen kann und was nicht.

Scraping vs. Crawling vs. API-Missbrauch

Crawling ist deklariert und verifizierbar, Scraping nimmt Ihre Inhalte oder Daten und ist oft nicht deklariert, und API-Missbrauch sind skriptgesteuerte Aufrufe Ihrer Endpunkte über Ihre Bedingungen oder Limits hinaus. Die Grenze zwischen ihnen ist Verhalten und Identität, nicht Technologie: Googlebot und ein Preis-Scraper können dieselbe HTTP-Bibliothek in derselben Cloud nutzen.

Ein verifizierter Crawler kann trotzdem scrapen, wie AhrefsBot zeigt, und ein Scraper kann trotzdem wie ein Crawler aussehen. Deshalb beginnt der nächste Abschnitt damit, nur die verifizierten zuzulassen.

Web Scraping verhindern, ohne Suchmaschinen-Crawler zu blockieren

Um Web Scraping zu verhindern, ohne Suchmaschinen-Crawler zu blockieren, lassen Sie zuerst verifizierte Crawler zu, setzen Sie dann Rate Limits pro Netzwerk, fordern Sie Clients heraus, die sich nicht wie Browser verhalten, und sperren Sie nur, was Sie bestätigt haben. Die Score-Bereiche von GeoIPHub liefern dafür die IP-Seite: allow bis 25, review bis 50, step_up bis 75 und block über 75. Die Reihenfolge ist wichtig. Eine pauschale Rechenzentrumssperre, die zuerst greift, hätte in unserer Tabelle Googlebot, CCBot, ClaudeBot und AhrefsBot getroffen, da alle vier aus Hosting-Netzwerken kamen.

1. Lassen Sie verifizierte Crawler zu, wenn threat.crawler.verified true ist und crawler.name zum User-Agent-Token passt. Wenden Sie dann Ihre eigene Richtlinie pro Crawler an. Für KI-Crawler zeigt unser Vergleich von GPTBot, OAI-SearchBot und ChatGPT-User, wie Sie das Training blockieren, ohne die KI-Suche zu verlassen.
2. Verwenden Sie die IP-Regeln wieder. Score-Bereiche, der Umgang mit Tor und Rate Limits pro Präfix funktionieren für Scraper genauso wie für jeden anderen Bot; der Übersichtsartikel behandelt sie. Behandeln Sie eine Rechenzentrums-IP als gewichteten Faktor, nicht als Sperrgrund, da Hosting auch KI-Agenten, Unternehmens-Proxys und Ihre eigenen Tools umfasst (siehe was eine Rechenzentrums-IP-Adresse ist).
3. Setzen Sie Rate Limits pro ASN auf den Seiten, die Scraper wollen. Ein Pool, der durch einen einzigen Hosting-Anbieter rotiert, bleibt unter jedem Limit pro IP, aber ein Zähler pro ASN auf Listen-, Such- und Preisseiten summiert ihn auf. Geben Sie großen Clouds eine höhere Obergrenze, da sich viele voneinander unabhängige Kunden eine ASN teilen.
4. Begrenzen Sie die Paginierung und legen Sie vollständige Listen hinter einen Login. Liefern Sie anonymen Besuchern eine feste Anzahl von Listenseiten aus. Eine Kontoschranke macht aus jedem Scraper Konten, die Sie zählen und schließen können.
5. Setzen Sie Kontingente pro Schlüssel für die JSON-Endpunkte, die Ihre Seiten aufrufen. Scraper überspringen oft das HTML und rufen die API dahinter auf, vergeben Sie daher Schlüssel oder Session-Tokens und begrenzen Sie die Aufrufe pro Schlüssel.
6. Fügen Sie eine Bot-Management- oder WAF-Ebene hinzu für die Client-Signale, die Ihre Logs nicht enthalten, etwa TLS-Fingerprints und JavaScript-Prüfungen am Edge.
7. Verwenden Sie Verhaltensregeln für Traffic aus Privatkundennetzen, bei dem die IP Ihnen nichts liefert.

Die Reaktionen bilden eine Leiter: zulassen, Rate Limit, Challenge, sperren. Manche Websites setzen zusätzlich ein Tarpit ein, das die Antworten an einen mutmaßlichen Scraper verlangsamt, oder liefern Köderinhalte wie veränderte Preise an Traffic aus, den sie bereits klassifiziert haben. Beides kostet Sie etwas, wenn die Klassifizierung falsch ist, setzen Sie es also nur bei Traffic ein, den Sie ohnehin sperren würden.

Für die reinen IP-Zeilen (Tor, Relays, Scanner, IPv6-Präfixe) verwenden Sie die Aktionsübersicht in unserem Leitfaden zur Bot-Erkennung per IP.

Und robots.txt? Es bittet, es erzwingt nicht. RFC 9309, der Standard für den Robots-Ausschluss, sagt, seine Regeln „are not a form of access authorization“ (sind keine Form der Zugriffsautorisierung) (RFC 9309). Behalten Sie es für die Crawler, die sich daran halten, und setzen Sie alles andere auf Ihrem Server durch. Unser Leitfaden zum Blockieren von KI-Crawlern zeigt diese Durchsetzungsebene mit Code für nginx und Express.

Beginnen Sie mit den Logs von gestern. Exportieren Sie die 50 aktivsten Clients, die keine Assets geladen haben, fügen Sie jeden in das kostenlose IP-Lookup ein (30 Abfragen pro Minute ohne Schlüssel, 1.500 pro Tag mit einem kostenlosen) und ordnen Sie sie den Klassen aus der Abfragetabelle oben zu. Die übrig gebliebenen, aktiv und in Endkundennetzen, sind die Stelle, an der Ihre Verhaltensregeln als Nächstes ansetzen.

Häufig gestellte Fragen

Wie blockiere ich KI-Scraper wie GPTBot oder CCBot?

Beginnen Sie mit robots.txt: GPTBot und CCBot halten sich beide daran, daher stoppt eine Disallow-Regel für ihre Tokens die deklarierten Crawler. robots.txt ist eine Bitte, keine Zugriffskontrolle (RFC 9309 stellt klar, dass seine Regeln keine Form der Zugriffsautorisierung sind), setzen Sie deshalb auch auf Ihrem Server durch: Verifizieren Sie jeden Crawler anhand seiner veröffentlichten IP-Bereiche und behandeln Sie einen Client, der den Namen von außerhalb dieser Bereiche verwendet, als nicht verifiziert. OpenAI betreibt mehrere Bots mit unterschiedlichen Aufgaben; unser Beitrag GPTBot vs. OAI-SearchBot vs. ChatGPT-User erklärt, welchen Sie blockieren sollten, wenn Sie in der ChatGPT-Suche bleiben wollen.

Ab wie vielen Anfragen pro Minute handelt es sich um Scraping?

Es gibt keine allgemeingültige Zahl. Messen Sie an einem normalen Tag Ihren eigenen menschlichen Ausgangswert, pro /24 bei IPv4 und pro /64 bei IPv6, und sehen Sie sich dann Netzwerke an, die weit darüber liegen. Die Rate allein markiert auch Büro-NAT, CGNAT und Monitoring-Dienste. Werten Sie eine hohe Rate daher nur dann als Scraping, wenn die Seiten in Reihenfolge abgerufen und keine Assets angefordert werden.

Kann man Web Scraping vollständig stoppen?

Nein. Alles, was ein Browser darstellen kann, kann ein entschlossener Scraper kopieren, auch über Residential Proxys und echte Browser. Das Ziel ist, Scraping langsam, teuer und sichtbar zu machen: Crawler verifizieren, Rate Limits pro Netzwerk setzen, Clients herausfordern, die sich nicht wie Browser verhalten, und wertvolle Daten hinter einen Login oder API-Schlüssel legen.

Stoppt das Blockieren von Rechenzentrums-IPs das Scraping?

Teilweise. Es stoppt Scraper, die auf günstigen Cloud-Servern laufen, blockiert aber auch verifizierte Crawler, sofern Sie diese nicht vorher zulassen: In unseren Abfragen vom 08.10.2026 erhielten CCBot auf AWS und der echte Googlebot jeweils einen Score von 0 (allow), beide aus Hosting-Netzwerken. Ein gewöhnlicher Linode-Server erhielt 10, ebenfalls allow, der Score allein blockiert ihn also nicht. Scraper, die Residential Proxys mieten, kommen an einer Rechenzentrumssperre vollständig vorbei.

Kann mir eine IP-Abfrage sagen, dass eine IP ein Scraper ist?

Nein. Eine Abfrage verrät Ihnen die Netzwerkklasse und das Risiko: ein verifizierter Crawler, ein Rechenzentrumsserver, ein Tor-Exit oder ein VPN. Ob diese IP Sie scrapt, ergibt sich aus Ihren Logs: aus ihrer Anfragerate, der Reihenfolge der abgerufenen Seiten, ob sie Assets lädt und ob ihr User-Agent zu dem Crawler passt, den die Abfrage verifiziert.

Wie erkenne ich, ob ein Scraper Residential Proxys nutzt?

An der IP können Sie es nicht erkennen, und GeoIPHub erkennt keine Residential Proxys. Achten Sie auf viele Endkunden-IPs, die ein gemeinsames Sitzungsmuster teilen: dieselbe Seitenreihenfolge, dasselbe Timing zwischen den Anfragen, dieselben fehlenden Assets und ähnliche TLS- oder Geräte-Fingerprints. Das Muster über viele Adressen hinweg verrät den Scraper, nicht eine einzelne Adresse.