Un sito WordPress può essere indicizzato dai motori di ricerca e, nello stesso tempo, dichiarare che i suoi contenuti non devono essere usati per addestrare modelli generativi. Finora questa scelta richiedeva regole diverse per ogni fornitore. Dal 30 ottobre 2026 esiste una proposta comune: un token in robots.txt pensato per esprimere la preferenza sull’uso dei contenuti, senza togliere le pagine dai risultati di ricerca.
Cosa cambia nel controllo dei contenuti
La proposta si chiama Machine-Readable Training Preference Signal ed è un Internet-Draft, quindi un documento di lavoro e non uno standard IETF approvato. Introduce il token __usage_ai-training: chi gestisce un sito può associargli regole per tutto il dominio oppure per percorsi specifici. Il vantaggio operativo è ridurre la manutenzione di istruzioni separate per ogni azienda. Google ha indicato il supporto per l’inizio del 2027; Microsoft applicherà le nuove preferenze dal 1° febbraio 2027. OpenAI ha annunciato l’adozione nei prossimi mesi, mentre Anthropic sta già lavorando all’implementazione.
Il punto importante per una PMI è un altro: questa preferenza riguarda il training dei modelli generativi, non l’indicizzazione tradizionale. Microsoft specifica che le pagine possono continuare ad apparire in Bing. Anche Google tratta separatamente i controlli dedicati ai propri crawler. Chi sta già misurando la differenza tra SEO e visibilità nei sistemi AI non deve quindi trasformare una decisione sull’uso dei contenuti in un blocco involontario del traffico organico.
La regola da preparare in robots.txt
Per esprimere l’opt-out sull’intero sito, la configurazione proposta è breve. Va aggiunta come gruppo autonomo, senza sostituire le regole già presenti per Googlebot, Bingbot, GPTBot o altri crawler specifici:
User-Agent: __usage_ai-training
Disallow: /Si può anche scegliere un controllo più granulare. Il draft mostra, per esempio, un sito che vieta il training su tutti i percorsi ma consente l’uso della cartella /press-kit/ aggiungendo Allow: /press-kit/. La preferenza viene letta sul contenuto recuperato mentre quella versione di robots.txt è attiva; non cancella dati raccolti in precedenza e non obbliga i soggetti che non adottano il meccanismo.
Questa distinzione evita una promessa falsa: il file non è un firewall. Il draft IETF dice esplicitamente che il token non è una direttiva sul comportamento di crawling. Per limitare davvero le richieste automatiche servono ancora regole rivolte ai singoli user agent e, quando necessario, controlli a livello di CDN o web application firewall.
Come applicarla su WordPress senza rischi
Prima di modificare il file, apri https://tuodominio.it/robots.txt e salva una copia del contenuto attuale. Su WordPress il file può essere fisico nella root del sito oppure generato dinamicamente dal CMS o da un plugin SEO: modificare il posto sbagliato produce una regola che non verrà mai servita. Poi aggiungi il gruppo dedicato in staging o in una finestra controllata e verifica la risposta pubblica con un browser e con curl.
- Controlla che la risposta sia HTTP 200 e contenga una sola volta il nuovo gruppo.
- Verifica che
User-Agent: *, sitemap e regole dei motori di ricerca siano rimasti invariati. - Decidi se esistono percorsi da consentire, come un press kit o una documentazione pubblica.
- Monitora log e strumenti webmaster dopo il rilascio, senza aspettarti un calo immediato delle richieste.
Su siti con più ambienti o CDN, ripeti il controllo dal dominio pubblico: cache e configurazioni edge possono servire un file diverso da quello visto nel pannello WordPress. Per osservare cosa accade davvero, affianca questa scelta a un metodo per tracciare le chiamate AI in WordPress.
L’errore da evitare e il take operativo
L’errore più costoso è cancellare oggi tutte le regole specifiche pensando che il token comune le abbia già sostituite. Al 31 ottobre 2026 il documento è ancora un Internet-Draft, le finestre di adozione non coincidono e i controlli proprietari possono avere precedenza. La mossa prudente è aggiungere il segnale condiviso alla configurazione esistente, documentare la decisione e programmare una revisione quando i fornitori avranno completato il rollout.
Il take operativo è semplice: tratta robots.txt come una policy versionata, non come un file da correggere una volta e dimenticare. Registra chi ha deciso l’opt-out, quali percorsi copre e quando va riesaminato. In questo modo la scelta resta comprensibile anche quando cambiano plugin, agenzia o responsabile interno.
Fonti: Internet-Draft IETF, Bing, Google Crawling Infrastructure e The Verge.