Cosa Significa Web Bot Auth se Stai Già Bloccando i Crawler AI

In breve: Web Bot Auth applica le firme dei messaggi HTTP dell’RFC 9421 al traffico dei crawler. I bot firmano le richieste con una chiave privata, pubblicano le chiavi pubbliche in una directory .well-known e consentono al tuo server di verificare la firma invece di fidarsi dell’header User-Agent. Oggi Google pubblica le chiavi su agent.bot.goog per il suo agente di navigazione AI; Googlebot “classico” non è ancora firmato. Il lavoro del 2026 consiste nell’aggiungere il percorso di verifica della firma senza eliminare il reverse-DNS, perché la maggior parte del traffico che dichiara di provenire da Google resta non firmato e lo sarà per almeno un altro anno.

Un operatore con cui collaboro scrisse nel 2024 una regola WAF su Cloudflare. Blocca tutto ciò il cui UA contiene GPTBot, ClaudeBot o PerplexityBot e consente tutto ciò il cui UA contiene Googlebot. La regola ha retto per due anni. Poi, nella primavera 2026, nei log è comparso un nuovo user agent, Google-Agent, con tre header mai visti: Signature-Agent, Signature-Input e Signature. La regola del 2024 non considera quegli header: legge solo l’UA. Il divario tra regole scritte sul vecchio modello di verifica e traffico che arriva col nuovo è l’argomento di questo articolo. Non “che cos’è robots.txt”. Non “devo bloccare i crawler AI”. È l’integrazione per gli operatori che già gestiscono un set di policy sui bot e devono capire cosa cambia con Web Bot Auth.

Cos’è davvero Web Bot Auth

Web Bot Auth è un profilo “in salsa bot” delle firme dei messaggi HTTP RFC 9421. Il bot firma ogni richiesta uscente con una chiave privata. Il sito recupera la chiave pubblica del bot da un URL .well-known/http-message-signatures-directory su un dominio controllato dal bot. Il sito verifica che la firma in arrivo sia stata prodotta dalla chiave privata corrispondente. Se sì, l’origine della richiesta è attestata criptograficamente. Se no, la richiesta è falsificata.

Tre nuovi header fanno il lavoro. Signature-Agent punta alla directory delle chiavi del bot. Signature-Input elenca cosa viene firmato più i metadati: keyid, timestamp created ed expires, algoritmo e la stringa letterale tag="web-bot-auth" che marca la firma come “bot” (non un altro uso dell’RFC 9421). Signature contiene i byte crittografici.

«Questo documento descrive un meccanismo per creare, codificare e verificare firme digitali o MAC sui componenti di un messaggio HTTP». — A. Backman, J. Richer, M. Sporny, RFC 9421 (HTTP Message Signatures, abstract)

Il profilo bot sopra l’RFC è ciò che rende questa soluzione Web Bot Auth e non “solo” firme di messaggi HTTP. La bozza IETF draft-meunier-web-bot-auth-architecture fissa le convenzioni: la stringa tag="web-bot-auth" nell’input, la forma dell’URL well-known, i componenti da coprire (al minimo @authority e signature-agent) e l’aspettativa che la directory sia cache-ata secondo il suo Cache-Control. Nulla di tutto ciò sta nell’RFC 9421 stesso. L’RFC è l’algebra. Web Bot Auth è il caso d’uso.

Perché UA + IP non basta più

Lo stack di verifica ha tre livelli, ognuno con un difetto noto. User-Agent è testo: chiunque può impostarlo. Il reverse DNS funziona per Googlebot ma è scomodo per i crawler più recenti instradati tramite infrastrutture generiche. Le allowlist IP sono fragili perché gli intervalli di uscita dei cloud cambiano senza preavviso.

Johannes Ullrich del SANS Internet Storm Center ha riassunto brutalmente il problema dello UA spoofing:

«Gli utenti hanno capito da tempo che impostare il proprio user agent su “Googlebot” può far superare alcuni paywall». — Johannes Ullrich, SANS Internet Storm Center, settembre 2025

Il lato allowlist IP ha un problema diverso ma correlato. Thibault Meunier e Mari Galicer di Cloudflare, che hanno portato la proposta Web Bot Auth all’IETF, lo hanno spiegato così nel post di maggio 2025: «le connessioni dal servizio di crawling potrebbero essere condivise da più utenti, ad esempio proxy di privacy e VPN, e questi intervalli, spesso gestiti dai provider cloud, cambiano nel tempo». Una allowlist corretta il lunedì può essere sbagliata il venerdì.

Il passaggio al traffico “agent” peggiora lo stack vecchio. Quando un crawler agisce per conto di un singolo utente all’interno di una chat, il profilo di origine si frammenta. Cloudflare ha evidenziato direttamente il cambio di scenario: «I bot non sono più diretti solo dai proprietari, ma anche dagli utenti finali che li fanno agire per loro».

La verifica crittografica è l’unico binario che sopravvive a tutti e tre i difetti legacy: non guarda l’IP sorgente, non si fida dello UA e non ha bisogno di lookup reverse DNS. Le interessa solo la chiave.

Com’è fatta una richiesta Googlebot firmata

Una richiesta firmata dall’agente di Google segue la forma documentata nelle reference Cloudflare e nella guida Google. Forma approssimativa, con keyid abbreviato:

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

Leggila da sinistra a destra. Signature-Agent dice dove prendere la chiave pubblica: g="https://agent.bot.goog" risolve in https://agent.bot.goog/.well-known/http-message-signatures-directory. Signature-Input descrive cosa viene attestato: qui il componente derivato @authority (host) e l’header signature-agent stesso, firmati al momento created e validi fino a expires. Il keyid è un thumbprint JWK che seleziona una specifica chiave nella directory. Signature contiene i byte della firma ed25519.

Semantica dei parametri, in tabella, perché è qui che molti operatori sbagliano al primo colpo:

Caveat esplicito di Google: «Non tutti gli user agent Google utilizzano Web Bot Auth». A maggio 2026 l’unico UA che firma in modo costante è Google-Agent, l’agente AI-browsing legato alle funzioni AI Mode. Googlebot, il crawler di indicizzazione che genera la maggior parte del traffico organico, non è ancora firmato. Regola di conseguenza.

Il flusso di verifica, end-to-end

Il percorso di verifica ha quattro passaggi, tutti leggeri. Gli elementi in movimento sono la cache della directory e la libreria dell’algoritmo, non la matematica.

Primo. Arriva la richiesta. Cerca l’header Signature-Agent. Se manca, la richiesta è non firmata e passi al percorso legacy (reverse DNS, UA, IP). Nel 2026 la maggior parte è ancora qui.

Secondo. Analizza Signature-Input. Estrai keyid, created, expires, alg e tag. Rigetta se tag non è letteralmente web-bot-auth. Rigetta se siamo oltre expires. Entrambe le verifiche avvengono prima di toccare la chiave.

Terzo. Recupera la directory di chiavi pubbliche all’URL in Signature-Agent. Rispetta il suo Cache-Control; Google lo imposta. Memorizza in cache (RAM o Redis), aggiorna alla scadenza, elimina le chiavi rimosse (rotazione). Estrai la chiave il cui thumbprint JWK combacia con keyid.

Quarto. Verifica la firma sui componenti elencati in Signature-Input. Se passa, hai attestato criptograficamente l’origine. Se fallisce, considera la richiesta falsificata.

La cache è l’errore tipico: rispetta Cache-Control. Non sovracache-are (una directory stantia accetta chiavi revocate) né sotto-cache-are (refetch per richiesta = latenza + abuso). Se la fetch fallisce con cache scaduta, ricadi sul percorso non firmato. Non bloccare su un miss transitorio.

Cosa cambia per le tue regole anti-bot AI

Questione centrale. Hai già regole. Il protocollo è cambiato. Che fai?

Buone notizie: le regole che bloccano “UA contiene GPTBot, ClaudeBot o PerplexityBot” restano valide. La richiesta porta ancora uno UA riconoscibile e un GPTBot falsificato stava già fingendo di essere il bot che volevi bloccare. Se blocchi anche il GPTBot legittimo firmato, è una scelta di policy già tua.

Notizie meno buone: le regole che consentono “UA contiene Googlebot” ora sono sotto-specificate. Uno spoofer con UA Googlebot passa ancora. Il fix non è riscriverle da zero (la quota firmata è troppo piccola), ma aggiungere un percorso parallelo: verifica la firma sul traffico Google firmato, tratta il resto non firmato con reverse DNS. Il team verified-bots di Cloudflare ha riassunto così il gap:

«I metodi attuali si basano su range IP (condivisi o mutevoli) e header user-agent (facilmente falsificabili). Hanno limiti evidenti.» — Cloudflare verified-bots team, luglio 2025

Il modello a due stack è la metafora giusta. Un ruleset gestisce il traffico firmato: verifica la firma, controlla keyid, valuta expires e instrada in base all’identità verificata. L’altro gestisce il traffico non firmato, con reverse DNS + UA + IP esattamente come oggi. Non eliminare le regole legacy. A metà 2026 la maggior parte del traffico Google reale passa ancora lì.

Verificare le firme all’origine (senza Cloudflare)

Se stai dietro Cloudflare, il lavoro è minimo. Cloudflare valida le firme all’edge ed espone il risultato via cf.verified_bot_category in WAF Custom/Transform Rules. La tua regola diventa “se cf.verified_bot_category è la categoria desiderata, instrada di conseguenza” e la crittografia è delegata.

Senza un CDN che verifichi, il lavoro tocca all’origine. Serve un piccolo middleware davanti a nginx o all’app. Intercetta le richieste con Signature-Agent, recupera la directory .well-known al primo avvistamento (poi in cache), verifica secondo RFC 9421 e imposta un header interno X-Verified-Bot che le tue regole downstream leggono.

Il team research di Cloudflare ha open-sourciato i pezzi su cloudflareresearch/web-bot-auth. Il crate Rust e il pacchetto TypeScript web-bot-auth contengono la logica; il repo offre plugin Caddy e Worker d’esempio. Non sono auditati (lo dice il README), ma la superficie è piccola e l’alternativa è implementare tu l’RFC 9421.

Consiglio pragmatico: su Cloudflare il percorso edge è ovvio. Fuori, installa il middleware, puntalo agli agent da verificare (oggi Google, domani altri) e leggi il suo header di trust nelle tue regole esistenti. In ogni caso, non infilare la verifica firma nel business code: tienila nel front-tier, auditabile e sostituibile.

Il fallback reverse-DNS non sparirà

Ripeto “non eliminare le regole legacy” perché la quota firmata è ancora bassa. A maggio 2026 Googlebot crawler di indicizzazione non firma. Solo l’agente AI-browsing Google-Agent firma. Per la maggior parte dei siti la quota AI-browsing è una cifra singola del traffico Google. Il crawler di indicizzazione che porta visibilità organica è non firmato oggi e probabilmente fino al 2027.

Google lo dice chiaramente. La stessa documentazione che introduce Web Bot Auth invita a «continuare ad affidarsi a indirizzi IP, reverse DNS e stringhe user-agent» insieme al nuovo protocollo. Non è una clausola di stile: è il modello operativo. Web Bot Auth è un binario; lo stack legacy l’altro. Corrono in parallelo, e nel 2026 lo stack legacy pesa di più.

Cadence di audit: ogni trimestre estrai un campione di traffico che dichiara Google, dividilo tra firmato e non e calcola la quota firmata. Quando supera il 30-40%, il percorso di verifica firma inizia a pesare. Quando supera il 70%, la regola UA Googlebot non firmata merita una review seria: gli spoofers si vedranno in quel bucket minoritario. Prima di quelle soglie, tieni entrambi i binari e considera quello criptografico come additivo.

Anti-pattern da evitare: non scrivere oggi una regola che blocchi il traffico Googlebot non firmato. Ti auto-deindicizzi in un ciclo di crawl.

Cosa fare effettivamente questo trimestre

Checklist in quattro punti, senza vendor.

Uno, inventaria le regole bot esistenti. Etichetta ognuna per ciò che verifica davvero: UA, reverse DNS, IP, firma. La maggior parte degli audit trova regole duplicate o stantie: pulisci prima di aggiungere.

Due, aggiungi il percorso di verifica firma. Su Cloudflare abilita la validazione verified-bots e crea una regola sul campo cf.verified_bot_category. All’origine installa il middleware WBA, puntalo a agent.bot.goog (e altri agent rilevanti) e fai esporre un header di trust leggibile dalle tue regole.

Tre, mantieni il percorso reverse-DNS per l’ampio pool non firmato di traffico Google. Non irrigidirlo, non sostituirlo: eseguilo in parallelo.

Quattro, pianifica l’audit trimestrale: quota firmata del traffico Google dichiarato, quota firmata degli agent AI, percentuale di spoofers intercettati dalla firma che sfuggivano alle regole legacy. I numeri si muovono lentamente nel 2026 e più velocemente nel 2027. La tua struttura di regole si deve muovere con loro.

Se il tuo team gestisce anche la policy crawler AI in senso ampio, il playbook sui crawler AI e la guida per disattivare il blocco AI-bot di Cloudflare sono letture complementari sul lato allow/block. Questo pezzo è sul lato identità.

Cosa NON risolve

Web Bot Auth riguarda l’identità, non l’autorizzazione. La firma attesta che la richiesta proviene da un bot specifico; non dice se quel bot può leggere l’URL. Un Google-Agent verificato può comunque scaricare contenuti a pagamento se le tue regole lo permettono. La firma dà fiducia sulla fonte; la policy resta tua.

Non influisce su robots.txt: un bot firmato che lo ignora resta un violatore. Se vuoi che l’agente AI-browsing salti la sezione a pagamento, glielo dici con robots e lo fai rispettare nelle regole.

E non decide per te tra routing AI-search e search tradizionale. Web Bot Auth dice “questo è davvero Google-Agent”. Se riceverà lo stesso contenuto di Googlebot o diverso è tua scelta. Il pezzo sull’ottimizzazione per Perplexity, ChatGPT Search e Google AI Mode copre quel lato routing.

Valutazione onesta: è un binario in uno stack a tre: firma per l’identità, reverse DNS per la verifica legacy, robots per l’autorizzazione. Il nuovo binario rinforza il primo. Gli operatori che vedo avere successo nel 2026 trattano tutti e tre come portanti.

Cadence di audit con l’adozione in crescita

La metrica da seguire 2026-2027 è la quota firmata del traffico che dichiara Google. Oggi, per la maggior parte dei siti, è a singola cifra. Quando supera il 30-40%, la verifica firma inizia a pesare nelle decisioni. Quando supera il 70%, la regola UA Googlebot non firmata merita una revisione seria.

Ripeti l’inventario ogni due trimestri e rileggi la documentazione crawler Google: è in evoluzione. La forma della directory e la lista dei componenti coperti sono i pezzi più soggetti a cambio. Due volte l’anno basta per restare avanti.

Per il contesto Googlebot di base, la nostra guida su cos’è Googlebot è il punto di partenza. Per il lato agent traffic, come costruire un sito agent-friendly spiega l’integrazione.

FAQ

Googlebot firma già le richieste? Non a metà 2026. Il rollout Web Bot Auth attuale copre l’agente AI-browsing Google-Agent. Googlebot, il crawler di indicizzazione che porta traffico organico, si autentica ancora via reverse DNS e range IP documentati. Gestiscili separatamente.

Web Bot Auth sostituisce robots.txt? No. Rispondono a domande diverse. Web Bot Auth attesta “questa richiesta è davvero di Google”. Robots.txt dichiara “questo URL è o non è consentito alla scansione”. Entrambi restano validi, e un bot firmato che ignora robots resta un violatore.

Quale algoritmo di firma usa Web Bot Auth? L’RFC 9421 ne supporta diversi. Gli esempi Cloudflare e la directory Google usano ed25519 (EdDSA su Curve25519). Il tuo verificatore deve implementarlo; in Go, Rust, Node, Python è una singola call di libreria.

Cosa succede se la directory di chiavi pubbliche di Google è irraggiungibile? Cache-i la directory secondo il suo Cache-Control. Se la cache è fresca continui a verificare. Se è scaduta e la fetch fallisce, ricadi sul percorso non firmato (reverse DNS, UA, IP). Non bloccare su un miss transitorio: rischi di auto-deindicizzarti se Google ha un hiccup.

Devo dismettere la verifica reverse-DNS per Googlebot? Non ancora, probabilmente non nel 2026. La quota firmata è troppo bassa. Il reverse DNS è la tua vera difesa contro gli UA spoof Googlebot, perché Googlebot non firma. Rivaluta ogni trimestre con la crescita della quota firmata. Il momento giusto per irrigidire il percorso non firmato è quando diventa minoritario, non quando è la maggioranza.