Ein KI-Agent hat gerade Ihre Website besucht. Woher wissen Sie, ob er echt ist?

Ein KI-Agent hat gerade eine Seite abgerufen, und in der Logzeile steht GPTBot/1.2. Dieser String ist kein Beweis. Einen User-Agent schreibt der Client selbst, also kann ihn jeder senden, und der einzige verlässliche Weg zur Verifizierung eines KI-Agenten führt über die Adresse, von der die Verbindung kam. Drei Prüfungen leisten die eigentliche Arbeit: Abgleich der Quell-IP mit der veröffentlichten Bereichsdatei des Betreibers, ein forward-confirmed Reverse-DNS-Lookup oder die Bestätigung, dass die IP vom eigenen ASN des Betreibers announced wird.

Welche der drei greift, hängt vollständig vom Betreiber ab, und genau das ist der lästige Teil. OpenAI veröffentlicht JSON-Bereichsdateien pro Bot. Anthropic veröffentlicht eine einzige Prefix-Datei, die ClaudeBot, Claude-User und Claude-SearchBot gemeinsam abdeckt. Apple unterstützt sowohl Reverse DNS als auch eine Bereichsdatei. Meta veröffentlicht weder noch und erwartet eine Prüfung gegen AS32934. Viele Crawler veröffentlichen überhaupt nichts, und dann ist der Name im Header reine Dekoration, während Sie nach Herkunft und Verhalten entscheiden.

Die Behauptung ist gratis, die Prüfung nicht

Überlegen Sie, was eine Allowlist-Regel wie "wenn User-Agent GPTBot enthält, Bot-Regeln überspringen" tatsächlich aussagt. Sie sagt: Jeder Client, der bereit ist, neun Zeichen zu tippen, bekommt die Behandlung, die Sie einem vertrauenswürdigen Crawler vorbehalten haben. Scraper lesen Ihre robots.txt, sehen, welche Agenten willkommen sind, und kleiden sich entsprechend. Diese Imitation ist nicht raffiniert, sondern schlicht billig, und sie funktioniert bei jeder Site, die nie hinter den Header schaut.

Die Prüfung kostet mehr. Sie brauchen die aktuellen Bereiche des Betreibers, einen DNS-Resolver oder Routing-Daten, pro Betreiber, aktualisiert bei jeder Änderung. Forscher haben bereits Traffic gemeldet, der sich als PerplexityBot ausgab und von Adressen außerhalb der veröffentlichten Bereiche von Perplexity kam. Genau das ist der Fehlerfall: Der Name war geborgt, das Netz nicht.

Jeder Betreiber dokumentiert das anders

Es gibt keinen gemeinsamen Standard, Verifizierung ist also ein Lookup pro Betreiber. Ein Ausschnitt aus dem Verzeichnis der KI-Crawler, das 150 Agenten erfasst:

Google-Extended verdient einen zweiten Blick, weil es das übliche Denkmodell bricht. Es ist eine robots.txt-Direktive zum Opt-out aus dem Gemini-Training, kein Crawler. Trifft eine Anfrage ein, die sich als Google-Extended ausgibt, ist sie per Definition eine Fälschung. Eine echte Version davon existiert nicht.

Von den 150 Agenten im Verzeichnis bieten 33 eine brauchbare Prüfung über veröffentlichte Bereiche, Reverse DNS oder ein ASN. Neun sind dokumentiert als Agenten, die robots.txt schlicht ignorieren. Der Rest liegt dazwischen: ein Name, und nichts, was ihn belegt.

So sieht Imitation in Ihren Logs aus

Zwei Anfragen, derselbe Header, wenige Minuten auseinander:

198.51.100.7  "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"
203.0.113.44  "Mozilla/5.0 ...; compatible; GPTBot/1.2; +https://openai.com/gptbot"

Nichts in der Zeile unterscheidet sie. Löst man die Adressen auf, ist der Unterschied sofort da: Eine liegt in den veröffentlichten Egress-Bereichen von OpenAI, die andere wird von einem Hoster announced, der Server stundenweise vermietet. Letztere hat außerdem 400 Produktseiten in neunzig Sekunden abgerufen und nie ein Stylesheet geladen, was kein Crawler tut, der sein eigenes veröffentlichtes Crawl-Budget einhält.

Das Muster wiederholt sich über alle Betreiber. Ein gefälschter ClaudeBot aus einem VPS-Bereich. Ein gefälschter Applebot mit einem PTR-Record, der auf die Domain eines Hosters zeigt, oder ganz ohne PTR. Ein gefälschter Amazonbot, dessen PTR plausibel aussieht, bis der Forward-Lookup eine andere Adresse zurückgibt, weshalb es den Bestätigungsschritt überhaupt gibt. In jedem Fall passte der Header perfekt und das Netz nicht.

Verifiziert, nicht verifizierbar und feindlich sind drei verschiedene Antworten

Sobald Sie den Header nicht mehr als Beweis behandeln, zerfällt der Traffic in Gruppen, die unterschiedliche Behandlung verdienen, und ein binäres Bot-Flag kann das nicht ausdrücken.

Ein verifizierter KI-Crawler ist eine Policy-Entscheidung: zulassen, abrechnen oder gezielt nach Namen blockieren, weil Ihre Inhalte nicht in diesen Korpus sollen. Eine Anfrage, die einen Namen behauptet und die IP-Prüfung nicht besteht, ist keine Policy-Entscheidung, sondern eine Fälschung, und sie darf nie den Zugang erben, den der echte Agent bekommt. Ein nicht verifizierbarer Crawler ohne jede Veröffentlichung braucht Rate Limits statt eines Verdicts. Und ein Headless-Browser aus einem Rechenzentrums-Bereich, der gar keinen Bot-Namen behauptet, ist genau der Fall, den Ihre Allowlist nie im Blick hatte.

Deshalb liefert Agentscan eine Klasse statt eines Booleans. Jede Anfrage kommt als human, known_bot, ai_agent oder malicious_automation zurück, mit einem Confidence-Wert und den Signalen, die dazu geführt haben.

Die Signale, die einen gefälschten User-Agent überleben

Die IP-Herkunft beantwortet den größten Teil der Frage, aber nicht alles. Ein Agent kann von einer Residential-Adresse laufen, und ein Scraper kann eine saubere IP ohne Vorgeschichte mieten. Drei weitere Signale halten stand, wenn der Header lügt:

JA4 TLS-Fingerprint. Der Client verrät seine Art, TLS zu sprechen, bevor er einen einzigen Header sendet: Cipher-Reihenfolge, Extensions, ALPN, Version. Ein Python-Skript, das sich als Chrome 124 ausgibt, erzeugt einen Handshake, den kein Chrome-Build je erzeugt hat. Der Header ist eine Behauptung, der Handshake ist Verhalten.

Headless-Spuren. Das webdriver-Flag, fehlende Browser-Oberflächen und Automationsmarker von Playwright, Puppeteer oder einem rohen HeadlessChrome-Build. Einzeln ist jede Spur schwach. Zusammen mit einer Rechenzentrums-Herkunft ist das Bild eindeutig.

Header-Konsistenz. Echte Browser senden Accept, Accept-Language und Accept-Encoding als Satz, in stabiler Reihenfolge, passend zur behaupteten Version. Handgebaute Request-Objekte senden meist nur eine Teilmenge, und die Lücken sind konsistent genug, um als Signal zu taugen.

Keines dieser Signale entscheidet allein, und genau darum geht es. Erst ihre Kombination trennt den verifizierten Crawler vom fähigen Imitator und beide vom normalen Besucher. Dieselbe Logik gilt für ältere Crawler, beschrieben in wie man Googlebot verifiziert.

Eine Policy, die den Kontakt mit echtem Traffic übersteht

Verifizierung nützt nur, wenn danach etwas passiert. Ein brauchbarer Standard:

1. Prüfen Sie die Behauptung mit der Methode des Betreibers, bevor irgendeine Allowlist-Regel greift. Bereichsdatei, Reverse DNS oder ASN, je nachdem, was dieser Betreiber veröffentlicht.
2. Eine fehlgeschlagene Verifizierung ist kein weiches Signal. Eine Anfrage, die sich als ClaudeBot ausgibt und von außerhalb der Anthropic-Prefixes kommt, ist Imitation. Behandeln Sie sie wie jeden unbekannten Scraper, nicht wie ein Vielleicht.
3. Trennen Sie die Allow-Entscheidung nach Zweck. Trainings-Crawler, KI-Suchcrawler und Assistenz-Fetcher brauchen eigene Regeln. Einen Suchcrawler zu blockieren, entfernt Sie aus den zitierten Antworten dieser Engine, das ist eine Traffic-Entscheidung, keine Sicherheitsfrage.
4. Begrenzen Sie das Nichtverifizierbare per Rate Limit. Bei Bytespider, CCBot und allem anderen ohne veröffentlichte Prüfung sagt der Name nichts. Anfragerate, Pfadmuster und Herkunft sagen umso mehr.
5. Loggen Sie die Klasse, nicht nur den Block. Zu wissen, dass sich der KI-Agent-Traffic im letzten Monat verdreifacht hat, ist mehr wert als ein Zähler blockierter Anfragen, gerade wenn Sie entscheiden, was Sie monetarisieren wollen.

Agentscan erledigt das mit einem POST auf /v1/agentscan/check: per Reverse DNS verifizierte Allowlist, Abgleich veröffentlichter Bereiche, IP-Herkunft, Headless-Flags und JA4 in einem einzigen Aufruf, gecacht, sodass wiederholte Lookups in unter 50ms zurückkommen. Schnell genug für die Middleware statt für die nächtliche Log-Auswertung.

Fazit

Sie können einen KI-Agenten nicht daran verifizieren, wie er sich selbst nennt. Prüfen Sie die Quell-IP gegen das, was der Betreiber tatsächlich veröffentlicht, behandeln Sie eine fehlgeschlagene Prüfung als Fälschung, und nutzen Sie JA4, Headless-Spuren und IP-Herkunft für alles, wofür die Allowlist nicht bürgen kann. Die Frage war nie "ist das ein Bot". Sie lautet, welche der vier Traffic-Arten gerade eingetroffen ist und was Sie mit jeder davon tun wollen.