KI-Crawler und KI-Agenten per IP verifizieren: Reverse DNS, CIDR-Bereiche und Web Bot Auth

Sie sehen GPTBot, ClaudeBot oder PerplexityBot in Ihren Logs und müssen entscheiden: zulassen, ratenbegrenzen oder sperren. Doch vorher müssen Sie eine grundlegendere Frage beantworten: Ist es tatsächlich dieser Bot? Denn ein User-Agent-Header ist eine Behauptung, kein Beweis. Jeder kann curl -A "GPTBot/1.3" https://your-site.com ausführen, und Ihre Logs halten pflichtbewusst „GPTBot“ fest.

Das ist keine Theorie. Das Satori-Team von HUMAN Security stellte fest, dass 5,7 % des gesamten Datenverkehrs, der sich als bekannter KI-Crawler ausgab, gefälscht waren, mit Spitzen von 7,7 % an manchen Tagen (~2 Millionen Anfragen pro Tag), wobei der Agent ChatGPT-User in etwa einer von sechs Anfragen imitiert wurde. Dieser Leitfaden behandelt die drei echten Wege, einen Crawler auf IP- und Kryptoebene zu verifizieren (Forward-Confirmed Reverse DNS, vom Betreiber veröffentlichte CIDR-Allowlists und Web Bot Auth), dazu die Fehlerfälle, über die fast jeder andere Leitfaden stolpert.

Warum ein User-Agent „GPTBot“ nichts beweist

Der User-Agent sind selbst gemeldete Metadaten. Darin steckt keine Authentifizierung, nichts ist signiert, nichts kann ein Ursprungsserver prüfen. Einen Crawler zu verifizieren heißt, die Anfrage an Infrastruktur oder einen Schlüssel zu binden, den der Betreiber tatsächlich kontrolliert. Genau drei Verfahren leisten das:

1. Forward-Confirmed Reverse DNS (FCrDNS): nachweisen, dass die IP auf die Domain des Betreibers und von ihr zurück auflöst.
2. Veröffentlichte CIDR-Allowlists: die IP mit Bereichen abgleichen, die der Betreiber veröffentlicht.
3. Web Bot Auth (RFC 9421): eine kryptografische Signatur auf der Anfrage selbst verifizieren.

Alles Folgende dreht sich darum, diese Verfahren korrekt umzusetzen und zu wissen, was jedes davon beweisen kann und was nicht.

Was 2026 auf dem Spiel steht: Bots sind die Mehrheit im Web

Die Verifizierung von Crawlern war in dem Moment keine SEO-Nische mehr, als automatisierter Datenverkehr den Großteil des Internets ausmachte. Impervas Bad Bot Report 2026 stellte fest, dass automatisierter Datenverkehr 53 % des 2025 beobachteten Web-Datenverkehrs ausmachte und bösartige Bots allein 40 %. Wenn die meisten Anfragen automatisiert sind und KI-Crawler weiter an Volumen zulegen, wird „Ist dieser Bot echt?“ zu einer Frage an Ihren Login-, Registrierungs- und Checkout-Endpunkten, nicht nur in Ihrer robots.txt. Im Checkout ist es inzwischen auch eine Betrugsfrage: Siehe wie Sie Betrug durch KI-Shopping-Agenten stoppen, ohne echte Agenten-Verkäufe zu blockieren. Welches IP-Signal welche Bot-Frage beantwortet, von Crawler-Bereichen bis zu Scanner-Flags, zeigt unser Überblick zur Bot-Erkennung per IP.

Methode 1: Forward-Confirmed Reverse DNS, richtig gemacht

FCrDNS ist das kanonische Verfahren, das Google zur Verifizierung von Googlebot dokumentiert. Vier Schritte:

Warum der Forward-Schritt tragend ist: Ein Angreifer kontrolliert den Reverse-Eintrag (PTR) für seine eigene IP, er kann 1.2.3.4 also auf crawl-fake.googlebot.com zeigen lassen. Was er nicht kann: das autoritative Forward DNS von googlebot.com fälschen, damit dieser Hostname wieder auf 1.2.3.4 auflöst. Eine Prüfung, die nur den PTR-Eintrag per String-Vergleich auf „googlebot.com“ abklopft (was erstaunlich viele Tutorials vorschlagen), ist selbst fälschbar. Die Forward-Bestätigung ist der eigentliche Zweck. Speziell für Google mit seinen drei Crawler-Typen und deren getrennten Bereichsdateien siehe unseren Leitfaden zum Verifizieren von Googlebot per IP und Erkennen gefälschter Googlebots.

Die Genauigkeitsgrenze, auf die Sie achten müssen: PTR-Einträge sind optional und fehlen häufig, besonders bei den neueren KI-Anbietern. Wenn es keinen PTR gibt, liefert FCrDNS „nicht verifizierbar“, was weder bestanden noch durchgefallen ist. Hier kommt Methode 2 ins Spiel.

Methode 2: Veröffentlichte CIDR-Allowlists, pro Bot

Die meisten KI-Anbieter verzichten auf PTR-Einträge und veröffentlichen stattdessen die IP-Bereiche ihrer Crawler als JSON. Das ist die im Betrieb praktikabelste Prüfung. Laden Sie den Primärquellen-Feed jedes Betreibers:

• OpenAI: Dateien pro Bot: openai.com/gptbot.json, openai.com/searchbot.json, openai.com/chatgpt-user.json (Crawler-Dokumentation von OpenAI).
• Google: fünf CIDR-Dateien unter developers.google.com/static/crawling/ipranges/.
• Anthropic: veröffentlicht eine Datei für seine Bots, claude.com/crawling/bots.json, verlinkt von seiner Hilfeseite zu Crawlern. Die Adressliste in der Plattform-Dokumentation gilt für die API, nicht für Crawler.
• Perplexity: perplexitybot.json und perplexity-user.json.
• Apple iCloud Private Relay: eine Egress-CSV unter mask-api.icloud.com/egress-ip-ranges.csv (Dokumentation von Apple). Hinweis: Das sind Menschen hinter einem Datenschutz-Relay, keine Bots. Setzen Sie sie auf die Allowlist; sperren Sie sie nicht.

Wir laden 19 Crawler-Bereichsdateien von 10 Betreibern; die Liste verifizierter Crawler-IPs enthält jede einzelne, mit Datum und einer Anleitung, wie Sie die Allowlist aufbauen.

Drei Regeln trennen eine korrekte Umsetzung von einer kaputten:

• Ordnen Sie jeden Bot den Dateien seines Betreibers zu, und nur dort seiner eigenen Datei, wo der Betreiber eine pro Bot veröffentlicht. GPTBot gehört in gptbot.json, nicht in „irgendeinen OpenAI-Bereich“, und wer die falsche OpenAI-Datei abgleicht, verwechselt einen Trainings-Crawler mit einem nutzerinitiierten Fetcher. Anthropic veröffentlicht eine gemeinsame Datei für alle drei seiner Bots, und die beiden Dateien von DuckDuckGo sind identisch; dort ist der Betreiber also die präziseste verfügbare Zuordnung. Unser Vergleich GPTBot vs. OAI-SearchBot vs. ChatGPT-User zeigt, was jeder OpenAI-Bot tut, was eine Sperre kostet, und eine echte Abfrage aus jeder Datei.
• Gleichen Sie das exakt veröffentlichte Präfix ab, niemals die Hosting-ASN. Wer „ganz AWS“ oder „ganz Google Cloud“ auf die Allowlist setzt, weil ein Bot zufällig dort läuft, winkt jeden Angreifer in derselben Cloud durch.
• Aktualisieren Sie regelmäßig. Diese Bereiche ändern sich; behandeln Sie sie als Feed, nicht als Konstante.

Unterschiede zwischen Anbietern: welche Methode überhaupt existiert

Die meisten Leitfäden werfen die Anbieter in einen Topf. Sie unterscheiden sich aber, sowohl darin, welche Verifizierungsmethode existiert, als auch in den Crawler-Tokens, die jeder ausliefert und die unterschiedliche Folgen für Ihre Richtlinien haben:

Die Feinheit, an der naive Pipelines scheitern: Nutzergesteuerte Fetcher verhalten sich wie echte Besucher und können legitimerweise von außerhalb der veröffentlichten Bot-Bereiche kommen. Wenn ein Nutzer einen Assistenten bittet, eine bestimmte URL zu öffnen, kann dieser Abruf aus allgemeiner Cloud-Infrastruktur mit einem normalen Browser-User-Agent kommen. Eine Sperre nach „nicht im GPTBot-Bereich“ kann also die Agenten-Aktion eines echten Nutzers blockieren. Richtlinien für Ratenbegrenzung und Sperren müssen sich pro Token unterscheiden, nicht pro Anbieter.

SEO- und Analyse-Crawler verifizieren: AhrefsBot und Co.

Dieselben beiden Methoden auf IP-Ebene verifizieren auch die SEO- und Analyse-Crawler, die man in den eigenen Logs am häufigsten eindeutig zuordnen möchte: AhrefsBot und vergleichbare wie SemrushBot und DataForSeoBot. Das sind keine KI-Crawler, die Verifizierung ist aber identisch:

• AhrefsBot lässt sich per Forward-Confirmed Reverse DNS verifizieren (seine Adressen lösen zu Hostnamen unter den eigenen Domains von Ahrefs auf), und Ahrefs veröffentlicht die IP-Bereiche seines Crawlers für Allowlists. Führen Sie dieselbe FCrDNS-Prüfung aus Methode 1 aus oder gleichen Sie mit der veröffentlichten Liste aus Methode 2 ab.
• Die Falle ist dieselbe, in die auch KI-Crawler tappen lassen: Setzen Sie nicht nach ASN auf die Allowlist. Ein „AhrefsBot“, der aus einem beliebigen, nie verifizierten Hosting-Bereich kommt, ist genau das Spoofing-Muster, denn jeder kann User-Agent: AhrefsBot/7.0 senden. Bestätigen Sie die IP, nicht den String.

Wenn Sie nach „AhrefsBot IP-Adressen“ suchen, um eine Firewall-Regel zu bauen, ist die dauerhafte Variante eine Forward-Confirmed-Reverse-DNS-Prüfung plus der veröffentlichte Bereich des Betreibers, regelmäßig aktualisiert, und keine fest kodierte IP-Liste, die beim ersten Kapazitätsausbau des Crawlers veraltet.

Methode 3: Web Bot Auth und kryptografische Verifizierung

Die strukturelle Lösung gegen Spoofing besteht darin, nicht mehr der Netzwerkposition zu vertrauen, sondern stattdessen eine Signatur zu verifizieren. Bei Web Bot Auth signiert der Agent jede Anfrage mit einem Ed25519-Schlüssel nach RFC 9421 HTTP Message Signatures (ein Proposed Standard, Februar 2024). Die Anfrage enthält:

• Signature: den Signaturwert
• Signature-Input: die abgedeckten Komponenten, created/expires, keyid und tag="web-bot-auth"
• Signature-Agent: optional, benennt den signierenden Agenten

Schlüssel werden als JWKS unter /.well-known/http-message-signatures-directory gefunden (aufbauend auf dem Well-known-URI-Mechanismus aus RFC 8615). Verifizierung: Laden Sie das Verzeichnis, gleichen Sie den keyid-Fingerabdruck ab, verifizieren Sie die Signatur und das Zeitfenster created/expires. Der Vorteil gegenüber IP-Methoden ist entscheidend: Das Verfahren hält auf geteilten, wechselnden und CGNAT-Adressen stand, weil die Identität mit der Anfrage reist und nicht mit der Route.

Realitätscheck: experimentell, kein Standard

Seien Sie bei Ihrer Architektur hier ehrlich. Web Bot Auth ist in IETF Internet-Drafts spezifiziert (draft-meunier-web-bot-auth-architecture, 2. März 2026, Autoren von Cloudflare und Google), die den Standardhinweis tragen, sie seien „nicht von der IETF gebilligt und ohne formellen Status“, und die am 3. September 2026 ablaufen. Googles eigene Unterstützung ist ausdrücklich experimentell. Google signiert „noch nicht jede Anfrage“ und rät Betreibern, weiterhin IP-, Reverse-DNS- und User-Agent-Verifizierung zu nutzen. Auf Infrastrukturebene ist das Verfahren weiter: Cloudflare hat Message Signatures in sein Verified Bots Program aufgenommen (Juli 2025), und AWS WAF hat Unterstützung ergänzt (November 2025). Fazit: Bevorzugen Sie Signaturen, wo sie vorhanden sind, verlassen Sie sich aber noch nicht darauf.

Die mehrstufige Entscheidungs-Pipeline (zum Übernehmen)

Kombinieren Sie die drei Methoden in einer Rangfolge, reichern Sie dann an und klassifizieren Sie. Sobald ein Bot verifiziert ist, entscheiden Sie, was mit jedem verifizierten KI-Crawler geschieht, mit der dreistufigen Richtlinie aus diesem Leitfaden:

In Schritt 5 kommt GeoIPHub ins Spiel: Wenn die IP eines Bots, der sich selbst ausweist, in keinem veröffentlichten Bereich liegt und keinen PTR hat, sind ASN-Eigentümer, Rechenzentrums-/Hosting-Flag, VPN-, Proxy- und Tor-Flags sowie ein Risikoscore das, womit Sie die nicht eindeutigen Fälle bei Login, Registrierung und Checkout bewerten können, statt zu raten. Wenn Sie die Gruppe der deklarierten, aber nicht verifizierten Bots ratenbegrenzen, schlüsseln Sie IPv6-Quellen nach dem Präfix statt nach der Adresse; unser Leitfaden zum Ratenbegrenzen und Sperren von IPv6 per /64-Präfix erklärt, warum.

Dieselbe Google-ASN, ein verifizierter Googlebot und einer nicht

Zwei Adressen im selben Google-Netzwerk erhalten gegensätzliche Crawler-Urteile, weil die Prüfung das veröffentlichte Präfix verwendet und nicht die ASN. Wir haben am 5. Oktober 2026 zwei Google-IPs abgefragt (die Ergebnisse ändern sich, wenn sich Bereiche verschieben): 192.178.4.0, die erste Adresse des ersten IPv4-Präfixes in Googles veröffentlichter Googlebot-Bereichsdatei, und 8.8.8.8, Google Public DNS.

Beide liegen in AS15169 und beide sind Hosting, eine ASN-Allowlist würde sie also gleich behandeln. Nur die erste liegt in der Googlebot-Datei, und threat.crawler.verification_method: "ip_range_list" zeigt, dass das Urteil aus Methode 2 stammt. Das Signal verified_crawler zieht ihren fraud_score auf 0, während 8.8.8.8 den einfachen Rechenzentrums-Score von 15 behält. Die Methode no_ptr_datacenter schlägt bei beiden an, weil unser Eintrag für sie keinen PTR enthält, und doch liefert ein Live-dig -x 192.178.4.0 den Namen crawl-192-178-4-0.googlebot.com. Das ist ein kleines, echtes Beispiel dafür, warum die Bereichsprüfung diejenige ist, die man automatisieren sollte: Sie hängt nicht davon ab, dass eine PTR-Abfrage gelingt.

Fehlerfälle und Fehlalarme

Das ist es, was die gut rankenden Artikel falsch machen:

• Außerhalb des Bereichs ≠ gefälscht. Der Fall Perplexity (Cloudflare, August 2025) zeigte einen Crawler mit generischem Chrome-UA, IPs außerhalb seines veröffentlichten Bereichs und wechselnden ASNs bei 3 bis 6 Mio. Anfragen pro Tag. Im Bereich ist ein echter Treffer; außerhalb des Bereichs ist nicht eindeutig und kein Beweis für eine Fälschung.
• Geografische Verzerrung durch CGNAT. Eine Cloudflare-Studie von Ende 2025 (via The Register) ergab, dass CGNAT-IPs ~3-mal häufiger ratenbegrenzt wurden, obwohl sie weniger Bot-Signale zeigten. Hunderte Nutzer teilen sich eine IPv4, konzentriert in Afrika und Asien. Naives Sperren nach IP ist ein Fairnessproblem.
• iCloud Private Relay. Geteilte, wechselnde Egress-IPs, die echte Menschen tragen; setzen Sie sie über Apples CSV auf die Allowlist.
• Residential Proxys. Sie hebeln ASN-Allowlists vollständig aus (Imperva stellte in seinem Bericht 2025 fest, dass 21 % der Bot-Angriffe sie nutzten), und genau deshalb ist das Erkennen anonymisierten Datenverkehrs, ohne echte Kunden zu blockieren, ein Verhaltensproblem und keine Listenabfrage.

Die Regel: Reservieren Sie harte Sperren für Verhalten plus Herkunft, niemals für das bloße Fehlen auf einer Liste.

Verifizierte Bots sind GIVT, gefälschte sind SIVT

In der Taxonomie des Media Rating Council gelten deklarierte Crawler und bekannte Rechenzentrums-IPs als General Invalid Traffic, der sich über Listen filtern lässt, während Bots, die sich „als legitime Nutzer tarnen“, Sophisticated Invalid Traffic sind, der Analyse und Prüfung erfordert. Einen Crawler per IP zu verifizieren ist genau das, was eine Anfrage aus der zweiten Kategorie in die erste verschiebt. Die vollständigen Kategorielisten, Googles eigene neun Kategorien und welche davon eine IP-Abfrage sehen kann, finden Sie in GIVT vs. SIVT: Googles Kategorien für ungültigen Traffic.

KI-Crawler und KI-Agenten mit GeoIPHub verifizieren

GeoIPHub liefert die Anreicherung aus Schritt 5, die etablierte Geo-IP-Anbieter in ihren Anleitungen auslassen: ASN und Verbindungstyp, Hosting-/Rechenzentrumserkennung, VPN-, Proxy- und Tor-Flags, Flags für verifizierte Crawler aus 19 offiziellen Bereichs-Feeds (darunter GPTBot, ClaudeBot, PerplexityBot und AhrefsBot) und einen IP-Risikoscore. Residential Proxys erkennen wir nicht; dafür braucht es Verhaltenssignale. So können Sie bestätigen, dass ein Bot, der sich selbst ausweist, tatsächlich aus der Infrastruktur des Anbieters stammt, und die nicht eindeutigen Fälle bewerten, statt sie pauschal zu sperren. Kombinieren Sie das mit den oben beschriebenen Verifizierungsmethoden und den verwandten Leitfäden zur Erkennung von Kontoübernahmen und Credential Stuffing und dazu, wie genau IP-Geolokalisierung wirklich ist.

FAQ

Wie verifiziere ich, dass eine Anfrage wirklich von GPTBot stammt und nicht gefälscht ist?

Vertrauen Sie nicht dem User-Agent-Header; er lässt sich trivial fälschen. Gleichen Sie die Quell-IP mit der von OpenAI veröffentlichten Bereichsdatei pro Bot ab (openai.com/gptbot.json) und binden Sie die Prüfung gezielt an GPTBot statt an einen allgemeinen OpenAI-Bereich. Ist eine gültige Web-Bot-Auth-Signatur vorhanden, verifizieren Sie diese zuerst gegen das Schlüsselverzeichnis von OpenAI, da sie unabhängig von der IP ist. Behandeln Sie eine IP, die nicht im veröffentlichten Bereich liegt, als nicht eindeutig und nicht als erwiesene Fälschung, weil nutzergesteuerter Agenten-Datenverkehr aus anderer Infrastruktur stammen kann. Unser Vergleich GPTBot vs. OAI-SearchBot vs. ChatGPT-User zeigt eine echte Abfrage aus jeder Bereichsdatei von OpenAI.

Was ist Forward-Confirmed Reverse DNS (FCrDNS)?

FCrDNS ist eine Prüfung in vier Schritten: Lösen Sie die Quell-IP per Reverse DNS zu einem Hostnamen auf, bestätigen Sie, dass der Hostname auf die Domain des Betreibers endet, lösen Sie diesen Hostnamen per Forward DNS auf und bestätigen Sie dann, dass er wieder auf die ursprüngliche IP verweist. Der Forward-Schritt ist das, was Spoofing vereitelt: Ein Angreifer kann auf seiner eigenen IP einen gefälschten PTR-Eintrag setzen, aber nicht das autoritative Forward DNS des Betreibers fälschen. Eine Prüfung, die nur den PTR-String betrachtet, lässt sich fälschen.

Warum kann ich KI-Crawler nicht einfach anhand des User-Agent-Strings sperren?

Weil der User-Agent eine Behauptung ist, die jeder senden kann. HUMAN Security stellte fest, dass 5,7 % des gesamten Datenverkehrs, der als bekannter KI-Crawler gekennzeichnet war, gefälscht waren, mit Spitzen von fast einer von sechs Anfragen beim Agenten ChatGPT-User. Wer nur nach Header sperrt, lässt gefälschte Bots durch und tut nichts gegen einen Betreiber, der sich einfach nicht mehr zu erkennen gibt.

Was ist Web Bot Auth, und ist es ein fertiger Standard?

Web Bot Auth ist ein aufkommendes Verfahren, bei dem ein Bot jede HTTP-Anfrage mit einem Ed25519-Schlüssel nach RFC 9421 HTTP Message Signatures kryptografisch signiert, und der Ursprungsserver verifiziert sie gegen Schlüssel, die unter /.well-known/http-message-signatures-directory veröffentlicht sind. RFC 9421 selbst ist ein Proposed Standard (Februar 2024), Web Bot Auth ist aber Mitte 2026 noch ein IETF Internet-Draft ohne formellen Status. Behandeln Sie es als experimentell: Verifizieren Sie Signaturen, wo sie vorhanden sind, behalten Sie aber IP- und Reverse-DNS-Verifizierung als Grundlage bei.

Wo veröffentlichen KI-Anbieter die IP-Bereiche ihrer Crawler?

OpenAI veröffentlicht JSON pro Bot unter openai.com/gptbot.json, searchbot.json und chatgpt-user.json; Google veröffentlicht CIDR-JSON unter developers.google.com/static/crawling/ipranges/; Anthropic veröffentlicht eine Datei für seine Bots unter claude.com/crawling/bots.json; Perplexity veröffentlicht perplexitybot.json und perplexity-user.json. Binden Sie jede Prüfung an die Datei des jeweiligen Bots, gleichen Sie die exakt veröffentlichten Präfixe statt der Hosting-ASN ab und aktualisieren Sie die Dateien regelmäßig. Zu den drei Dateien von OpenAI und ihrer aktuellen Anzahl an Präfixen siehe IP-Bereiche von GPTBot, OAI-SearchBot und ChatGPT-User.

Wenn eine IP nicht im veröffentlichten Bereich des Anbieters liegt, ist die Anfrage dann gefälscht?

Nein. Eine IP im Bereich, ein bestandener FCrDNS-Test oder eine gültige Signatur ist ein echter Treffer mit hoher Konfidenz, eine IP außerhalb des Bereichs ist dagegen nicht eindeutig. Es könnte legitimer, nutzergesteuerter Agenten-Datenverkehr aus anderer Infrastruktur sein, eine per CGNAT geteilte Adresse, ein Egress von iCloud Private Relay, ein Anbieter ohne PTR-Einträge oder eine veraltete Bereichsdatei auf Ihrer Seite. Reservieren Sie harte Sperren für Verhaltens- und Herkunftssignale, nicht für das bloße Fehlen auf einer Liste.

Treffen Sperren von Crawler-IP-Bereichen nicht auch echte Nutzer auf geteilten Adressen?

Doch, und deshalb sollte das Fehlen einer IP keine harten Sperren auslösen. Eine Cloudflare-Studie von Ende 2025 ergab, dass CGNAT-Adressen etwa dreimal häufiger ratenbegrenzt wurden als andere, obwohl sie weniger Bot-Indikatoren zeigten, weil sich Hunderte bis Tausende Nutzer eine IPv4-Adresse teilen; CGNAT konzentriert sich zudem auf Teile Afrikas und Asiens, was eine geografische Verzerrung erzeugt. Auch Egress-IPs von iCloud Private Relay tragen echte Menschen und sollten anhand der von Apple veröffentlichten CSV-Datei auf die Allowlist gesetzt werden.