I crawler AI non sono tutti uguali: come un sito può definire gli ambiti di accesso

I siti web vogliono essere trovati dagli utenti senza che i loro contenuti vengano estratti senza limiti. I due obiettivi non sono in conflitto; il problema è che, quando tutte le visite automatizzate vengono etichettate come «crawler AI», la scelta si riduce spesso ad aprire tutto o bloccare tutto.

Una distinzione più utile si chiede se una determinata visita serve a costruire un indice di ricerca, ad addestrare un modello o a completare un'attività per conto di un utente. Scopi diversi comportano ritorni, oneri e controlli necessari diversi. Questo articolo esamina le modifiche pubbliche di Cloudflare per capire come i siti di contenuti e le homepage di prodotto possono fare questa valutazione. La verifica dei fatti è aggiornata al 2026-9-5 e non comporta alcuna modifica alla configurazione reale di un sito.

Durante la revisione del 2026-9-8, gli annunci e la documentazione di configurazione di Cloudflare indicavano ancora il 9-15 come futura modifica dei valori predefiniti. Questo articolo mantiene il periodo della prima pubblicazione e il contesto dell'epoca; per sapere se le modifiche entreranno in vigore come previsto all'arrivo di quelle date bisogna rileggere la documentazione ufficiale, e qui non è possibile affermarlo in anticipo.

Dall'interruttore AI allo scopo dell'accesso

Nel suo annuncio del 2026-7, Cloudflare suddivide ulteriormente il traffico legato all'AI in Search, Agent e Training. Search serve a raccogliere o indicizzare contenuti per query successive; Agent riguarda l'esecuzione di attività immediate per conto degli utenti; Training serve all'addestramento o al fine-tuning dei modelli. Si tratta della tassonomia di prodotto di Cloudflare, non di uno standard applicato universalmente su internet.

Questa distinzione merita attenzione perché uno stesso documento pubblico può avere più ruoli: un sistema di ricerca lo legge per aiutare altri a trovare risposte in seguito, un assistente lo legge ora perché un utente sta facendo il debug di un'API, e la raccolta per l'addestramento può non avere alcun legame con la query di un visitatore attuale.

Per le homepage di prodotto, il secondo tipo di visita non è privo di valore in sé. Se uno sviluppatore chiede a un assistente il significato di un parametro, il fatto che l'assistente possa accedere a documentazione corretta per la versione influisce sulla capacità dell'utente di proseguire con l'integrazione. Questo valore non si traduce necessariamente subito in un clic dal browser.

Questo non significa però che tutti gli agenti debbano avere accesso. Bisogna comunque valutare caso per caso se una visita rientra negli usi consentiti, richiede autenticazione o impone un carico anomalo. Trattare tutto il traffico con «AI» nel nome come un'opportunità di acquisizione clienti è grossolano quanto considerarlo tutto traffico senza valore.

Il calendario del 9-15 non si può dare per attivo su tutti i siti web

La documentazione di configurazione di Cloudflare indica l'intenzione di modificare alcuni comportamenti predefiniti il 2026-9-15: per i domini aggiunti di recente, il traffico di training e degli agenti viene bloccato per impostazione predefinita mentre quello di ricerca resta consentito; inoltre cambia il modo in cui i crawler con scopi misti, che fanno sia ricerca sia training, interagiscono con le policy di blocco del training.

Questa affermazione contiene diverse condizioni da non trascurare: la data prevista, i domini aggiunti di recente, le pagine interessate e le regole per le visite con scopi misti. Al momento della revisione la data è ancora il 9-5, quindi non si può riformulare come «Cloudflare ha bloccato l'accesso dell'AI per tutti i siti web». Il comportamento finale di un sito dipende dalle impostazioni effettive e dai successivi aggiornamenti del prodotto.

Se usi servizi di questo tipo, vale la pena controllare non quanto sia forte il titolo di un articolo di sintesi, ma le policy attuali dell'account, le categorie delle pagine e i log di accesso reali. Un interruttore valido per tutto il sito può influire contemporaneamente su pagine con scopi diversi, e un visitatore classificato a scopo misto non si può considerare autorizzato solo in base al nome.

La nostra valutazione è che modifiche di questo tipo dovrebbero portare a rivedere gli ambiti di accesso, non a cambiare d'impulso un'impostazione valida per tutto il sito. Prima elenca i contenuti che vuoi rendere individuabili, poi verifica se le policy attuali sono in conflitto con questo obiettivo. Questo articolo non consiglia di copiare alcuna configurazione e non implica che abbiamo verificato il tuo account.

Robots.txt, preferenze d'uso e blocco effettivo operano su livelli diversi

La RFC 9309 afferma esplicitamente che le regole di esclusione dei robot non sono meccanismi di autorizzazione all'accesso. Indicano ai crawler che le rispettano come accedere a un sito, ma non possono sostituire credenziali di login, controlli dei permessi o controllo degli accessi lato server.

Questo significa che i documenti riservati non dovrebbero affidarsi solo a robots.txt per restare nascosti. Al contrario, le spiegazioni destinate al pubblico possono comunque essere bloccate da altre regole di rete o applicative anche se robots.txt consente il crawling. Per capire se una pagina è accessibile bisogna controllare le risposte effettive, non un singolo file.

Anche l'annuncio di Cloudflare introduce segnali di preferenza sull'uso dei contenuti, attualmente in fase di test, precisando che esprimere una preferenza non attiva direttamente un blocco. Chi gestisce un sito dovrebbe registrare separatamente «quale preferenza ho espresso», «quali regole ha applicato il servizio» e «quali azioni hanno compiuto davvero i visitatori». Inviare un segnale non garantisce che i contenuti non vengano più usati per l'addestramento o riprodotti.

Questo articolo tratta ambiti tecnici e di prodotto e non considera le impostazioni di accesso una definizione completa dei diritti sui contenuti o delle licenze d'uso. Le informazioni private da limitare vanno protette con meccanismi adeguati di identità e permessi, mentre i materiali pubblici richiedono versioni, attribuzioni e ambiti d'uso chiari.

Essere letti non significa essere citati

La documentazione di Google sulle funzionalità di ricerca AI continua a insistere sulle basi della SEO: crawlability, individuabilità tramite link interni, contenuti principali in formato testo e dati strutturati coerenti con il testo della pagina. Per poter comparire come link di supporto nelle funzionalità di ricerca AI pertinenti, le pagine devono essere idonee all'indicizzazione e alla visualizzazione degli snippet, ma soddisfare i requisiti non garantisce né il crawling, né l'indicizzazione, né la visualizzazione.

Di conseguenza, una richiesta di un crawler nei log del server indica solo che c'è stato un accesso. Non dimostra che la pagina sia entrata in un indice di ricerca, tanto meno che una specifica risposta dell'AI ne abbia usato il contenuto. Una menzione del brand in una risposta non significa necessariamente che l'elenco delle fonti citi quella pagina.

Per i team di contenuti, questa distinzione cambia la valutazione quotidiana. Quando un articolo viene pubblicato, il team può verificare prima l'accesso pubblico, i link e la correttezza dei contenuti, e solo dopo controllare indicizzazione e visualizzazione nei sistemi di ricerca. Usare fin dall'inizio «l'AI l'ha citato?» come unico criterio di accettazione rischia di far dichiarare un fallimento troppo presto o di scambiare menzioni casuali per una crescita duratura.

Chi effettua le chiamate affronta un problema simile: trovare corrispondenze nella ricerca, leggere il testo e verificare le conclusioni sono passaggi distinti. Le guide del sito alla scelta degli strumenti di ricerca per agenti spiegano questa distinzione dal punto di vista di chi usa gli strumenti, mentre questo articolo esamina accesso e distribuzione dal punto di vista di chi possiede i contenuti, senza fondere le due cose in un'unica metrica.

Decidi in base allo scopo della pagina, non all'atteggiamento verso l'AI

Consigliamo di classificare le pagine prima di discutere gli scopi dell'accesso. La documentazione pubblica di prodotto serve di solito ad aiutare gli utenti a capire e completare l'integrazione; gli articoli di ricerca originali possono dare priorità ad attribuzione, citazione e manutenzione nel tempo; i dati dei clienti accessibili dopo il login devono restare limitati dai permessi degli utenti, non essere esposti per aumentare la visibilità.

Per ogni categoria di pagine si possono porre quattro domande specifiche:

1. Chi deve leggerla e in quale contesto: potenziali utenti che scoprono il prodotto o utenti esistenti che stanno risolvendo un problema?
2. L'accesso automatizzato può aiutare a completare questo task, e quali prove osservabili lo dimostrano?
3. Quali modalità di accesso escono dai valori attesi, e richiedono dichiarazioni di preferenza, controlli sul traffico o un'autenticazione rigorosa?
4. Se modifichi le policy, come puoi confermare che gli utenti target non ne risentano e che le impostazioni originali si possano ripristinare?

Questo non richiede di scrivere policy complesse per ogni singolo crawler, ma di assicurarsi che ogni modifica alle regole abbia una motivazione esplicita. Ad esempio, se la documentazione delle API serve ad aiutare gli utenti a risolvere problemi, verifica che le normali letture avviate dagli utenti restituiscano il contenuto; se i dati sono riservati agli utenti autenticati, verifica che le richieste non autorizzate vengano rifiutate correttamente. I criteri di successo nei due casi sono del tutto diversi.

Anche le modifiche alle regole possono alterare i campioni di dati. Se una fonte pubblica diventa temporaneamente inaccessibile, un sistema di osservazione riceve meno contenuti, ma questo non equivale a un reale calo delle discussioni esterne. Nelle analisi su più fonti, le lacune di copertura vanno conservate invece di trattare i dati mancanti come zero. I blueprint del sito per il monitoraggio della reputazione su più piattaforme trattano la separazione tra stato della raccolta e conclusioni di business come nota metodologica, non come guasti osservati presso clienti.

Valutare i ritorni senza ostacolare l'uso normale

Dopo aver modificato le policy, monitora le metriche su finestre di osservazione coerenti: volume e tasso di errore del traffico automatizzato, accessibilità delle pagine critiche, impressioni e clic nella ricerca, link di citazione verificabili e comportamenti di conversione degli utenti che portano alla documentazione o al completamento dell'integrazione. Evita di aggregare questi valori in una metrica ambigua di «traffico AI».

Alcuni ritorni possono restare per ora non attribuibili. Ad esempio, se un utente scopre un prodotto tramite un assistente e poi visita direttamente la homepage, il normale tracciamento della provenienza potrebbe non cogliere l'intero percorso. L'approccio corretto è mantenere questa parte sconosciuta, invece di fornire stime per dimostrare l'efficacia di una policy.

La gestione degli accessi AI sta diventando più granulare e la governance dei siti dovrebbe adeguarsi. Prima chiarisci quali contenuti servono a chi, poi verifica scopi dell'accesso, regole effettive e risultati d'uso. Per le homepage che devono essere trovate, l'obiettivo non è massimizzare le voci di log dei bot automatizzati; per i contenuti protetti, non è far fallire tutte le richieste automatizzate. L'obiettivo è offrire alle persone e agli strumenti giusti informazioni affidabili e sufficienti a completare i loro task entro i limiti consentiti.