KI-Crawler Fingerprinting: Echte Bots von Fälschungen unterscheiden

Jeder Server kann den User-Agent-String von GPTBot in eine Anfrage schreiben, ganz ohne mit der Infrastruktur von OpenAI verbunden zu sein. Deshalb veröffentlicht OpenAI für seine Crawler eigene, maschinenlesbare IP-Listen (https://developers.openai.com/api/docs/bots).

Definition: KI-Crawler Fingerprinting bezeichnet die technische Prüfung, ob eine Anfrage tatsächlich von einem bekannten KI-Bot wie GPTBot, ClaudeBot oder PerplexityBot stammt oder nur dessen Kennung imitiert. Grundlage dafür sind veröffentlichte IP-Listen, Reverse-DNS-Abgleiche oder kryptografische Signaturen, nicht der leicht fälschbare User-Agent-Header allein.

Der erste Fehler: Vertrauen in den User-Agent-Header

Der User-Agent-Header ist ein einfacher Text, den jeder Client frei setzen kann. Ein Scraper, der sich als GPTBot ausgibt, umgeht damit robots.txt-Regeln, die nur nach diesem String filtern, und taucht in deinen Logs als vermeintlich legitimer KI-Crawler auf.

Technisch spricht nichts dagegen, sich per User-Agent als GPTBot, ClaudeBot oder PerplexityBot auszugeben, wenn die Filterregel ausschließlich auf diesem String beruht und keine IP- oder DNS-Prüfung dahintersteht. Aus unserer Sicht lohnt sich deshalb ein Blick über den User-Agent-Header hinaus, sobald robots.txt oder Firewall-Regeln auf Bot-Namen reagieren sollen. Genau deshalb braucht Fingerprinting eine zweite Ebene: den Abgleich gegen etwas, das sich nicht einfach kopieren lässt.

Schritt 1: IP-Listen der KI-Anbieter abgleichen

Für den IP-Abgleich braucht es die aktuellen Adressbereiche der jeweiligen Anbieter:

Anbieter	Crawler	Quelle
OpenAI	GPTBot, OAI-SearchBot, ChatGPT-User	openai.com/gptbot.json (https://developers.openai.com/api/docs/bots)
Anthropic	ClaudeBot, Claude-User, Claude-SearchBot	claude.com/crawling/bots.json
Perplexity	PerplexityBot, Perplexity-User	perplexitybot.json / perplexity-user.json

Laut der Dokumentation von Anthropic gilt ein Treffer auf der veröffentlichten IP-Liste als Echtheitsnachweis für ClaudeBot, Claude-User und Claude-SearchBot, während reines Blockieren nach IP-Adresse als unzuverlässig eingestuft wird (https://support.claude.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler). Perplexity dokumentiert seine Crawler-IPs ebenfalls in getrennten JSON-Dateien für PerplexityBot und Perplexity-User (https://docs.perplexity.ai/docs/resources/perplexity-crawlers).

Der typische Stolperstein: Diese Listen sind keine statischen Dateien, die man einmal herunterlädt und ablegt. Wer sie fest im Code verdrahtet, prüft in drei Monaten gegen veraltete Adressen und schließt damit im Zweifel echte Anfragen aus oder lässt Fälschungen durch.

Schritt 2: Mit Reverse-DNS-Lookup Bots verifizieren

Für Googlebot empfiehlt Google in der eigenen Crawler-Dokumentation einen Reverse-DNS-Lookup: Der Hostname der anfragenden IP muss auf googlebot.com, google.com oder googleusercontent.com enden, bestätigt durch einen anschließenden Forward-Lookup zurück zur selben IP (https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests). Das Prinzip lässt sich auf andere Crawler übertragen, sofern der Anbieter passende PTR-Einträge pflegt.

Der Stolperstein hier liegt in der Übertragbarkeit: Nicht jeder KI-Crawler dokumentiert ein Reverse-DNS-Verfahren in dieser Form. Wer die Methode blind auf GPTBot oder PerplexityBot anwendet, ohne die jeweilige Dokumentation zu prüfen, verlässt sich auf eine unbelegte Annahme. Für Google ist das Verfahren dokumentiert, für andere Anbieter bleibt der IP-Listen-Abgleich aus Schritt 1 der belastbarere Weg.

Schritt 3: Web Bot Auth als kryptografischer Nachweis prüfen

Cloudflare hat mit Web Bot Auth einen Standard vorgestellt, der auf RFC 9421 (HTTP Message Signatures) basiert und Bot-Anfragen anhand kryptografischer Signaturen verifiziert (https://blog.cloudflare.com/web-bot-auth/). Nach der Cloudflare-Dokumentation stuft das System einen Bot nur dann als „Verified” ein, wenn er sich per Web-Bot-Auth-Signatur, veröffentlichter IP-Liste mit stabilem User-Agent oder Reverse-DNS eindeutig zu erkennen gibt und dabei robots.txt sowie Crawl-Direktiven respektiert (https://developers.cloudflare.com/bots/concepts/bot/verified-bots/).

Der Stolperstein: Web Bot Auth ist ein junger Ansatz, kein branchenweiter Zwangsstandard. Wer hinter Cloudflare sitzt, profitiert von dieser Klassifizierung automatisch mit. Wer eigene Server ohne CDN betreibt, muss IP-Listen und Reverse-DNS selbst implementieren, weil Signatur-Prüfung ohne die passende Infrastruktur dahinter praktisch nicht umsetzbar ist.

Schritt 4: Fingerprinting in robots.txt und Firewall-Regeln verankern

Erst wenn IP-Liste, DNS-Check oder Signatur zusammenlaufen, lohnt es sich, Regeln in robots.txt und WAF zu verankern. Perplexity weist in der eigenen Dokumentation ausdrücklich darauf hin, dass Änderungen an robots.txt- oder WAF-Regeln bis zu 24 Stunden benötigen, um wirksam zu werden (https://docs.perplexity.ai/docs/resources/perplexity-crawlers).

Ein Rechenbeispiel zur Einordnung: Angenommen, ein Server verzeichnet täglich 2.000 Anfragen mit dem User-Agent „GPTBot” im Log. In diesem Szenario würde der Abgleich dieser IPs gegen die von OpenAI veröffentlichte Liste einen klaren Filter liefern: Jede Anfrage außerhalb der Liste wäre dann per Definition kein echter GPTBot-Zugriff, unabhängig vom Header. Genau ein solcher Abgleich lässt sich, wie im Beitrag zur Log File Analyse: So erkennst du KI-Crawler wie GPTBot im Server-Log beschrieben, in bestehende Log-Auswertungen einbauen. Wer zusätzlich über Kontingente für verifizierte Bots nachdenkt, findet Ansätze dazu im Beitrag Rate Limiting für KI-Crawler: Solltest du GPTBot begrenzen?. Grundlegende Steuerung über die Datei selbst behandelt der Beitrag robots.txt für KI-Crawler: Crawlability und KI-Sichtbarkeit optimieren.

Der Stolperstein: Wer eine WAF-Regel scharfstellt und Minuten später ungeduldig testet, sieht unter Umständen noch das alte Verhalten und hält die Regel fälschlich für wirkungslos.

Was falsche Bot-Klassifizierung für deine KI-Sichtbarkeit bedeutet

Wird ein echter GPTBot-Zugriff fälschlich blockiert, weil eine veraltete IP-Liste im Einsatz ist, fehlt der Seite im schlechtesten Fall die Grundlage, um überhaupt in einer KI-Antwort zitiert zu werden. Wird umgekehrt ein gefälschter Bot durchgelassen, verzerrt das Crawl-Statistiken und Server-Last, ohne dass ein echter KI-Suchsystem-Zugriff dahintersteht. Beide Fehler wirken sich unmittelbar auf SEO- und GEO-Kennzahlen aus, die auf Crawler-Traffic beruhen.

Wie stark falsch klassifizierter Bot-Traffic die tatsächliche Sichtbarkeit einer Domain in ChatGPT, Perplexity oder Claude verzerrt, ist öffentlich nicht einheitlich untersucht. Aus unserer Sicht ist das kein Grund, Fingerprinting zu verschieben: Ein sauberer Abgleich gegen offizielle IP-Listen kostet wenig Aufwand und verhindert die teureren Folgefehler bei Log-Analyse und Rate Limiting.

Häufig gestellte Fragen

Wie erkenne ich, ob eine Anfrage wirklich von GPTBot stammt? Gleiche die anfragende IP-Adresse gegen die von OpenAI veröffentlichte Liste unter openai.com/gptbot.json ab. Nur ein Treffer auf dieser Liste gilt als belastbarer Nachweis, der User-Agent-String allein reicht nicht.

Reicht robots.txt aus, um gefälschte KI-Bots zu blockieren? Nein. robots.txt ist eine freiwillige Anweisung, an die sich nur Crawler halten, die sie überhaupt respektieren. Echte Validierung braucht IP-Liste, DNS-Check oder Signatur.

Was ist Web Bot Auth und brauche ich das? Wie im Abschnitt zu Web Bot Auth beschrieben, ist das ein von Cloudflare vorgestellter Standard auf Basis von RFC 9421, der Bots über kryptografische Signaturen verifiziert (https://blog.cloudflare.com/web-bot-auth/). Relevant ist er vor allem, wenn deine Website hinter Cloudflare läuft. Ohne CDN musst du auf IP-Listen und Reverse-DNS setzen.

Wie oft ändern sich die IP-Listen der KI-Crawler? Die Anbieter aktualisieren ihre Listen unregelmäßig, ohne festen Turnus öffentlich zu dokumentieren. Perplexity weist darauf hin, dass Regel-Änderungen bis zu 24 Stunden brauchen, um wirksam zu werden. Das zeigt: Auch die eigene Prüfung reagiert mit Verzögerung.

**Offen:** Nichts über die zwei benannten Beanstandungen hinaus — der Rest des Artikels war laut Claim-Gate unbeanstandet und blieb unverändert.