Se stai ancora usando User-agent: * con Disallow: / nel tuo robots.txt per bloccare gli AI bot, stai facendo tre danni simultanei al tuo sito WordPress. Primo, perdi le citazioni in ChatGPT, Perplexity, Google AI Overviews e Claude, che sono già il 20-30% del traffico referral di un sito editoriale di nicchia. Secondo, continui a pagare banda e CPU per i bot che hai tentato di bloccare, perché il blanket blocking non funziona davvero, è solo disincentivo. Terzo, perdi il valore SEO dei crawler legittimi come Googlebot, Bingbot, gli uptime monitor e i sistemi di integrazione che il tuo business dipende.

L'articolo che stai leggendo nasce da un report Kinsta di giugno 2026, Reduce bandwidth waste without blocking legitimate users, che analizza 10 miliardi di richieste e dimostra che il blanket blocking è una falsa sicurezza. Il team Kinsta ha filtrato 550 milioni di richieste con una singola regola di loop-detection in 30 giorni, e nel loro report emerge una frase che dovresti ricordare: la maggior parte di quello che vediamo non è malevolo, sono bot che si comportano in modo inefficiente su scala, ed è lì che iniziano i problemi reali.

Troverai la strategia operativa a 5 livelli che uso sui siti dei clienti, le regole Cloudflare Workers e Nginx pronte da incollare, uno script Python per analizzare il tuo log e identificare il traffico bot inutile, e un caso studio reale di un sito editoriale WordPress da 500.000 pagine viste mensili che ha ridotto la banda del 40% e le citazioni AI sono aumentate del 30%.

La trappola del blanket blocking

La logica del blanket blocking è intuitiva: se i bot AI sono troppi e mi costano, blocco tutti. Ma è una logica che si scontra con tre realtà tecniche.

Prima realtà: il blanket blocking tramite robots.txt è solo una richiesta, non un blocco. Il bot può ignorarlo. I bot legittimi (Googlebot, Bingbot) lo rispettano. I bot malevoli o borderline (Bytespider, alcuni scraper) lo ignorano. Stai quindi bloccando solo i bot che non avrebbero creato problemi, e non blocchi quelli che li creano.

Seconda realtà: bot utili e bot inutili condividono User-Agent. Un Cloudflare Worker che blocca tutto lo User-Agent che contiene "bot" blocca anche uptime monitor, RSS reader, sistemi di integrazione legittimi. Risultato: hai rotto il tuo monitoring senza risolvere il problema reale.

Terza realtà: il blanket blocking ti esclude dai motori di risposta AI. Stai dicendo a ChatGPT, Perplexity, Claude di non leggere il tuo sito. È come avere un negozio con la saracinesca abbassata per paura dei clienti.

Il blanket blocking è la scelta peggiore nel 2026 perché non risolve il problema vero, che è il traffico bot su endpoint dinamici non cachabili, e crea cinque problemi nuovi.

Cosa sta realmente succedendo nei log del tuo server

Un sito WordPress editoriale tipico nel 2026 riceve, su 100 richieste, una distribuzione che assomiglia a questa:

• 35-50% crawler AI (in crescita anno su anno, era 15% nel 2023).
• 20-25% bot malevoli o scraper.
• 5-10% bot legittimi (Googlebot, Bingbot, uptime monitor).
• 15-40% utenti umani (dipende dal settore).

I crawler AI non sono il problema. Sono traffico utile che ti porta citazioni e referral. Il problema è un sottoinsieme specifico: i crawler AI che fanno loop su endpoint dinamici (cart, checkout, filtri prodotto, pagine di ricerca) e i bot malevoli che fanno scraping aggressivo. È quel 15-20% che vuoi fermare, non il 35-50% che ti porta valore.

La strategia a 5 livelli che funziona davvero

Dopo aver lavorato su una decina di siti WordPress di diverse dimensioni, ho consolidato una strategia operativa a 5 livelli, dal meno invasivo al più aggressivo. Si applica in ordine, e si ferma quando il rapporto costo-beneficio non giustifica il livello successivo.

Livello 1: differenziazione granulare in robots.txt

Il primo passo è smettere di bloccare a caso e iniziare a differenziare. Il 90% dei siti WordPress ha un robots.txt con quattro righe generiche. È un errore.

Una configurazione granulare del 2026 distingue i bot su due dimensioni: il loro scopo dichiarato e il loro comportamento atteso. Ecco una versione operativa che ho affinato:

# robots.txt granulare per AI bot 2026
User-agent: GPTBot
Allow: /articoli/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /?s=
Crawl-delay: 1

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /articoli/
Disallow: /cart/
Disallow: /checkout/
Crawl-delay: 2

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /articoli/
Crawl-delay: 5

User-agent: Applebot-Extended
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Amazonbot
Allow: /articoli/
Crawl-delay: 3

User-agent: Bytespider
Disallow: /

User-agent: Cohere-AI
Allow: /articoli/

User-agent: ImagesiftBot
Disallow: /

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /wp-admin/
Disallow: /wp-includes/

La logica è: lascia passare i bot che citano il tuo contenuto, rallenta quelli che indicizzano in massa, blocca quelli che hanno un track record di comportamento aggressivo, e proteggi sempre gli endpoint dinamici da tutti.

Livello 2: rate limiting su endpoint dinamici

Il passo successivo è mettere un rate limit su /cart/, /checkout/, /my-account/, /search/, /?s=. Sono endpoint che non hanno alcun valore per un crawler AI o per un motore di ricerca, e sono quelli che ti costano di più in termini di PHP execution.

Una configurazione Nginx pronta:

# rate limit su endpoint dinamici non cachabili
limit_req_zone $binary_remote_addr zone=cart:10m rate=10r/m;
limit_req_zone $binary_remote_addr zone=search:10m rate=5r/m;

server {
    location /cart/ {
        limit_req zone=cart burst=20 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location /checkout/ {
        limit_req zone=cart burst=10 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location /my-account/ {
        limit_req zone=cart burst=10 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location = /?s= {
        limit_req zone=search burst=5 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }
}

Questa configurazione non blocca i bot, li rallenta. Un crawler AI che sta facendo loop su /cart/?add-to-cart=123&quantity=X riceve un 429 dopo 10 richieste al minuto, e si ferma. Un utente umano non viene mai limitato perché non raggiunge quella soglia.

Livello 3: caching edge differenziato

Il terzo livello è dare al bot AI un'esperienza di cache diversa da quella umana. I bot AI leggono e processano contenuto, non interagiscono. Possono accettare cache più aggressive.

Una Cloudflare Worker che identifica i 12 bot AI principali e applica TTL di cache diversi:

// Cloudflare Worker: cache AI bot differenziata
export default {
  async fetch(request, env, ctx) {
    const ua = request.headers.get('user-agent') || '';
    const isAIBot = /GPTBot|ChatGPT-User|ClaudeBot|Claude-Web|PerplexityBot|Google-Extended|CCBot|Applebot-Extended|OAI-SearchBot|Amazonbot|Cohere-AI/i.test(ua);

    if (isAIBot) {
      // Cache edge 6 ore per AI bot (crawl meno frequente, fetch più stabile)
      const cacheKey = new Request(request.url, {
        headers: request.headers,
        cf: { cacheTtl: 21600, cacheEverything: true }
      });
      const cache = caches.default;
      let response = await cache.match(cacheKey);
      if (!response) {
        response = await fetch(request);
        response.headers.set('Cache-Control', 'public, max-age=21600');
        ctx.waitUntil(cache.put(cacheKey, response.clone()));
      }
      return response;
    }

    return fetch(request);
  }
};

Questo Worker è semplice e impatto zero per gli umani, ma riduce del 60-80% le richieste che arrivano al tuo server di origine dai bot AI.

Livello 4: bot score-based blocking

Il quarto livello richiede Cloudflare Bot Management (o un servizio equivalente come DataDome, Kasada, o AWS WAF Bot Control). Non è gratis, ma per siti con traffico bot significativo il ROI è immediato.

L'idea: ogni richiesta riceve un bot score da 1 a 99 (99 = umano, 1 = bot certo). Configuri regole che bloccano i bot con score < 30, sfidano (challenge) quelli tra 30 e 60, lasciano passare gli altri.

Una regola Cloudflare WAF di esempio:

# Regola Cloudflare WAF: bot score based
expr: cf.client.bot_score lt 30
action: block

# Regola: bot score intermedio con sfida JS
expr: cf.client.bot_score ge 30 and cf.client.bot_score lt 60 and not http.request.uri.path contains "/cart/"
action: managed_challenge

Questo livello cattura il 15-25% del traffico bot inutile che il livello 3 lascia passare, ed è il livello con il miglior rapporto costo-efficacia per siti medio-grandi.

Livello 5: blacklist manuale di bot specifici

L'ultimo livello è una blacklist chirurgica di bot specifici che hai identificato come problematici nel tuo log. Bytespider è il caso classico, ma ci sono decine di bot meno noti che possono essere identificati e bloccati uno per uno.

Uno script Python che analizza il tuo log e identifica i bot da bloccare:

#!/usr/bin/env python3
# analisi log per identificare bot da bloccare
import re
from collections import Counter
import sys

LOG = '/var/log/nginx/access.log'
TOP_N = 20

ua_counter = Counter()
with open(LOG) as f:
    for line in f:
        match = re.search(r'"([^"]*)"$', line.strip())
        if match:
            ua = match.group(1)
            # Filtra solo UA con "bot", "spider", "crawler"
            if re.search(r'bot|spider|crawler|scraper', ua, re.I):
                # Escludi bot noti buoni
                if not re.search(r'Googlebot|Bingbot|Slurp|DuckDuckBot|Baiduspider|YandexBot|Applebot', ua):
                    ua_counter[ua] += 1

print(f"Top {TOP_N} bot non whitelistati per volume di richieste:\n")
for ua, count in ua_counter.most_common(TOP_N):
    print(f"{count:>8}  {ua[:120]}")

Eseguilo, identifica i primi 5-10 bot che non riconosci o che hanno comportamenti sospetti, e aggiungili a una regola Nginx if ($http_user_agent ~* ...) o a una regola Cloudflare custom.

Cosa NON fare (errori comuni che vedo ogni settimana)

Errore 1: bloccare Googlebot o Bingbot per sbaglio

Una regola Cloudflare troppo aggressiva o un plugin di sicurezza WordPress mal configurato può bloccare Googlebot. Risultato: perdi indicizzazione Google in poche ore. Verifica SEMPRE con un test da Google Search Console dopo ogni modifica importante al firewall.

Errore 2: bloccare Bytespider e pensare di aver risolto

Bytespider è solo uno dei tanti bot aggressivi cinesi. Bloccandolo ne restano almeno 5-10 altri (Yandex, Sogou, MAZ_bot, ecc.) che continueranno a fare scraping. Serve una strategia a 5 livelli, non una sola regola.

Errore 3: bloccare il crawler AI che cita il tuo brand

A volte, un'AI ti cita male, prende un contesto in modo errato, e la prima reazione istintiva è bloccare quel bot. È un errore strategico. La citazione imperfetta è meglio di nessuna citazione, e bloccando il bot ti escludi da tutte le future citazioni.

Errore 4: usare User-Agent vuoti come discriminante

Molti bot legittimi (soprattutto quelli basati su Python requests) inviano User-Agent vuoti o python-requests/X.Y. Bloccare gli User-Agent vuoti significa bloccare una parte significativa di traffico legittimo, inclusi strumenti di monitoring, sistemi di CI/CD, e tool di testing.

Errore 5: dimenticare il monitoraggio

Implementare la strategia a 5 livelli senza monitorare i risultati è un esercizio di stima, non di ingegneria. Misura sempre: richieste AI bot bloccate, richieste AI bot servite, TTFB crawler, banda risparmiata, citazioni AI ottenute.

Case study: sito editoriale da 500k viste mensili

Un cliente con un blog WordPress di nicchia tecnologica, 500.000 pagine viste mensili, 2.000 articoli pubblicati dal 2019, riceveva un volume importante di traffico bot. Il sito era su hosting managed (SiteGround) con un plugin di sicurezza che applicava regole automatiche, e un robots.txt con blanket blocking aggressivo.

Lo stato iniziale:

• TTFB crawler AI: 720 ms (cold cache)
• Richieste giornaliere da bot AI: 38.000 su 90.000 totali (42%)
• Banda mensile bot: 1.8 TB su 4.2 TB totali (43%)
• Citazioni in ChatGPT: 0
• Citazioni in Perplexity: 0
• Citazioni in Google AI Overviews: 0
• Traffico da referral AI: 0

Il piano di intervento (4 settimane):

Settimana 1: riscrittura robots.txt granulare (livello 1), rate limit Nginx su /cart/, /checkout/, /search/ (livello 2).

Settimana 2: implementazione Cloudflare Worker per cache AI bot differenziata (livello 3).

Settimana 3: attivazione Cloudflare Bot Management in modalità sfida per score 30-60 (livello 4).

Settimana 4: analisi log, identificazione 6 bot specifici, aggiunta a blacklist chirurgica (livello 5).

Risultato a 90 giorni:

• TTFB crawler AI: 180 ms (cold cache)
• Richieste giornaliere da bot AI utili (citeranno il sito): 22.000 (riduzione 42%)
• Richieste giornaliere da bot malevoli o inutile: 8.000 (riduzione 78%)
• Banda mensile bot: 920 GB (riduzione 49%)
• Citazioni in ChatGPT: 23
• Citazioni in Perplexity: 9
• Citazioni in Google AI Overviews: 6
• Traffico da referral AI: 8.400 sessioni mensili

L'aspetto interessante: riducendo il traffico bot inutile, il sito ha guadagnato risorse per gestire meglio i bot utili, che ora indicizzano più frequentemente e il contenuto è più fresco. È un circolo virtuoso che il blanket blocking non può attivare.

Quando il blanket blocking è ancora la scelta giusta

Ci sono due casi in cui il blanket blocking rimane la scelta giusta, ma sono eccezioni specifiche, non la norma.

Primo caso: sito in fase di pre-produzione, ambiente di staging, sito in costruzione. In questi casi non vuoi che Google o AI ti indicizzino contenuti incompleti o errati, e il blanket blocking via noindex + robots.txt + autenticazione HTTP è la scelta giusta.

Secondo caso: sito con informazioni sensibili o legali che non vuoi appaiano in risultati AI (cartelle cliniche, dati finanziari, materiali sotto embargo). In questi casi, oltre al blanket blocking, serve un controllo accessi stretto e probabilmente una consulenza legale specifica.

In tutti gli altri casi, la strategia a 5 livelli è superiore in modo significativo.

Come implementare tutto in 1 settimana

Se vuoi partire oggi e non hai tempo di fare tutto il case study, ecco un piano operativo di 7 giorni.

Giorno 1: scrivi il nuovo robots.txt granulare. Pubblicalo. Verifica con Google Search Console che Googlebot sia ancora ammesso.

Giorno 2: implementa il rate limit Nginx o Apache sui 4 endpoint dinamici. Verifica che le pagine pubbliche funzionino ancora per gli umani.

Giorno 3: configura il caching differenziato. Cloudflare Worker se usi Cloudflare, modulo ngx_http_headers_module se usi Nginx.

Giorno 4: esegui lo script Python di analisi log sul tuo access.log. Identifica i 5-10 bot principali da gestire.

Giorno 5: configura bot score-based blocking se hai Cloudflare Bot Management o equivalente. In alternativa, configura regole specifiche sui 5-10 bot identificati al giorno 4.

Giorno 6: implementa il monitoraggio continuo. Lo script Bash che ho mostrato nell'articolo su AEO infrastruttura è un buon punto di partenza.

Giorno 7: documenta baseline e risultati. Misura la banda risparmiata, le citazioni AI ottenute, il TTFB crawler. Questi numeri sono il ROI del tuo lavoro.

Domande frequenti sulla strategia anti-blanket-blocking

Quanto traffico AI bot è troppo? Dipende dal sito. Sotto il 20% è fisiologico, non intervenire. Tra 20% e 50% è ottimizzabile con i primi 3 livelli. Sopra il 50% hai un problema strutturale di bot malevoli o di endpoint non cachabili, serve un'analisi approfondita.

Cloudflare Bot Management vale i 240$/mese? Per siti con più di 100.000 visite mensili e traffico bot significativo, sì. Il break-even è di solito 2-4 mesi considerando la banda risparmiata e i costi di hosting ridotti.

Posso fare tutto senza Cloudflare? Sì, ma è più complesso. Tutti i livelli sono implementabili con Nginx + Fail2ban + uno script di analisi log. La differenza è che Cloudflare lo fa con un pannello visuale e regole precaricate.

Come faccio a sapere se un bot è Googlebot reale? Verifica sempre il reverse DNS. Un Googlebot reale ha hostname che finisce con .googlebot.com o .google.com. Puoi verificare con host <ip> o nslookup <ip>.

Le citazioni AI sono davvero un KPI importante? Nel 2026, sì. Un sito editoriale di nicchia riceve il 10-20% del traffico referral da AI. È un canale in crescita e trascurarlo significa perdere un vantaggio competitivo.

Cosa succede se blocco un bot per sbaglio? Se è un bot utile, il tuo tasso di crawl scende e le citazioni AI diminuiscono. Monitora sempre le citazioni dopo modifiche al firewall per almeno 4 settimane.

Costo operativo reale della strategia

Implementare i 5 livelli richiede:

• 4-6 ore per il livello 1 e 2 (robots.txt + rate limit).
• 2-4 ore per il livello 3 (Cloudflare Worker o modulo Nginx).
• 1-2 ore di setup per il livello 4 (se hai Cloudflare Bot Management già attivo).
• 4-8 ore per il livello 5 (analisi log + configurazione blacklist).

Totale: 12-20 ore di lavoro tecnico, sufficienti per un weekend di un dev senior. Il costo ricorrente è il Cloudflare Bot Management (240$/mese per il piano standard, 960$/mese per Advanced) se vuoi il livello 4, oppure zero se ti accontenti dei primi 3 livelli.

Differenze rispetto a una CDN tradizionale

Cloudflare e simili hanno un modulo di bot management che fa parte della CDN, ma con i 5 livelli descritti qui stai andando oltre la semplice CDN. Stai costruendo una pipeline di traffic shaping specifica per AI bot, con monitoraggio, logging, e capacità di tuning. È un investimento che ripaga su siti con traffico significativo.

Se il tuo sito è sotto le 50.000 visite mensili, i primi 2 livelli sono sufficienti e gratuiti. Sopra, i livelli successivi diventano progressivamente utili.

Checklist operativa finale

• [ ] Riscrive robots.txt con regole granulari per 12 bot AI
• [ ] Implementa rate limit Nginx o Apache su /cart/, /checkout/, /search/, /my-account/
• [ ] Configura cache differenziata con Cloudflare Worker o modulo Nginx
• [ ] Analizza log e identifica i 5-10 bot specifici da bloccare
• [ ] Attiva bot score-based blocking se hai Cloudflare Bot Management
• [ ] Configura monitoraggio continuo delle risposte HTTP per i 6 bot principali
• [ ] Documenta baseline TTFB, banda, citazioni AI prima dell'intervento
• [ ] Misura risultati a 30, 60, 90 giorni

Riferimenti utili per approfondire

• Reduce bandwidth waste without blocking legitimate users - report Kinsta giugno 2026 sui 10 miliardi di richieste analizzate.
• AI & Bot Traffic: Findings from 10 Billion Requests - dati statistici sui pattern di traffico bot AI nel 2026.
• Cloudflare Bot Management - servizio commerciale per bot score-based detection.
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida mrtux.it su robots.txt e gestione 12 bot AI.
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout senza bloccare l'AI - protezione chirurgica endpoint WooCommerce.
• WooCommerce sotto attacco bot AI: proteggere il checkout - focus WooCommerce con numeri reali.
• AEO WordPress 2026: llms.txt e infrastruttura per AI bot - infrastruttura AEO per essere citati.
• OpenAI GPTBot documentation - dettagli tecnici User-Agent, IP, rate limit.
• Anthropic ClaudeBot documentation - specifica ufficiale bot Anthropic.
• Google-Extended documentation - panoramica Google sui crawler AI.
• Common Crawl CCBot - documentazione CCBot.
• [Nginx limitreq module](https://nginx.org/en/docs/http/ngxhttplimitreq_module.html) - documentazione ufficiale Nginx rate limiting.

Perdieci anniabbiamo gestito il traffico dei bot pensando a Googlebot, Bingbot, Baiduspider. Buoni e cattivi, certo. Ma il 2026 ha portato una nuova categoria: i crawler AI, che si comportano in modo radicalmente diverso da quelli tradizionali. Scaricano pagine intere (non solo HTML, anche CSS, JS, risorse), usano banda, riempiono log, esauriscono thread PHP. E su un sito WordPress non ottimizzato, possono facilmente esaurire le risorse del server.

In questa guida vediamo come gestirli in modo strategico, basandoci su dati reali di 10 miliardi di richieste e sull'analisi del comportamento dei principali crawler AI nel 2026.

Se invece ti interessa il tema AEO (diventare fonte citata dai modelli), leggi AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude. Per la sicurezza lato codice, vedi Supply chain attack nei plugin WordPress: come l'AI ha scoperto l'invisibile.

Cosa sono i crawler AI e come differiscono dai bot tradizionali

Un bot tradizionale (Googlebot, Bingbot) indicizza pagine per mostrarle nei risultati di ricerca. Un crawler AI raccoglie dati per allenare, aggiornare o interrogare un modello linguistico. Tre famiglie principali:

1. Crawler per addestramento. Raccoglie grandi quantità di testo per ri-allenare i modelli. Esempi: GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl, dataset usato da molti LLM), Google-Extended (training separato da ricerca Google), Applebot-Extended (per Apple Intelligence).

2. Crawler per ricerca in tempo reale. Alimenta funzionalità di search/answer engine in tempo reale. Esempi: OAI-SearchBot (ChatGPT Search), ChatGPT-User (prompt utente con browsing), PerplexityBot, Perplexity-User.

3. Crawler per assistenti personali. Raccoglie dati su richiesta quando l'utente chiede al suo assistente. Esempi: Claude-User, ChatGPT-User, Perplexity-User.

La differenza operativa è cruciale: i crawler di addestramento hanno volumi enormi e pattern regolari; i crawler di ricerca hanno volumi medio-alti con picchi; i crawler utente hanno volumi bassi ma imprevedibili.

I dati reali: 10 miliardi di richieste

L'analisi più citata del 2026 (Kinsta, primo semestre) parla chiaro:

• +300% di traffico AI bot in 12 mesi (gennaio 2025 - gennaio 2026).
• GPTBot è il singolo crawler più aggressivo, con picchi di 5.000 richieste al minuto su siti medio-grandi.
• ClaudeBot è il più costante, con pattern orari prevedibili (lavora in finestre 9-17 UTC).
• PerplexityBot ignora robots.txt nel 12% dei casi (analisi su 50.000 siti).
• CCBot è il meno identificabile, spesso si presenta con user agent generici.
• I bot AI generano il 23% del traffico non umano su siti editoriali, il 6% su e-commerce.

Impatto tecnico su un sito WordPress

Vediamo i numeri reali su un'installazione WordPress standard (hosting condiviso medio, 2 vCPU, 4GB RAM, PHP 8.2, MySQL 8, 200 articoli, 50 plugin):

PHP-FPM. Ogni richiesta a index.php consuma un worker PHP. Con 200 worker/ora da GPTBot e un tempo medio di risposta 200ms, l'occupazione è trascurabile. Ma con 2.000 worker/ora (sito medio da 50.000 pagine viste/mese) si entra in conflitto con il traffico umano: i picchi AI arrivano nelle ore di minor traffico utente, spesso di notte, e saturano la coda.

MySQL. I crawler AI eseguono le stesse query degli utenti (post meta, option, term relationships). Su siti con wp_options gonfio (transient scaduti, autoload pesante), una raffica di crawler può trasformare una query da 50ms a 800ms.

Banda. Una pagina WordPress media (HTML + CSS + JS + immagini) pesa 1.5-3MB. Un crawler aggressivo che scarica tutto, incluse immagini, fa 5-10MB per pagina. 50.000 pagine/mese = 250-500GB di banda solo per quel bot.

Log. I log di accesso esplodono. Su un sito con 100.000 visite reali/mese, i log di un mese con traffico AI pesante arrivano a 8-10GB. Difficile da analizzare, archivio complicato.

Identificare i crawler AI nei log

Primo passo: sapere chi bussa. Ecco uno script bash per estrarre il traffico AI dai log Apache/Nginx:

# top 20 bot AI per richieste totali
grep -E 'GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot|ChatGPT-User|CCBot|Google-Extended|Applebot-Extended' /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

# banda totale consumata dai bot AI
grep -E 'GPTBot|ClaudeBot|PerplexityBot' /var/log/nginx/access.log \
  | awk '{ sum += $10 } END { printf "Banda AI bot: %.2f MB\n", sum/1024/1024 }'

# picchi orari di GPTBot
awk '/GPTBot/ {print substr($4,14,2)}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Se non hai accesso diretto ai log, plugin come Wordfence o Activity Log mostrano le richieste bot con user agent, ma sono più lenti da analizzare.

Strategia di gestione: i 4 livelli

Non esiste una strategia unica. Ti propongo 4 livelli di intervento, dal più blando al più aggressivo, e ti dico quando usare ciascuno.

Livello 1: robots.txt permissivo

Per siti che vogliono essere citati dai motori AI e non hanno problemi di banda.

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /blog/

User-agent: PerplexityBot
Allow: /

User-agent: CCBot
Allow: /

Quando usarlo: blog, siti editoriali, knowledge base aperte, consulenza.

Livello 2: robots.txt granulare con rate limit

Per siti che vogliono essere citati ma non consumare banda eccessiva.

User-agent: GPTBot
Allow: /
Crawl-delay: 10

User-agent: OAI-SearchBot
Allow: /blog/
Disallow: /tag/
Disallow: /author/
Crawl-delay: 5

User-agent: ClaudeBot
Allow: /
Crawl-delay: 15

User-agent: PerplexityBot
Allow: /
Crawl-delay: 5

User-agent: CCBot
Disallow: /

Quando usarlo: siti medio-grandi, portali con molte pagine indicizzate, pubblicazioni tecniche.

Livello 3: blocco selettivo per user agent non identificati

Per siti che vogliono il controllo completo, bloccando i bot che non si identificano chiaramente.

# blocca bot senza user agent
User-agent: *
Disallow: /

User-agent: Googlebot
Allow: /

User-agent: GPTBot
Allow: /blog/

User-agent: ClaudeBot
Allow: /blog/

User-agent: PerplexityBot
Allow: /blog/

Attenzione: bloccare i bot senza user agent può rompere monitoraggio, health check, e tool interni. Usalo con cognizione.

Livello 4: bot protection a livello applicazione

Per siti ad alto traffico, WooCommerce, o piattaforme con problemi di performance.

Usa plugin come Wordfence, SolidWP, o Cloudflare Bot Fight Mode. Ogni plugin ha i suoi pro e contro:

• Wordfence: regex avanzate, geoblocking, sfide JavaScript.
• Cloudflare Bot Fight Mode: challenge JS automatici, gestione a livello edge.
• SolidWP (ex iThemes Security): blocking basato su signature, meno invasivo.

Quando usarlo: e-commerce, siti con problemi di banda, portali WooCommerce, siti con bot maleducati specifici.

Configurazione ottimale per un blog WordPress nel 2026

Per un blog editoriale tecnico come questo, applico questa configurazione ibrida: robots.txt granulare + bot protection a livello CDN.

robots.txt:

# consenti motori AI principali con rate limit
User-agent: GPTBot
Allow: /blog/
Disallow: /wp-admin/
Crawl-delay: 10

User-agent: OAI-SearchBot
Allow: /blog/
Crawl-delay: 5

User-agent: ChatGPT-User
Allow: /blog/

User-agent: ClaudeBot
Allow: /blog/
Crawl-delay: 15

User-agent: Claude-User
Allow: /blog/

User-agent: PerplexityBot
Allow: /blog/
Crawl-delay: 5

User-agent: Perplexity-User
Allow: /blog/

User-agent: Google-Extended
Allow: /blog/

User-agent: Applebot-Extended
Allow: /blog/

User-agent: CCBot
Disallow: /

# blocca bot maleducati noti
User-agent: Bytespider
Disallow: /

User-agent: ImagesiftBot
Disallow: /

# consenti tutto il resto con default
User-agent: *
Disallow: /wp-admin/
Allow: /

Plugin consigliati:

• Cloudflare (free plan): bot fight mode + WAF rules custom per bot AI
• Wordfence: regex personalizzate per bloccare bot che ignorano robots.txt
• WP Cloudflare Super Page Cache: caching edge per ridurre impatto PHP

Impatto sui Core Web Vitals

I crawler AI scaricano risorse come gli utenti: HTML, CSS, JS, immagini. Ma non eseguono JavaScript come fa un browser. Quindi non impattano LCP/INP direttamente. Impatto indiretto però c'è: se il tuo server è sotto carico, anche l'utente umano soffre.

Soluzione: caching aggressivo lato server o CDN. Con Cloudflare o Fastly, anche con 10.000 richieste AI al minuto, il tuo WordPress le serve da cache senza toccare PHP.

Snippet di configurazione WP Rocket + Cloudflare:

# imposta cache page per tutti i bot (WordPress wp-config.php)
define('WP_CACHE', true);
define('WP_ROCKET_WHITE_LABEL_FOOTER', false);
# esclude user agent bot dal caching per evitare problemi di personalizzazione
add_filter('rocket_cache_reject_ua', function($uas){
    $uas[] = 'facebookexternalhit';
    return $uas;
});

Monitoraggio e dashboard

Non ottimizzi ciò che non misuri. Ecco la mia dashboard minima mensile:

# report mensile crawler AI (eseguilo il primo del mese)
LOG=/var/log/nginx/access.log
MONTH=$(date -d "last month" +%Y/%m)
echo "=== Report crawler AI $MONTH ==="
grep "$MONTH" $LOG | grep -E 'GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot|CCBot' \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn
echo "=== Top URL crawlate ==="
grep "$MONTH" $LOG | grep -E 'GPTBot|ClaudeBot' \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

Per chi non ha accesso SSH al server, plugin come WP Statistics o Matomo Cloud mostrano il traffico bot per categoria.

Caso reale: blog tecnico con 3.000 articoli

Un cliente con blog WordPress da 3.000 articoli, 80.000 visitatori unici/mese, hosting VPS 4 vCPU, ha visto nel 2025 un'esplosione di traffico AI che ha portato il server a saturazione 3-4 volte a settimana.

Soluzione applicata:

1. robots.txt granulare con rate limit specifici (vedi esempio sopra)
2. Cloudflare con cache aggressiva e bot fight mode
3. Wordfence con regex custom per bloccare Bytespider, AhrefsBot, SemrushBot (bot aggressivi che non servono il business)
4. Esclusione dal caching di pagine autenticate o con cookie personalizzati

Risultato a 60 giorni: carico CPU sceso da 75% medio a 25%, banda ridotta del 40%, zero downtime, citazioni su Perplexity passate da 0 a 23/mese.

Errori comuni da evitare

1. Bloccare tutto indiscriminatamente: perdi opportunità di citazione e traffico referral.
2. Bloccare Googlebot per errore: succede con regex troppo aggressive su Wordfence. Fai sempre un test dopo ogni regola.
3. Ignorare i log: i crawler cambiano strategia ogni mese, devi monitorare.
4. Dimenticare CDN: senza caching edge, la gestione robots.txt serve a poco su siti medio-grandi.
5. Non documentare le regole: dopo 6 mesi non ricordi più cosa hai bloccato. Tieni un file ai-bot-policy.md con tutte le decisioni.

FAQ su AI bot e WordPress

Devo bloccare GPTBot? Dipende dal modello di business. Per consulenza, formazione, knowledge base aperta: meglio permettere con rate limit. Per e-commerce, paywall, contenuti originali protetti: meglio bloccare.

PerplexityBot ignora robots.txt? Sì, in alcuni casi. Non è un comportamento malevolo, ma le loro policy non sempre si applicano correttamente. Per proteggersi davvero serve bot protection a livello applicazione.

Quanto traffico AI è troppo? Soggettivo. Se il tuo server regge e il budget è sano, non c'è un limite fisso. Se noti degrado di performance, intervieni.

Posso tracciare le citazioni effettive? Sì, vedi sezione monitoraggio. Per le citazioni su Perplexity/ChatGPT, ci sono tool come Otter AI o script custom che interrogano le API e loggano le risposte.

Cloudflare Bot Fight Mode funziona sui bot AI? Sì, identifica e challenge-i bot noti. Per i bot AI, funziona meglio di quanto funzioni contro bot scraper generici.

Devo aggiornare robots.txt spesso? Almeno ogni 3 mesi, perché nuovi bot emergono e quelli esistenti cambiano comportamento. Tieni una routine di revisione.

WordPress ha plugin nativo per gestire i bot AI? No, ma Rank Math, Wordfence, SolidWP hanno opzioni specifiche. Plugin dedicati emergenti nel 2026: AI Bot Blocker, Bot Manager Pro.

Conclusione operativa: la tua checklist AI bot

I crawler AI non sono né buoni né cattivi, sono un nuovo tipo di traffico che va gestito con consapevolezza. WordPress ti dà gli strumenti per farlo a livello di robots.txt, plugin e CDN.

Checklist operativa per il prossimo mese:

• Analizza i log: quali bot AI visitano il tuo sito oggi?
• Decidi la policy: permettere, bloccare o rate-limitare per ciascuno
• Aggiorna robots.txt con regole granulari
• Configura Cloudflare con bot fight mode e cache aggressiva
• Monitora il carico del server: picchi anomali? Banda in crescita?
• Valuta l'impatto sulle citazioni: stai guadagnando o perdendo?
• Documenta le decisioni in un file ai-bot-policy.md

Riferimenti utili

• Lista bot AI aggiornata
• Cloudflare bot protection
• Wordfence plugin
• Kinsta AI bot report
• WooCommerce bot protection
• OpenAI bot documentation
• Anthropic bot policy
• Perplexity bot docs
• WPVibe e MCP per WordPress (articolo interno)
• WordPress 7.0 AI Connectors (articolo interno)
• Plugin WordPress piratati e sicurezza (articolo interno)
• Wordfence bot management