Cloudflare e il managed robots.txt: governare i crawler AI da publisher italiano

C'è un dato che dovrebbe far riflettere ogni publisher, e che fotografa meglio di mille parole cosa è cambiato. Secondo le misurazioni di Cloudflare di giugno 2025, per ogni visita che rimanda a un sito, il crawler di Google ne fa circa 14, quello di OpenAI ne fa 1.700, e quello di Anthropic ne fa 73.000. Il patto storico del web, "tu mi dai il contenuto, io ti mando traffico", su cui si è retto il rapporto tra editori e motori di ricerca, nel caso dei crawler AI è diventato radicalmente asimmetrico: il contenuto viene consumato per rispondere agli utenti dentro le app, e il traffico di ritorno è quasi nullo. Davanti a questo, la reazione istintiva di molti è bloccare tutto. Ma bloccare tutto è quasi sempre l'errore sbagliato, perché ti rende invisibile proprio agli assistant AI da cui vorresti essere citato. La questione vera, per un publisher, non è bloccare i crawler AI, è governarli: distinguere chi consuma per addestrare modelli da chi recupera per citarti, e decidere con precisione cosa concedere a chi. In questo articolo spiego gli strumenti che Cloudflare mette a disposizione per farlo, l'errore di configurazione che svuota la tua visibilità senza che te ne accorga, e come decidere cosa bloccare in base ai tuoi obiettivi, non alla paura.

Perché governare i crawler AI, e non solo bloccarli?

Perché "crawler AI" non è una categoria sola, e trattarla come tale fa danni in entrambe le direzioni. La distinzione fondamentale, che Cloudflare stessa rende esplicita, è tra bot di addestramento e bot di ricerca. I primi, come GPTBot di OpenAI, ClaudeBot di Anthropic o CCBot, raccolgono il tuo contenuto per addestrare i modelli: è il loro lavoro che alimenta l'asimmetria 73.000:1, e per molti publisher è ciò che si vuole limitare, perché significa cedere il proprio valore senza contropartita. I secondi, come OAI-SearchBot, Claude-SearchBot o PerplexityBot, recuperano il contenuto in tempo reale per rispondere a una domanda di un utente citando la fonte: sono il canale attraverso cui finisci dentro le risposte di ChatGPT, Perplexity o Google, ed è quasi sempre traffico e autorevolezza che vuoi, non che vuoi respingere.

Confondere i due significa fare l'errore più costoso possibile: bloccare indiscriminatamente i crawler AI spegne anche i bot di ricerca, e il risultato è che il tuo sito sparisce dalle risposte degli assistant proprio mentre i tuoi concorrenti ci compaiono. È l'opposto di quello che un publisher accorto vuole nel 2026, quando essere citati da un assistant AI è un canale di visibilità che cresce mentre il traffico organico tradizionale si comprime.

La domanda giusta non è "blocco i crawler AI?", è "blocco chi addestra e lascio passare chi cita?". Il blocco indiscriminato è la mossa che ti toglie il controllo invece di dartelo: spegne il canale che ti porta visibilità insieme a quello che ti svuota.

Le tassonomie dei bot vanno conosciute nel dettaglio, perché le sfumature contano. Anthropic distingue tre user-agent: ClaudeBot per l'addestramento, Claude-SearchBot per l'indicizzazione di ricerca, Claude-User per il recupero su richiesta diretta dell'utente. OpenAI ne ha quattro, tra cui GPTBot per il training e OAI-SearchBot per la ricerca. Controllarli separatamente è possibile, ed è esattamente ciò che permette di governare invece di subire.

Cosa offre Cloudflare per controllare i crawler?

Offre una serie di strumenti che vanno dal segnalare la propria volontà fino a far pagare l'accesso, e conoscerli permette di scegliere il livello di controllo giusto. Il punto di partenza, gratuito su tutti i piani, è il managed robots.txt: Cloudflare mantiene e aggiorna automaticamente le direttive contro i principali bot di addestramento AI, segnalando a Google-Extended e Applebot-Extended di non usare il contenuto per il training pur preservando l'accesso a Googlebot per la SEO. Se hai già un tuo robots.txt, le direttive gestite vengono anteposte senza cancellare le tue regole. Risolve il divario, documentato da Cloudflare, tra chi vorrebbe controllare l'uso AI del proprio contenuto e chi sa configurarlo davvero: secondo le loro misurazioni, solo il 37% dei diecimila domini più importanti ha un file robots.txt.

Dal cosiddetto "Content Independence Day" del 1 luglio 2025, Cloudflare ha aggiunto misure più incisive, documentate sul loro blog ufficiale. La prima è il blocco di default: i nuovi domini che passano da Cloudflare bloccano i crawler AI in partenza, ribaltando la logica da opt-out a opt-in. La seconda, più radicale, è il Pay Per Crawl: il publisher imposta un prezzo per ogni scansione, e il crawler che non paga riceve un HTTP 402 Payment Required, dovendo per giunta dichiarare lo scopo della richiesta. È l'infrastruttura di un nuovo patto economico per sostituire quello rotto, e ne ho scritto il versante implementativo nell'articolo su come monetizzare i crawler AI con HTTP 402.

C'è poi la Content Signals Policy, introdotta a settembre 2025: una sintassi leggibile dalle macchine, espressa nel robots.txt e come header di risposta, che separa i tre consensi distinti. Ha questa forma:

# robots.txt
Content-Signal: ai-train=no, search=yes, ai-input=yes
User-agent: *
Allow: /

Con una riga dichiari che non vuoi essere usato per l'addestramento, ma sì per la ricerca e sì come input per il grounding di un assistant. Non è un enforcement tecnico, è una dichiarazione di preferenza, ma rende esplicita e documentata la tua volontà, il che ha un valore anche sul piano della tracciabilità legale.

C'è anche un'opzione più chirurgica per chi monetizza tramite pubblicità: il blocco selettivo basato sulla monetizzazione, che impedisce ai bot di addestramento di accedere solo alle pagine che contengono annunci, lasciando invece libero l'accesso alle sezioni non monetizzate come la documentazione o le pagine di supporto. La logica è elegante: proteggi il contenuto che genera ricavi senza chiudere la porta a tutto il resto, e Cloudflare rileva le pagine con pubblicità scansionando l'HTML alla ricerca dei pattern degli ad server. È un esempio di quanto la governance possa essere granulare quando si smette di ragionare per blocco totale e si inizia a ragionare per obiettivo. Tutti questi controlli, insieme alle analitiche sui crawler e alle regole per singolo bot, si gestiscono dalla dashboard AI Crawl Control, di cui le funzioni complete richiedono i piani a pagamento.

Vale la pena inquadrare tutto questo nel quadro economico più ampio, perché spiega perché Cloudflare e altri stanno costruendo questa infrastruttura adesso. Il rapporto crawl-su-visite di 73.000 a 1 non è sostenibile: significa che un'azienda come Anthropic preleva enormi quantità di contenuto restituendo quasi nulla in cambio. Un sistema così non regge nel tempo senza una qualche forma di compensazione ai creatori, ed è esattamente il vuoto che il Pay Per Crawl prova a riempire, trasformando l'accesso da gratuito e unilaterale a negoziato e pagato. Per un publisher, capire questo significa non vedere il blocco come un atto difensivo isolato, ma come la propria posizione in una rinegoziazione del patto fondamentale del web, dove per la prima volta si può mettere un prezzo a ciò che prima era preso e basta. Se stai costruendo un'architettura di pubblicazione che deve restare visibile agli assistant senza farsi svuotare, nel mio hub dedicato all'AI per le aziende raccolgo gli articoli sul tema con la metodologia che applico, dichiarata.

Qual è l'errore che ti rende invisibile a ChatGPT?

È lasciare che una protezione anti-bot generica sfidi silenziosamente i bot di ricerca legittimi, e accorgersene solo quando il traffico dagli assistant è già sparito. Il caso più insidioso è la modalità anti-bot aggressiva: una funzione come il Bot Fight Mode di Cloudflare, pensata per fermare gli scraper malevoli, può presentare un CAPTCHA o una sfida JavaScript anche a OAI-SearchBot e PerplexityBot, che non sono in grado di risolverli. Il risultato è che i bot di ricerca vengono respinti, e il tuo sito diventa invisibile a ChatGPT Search e Perplexity senza che nessuna impostazione dica esplicitamente "blocca gli assistant AI". È un effetto collaterale, non una scelta, ed è proprio per questo che è pericoloso: nessuno lo decide, ma il danno è reale.

La contromisura è creare regole esplicite di esenzione per gli user-agent dei bot di ricerca verificati, così che le protezioni anti-scraper non li tocchino. Un altro caso particolare è Googlebot: lo stesso user-agent serve sia l'indicizzazione SEO sia l'addestramento AI di Google, quindi bloccarlo distrugge la SEO. Per limitare solo l'uso AI di Google senza toccare il ranking, la direttiva da usare è Google-Extended, non Googlebot. Confondere i due è un errore che si paga con il crollo della visibilità organica, e succede più spesso di quanto si pensi a chi configura il blocco con la mano pesante.

robots.txt basta a proteggere il contenuto?

No, e crederlo è un fraintendimento tecnico con conseguenze pratiche. Il robots.txt è una direttiva volontaria, definita dallo standard RFC 9309: chiede al crawler di rispettare certe regole, ma non impone nulla a livello tecnico. Un crawler ben educato lo rispetta; uno malevolo lo ignora e basta. Per giunta, alcuni bot legittimi attivati dall'utente, come ChatGPT-User quando una persona chiede esplicitamente di leggere una pagina, possono per design non rispettare il robots.txt, perché trattano la richiesta come un'azione dell'utente e non come un crawl automatico.

Questo significa che, se hai contenuto che davvero non deve essere letto da nessun bot, il robots.txt non è la difesa giusta: serve un controllo di accesso vero, un'autenticazione, una protezione a livello di rete. Il robots.txt governa il comportamento dei crawler collaborativi, che sono la maggioranza di quelli che contano, ma non è una serratura. La difesa di un asset critico è l'autenticazione zero-trust, il monitoraggio dei log per tentativi di accesso evasivi, e il blocco a livello di edge, non una riga in un file di testo che chiede cortesemente di non entrare. Per i contenuti che invece vuoi servire in modo efficiente agli agent che li richiedono legittimamente, la strada è la content negotiation, di cui ho scritto in dettaglio nell'articolo su come servire markdown agli agent senza Cloudflare.

Bloccare i crawler AI è un obbligo di legge?

No, ed è importante dirlo con chiarezza per non vendere paura travestita da compliance. Nessuna norma o provvedimento qualifica oggi il blocco dei crawler AI come un obbligo, per esempio ai sensi del GDPR. Si può argomentare che applicare controlli sull'accesso dei crawler sia una misura tecnica appropriata quando il sito contiene dati personali o segreti industriali, e in un'analisi di rischio è una tesi difendibile. Ma è posizionamento, una scelta di prudenza, non un requisito normativo accertato. Chi ti vende il blocco dei crawler come "obbligo di legge" sta usando la leva sbagliata, e va corretto: la decisione di governare i crawler è strategica e di tutela del valore, non un adempimento.

Questa distinzione conta perché orienta la decisione nella direzione giusta. Se la trattassi come un obbligo, faresti il minimo per essere "conforme". Trattandola per quello che è, una scelta strategica su come proteggere e valorizzare il tuo contenuto, la affronti con la lente giusta: cosa voglio concedere, a chi, e in cambio di cosa.

Come decido cosa bloccare, in pratica?

Si decide partendo dagli obiettivi, non dalla tecnologia, e la scelta cambia radicalmente a seconda di cosa il contenuto deve fare per te. Se sei un publisher che vive di pubblicità, vuoi quasi certamente limitare i bot di addestramento, che consumano senza ricambiare, e tenere aperti i bot di ricerca, che ti portano citazioni e visibilità: il managed robots.txt più, se vuoi spingerti oltre, il Pay Per Crawl sono gli strumenti giusti. Se sei un e-commerce con ambizioni di essere trovato dagli assistant, blocchi i bot di addestramento per non alimentare i concorrenti col tuo catalogo, ma lasci passare i bot di ricerca per essere consigliato dentro ChatGPT e Perplexity.

Se hai documentazione tecnica pubblica e vuoi che gli agent di coding la consumino, apri l'accesso ai bot di ricerca e valuti la content negotiation. E se hai asset davvero proprietari e critici, non ti affidi al robots.txt ma metti un'autenticazione vera e monitori i log. Il filo che lega tutti gli scenari è che la scelta nasce dal tradeoff tra visibilità e controllo: più apri, più sei visibile agli assistant ma meno controlli l'uso del tuo contenuto; più chiudi, più proteggi il valore ma più rischi di sparire dalle risposte AI. Non esiste la configurazione giusta in assoluto, esiste quella giusta per i tuoi obiettivi, e governare i crawler significa esattamente posizionarsi consapevolmente su quel tradeoff invece di subirlo con un blocco indiscriminato o un'apertura inconsapevole. Se vuoi impostare questa governance sul tuo sito, distinguendo bot per bot cosa concedere e cosa no senza perdere la visibilità che conta, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ragioniamo sul tuo caso concreto invece che su una regola generica.