AI bot WordPress 2026: perché il blanket blocking non funziona più

Il blocco totale è la scelta peggiore del 2026

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.