Was Web Bot Auth bedeutet, wenn Sie bereits KI-Crawler blockieren

Kurzfassung: Web Bot Auth ist RFC 9421 HTTP Message Signatures, angewandt auf Crawler-Traffic. Bots signieren ihre Requests mit einem privaten Schlüssel, veröffentlichen öffentliche Schlüssel im .well-known-Verzeichnis und lassen Sie die Signatur prüfen, statt dem User-Agent-Header zu vertrauen. Google stellt die Schlüssel heute unter agent.bot.goog für seinen AI-Browsing-Agent bereit; der eigentliche Googlebot ist noch nicht signiert. Die Aufgabe bis 2026 ist, einen Signatur-Prüfpfad einzubauen, ohne die Reverse-DNS-Kontrolle zu entfernen, denn der Großteil des als „Google“ getarnten Traffics bleibt noch mindestens ein Jahr unsigniert.

Ein Betreiber, mit dem ich arbeite, schrieb 2024 eine Cloudflare-WAF-Regel. Sie blockiert alles, dessen UA GPTBot, ClaudeBot oder PerplexityBot enthält, und erlaubt alles, dessen UA Googlebot enthält. Die Regel hielt zwei Jahre. Dann tauchte im Frühjahr 2026 ein neuer User-Agent in den Logs auf: Google-Agent, begleitet von drei unbekannten Headern: Signature-Agent, Signature-Input und Signature. Die 2024-Regel ignoriert diese Header; sie sieht nur den UA. Genau diese Lücke zwischen Regeln, die auf dem alten Verifikations­modell basieren, und Traffic, der nach dem neuen Modell ankommt, ist Thema dieses Beitrags. Nicht „was ist robots.txt“. Nicht „soll ich KI-Crawler blockieren“. Sondern das Integrations­thema für Betreiber, die bereits ein Bot-Policy-Ruleset pflegen und wissen müssen, was Web Bot Auth daran ändert.

Was Web Bot Auth tatsächlich ist

Web Bot Auth ist ein bot-spezifisches Profil von RFC 9421 HTTP Message Signatures. Der Bot signiert jede ausgehende Anfrage mit einem privaten Schlüssel. Die Website ruft den öffentlichen Schlüssel des Bots unter einer URL .well-known/http-message-signatures-directory auf einer vom Bot kontrollierten Domain ab. Die Site prüft, ob die Signatur der eingehenden Anfrage mit dem passenden privaten Schlüssel erzeugt wurde. Ist das der Fall, ist der Herkunfts­nachweis kryptografisch belegt. Ist es nicht der Fall, ist die Anfrage gefälscht.

Drei neue Request-Header erledigen die Arbeit. Signature-Agent verweist auf das Schlüssel­verzeichnis des Bots. Signature-Input listet die signierten Bestandteile plus Metadaten: keyid, created- und expires-Zeitstempel, Algorithmus sowie den Literal­string tag="web-bot-auth", der diese Signatur eindeutig als Bot-Signatur kennzeichnet. Signature trägt die kryptografischen Bytes.

„This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message.“ — A. Backman, J. Richer, M. Sporny, RFC 9421 (HTTP Message Signatures, Abstract)

Das Bot-Profil auf Basis des RFC macht daraus Web Bot Auth und nicht nur HTTP-Message-Signatures. Der IETF-Entwurf draft-meunier-web-bot-auth-architecture präzisiert die Bot-Konventionen: den String tag="web-bot-auth" im Input, die Form der Well-Known-URL, die empfohlenen signierten Komponenten (mindestens @authority und signature-agent) und die Erwartung, dass das Verzeichnis gemäß seinem eigenen Cache-Control-Header gecacht wird. Nichts davon steht in RFC 9421 selbst. RFC 9421 ist die Algebra. Web Bot Auth ist das Einsatz­szenario.

Warum UA + IP-Verifikation nicht mehr reicht

Der Verifikations-Stack hat drei Ebenen, jede mit einem bekannten Fehler­muster. User-Agent ist reiner Text; jeder kann ihn setzen. Reverse DNS funktioniert für Googlebot, ist aber umständlich für neuere Agent-Crawler, die über allgemeine Cloud-Infrastruktur laufen. IP-Allowlists sind fragil, weil sich Cloud-Egress-Ranges ohne Vorwarnung ändern.

Johannes Ullrich vom SANS Internet Storm Center formulierte das UA-Spoofing-Problem unverblümt:

„Users have long figured out that setting your user agent to ‘Googlebot’ may get you past some paywalls.“ — Johannes Ullrich, SANS Internet Storm Center, September 2025

Die IP-Allowlist hat ein verwandtes Problem. Thibault Meunier und Mari Galicer von Cloudflare, die den Web-Bot-Auth-Vorschlag in der IETF begleiteten, beschrieben es im Mai 2025 so: „Connections from the crawling service might be shared by multiple users, such as in the case of privacy proxies and VPNs, and these ranges, often maintained by cloud providers, change over time.“ Eine Allowlist, die am Montag korrekt war, kann am Freitag schon falsch sein.

Die Verschiebung hin zu Agent-Traffic verschlimmert den alten Stack. Handelt ein Crawler im Auftrag eines einzelnen Nutzers aus einer Chat-Session heraus, fragmentiert das Quellprofil. Cloudflare sprach diese neue Perspektive direkt an: „Bots are no longer directed only by the bot owners, but also by individual end users to act on their behalf.“

Kryptografische Verifikation ist das einzige Verfahren, das alle drei Legacy-Fehler­modi übersteht. Sie interessiert sich weder für die Quell-IP, noch vertraut sie dem UA, noch braucht sie einen Reverse-DNS-Lookup. Entscheidend ist nur der Schlüssel.

So sieht ein signierter Googlebot-Request wirklich aus

Eine signierte Anfrage vom Google-Agent folgt der Form aus Cloudflares Referenz und Googles Entwickler­leitfaden. Ungefähr so, keyid gekürzt:

GET /article/example HTTP/1.1
Host: yoursite.com
User-Agent: Mozilla/5.0 (compatible; Google-Agent/1.0; ...)
Signature-Agent: g="https://agent.bot.goog"
Signature-Input: sig=("@authority" "signature-agent")
 ;created=1735689600;keyid="poqkLGiymh_W0uP6PZFw-dvez3QJT5SolqXBCW38r0U"
 ;alg="ed25519";expires=1735693200;tag="web-bot-auth"
Signature: sig=:MEQCIBmw...truncated...:

Von links nach rechts: Signature-Agent zeigt, wo der öffentliche Schlüssel abzurufen ist. Der Literal­wert g="https://agent.bot.goog" verweist auf ein Verzeichnis unter https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input beschreibt, was attestiert wird: hier die abgeleitete Komponente @authority (Hostname) und der Header signature-agent, signiert zum Zeitpunkt created und gültig bis expires. keyid ist ein JWK-Thumbprint, der einen speziellen Schlüssel im Verzeichnis auswählt. Signature enthält die ed25519-Signatur-Bytes.

Die Bedeutung der einzelnen Parameter in Tabellenform – hier passieren beim ersten Lesen die meisten Fehler:

Ein direktes Caveat von Google: „Not all Google user agents are using Web Bot Auth.“ Im Mai 2026 signiert konsistent nur Google-Agent, der AI-Browsing-Agent hinter Googles AI-Mode-Features. Googlebot – der Index-Crawler, der den größten Teil Ihres organischen Traffics liefert – ist noch nicht signiert. Planen Sie Ihre Regeln entsprechend.

Der komplette Verifikationsflow

Der Prüfvorgang umfasst vier Schritte. Keiner ist teuer. Die beweglichen Teile sind der Directory-Cache und die Algo-Bibliothek, nicht die Mathematik.

Schritt 1: Die Anfrage trifft ein. Prüfen Sie auf einen Signature-Agent-Header. Fehlt er, ist die Anfrage unsigniert und fällt zurück auf den Legacy-Pfad (Reverse DNS, UA, IP). 2026 landet noch die Mehrzahl der Requests hier.

Schritt 2: Signature-Input parsen. keyid, created, expires, alg und tag herausziehen. Alles verwerfen, bei dem tag nicht exakt web-bot-auth ist. Alles verwerfen, was nach expires liegt. Beides passiert, bevor Sie den Public Key anfassen.

Schritt 3: Das Public-Key-Verzeichnis unter der URL aus Signature-Agent abrufen. Den Cache-Control-Header des Verzeichnisses respektieren; Google setzt ihn. Directory im Speicher oder Redis cachen, bei Ablauf auffrischen und Schlüssel entfernen, die verschwunden sind (Key-Rotation). Den Schlüssel auswählen, dessen JWK-Thumbprint keyid entspricht.

Schritt 4: Signatur gegen die in Signature-Input genannten Komponenten prüfen. Besteht die Prüfung, ist kryptografisch belegt, dass die Anfrage vom Inhaber des Private Keys stammt. Scheitert sie, gilt die Anfrage als gefälscht.

Der Directory-Cache ist das Element, das Betreiber am häufigsten falsch konfigurieren. Behandeln Sie den Cache-Control-Header als maßgeblich. Nicht über-cachen (ein veraltetes Verzeichnis akzeptiert widerrufene Schlüssel) und nicht unter-cachen (Refetch pro Request erhöht Latenz und belastet das Verzeichnis-Endpoint). Schlägt ein Fetch fehl und der Cache ist abgelaufen, fallen Sie auf den unsignierten Pfad zurück. Blockieren Sie nicht bei einem transienten Miss.

Was sich für Ihre KI-Bot-Block-Regeln ändert

Hier die Kernfrage der Betreiber: Sie haben Regeln geschrieben. Das Protokoll hat sich geändert. Was nun?

Die gute Nachricht zuerst: Regeln, die „UA enthält GPTBot, ClaudeBot oder PerplexityBot“ blockieren, bleiben unverändert wirksam. Die Anfrage kommt weiterhin mit erkennbarem UA, und ein gefälschter GPTBot gab sich schon immer als der Bot aus, den Sie blockieren wollten. Wenn Ihre Regeln auch den legitimen signierten GPTBot blockieren, ist das eine bewusste Policy-Entscheidung.

Die weniger gute Nachricht: Regeln, die „UA enthält Googlebot erlaubt“ verwenden, sind jetzt zu grob. Ein Spoofer mit Googlebot-UA passiert sie weiterhin. Die Lösung ist nicht, die Regel über Nacht zu löschen (der signierte Anteil ist noch zu klein), sondern einen parallelen Regelpfad hinzuzufügen: Signatur für signierten Google-Traffic prüfen, den unsignierten Rest per Reverse-DNS verifizieren. Cloudflares Verified-Bots-Team fasste die Lücke so zusammen:

„Existing identification methods rely on a combination of IP address range (which may be shared by other services, or change over time) and user-agent header (easily spoofable). These have limitations and deficiencies.“ — Cloudflare verified-bots team, Juli 2025

Das Zwei-Stack-Modell ist das richtige Bild: Ein Regelwerk behandelt signierten Traffic, prüft die Signatur, validiert die keyid gegen eine Trusted-List, kontrolliert expires und routet anhand der verifizierten Identität. Das andere Regelwerk behandelt unsignierten Traffic und führt Reverse-DNS, UA- und IP-Prüfung wie bisher aus. Löschen Sie die Legacy-Regeln nicht; Mitte 2026 läuft der Großteil Ihres echten Google-Traffics noch darüber.

Signaturen am Origin prüfen (ohne Cloudflare)

Sitzen Sie hinter Cloudflare, ist der Aufwand gering. Cloudflare validiert Signaturen am Edge und stellt das Ergebnis über cf.verified_bot_category in WAF-Custom- und Transform-Rules zur Verfügung. Ihre Regel lautet dann: „Wenn cf.verified_bot_category die gewünschte Kategorie ist, entsprechend routen“ – die Kryptografie erledigt ein anderer.

Ohne verifizierenden CDN erledigen Sie die Arbeit am Origin. Dafür braucht es eine kleine Middleware vor nginx oder Ihrem App-Server. Sie fängt Requests mit Signature-Agent ab, ruft beim ersten Mal (danach gecacht) das .well-known-Verzeichnis des Bots ab, prüft nach RFC 9421 und setzt einen internen X-Verified-Bot-Header, den Ihre Downstream-Regeln auswerten.

Cloudflares Research-Team hat die Prüfkomponenten unter cloudflareresearch/web-bot-auth open-sourced. Das Rust-Crate und das TypeScript-npm-Paket (web-bot-auth) enthalten die Verifikations-Logik; das Repo bringt einen Caddy-Plugin und Worker-Beispiele mit. Nichts davon ist auditiert (steht im README), aber die Prüffläche ist klein, und die Alternative wäre, RFC 9421 selbst zu implementieren.

Pragmatischer Rat: Auf Cloudflare ist der Edge-Pfad offensichtlich. Ohne Cloudflare installieren Sie die Middleware, konfigurieren sie auf die Agent-Verzeichnisse, die Sie prüfen wollen (heute Google, später weitere) und lesen den Trust-Header in Ihren bestehenden Regeln. In beiden Fällen: Bauen Sie die Signatur-Prüfung nicht in Business-Logik ein. Halten Sie sie in der Front-Tier, wo sie auditierbar und austauschbar bleibt.

Der Reverse-DNS-Fallback verschwindet nicht

Ich betone „löschen Sie die Legacy-Regeln nicht“, weil der signierte Anteil noch klein ist. Im Mai 2026 signiert der Googlebot-Index-Crawler nicht. Nur der AI-Browsing-Google-Agent signiert. Für die meisten Sites ist der AI-Browsing-Anteil einstelliger Prozentbereich des Google-Traffics. Der Index-Anteil, der Ihre organische Sichtbarkeit liefert, ist heute unsigniert und voraussichtlich bis 2027.

Google schreibt es klar: Die Crawler-Dokumentation, die Web Bot Auth vorstellt, rät Betreibern, „continue relying on IP addresses, reverse DNS, and user-agent strings“ zusätzlich zum neuen Protokoll. Das ist kein Hintertürchen, sondern das Betriebsmodell. Web Bot Auth ist eine Verifikations-Schiene; der Legacy-Stack ist die andere. Beide laufen parallel, 2026 trägt der Legacy-Stack noch mehr Last.

Audit-Rhythmus: Vierteljährlich ziehen Sie eine Stichprobe des „Google“-Traffics aus den Logs, teilen ihn in signiert und unsigniert und berechnen den signierten Anteil. Steigt er auf 30–40 %, gewinnt der Signatur-Pfad an Gewicht. Steigt er auf 70 %, verdient die unsignierte Googlebot-UA-Regel eine harte Prüfung; die Spoofer sind dann in diesem Minderheits-Bucket am sichtbarsten. Vor allen Schwellen behalten Sie beide Schienen und behandeln die kryptografische als additive.

Ein Gegen-Anti-Pattern: Schreiben Sie heute keine Regel, die unsignierten Googlebot-UA-Traffic blockiert. Sie de-indexieren sich in einem Crawl-Zyklus selbst.

Was Sie dieses Quartal konkret tun

Vier-Punkte-Checkliste – ohne Vendor-Lock-in:

Erstens: Inventarisieren Sie Ihre bestehenden Bot-Regeln. Markieren Sie jede nach dem tatsächlichen Prüfkriterium: UA, Reverse DNS, IP-Range oder Signatur. Bei den meisten Audits tauchen doppelte oder veraltete Regeln auf. Bereinigen Sie die, bevor Sie Neues hinzufügen.

Zweitens: Fügen Sie einen Signatur-Prüfpfad hinzu. Auf Cloudflare: Verified-Bots-Edge-Validation aktivieren und eine Regel auf cf.verified_bot_category bauen. Am eigenen Origin: WBA-Middleware installieren, auf agent.bot.goog (und weitere) konfigurieren und einen Trust-Header ausgeben, den Ihre Regeln lesen.

Drittens: Behalten Sie den Reverse-DNS-Pfad für den viel größeren Pool unsignierten Google-Traffics. Nicht verschärfen, nicht ersetzen – parallel fahren.

Viertens: Planen Sie das Quartals-Audit: Signierter Anteil des Google-Traffics, signierter Anteil des AI-Agent-Traffics, Prozent­zahl der Spoofer, die durch Signatur-Prüfung erwischt wurden und von Legacy-Regeln verpasst wurden. Die Werte bewegen sich 2026 langsam, 2027 schneller. Ihre Regel­struktur sollte Schritt halten.

Falls Ihr Team auch die breitere KI-Crawler-Policy betreibt, sind das AI-Crawler-Playbook und der Artikel zum Deaktivieren der Cloudflare-AI-Bot-Blockade passende Ergänzungen zur Allow/Block-Seite. Dieser Beitrag behandelt die Identitäts-Seite.

Was das NICHT löst

Web Bot Auth ist Identität, nicht Autorisierung. Die Signatur beweist, dass eine Anfrage von einem bestimmten Bot stammt. Sie sagt nichts darüber aus, ob der Bot die URL lesen darf. Ein verifizierter, signierter Google-Agent kann Ihre Paywall trotzdem scrapen, wenn Ihre Regeln ihn durchlassen. Die Signatur kauft Vertrauen in die Herkunfts­angabe. Die Policy liegt weiter bei Ihnen.

Zu robots.txt hat Web Bot Auth ebenfalls keine Meinung. Ein signierter Bot, der robots ignoriert, bleibt ein robots-Verletzer; Signieren verleiht keine Zusatz­rechte. Wenn der signierte AI-Browsing-Agent Ihren Pay-Bereich auslassen soll, teilen Sie es via robots mit und erzwingen es in Ihren Regeln.

Und es entscheidet nicht, ob Sie AI-Search-Routing oder traditionelles Search-Routing einsetzen. Web Bot Auth sagt Ihnen nur „das ist wirklich Google-Agent“. Ob Google-Agent denselben Content wie Googlebot oder abweichenden Content bekommt, ist Ihre Policy. Der Beitrag zum Optimieren für Perplexity, ChatGPT-Search und Google AI Mode behandelt die Routing-Seite.

Ehrliche Einschätzung: Das ist eine Schiene in einem Drei-Schienen-Stack. Signatur für Identität, Reverse DNS für Legacy-Verifikation, robots-Policy für Autorisierung. Die neue Schiene härtet die erste. Betreiber, die 2026 erfolgreich sind, betrachten alle drei als tragend.

Der Audit-Rhythmus, wenn die Adoption steigt

Die Kennzahl durch 2026/2027 ist der signierte Anteil Ihres Google-Traffics. Heute sind das meist einstellige Prozentwerte. Überschreitet er 30–40 %, gewinnt der Verifikations-Pfad an Bedeutung. Überschreitet er 70 %, braucht die unsignierte Googlebot-UA-Regel eine harte Überprüfung.

Führen Sie das Inventar alle zwei Quartale erneut durch und lesen Sie Googles Crawler-Doku dabei; sie ändert sich. Die Directory-Struktur und die Liste der signierten Komponenten sind die zwei Spezifikations­teile mit größter Änderungs­wahrscheinlichkeit. Zwei Mal pro Jahr reicht, um vorne zu bleiben.

Für den grundlegenden Googlebot-Kontext ist unser Googlebot-Erklärer der richtige Start. Für die Agent-Traffic-Seite zeigt How to build an agent-friendly website das Integrations-Bild.

FAQ

Signiert Googlebot inzwischen? Stand Mitte 2026: nein. Googles aktueller Web-Bot-Auth-Rollout umfasst den AI-Browsing-Google-Agent. Googlebot, der Index-Crawler für klassisches organisches Ranking, authentifiziert weiter via Reverse DNS und Googlebot-IP-Ranges. Behandeln Sie beide getrennt.

Ersetzt Web Bot Auth robots.txt? Nein. Sie beantworten unterschiedliche Fragen. Web Bot Auth bestätigt „diese Anfrage stammt wirklich von Google“. Robots.txt regelt „diese URL darf oder darf nicht gecrawlt werden“. Beides gilt weiterhin, und ein signierter Bot, der robots ignoriert, verletzt sie trotzdem.

Welchen Signatur-Algorithmus nutzt Web Bot Auth? RFC 9421 unterstützt mehrere. Cloudflares Beispiele und Googles Verzeichnis nutzen ed25519 (EdDSA über Curve25519). Ihr Verifier braucht eine ed25519-Implementation – ein einziger Bibliotheks-Call in Go, Rust, Node, Python usw.

Was passiert, wenn Googles Public-Key-Verzeichnis nicht erreichbar ist? Sie cachen das Verzeichnis gemäß Cache-Control. Ist Ihr Cache frisch, prüfen Sie gegen die gecachten Keys. Ist er abgelaufen und das Fetch schlägt fehl, fallen Sie auf den unsignierten Pfad (Reverse DNS, UA, IP) zurück. Blockieren Sie nicht auf einen transienten Cache-Miss – sonst de-indexieren Sie sich, wenn Googles Verzeichnis hakt.

Sollte ich Reverse-DNS-Verifikation für Googlebot abschalten? Noch nicht, wahrscheinlich auch 2026 nicht. Der signierte Anteil ist zu klein. Reverse DNS ist Ihre echte Verteidigung gegen UA-Spoofer, die sich als Googlebot ausgeben, weil Googlebot aktuell unsigniert ist. Bewerten Sie quartalsweise neu, wenn der signierte Anteil steigt. Der richtige Zeitpunkt zum Verschärfen des unsignierten Pfads ist, wenn er Minderheit Ihres realen Google-Traffics ist – nicht umgekehrt.