Se tratti tutti i bot AI allo stesso modo, hai due risultati possibili: consumi risorse per crawler che non ti portano valore oppure blocchi anche quelli che potrebbero citare il sito. Su WordPress la scelta giusta non è un interruttore unico. È una policy diversa per ogni comportamento.
Il problema: un bot AI non vale l’altro
La distinzione utile non parte dal nome del crawler, ma da ciò che fa. Cloudflare classifica il traffico AI in tre comportamenti: Search, che raccoglie contenuti per rispondere alle ricerche; Agent, che agisce in tempo reale per conto di una persona; Training, che acquisisce contenuti per addestrare o perfezionare un modello. Per una PMI sono tre scambi diversi. Il primo può generare citazioni e visite, il secondo può servire un cliente mentre confronta prodotti o servizi, il terzo usa banda senza promettere un ritorno diretto. Se li metti nella stessa regola, rinunci a decidere. Inoltre un crawler può visitare archivi, feed, pagine con parametri e risorse che WordPress genera dinamicamente: richieste poco costose prese singolarmente, ma capaci di moltiplicare PHP, query e cache miss quando arrivano in sequenza. Prima di bloccare, guarda quindi richieste, percorsi e frequenza nel pannello CDN o nei log del server.
La soluzione: una policy per comportamento
Parti da una matrice semplice. Consenti i bot di ricerca AI se vuoi essere trovato nelle risposte sintetiche e se le loro richieste restano sostenibili. Per gli agenti in tempo reale, limita l’accesso alle pagine pubbliche e nega aree amministrative, endpoint sensibili, URL di anteprima e percorsi che generano azioni. Per i crawler di training, scegli in modo esplicito se consentire, disabilitare tramite robots.txt o bloccare al firewall. È importante separare intenzione ed enforcement: la documentazione Cloudflare chiarisce che robots.txt comunica una preferenza, ma il rispetto è volontario. Se vuoi impedire davvero l’accesso serve una regola applicata dal CDN o dal WAF. La mia scelta predefinita per un sito aziendale è questa: Search consentito e monitorato, Agent consentito solo sulle superfici pubbliche, Training disabilitato salvo un accordo o un beneficio misurabile.
I passaggi essenziali su WordPress
Prima misura per almeno una giornata il traffico automatizzato: user agent, URL richieste, risposta HTTP, cache hit e picchi di frequenza. Poi escludi dal traffico consentito /wp-admin/, /wp-login.php, le preview, gli endpoint di staging e qualsiasi URL che avvii un processo. Mantieni invece raggiungibili articoli, pagine, robots.txt e sitemap per i crawler Search che hai deciso di accettare. Applica la regola a monte di WordPress, sul CDN o sul WAF, così le richieste respinte non avviano PHP né interrogano il database. Parti con un’azione osservabile o un rate limit, controlla i falsi positivi e passa al blocco soltanto quando hai identificato il comportamento. Infine annota la decisione: bot, categoria, azione, eccezioni e data di revisione. È lo stesso principio dei guardrail prima del go-live per gli agenti AI: una regola senza log e senza criterio di ritorno diventa presto invisibile.
L’errore da evitare e la take finale
L’errore più comune è copiare una lista di user agent dentro robots.txt e considerare il problema risolto. Quel file non è un firewall, le stringhe possono cambiare e un client ostile può dichiararsi con un nome diverso. Il secondo errore è opposto: bloccare ogni bot AI per alleggerire il server, senza distinguere l’indicizzazione dalla raccolta per training. Così una misura di performance diventa una scelta editoriale fatta per sbaglio. La take operativa è netta: non gestire i bot per marca, gestiscili per comportamento e costo. Mantieni una policy corta, verificabile e applicata prima dell’origine; rivedila quando cambiano traffico o obiettivi. Le fonti tecniche usate per questa procedura sono la classificazione dei bot AI di Cloudflare, la guida sul limite operativo di robots.txt e il riferimento ai crawler riconosciuti.