Controllo dei crawler AI con robots.txt, Google prepara un segnale condiviso per l'addestramento dei modelli

Google ha annunciato il 30 ottobre 2026 un nuovo sistema per consentire ai proprietari dei siti web di esprimere le proprie preferenze sull'utilizzo dei contenuti nell'addestramento dei modelli di intelligenza artificiale. Il progetto prevede l'introduzione di un segnale condiviso nel file robots.txt, riconoscibile da diversi operatori AI senza dover configurare istruzioni separate per ciascuno.

La novità, illustrata da John Mueller sul blog ufficiale Google Search Central, nasce dal lavoro sviluppato nell'ambito di AIPREF, il gruppo dell'Internet Engineering Task Force (IETF) impegnato nella definizione di modalità standardizzate per comunicare le preferenze relative all'utilizzo dei contenuti digitali da parte dei sistemi di intelligenza artificiale.

L'obiettivo è affrontare una difficoltà concreta per editori, imprese e gestori di piattaforme online. Attualmente, chi intende limitare l'impiego dei propri contenuti nell'addestramento deve conoscere le modalità di controllo previste dai singoli fornitori, verificarne le differenze e mantenere aggiornate le configurazioni.

Il nuovo meccanismo permetterebbe di esprimere una preferenza generale attraverso un'unica istruzione, mantenendo la possibilità di stabilire comportamenti differenti per specifici operatori.

Il supporto annunciato da Google è previsto nel 2027. Non si tratta quindi di una funzionalità già universalmente operativa, né di uno standard definitivamente adottato dall'intero settore.

Come funzionerà il segnale condiviso nel file robots.txt

Il progetto utilizza il file robots.txt, normalmente collocato nella directory principale di un sito web e impiegato per comunicare ai crawler quali risorse possono essere richieste e quali devono essere escluse dalla scansione.

Il controllo dei crawler AI con robots.txt seguirà una logica differente rispetto alla gestione tradizionale dell'accesso alle pagine. Il segnale condiviso non servirà principalmente a impedire che un programma automatico scarichi un documento, ma a indicare una preferenza sul successivo utilizzo di quel contenuto per addestrare modelli generativi.

La proposta tecnica pubblicata il 30 ottobre 2026 da Kevin Kelley introduce un identificatore comune denominato __usage_ai-training, utilizzato come policy token all'interno di un normale gruppo di regole robots.txt.

Il funzionamento previsto sfrutta le direttive già conosciute dai gestori dei siti, come User-agent, Allow e Disallow, senza introdurre una nuova grammatica del file.

Un gruppo associato al token comune può comunicare una preferenza contraria all'addestramento per l'intero sito oppure per determinate sezioni. Analogamente, può indicare percorsi per i quali il titolare esprime una preferenza favorevole.

Questa distinzione consente una gestione più precisa dei materiali pubblicati. Un editore potrebbe, per esempio, esprimere un'opposizione all'addestramento sui propri articoli riservando un trattamento diverso ad alcune risorse informative liberamente riutilizzabili. Si tratta di una possibilità tecnica prevista dalla proposta, non di un obbligo né di una configurazione già necessaria per tutti i siti.

Il documento specifica inoltre che il token deve essere riconosciuto in maniera esatta dagli operatori che lo supportano. Le normali regole riferite genericamente a tutti i crawler non devono essere automaticamente interpretate come preferenze espresse attraverso il nuovo identificatore.

La differenza è sostanziale: una regola che disciplina la scansione e una preferenza relativa all'addestramento rappresentano due istruzioni distinte, anche quando vengono comunicate attraverso lo stesso file.

Cosa cambierà per Google-Extended e per le istruzioni dei singoli fornitori

Google dispone già dal 2023 di Google-Extended, un controllo attraverso il quale i proprietari dei siti possono gestire determinati utilizzi dei contenuti da parte dei sistemi di intelligenza artificiale dell'azienda.

L'annuncio del 30 ottobre chiarisce come il nuovo segnale condiviso dovrebbe interagire con questa impostazione.

Quando un sito esprimerà attraverso il policy token comune una preferenza contraria all'addestramento e Google-Extended non sarà specificato esplicitamente, Google prevede di interpretare il segnale generale come se il proprietario avesse inserito una regola di esclusione per Google-Extended.

La precisazione evita che l'assenza di una configurazione proprietaria venga interpretata automaticamente come una scelta favorevole all'utilizzo dei contenuti. Il segnale comune potrà quindi assumere un ruolo operativo anche per Google, purché siano soddisfatte le condizioni indicate.

Diverso è il caso in cui il proprietario abbia già configurato esplicitamente Google-Extended. L'azienda ha previsto la convivenza tra il nuovo controllo generale e le istruzioni specifiche, consentendo ai gestori di mantenere preferenze differenziate.

Un sito potrebbe quindi adottare una posizione generale contraria all'addestramento da parte degli operatori aderenti, ma scegliere un trattamento diverso per Google attraverso Google-Extended.

Il documento pubblicato da Google chiarisce inoltre che i siti che autorizzano specificamente Google-Extended possono essere idonei a comparire nelle risposte delle applicazioni Gemini e a ricevere visite attraverso i collegamenti utilizzati nelle operazioni di grounding.

Questo rende la gestione delle preferenze più articolata di un semplice consenso o rifiuto universale. Le condizioni associate a Google-Extended comprendono infatti utilizzi che vanno oltre il solo addestramento.

Google-Extended non è neppure un crawler autonomo identificabile attraverso uno specifico user-agent nelle richieste HTTP. È un identificatore di controllo che viene interpretato rispetto ai contenuti acquisiti attraverso l'infrastruttura di scansione di Google.

Un'eventuale opposizione espressa mediante Google-Extended non equivale dunque alla disattivazione generale di Googlebot.

Addestramento, scansione e grounding: tre attività da distinguere

La principale questione tecnica riguarda il significato attribuito al termine addestramento.

Nel lavoro AIPREF, l'AI training viene definito come l'utilizzo di una risorsa digitale per modificare i parametri appresi da un modello di intelligenza artificiale generativa.

La definizione esclude l'addestramento di modelli utilizzati esclusivamente per attività non generative, anche quando la tecnologia impiegata potrebbe teoricamente essere capace di generare contenuti.

Il controllo dei crawler AI con robots.txt riguarda quindi una specifica categoria di utilizzo delle informazioni, non tutte le operazioni che possono coinvolgere una pagina web e un sistema automatizzato.

La scansione consiste nell'accesso a una risorsa online per acquisirne il contenuto. L'indicizzazione è invece il processo attraverso il quale un motore di ricerca analizza e organizza le informazioni per renderle potenzialmente disponibili nei risultati.

Il grounding interviene in un momento diverso. Un sistema di intelligenza artificiale può recuperare informazioni da una fonte esterna e utilizzarle durante la generazione di una risposta, migliorandone l'aderenza ai fatti o fornendo elementi aggiornati. Questa operazione non richiede necessariamente una modifica dei parametri del modello.

Un contenuto può pertanto essere utilizzato come riferimento durante una risposta senza essere impiegato per addestrare il modello.

La differenza assume particolare rilievo nel rapporto tra il segnale condiviso e Google-Extended. Quest'ultimo, secondo la documentazione tecnica di Google, consente di controllare l'impiego dei contenuti sia per l'addestramento di future generazioni dei modelli Gemini, sia per alcune attività di grounding nelle applicazioni Gemini e nei servizi collegati a Vertex AI.

Il nuovo token comune nasce invece da una definizione più circoscritta, riferita all'addestramento generativo.

Di conseguenza, un'opposizione generale all'AI training non deve essere considerata automaticamente un divieto universale di utilizzare le informazioni per generare risposte, né una richiesta di rimuovere il sito dai motori di ricerca.

Anche la visualizzazione dei contenuti nei risultati tradizionali e nelle funzionalità AI di Google Search segue meccanismi specifici.

Google distingue i controlli disponibili per le esperienze di ricerca, comprese AI Overviews e AI Mode, dalle preferenze gestite attraverso Google-Extended. Per limitare la visualizzazione di determinati contenuti nelle ricerche esistono istruzioni dedicate, tra cui noindex, nosnippet, max-snippet e data-nosnippet, ciascuna con caratteristiche differenti.

Nel caso di noindex, per esempio, l'obiettivo è impedire che una pagina venga indicizzata. Le istruzioni relative agli snippet intervengono invece sulla quantità di contenuto che può essere mostrata nelle anteprime.

Un blocco della scansione tramite robots.txt non garantisce, da solo, che un URL scompaia dai risultati di ricerca, perché il motore potrebbe conoscerne l'esistenza attraverso collegamenti esterni senza averne acquisito il contenuto.

Confondere questi strumenti può produrre conseguenze indesiderate sulla visibilità organica di un sito.

Il ruolo dell'IETF e i limiti di uno standard ancora in discussione

L'iniziativa annunciata da Google si inserisce in un percorso di standardizzazione che coinvolge soggetti con interessi differenti: sviluppatori di sistemi AI, editori, organizzazioni della società civile, esperti tecnici e rappresentanti delle istituzioni.

L'IETF è l'organizzazione internazionale che sviluppa numerosi standard e protocolli utilizzati per il funzionamento di Internet. Il gruppo AIPREF lavora a un vocabolario condiviso attraverso il quale descrivere le preferenze dei titolari dei contenuti rispetto a specifiche modalità di utilizzo da parte dei sistemi automatizzati.

Il documento A Vocabulary For Expressing AI Usage Preferences, nella versione pubblicata il 14 settembre 2026, definisce diverse categorie di impiego delle risorse digitali. Tuttavia, il testo evidenzia che alcune parti del vocabolario non hanno ancora raggiunto un consenso definitivo.

La proposta relativa al policy token comune cerca di rendere utilizzabile una parte di questo lavoro senza attendere la conclusione di tutte le discussioni sulle altre categorie.

Il meccanismo è descritto nell'Internet-Draft Machine-Readable Training Preference Signal, pubblicato il 30 ottobre 2026. Il documento chiarisce che la soluzione non modifica le regole fondamentali del protocollo robots.txt, ma associa un significato specifico a un gruppo di istruzioni identificato dal nuovo token.

La scelta riduce la complessità tecnica necessaria per adottare il segnale, perché sfrutta strutture già presenti nella maggior parte delle configurazioni web.

Resta però una distinzione tra pubblicazione di una proposta tecnica, riconoscimento da parte degli operatori e adozione generalizzata.

Un Internet-Draft non equivale automaticamente a uno standard Internet definitivo. Le specifiche possono subire modifiche nel corso del confronto tecnico e la loro efficacia pratica dipende dai sistemi che decidono di implementarle.

Google ha indicato il 2027 come periodo previsto per introdurre il supporto, insieme ad altri fornitori di intelligenza artificiale. La documentazione dedicata ai crawler fa riferimento all'inizio del 2027, ma non stabilisce una data vincolante per l'adozione da parte dell'intero settore.

Il controllo dei crawler AI con robots.txt rimane quindi un progetto in fase di definizione e implementazione, con una direzione tecnica già delineata ma senza una copertura universale garantita.

Le implicazioni per editori e siti aziendali

La possibilità di esprimere una preferenza comune interessa soprattutto i siti che pubblicano grandi quantità di contenuti originali.

Le testate giornalistiche producono quotidianamente articoli, approfondimenti, fotografie e materiali informativi che possono rappresentare risorse utilizzabili nello sviluppo dei modelli generativi. Gli editori devono valutare come preservare il valore economico di questi contenuti, anche rispetto alla possibilità che vengano utilizzati in servizi che rispondono direttamente alle domande degli utenti.

Il controllo condiviso potrebbe semplificare l'espressione delle preferenze, ma non risolve automaticamente le questioni relative alla remunerazione, alle licenze e alla tutela dei diritti.

Lo stesso vale per le aziende che investono nella pubblicazione di guide tecniche, ricerche, documentazione di prodotto e contenuti specialistici.

Un'impresa potrebbe voler rendere accessibili tali informazioni ai motori di ricerca per acquisire traffico qualificato, limitando contemporaneamente il loro impiego nell'addestramento di modelli generativi.

Questa esigenza richiede una configurazione capace di separare i diversi utilizzi del materiale pubblicato, evitando interventi indiscriminati sulla scansione.

Il controllo dei crawler AI con robots.txt offre una possibile risposta a questa necessità, soprattutto quando il sito deve gestire istruzioni destinate a più fornitori.

Rimane tuttavia il problema dell'effettivo riconoscimento delle preferenze.

Il file robots.txt è uno strumento di comunicazione delle istruzioni ai sistemi automatici, non un dispositivo di protezione che impedisce fisicamente l'accesso ai contenuti. Un operatore che non supporta il nuovo segnale, oppure che non rispetta le preferenze espresse dal proprietario del sito, potrebbe continuare a trattare le informazioni secondo modalità differenti.

L'esistenza di una regola pubblicata non dimostra inoltre che i contenuti già acquisiti in passato siano stati esclusi dai processi di addestramento.

La proposta prende in considerazione le preferenze associate ai contenuti nel momento della loro acquisizione, ma non introduce da sola un sistema universale per verificare retroattivamente l'impiego dei dati, ottenere la cancellazione delle informazioni già utilizzate o accertare il comportamento di ciascun modello.

Per gli editori, quindi, il segnale tecnico può diventare parte di una strategia più ampia di gestione dei contenuti, senza sostituire le valutazioni contrattuali e giuridiche.

Che cosa devono verificare i responsabili SEO

L'introduzione del nuovo sistema richiederà particolare attenzione nella manutenzione dei file robots.txt.

La prima verifica riguarda le istruzioni già presenti per Googlebot e per gli altri crawler. Le regole utilizzate per impedire la scansione di directory tecniche, risorse riservate o sezioni non rilevanti per la ricerca devono continuare a svolgere la propria funzione.

Le preferenze sull'addestramento dovranno essere gestite separatamente, senza modificare involontariamente le condizioni di accesso dei motori di ricerca.

Un secondo controllo riguarda Google-Extended. I siti che hanno già configurato esplicitamente questo identificatore dovranno valutare la compatibilità tra le preferenze esistenti e quelle eventualmente introdotte attraverso il token condiviso.

L'annuncio Google prevede la convivenza dei due sistemi, rendendo possibile una gestione differenziata. Tuttavia, il significato operativo delle configurazioni deve essere verificato rispetto alla documentazione aggiornata dei singoli fornitori.

Un'altra questione interessa i siti con una struttura complessa, organizzati in più sottodomini o ospitati su infrastrutture differenti.

Le istruzioni robots.txt vengono interpretate in relazione all'host e all'ambito per cui il file è valido. La presenza di un'unica regola sul dominio principale non implica necessariamente che le stesse preferenze si applichino automaticamente a tutti i sottodomini.

Occorre inoltre considerare i sistemi di gestione dei contenuti che generano dinamicamente robots.txt, le configurazioni dei server e le eventuali modifiche introdotte da plugin SEO o servizi di distribuzione dei contenuti.

Una configurazione apparentemente corretta potrebbe essere sovrascritta da un aggiornamento oppure non essere effettivamente pubblicata nell'host previsto.

Il controllo dei crawler AI con robots.txt richiederà quindi verifiche sia sulla sintassi sia sull'effettiva disponibilità delle istruzioni, tenendo presente che la loro presenza nel file non dimostra il rispetto delle preferenze da parte degli operatori.

Per i responsabili SEO sarà altrettanto necessario evitare interpretazioni errate dei dati di Google Search Console. Gli strumenti di monitoraggio della scansione e dell'indicizzazione non costituiscono, di per sé, una certificazione sull'utilizzo o sul mancato utilizzo dei contenuti durante l'addestramento dei modelli.

Un sito può continuare a ricevere visite dai crawler tradizionali anche quando esprime una preferenza contraria all'AI training. Analogamente, la presenza di una pagina nell'indice di Google non permette di stabilire se il suo contenuto sia stato utilizzato per modificare i parametri di un modello generativo.

La questione dell'adozione da parte degli operatori AI

Il valore del nuovo segnale dipenderà dalla diffusione del supporto tra le aziende che sviluppano e distribuiscono sistemi di intelligenza artificiale.

Oggi le preferenze pubblicate attraverso i file robots.txt devono confrontarsi con un insieme di identificatori proprietari e regole specifiche. Un linguaggio comune potrebbe ridurre il numero di configurazioni necessarie e rendere più comprensibili le scelte espresse dai titolari dei siti.

L'adozione rimarrà però progressiva. Gli operatori che riconosceranno il policy token potranno interpretare il segnale secondo le specifiche condivise, mentre quelli che non lo implementeranno non saranno automaticamente vincolati dal nuovo meccanismo tecnico.

Si pone anche un problema di verifica indipendente. Le attività di scansione possono essere osservate attraverso i log del server, mentre l'impiego effettivo di un contenuto nei processi interni di addestramento risulta molto più difficile da accertare dall'esterno.

Un proprietario può individuare le richieste effettuate da determinati crawler, ma non ricostruire attraverso quei soli dati tutte le successive operazioni compiute sulle informazioni raccolte.

Il dibattito riguarda anche la dimensione normativa. Nell'annuncio del 30 ottobre Google richiama il Codice di buone pratiche europeo per i fornitori di modelli di intelligenza artificiale per finalità generali, sviluppato nel quadro dell'AI Act, che riconosce robots.txt come uno degli strumenti principali per esprimere preferenze leggibili automaticamente.

Il riconoscimento di questo meccanismo non significa tuttavia che ogni istruzione inserita nel file determini, in qualsiasi circostanza, un divieto giuridico assoluto. La portata delle preferenze dipende anche dalla normativa applicabile, dalle condizioni di utilizzo dei contenuti e dalle eventuali eccezioni previste dal diritto d'autore.

La stessa documentazione AIPREF distingue l'espressione tecnica delle preferenze dalle conseguenze giuridiche che possono derivarne nelle diverse giurisdizioni.

Nel 2027, con l'introduzione del supporto annunciato da Google, sarà possibile valutare più concretamente come il nuovo policy token verrà interpretato dai sistemi aderenti e quali differenze emergeranno rispetto alle istruzioni proprietarie già disponibili.

Per i siti che oggi utilizzano Google-Extended o altri controlli specifici, la prospettiva più rilevante è la possibilità di affiancare alle configurazioni esistenti una preferenza condivisa, senza rinunciare alla presenza nelle ricerche tradizionali.

L'effettiva utilità del sistema si misurerà soprattutto sulla capacità degli operatori AI di riconoscere le stesse istruzioni, applicarle in modo coerente e rendere verificabile, almeno sul piano delle procedure adottate, il rispetto delle scelte espresse dai titolari dei contenuti.