Cloudflare ha cambiato le regole del gioco per i bot AI
Cloudflare introduce Bot Preference Sync, ma dal 15 settembre bloccare i crawler di training potrebbe escludere Googlebot e altri dalla ricerca.
La sincronizzazione antepone le nuove regole al file esistente, ma la scadenza del 2026 complica la gestione dei crawler multiuso
Non è una policy: è un prepend. Venerdì scorso Cloudflare ha lanciato Bot Preference Sync, disponibile per tutti i clienti dal livello gratuito a Enterprise. Secondo l’annuncio pubblicato da Cloudflare, la funzionalità genera o aggiorna il robots.txt di un sito a partire dalla configurazione dei bot AI, eliminando la discrepanza tra preferenze dichiarate e regole applicate. Se un file robots.txt esiste già, i contenuti aggiunti da Bot Preference Sync vengono anteposti al materiale esistente: le direttive Disallow preesistenti restano, ma le nuove regole arrivano prima. Il risultato tecnico è un file che dice esattamente ciò che il publisher ha configurato, non una versione negoziata o parziale.
Il 1 luglio scorso Cloudflare aveva già introdotto opzioni più semplici per gestire diversi tipi di traffico AI. Bot Preference Sync è il passo successivo: per i nuovi clienti sarà attivo per impostazione predefinita, per rendere più semplice gestire blocchi e preferenze che riflettano la stessa policy.
Il prepend: non un override, una coda di precedenza
Per capire perché è diverso, serve guardare al meccanismo. In un normale intervento di sincronizzazione, ci si aspetterebbe che il provider sovrascriva il robots.txt o lo sostituisca con una versione generata. Cloudflare ha scelto una strada più chirurgica: i contenuti generati vengono preposti al file già presente. Le direttive Disallow esistenti vengono mantenute, ma le regole nuove, derivate dalla configurazione dei bot AI, finiscono in testa. Questo non è un override, ma una coda di precedenza: la preferenza dichiarata diventa la prima cosa che un crawler incontra quando recupera il file.
La scelta è rilevante perché alcuni crawler, secondo quanto scrive Cloudflare, trattano la discrepanza tra preferenze dichiarate e regole applicate come base per ignorare le preferenze o tentare di aggirare le regole. Eliminare quella discrepanza è il cuore tecnico di Bot Preference Sync. Ma se il prepend risolve la coerenza, apre un problema nuovo: la sincronizzazione non distingue più i crawler di ricerca da quelli di training.
Il paradosso del 15 settembre: blocchi i trainer, perdi la ricerca
Il problema nuovo ha una data: 15 settembre 2026. Da quel giorno, come ricostruito da Help Net Security, se un sito blocca i crawler di training, anche i crawler multiuso come Googlebot, Applebot e BingBot saranno bloccati, persino quando i crawler di ricerca sono consentiti. La modifica scatterà nei controlli di Cloudflare dedicati ai crawler AI, e il motivo è tecnico: questi crawler non sono solo motori di ricerca, ma agenti multiuso che possono essere usati anche per l’addestramento. Una policy binaria non può separare i due usi.
Il trade-off si materializza proprio qui. Bot Preference Sync traduce la preferenza dichiarata in regola applicata, ma il robots.txt non ha un campo per distinguere l’intento di ricerca dall’intento di addestramento. Se un publisher blocca i crawler di training per impedire l’uso dei contenuti nell’addestramento dei modelli, la stessa configurazione, tradotta in robots.txt, colpirà anche i crawler che portano visite organiche. La protezione dei contenuti, insomma, può costare la visibilità nella ricerca: un paradosso per chi vive di traffico.
La scadenza del 15 settembre lascia poco spazio per aggiustamenti incrementali: chi ha configurato blocchi ai crawler di training dovrà decidere se accettare la perdita di copertura da parte di Googlebot, Applebot e BingBot oppure rivedere la policy. Se il costo della protezione è la perdita della ricerca, esiste un modello che eviti questo bivio?
Akamai ha scelto i soldi; Cloudflare le regole. Chi protegge davvero chi pubblica?
La risposta non sta solo in Cloudflare, ma nel confronto con chi ha scelto un’altra strada. Nell’approccio descritto da Akamai, la monetizzazione sostituisce il blocco indiscriminato: invece di negare l’accesso a tutti i bot AI, le strategie avanzate consentono la licenza dei contenuti e uno scambio di valore equo attraverso partnership con piattaforme come Skyfire e TollBit. Sono due modelli profondamente diversi: Cloudflare sincronizza le preferenze con un file tecnico, Akamai punta a trasformare l’accesso in una transazione economica. Il punto non è se il robots.txt sia giusto, ma chi controlla il contratto tecnico tra publisher e crawler.
Per chi costruisce, la scelta non è più tra consentire e bloccare, ma tra due stack: uno che sincronizza preferenze, uno che monetizza accessi. Il robots.txt non è più un file statico: è una superficie di negoziazione.
