Google promette un opt-out AI comune. Ma quale regola prevale?

Nel file robots.txt possiamo scrivere una regola che impedisce a un crawler di accedere a una pagina. Oppure, secondo una proposta annunciata oggi da Google, possiamo dichiarare che quel contenuto non dovrebbe essere usato per addestrare modelli generativi. Stesso file, due domande completamente diverse. E confonderle è un ottimo modo per costruire una configurazione apparentemente rigorosa che non controlla ciò che pensiamo.

Il 30 ottobre 2026 Google Search Central ha annunciato l’intenzione di supportare nel 2027 un segnale condiviso di preferenza per l’addestramento AI. L’obiettivo è evitare che ogni editore debba mantenere un elenco infinito di istruzioni proprietarie. Non è però un nuovo standard già operativo, e soprattutto non è un firewall contro lo scraping.

La distinzione che viene prima di ogni configurazione

Un crawler chiede una risorsa. Un sistema AI può poi usare quella risorsa in modi diversi: per indicizzare una pagina, per costruire un indice di ricerca, per fornire contesto a una risposta oppure per aggiornare i parametri di un modello durante l’addestramento. La richiesta HTTP e l’utilizzo successivo non sono la stessa operazione.

Una regola Disallow associata a Googlebot riguarda l’accesso del crawler e può compromettere la presenza della pagina nella Ricerca Google. Una regola di preferenza sull’uso dei dati riguarda invece ciò che un soggetto dichiara di poter fare con contenuti già ottenuti. È una separazione architetturale, prima ancora che SEO.

Bloccare l’accesso a una risorsa e dichiarare come può essere utilizzata sono due contratti diversi. Se li metti nello stesso file, devi comunque continuare a ragionare come se fossero due sistemi.

Che cosa ha annunciato davvero Google

Google propone un policy token condiviso, leggibile in robots.txt da più fornitori AI. L’editore potrà esprimere una preferenza generale contro il training e, contemporaneamente, mantenere istruzioni specifiche per singoli provider. La data indicata da Google è il 2027: oggi stiamo parlando di un impegno pubblico e di una proposta tecnica, non di una funzionalità universalmente implementata.

Il dettaglio interessante non è l’esistenza di un nuovo nome da aggiungere a un file. È la precedenza. Google afferma che, quando trova un opt-out condiviso e non esiste un’istruzione esplicita per Google-Extended, intende interpretare il primo come se fosse stato negato l’uso tramite Google-Extended. Se invece l’editore ha scritto una scelta specifica per Google-Extended, quella scelta può differenziare il trattamento del contenuto rispetto alla preferenza generale.

Questa distinzione produce casi concreti: un sito può esprimere una preferenza negativa comune, ma mantenere una scelta diversa per Google; oppure può voler mantenere il proprio accesso alla Ricerca senza autorizzare determinati utilizzi per l’addestramento. Non basta sapere che un token esiste: serve sapere chi lo interpreta, con quali priorità e per quali prodotti.

Il token proposto non è un nuovo crawler

Il documento draft-kelley-aipref-training-preference-signal-00, pubblicato il 30 ottobre 2026 come Internet-Draft individuale, propone il token __usage_ai-training. Usa i normali gruppi User-agent, Allow e Disallow già presenti in robots.txt. Il token descrive una finalità di utilizzo, non un processo che si presenta con quell’User-Agent durante una richiesta HTTP.

Il seguente è un esempio del draft, non una configurazione consigliata oggi per la produzione:

User-agent: __usage_ai-training
Disallow: /
Allow: /press-kit/

Nella semantica proposta, questo esprime una preferenza contraria al training per il sito, con eccezione per il percorso /press-kit/. Non ordina ai crawler di non scaricare le pagine. Un parser che non conosce il token continuerà a comportarsi come prima. Il documento precisa anche che il gruppo User-agent: * non deve essere interpretato automaticamente come preferenza per il policy token.

C’è poi un secondo punto che merita precisione: questo draft individuale non coincide con il documento del gruppo IETF AIPREF che studia la direttiva Content-Usage e l’omonimo header HTTP. Il draft-ietf-aipref-attach affronta il trasporto delle preferenze anche attraverso una sintassi diversa, come Content-Usage: train-ai=n. Sono lavori collegati, ma non due nomi intercambiabili dello stesso meccanismo. Entrambi vanno trattati come documenti in evoluzione, non come RFC definitive.

Google-Extended non è Googlebot

Un altro errore frequente è cercare Google-Extended nei log del server come se fosse uno User-Agent HTTP autonomo. La documentazione ufficiale dei crawler Google chiarisce che Google-Extended è un token di controllo: il crawling avviene tramite gli User-Agent già esistenti.

Secondo Google, Google-Extended controlla determinati utilizzi dei contenuti per il training dei modelli Gemini e per alcune forme di grounding nelle applicazioni Gemini e su Vertex AI. Google specifica inoltre che il token non influenza l’inclusione o il ranking nella Ricerca Google. Questa affermazione riguarda Google-Extended, non ogni possibile funzione AI di Google Search: sarebbe scorretto dedurre che una singola regola controlli indistintamente ogni esperienza generativa del motore.

Tre situazioni da non mescolare

Primo caso: un sito vuole restare indicizzabile in Google Search ma limitare gli utilizzi AI coperti da Google-Extended. Deve distinguere i controlli di crawling da quelli di uso dei contenuti. Secondo caso: il sito vuole una preferenza generale per più fornitori; il segnale condiviso potrebbe ridurre la manutenzione, ma solo quando i provider lo supporteranno davvero. Terzo caso: il sito vuole un’eccezione per Google: la relazione tra token comune e Google-Extended esplicito diventa il requisito da verificare.

Una preferenza dichiarata non è una protezione tecnica

Il punto meno comodo è anche quello più importante. Un file pubblico non impedisce fisicamente a un attore non conforme di scaricare contenuti o di usarli contro la preferenza dichiarata. Un protocollo può definire una semantica condivisa; non può garantire da solo l’adesione dei soggetti che lo ignorano. Il draft distingue infatti espressamente le preferenze d’uso dai segnali di gestione del traffico.

In pratica, per un editore servono almeno tre livelli di controllo: una policy chiara e documentata, una verifica dei comportamenti osservabili dei crawler e una valutazione separata degli strumenti contrattuali o giuridici disponibili. Non sono equivalenti. I log HTTP possono mostrare richieste e accessi, ma non dimostrano da soli come un contenuto sia stato utilizzato nel training di un modello.

Questo tema si collega a una questione che avevo già affrontato parlando di Cloudflare e monetizzazione dell’uso dei contenuti da parte dell’AI: misurare un crawl e misurare il valore prodotto dall’uso di un contenuto sono operazioni diverse. Qui il problema è ancora più a monte: prima di misurare o negoziare un utilizzo, bisogna saperlo descrivere senza ambiguità.

Cosa fare oggi su un sito WordPress

La prima cosa sensata è non trasformare una proposta del 2027 in una modifica frettolosa del robots.txt di produzione. Chi sviluppa temi, plugin SEO o sistemi editoriali può invece preparare il modello dati e la procedura di verifica.

Separare le intenzioni

Definire esplicitamente se si vuole regolare la scansione, l’indicizzazione, l’uso per training o altre forme di utilizzo. Un’opzione unica chiamata “blocca AI” è comoda da mostrare nel backend, ma tecnicamente nasconde decisioni diverse. Anche un plugin dovrebbe poter spiegare quale provider e quale comportamento viene realmente coinvolto.

Verificare le precedenze

Quando il supporto sarà documentato e disponibile, testare combinazioni di preferenza generale, istruzione esplicita Google-Extended e assenza di entrambe. Una regola generale non dovrebbe cancellare silenziosamente una scelta specifica. Occorre inoltre verificare che il robots.txt effettivamente servito dal sito corrisponda a quello configurato nel CMS, specialmente con cache, CDN e generazione dinamica.

Misurare ciò che è misurabile

Conservare versioni e date delle policy, annotare i provider che dichiarano di supportarle, monitorare le richieste e verificare le risposte HTTP. Non trasformare l’assenza di un User-Agent specifico in prova che un utilizzo non avvenga. Per un sistema SEO serio l’osservabilità conta, ma conta anche sapere che cosa non può dimostrare.

La differenza tra una regola e un sistema

La direzione annunciata da Google ha un vantaggio concreto: ridurre il numero di istruzioni proprietarie da mantenere e rendere più leggibile la volontà degli editori. È un progresso possibile, non ancora un risultato verificato. Il lavoro IETF è aperto, l’implementazione è prospettata per il 2027 e la conformità effettiva dipenderà dai provider.

La domanda utile per chi gestisce siti non è “quale riga devo copiare oggi?”. È: quale utilizzo voglio consentire, quale segnale lo rappresenta, chi promette di rispettarlo e come verifico che il mio sistema non stia dicendo due cose in contraddizione? Il file è l’ultimo passaggio. Prima viene l’architettura della scelta.