Come disattivare le funzioni AI di WordPress (core o plugin, senza giri di parole)

Quasi tutte le funzioni AI che si vogliono eliminare da WordPress arrivano da un plugin, dall’hosting o da WordPress.com, non dal core self-hosted. Prima di incollare uno snippet con remove_action in functions.php, apri l’elenco dei plugin e individua cosa sta davvero disegnando quel pannello AI: rimuovere una funzione che il core non include è tempo buttato su un sito che già si comporta male.

La distinzione conta perché le soluzioni sono completamente diverse. Una funzione di un plugin ha un interruttore nelle impostazioni. Una funzione iniettata dall’hosting vive nel pannello di controllo dell’hosting, non nella bacheca di WordPress. E la questione che le persone intendono davvero quando dicono “disattivare l’AI” — impedire alle aziende di addestrare i modelli sui propri articoli — non è affatto un’impostazione di WordPress. È un problema di robots e configurazione del server.

Cosa fa parte del core e cosa no

Il core di WordPress self-hosted non include un assistente di scrittura AI, un chatbot o un generatore di immagini pronti all’uso. Se vedi l’icona con le stelline dell’AI nell’editor a blocchi, qualcosa l’ha installata.

Da dove arrivano davvero le funzioni AI:

Origine	Funzione tipica	Dove si disattiva
Jetpack	Blocco e pannello AI Assistant nell’editor	Impostazioni Jetpack, interruttore del modulo
Plugin AI dedicati	Generatori di contenuti, chatbot, testi alternativi automatici	Schermata delle impostazioni del plugin
Plugin SEO	Suggerimenti AI per titolo e descrizione	Impostazioni del plugin, di solito funzione per funzione
Page builder	Generazione AI di testi e immagini nell’interfaccia del builder	Impostazioni del builder o pannello account
Hosting gestiti	Assistenti AI iniettati tramite mu-plugin o bacheca	Pannello di controllo dell’hosting
WordPress.com	Strumenti di scrittura AI in hosting	Impostazioni dell’account WordPress.com, non del tuo sito

Il progetto WordPress ha comunque uno sviluppo attivo legato all’AI: feature plugin sperimentali che un giorno potrebbero entrare nel core. Se usi una versione recente e noti qualcosa di “AI” che non riesci ad attribuire a un plugin, controlla prima l’elenco dei plugin installati e poi il changelog della tua versione, invece di dare per scontata un’impostazione predefinita del core da filtrare via. È una cautela voluta: in questo ambito le affermazioni legate a una versione specifica invecchiano in fretta, e sbagliarne una ti porta a modificare file senza motivo.

Individuare cosa lo sta davvero aggiungendo

Disattiva i plugin a gruppi finché il pannello AI non sparisce. Metodo grezzo, ma ti dà una risposta certa invece di un’ipotesi.

Se hai WP-CLI, elenca prima tutto ciò che è attivo:

wp plugin list --status=active --field=name

Poi controlla il codice iniettato dall’hosting, che non compare nella normale schermata dei plugin:

ls -la wp-content/mu-plugins/

I must-use plugin si caricano automaticamente e non si possono disattivare dalla bacheca. Se il tuo hosting ha piazzato lì un assistente AI, l’unica rimozione pulita passa dal loro pannello di controllo: cancellare il file spesso significa vederlo ricomparire al successivo aggiornamento della piattaforma.

Disattivarlo nel modo giusto

Usa l’impostazione del plugin. È la risposta noiosa ed è quella corretta. Jetpack in particolare è costruito su moduli attivabili singolarmente, quindi puoi spegnere AI Assistant mantenendo statistiche, backup o qualsiasi altra cosa ti serva. La maggior parte dei plugin AI dedicati offre una casella di attivazione per ogni funzione.

Se non usi il plugin per altro, disattivalo del tutto. Un plugin AI lasciato installato ma “disabilitato” carica comunque il suo codice a ogni richiesta. Disattivarlo è più rapido, più sicuro e concretamente più leggero di qualsiasi filtro.

Sganciare gli hook con remove_action è l’ultima risorsa. Funziona davvero, ma solo se conosci con esattezza nome dell’hook, callback e priorità registrati dal plugin, e solo finché il plugin non rinomina uno di questi elementi:

// Only if you have verified the exact hook, callback and priority.
// Runs late so the plugin has already registered its own hooks.
add_action( 'init', function () {
    remove_action( 'enqueue_block_editor_assets', array( 'Some_Plugin_Class', 'enqueue_ai_panel' ), 10 );
}, 99 );

Il costo reale: si rompe in silenzio. Un aggiornamento cambia il nome della classe, la tua rimozione non corrisponde più, il pannello AI riappare e nessun errore te lo segnala. Se scegli questa strada, annota cosa hai rimosso e ricontrollalo dopo ogni aggiornamento di quel plugin.

La stessa cautela vale per la deregistrazione dei pannelli dell’editor via JavaScript. È una possibilità concreta, ma stai intervenendo sulla registrazione di un altro plugin tramite un identificatore testuale, e quell’identificatore non è un contratto pubblico.

Non provare a bloccare le funzioni AI modificando costanti di wp-config.php trovate in un post di un forum. Nessuna costante del core spegne l’AI di un plugin di terze parti. Se uno snippet sostiene il contrario e non riesci a ricondurre la costante alla documentazione di quel plugin, non fa assolutamente nulla.

L’altra domanda: impedire l’addestramento AI sui tuoi contenuti

È una questione a parte, ed è lì che si concentra l’ansia vera. Spegnere un pannello nell’editor non cambia nulla su chi passa a scansionare i tuoi articoli. Quel controllo si esercita nel robots.txt e, se lo vuoi imporre davvero, a livello di server.

WordPress serve un robots.txt virtuale finché non esiste un file reale nella root del sito. Se il file fisico c’è, WordPress si fa da parte del tutto e i crawler ricevono quel file. Per modificare la versione virtuale, usa il filtro:

add_filter( 'robots_txt', function ( $output ) {
    $output .= "\nUser-agent: GPTBot\nDisallow: /\n";
    return $output;
}, 10 );

Costruire le regole a mano è il punto in cui si sbaglia: un token scritto male non blocca nulla, e un Disallow: / finito sull’agente sbagliato può farti sparire dalla ricerca normale. Il generatore di robots.txt assembla i blocchi per i crawler AI insieme alle direttive per i motori di ricerca, così vedi il file completo prima di pubblicarlo.

I token che i principali operatori pubblicano e dichiarano di rispettare:

Token	Operatore	Cosa copre
GPTBot	OpenAI	Scansione per l’addestramento dei modelli
ChatGPT-User	OpenAI	Richieste avviate da un utente
ClaudeBot	Anthropic	Scansione
Google-Extended	Google	Uso dei contenuti per l’addestramento di Gemini, non la scansione in sé
Applebot-Extended	Apple	Uso per l’addestramento dei modelli generativi di Apple
PerplexityBot	Perplexity	Scansione
CCBot	Common Crawl	Archivio massivo su cui si addestrano molti modelli

Due avvertenze oneste. Primo, il robots.txt è volontario: gli operatori corretti lo seguono, chi vuole ignorarlo lo ignora. Secondo, bloccare non è gratis. Alcuni di questi token determinano se compari nelle risposte generate dall’AI che ti citano con un link. Bloccandoli tutti perdi quella fonte di traffico insieme all’esposizione all’addestramento. Decidi cosa ti interessa davvero.

Per imporre il blocco invece di limitarti a chiederlo, intervieni sul server. In .htaccess su Apache:

<IfModule mod_setenvif.c>
  SetEnvIfNoCase User-Agent "GPTBot|CCBot|ClaudeBot|PerplexityBot" ai_bot
  <RequireAll>
    Require all granted
    Require not env ai_bot
  </RequireAll>
</IfModule>

Le stringhe user-agent si falsificano con un nulla, quindi questo ferma il traffico onesto ma indesiderato, non uno scraper determinato. Bloccare per intervalli IP verificati sulla CDN o sul firewall è più solido, e ormai quasi tutte le CDN offrono una regola anti-bot AI attivabile con un clic, più semplice da mantenere di un elenco scritto a mano.

Cosa non funziona

llms.txt è una proposta, non uno standard. È un file markdown suggerito per descrivere il sito ai modelli linguistici. Nessun grande operatore si è impegnato a trattarlo come controllo degli accessi. Aggiungerlo non costa nulla e può aiutare il modo in cui i modelli ti leggono, ma non blocca niente.

I meta tag noai e noimageai non li rispetta quasi nessuno. Sono nati dalla policy di una singola piattaforma, non da un accordo di settore. Aggiungerli non fa danni; aspettarsi che funzionino sì.

Un plugin che promette di “bloccare l’AI” di solito scrive solo regole robots. Va benissimo, ed è esattamente quello che puoi fare da solo in dieci righe. Non è una barriera legale né tecnica, e nessun plugin può renderla tale.

Bloccare i crawler AI non rimuove i contenuti già finiti in un modello addestrato. Nulla di ciò che aggiungi oggi tira fuori retroattivamente i tuoi articoli da un modello rilasciato l’anno scorso. Le regole robots valgono solo da qui in avanti.

Se il pannello AI è ancora lì

Se hai disattivato tutti i plugin e il pannello resiste, ricontrolla wp-content/mu-plugins/, poi la bacheca del tuo hosting, poi verifica se stai usando WordPress.com invece di un’installazione self-hosted: lì gli interruttori stanno nelle impostazioni dell’account, non nell’amministrazione del sito. E se la funzione ricompare dopo l’aggiornamento di un plugin, è la firma di uno snippet di sgancio che ha smesso di corrispondere, non di un’impostazione predefinita del core che si riafferma.