TL;DR: bloccare tutti i crawler AI è semplice, ma mette nello stesso sacco addestramento, ricerca e agenti che visitano il sito per conto di una persona. Per una PMI sceglierei l’accesso selettivo: Search aperto, Training bloccato salvo accordi espliciti, Agent limitato alle pagine pubbliche e alle sole richieste di lettura. Il criterio non è “AI sì o no”. È il valore e il rischio di ogni richiesta.
Il criterio: valore per richiesta, non user agent
Il confronto parte da una domanda pratica: quella visita automatica può portare scoperta, eseguire un compito utile o estrarre contenuti senza un ritorno misurabile? Se le tre attività vengono trattate allo stesso modo, la policy è facile da configurare ma troppo grossolana per un sito professionale.
Il 1° luglio 2026 Cloudflare ha aggiornato la propria classificazione dei bot distinguendo almeno tre comportamenti pertinenti: Search, che costruisce indici o basi RAG; Agent, che visita una pagina su richiesta di una persona; Training, che raccoglie dati per addestrare o rifinire modelli. Un singolo bot può avere più comportamenti. È una distinzione utile anche per chi non usa Cloudflare, perché costringe a definire lo scopo dell’accesso invece di fidarsi del nome scritto nello user agent.
Approccio A: bloccare tutto il traffico AI
Il blocco totale ha un vantaggio chiaro: riduce l’area di decisione. Non serve mantenere un elenco di crawler, valutare scopi diversi o inseguire ogni nuovo operatore. Per un archivio a pagamento, un’area con documenti riservati o un sito sotto scraping aggressivo, partire chiusi può essere sensato.
Ci sono anche benefici operativi. Meno richieste automatiche significa meno carico su WordPress, meno hit su pagine dinamiche e meno rumore nei log. Se il sito espone ricerca interna, filtri WooCommerce o endpoint costosi, una regola edge può fermare il traffico prima che PHP, database e plugin debbano lavorare.
Il contro è altrettanto concreto: il blocco non distingue chi usa il contenuto per addestrare un modello da chi lo indicizza per rispondere a una ricerca. Cloudflare ha annunciato che dal 15 settembre 2026, per i nuovi domini, Search resterà consentito per impostazione predefinita, mentre Training e Agent verranno bloccati sulle pagine con pubblicità. La scelta riflette un punto economico: la ricerca può restituire scoperta e visite; l’addestramento non garantisce lo stesso scambio.
C’è poi il caso dei crawler multiuso. Se una regola applica il comportamento più restrittivo, bloccare Training può fermare anche un bot che svolge Search. Per una PMI che sta cercando visibilità, una configurazione troppo larga rischia di risolvere lo scraping cancellando anche una parte della distribuzione.
Approccio B: accesso selettivo per scopo
L’accesso selettivo assegna una policy diversa a Search, Agent e Training. È più coerente con il modo in cui il web viene usato nel 2026, ma richiede osservabilità. Devi sapere chi arriva, quali URL richiede, con quale frequenza e se rispetta le direttive pubblicate.
I pro sono misurabili. Puoi lasciare raggiungibili articoli, sitemap e pagine servizio per la ricerca AI; bloccare l’addestramento dove non esiste un accordo; consentire a un agente verificato di leggere una scheda pubblica senza aprirgli login, carrello o endpoint di scrittura. Cloudflare definisce “Verified” un servizio che si identifica in modo controllabile e non abusa dell’accesso. La verifica riduce l’impersonificazione, ma non sostituisce una policy sul comportamento.
Il costo è la manutenzione. Le classificazioni cambiano, alcuni operatori hanno più scopi e una allowlist può diventare vecchia. Serve quindi una regola di default, non una collezione infinita di eccezioni: accesso pubblico in lettura dove produce valore, blocco o challenge sul resto, log sufficienti per rivedere la decisione.
robots.txt dichiara la regola, l’edge la applica
robots.txt resta il posto corretto per dichiarare le preferenze di crawling. L’RFC 9309 standardizza formato, matching e recupero del file. Lo stesso standard precisa però che il Robots Exclusion Protocol non è una misura di sicurezza e che i crawler sono invitati a rispettarlo. La documentazione Cloudflare è ancora più esplicita: la conformità è volontaria.
Quindi Disallow non protegge un contenuto riservato. Se una URL non deve essere letta, servono autenticazione, autorizzazione e controllo a livello applicativo o edge. La configurazione robusta usa entrambi: robots.txt come policy leggibile e WAF o crawl control come enforcement. È lo stesso principio che applico alle automazioni AI: il prompt esprime l’intento, il codice impone il limite.
Cosa cambia su WordPress
Su WordPress separerei prima di tutto superfici pubbliche e operative. Articoli pubblicati, categorie utili e sitemap possono restare accessibili a Search. Preview, wp-admin, login e dati cliente non devono dipendere da robots.txt: sono protetti da autenticazione e regole di rete. Gli endpoint REST di scrittura richiedono credenziali e permessi minimi; nessun crawler deve raggiungerli solo perché dichiara di essere un agente.
Il secondo passaggio è misurare. Per due settimane registrerei richieste per categoria, URL, status code e consumo origin. Se Search legge articoli canonici e la presenza nelle risposte AI conta per il business, lo lascerei aperto. Se Training scarica tutto l’archivio senza un beneficio definito, lo bloccherei. Se Agent visita pagine pubbliche su richiesta dell’utente, applicherei rate limit e accesso in sola lettura.
Questa policy completa il lavoro di ottimizzazione descritto nella checklist WordPress per AI Search: rendere una pagina leggibile serve solo se i crawler utili possono raggiungerla. E va misurata con metriche diverse dal solo click, come spiegato nell’analisi su AI Search e visibilità senza referral.
La mia take: selettivo per default
Per un sito PMI non sceglierei il blocco totale. Userei una policy selettiva e conservativa: Search consentito sulle pagine pubbliche; Training bloccato finché non esiste un motivo contrattuale o commerciale per aprirlo; Agent consentito solo in lettura, su URL pubbliche, con identità verificabile e limiti di frequenza. Tutto ciò che autentica, modifica o acquista resta fuori da questa policy e passa da permessi applicativi.
Il blocco totale resta il piano di emergenza quando non hai log, classificazione o tempo per governare il traffico. Ma non è una strategia di distribuzione. La scelta matura è concedere accesso dove puoi spiegare il ritorno e negarlo dove il sito paga il costo senza ricevere valore.