Wat Web Bot Auth betekent als je AI-crawlers al blokkeert

TL;DR: Web Bot Auth is RFC 9421 HTTP-message-signatures toegepast op crawler-verkeer. Bots ondertekenen hun requests met een private key, publiceren public keys in een .well-known-map en laten je de handtekening verifiëren in plaats van op de User-Agent-header te vertrouwen. Google publiceert sleutels op agent.bot.goog voor zijn AI-browsing-agent; Googlebot zelf is nog niet gesigneerd. Het werk voor 2026 is een verificatiepad toevoegen zonder reverse-DNS uit te faseren, omdat het merendeel van het verkeer dat zich als Google uitgeeft nog zeker een jaar ongesigneerd blijft.

Een operator waarmee ik samenwerk schreef in 2024 een Cloudflare-WAF-regel. Die blokkeert alles waarvan de UA GPTBot, ClaudeBot of PerplexityBot bevat en staat alles toe met Googlebot in de UA. Die regel hield twee jaar stand. In het voorjaar van 2026 verscheen echter een nieuwe user-agent in de logs: Google-Agent, met drie onbekende headers: Signature-Agent, Signature-Input en Signature. De regel uit 2024 kijkt niet naar die headers, alleen naar de UA. Die kloof tussen regels die op het oude verificatiemodel zijn geschreven en verkeer dat onder het nieuwe model binnenkomt, is waar dit stuk over gaat. Niet “wat is robots.txt” en ook niet “moet ik AI-crawlers blokkeren”, maar de integratie-vraag voor operators die al een bot-policy-ruleset beheren en willen weten wat Web Bot Auth daarvoor verandert.

Wat Web Bot Auth precies is

Web Bot Auth is een botgerichte profile van RFC 9421 HTTP Message Signatures. De bot ondertekent elke uitgaande request met een private key. De site haalt de public key van de bot op via een URL .well-known/http-message-signatures-directory op een domein dat de bot beheert. De site controleert of de handtekening op de inkomende request is gemaakt met de bijbehorende private key. Zo ja, dan is de herkomst cryptografisch bevestigd; zo nee, dan is de request vervalst.

Drie nieuwe request-headers doen het werk. Signature-Agent wijst naar de key-directory. Signature-Input vermeldt wat er is ondertekend plus metadata: keyid, created- en expires-tijds­stempels, algoritme en de letterlijke string tag="web-bot-auth" die deze handtekening als bot-specifiek markeert. Signature bevat de cryptografische 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)

Het bot-profile boven op de RFC maakt dit Web Bot Auth in plaats van zomaar HTTP-signatures. De IETF-draft draft-meunier-web-bot-auth-architecture legt de bot-conventies vast: de tag="web-bot-auth" in de input, de vorm van de well-known-URL, de aanbevolen onderdelen die moeten worden gedekt (minimaal @authority en signature-agent) en de verwachting dat de directory wordt gecachet met respect voor de eigen Cache-Control-header. Dat staat niet in RFC 9421 zelf; RFC 9421 is de algebra, Web Bot Auth het use-case-laagje.

Waarom UA + IP-verificatie niet meer genoeg is

De verificatiestack heeft drie lagen, elk met een bekend faal­scenario. User-Agent is tekst; iedereen kan ’m instellen. Reverse DNS werkt voor Googlebot maar is onhandig voor nieuwere agents die via generieke cloud-infra lopen. IP-allowlists zijn fragiel omdat cloud-egressranges zonder waarschuwing wisselen.

Johannes Ullrich van het SANS Internet Storm Center formuleerde het UA-spoofing-probleem kort en krachtig:

"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

Het IP-allowlist-probleem is verwant. Cloudflare’s Thibault Meunier en Mari Galicer, die Web Bot Auth door het IETF-proces loodsten, schreven in mei 2025: "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." Een allowlist die maandag klopt, kan vrijdag fout zijn.

De verschuiving naar agent-verkeer maakt de oude stack nóg zwakker. Wanneer een crawler namens een individuele gebruiker uit een chatsessie handelt, fragmenteert het bronprofiel. Cloudflare benoemde die kader­verandering expliciet: "Bots are no longer directed only by the bot owners, but also by individual end users to act on their behalf."

Cryptografische verificatie overleeft alle drie legacy-fouten. IP maakt niet uit, UA wordt niet vertrouwd en er is geen reverse-DNS-lookup nodig. Het draait om de sleutel.

Hoe een gesigneerde Google-request eruitziet

Een gesigneerde request van Google’s agent volgt de vorm in Cloudflare’s docs en Google’s gids. Ongeveer zo, met afgekorte keyid:

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...:

Lees van links naar rechts. Signature-Agent vertelt waar de public key staat. g="https://agent.bot.goog" resolveert naar https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input beschrijft wat is geattesteerd: hier het afgeleide component @authority (hostnaam) en de header signature-agent, ondertekend op created en geldig tot expires. De keyid is een JWK-thumbprint die één specifieke sleutel uit de directory kiest. Signature draagt de ed25519-handtekening.

De semantiek per parameter, in tabelvorm – dit is waar operators zich op een eerste leesbeurt vergissen:

Eén kanttekening van Google zelf: "Not all Google user agents are using Web Bot Auth." In mei 2026 is de UA die consequent signeert Google-Agent, de AI-browsing-agent achter AI Mode. Googlebot, de indexeringscrawler die het gros van je organische verkeer levert, is nog ongesigneerd. Stem je regels daarop af.

De verificatieflow van begin tot eind

Het pad heeft vier stappen. Geen ervan is duur. De bewegende delen zijn de directory-cache en de algoritme­bibliotheek, niet de wiskunde.

Stap één. De request komt binnen. Zoek een Signature-Agent-header. Ontbreekt die, dan is de request ongesigneerd en val je terug op de legacy-flow (reverse DNS, UA, IP). In 2026 geldt dit nog voor de meeste requests.

Stap twee. Parse Signature-Input. Haal keyid, created, expires, alg en tag eruit. Verwerp alles waar tag niet letterlijk web-bot-auth is. Verwerp alles voorbij expires. Beide checks komen vóór de sleutel.

Stap drie. Haal de public-key-directory op bij de URL in Signature-Agent. Respecteer de Cache-Control-header; Google zet er één. Cache in geheugen of Redis, ververs op expiratie, verwijder sleutels die verdwijnen (rotatie). Haal de sleutel met dezelfde thumbprint als keyid.

Stap vier. Verifieer de handtekening tegen de components uit Signature-Input. Bij succes is de herkomst cryptografisch bevestigd; bij falen beschouw je de request als vervalst.

De directory-cache gaat vaak mis bij operators. Neem Cache-Control als leidend. Niet te lang cachen (een verouderde directory accepteert ingetrokken sleutels) en niet per request refetchen (latentie + directory-DDoS). Bij fetch-fout met verlopen cache val je terug op het ongesigneerde pad. Blokkeer niet op een tijdelijke miss.

Wat er verandert voor je AI-bot-block-regels

De kernvraag voor operators: je hebt regels. Het protocol veranderde. Wat nu?

Goed nieuws: regels die blokkeren op UA bevat GPTBot, ClaudeBot of PerplexityBot blijven werken. De request heeft nog steeds een herkenbare UA, en een gespoofde GPTBot was altijd al de bot die je wilde blokkeren. Als je ook de legitieme gesigneerde GPTBot blokt, is dat een bewust beleid.

Minder goed nieuws: regels die toestaan op UA bevat Googlebot zijn nu ondergespecificeerd. Een spoofer met Googlebot-UA komt er nog steeds langs. De oplossing is niet om die regel onmiddellijk te herschrijven (het gesigneerde aandeel is te klein), maar een parallel pad toe te voegen: verifieer de handtekening op gesigneerd Google-verkeer en behandel de ongesigneerde rest via reverse DNS. Cloudflare’s verified-bots-team vatte het zo samen:

"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

Het twee-stack-model is het juiste mentale beeld. Eén regelset behandelt gesigneerd verkeer, verifieert de handtekening, checkt keyid, valideert expires en routeert op basis van de bevestigde identiteit. De andere regelset behandelt ongesigneerd verkeer met de legacy-checks precies zoals nu. Verwijder de legacy-regels niet; medio 2026 loopt het meeste echte Google-verkeer er nog doorheen.

Signatures verifiëren op je origin (zonder Cloudflare)

Zit je achter Cloudflare, dan is het werk klein. Cloudflare valideert aan de edge en exposeert het resultaat via cf.verified_bot_category in WAF- en Transform-Rules. Je regel wordt “als cf.verified_bot_category de gewenste categorie is, routeer X”, en de crypto ligt buiten je code.

Zit je niet achter een verifiërende CDN, dan doe je het op je origin. Dat is een kleine middleware vóór nginx of je app-server. Die onderschept requests met Signature-Agent, haalt de .well-known-directory op (cache), verifieert volgens RFC 9421 en zet een interne X-Verified-Bot-header die je downstream-regels lezen.

Het Cloudflare-onderzoeksteam open-sourcete de onderdelen op cloudflareresearch/web-bot-auth. De Rust-crate en TypeScript-npm-package (web-bot-auth) bevatten de verificatielogica; de repo levert een Caddy-plugin en Worker-voorbeelden. Niet geaudit (staat in de README), maar het oppervlak is klein en zelf RFC 9421 bouwen is zwaarder.

Pragmatisch: op Cloudflare is het edge-pad duidelijk. Buiten Cloudflare: installeer de middleware, wijs ’m op de agents die je wilt verifiëren (nu agent.bot.goog en eventueel meer) en lees de trust-header in je bestaande regels. Embed de signature-verificatie niet in business-code; houd ’m in de front-tier waar audit en vervanging makkelijk zijn.

De reverse-DNS-fallback verdwijnt niet

Ik ham er steeds op: verwijder de legacy-regels niet, want het gesigneerde aandeel is nog klein. In mei 2026 signeert de Googlebot-indexeringscrawler niet. Alleen de AI-browsing Google-Agent signeert. Voor de meeste sites is AI-browsing eenfracte van het totale Google-verkeer. De indexeringsshare die je organische zichtbaarheid stuurt, is ongesigneerd tot zeker 2027.

Google zegt dat expliciet. Dezelfde crawler-documentatie die Web Bot Auth introduceert, adviseert operators “continue relying on IP addresses, reverse DNS, and user-agent strings” naast het nieuwe protocol. Dat is geen slag om de arm; het is het werkmodel. Web Bot Auth is één rail, de legacy-stack een tweede. Ze draaien parallel en in 2026 draagt legacy meer gewicht.

Auditritme: elk kwartaal een sample van Google-verkeer uit de logs, buckets gesigneerd/ongesigneerd, bereken het gesigneerde aandeel. Stijgt dat boven 30-40 %, dan wordt signature-verificatie leidend. Boven 70 % verdient de ongesigneerde Googlebot-UA-regel een harde review; spoofers vallen dan juist in die minderheid. Tot die drempels: laat beide rails lopen en zie crypto als additief.

Één anti-patroon: schrijf nu geen regel die ongesigneerde Googlebot-UA blokkeert. Je de-indexeert jezelf binnen één crawlcyclus.

Wat je dit kwartaal echt moet doen

Checklist van vier, vendor-vrij.

Ten eerste: inventariseer je bestaande bot-regels. Label per regel wat hij verifieert: UA, reverse DNS, IP-range of signature. Meestal vind je dubbele of verouderde regels. Ruim die op vóór je nieuwe toevoegt.

Ten tweede: voeg een signature-pad toe. Op Cloudflare: zet verified-bots-edge-validatie aan en maak één regel op cf.verified_bot_category. Op je eigen origin: installeer de WBA-middleware, wijs ’m op agent.bot.goog (en andere relevante directories) en surf een trust-header uit.

Ten derde: behoud het reverse-DNS-pad voor de veel grotere pool ongesigneerd Google-verkeer. Niet aanscherpen, niet vervangen, gewoon naast het signature-pad laten lopen.

Ten vierde: plan het kwartaalrapport: aandeel gesigneerd Google-verkeer, aandeel gesigneerd AI-agent-verkeer en percentage spoofers dat door signature-verificatie is gepakt maar legacy miste. De cijfers bewegen langzaam in 2026 en sneller in 2027. Je regels moeten meebewegen.

Beheer je ook bredere AI-crawler-policy, lees dan de AI-crawler-playbook en het Cloudflare-AI-bot-block-stuk voor de allow/block-kant. Dit artikel gaat over identiteit.

Wat dit NIET oplost

Web Bot Auth gaat over identiteit, niet autorisatie. De handtekening bewijst dat een request van een specifieke bot komt. Ze zegt niets over de vraag of die bot de URL mag lezen. Een gesigneerde Google-Agent kan nog steeds je betaalmuur scrapen als je regels dat toelaten. De handtekening geeft vertrouwen in de bron; het beleid is aan jou.

Het heeft ook geen mening over robots.txt. Een gesigneerde bot die robots negeert, blijft een robots-overtreder; signing geeft geen extra rechten. Wil je dat de gesigneerde AI-agent je betaalde sectie overslaat, stel dat in via robots en handhaaf het in je regels.

Evenmin beslist het tussen AI-search-routing en traditionele search. Web Bot Auth zegt “dit is echt Google-Agent.” Of die dezelfde content krijgt als Googlebot of iets anders, is jouw keuze. Het stuk over optimaliseren voor Perplexity, ChatGPT-search en Google AI Mode behandelt die routing-kant.

Eerlijke beoordeling: dit is één rail in een drielaagse stack. Signature voor identiteit, reverse DNS voor legacy-verificatie, robots-policy voor autorisatie. De nieuwe rail verstevigt de eerste. Operators die in 2026 slagen, behandelen alle drie als dragend.

Het auditritme naarmate adoptie groeit

De lijn om te volgen door 2026-2027 is het gesigneerde aandeel van je Google-verkeer. Nu is dat bij de meeste sites eencijferig. Boven 30-40 % wordt het verificatiepad bepalend. Boven 70 % verdient de ongesigneerde Googlebot-regel een zware review.

Herhaal de inventarisatie halfjaarlijks en lees Google’s crawler-docs dan opnieuw; ze evolueren. De directory-vorm en de lijst gedekte components zijn de spec-delen die het meest kunnen schuiven. Twee keer per jaar is genoeg.

Voor de basis over Googlebot zie onze uitleg over wat Googlebot is. Voor de agent-kant: hoe je een agent-vriendelijke site bouwt schetst het integratieplaatje.

FAQ

Signeert Googlebot zelf al requests? Niet medio 2026. Google’s huidige Web Bot Auth-uitrol dekt de AI-browsing-agent Google-Agent. Googlebot, de indexeringscrawler voor organisch verkeer, authenticert nog via reverse DNS en de gedocumenteerde IP-ranges. Behandel ze gescheiden in je regels.

Vervangt Web Bot Auth robots.txt? Nee. Ze beantwoorden verschillende vragen. Web Bot Auth bevestigt “deze request is echt van Google”. Robots.txt bepaalt “deze URL mag wel of niet gecrawld worden”. Beide blijven gelden; een gesigneerde bot die robots negeert, blijft in overtreding.

Welk signature-algoritme gebruikt Web Bot Auth? RFC 9421 ondersteunt er meerdere. Cloudflare’s voorbeelden en Google’s directory gebruiken ed25519 (EdDSA over Curve25519). Je verifier heeft dus een ed25519-implementatie nodig; in Go, Rust, Node en Python is dat één library-call.

Wat als Google’s public-key-directory niet bereikbaar is? Cache de directory volgens Cache-Control. Is je cache vers, dan verifieer je daarmee. Is de cache verlopen en faalt de fetch, val terug op het ongesigneerde pad (reverse DNS, UA, IP). Blokkeer niet op een tijdelijke cache-miss; zo de-indexeer je jezelf bij een hik in Google’s directory.

Moet ik reverse-DNS-verificatie voor Googlebot schrappen? Nog niet, en waarschijnlijk niet in 2026. Het gesigneerde aandeel is te klein. Reverse DNS is je echte verdediging tegen UA-spoofers die zich als Googlebot uitgeven, omdat Googlebot zelf ongesigneerd is. Her­evalueer elk kwartaal. Verstrak pas wanneer het ongesigneerde pad minderheidsverkeer is.