Cloudflare Bot Preference Sync cambia il modo in cui un sito può coordinare le proprie preferenze sui crawler AI con il file robots.txt.
La funzione nasce per risolvere un problema sempre più concreto: un sito può dichiarare una determinata policy nel robots.txt e, nello stesso tempo, applicarne una diversa attraverso Cloudflare.
Con Bot Preference Sync le due configurazioni possono essere sincronizzate.
Cloudflare ha annunciato la funzione il 21 agosto 2026 nel post ufficiale Say it once: introducing Bot Preference Sync, spiegando che le preferenze configurate per tre categorie di traffico — Search, Agent e Training — possono essere riflesse automaticamente nel robots.txt servito dal dominio.
La funzione è disponibile per i clienti Cloudflare dal piano Free fino all’Enterprise.
Questo non significa però che robots.txt e blocco tecnico siano diventati la stessa cosa.
È proprio questa distinzione che bisogna capire prima di attivare la funzione.
Cos’è Cloudflare Bot Preference Sync
Bot Preference Sync è una funzione che mantiene il contenuto del robots.txt coerente con le preferenze configurate per i crawler AI nella zona Cloudflare.
L’idea di fondo è semplice.
Supponiamo di decidere che i crawler utilizzati per la ricerca possano accedere al sito, mentre non vogliamo consentire l’utilizzo dei contenuti per il training.
Senza sincronizzazione potremmo avere:
robots.txt → una determinata policy
e contemporaneamente:
Cloudflare → una policy differente
Bot Preference Sync cerca di eliminare questa divergenza.
Quando è attivo, Cloudflare può servire direttive robots.txt derivate dalle impostazioni configurate per i bot AI.
Il risultato è un modello più simile a:
decisione → policy Cloudflare → robots.txt coerente
anziché mantenere manualmente due configurazioni indipendenti.
Cloudflare descrive esplicitamente Bot Preference Sync come uno strumento che mantiene allineate le preferenze dichiarate nel robots.txt con le regole applicate a livello di zona.
Search, Agent e Training: perché Cloudflare distingue i crawler AI
Uno degli aspetti più interessanti di Bot Preference Sync è che Cloudflare non tratta più genericamente tutto il traffico AI come una singola categoria.
Distingue tre possibili utilizzi.
| Categoria | Funzione |
|---|---|
| Search | crawler utilizzati per ricerca e discovery |
| Agent | bot che accedono ai contenuti per svolgere attività richieste da un utente |
| Training | crawler che raccolgono contenuti destinati all’addestramento dei modelli |
La distinzione è importante perché un proprietario potrebbe avere obiettivi diversi.
Potrebbe voler configurare:
Search → Allow
per continuare a essere scoperto;
Agent → Allow
per permettere agli agenti di utilizzare il sito durante attività richieste dagli utenti;
Training → Disallow
per esprimere invece una preferenza contraria all’utilizzo dei contenuti per addestrare modelli.
Con Cloudflare Bot Preference Sync, questa distinzione tra Search, Agent e Training diventa operativa anche nel modo in cui le preferenze vengono riflesse nel robots.txt.
Non siamo quindi più davanti alla scelta binaria:
AI sì / AI no.
La decisione può dipendere dallo scopo per cui il crawler sta richiedendo il contenuto.
Cloudflare ha introdotto questa separazione proprio per consentire ai proprietari dei siti di esprimere preferenze differenti in base all’utilizzo del contenuto.
Cosa fa Bot Preference Sync al tuo robots.txt
Questo è il punto operativo più importante.
Se il sito possiede già un robots.txt, Cloudflare afferma che il contenuto generato da Bot Preference Sync viene anteposto a quello esistente.
Non dovrebbe quindi cancellare le direttive già presenti.
Quando Cloudflare Bot Preference Sync è attivo, il robots.txt pubblico può quindi includere direttive generate da Cloudflare prima delle regole già presenti sull’origin.
Il file può assumere concettualmente questa struttura:
# BEGIN Cloudflare Bot Preference Sync User-agent: ... Disallow: / # END Cloudflare Bot Preference Sync # regole robots.txt già presenti sul sito
L’esempio è volutamente semplificato.
Non conviene copiare manualmente una lista statica di user-agent pensando di replicare il comportamento della funzione.
Cloudflare collega infatti Bot Preference Sync al proprio sistema di classificazione dei crawler e può aggiornare nel tempo i bot associati alle diverse categorie.
Questo produce una conseguenza importante.
Il robots.txt che viene effettivamente servito agli utenti e ai crawler può non corrispondere più esattamente al file conservato sul server origin.
Per verificare la configurazione reale bisogna quindi osservare la risposta pubblica del dominio, non soltanto aprire il file presente nell’hosting.
Bot Preference Sync non trasforma robots.txt in un firewall
Qui è facile fare confusione.
Una direttiva Disallow in robots.txt esprime una regola destinata ai crawler che rispettano il Robots Exclusion Protocol.
Non è una barriera di sicurezza.
Un crawler non cooperativo può comunque tentare di richiedere la risorsa.
Cloudflare può invece applicare controlli a livello edge attraverso le proprie funzionalità di bot management.
Sono due livelli differenti:
| Livello | Cosa fa |
|---|---|
| robots.txt | comunica una preferenza o una regola al crawler |
| Cloudflare edge | può applicare tecnicamente una policy alla richiesta |
Bot Preference Sync serve a rendere più coerenti questi due livelli.
Non bisogna quindi interpretarlo come una nuova capacità di robots.txt di impedire fisicamente l’accesso.
Questo principio vale anche fuori da Cloudflare.
Nella guida Creativemotions dedicata a robots.txt viene già distinta la gestione del crawling da quella dell’indicizzazione e dagli altri controlli tecnici necessari in scenari differenti.
Cosa succede se hai già un robots.txt personalizzato
In un sito semplice la sincronizzazione può ridurre il lavoro manuale.
In un’infrastruttura più complessa bisogna invece verificare le interazioni.
Cloudflare dichiara che il proprio blocco viene aggiunto prima delle regole già esistenti, mantenendo il contenuto originario.
Questo non significa però che qualsiasi configurazione complessa venga automaticamente compresa.
Bot Preference Sync lavora sulle decisioni definite per categorie.
Se hai eccezioni specifiche per singoli crawler, accordi particolari, regole WAF personalizzate o logiche differenti per determinate aree del sito, la sincronizzazione automatica potrebbe non rappresentare l’intera policy.
Cloudflare chiarisce nel proprio annuncio ufficiale di Bot Preference Sync che la funzione non legge direttamente le singole custom rule con logiche più complesse.
In questi casi la domanda corretta non è:
Posso attivare Bot Preference Sync?
ma:
La policy generata rappresenta davvero la configurazione che voglio comunicare ai crawler?
Se la risposta è no, mantenere il controllo manuale può essere più appropriato.
Consentire Search ma impedire Training
È probabilmente uno degli scenari più interessanti per editori e proprietari di siti.
L’obiettivo è:
essere scoperti senza concedere automaticamente lo stesso trattamento a qualsiasi utilizzo AI del contenuto.
Cloudflare sta cercando di rappresentare tecnicamente questa distinzione attraverso le categorie Search, Agent e Training.
Per Training, la scelta Disallow può essere riflessa nel robots.txt.
Il punto da non semplificare è che la stessa organizzazione può utilizzare crawler con più funzioni.
Cloudflare parla esplicitamente di mixed-use crawlers, cioè bot che possono combinare ricerca, utilizzo agentico e training sotto lo stesso user-agent.
Per questi casi Cloudflare lega il comportamento dei crawler a criteri di trasparenza e alla propria classificazione dei bot.
La qualità del sistema dipende inevitabilmente anche dalla corretta identificazione dei crawler e dal loro comportamento.
Per questo una policy AI non dovrebbe essere progettata soltanto leggendo il nome dello user-agent.
Bisogna ragionare sullo scopo dell’accesso.
Bloccare Training significa perdere visibilità nella ricerca?
Non è corretto trasformare questa domanda in un sì o un no universale.
Dipende dal crawler e dal modo in cui l’operatore separa ricerca, training e altri utilizzi.
Cloudflare sta cercando esplicitamente di permettere una configurazione nella quale un proprietario possa dichiarare:
Search consentito
e:
Training non consentito.
Nell’annuncio di Bot Preference Sync Cloudflare spiega inoltre che, per i crawler che soddisfano determinati criteri di trasparenza, una preferenza no-training può coesistere con l’accesso necessario per la ricerca.
Questo è però il modello dichiarato da Cloudflare, non una garanzia universale valida per qualsiasi motore AI.
Quando la visibilità organica è importante, conviene verificare singolarmente i crawler che producono traffico o discovery rilevanti.
Bot Preference Sync e Googlebot non sono la stessa questione
Un altro errore sarebbe pensare che qualsiasi decisione relativa ai bot AI debba essere automaticamente applicata a Googlebot.
La SEO tradizionale continua a dipendere dalla possibilità di Google di scansionare le risorse necessarie.
Google documenta inoltre che le proprie funzionalità AI nella Ricerca continuano a utilizzare le infrastrutture fondamentali di Search.
Non serve quindi creare una versione separata del sito per AI Overviews o AI Mode.
Su Creativemotions il rapporto tra crawling, ricerca e visibilità AI viene approfondito anche nella guida all’Answer Engine Optimization.
Prima di bloccare una categoria è quindi essenziale capire quali crawler ne fanno parte e quale funzione svolgono.
La regola prudente è:
non bloccare qualcosa soltanto perché contiene l’etichetta “AI”.
Prima identifica cosa perderesti.
Come verificare se Cloudflare sta modificando robots.txt
Dopo l’attivazione non basta controllare il file nell’hosting.
Apri direttamente:
https://tuodominio.it/robots.txt
e osserva la risposta effettivamente servita.
Se Bot Preference Sync sta intervenendo, cerca i marker relativi al blocco gestito da Cloudflare.
Poi confronta tre livelli:
- configurazione AI bot nella dashboard Cloudflare;
robots.txteffettivamente restituito dal dominio;- eventuali custom rule, WAF o bot rule applicate all’edge.
Devono raccontare la stessa policy.
Se il robots.txt dichiara un blocco che l’edge non applica, oppure Cloudflare blocca un crawler che il file sembra consentire, hai ancora una divergenza da investigare.
Per siti WordPress dietro Cloudflare questo controllo va aggiunto alle verifiche normalmente effettuate su CDN, DNS e sicurezza descritte nella guida come configurare Cloudflare per WordPress.
Quando conviene usare Bot Preference Sync
La funzione è particolarmente interessante quando vuoi una policy relativamente uniforme per categoria.
Per esempio:
- consentire Search;
- consentire Agent;
- non consentire Training;
- evitare di mantenere manualmente una lista di crawler che cambia nel tempo.
In questo scenario la sincronizzazione riduce il rischio che la configurazione Cloudflare e il file pubblico raccontino due cose differenti.
È meno adatta quando la policy dipende fortemente dal singolo crawler.
Immagina di consentire l’accesso a un determinato agente perché hai un accordo specifico con il provider, ma di bloccare tutti gli altri agenti della stessa categoria.
Questa eccezione vive meglio in una configurazione granulare.
La sincronizzazione per categoria non può dedurre automaticamente l’intenzione dietro ogni custom rule.
Bot Preference Sync è utile anche per WordPress?
Sì, ma non perché sia una funzione WordPress.
Opera a livello Cloudflare.
Quindi può essere utilizzata davanti a WordPress esattamente come davanti a un altro CMS.
Su WordPress, Cloudflare Bot Preference Sync opera indipendentemente dal CMS e dai plugin SEO, perché la sincronizzazione avviene a livello Cloudflare.
Questo è anche uno dei suoi vantaggi: la policy non dipende dal plugin SEO installato o dal tema.
C’è però una conseguenza operativa.
Se WordPress o un plugin genera un robots.txt virtuale e Cloudflare aggiunge le proprie direttive a monte, il file osservato dal crawler può essere diverso da quello che pensi di avere configurato nel CMS.
Per questo, dopo qualsiasi modifica, bisogna sempre controllare il documento pubblico.
Non il pannello.
Non il file locale.
La risposta HTTP realmente servita.
Bot Preference Sync cambia la SEO?
Non introduce una nuova regola di ranking.
Il suo impatto SEO deriva dalle decisioni di crawling che configuri.
Se consenti ai crawler necessari di accedere alle pagine importanti, la funzione è soprattutto uno strumento di gestione della policy.
Se invece una configurazione errata impedisce l’accesso a un crawler da cui dipende una superficie di ricerca importante, la conseguenza può diventare un problema di discoverability.
È quindi più corretto classificare Bot Preference Sync come controllo infrastrutturale della crawler policy che come “funzione SEO”.
La SEO entra in gioco quando devi decidere chi deve poter raggiungere quali contenuti e per quale finalità.
Checklist prima di attivarlo
Prima di attivare Cloudflare Bot Preference Sync, conviene controllare che la policy per Search, Agent e Training sia coerente con le regole già presenti sul sito.
| Controllo | Domanda |
|---|---|
| Search | quali crawler di ricerca devono continuare ad accedere? |
| Agent | voglio che agenti AI possano utilizzare le pagine? |
| Training | voglio consentire l’utilizzo per addestramento? |
| robots.txt | esistono già regole importanti? |
| Custom rules | ci sono eccezioni per crawler specifici? |
| WordPress | il robots.txt è fisico o generato dal CMS o da un plugin? |
| Edge | le regole Cloudflare corrispondono alla policy dichiarata? |
| Verifica | il robots.txt pubblico è quello che mi aspetto? |
La checklist evita di trasformare una funzione nata per semplificare la configurazione in una nuova fonte di incoerenza.
Conclusione
Cloudflare Bot Preference Sync è interessante non perché renda robots.txt più potente, ma perché cerca di risolvere un problema di governance.
I crawler AI stanno assumendo funzioni differenti: ricerca, agenti, training e combinazioni dei tre.
Una singola regola generica diventa quindi sempre meno adatta a rappresentare ciò che un proprietario vuole realmente consentire.
Cloudflare prova a spostare la decisione verso una policy per finalità e a mantenere robots.txt sincronizzato con quella scelta.
Per configurazioni semplici può ridurre molto il lavoro manuale.
Per configurazioni avanzate non elimina invece la necessità di capire crawler, regole custom ed enforcement.
Cloudflare Bot Preference Sync è quindi soprattutto uno strumento di coerenza tra policy dichiarata, robots.txt e controllo applicato all’edge.
La verifica fondamentale rimane sorprendentemente semplice:
decidi la policy, controlla cosa applica Cloudflare e poi verifica cosa il tuo dominio dichiara realmente nel robots.txt.
Se questi tre livelli coincidono, Bot Preference Sync sta facendo il lavoro per cui è stato progettato.