Cloudflare serve oggi una riga come Content-Signal: search=yes, ai-train=no nel robots.txt di oltre 3,8 milioni di domini. Il tuo sito WordPress, quasi certamente, non dice niente: ne’ si’ ne’ no. Nel vocabolario della Content Signals Policy il silenzio non e’ una difesa, e’ assenza di preferenza: chi raccoglie i tuoi articoli per addestrare un modello non trova niente da rispettare, e tu non hai niente da mostrare se un giorno vuoi contestarlo. Sistemarlo su un sito WordPress sono cinque minuti e uno snippet.

Cosa dichiara davvero un content signal

La policy definisce tre segnali, ognuno legato a un uso del contenuto dopo che il crawler lo ha letto. search copre la costruzione di un indice e i risultati di ricerca classici, link e snippet brevi, e non include i riassunti generati dall’AI. ai-input copre l’uso del testo come input di un modello in tempo reale: RAG, grounding, risposte generative. ai-train copre l’addestramento e il fine-tuning. La sintassi e’ una riga sola, dentro un gruppo User-agent: come Allow e Disallow, con valori yes o no separati da virgola. Un segnale che non scrivi non vale come no: vale come nessuna dichiarazione. Il testo della policy qualifica le restrizioni come riserva espressa di diritti ai sensi dell’articolo 4 della direttiva UE 2019/790, quella che regola il text and data mining. L’efficacia cambia da giurisdizione a giurisdizione e non e’ un parere legale, ma la forma leggibile a macchina e’ esattamente quella che la norma si aspetta. La policy e’ rilasciata con licenza CC0: non serve essere clienti Cloudflare per usarla.

Aggiungerlo a WordPress in cinque minuti

WordPress genera un robots.txt virtuale con do_robots() e lo espone al filtro robots_txt. Il posto giusto e’ un plugin mu o uno snippet, mai functions.php del tema figlio se il tema puo’ cambiare.

add_filter( 'robots_txt', function ( $output, $public ) {
    // Sito non indicizzabile dalle impostazioni: non dichiarare nulla.
    if ( ! $public ) {
        return $output;
    }
    $riga  = "Content-Signal: search=yes, ai-input=yes, ai-train=no\n";
    return $output . $riga;
}, -1, 2 );

La priorita’ -1 non e’ un vezzo ed e’ il punto in cui quasi tutti gli snippet che girano online sbagliano. Dal 5.5 il core registra WP_Sitemaps::add_robots() sullo stesso filtro con priorita’ 0 e appende \nSitemap: ...\n: se scrivi a priorita’ 10 la tua riga finisce dopo una riga vuota, quindi fuori dal gruppo User-agent: * e senza destinatario. Girando prima del core la dichiarazione resta attaccata alle regole di wp-admin, cioe’ dentro il gruppo che vale per tutti i crawler. Se hai altri gruppi User-agent:, ripeti la riga in ciascuno: le direttive non si ereditano tra gruppi. Poi verifica dall’esterno, non dall’editor: curl -s https://tuosito.it/robots.txt | grep -i content-signal. Se non esce niente, il file che il mondo vede non e’ quello che credi. Molti hosting servono il robots.txt da un layer statico: purga cache sito e CDN prima di dire che lo snippet non funziona.

L’errore che rende il file muto

Il filtro non viene eseguito se nella root del sito esiste un robots.txt fisico: in quel caso il server lo serve direttamente e WordPress non entra mai in gioco, snippet compreso. E’ la causa numero uno di modifiche che “non si vedono”, e capita spesso sui siti migrati, dove il file e’ rimasto dentro un backup ripristinato a mano. Prima di scrivere codice, controlla via FTP o file manager se il file esiste: se c’e’, la riga va aggiunta li’ dentro e lo snippet non serve. Il secondo caso e’ un plugin SEO con editor del robots.txt integrato, come Rank Math o Yoast: prende in mano l’output, e la riga va messa nel suo campo, non nel filtro. Il terzo errore non e’ tecnico ma di aspettativa: i content signal esprimono preferenze, non sono contromisure. Chi ignora il robots.txt continuera’ a ignorarlo. Per fermare davvero un crawler servono Disallow per user-agent specifici e, sopra, una regola al CDN o al WAF. Lo stesso principio dei caratteri invisibili nei contenuti WordPress: una dichiarazione non sostituisce un controllo. Dove tracciare la linea tra dichiarare e bloccare l’ho analizzato in crawler AI, blocco totale o accesso selettivo.

Quali valori scegliere, e cosa controllare dopo

La scelta interessante non e’ ai-train, dove quasi tutti mettono no senza pensarci troppo, ma ai-input. Se metti no stai chiedendo di non essere usato nelle risposte generative, e quindi stai chiedendo di non essere citato da ChatGPT, Perplexity o dalle AI Overviews. Per un editore che vende pubblicita’ sulle pagine ha senso. Per uno studio professionale o una PMI che dal blog raccoglie richieste di preventivo e’ un autogol: quelle citazioni sono esattamente il canale nuovo che stai provando ad aprire. La combinazione ragionevole per chi fa consulenza e’ search=yes, ai-input=yes, ai-train=no: ti fai trovare e citare, non regali il corpus per il prossimo modello. Dopo la pubblicazione controlla due cose. Una volta: che curl restituisca la riga sul dominio vero, con e senza www, perche’ sono due file diversi se l’hosting li serve separatamente. Ogni mese: i log del server filtrati sui bot AI, per vedere chi passa comunque, che e’ l’unico dato che ti dice se il segnale sta funzionando o se serve un blocco vero. Cinque minuti di lavoro, zero effetti sul posizionamento, una posizione dichiarata invece di un silenzio interpretabile.

Fonti: Cloudflare, Giving users choice with Cloudflare’s new Content Signals Policy; WordPress Developer Resources, filtro robots_txt; WordPress Developer Resources, funzione do_robots().