Cloudflare Disallow AI Training separa la visibilità nella ricerca dall'addestramento dei modelli

Cloudflare ha lanciato Disallow AI Training, un nuovo controllo pensato per preservare l'indicizzazione nei motori di ricerca rifiutando al contempo l'addestramento dei modelli da parte dello stesso crawler. Finora, gli editori si trovavano spesso di fronte a una scelta netta nella gestione dei bot a uso misto: accettare entrambe le finalità oppure bloccare completamente il crawler.

La modifica riguarda Applebot, Googlebot e Bingbot, che Cloudflare classifica come crawler a uso misto perché ciascuno può supportare la ricerca e utilizzi legati all'AI. Cloudflare ora definisce questi bot “Accountable” quando i loro operatori forniscono controlli, reportistica e garanzie che l'esclusione dall'addestramento non ridurrà la tradizionale visibilità nella ricerca.

Questa designazione stabilisce un modello operativo condiviso tra Cloudflare, Apple, Google e Microsoft. Tuttavia, non crea uno standard tecnico vincolante. Il nuovo sistema combina controlli nella dashboard, istruzioni in robots.txt, impegni delle aziende e l'applicazione delle regole da parte di Cloudflare nei confronti di altri crawler per l'addestramento.

Questo è il compromesso centrale. Gli editori ottengono un modo più semplice per esprimere il consenso senza scomparire dalla ricerca, ma gran parte della protezione continua a dipendere dal fatto che gli operatori dei crawler rispettino tale scelta.

Cloudflare Disallow AI Training cambia la scelta predefinita

Cloudflare sta trasformando un'unica decisione di blocco, sovraccarica di implicazioni, in scelte separate per ricerca, addestramento e agenti guidati dagli utenti.

I controlli sui crawler AI di Cloudflare classificano l'attività automatizzata in base al comportamento, anziché trattare allo stesso modo ogni richiesta collegata all'AI. I crawler di ricerca costruiscono indici, quelli per l'addestramento raccolgono materiale per lo sviluppo dei modelli e gli agenti recuperano pagine agendo per conto di un utente.

Queste categorie contano perché gli effetti economici sono diversi. Un motore di ricerca mostra normalmente link che possono portare una persona al sito web originale. Un processo di addestramento può assorbire informazioni senza generare una visita immediata. Un agente potrebbe recuperare una pagina e fornirne i contenuti senza che l'utente la apra mai.

Un crawler può rientrare in più di una categoria. Googlebot, Applebot e Bingbot sono esempi importanti perché le loro funzioni di ricerca rendono difficile per gli editori bloccarli. Rimuoverne l'accesso può influire nel tempo su indicizzazione, aggiornamento e reperibilità.

I precedenti controlli di Cloudflare gestivano questo problema escludendo i crawler a uso misto da alcuni blocchi dell'addestramento. Ciò proteggeva la visibilità nella ricerca, ma lasciava anche gli editori senza un modo diretto per rifiutare la componente di addestramento attraverso la stessa impostazione.

Il nuovo modello di controllo dei crawler introduce Disallow AI Training come opzione intermedia. Pubblica una preferenza contraria all'addestramento tramite robots.txt, mantiene disponibili per la ricerca i crawler a uso misto Accountable e blocca gli altri crawler associati all'addestramento.

Cloudflare afferma che i crawler esclusivamente dedicati all'addestramento gestiti da Amazon, Anthropic, Meta e OpenAI possono essere bloccati senza influire sui rispettivi crawler di ricerca separati. Queste aziende utilizzano bot distinti per scopi diversi, rendendo l'applicazione delle regole più diretta a livello di rete.

Cloudflare sta inoltre modificando il significato delle sue impostazioni più restrittive. “Block” e “Block on pages with ads” ora si applicano ai crawler a uso misto, inclusi Googlebot, Applebot e Bingbot. La selezione di una delle due opzioni può quindi influire sia sulla ricerca sia sull'addestramento.

Questa distinzione rende la configurazione più rilevante. Disallow AI Training comunica una preferenza limitata preservando l'accesso alla ricerca. Block nega l'accesso al crawler stesso, indipendentemente dal fatto che una determinata richiesta supporti la ricerca o l'addestramento.

Le configurazioni esistenti vengono migrate verso i nuovi controlli. Un dominio che in precedenza utilizzava un'opzione generale di blocco dell'AI in genere manterrà l'accesso alla ricerca, spostando la propria preferenza per l'addestramento su Disallow AI Training. Anche i domini con policy granulari già esistenti vedranno mantenute le loro selezioni operative.

Per i nuovi domini supportati dalla pubblicità, Cloudflare consiglia di consentire la ricerca, vietare l'addestramento e bloccare gli agenti nelle pagine in cui compaiono annunci. I nuovi domini senza pubblicità ricevono una raccomandazione meno restrittiva che consente tutte e tre le categorie.

Queste preimpostazioni sono raccomandazioni, non regole permanenti. I proprietari dei siti possono modificarle durante l'onboarding o in seguito tramite Security Settings. I controlli sono disponibili su tutti i piani Cloudflare e operano a livello di dominio.

Il risultato è un albero decisionale più chiaro. Un editore può consentire la normale indicizzazione, rifiutare l'addestramento e scegliere una policy distinta per gli agenti. Questa struttura riflette meglio il modo in cui i sistemi automatizzati interagiscono oggi con i siti web.

Rende inoltre più semplice diagnosticare una configurazione errata. Se un editore seleziona Block e successivamente perde l'accesso del crawler, la conseguenza deriva direttamente dall'impostazione scelta. Disallow AI Training è pensato per l'obiettivo più circoscritto di mantenere la ricerca rifiutando l'uso per lo sviluppo dei modelli.

Non si tratta semplicemente di un interruttore per bot rinominato. Cambia l'unità di controllo dalla sola identità del crawler alla combinazione di identità, finalità dichiarata e comportamento dell'operatore.

Perché i crawler a uso misto mettono sotto pressione gli editori

Il conflitto esiste perché un crawler che genera prezioso traffico dalla ricerca può anche raccogliere materiale per una finalità commerciale completamente diversa.

Lo scambio tradizionale del web aperto era relativamente semplice da comprendere. Gli editori permettevano ai motori di ricerca di eseguire la scansione delle loro pagine, e i motori restituivano link, estratti e potenziali visitatori. Pubblicità, abbonamenti, vendite e relazioni con i lettori dipendevano dall'arrivo di una parte di quegli utenti.

L'AI generativa complica questo scambio. Un modello può utilizzare il materiale raccolto durante l'addestramento, mentre una risposta AI può soddisfare una query prima che il lettore visiti qualunque fonte citata. Ricerca, sviluppo dei modelli e generazione di risposte creano quindi forme di valore differenti.

Le rilevazioni di Cloudflare illustrano perché gli editori sono preoccupati. L'azienda ha riferito che l'addestramento rappresentava l'80 percento della scansione AI classificata in un periodo di 12 mesi. Nella successiva analisi di sei mesi, la quota dell'addestramento è salita all'82 percento, mentre la ricerca rappresentava il 15 percento e le azioni degli utenti il 3 percento.

Queste cifre descrivono il traffico osservato e classificato da Cloudflare, non l'intero web. Mostrano comunque che l'attività di addestramento può dominare la domanda automatizzata che raggiunge i fornitori di contenuti.

Un editore che blocca un crawler esclusivamente dedicato all'addestramento affronta un calcolo gestibile. Il blocco può fermare la raccolta indesiderata senza rimuovere un importante indicizzatore per la ricerca. Bot distinti come GPTBot e OAI-SearchBot rendono più semplice separare queste finalità.

I crawler a uso misto creano un problema più difficile. Se lo stesso crawler supporta ricerca e addestramento, un blocco a livello di infrastruttura non può stabilire cosa accadrà dopo che il contenuto raggiunge il suo operatore. Bloccare l'accesso protegge il materiale ma rimuove anche la funzione di ricerca.

Consentire l'accesso preserva la reperibilità, ma richiede un altro meccanismo per limitare l'uso a valle. Questo è il divario che l'impostazione Cloudflare Disallow AI Training tenta di colmare.

Cloudflare ha iniziato ad affrontare questo divario con Content Signals, un vocabolario proposto inserito in robots.txt. La policy dei segnali di contenuto distingue tre utilizzi dichiarati: search, ai-input e ai-train.

Il segnale di ricerca copre l'indicizzazione e i risultati di ricerca tradizionali. Non include i riepiloghi generati dall'AI. Il segnale ai-input riguarda l'uso in tempo reale da parte dei sistemi AI, inclusi recupero e grounding. Il segnale ai-train riguarda l'addestramento e il fine-tuning dei modelli.

Un sito può quindi pubblicare search=yes e ai-train=no. Può lasciare ai-input non specificato se il suo proprietario non ha deciso come le risposte generative debbano utilizzare il contenuto.

Questa separazione è importante perché un'assenza di preferenza non dovrebbe essere interpretata come autorizzazione o rifiuto. La policy di Cloudflare tratta un segnale omesso come neutrale, anziché presumere l'intenzione dell'editore.

Tuttavia, Content Signals sono espressioni di preferenza. Non sono barriere che impediscono fisicamente a uno scraper di scaricare una pagina. Cloudflare ha in precedenza consigliato agli editori di combinare tali segnali con controlli sui bot o regole firewall quando è necessaria un'applicazione tecnica.

La nuova designazione Accountable cerca di collegare questi livelli. Identifica gli operatori dei crawler che, secondo Cloudflare, forniscono o si sono impegnati a fornire controlli e trasparenza specifici. I requisiti includono l'esclusione dall'addestramento, l'esclusione dai riepiloghi AI, visibilità a livello di URL e tutela del posizionamento nella ricerca tradizionale.

Apple, Google e Microsoft soddisfano questa soglia attraverso diverse combinazioni di funzionalità attuali e impegni con tempistiche definite. La designazione non significa che le loro implementazioni siano identiche. Significa che Cloudflare ritiene che ciascun operatore abbia accettato le stesse responsabilità fondamentali.

Ciò crea pressione sugli altri operatori di crawler. Un'azienda che desidera un accesso ampio può ora essere confrontata con un riferimento pubblicato per consenso, ispezione e neutralità nella ricerca. Separare le identità dei bot resta un modo per soddisfare questo riferimento, ma non è più l'unica strada.

Gli editori affrontano anche una nuova responsabilità operativa. Visibilità nella ricerca, addestramento AI, generazione di risposte e accesso degli agenti richiedono ora policy separate. Un'unica decisione di “bloccare l'AI” non coglie più tutti i compromessi commerciali.

Un sito di notizie finanziato dalle visualizzazioni di pagina potrebbe rifiutare sia l'addestramento sia l'accesso degli agenti sulle pagine pubblicitarie. Un rivenditore potrebbe attribuire valore a referral AI qualificati anche se il loro volume è inferiore. Un sito di documentazione potrebbe accogliere il recupero AI in tempo reale rifiutando al contempo l'addestramento a lungo termine dei modelli.

La domanda rilevante non è più se i bot AI siano buoni o cattivi. È quale utilizzo giustifichi l'accesso, quale valore ritorni all'editore e se tale utilizzo possa essere verificato.

Apple, Google e Microsoft condividono un modello, non un'unica implementazione

Le tre aziende sostengono lo stesso principio, ma i loro controlli restano tecnicamente disomogenei e arrivano secondo tempistiche diverse.

Apple consente già agli editori di gestire l'addestramento tramite Applebot-Extended. Il proprietario di un sito può vietare questo user agent in robots.txt continuando a consentire le normali funzioni di ricerca di Applebot.

La documentazione di Apple afferma che la preferenza Applebot-Extended non influisce sul modo in cui un sito appare nei risultati di ricerca. Supporta inoltre meccanismi a livello di pagina relativi all'output generativo, inclusi nosnippet ed etichette per materiale protetto da paywall.

Questi strumenti non forniscono ancora ogni elemento del framework Accountable di Cloudflare. Cloudflare afferma che Apple non dispone della possibilità di ispezione a livello di URL per questo scopo. Apple avrebbe condiviso i dettagli di una soluzione in corso, prevista per il prossimo anno.

Gli attuali controlli Applebot forniscono quindi una separazione funzionante tra ricerca e addestramento, ma una visibilità incompleta su ciò che accade dopo l'accesso. Cloudflare accetta l'impegno a colmare questa lacuna.

Google utilizza un modello di estensione simile. Gli editori possono bloccare Google-Extended senza bloccare Googlebot. Google-Extended è un token di controllo che disciplina alcuni utilizzi dell'AI generativa, anziché un crawler separato che effettua sempre richieste proprie.

Questo dettaglio conta. Googlebot potrebbe comunque recuperare il contenuto per la ricerca, mentre Google utilizza la preferenza Google-Extended per determinare se il materiale possa supportare i sistemi AI coperti. L'editore controlla l'uso a valle attraverso una policy, anziché mediante un'identità di rete separata.

Google afferma che l’esclusione tramite Google-Extended non influisce sull’inclusione né sul posizionamento in Google Search. Le sue linee guida per l’esclusione dall’addestramento documentano il rapporto tra Googlebot e Google-Extended.

Google fornisce inoltre report sulle prestazioni di ricerca e controlli relativi alle esperienze di ricerca generate. Cloudflare afferma che Google sta lavorando a ulteriore trasparenza a livello di URL associata a Google-Extended, con un lancio previsto entro poche settimane.

Microsoft è la meno completa delle tre sotto questo specifico meccanismo. Bing supporta controlli granulari per i webmaster e gli editori possono utilizzare il meta tag NOARCHIVE per limitare determinati usi dei contenuti memorizzati nella cache o visualizzati.

Microsoft afferma che NOARCHIVE non rimuove una pagina dal posizionamento nei risultati di ricerca. I proprietari dei siti possono inoltre usare Bing Webmaster Tools per la rimozione dei contenuti e la gestione degli URL.

Tuttavia, Bingbot non rispetta ancora automaticamente la preferenza di non addestramento a livello di dominio di Cloudflare tramite robots.txt. Cloudflare afferma che Microsoft sta sviluppando questa funzionalità per l’inizio del 2027.

Fino ad allora, selezionare Disallow AI Training non comunica automaticamente a Bing la restrizione prevista attraverso il nuovo flusso di lavoro. Gli editori che cercano una restrizione immediata su Bing devono ancora utilizzare gli strumenti esistenti di Microsoft e i metadati a livello di pagina.

Microsoft ha descritto le sue opzioni di controllo dell’AI come un modo per preservare la scoperta attraverso la ricerca limitando al contempo il modo in cui i contenuti appaiono nelle esperienze generative. Tuttavia, l’interruttore unificato di Cloudflare non è ancora pienamente collegato a tali controlli.

Questo divario di implementazione è l’avvertenza più importante del lancio. Cloudflare presenta Applebot, Googlebot e Bingbot sotto un’unica etichetta Accountable, ma solo Apple e Google espongono attualmente lo specifico percorso basato su user agent esteso per le preferenze di addestramento.

L’inclusione di Microsoft si basa in parte su un impegno datato. Ciò può essere ragionevole per stabilire uno standard cooperativo, ma gli editori dovrebbero comprendere la differenza tra l’applicazione disponibile e la compatibilità promessa.

Il modello condiviso dipende inoltre dall’interpretazione che ciascun operatore dà all’addestramento. Il preaddestramento di un nuovo modello, il fine-tuning di un sistema esistente, il grounding di una risposta in tempo reale e la generazione di un riepilogo di ricerca sono attività distinte. Una scelta di “nessun addestramento” non rifiuta necessariamente ogni uso mediato dall’AI.

Cloudflare tratta esplicitamente l’input per l’AI e i riepiloghi AI come questioni diverse. Questo impedisce che una preferenza copra silenziosamente usi non correlati, ma significa anche che il nuovo controllo è più ristretto di quanto potrebbe suggerire la sua semplice etichetta nella dashboard.

Un editore può rifiutare l’addestramento dei modelli restando al contempo idoneo per i riepiloghi di ricerca generati dall’AI. Un altro editore può usare controlli sui riepiloghi specifici dell’operatore consentendo l’addestramento. Queste scelte possono produrre risultati diversi in termini di traffico e attribuzione.

Il framework Accountable va quindi inteso come un contratto minimo. Chiede agli operatori di separare gli scopi, rispettare le preferenze, fornire strumenti di ispezione ed evitare di penalizzare il rifiuto dell’addestramento nella ricerca tradizionale.

Non rende Apple, Google e Microsoft tecnicamente intercambiabili. Né garantisce che ogni funzionalità AI offerta da tali aziende rientri nella medesima esclusione.

Il valore immediato deriva dal consolidamento. I clienti Cloudflare ricevono un unico punto in cui esprimere una preferenza comune, mentre gli operatori mappano tale preferenza sui loro controlli esistenti o futuri.

Il valore a lungo termine dipende dal fatto che tali mappature diventino abbastanza trasparenti da consentire a un editore di verificarle a livello di URL.

L’impostazione è un segnale di consenso, non una prova di conformità

Cloudflare ha semplificato l’istruzione, ma non può dimostrare che ogni uso successivo sia cessato solo perché un sito ha pubblicato quell’istruzione.

Questa limitazione inizia con robots.txt. Il file è stato progettato come protocollo volontario per crawler, non come sistema di controllo degli accessi. I crawler conformi lo leggono e adeguano il proprio comportamento. Un operatore che lo ignora può comunque richiedere pagine pubblicamente disponibili, salvo che un altro controllo blocchi il traffico.

Cloudflare può applicare decisioni al margine della propria rete quando riconosce un crawler. Ciò rende il blocco più forte di un segnale di preferenza. Tuttavia, l’applicazione dipende da un’identificazione affidabile e le stringhe user agent possono essere copiate da bot non correlati.

I programmi per bot verificati riducono questo rischio controllando le origini delle richieste rispetto alle informazioni fornite dagli operatori. L’autenticazione crittografica potrebbe offrire una prova più solida, ma l’adozione resta incompleta nell’intero mercato dei crawler.

Persino una richiesta verificata rivela chi ha recuperato una pagina, non necessariamente tutti gli usi successivi dei suoi contenuti. Un operatore di crawler deve mantenere una separazione interna tra indicizzazione della ricerca, addestramento dei modelli, generazione di risposte e altre elaborazioni.

I requisiti Accountable di Cloudflare affrontano questa lacuna di fiducia attraverso report e impegni. La visibilità a livello di URL dovrebbe aiutare gli editori a vedere quali pagine sono diventate disponibili per l’addestramento e come i contenuti sono apparsi nella ricerca.

La parola chiave è “dovrebbe”. Il sistema di ispezione di Apple è ancora in fase di sviluppo, gli strumenti aggiuntivi di Google sono in arrivo e il supporto di Microsoft a robots.txt a livello di dominio è previsto per l’inizio del 2027.

La designazione combina quindi capacità attuali e promesse future. Cloudflare non afferma che oggi tutti e quattro i requisiti abbiano implementazioni di produzione identiche.

Gli editori dovrebbero inoltre evitare di interpretare “Disallow AI Training” come una soluzione legale universale. Eccezioni al copyright, termini contrattuali, differenze giurisdizionali e raccolte passate restano questioni separate. Una nuova preferenza non può rimuovere retroattivamente il materiale da un modello esistente.

L’impostazione regola il comportamento futuro dei crawler, così come implementato dagli operatori partecipanti e da Cloudflare. Non conferma che le copie raccolte in precedenza siano state eliminate. Non stabilisce neppure in che modo un modello addestrato possa conservare o riprodurre informazioni.

Un’altra incertezza riguarda la classificazione. Cloudflare assegna comportamenti di Search, Training e Agent basandosi in parte sulle dichiarazioni degli operatori e su altre informazioni osservate. Lo scopo dichiarato di un crawler può cambiare e un singolo servizio può supportare più prodotti.

Quando le classificazioni restano indietro rispetto alle modifiche dei prodotti, una policy potrebbe consentire più attività di quanto un editore si aspetti. Registri delle modifiche trasparenti e monitoraggio indipendente conteranno quanto il design iniziale della dashboard.

I riepiloghi AI espongono un divario ancora maggiore. L’addestramento determina se i contenuti contribuiscono allo sviluppo del modello. I riepiloghi determinano se i contenuti correnti vengono trasformati in una risposta che può ridurre la necessità di una visita.

Cloudflare cita ricerche che mostrano come i riepiloghi AI siano già comuni nel comportamento di ricerca. Uno studio sul comportamento di ricerca ha rilevato che gli utenti erano meno propensi a fare clic sui link dei risultati quando appariva un riepilogo AI.

Non è lo stesso problema dell’addestramento. Un editore potrebbe rifiutare con successo l’addestramento e perdere comunque visite quando un prodotto di ricerca riassume materiale appena indicizzato.

Cloudflare afferma che gli operatori Accountable devono offrire un’esclusione dai riepiloghi AI direttamente e, in futuro, tramite Cloudflare. Il suo prossimo obiettivo è un controllo più granulare sulla quantità di contenuto che un riepilogo può includere.

Questo piano riconosce una debolezza del consenso binario. Consentire una breve citazione con un link chiaro è diverso dal consentire una risposta dettagliata che sostituisce la fonte. Entrambi potrebbero tecnicamente rientrare nell’uso dei riepiloghi.

Anche i modelli di business modificano l’equilibrio accettabile. Un editore finanziato dalla pubblicità necessita di volume di visite perché le impression generano ricavi. Un rivenditore potrebbe accettare meno visite se i referral AI producono più acquisti. Un editore in abbonamento potrebbe attribuire più valore all’attribuzione e al riconoscimento da parte dei lettori che ai clic puri.

Cloudflare ha citato stime di terze parti secondo cui i referral AI possono convertire a tassi più elevati rispetto ai referral della ricerca tradizionale. Queste cifre variano in base al dataset e alla metodologia, quindi non dovrebbero essere considerate una compensazione universale per il traffico perso.

Il vero problema di misurazione è causale. Un editore deve sapere quale crawler ha avuto accesso a un URL, quale prodotto lo ha utilizzato, se è apparso un riepilogo, quanto contenuto ha mostrato e se l’interazione ha prodotto una visita.

Oggi la maggior parte delle organizzazioni non dispone di questa catena completa. I log del server rivelano le richieste, mentre le console di ricerca rivelano impression e clic. Nessuno dei due, da solo, stabilisce come i contenuti siano transitati attraverso un prodotto AI.

I nuovi controlli migliorano l’autonomia prima di garantire una piena responsabilità. Consentono agli editori di dichiarare una policy più ristretta e applicare blocchi più forti ai crawler che non si qualificano per l’eccezione Accountable.

Non eliminano la necessità di monitoraggio. Gli editori dovrebbero esaminare la copertura di ricerca, i log dei crawler, i modelli di referral e gli output pubblici dei principali prodotti AI dopo aver modificato le impostazioni.

Per i team che gestiscono ricerca, documentazione o memoria istituzionale, la policy sui crawler è solo uno strato della governance delle informazioni. Una knowledge base ricercabile può preservare internamente il contesto delle fonti anche quando le piattaforme esterne riassumono la versione pubblica.

La conclusione scettica è semplice. Cloudflare ha creato una superficie di controllo credibile, ma la conformità resta un sistema di applicazione tecnica, standard volontari, policy degli operatori e trasparenza futura.

Definire un crawler Accountable innalza lo standard atteso. Non fa sparire il problema di fiducia sottostante.

Tre segnali mostreranno se il nuovo modello funziona

Il prossimo test è verificare se la policy condivisa di Cloudflare produce comportamenti misurabili, non se più aziende ne approvano il linguaggio.

Il primo segnale è il supporto promesso da Microsoft per una preferenza di non addestramento a livello di dominio in robots.txt. Cloudflare afferma che questa capacità è prevista per l’inizio del 2027.

Un’implementazione funzionante chiuderebbe l’attuale divario più grande tra i tre operatori di crawler a uso misto. Consentirebbe alla stessa impostazione Cloudflare di comunicare un rifiuto dell’addestramento a Bing senza richiedere un’implementazione separata di NOARCHIVE o un flusso di lavoro per la rimozione.

Un ritardo indebolirebbe la designazione Accountable perché uno dei suoi partecipanti più importanti continuerebbe a fare affidamento su alternative manuali o a livello di pagina. L’implementazione dovrebbe inoltre chiarire quali usi AI di Microsoft rientrano nell’“addestramento” e quali restano disciplinati da controlli separati.

Il secondo segnale è il reporting a livello di URL da parte di Apple e Google. Gli editori hanno bisogno di più della conferma dell’esistenza di una preferenza a livello di dominio. Devono sapere quali pagine sono state consultate, quali usi sono stati consentiti e se la preferenza ha modificato l’elaborazione successiva.

Le aggiunte promesse da Google relative a Google-Extended forniscono un primo test. La capacità di ispezione pianificata da Apple ne offre uno più a lungo termine. Un reporting utile dovrebbe essere abbastanza specifico da confrontare l’accesso dei crawler con le prestazioni di ricerca e la visibilità AI.

Un conteggio generico in una dashboard offrirebbe una responsabilità limitata. Record a livello di pagina, etichette di scopo comprensibili e dati storici stabili rafforzerebbero l’affermazione di Cloudflare secondo cui gli editori possono prendere decisioni informate.

Il terzo segnale è il lavoro di Cloudflare sui controlli dei riepiloghi AI. Le esclusioni dall’addestramento risolvono solo una parte del conflitto con gli editori. Le risposte generate dalla ricerca possono incidere sul traffico anche quando non esiste alcuna autorizzazione all’addestramento dei modelli.

Il controllo pianificato da Cloudflare sulla quantità di contenuto visualizzata in un riepilogo è più ambizioso di una semplice esclusione. Richiederebbe agli operatori di interpretare in modo coerente una preferenza condivisa e di esporre dati sufficienti affinché gli editori possano valutarne il risultato.

Il successo rafforzerebbe il principio più ampio alla base di Cloudflare Disallow AI Training: l’accesso dovrebbe essere specifico per finalità, misurabile e modificabile dal proprietario dei contenuti. Il fallimento lascerebbe invece gli editori a gestire controlli distinti per ogni provider di ricerca e AI.

La risposta pratica, oggi, è considerare il lancio come un aggiornamento delle policy, non come una garanzia da impostare e dimenticare. I proprietari dei siti dovrebbero verificare le impostazioni migrate per ogni dominio, soprattutto se in precedenza avevano attivato un’opzione generale di blocco dell’AI.

Dovrebbero confermare che la ricerca rimanga consentita e che per l’addestramento compaia ora Disallow AI Training anziché Block. La selezione di un blocco completo può fermare Applebot, Googlebot e Bingbot, producendo un risultato diverso dalla pubblicazione di una preferenza di non addestramento.

I team dovrebbero inoltre documentare il motivo per cui ciascuna categoria viene consentita o rifiutata. Ricerca, addestramento e agenti rispondono a finalità diverse, quindi la policy dovrebbe riflettere il modello di ricavi del sito e il rapporto con il pubblico.

Dopo ogni modifica, monitorate le risposte dei crawler e l’indicizzazione. Un calo della copertura nella ricerca potrebbe indicare che è stata selezionata l’impostazione sbagliata o che un’altra regola del firewall sta sovrascrivendo la preferenza.

La stessa verifica dovrebbe includere i sottodomini importanti. Documentazione, centri di assistenza, blog e pagine dell’applicazione possono trovarsi dietro configurazioni diverse, anche quando condividono lo stesso brand principale.

Il lancio di Cloudflare è importante perché sostituisce una scelta binaria artificiale con un’alternativa più realistica. Un sito non dovrebbe essere costretto a offrire materiale per lo sviluppo dei modelli solo per rimanere visibile in un indice di ricerca tradizionale.

Tuttavia, la credibilità del sistema dipenderà da risultati verificabili. Microsoft deve completare la sua integrazione, Apple e Google devono offrire strumenti di ispezione utili e Cloudflare deve trasformare il controllo sintetico in qualcosa che gli editori possano misurare.

Per ora, Cloudflare Disallow AI Training offre ai proprietari di siti web un’istruzione più chiara e una via intermedia più sicura. La domanda successiva è se i maggiori operatori di crawler renderanno questa istruzione sufficientemente osservabile da meritare fiducia.

Esaminate le tre policy relative ai crawler del vostro dominio, registrate il risultato previsto e osservate la copertura nella ricerca dopo ogni modifica. Se il traffico rimane stabile mentre l’accesso per l’addestramento diminuisce, il modello condiviso avrà superato il suo primo test pratico.