Una riga sbagliata in robots.txt può togliere contenuti dai sistemi AI senza produrre l’effetto che l’azienda si aspetta. Il nuovo segnale condiviso __usage_ai-training riduce il lavoro di manutenzione, ma non è un interruttore universale: riguarda il training dei modelli generativi, non blocca automaticamente i crawler, non elimina dati già raccolti e non decide da solo se una pagina può comparire nelle risposte AI.

Per una PMI la conseguenza pratica è semplice: prima di modificare il file bisogna decidere quale uso dei contenuti si vuole limitare. Proteggere un’area riservata, rinunciare al training e conservare la visibilità nelle risposte con fonti sono tre problemi diversi. Trattarli come se fossero lo stesso problema porta a configurazioni fragili e a decisioni impossibili da verificare.

Il 30 ottobre 2026 OpenAI, Google e Microsoft hanno annunciato il supporto al segnale comune proposto nell’Internet-Draft IETF “Machine-Readable Training Preference Signal”. Anthropic è indicata come organizzazione dell’autore del draft e ha già avviato l’implementazione, mentre gli altri provider hanno comunicato finestre diverse. Questa guida serve a preparare una policy verificabile oggi, senza fingere che il nuovo controllo sia già applicato ovunque.

Cosa cambia davvero nel robots.txt

Finora un gestore doveva mantenere gruppi separati per i crawler dei diversi provider. Il nuovo meccanismo usa invece un policy token nel campo User-Agent:

User-Agent: __usage_ai-training
Disallow: /

Il significato dichiarato è: non usare le risorse comprese nel percorso per modificare i parametri appresi di un modello AI generativo. La sintassi riutilizza le regole ordinarie di robots.txt: gruppi, percorsi e precedenza della corrispondenza più specifica. Non introduce una nuova direttiva.

Il punto da non perdere è scritto nel draft: il policy token non è un crawler e la preferenza non è una direttiva di accesso. Se l’obiettivo è impedire a un bot specifico di scaricare una pagina, restano necessarie le regole dedicate al suo user agent oppure controlli a livello di server, CDN o applicazione. Il gruppo generico User-Agent: * non va interpretato come preferenza per il training.

Anche lo stato del documento conta. Al 31 ottobre 2026 è un Internet-Draft individuale attivo, non uno standard IETF approvato. Può essere aggiornato, sostituito o ritirato; la versione iniziale scade il 3 maggio 2027. È abbastanza concreta da meritare una voce nella governance del sito, ma non abbastanza stabile da giustificare la rimozione immediata di tutte le regole esistenti.

Training, crawling e grounding sono tre leve

Una policy utile parte dagli usi, non dai nomi dei bot. Per ogni area del sito conviene scegliere separatamente queste tre leve:

  • Crawling: il sistema può recuperare la risorsa? È una scelta tecnica di accesso, espressa con regole per crawler e, quando serve, con autenticazione o controlli infrastrutturali.
  • Training: il contenuto recuperato può contribuire a modificare i parametri di un modello generativo? È l’ambito del nuovo __usage_ai-training.
  • Grounding: il contenuto può essere usato al momento della risposta per fornire informazioni aggiornate, link e citazioni? Non coincide con il training e può avere controlli separati.

Microsoft, per esempio, ha annunciato preferenze indipendenti per training e grounding. Dal 1° febbraio 2027 intende leggere il nuovo segnale di training e supportare impostazioni a livello di pagina. Per il grounding prevede Allow, DisallowExtended e Disallow; la seconda opzione limita l’uso alle esperienze operate da Microsoft, escludendo i servizi di grounding forniti a terzi. Queste scelte non modificano l’idoneità ai risultati tradizionali di Bing, ma una restrizione sul grounding riduce la possibilità di comparire nelle esperienze AI.

Google ha comunicato che mira al supporto nel 2027. Se trova il nuovo opt-out e non esiste una regola esplicita per Google-Extended, intende trattarlo come un blocco di Google-Extended. Allo stesso tempo specifica che i siti che consentono Google-Extended possono risultare idonei alla presenza, con link, nelle risposte basate su fonti delle app Gemini. OpenAI ha indicato un’implementazione “nei prossimi mesi”, mantenendo in parallelo i controlli specifici esistenti.

La mia raccomandazione tecnica è non impostare un opt-out globale per riflesso. Un sito che vive di autorevolezza, lead organici e citazioni potrebbe voler negare il training ma consentire il grounding. Un’area con documentazione proprietaria riservata non dovrebbe invece affidarsi a robots.txt: deve richiedere autenticazione, perché il file pubblica preferenze e non crea una barriera di sicurezza.

Una matrice prima della configurazione

Prima di toccare WordPress, apri un foglio con quattro colonne: percorso, tipo di contenuto, uso consentito, controllo tecnico. Bastano poche righe per evitare una policy indistinta.

  • /blog/: contenuti editoriali pubblici; training da decidere, grounding normalmente utile, crawling dei motori consentito.
  • /documentazione/: manuali pubblici; training valutato in base alla licenza, grounding utile se genera citazioni corrette.
  • /area-clienti/: materiale non pubblico; accesso con login e risposta HTTP coerente, non semplice disallow.
  • /preventivi/ o endpoint operativi: accesso applicativo limitato, esclusione dall’indice e log di sicurezza.

Questa matrice deve avere un responsabile e una data di revisione. I nomi dei crawler cambiano, le implementazioni arrivano in momenti diversi e il draft può evolvere. Senza un proprietario della policy, il file tende ad accumulare blocchi copiati da articoli diversi, senza sapere quali siano ancora necessari.

La scelta va collegata anche alla strategia di traffico. La dipendenza da una sola piattaforma è un rischio, ma rinunciare a ogni superficie AI può ridurre i percorsi con cui un potenziale cliente scopre il brand. Nel caso di un blog aziendale, il tema non è “AI sì o no”: è decidere quali contenuti possono generare visibilità e quali rappresentano un patrimonio da licenziare o proteggere. È lo stesso principio operativo discusso nella guida Traffico web: la lezione di Reddit: distribuzione e controllo vanno progettati insieme.

Come implementarlo in WordPress senza sorprese

WordPress genera un robots.txt virtuale quando non trova un file fisico nella root pubblica. Plugin SEO, configurazioni del server e servizi CDN possono modificarlo o sostituirlo. Per questo il primo passo non è aprire l’editor del tema, ma leggere la risposta effettivamente servita all’esterno:

curl -i https://esempio.it/robots.txt

Controlla codice HTTP, Content-Type, eventuali redirect e contenuto finale. Se il file è gestito da un plugin SEO, usa il suo punto di configurazione documentato. Se è fisico, applica la modifica nel repository o nel processo di deploy. Evita snippet nel tema quando la policy appartiene all’infrastruttura: un cambio tema non dovrebbe modificare le regole dei crawler.

Una configurazione prudente, durante la fase di transizione, mantiene il segnale comune e i controlli specifici già adottati. L’esempio seguente esprime solo un’intenzione di governance; i nomi e le regole dedicate devono essere verificati sulle documentazioni aggiornate dei provider:

User-Agent: __usage_ai-training
Disallow: /

# Mantieni temporaneamente i controlli specifici esistenti
# finché ogni provider non conferma l'implementazione.

Se vuoi escludere soltanto una sezione, usa il percorso più ristretto:

User-Agent: __usage_ai-training
Disallow: /ricerca-proprietaria/
Allow: /

Non inserire nel file percorsi che rivelano aree sensibili e non considerare il loro disallow una protezione. Per accessi remoti, fornitori e pannelli, applica controlli reali e revocabili come descritto in WordPress: revoca gli accessi remoti.

Su installazioni multisito, ambienti con cache aggressiva o proxy, verifica ogni hostname separatamente. www, dominio nudo e sottodomini possono servire file diversi. Dopo la modifica svuota soltanto le cache coinvolte, poi ripeti il controllo da una rete esterna. Una risposta corretta in wp-admin non dimostra cosa riceva un crawler.

Il collaudo deve misurare quattro cose

Il test non finisce quando il file contiene la riga prevista. Registra almeno quattro evidenze:

  1. Distribuzione: il dominio pubblico restituisce il file aggiornato con HTTP 200, senza redirect inattesi o versioni diverse in cache.
  2. Ambito: le regole colpiscono i percorsi scelti e non bloccano per errore CSS, JavaScript, immagini o sezioni necessarie all’indicizzazione.
  3. Interpretazione: i gruppi dedicati non sono fusi per errore e la corrispondenza dei percorsi produce l’esito atteso.
  4. Effetto: log server, strumenti dei provider e traffico referral mostrano cosa cambia dopo che i sistemi hanno riletto la policy.

Salva una copia datata del file prima e dopo la modifica. Annota chi ha approvato la decisione, quali provider erano già compatibili e quando rieseguire il test. Questo trasforma un frammento tecnico in un controllo di governance verificabile.

I log richiedono cautela. Vedere richieste con uno user agent noto prova che una stringa ha raggiunto il server, non l’identità certa del chiamante né l’uso successivo dei dati. Il nuovo segnale è volontario: funziona per gli operatori che lo riconoscono e lo rispettano. Rate limiting, firewall applicativo e autenticazione rispondono a minacce diverse e non vanno sostituiti con una preferenza dichiarativa.

Dopo il deploy monitora almeno due finestre: una breve, per intercettare errori di cache o indicizzazione, e una più lunga, compatibile con i tempi di recrawl. Microsoft chiarisce che pubblicare la preferenza non significa attivarla immediatamente: il sistema deve recuperare la pagina o il file. Anche IndexNow può favorire la scoperta della modifica, ma non garantisce una data di recrawl.

Gli errori più costosi da evitare

Il primo errore è scrivere che il segnale “blocca lo scraping”. La formulazione è comoda ma imprecisa: esprime una preferenza d’uso per il training. Un provider può continuare a recuperare contenuti per ricerca, grounding o richieste dell’utente, in base ai propri crawler e alle regole applicabili.

Il secondo è confondere futuro e presente. Il 31 ottobre 2026 il supporto non è uniforme: OpenAI parla di prossimi mesi, Google del 2027 e Microsoft del 1° febbraio 2027. Le vecchie regole non vanno eliminate finché non esiste evidenza che la nuova preferenza copra davvero i provider rilevanti.

Il terzo è usare robots.txt per contenuti confidenziali. Il file è pubblico, l’adesione è volontaria e i percorsi elencati possono perfino attirare attenzione. Dati personali, contratti, listini riservati e materiali clienti devono stare dietro autenticazione e autorizzazione.

Il quarto è non distinguere training e grounding. Per molte PMI la presenza in una risposta con link può avere valore commerciale, mentre il training non offre un ritorno misurabile. Una policy che blocca entrambi senza una decisione esplicita rischia di sacrificare visibilità senza aumentare davvero la sicurezza.

Il quinto è trattare il draft come definitivo. Inserisci la revisione della sintassi nel calendario tecnico per il primo trimestre 2027. Controlla la versione del documento IETF, le pagine ufficiali dei provider e la risposta pubblica del sito. Una regola copiata oggi e dimenticata per due anni non è governance: è debito operativo.

Il piano operativo da completare in 30 minuti

  1. Elenca le aree pubbliche, proprietarie e riservate del sito.
  2. Per ogni area decidi separatamente crawling, training e grounding.
  3. Apri il robots.txt pubblico e individua chi lo genera davvero.
  4. Conserva i controlli specifici attuali e aggiungi il segnale comune solo dove la policy è approvata.
  5. Verifica HTTP, cache, hostname e percorsi da una rete esterna.
  6. Registra la configurazione, il responsabile e una revisione entro il 31 marzo 2027.

La decisione corretta non è necessariamente bloccare tutto. È rendere esplicito l’uso consentito, applicare il controllo adatto e conservare prove che la configurazione servita corrisponda alla policy. Il nuovo token riduce la manutenzione, ma solo una matrice per percorso impedisce che la semplificazione tecnica diventi una rinuncia involontaria alla visibilità.

Fonti

Approfondimenti