l nuovo pannello Cloudflare divide i crawler in tre. Una guida completa per chi fa digital e SEO.
Per quasi trent’anni il crawling è stato una cosa sola. Un bot passava sul sito, indicizzava le pagine, e in cambio quel sito otteneva visibilità e traffico. Un patto implicito che ha retto per tutta l’era dei motori di ricerca. Adesso quel patto non tiene più, e Cloudflare lo mette nero su bianco nel post “Your site, your rules: new AI traffic options for all customers”.
Il punto è semplice. Oggi un crawler può visitare una pagina per almeno tre motivi diversi: metterla nell’indice di un motore di ricerca, leggerla al volo per rispondere a un utente, oppure raccoglierla per addestrare un modello. Tre finalità differenti, tre impatti differenti sul business di chi produce contenuti. Fino a ieri li trattavamo tutti allo stesso modo.
Cloudflare, che oggi copre oltre il 20% dei domini web, cambia la logica di fondo. La configurazione non è più “faccio passare i bot o li blocco”. Adesso è “faccio passare i bot per fare cosa”. [Blog Cloudflare]
La nuova tassonomia: Search, Agent, Training
Cloudflare smette di parlare genericamente di “bot AI” e introduce tre categorie configurabili, con default diversi. Le definizioni che seguono sono quelle ufficiali del blog.
🔍
Search
Comportamenti che raccolgono o indicizzano i contenuti per costruire un database del sito, da interrogare successivamente quando arriva una query. Cloudflare specifica che i proprietari dei siti dovrebbero aspettarsi traffico di referral o compensi equivalenti in cambio.
🤖
Agent
Automazioni che agiscono in tempo reale per conto di una persona: chat fetch bot come ChatGPT-User, e browser-use agent come Gemini o Claude che pilotano Chrome. Visitano l’applicazione per completare un compito adesso, spesso con un umano che sta aspettando dall’altra parte.
🧠
Training
Un crawler che ingerisce i contenuti per addestrare o fare fine-tuning di un modello. I dati vengono assorbiti dentro l’architettura del modello, in modo permanente, per migliorarne le capacità. Il contenuto non torna indietro: diventa parte del modello.
* I nuovi default per Training e Agent si applicano solo alle pagine che mostrano annunci pubblicitari. Search resta consentito di default ovunque.
La logica dichiarata da Cloudflare è coerente: se una pagina mostra pubblicità, significa che il proprietario voleva una persona lì, davanti agli annunci. Su quelle pagine l’attenzione umana è il fine monetizzabile, quindi i bot che rischiano di sostituirla (Training e Agent) vengono tenuti lontano. Search invece continua a portare visitatori umani, e per questo resta consentito.
Al di là dei singoli default, il cambio concettuale è più profondo. Essere indicizzati e rendere i propri contenuti disponibili all’AI diventano due autorizzazioni distinte. Non più un interruttore acceso/spento, ma tre leve indipendenti.
Due meccanismi, due logiche: Content Signals e AI Crawl Control
Qui c’è una precisazione che nel post di Cloudflare passa un po’ in sordina, ma che chi lavora sui siti dei clienti deve tenere ben presente. Le nuove opzioni di Cloudflare non lavorano tutte allo stesso modo. Ci sono due meccanismi distinti, con effetti tecnici diversi.
1. Content Signals nel robots.txt
Quando un cliente attiva questa opzione, Cloudflare scrive nel robots.txt del sito una serie di direttive: search=yes, ai-train=no, use=reference, oltre alle classiche Disallow per gli user-agent AI noti (GPTBot, Google-Extended, ClaudeBot, PerplexityBot e via elencando).
Questo è un livello dichiarativo. Cloudflare dice al bot “questo sito non vuole essere usato per training”. Se il bot è educato e rispetta il robots.txt, si ferma. Se decide di ignorarlo, o se si presenta con uno user-agent diverso da quelli listati, la richiesta arriva regolarmente al server. Zero enforcement tecnico.
2. AI Crawl Control / Block AI Bots
Qui Cloudflare non chiede gentilezza, blocca a livello di edge, cioè sui propri server, prima che la richiesta tocchi l’hosting. Cloudflare identifica il bot tramite fingerprint, verifica del reverse DNS, range di IP, signature comportamentali, non solo user-agent.
Se il bot è classificato come Training e la policy lo blocca, riceve un 403 e non passa. Il bot non decide niente, viene fermato da Cloudflare. Questo è enforcement tecnico vero, a livello WAF.
Sono due strumenti che risolvono problemi diversi. Il robots.txt gestito è utile per comunicare in modo pulito le preferenze e per contribuire a uno standard emergente. AI Crawl Control è utile per bloccare davvero i crawler AI che il robots.txt da solo non ferma.
Un audit fatto bene deve verificare quale dei due meccanismi è attivo su un dominio, perché la scelta “block training” tramite Content Signals e la scelta “block training” tramite AI Crawl Control producono outcome molto diversi.
Il nodo Googlebot e i “crawler multi-purpose”
Cloudflare, nel suo post, usa un’espressione che merita di essere smontata: parla di “multi-purpose crawler” e cita Googlebot, BingBot e Applebot come esempi. Dice che, siccome fanno più cose insieme (Search e Training), chi blocca il Training di fatto blocca anche l’indicizzazione, perché il crawler è lo stesso.
Detto così, però, è una semplificazione. E per i big che vengono citati, oggi, non corrisponde alla realtà tecnica.
Google, qualche anno fa, ha già separato le cose. Googlebot resta il crawler per la Search, quello che indicizza le pagine come sempre. Google-Extended è un token separato, dedicato all’uso AI, che permette a un sito di dire “non usare i miei contenuti per addestrare Gemini o per Vertex AI”. Basta scrivere nel robots.txt una regola Disallow sotto User-agent: Google-Extended per bloccare l’uso AI mantenendo intatta l’indicizzazione. Sono due leve separate, gestite direttamente da Google.
Apple ha fatto la stessa cosa. Applebot è il crawler per la Search, Applebot-Extended è il canale dedicato all’addestramento di Apple Intelligence. Bing ha un meccanismo analogo, un po’ meno pulito ma esiste.
La conseguenza pratica è importante. Se un sito su Cloudflare attiva “block Training” tramite AI Crawl Control (quindi enforcement WAF vero, non solo robots.txt), Cloudflare bloccherà Googlebot dal server, anche se Google, lasciato libero, avrebbe rispettato Google-Extended senza toccare l’indicizzazione. In quel caso il “blocco della Search” è un effetto collaterale della policy Cloudflare, non un comportamento imposto da Google.
Ecco perché, in un audit ben fatto, il primo livello di lavoro va fatto sul robots.txt del sito, gestendo Google-Extended, Applebot-Extended e i vari token AI-only degli operatori. Solo a valle di questo si valuta se serve anche il livello WAF di Cloudflare, e con quale configurazione.
Il valore vero delle funzioni AI Crawl Control, allora, non sta nel bloccare Googlebot (che si può gestire meglio a monte con il robots.txt). Sta nel bloccare i crawler AI che non rispettano il robots.txt, o quelli che si mascherano con user-agent generici, o quelli minori che non hanno mai pubblicato un token separato. Lì il robots.txt non basta, e l’enforcement WAF di Cloudflare fa una differenza reale.
Cosa succede e quando
ORA
Fino al 15 set
15 settembre 2026
Post 15 set
Prima e Dopo, in una tabella
Cosa significa per chi fa SEO
Questa non è una notizia da addetti ai bot. Riguarda chiunque produca contenuti, gestisca un sito e viva di traffico organico. I punti operativi principali sono cinque.
1. “Crawler” da solo non è più una categoria utile
Quando un cliente chiede “i bot possono accedere al mio sito?”, la risposta d’ora in poi è un’altra domanda: quale bot, e per fare cosa. Per chi fa SEO significa aggiornare il vocabolario che si usa nei report e nelle call con i clienti, perché la distinzione fra le tre finalità sta per diventare centrale.
2. Il robots.txt fatto bene è il primo livello di controllo
Prima ancora di toccare le impostazioni Cloudflare, va fatto un lavoro pulito sul robots.txt. Google-Extended, Applebot-Extended e i token AI-only dei vari operatori permettono di bloccare l’uso AI mantenendo intatta la Search, in modo nativo, senza passare da alcun edge. È il livello di controllo più preciso perché parla la lingua degli operatori stessi.
3. Cloudflare è il secondo livello, non il primo
AI Crawl Control serve dove il robots.txt non basta: crawler che non lo rispettano, user-agent generici, bot minori che non hanno mai dichiarato un token AI-only. Lì l’enforcement WAF è utile davvero. Su Googlebot, BingBot e Applebot, invece, la logica prudenziale di Cloudflare può bloccare più di quanto sarebbe necessario. Va valutato caso per caso.
4. L’opt-out va valutato con attenzione
Per i clienti su Cloudflare che vogliono bloccare l’uso AI ma mantenere piena indicizzazione, l’opt-out dai nuovi default sui crawler multi-purpose è probabilmente la scelta più equilibrata, se si è già lavorato bene sul robots.txt a monte. Non agire equivale ad accettare i default, che sono più restrittivi.
5. Il tema geo entra nell’equazione
Molte ricerche locali passano attraverso contenuti che i motori, ormai AI-first, leggono in tempo reale: schede attività, orari, disponibilità, recensioni. Se il traffico Agent viene bloccato, l’accesso in tempo reale a queste informazioni può ridursi. Un tema che tocca direttamente i clienti con presenza locale.
Checklist Operativa
Per i clienti Fattoretto Agency e per i colleghi SEO
Cosa resta, oltre la notizia
Comunque evolva la vicenda nei dettagli tecnici, il messaggio di fondo è già leggibile. Nei prossimi anni parlare genericamente di “crawler” non basterà più. Come già si distingue fra organico e a pagamento, fra desktop e mobile, fra search e social, ora andrà distinto fra indicizzazione e utilizzo AI. Sono due cose diverse, con valori economici diversi e con impatti diversi sui contenuti.
Cloudflare non ha introdotto solo dei nuovi controlli. Ha spostato il vocabolario con cui parliamo del rapporto fra contenuti e automazione. E il vocabolario, come si sa, non è mai neutro.
Per chi produce contenuti, e per chi come noi in Fattoretto Agency lavora perché quei contenuti raggiungano le persone giuste, è un passaggio da presidiare. Il vecchio modello era lineare: fatti indicizzare, ricevi traffico. Il nuovo è articolato: decidi chi indicizza, decidi chi legge i tuoi contenuti in tempo reale per rispondere agli utenti, decidi chi ci addestra i propri modelli. Tre decisioni distinte, finalmente separabili. E per gestirle bene, i due livelli (robots.txt lato operatore, edge WAF lato Cloudflare) vanno letti insieme, non confusi.
Fonti e approfondimenti
- Your site, your rules: new AI traffic options for all customers, Cloudflare Blog (annuncio ufficiale, 1 luglio 2026)
- Cloudflare BotBase, database ufficiale dei bot tracciati
- Manage AI bot traffic, documentazione tecnica Cloudflare
- Content Signals, il progetto aperto per esprimere preferenze sul riutilizzo dei contenuti
- Google-Extended, documentazione ufficiale Google sui crawler
- Applebot-Extended, documentazione ufficiale Apple
- Cloudflare bloccherà i crawler AI misti, macitynet (analisi in italiano)
