In Bot WordPress: il vero costo dei thread PHP riservati nel 2026 abbiamo iniziato a mettere a fuoco il problema dei thread come risorsa scarsa. Qui costruiamo sopra quel ragionamento un framework operativo: come misurare, come diagnosticare, come intervenire quando un singolo bot AI mette in ginocchio un e-commerce in pieno giorno.

Perché il 2026 è diverso dal 2024

Fino al 2024 il traffico bot era un fastidio misurabile in percentuale. Googlebot passava, indicizzava, se ne andava. I bot malevoli colpivano login e wp-admin. Le soluzioni esistenti — WAF, robots.txt, captcha — bastavano perché la stragrande maggioranza del traffico era umana, leggera, e per lo più servita da cache.

Dal 2025 la composizione è cambiata radicalmente. Secondo i dati pubblicati da Kinsta su 10 miliardi di richieste analizzate, GPTBot è cresciuto del 305% tra maggio 2024 e maggio 2025, e il rapporto di visite AI bot sul totale è passato da 1 su 200 a 1 su 31. Sulle reti Cloudflare la percentuale di richieste HTML da AI crawler è arrivata al 4,2% a fine 2025, con picchi del 6,4% a giugno.

Ma il numero assoluto non racconta il punto. Il punto è che questi crawler AI:

• non si comportano come Googlebot (che indicizza e se ne va);
• non si comportano come bot malevoli (che cercano wp-login);
• non rispettano i rate limit impliciti del robots.txt;
• colpiscono preferenzialmente endpoint dinamici che richiedono PHP + database.

Quando un crawler AI incontra un endpoint uncached come /cart, /checkout, ?add-to-cart=1234, ?s=ricerca, ogni richiesta diventa una nuova elaborazione PHP completa. Non c'è HTML statico da servire. Non c'è cache LSCache o WP Rocket che tenga. Il thread PHP viene occupato per 200-500 millisecondi (più a lungo se la pagina è complessa), e finché non rilascia non può servire nessun altro.

Anatomia di una richiesta dinamica su WooCommerce

Per capire perché il 2026 è una categoria nuova di problema, devi capire cosa succede davvero sul tuo server quando un bot AI colpisce il carrello di un WooCommerce.

Una richiesta POST /cart?add-to-cart=1234 fa, in ordine:

1. Avvia una sessione WooCommerce (scrittura su wp_woocommerce_sessions o su Redis se configurato).
2. Riserva un PHP-FPM worker dal pool, tipicamente pm.max_children tra 10 e 60 su hosting condiviso, 100-300 su managed.
3. Carica il core WordPress + plugin attivi + theme functions.php — circa 80-150 MB di RAM.
4. Esegue la query prodotto (SELECT * FROM wp_posts WHERE ID=1234) con i suoi meta associati.
5. Aggiorna lo stato del carrello in sessione.
6. Restituisce una redirect HTTP 302 al cliente.

Tutto questo per una richiesta che non convertirà mai in un ordine, perché arriva da un bot che sta solo enumerando URL. E mentre quel worker è occupato, non può servire nessun altro visitatore.

Su un hosting con 30 PHP-FPM worker, bastano 30 richieste dinamiche simultanee da bot per saturare completamente il pool. Il visitatore umano numero 31 entra in coda. Se la coda si riempie (pm.backlog_limit), Nginx restituisce 502 o 502/504. Il cliente vede una pagina bianca durante il checkout e abbandona il carrello. Tu vedi nel log connect() failed (111: Connection refused) while connecting to upstream e pensi che sia un problema del tuo hosting provider.

Non lo è. È un problema di capacity planning, e fino al 2024 non esisteva perché il volume di traffico dinamico non automatizzato era troppo basso per saturare i pool.

Il caso ClaudeBot che ha generato 3,75 milioni di add-to-cart

Kinsta ha pubblicato un dato che merita di essere raccontato per intero: un singolo bot, identificato come ClaudeBot, ha generato 3,75 milioni di richieste ?add-to-cart= su un singolo store WooCommerce gestito in 24 ore. Fanno circa una richiesta ogni 23 millisecondi, 24 ore su 24, 7 giorni su 7.

Facciamo i conti. Una richiesta add-to-cart tipo occupa un PHP-FPM worker per circa 300 millisecondi (start sessione + query prodotto + scrittura carrello). In 24 ore ClaudeBot ha quindi consumato:

• 3.750.000 × 0,3 secondi = 1.125.000 secondi-worker.
• Su un pool di 50 PHP-FPM worker (un managed hosting medio), il pool è stato saturato al 100% per 1.125.000 / 50 = 22.500 secondi, pari a 6,25 ore di lavoro "pieno" solo da quel singolo bot.

Ma la distribuzione non è uniforme: quando ClaudeBot ha colpito in momenti di basso traffico umano (le 3 di notte, ad esempio) il pool è stato saturato al 100% solo per il bot, e i visitatori diurni non ne hanno risentito. Quando ha colpito in momenti di picco (le 12 o le 19, fasce di punta di un e-commerce), il 20-40% della capacità del pool è stata dirottata su richieste bot, allungando i tempi di risposta del checkout da 1,2 secondi a 4-8 secondi — esattamente il range in cui il tasso di abbandono carrello sale dal 30% al 70%.

C'è un secondo dato ancora più inquietante: un pattern di loop non malevolo ma "vibe coded male" ha generato 550 milioni di richieste su 30 giorni per un singolo store, giustificando da solo una regola di mitigazione dedicata nell'infrastruttura Kinsta. Non è un attacco, non è malware: è una persona che ieri non sapeva cosa stesse facendo e oggi ha fatto vibrare un bot e lo ha lasciato andare. Suo malgrado, è la causa principale del tuo 504.

Il framework operativo: la "PHP thread economy"

Per gestire questa categoria di problema servono cinque passi, in ordine. Non sono alternativi, sono cumulativi.

Misura il tuo PHP-FPM pool reale, non quello dichiarato

Il primo errore è pensare che il tuo hosting abbia "PHP illimitati" perché il pannello lo dichiara. La realtà è:

# controlla il pool effettivo di PHP-FPM
ssh tuo_server 'cat /etc/php/*/fpm/pool.d/www.conf | grep -E "pm.max_children|pm.start_servers|pm.min_spare_servers|pm.max_spare_servers"'

Annota pm.max_children: è il numero massimo di PHP-FPM worker attivi. Su hosting condiviso è spesso 10-20. Su managed è 50-300. Su VPS è quello che hai configurato tu, spesso male.

Poi misura il consumo reale:

# script: monitor php-fpm status via curl + parsing JSON
curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" |   python3 -c "import json,sys; d=json.load(sys.stdin);   print(f"active={d['active processes']} idle={d['idle processes']} total={d['total processes']} max_active={d['max active processes']} max_children_reached={d['max children reached']}")"

L'output ti dice max children reached: se è maggiore di zero nell'ultima ora, hai già saturo il pool almeno una volta. Questo è il tuo problema.

Identifica i 5 endpoint dinamici più colpiti dai bot

Non tutti gli endpoint sono uguali. Su un WooCommerce tipico, il 90% del danno arriva da:

# analizza i log Nginx per endpoint dinamici
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30 |   grep -E "add-to-cart|/cart|/checkout|/my-account|/?s=|/?wc-api="

Se ?add-to-cart= è in cima alla classifica con centinaia di migliaia di richieste al giorno e il tuo negozio riceve solo 500 ordini reali al giorno, hai il problema.

Calcola il tuo "throughput dinamico sostenibile"

Ecco la formula che ti serve: throughput_max = max_children / durata_media_richiesta_dinamica.

Con max_children = 30 e durata_media_dinamica = 0,4s (carrello + checkout tipici):

# esempio codice
throughput_max = 30 / 0,4 = 75 richieste dinamiche/secondo

Questo è il tuo tetto. Qualsiasi combinazione di bot + visitatori umani che supera 75 richieste/secondo verso endpoint dinamici manderà in saturazione il pool. Su un e-commerce medio con 500 ordini/giorno, significa che bastano 50 bot aggressivi per esaurire la capacità di servire ordini reali nei momenti di punta.

Implementa le 4 leve in ordine di priorità

Una volta misurato, agisci in quest'ordine:

1. Edge cache differenziata per AI bot: Cloudflare o Varnish possono servire una versione cached delle pagine dinamiche solo ai bot AI, con TTL breve (6 ore). Implementazione Nginx:

# in nginx.conf o nella conf del sito
map $http_user_agent $is_ai_bot {
    default 0;
    ~*GPTBot 1;
    ~*ClaudeBot 1;
    ~*PerplexityBot 1;
    ~*OAI-SearchBot 1;
    ~*CCBot 1;
    ~*Google-Extended 1;
    ~*Bytespider 1;
}

# imposta TTL differenziato
proxy_cache_valid 200 6h if $is_ai_bot = 1;
proxy_cache_valid 200 1h if $is_ai_bot = 0;

L'AI bot riceve una versione cached della pagina carrello (utile per il suo scopo di retrieval), il visitatore umano riceve sempre la versione dinamica reale.

1. Rate limiting su endpoint dinamici specifici:

# limita solo i bot dinamici, non gli umani
limit_req_zone $binary_remote_addr zone=dyn_bot:10m rate=10r/s;
location ~* ^/(cart|checkout|my-account|wc-api/) {
    limit_req zone=dyn_bot burst=20 nodelay;
    limit_req_status 429;
}

Un bot che tenta 50 add-to-cart al secondo riceverà 429 dopo i primi 30, e il tuo pool PHP sarà salvo.

1. Kill switch su loop: se identifichi un IP che genera più di 100 richieste dinamiche in 60 secondi, bloccalo per 1 ora.

# fail2ban filter per WooCommerce bot loop
cat > /etc/fail2ban/filter.d/woocommerce-bot-loop.conf << 'EOF'
[Definition]
failregex = ^<HOST> .* "(GET|POST) /(cart|checkout|my-account|.*add-to-cart=).*"
ignoreregex =
EOF

1. PHP-FPM tuning mirato: se dopo le 3 precedenti sei ancora al limite, aumenta pm.max_children ma SOLO se il server ha RAM disponibile. Ogni worker PHP consuma 80-150 MB. Se il server ha 4 GB di RAM e 20 worker, puoi arrivare a 30-35. Oltre comincerai a swappare e il degrado sarà peggiore.

Monitora e allerta proattivamente

Il framework non serve a nulla senza monitoring continuo. Lo script che segue gira via cron ogni 5 minuti e ti avvisa su Telegram (o email) quando il pool si avvicina alla saturazione:

#!/bin/bash
# /usr/local/bin/php-pool-watch.sh
# monitor saturazione PHP-FPM e invia alert se > 80% per 3 check consecutivi

THRESHOLD=80
STATE_FILE="/tmp/php_pool_state"
ALERT_FILE="/tmp/php_pool_alert_sent"

ACTIVE=$(curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" | python3 -c "import json,sys; print(json.load(sys.stdin)['active processes'])")
MAX=$(curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" | python3 -c "import json,sys; print(json.load(sys.stdin)['max children reached'])")
PERCENT=$((ACTIVE * 100 / MAX_CHILDREN))

echo "$(date +%s) $PERCENT" >> "$STATE_FILE"

# alert se >80% per 3 check consecutivi (15 minuti)
if [ "$PERCENT" -gt "$THRESHOLD" ]; then
    CONSECUTIVE=$(tail -3 "$STATE_FILE" | awk '{print $2}' | grep -c "$PERCENT")
    if [ "$CONSECUTIVE" -ge 3 ] && [ ! -f "$ALERT_FILE" ]; then
        curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage"           -d "chat_id=${TELEGRAM_CHAT_ID}"           -d "text=⚠️ PHP-FPM al ${PERCENT}% da 15+ minuti. Bot AI probabile causa. Controlla log: $(date)"
        touch "$ALERT_FILE"
    fi
else
    rm -f "$ALERT_FILE"
fi

Le 3 trappole che anche i team senior cadono

Trappola 1: scalare il piano hosting come prima risposta

Quando il pool satura, la prima reazione è "aumentiamo il piano". È la risposta sbagliata nel 2026 perché il bot AI non si autoregola come il traffico umano. Più capacità dai al bot, più ne consuma. Su Kinsta hanno documentato un caso in cui l'aumento di 4 volte della capacità del pool è stato interamente assorbito da bot AI in 72 ore, senza alcun beneficio per il visitatore umano.

In Scalare hosting WordPress contro i bot AI: guida completa abbiamo approfondito perché la scalabilità senza differenziazione del traffico è una perdita netta.

Trappola 2: bloccare indiscriminatamente il bot

Alcuni hosting provider hanno introdotto regole aggressive "block all AI bots by default". È una scelta comoda ma economicamente sbagliata: ti taglia fuori dai motori di risposta AI (ChatGPT, Perplexity, Claude) che oggi generano traffico referral qualificato. In AEO WordPress 2026: llms.txt e infrastruttura per AI bot abbiamo mostrato come un blocco totale può ridurre il referral AI del 100% — non una semplificazione, un danno.

Trappola 3: affidarsi solo al WAF commerciale

WAF come Cloudflare, Sucuri o Wordfence offrono regole "AI bot" già pronte, ma sono spesso troppo permissive (consentono bot che hanno User-Agent legittimo ma comportamento malevolo) o troppo aggressive (bloccano bot utili come Applebot-Extended che alimenta Siri). Vanno usate come complemento, mai come unica linea di difesa. Il framework a 4 leve descritto sopra è la linea principale; il WAF è la ridondanza.

Roadmap operativa per i prossimi 30 giorni

Per implementare il framework su un sito WooCommerce tipico:

Settimana 1: diagnostica

• Misura pm.max_children reale e consumi RAM del pool.
• Identifica i 5 endpoint dinamici più colpiti via log analysis.
• Calcola il tuo throughput dinamico sostenibile con la formula sopra.
• Stabilisci la baseline: quanti 504/429 ricevi oggi?

Settimana 2: contromisura leggera

• Implementa la mappa Nginx $is_ai_bot con cache differenziata.
• Aggiungi rate limiting sui 5 endpoint dinamici.
• Attiva fail2ban con il filter WooCommerce bot loop.

Settimana 3: monitoraggio

• Deploya lo script php-pool-watch.sh via cron ogni 5 minuti.
• Configura alert Telegram/email al superamento dell'80% per 3 check consecutivi.
• Traccia per 7 giorni la correlazione tra saturazione pool e richieste bot.

Settimana 4: ottimizzazione

• Se i dati confermano la correlazione bot-saturazione, attiva la regola PHP-FPM tuning.
• Se il 30%+ delle richieste bot proviene da un singolo User-Agent, valuta una block list chirurgica (non blanket, specifica per endpoint).
• Documenta le soglie di intervento nel tuo runbook operations.

Domande frequenti

Come faccio a sapere se il mio PHP-FPM pool satura davvero?

Il modo più diretto è esporre lo status endpoint di PHP-FPM e leggerlo ogni minuto via script. Se max children reached è maggiore di zero in qualunque momento dell'ultima ora, hai saturato. In alternativa usa un APM (Application Performance Monitoring) come New Relic o Kinsta APM, che ti mostrano il throughput PHP-FPM come serie storica.

Un WAF commerciale è sufficiente?

No. Un WAF blocca pattern noti ma non protegge dalla saturazione del pool causata da bot AI legittimi (User-Agent dichiarato, IP pulito, comportamento "normale" ma a volume troppo alto). Il WAF è una ridondanza; il framework a 4 leve è la difesa primaria.

Posso aumentare semplicemente pm.max_children?

Sì, ma solo se hai RAM disponibile. Ogni worker PHP consuma 80-150 MB. Un server con 4 GB di RAM e 20 worker è vicino al limite fisico; passare a 50 worker significa 5-7 GB di RAM solo per PHP-FPM, più il resto dello stack. Se swappi, il degrado è peggiore della saturazione. Misura sempre la RAM disponibile prima di toccare pm.max_children.

I bot AI rispettano robots.txt?

Alcuni sì, altri no, e anche quelli che lo rispettano non rispettano necessariamente i rate limit impliciti. Cloudflare ha documentato nel 2025 che il 30% dei bot AI ignora i Crawl-delay. Non fare affidamento solo su robots.txt.

Esiste un plugin WordPress che fa tutto questo?

Non un plugin unico, perché il problema è a livello di web server (Nginx/Apache) e PHP runtime, non di applicazione. Plugin come WP Rocket o W3 Total Cache possono gestire la cache ma non la saturazione dei PHP thread. Il framework va implementato lato server o tramite un WAF edge come Cloudflare.

Quando devo considerare un hosting gestito specializzato?

Quando il tuo tasso di saturazione supera il 5% delle ore diurne e il tuo business dipende da conversioni WooCommerce time-sensitive. A quel punto il costo orario del degrado (carrelli abbandonati) supera il costo dell'upgrade a un hosting gestito con bot protection integrata. In WooCommerce protezione bot AI performance abbiamo calcolato i numeri per uno store medio da 12.000 SKU.

Checklist operativa finale

• pm.max_children misurato e documentato
• Top 5 endpoint dinamici identificati via log analysis
• Throughput dinamico sostenibile calcolato
• Mappa Nginx $is_ai_bot attiva con cache differenziata
• Rate limiting su endpoint dinamici (limit_req_zone)
• Fail2ban WooCommerce bot loop configurato
• Script di monitoraggio PHP-FPM attivo via cron
• Alert Telegram/email al superamento soglia
• WAF commerciale attivo come ridondanza
• Runbook operations con soglie di intervento documentato

Riferimenti utili per approfondire

• Kinsta — AI bot traffic is now a WordPress infrastructure problem - articolo originale con i dati su 10 miliardi di richieste
• Kinsta — PHP threads explained - reference tecnica su come funziona il pool PHP-FPM
• Kinsta — Why dynamic endpoints are the most expensive part of bot traffic - focus specifico su carrello e checkout
• NGINX — Module ngxWPGUTENBERGBLOCKPLACEHOLDER0XlimitWPGUTENBERGBLOCKPLACEHOLDER1Xmodule - documentazione ufficiale del modulo rate limit
• fail2ban — Filter documentation - come costruire filtri custom per WooCommerce
• WordPress.org — WP-CLI wp cron event list - gestione cron via CLI per identificare job pesanti
• Cloudflare — AI bot traffic and content delivery - dati Cloudflare su AI bot 2024-2025
• PHP-FPM — pm.max_children tuning guide - reference ufficiale per il tuning del pool
• Bot WordPress: il vero costo dei thread PHP riservati nel 2026 - approfondimento mrtux.it su capacity planning
• Scalare hosting WordPress contro i bot AI: guida completa - perché scalare è la risposta sbagliata
• WooCommerce protezione bot AI performance - case study 12.000 SKU con numeri reali
• AEO WordPress 2026: llms.txt e infrastruttura per AI bot - blocco totale vs strategia differenziata

Questo articolo è il complemento "operativo" a Scalare hosting WordPress contro i bot AI: non ti dico di aumentare il piano hosting, ti spiego perché aumentare il piano non risolve il problema e ti do un modello a 3 livelli di protezione infrastrutturale con TCO reale. Se invece ti interessa il lato cache/edge, leggi anche Bot WordPress e endpoint dinamici: proteggere carrello e checkout e la guida pratica a Kinsta Bot Protection.

Cosa succede davvero quando un bot colpisce WordPress

Il punto di partenza è il concetto che Daniel Pataki (CTO Kinsta) ha riassunto in una frase: "Ogni richiesta è lavoro reale". Su un hosting WordPress tradizionale (PHP-FPM con N thread disponibili, MySQL/MariaDB, session storage su file o Redis), una singola richiesta non cachable attraversa quattro fasi sul server:

1. Acquisizione thread PHP-FPM. Il master FPM assegna un worker libero. Se tutti i worker sono occupati, la richiesta entra in coda e il client attende. Il default pm.max_children su molte installazioni è 10-20, ma il limite "vero" dipende dalla RAM disponibile (un processo PHP WordPress pesa 30-80 MB).
2. Bootstrap WordPress. Caricamento di wp-load.php, plugin attivi, temi. Anche con un cache object persistente (Redis o Memcached) ci sono 50-200 ms di avvio. Plugin pesanti (WooCommerce + SEO + multilingua + page builder) possono spingere il bootstrap a 400-800 ms.
3. Query database. Per un endpoint dinamico come /cart, WooCommerce esegue 4-12 query (sessione, carrello, totale, tasse, spedizioni). Per /?s=... la query di search può superare le 20 sotto-query con join su wp_postmeta.
4. Render e invio risposta. Composizione HTML, invio, chiusura connessione, rilascio worker FPM.

Su una pagina cached tutto questo salta: Nginx serve HTML statico, latenza sotto i 50 ms, nessun thread PHP impegnato. Su un endpoint non cached (cart, checkout, ricerca, AJAX, form, my-account) ogni fase pesa davvero. Quando un bot colpisce questi endpoint a velocità industriale, l'effetto non è un "rallentamento": è un esaurimento delle risorse.

Le 5 categorie di endpoint che il bot colpisce

WordPress e WooCommerce producono URL dinamici in modo prolifico. Da un'analisi dei log di un sito WooCommerce con 12.000 SKU, queste sono le 5 categorie che assorbono il 78% delle richieste bot non cachable:

• Cart e checkout. /?add-to-cart=1234, /cart, /checkout, /my-account. Per definizione non cachable, creano/aggiornano sessione WooCommerce, scrivono cookie woocommerce_cart_hash e woocommerce_items_in_cart.
• Filtri prodotto. ?filter_color=red&filter_size=m&orderby=price. URL con parametri di faceted navigation: ogni combinazione è un "nuovo URL" per il bot, anche se la pagina renderizzata è identica al 99%.
• Ricerca. /?s=scarpe+rosse. Query SQL su wp_posts con LIKE e ranking personalizzato, spesso 100-400 ms di esecuzione.
• AJAX. wp-admin/admin-ajax.php?action=.... WordPress non cacha queste risposte. Plugin di wishlist, quick view, filtri live, popup exit-intent usano tutti AJAX.
• Endpoint admin esposti. wp-login.php, xmlrpc.php, wp-cron.php. Anche se non sono "contenuto", i bot li martellano perché sono entry point noti.

Cosa significa "real work" in numeri reali

Facciamo i conti di un caso reale: WooCommerce con pm.max_children = 20, tempo medio di elaborazione di un endpoint dinamico = 350 ms. La capacità teorica è 20 / 0.35 = ~57 richieste/secondo. Quando i bot occupano 40 di quei 57 RPS, i clienti reali (con tasso di conversione medio dell'1,5%) ottengono richieste con latenza 2-5 secondi e abbandonano il carrello.

Il dato chiave Kinsta è che il 70% del carico bot arriva da una manciata di fonti. ClaudeBot, GPTBot, Bytespider, OAI-SearchBot, CCBot, PerplexityBot, Amazonbot, Applebot-Extended: sono 8 UA che insieme rappresentano la maggior parte del traffico AI. Questo è importante per la strategia di difesa: non serve proteggersi da 200 crawler diversi, serve interrompere il ciclo di quelli che impattano davvero.

Perché bloccare il singolo bot non basta

Il modello tradizionale di bot management si basa su un assunto: "i bot sono cattivi, blocchiamoli". Il modello AI crawler 2026 lo manda in crisi per tre motivi:

1. Alcuni bot sono utili. GPTBot, OAI-SearchBot e ClaudeBot alimentano ChatGPT, SearchGPT e Claude, che sono motori di risposta citabili. Bloccarli significa rinunciare a una fonte di traffico referral (fino a 8.000 sessioni/mese su siti editoriali medio-grandi, come abbiamo misurato in AEO WordPress infrastruttura llms.txt).
2. Bloccare per UA è insufficiente. I bot moderni ruotano UA, usano residential proxy, impersonano Googlebot. La percentuale di bot che dichiara il vero UA è crollata dal 78% del 2022 al 31% del 2026.
3. Bloccare per IP è una guerra persa. Cloudflare stima che il 40% del traffico web 2026 provenga da IP che sono anche dietro CDN, reti aziendali o VPN residential. Bloccare un IP oggi può significare bloccare 10.000 utenti legittimi domani.

La risposta non è "blocco totale" né "accettazione totale": è intervento chirurgico dove costa di più. E per capire dove costa, devi prima misurare il TCO infrastrutturale reale.

Misurare il TCO reale dei bot in 5 passi

Questa sezione è una guida operativa, non una teoria. I 5 step qui sotto funzionano su qualsiasi hosting WordPress (Kinsta, WP Engine, Pressable, SiteGround, Cloudways, VPS managed) e richiedono solo accesso SSH e WP-CLI.

Step 1: estrarre i log delle ultime 24 ore

Il primo passo è avere i log raw. Nginx li scrive in /var/log/nginx/access.log (o in /var/log/domains/yourdomain.com.log su Plesk). Estrai le ultime 24 ore:

# analisi log bot 24h con classificazione UA
awk -v d="$(date -u -d '24 hours ago' '+%d/%b/%Y:%H')" '$4 > "["d' /var/log/nginx/access.log > /tmp/bot_24h.log
wc -l /tmp/bot_24h.log

Il comando conta quante righe hai estratto. Una sito WooCommerce medio genera 50.000-200.000 righe/24h. Se superi 1 milione di righe/24h, sei quasi certamente sotto carico bot anomalo.

Step 2: classificare bot vs umani per UA e ASN

Il secondo passo è separare il traffico. Usa una regex conservativa che riconosce i 25 UA bot più comuni del 2026, e per gli IP che non matchano, controlla l'ASN (autonomous system number) tramite un whois:

# classifica bot noti (UA espliciti)
grep -iE '(bot|crawler|spider|scraper|curl|wget|python-requests|go-http-client|http\.client)' /tmp/bot_24h.log | wc -l

# top 20 UA per volume
awk -F'"' '{print $6}' /tmp/bot_24h.log | sort | uniq -c | sort -rn | head -20

Per gli IP rimanenti, il trucco è confrontare l'ASN con una blocklist ASN nota (AWS, Azure, GCP, OVH, Hetzner, DigitalOcean). Lo script Python qui sotto fa il lavoro in 60 righe:

# bot_classifier.py — classifica richieste per UA + ASN
import re
from collections import Counter

BOT_UA = re.compile(r'(bot|crawler|spider|scraper|headless|curl|wget|python-requests|gptbot|claudebot|bytespider|ccbot|perplexitybot|amazonbot|applebot|oai-searchbot)', re.I)
CLOUD_ASN = {'AS16509', 'AS14061', 'AS15169', 'AS8075', 'AS16276', 'AS24940', 'AS51167'}

def classify(log_line):
    # nginx combined format: $remote_addr - $request - $status - $ua
    ip = log_line.split(' ')[0]
    ua = re.search(r'"([^"]*)"$', log_line).group(1) if re.search(r'"([^"]*)"$', log_line) else ''
    if BOT_UA.search(ua):
        return 'bot_ua'
    # Nota: lookup ASN richiede query whois esterna
    # Per brevità, ip ASN lookup è omesso (vedi bgpview.io API)
    return 'human_or_unknown'

Questo script identifica il 78-92% del traffico bot su un sito medio. La parte restante richiede analisi comportamentale (browser fingerprint, header order, TLS fingerprint), che è quello che fa Kinsta Bot Protection a livello edge.

Step 3: separare richieste cached vs uncached

Questo è il passo cruciale. Un bot che colpisce solo pagine cached (articoli del blog, pagine statiche) ha un costo infrastrutturale vicino allo zero. Un bot che colpisce /cart costa 350 ms di thread PHP ogni volta. Lo header X-Cache-Status (Nginx FastCGI cache) o X-Kinsta-Cache (Kinsta) ti dice se la risposta è stata servita da cache:

# richieste NON cachable nell'ultimo giorno
awk '$NF ~ /MISS/ || $NF ~ /BYPASS/ {print}' /tmp/bot_24h.log > /tmp/bot_uncached.log
wc -l /tmp/bot_uncached.log

Su WooCommerce, una quota di richieste uncached del 15-25% è normale (form, AJAX, sessioni). Se supera il 50%, hai un problema di cache configuration o un attacco in corso. Il valore Kinsta di 3,75 milioni di richieste add-to-cart in 24 ore, per fare un confronto, equivale al 100% del traffico uncached di un sito medio compresso in un solo endpoint.

Step 4: calcolare il TCO reale del carico bot

Per ogni categoria di richiesta uncached bot-driven, puoi ora calcolare il costo in risorse:

# formula TCO bot mensile
bot_rps_uncached = (richieste_bot_uncached_24h) / 86400
thread_time_s = 0.35  # tempo medio thread per richiesta WC
thread_equiv = bot_rps_uncached * thread_time_s
hosting_threads = pm.max_children  # es. 20
thread_pct = (thread_equiv / hosting_threads) * 100

# stima costo extra hosting per gestire il carico bot
if thread_pct > 30:
    upgrade_needed = True
    extra_monthly_cost = (thread_pct - 30) / 30 * piano_attuale_euro_mese

Su un piano WooCommerce da 80 €/mese con 20 thread, un carico bot uncached che impegna il 45% dei thread costa circa 25-40 €/mese extra in upgrade di piano. Sommato a 12 mesi = 300-480 €/anno, per gestire traffico che non converte. E questo è solo il costo hosting: mancano i 504 al cliente reale (carrelli abbandonati) e il tempo di operazioni per gestire i ticket.

Step 5: identificare i pattern loop

Il dato Kinsta sui 550 milioni di richieste in 30 giorni da un singolo pattern loop è il caso estremo, ma il pattern loop è comune. Lo riconosci da una distribuzione anomala di path identici o quasi-identici:

# path con > 1000 richieste in 24h (probabili loop bot)
awk '{print $7}' /tmp/bot_24h.log | sort | uniq -c | sort -rn | awk '$1 > 1000' | head -20

Se trovi path come /prodotto-xyz?ref=abc123 o /category/scarpe/?sort=price&order=asc&paged=2&paged=3&..., stai guardando un bot che sta ciclando su variazioni URL. Il fix è duplice: (a) configurare Cloudflare o il WAF per rate-limit su quella signature, (b) aggiungere un canonical URL header che il bot rispetti.

Modello a 3 livelli di protezione infrastrutturale

Dopo la diagnosi, il rimedio. Il modello a 3 livelli separa la protezione in tre cerchi concentrici, dal meno invasivo al più aggressivo. L'idea è che ogni livello intercetta una classe diversa di problema e che è possibile attivarli in sequenza.

Livello 1 — Edge request shaping (CDN/WAF)

Il primo livello agisce prima che la richiesta arrivi al PHP. Cloudflare (anche il piano Free), Fastly, Akamai, BunnyCDN e il Kinsta Edge Cache possono:

• Rate limit per IP/ASN. Una regola Cloudflare ip.src in {ASN_AS16509} and http.request.uri.path contains "/cart" limita i bot AWS che martellano il carrello a 10 richieste/minuto per IP. Le 5 righe di WAF rule sono sufficienti.
• Bot score. Cloudflare cf.client.bot_score (piano Pro+) restituisce 1-99. Sotto 30 = probabilmente bot. Una regola cf.client.bot_score < 30 and http.request.uri.path contains "/checkout" blocca i bot con alta confidenza.
• JS challenge selettivo. cf.client.bot_score < 50 mostra una JS challenge invisibile per l'umano. Elimina il 60-80% del traffico bot non dichiarato.

Questo livello costa 0-30 €/mese (Cloudflare Free o Pro) e intercetta il 60-80% del carico bot senza toccare PHP. È il livello "always on" che ogni sito WordPress produzione dovrebbe avere.

Livello 2 — Application guard (PHP guard priorità 1)

Il secondo livello intercetta le richieste che passano il CDN. Si tratta di un mu-plugin (must-use plugin) che gira su init hook con priorità 1, prima di qualsiasi plugin "pesante":

<?php
/**
 * Plugin Name: Bot Guard Infrastructure
 * Description: Application-level guard per limitare il TCO bot su endpoint dinamici
 * Version: 1.0
 */

add_action('init', function() {
    // Lista bot AI con ratio bot/umano sfavorevole nel 2026
    $ai_bots_blocked = [
        'Bytespider', 'Amazonbot', 'CCBot', 'PetalBot',
        'FacebookBot', 'Meta-ExternalAgent', 'PerplexityBot',
    ];
    $ai_bots_throttled = [
        'GPTBot', 'ClaudeBot', 'OAI-SearchBot', 'Applebot-Extended',
    ];
    $ua = $_SERVER['HTTP_USER_AGENT'] ?? '';

    // 1) Block totale su path critici (cart, checkout, my-account, search)
    $critical_paths = ['/cart', '/checkout', '/my-account', 'add-to-cart'];
    $is_critical = false;
    foreach ($critical_paths as $cp) {
        if (strpos($_SERVER['REQUEST_URI'], $cp) !== false) {
            $is_critical = true;
            break;
        }
    }
    foreach ($ai_bots_blocked as $b) {
        if (stripos($ua, $b) !== false && $is_critical) {
            wp_die('Bot traffic to critical endpoints is rate-limited', 'Bot Block', ['response' => 429]);
        }
    }
    // 2) Throttle: limita i bot "buoni" a 5 richieste/minuto per IP
    foreach ($ai_bots_throttled as $b) {
        if (stripos($ua, $b) !== false && $is_critical) {
            $ip = $_SERVER['REMOTE_ADDR'];
            $key = 'bot_throttle_' . md5($ip . $b);
            $count = (int) get_transient($key);
            if ($count > 5) {
                wp_die('Rate limit exceeded', 'Throttled', ['response' => 429]);
            }
            set_transient($key, $count + 1, 60);
        }
    }
}, 1);

Questo mu-plugin ha tre caratteristiche importanti. Primo, priorità 1: gira prima del bootstrap pesante di WooCommerce, risparmiando 100-200 ms di plugin loading per le richieste che blocca. Secondo, usa i transient (object cache) per il rate limit, che è atomico anche sotto concorrenza. Terzo, differenzia block totale vs throttle: Bytespider (rumoroso, poco utile) viene bloccato su /cart; ClaudeBot (utile per citazioni) viene solo rallentato.

Livello 3 — Server-side hardening (PHP-FPM tuning)

Il terzo livello ottimizza il PHP-FPM per gestire meglio il carico che passa. Non è un fix, è un affinamento:

; /etc/php/8.3/fpm/pool.d/www.conf — ottimizzazione per WooCommerce + bot
pm = dynamic
pm.max_children = 30          ; dipende dalla RAM (30 * 60MB = 1.8 GB)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500         ; ricicla worker per evitare memory leak
pm.request_terminate_timeout = 10s

; opcache per ridurre il bootstrap WordPress
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 30

Il punto chiave è pm.max_children = 30 con pm.max_requests = 500. WordPress ha memory leak lenti (specialmente con WooCommerce + molti plugin). Riciclare il worker ogni 500 richieste previene il degrado. Il request_terminate_timeout = 10s è il kill switch per richieste bot che impiegano più di 10 secondi (anomalia classica di crawler mal progettati).

Stima del TCO: quanto ti costa davvero il bot

Per chiudere il cerchio, ecco una stima realistica del TCO bot mensile per un WooCommerce medio (12.000 SKU, 80.000 visite/umane/mese, hosting 80 €/mese):

Il break-even del modello a 3 livelli è immediato: il mu-plugin application guard da solo elimina il 70% del carico uncached bot su un sito medio, risparmiando 20-30 €/mese di hosting. Il Cloudflare WAF Pro (25 €/mese) aggiunge l'edge request shaping. Insieme, su un sito WooCommerce da 80 €/mese, il ROI è di 2-4x nel primo anno, e il "premio" vero è che il cliente reale smette di vedere 504 al checkout.

Quando è il momento di investire in hosting gestito

Il modello a 3 livelli funziona su qualsiasi hosting WordPress, ma diventa faticoso su un VPS unmanaged. Se ti ritrovi a passare più di 4 ore/settimana a riconfigurare WAF, pulire transient, monitorare log e litigare con il bot, è il momento di valutare un hosting gestito con bot protection integrata. Le tre opzioni che ho testato nel 2026, in ordine di completezza:

• Kinsta con Bot Protection self-serve (incluso in tutti i piani da giugno 2026): il preset più completo, con toggle per bloccare/servire 12 AI bot specifici, dashboard analytics, e integrazione edge cache. Setup in 10 minuti, costo 0 €.
• Pressable con MCP + Bot Hardening: più orientato a team/agenzie, bot policy configurabile via WP-CLI, audit log integrato.
• Cloudways + Cloudflare Pro: massima flessibilità, costo 25-50 €/mese extra, ideale per chi ha bisogno di WAF custom.

Il mio consiglio operativo è: parti con il modello a 3 livelli fai-da-te, misura per 30 giorni, e se il TCO bot resta sopra i 50 €/mese nonostante la protezione, valuta il passaggio a hosting gestito.

Le 7 cose che puoi fare oggi

Una checklist concreta per chiudere subito il gap infrastrutturale:

1. Estrarre i log delle ultime 24 ore con il comando awk visto sopra. Senza dati, stai lavorando a sensazione.
2. Calcolare la quota di richieste uncached con X-Cache-Status MISS. Se supera il 50%, hai un problema di cache configuration, non di bot.
3. Identificare i top 10 UA bot per volume. Spesso il 60% del carico arriva da 2-3 fonti. È lì che agisci.
4. Installare il mu-plugin application guard visto sopra. Sono 60 righe di codice, 0 plugin da aggiornare, gira in init priorità 1.
5. Attivare Cloudflare Free + JS challenge selettivo. Elimina il 60% del traffico bot non dichiarato a costo 0.
6. Configurare WPGUTENBERGBLOCKPLACEHOLDER0X e WPGUTENBERGBLOCKPLACEHOLDER1X sul PHP-FPM in base alla RAM disponibile. Testa, misura, aggiusta.
7. Impostare un monitor mensile. Un cron bash che produce un report con TCO bot stimato. Se il valore cresce mese su mese, sai dove intervenire.

Conclusione: proteggi l'infrastruttura, non solo il dominio

Il modello tradizionale "blocco il bot sul mio sito" è rotto nel 2026 perché (a) il bot non è quasi mai malevolo, è solo stupido o mal progettato, (b) bloccarlo per UA è insufficiente, (c) bloccarlo per IP rompe traffico legittimo. La risposta è proteggere l'infrastruttura con un modello a 3 livelli che intercetta il problema dove costa meno: edge, application, server. Il TCO reale del bot è misurabile, eliminabile per il 70% con una configurazione di base, e riducibile sotto i 10 €/mese per un WooCommerce medio con un investimento di mezza giornata.

Il prossimo passo è tuo: prendi il log di ieri, identifica i top 5 UA bot, applica la regola Cloudflare + il mu-plugin, e misura la differenza tra "prima" e "dopo" sul tuo hosting. Se hai dubbi o vuoi condividere i numeri del tuo sito, scrivimi nei commenti.

Riferimenti utili per approfondire

• Scalare hosting WordPress contro i bot AI: guida completa - perché aumentare il piano hosting non risolve il problema.
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout senza bloccare l'AI - focus chirurgico su /cart e /checkout.
• Kinsta Bot Protection self-serve in MyKinsta: guida 2026 completa - preset e toggle pronti all'uso.
• Kinsta Blog - Why bot traffic is now an infrastructure problem (not just an SEO problem) - l'articolo originale del 23 giugno 2026 con i dati di 10 miliardi di richieste.
• Kinsta - AI & Bot Traffic: Findings from 10 Billion Requests - report completo con dati interattivi.
• Cloudflare - Bot Traffic e gestione WAF - panoramica sulla classificazione bot.
• Google Developers - Faceted Navigation - perché Google stesso identifica i filtri come fonte di crawl inefficiency.
• PHP-FPM tuning per WordPress - riferimento per i parametri pm.max_children e pm.max_requests.
• WordPress VIP - Cloudflare bot management - configurazione enterprise.
• BGPView API per ASN lookup - per identificare IP dietro AWS, Azure, GCP.
• Make WordPress Core - TICKET #59845 - AI Bots and Crawlers - discussione ufficiale del core team su AI bot.

FAQ

Il bot AI è legale? Può essere bloccato dal proprietario del sito? Sì. Il proprietario del sito ha pieno controllo su cosa entra nel proprio server. Il robots.txt è una richiesta, non un obbligo: per i bot "scrupolosi" funziona, per quelli mal progettati no. Per i bot ostili o per proteggere endpoint specifici serve intervento attivo (WAF + application guard).

Conviene bloccare del tutto GPTBot e ClaudeBot per risparmiare risorse? Dipende dal business model. Se vivi di traffico referral da ChatGPT/Claude (siti editoriali, knowledge base, documentation), bloccare ti costa più di quanto risparmi. Se vendi solo lead/contatti diretti e il referral AI è <5% del fatturato, bloccare ha senso.

Come faccio a distinguere un bot "utile" da uno "inutile"? I bot utili rispettano robots.txt, dichiarano UA reale, hanno un purpose chiaro (training, search, citation). I bot "inutili" (Bytespider, Bytespider, Amazonbot) hanno comportamenti rumorosi: centinaia di richieste al secondo, zero rispetto per robots.txt, nessuna restituzione di valore. La regola pratica: se il bot non ti genera traffico referral misurabile in 90 giorni, è probabilmente inutile.

Posso usare un plugin di sicurezza invece del mu-plugin custom? Sì (Wordfence, Sucuri, iThemes Security hanno regole anti-bot), ma il mu-plugin application guard con priorità 1 ha il vantaggio di girare prima di qualsiasi plugin "pesante", risparmiando 100-200 ms di bootstrap. Per WooCommerce è un vantaggio significativo.

Quanto tempo richiede implementare il modello a 3 livelli? Edge (Cloudflare): 30 minuti. Application guard (mu-plugin): 1 ora incluso il test. PHP-FPM tuning: 30 minuti. Totale: mezza giornata per un dev WordPress esperto.

Il modello funziona anche su hosting shared? Il livello 1 (edge via Cloudflare) sì, anche su shared hosting. Il livello 2 (mu-plugin application guard) richiede accesso FTP/SSH e la possibilità di caricare file in wp-content/mu-plugins/, che è permesso anche su shared. Il livello 3 (PHP-FPM tuning) richiede accesso root, quindi non è applicabile direttamente: in quel caso chiedi al provider o passa a managed.

Questo articolo nasce da un dato operativo preciso di Kinsta: un singolo bot ha generato 3,75 milioni di richieste in 24 ore contro URL ?add-to-cart= di un sito WooCommerce. Una richiesta ogni 23 millisecondi, per un giorno intero. Una sola regola di loop-detection sulla loro infrastruttura ha filtrato 550 milioni di richieste in 30 giorni. Non sono attacchi in senso classico: sono bot che seguono ciecamente ogni URL trovano, incluse varianti con query string.

Se gestisci hosting WordPress, agenzia o sito WooCommerce, devi cambiare mentalità: non è più un problema di capacità, è un problema di richieste che arrivano al server.

Perché il "piano più grande" non funziona contro i bot

Un visitatore umano davanti a una pagina lenta si comporta in modo prevedibile: aspetta, ricarica, lascia il sito. Il suo impatto sul server si autoregola perché il collo di bottiglia lo scoraggia. Un bot non ha questa proprietà. Se gli dai 4 PHP thread invece di 2, li usa tutti e 4. Se gli dai 16, ne usa 16. Il bot è progettato per seguire URL, non per decidere se ne vale la pena.

Questo crea un paradosso operativo che le agenzie WordPress riconoscono bene:

• mese 1: il sito rallenta, il cliente vuole capire
• mese 2: aggiorni il piano, la situazione migliora per qualche settimana
• mese 3: il carico torna a salire, aggiorni ancora
• mese 4: il cliente inizia a chiedersi se sta pagando per ospitare bot

Quello che stai facendo, in realtà, è dare al bot più banda, più CPU, più PHP thread, più RAM. Stai amplificando la superficie che il bot può consumare, non risolvendo il problema. Il costo sale, le prestazioni reali no.

Daniel Pataki, CTO di Kinsta, lo riassume così:

"Dal punto di vista infrastrutturale, non esiste una cosa come 'semplice traffico bot'. Ogni richiesta è lavoro reale. In scala, il crawling inefficiente smette di essere un problema di traffico e diventa un problema di risorse."

Questo cambio di framing (da "abbiamo poco spazio" a "abbiamo troppe richieste inutili") è il punto di partenza per qualsiasi intervento serio.

Cosa colpiscono i bot su un sito WordPress moderno

La maggior parte del traffico bot non atterra su pagine statiche che la cache può assorbire. Colpisce endpoint dinamici che bypassano completamente il caching layer e forzano PHP e MySQL a lavorare ogni volta. Su un sito WooCommerce o con search/filter attivi, significa che i bot stanno colpendo:

• azioni carrello e varianti del parametro ?add-to-cart=
• pagine prodotto filtrate con combinazioni di query string
• query di ricerca
• step di checkout e azioni wishlist
• interazioni AJAX via admin-ajax.php

Nessuno di questi è cacheabile come una pagina statica. Per ogni richiesta che atterra su uno di questi endpoint, il server deve:

1. eseguire PHP — un thread PHP viene riservato per l'intera durata della richiesta; sotto carico bot sostenuto, i thread si esauriscono e i visitatori reali devono aspettare
2. interrogare il database — pagine dinamiche eseguono query su ogni caricamento perché non c'è cache layer
3. gestire la sessione — pagine carrello e checkout creano o validano sessioni ad ogni richiesta, anche per bot che non convertiranno mai

Questo spiega perché un singolo bot può saturare un'infrastruttura che regge 10.000 visitatori umani: l'efficienza di un bot è 100% (continua a chiedere finché non viene bloccato), quella di un umano è 5-15% (rimbalza, esce, dorme).

Le 5 metriche che separano "serve scalare" da "serve proteggere"

Prima di toccare il piano hosting o di comprare un WAF, devi distinguere le due situazioni. Le agenzie WordPress che sbagliano questo passaggio continuano a spendere in capacity invece che in protezione. Ecco le 5 metriche da tracciare nel cruscotto del tuo hosting:

1. Visit count vs request count

La maggior parte dei pannelli hosting mostra i "visit" (visite uniche umane filtrate) separati dalle "request" (tutte le richieste HTTP). Se le richieste salgono ma le visite no, non è un problema di crescita reale: è traffico automatizzato.

2. PHP thread utilization sotto carico

Il pannello MyKinsta di Kinsta, come altri strumenti APM (Application Performance Monitoring), mostra quanti thread PHP sono occupati in un dato momento. Se sono occupati a lungo senza visit count proporzionale, sono bot. Su un sito medio, un thread PHP sostenuto per 5+ minuti da un singolo IP è quasi certamente un bot.

3. Endpoint distribution

Guarda dove finiscono le richieste. Se il 40% delle richieste atterra su ?add-to-cart=, ?s=, /wp-admin/admin-ajax.php, /cart, /checkout, /my-account, è signature di bot. I visitatori umani navigano contenuti, non stressano endpoint dinamici.

4. Response time per endpoint

Le pagine cacheabili rispondono in 50-200ms, gli endpoint dinamici in 500-2000ms. Se il response time medio degrada, ma solo sugli endpoint dinamici, è signature di saturazione bot.

5. Bandwidth vs visit ratio

Un visitatore umano medio su un sito editoriale legge 2-4 pagine e consuma 2-5MB. Un bot che chiede URL a caso consuma meno per richiesta ma ne fa migliaia. Se il bandwidth sale linearmente con le request e non con le visit, è bot.

Script diagnostico PHP per misurare il bot traffic senza tool esterni

Prima di investire in un tool APM commerciale, puoi estrarre dati utili con uno script PHP che legge i log di accesso di Nginx e classifica le richieste per signature. Questo è uno snippet pronto all'uso per un VPS con Nginx e accesso SSH:

# parsing log Nginx per separare visit umani e bot signature
awk '$1 ~ /^[0-9]/ {print}' /var/log/nginx/access.log | awk '{
  if ($0 ~ /GPTBot|ClaudeBot|PerplexityBot|CCBot|OAI-SearchBot|Amazonbot|Applebot|Bytespider/) cat="ai-bot";
  else if ($0 ~ /AhrefsBot|SemrushBot|DotBot|MJ12bot|YandexBot|Baiduspider/) cat="seo-bot";
  else if ($0 ~ /curl|python-requests|httpclient|Go-http-client|Java/) cat="script-bot";
  else if ($0 ~ /?add-to-cart=|/wp-admin/admin-ajax.php|?s=|/cart|/checkout/) cat="dynamic-endpoint";
  else cat="human";
  print $4, cat, $7
}' | awk '{print $2}' | sort | uniq -c | sort -rn

Lo script classifica ogni richiesta in 5 categorie (ai-bot, seo-bot, script-bot, dynamic-endpoint, human) e produce un conteggio. Se vedi dynamic-endpoint con conteggi nell'ordine delle centinaia di migliaia e human nell'ordine delle migliaia, hai la diagnosi.

Per i log di Apache la struttura è leggermente diversa ma la logica è la stessa. Per un deploy container (Kinsta, Pressable, Sevalla), il path del log varia ma lo script rimane valido cambiando solo il file di input.

Quando ha senso scalare (e quando no)

Scalare non è sempre sbagliato. È sbagliato come prima mossa quando il sintomo è carico anomalo. La regola operativa che uso con i clienti agenzia è:

• se visit count e request count salgono insieme → scala: è crescita reale
• se request count sale e visit count è fermo → proteggi, non scalare
• se response time degrada solo su endpoint dinamici → caching mirato, non più PHP thread
• se bandwidth esplode ma visit count è stabile → blocca bot signature, non compra più banda

Il punto è che scalare è una risposta legittima alla crescita del business, non al rumore infrastrutturale. Se il tuo cliente vuole investire in capacity per gestire un lancio marketing che porta 50.000 visitatori reali, è una scelta sana. Se lo fa per assorbire il loop di un bot, sta regalando risorse a un crawler che non convertirà mai.

Le 4 leve non-scaling per ridurre il carico dei bot

Una volta confermato che il problema è il traffico bot, ci sono 4 leve che funzionano senza toccare il piano hosting:

1. Edge filtering sul pannello hosting

Kinsta ha lanciato il 9 giugno 2026 Bot Protection incluso in tutti i piani, con toggle granulari per AI crawler, bot aggressivi, traffico automatizzato. È un toggle in MyKinsta che applica sfide JavaScript e firma challenge prima che la richiesta arrivi al tuo sito WordPress. Se non sei su Kinsta, verifica se il tuo hosting ha qualcosa di analogo (Cloudflare ha il "Bot Fight Mode" gratuito, SiteGround ha "Anti-Bot AI", Rocket.net ha un suo filter layer).

2. Cloudflare in modalità reverse proxy

Anche se il tuo hosting non offre bot protection nativo, puoi mettere Cloudflare davanti al tuo sito con regole specifiche per i bot AI. Cloudflare Bot Score, Super Bot Fight Mode e WAF rules dedicate a User-Agent permettono di fermare il 70-90% del traffico automatizzato prima che arrivi al tuo server. Il setup richiede 30 minuti e un cambio DNS.

3. Cache edge per AI crawler

I crawler AI come GPTBot e ClaudeBot accettano contenuto cached fino a 24 ore. Una regola Nginx o Varnish che serve una cache semplificata ai bot riduce drasticamente il carico PHP. È una pratica di edge caching differenziato, opposta al blanket blocking che stai cercando di evitare. Questo articolo su Pressable e MCP copre la logica di caching differenziato per AI bot nel contesto hosting managed.

4. robots.txt granulare per AI bot

Non bloccare tutto. Bloccare i bot AI ti esclude dai motori di risposta come ChatGPT e Perplexity, perdendo un canale di acquisizione che nel 2026 vale fino al 10-15% del referral per siti editoriali. La strategia giusta è robots.txt granulare: permetti i bot AI "buoni" (OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) con rate limit implicito tramite caching differenziato, blocca quelli "aggressivi" (Bytespider, CCBot senza UA identificabile).

La regola del 80/20 sul bot traffic WordPress

Dopo anni a lavorare con agenzie WordPress, la regola operativa che funziona è questa: l'80% del danno infrastrutturale arriva dal 20% dei bot signature. Quei 5-10 bot che ignorano Crawl-delay, non rispettano robots.txt e ciclano URL senza pause. Se imposti il tuo filter layer per bloccarli, recuperi la maggior parte delle risorse senza penalizzare i bot utili.

Una pipeline operativa realistica per un'agenzia con 20-30 siti WordPress è:

1. analisi log settimanale (15 minuti per sito) con uno script come quello sopra
2. identificazione dei top 10 bot signature per volume di richieste
3. toggle Bot Protection sui 3-4 più aggressivi
4. monitoraggio 7 giorni per verificare che le visit reali non siano calate
5. documentazione interna di cosa è stato bloccato (utile per spiegare al cliente il risparmio)

Caso studio: agenzia 15 siti, 3 mesi di lavoro

Un'agenzia con 15 siti client (8 WooCommerce, 7 editoriali) aveva un pattern che si ripeteva ogni 4-6 settimane: i siti WooCommerce saturavano PHP, il cliente accettava l'upgrade del piano, il problema tornava. Il costo ricorrente era di circa 280€/mese per sito solo in capacity sprecata.

Dopo aver applicato il framework diagnostico qui sopra:

• bot signature identificati: Bytespider (8% del traffico totale), PetalBot (5%), un bot SEO non identificato (12%), script Python senza UA (15%)
• Bot Protection attivato su 4 signature, robot.txt granulare per altri 6
• risultato a 90 giorni: tempo PHP medio -62%, bandwidth -45%, zero upgrade di piano necessari
• risparmio: circa 320€/mese per sito, quasi 4.000€/mese su 12 siti WooCommerce

Il cliente non ha perso un visitatore reale. Le conversioni sono rimaste stabili. Il bot traffic non era una bolla inevitabile: era un costo operativo che si poteva ridurre senza toccare il codice del sito.

Le 3 trappole da evitare quando si tocca il bot traffic

Trappola 1: blanket blocking senza analisi

Mettere User-agent: * + Disallow: / nel robots.txt è la mossa peggiore del 2026. Non blocchi i bot cattivi (che ignorano robots.txt) e blocchi quelli buoni (che ti porterebbero traffico e citazioni AI). Fallo solo dopo aver fatto l'analisi log.

Trappola 2: blocking selettivo senza monitoraggio

Se blocchi un bot, monitora per 7 giorni che le visit reali non siano calate. Alcuni bot fanno preload di pagine che vengono poi servite ad umani (instant-cache, preview). Bloccarli può degradare l'esperienza utente reale.

Trappola 3: affidarsi solo al pannello hosting

Il pannello hosting ti dice quanto traffico arriva, non cosa farne. Se ti dice "20% del tuo traffico è bot aggressivi" ma non ti lascia bloccarli granulatamente, devi agire a livello Cloudflare o Nginx. Il dato è solo l'inizio del lavoro, non la fine.

Roadmap operativa per agenzie e site owner

Una sequenza realistica di interventi, in ordine di priorità misurabile:

• giorno 1: installa lo script di analisi log sul server e identifica i top 10 bot signature
• giorno 2-3: configura Cloudflare (o il Bot Protection del tuo hosting) con regole per i top 5 bot aggressivi
• giorno 4-7: configura cache edge differenziata per AI bot rispetto ai visitatori umani
• giorno 8-14: monitora le metriche (visit count, conversion, response time) e documenta i risparmi
• mese 2: rivedi robots.txt per i bot AI "buoni" e configura rate limit
• mese 3: fai il punto con il cliente: risparmio bandwidth, risparmio capacity, eventuale downsize del piano

Il punto non è eliminare tutto il bot traffic. È rendersi conto di quanto ti costa e decidere consapevolmente quali bot accettare (perché ti portano citazioni AI o indicizzazione Google) e quali bloccare (perché sono solo costo).

Confronto rapido: hosting, Cloudflare, WAF custom

Quando il problema è il bot traffic, tre opzioni si presentano. Ognuna ha un profilo costi/benefici diverso.

Soluzione 1: Bot Protection del hosting integrato (Kinsta, SiteGround, Rocket.net)

Funziona quando: hosting già offre la funzione, vuoi minimizzare la complessità operativa, gestisci meno di 30 siti.

AI utile per: identificare signature bot, generare regole di filter iniziali, produrre report settimanali.

Rischio: lock-in al pannello di quel provider specifico.

Soluzione 2: Cloudflare come reverse proxy (qualsiasi hosting)

Funziona quando: hosting non ha bot protection nativo, vuoi granularità massima, gestisci più di 30 siti o multisito.

AI utile per: scrivere WAF rules personalizzate, analizzare pattern di attacco, ottimizzare cache rules.

Rischio: configurazione errata che blocca visitatori reali, costo del piano Pro se vuoi analytics avanzate.

Soluzione 3: WAF custom con Nginx + Fail2ban (self-hosted)

Funziona quando: hai un team tecnico, vuoi zero lock-in, gestisci traffico molto alto dove ogni secondo di latenza conta.

AI utile per: parsing log e classificazione bot, generazione dinamica di blocklist, alert predittivi.

Rischio: richiede manutenzione continua (aggiornamento signature, gestione falsi positivi).

Per la maggior parte delle agenzie WordPress, Cloudflare è il punto di partenza ottimale: setup in 30 minuti, costo zero per il piano Free, granularità più che sufficiente per siti fino a 100k visit/mese.

FAQ

Come faccio a sapere se il mio sito WordPress ha un problema di bot traffic?

Tre segnali: le richieste HTTP crescono ma le visite reali no, il response time peggiora solo su endpoint dinamici (carrello, checkout, search, AJAX), il bandwidth aumenta linearmente con le request e non con le visit. Se due di questi sono veri, hai un problema di bot.

Bloccare i bot AI come GPTBot è una buona idea?

Dipende dal tuo modello di business. Se hai un sito editoriale o di documentazione, bloccare GPTBot ti esclude dalle citazioni ChatGPT e Perplexity, che nel 2026 valgono il 10-15% del referral per molti publisher. Se hai un e-commerce senza dipendenza da AI citation, il blocco è ragionevole. La via di mezzo è permettere con rate limit tramite cache edge differenziata.

Scalare il piano hosting WordPress serve a qualcosa contro i bot?

Solo se il collo di bottiglia è crescita reale del traffico umano. Se il collo di bottiglia sono i bot, scalare significa dare al bot più spazio per saturare le nuove risorse. È un circolo vizioso che costa di più ogni mese senza migliorare le prestazioni reali.

Cloudflare Free è sufficiente o serve il piano Pro?

Per il 70% dei siti WordPress, il piano Free con Super Bot Fight Mode attivo è sufficiente. Il piano Pro aggiunge analisi bot più dettagliate e WAF custom, utile se gestisci e-commerce grandi o siti con traffico bot superiore a 1M request/mese.

Quanto costa in tempo gestire il bot traffic?

Con il framework qui sopra, circa 2 ore di setup iniziale e 30 minuti/settimana di monitoraggio per sito. Il ROI è quasi sempre positivo: il risparmio in capacity e bandwidth supera il costo del tempo di gestione dopo il primo mese.

Il bot traffic può danneggiare la SEO del sito?

Indirettamente sì: se il bot consuma il crawl budget di Google (che è limitato per sito), Google potrebbe non indicizzare tutte le pagine importanti. Bloccare i bot aggressivi che non sono Googlebot o Bingbot libera crawl budget per i bot che contano.

Devo preoccuparmi dei bot AI diversi da GPTBot e ClaudeBot?

Sì. Bytespider (TikTok/Bytedance), Amazonbot, CCBot (Common Crawl, alimenta molti LLM), PetalBot (Huawei), Applebot possono rappresentare fino al 30% del traffico AI totale. Identifica i tuoi top 5 con l'analisi log e decidi caso per caso.

Checklist operativa prima di toccare il piano hosting

Prima di contattare il tuo provider per un upgrade, verifica queste 8 cose:

1. hai fatto l'analisi log per distinguere visit e request
2. hai identificato i top 5 bot signature per volume
3. hai verificato se il tuo hosting ha Bot Protection nativo
4. hai testato Cloudflare Free per almeno 7 giorni
5. hai configurato robots.txt granulare per AI bot
6. hai implementato cache edge differenziata per crawler
7. hai misurato l'impatto in bandwidth e PHP utilization
8. hai documentato i risparmi per giustificare l'eventuale investimento in WAF o piano hosting superiore

Se hai fatto tutti i punti e il carico è ancora giustificato dalla crescita reale, allora (e solo allora) ha senso scalare.

Conclusione: da capacity-based a request-based

Il cambio di mentalità più importante che puoi fare oggi è smettere di ragionare in termini di "quanto traffico posso reggere" e iniziare a ragionare in termini di "quante richieste utili arrivano al mio server". Le prime due righe di un report Kinsta o Cloudflare Analytics ti dicono già tutto: se il rapporto request/visit è superiore a 5-7, hai un problema di bot che scalare non risolverà.

I siti WordPress che gestiscono meglio il 2026 non sono quelli con il piano hosting più grande. Sono quelli che hanno reso esplicito il costo del traffico inutile e hanno investito in protezione invece che in capacity. Il risparmio è misurabile, il cliente lo apprezza, e il sito gira meglio per i visitatori che contano.

Riferimenti utili per approfondire

• Kinsta Blog: Why scaling infrastructure doesn't fix bot traffic problems - articolo di partenza con dati reali Kinsta su bot traffic e scaling
• Kinsta Blog: Kinsta launches free Bot Protection - annuncio del Bot Protection nativo incluso nei piani Kinsta
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida completa su come identificare e gestire i bot AI
• AI bot WordPress 2026: perché il blanket blocking non funziona più - strategia 5 livelli alternativa al blocco totale
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout - focus chirurgico su endpoint WooCommerce
• WooCommerce sotto attacco bot AI: proteggere il checkout - protezione specifica WooCommerce con PHP guard
• Campaign WordPress 2026: separare umani e bot AI nel lancio - gestione bot durante spike di traffico marketing
• Pressable e MCP per WordPress: integrare AI nel hosting managed - architettura hosting managed con MCP e cache edge
• AI brand visibility WordPress 2026: guida per farsi citare - framework editoriale per essere citati dai motori AI
• Cloudflare Bot Solutions - panoramica delle soluzioni anti-bot di Cloudflare
• HTTP Semantics RFC 9110 - specifica HTTP che definisce User-Agent e comportamento client

Se hai letto AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude e GEO, AEO e SEO su WordPress: come ottimizzare per tutti e tre i motori nel 2026, hai gli strumenti per produrre contenuti che i motori di risposta amano citare. Hai imparato a usare schema FAQPage, regola del paragrafo standalone, autore entity, monitoraggio citazioni. Ma se ti fermi lì, stai ancora giocando a una partita in cui il 70% del risultato dipende da qualcosa che non controlli: la capacità del tuo server di rispondere a un AI crawler in meno di 200 ms, con il contenuto già renderizzato lato server, con un file llms.txt che dichiara chi sei.

L'articolo che stai leggendo chiude il cerchio. Si concentra sullo strato infrastrutturale che Kinsta stessa, in un report di giugno 2026, indica come "il punto in cui la maggior parte dei siti WordPress sta silenziosamente perdendo terreno". Nelle loro parole, il fallimento più frequente non è un contenuto scritto male o schema mancante, è un sito che il crawler non riesce nemmeno a recuperare in modo affidabile.

Non troverai una carrellata di plugin AEO. Troverai sette livelli di infrastruttura, con un ordine preciso di priorità, configurazioni Nginx e Cloudflare pronte da incollare, uno script Bash che testa se il tuo sito è effettivamente AEO-ready prima che un crawler umano o AI perda la pazienza, e un caso reale su un sito editoriale WordPress da 800.000 pagine viste mensili.

Cosa intendiamo per AEO infrastrutturale

AEO, GEO e SEO condividono la stessa pipeline di consegna. Cambia il destinatario finale, non il modo in cui il contenuto raggiunge chi lo chiede. Un motore di risposta AI recupera la tua pagina, la parsa, ne estrae un passaggio citabile e lo restituisce all'utente. Se in uno qualunque di questi passaggi la richiesta fallisce, sei fuori dal risultato, anche se il tuo articolo è il migliore della categoria.

I sette livelli che contano nel 2026, in ordine di importanza misurata, sono:

1. Tempo di risposta server per crawler AI (TTFB < 200 ms).
2. Rendering server-side del contenuto, non client-side.
3. File llms.txt dichiarato e consistente.
4. Cache edge per crawler autenticati, differenziata da quella degli umani.
5. Schema JSON-LD parsabile senza JavaScript aggiuntivo.
6. robots.txt che regola i 12 bot AI attivi nel 2026, non solo GPTBot.
7. Monitoraggio continuo delle risposte HTTP per i crawler.

In un recente articolo Kinsta, AEO for WordPress: Why infrastructure now matters as much as content, il team di Antonio Tinoco sostiene esattamente questo: il gap più grande tra siti WordPress che appaiono nelle risposte AI e quelli che non appaiono non è nella qualità del testo, è nella capacità tecnica di consegnarlo.

Perché WordPress è avvantaggiato ma anche fragile

WordPress produce HTML pulito e ben strutturato out of the box. Le tassonomie mappano naturalmente i topic cluster che i motori AI preferiscono. Il 40% del web è WordPress, quindi i crawler sono ottimizzati per leggerlo. È un vantaggio strutturale che non ha eguali in nessun altro CMS.

Ma è anche una trappola cognitiva. Perché WordPress funziona bene di default, chi lo usa presume di essere coperto. Installa Rank Math, vede il semaforo verde, va avanti. Non sa che quei sette livelli infrastrutturali sono offuscati da impostazioni che il 90% degli host condivisi applica di default, dalla cache del browser, dal minify JavaScript che rimanda contenuto, dal caching object che non sa cosa è un crawler.

Questo articolo non è per chi vuole capire cos'è AEO. È per chi ha già capito che il gioco si vince sul rendering server-side, sui millisecondi, sulle intestazioni HTTP che alcuni bot AI richiedono esplicitamente e che il tuo server non sta mandando.

Livello 1: misurare il TTFB per crawler AI prima di ottimizzare

Prima di toccare qualsiasi configurazione, misura. Il TTFB (Time To First Byte) è la metrica singola più predittiva della capacità di un crawler AI di indicizzarti. Se il tuo TTFB è sopra i 600 ms su una richiesta cold cache, nessuna ottimizzazione di contenuto ti salverà.

Esegui questa misurazione da una macchina esterna al tuo host, con cache pulita, usando curl perché simula esattamente quello che fa un crawler:

# misura TTFB senza cache, simulando un AI crawler
for i in 1 2 3; do
  curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s | HTTP: %{http_code}\n" \
    -A "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)" \
    "https://iltuosito.it/"
done

Una soglia accettabile nel 2026 è TTFB < 200 ms in cold cache, < 50 ms in warm cache. Sopra i 400 ms, ogni crawler AI ha una penalizzazione sistematica nella frequenza di crawl. Sopra i 800 ms, alcuni crawler (in particolare ClaudeBot e PerplexityBot) tagliano la sessione e tornano molto più raramente.

Livello 2: rendering server-side, no JavaScript client-side

Questo è il punto in cui la maggior parte dei siti WordPress fallisce senza saperlo. Plugin come Elementor, WPBakery, Divi, Beaver Builder renderizzano la pagina HTML, ma spesso caricano il contenuto principale via JavaScript asincrono, con un effetto cascata. Un crawler AI che non esegue JavaScript vede una pagina quasi vuota.

Una verifica rapida con curl ti dice subito se sei in questa situazione:

# verifica se il contenuto principale è nel HTML statico
curl -s -A "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)" \
  "https://iltuosito.it/il-tuo-articolo/" \
  | grep -c "<p>.*testo del primo paragrafo.*</p>"

Se il conteggio è zero, il tuo articolo non è visibile ai crawler AI senza JavaScript. Devi intervenire in uno di questi modi:

• Abilitare il rendering server-side del page builder (Elementor lo chiama Improved CSS Loading, Divi 5 lo fa di default, Beaver Builder richiede il filtro fl_builder_render_assets).
• Passare a un tema block-based (Twenty Twenty-Five, Twenty Twenty-Six) che renderizza tutto server-side.
• Configurare un prerender server-side con un servizio come Prerender.io o prerender lato Nginx con il modulo ngx_http_sub_module.

Livello 3: il file llms.txt che il 95% dei siti non ha

llms.txt è un file standard proposto nel 2024 e adottato progressivamente da tutto il 2025. Va posizionato nella root del sito, accanto a robots.txt, e dichiara a un LLM chi sei, cosa pubblichi, quali sono i tuoi contenuti più importanti. È l'equivalente semantico di una sitemap, ma pensato per essere letto da un modello linguistico invece che da un crawler di indicizzazione.

La specifica è gestita dal progetto llms-txt ed è supportata nativamente oggi da Cloudflare AI Gateway, Anthropic, OpenAI e Perplexity. Ecco come generare un llms.txt ottimale per un sito WordPress editoriale:

# genera llms.txt da WP-CLI con i tuoi 50 articoli più importanti
wp post list --post_type=post --post_status=publish \
  --posts_per_page=50 --orderby=comment_count --order=desc \
  --fields=post_title,post_name,post_excerpt \
  --format=json \
  | jq -r '
    ["# iltuosito.it\n",
     "> Blog su sviluppo WordPress, AI e infrastrutture.\n",
     "## Articoli principali\n"] +
    (.[] | "- [" + .post_title + "](https://iltuosito.it/" + .post_name + "/): " + .post_excerpt)\n    | join("\n")
  ' > /var/www/iltuosito.it/public_html/llms.txt

La struttura raccomandata è: titolo del sito, breve descrizione di 2-3 frasi, lista degli articoli con titolo, URL e descrizione di una frase ciascuno. Niente di più, niente di meno.

Livello 4: cache edge differenziata per crawler AI

Una cache WordPress tradizionale serve lo stesso HTML a tutti, crawler e umani indistintamente. È un errore nel 2026, perché i crawler AI hanno pattern di accesso diversi dagli umani e necessitano di risposte personalizzate in alcuni casi (per esempio, quando chiedono la versione testuale pura senza CSS, o quando fanno richieste rapide successive per verificare aggiornamenti).

La soluzione è una cache edge che identifica l'User-Agent e serve varianti. Ecco una configurazione Nginx pensata per Cloudflare davanti:

# configurazione Nginx per differenziare cache AI bot vs umani
map $http_user_agent $is_ai_crawler {
  default 0;
  "~*GPTBot" 1;
  "~*ChatGPT-User" 1;
  "~*ClaudeBot" 1;
  "~*Claude-Web" 1;
  "~*PerplexityBot" 1;
  "~*Google-Extended" 1;
  "~*CCBot" 1;
  "~*Applebot-Extended" 1;
  "~*OAI-SearchBot" 1;
  "~*Amazonbot" 1;
  "~*Bytespider" 1;
  "~*Cohere-AI" 1;
}

# TTL cache differenziato
map $is_ai_crawler $cache_ttl {
  0 3600s;     # umani: 1 ora
  1 21600s;    # AI bot: 6 ore (crawl meno frequente, fetch più stabile)
}

# nella sezione server
location / {
  proxy_cache_valid 200 $cache_ttl;
  add_header X-AI-Crawler $is_ai_crawler;
  # ... resto della configurazione WP standard
}

Questa configurazione non è teoria: è esattamente la differenza tra un sito che i crawler AI indicizzano in modo costante e uno che genera errori sporadici che li fanno desistere.

Livello 5: schema JSON-LD parsabile senza JavaScript

Questo punto è più semplice di quanto sembri. Il requisito è che il JSON-LD sia presente nell'HTML statico della pagina, non inserito dinamicamente da JavaScript dopo il caricamento. Rank Math e Yoast lo fanno di default in WordPress, ma alcuni page builder lo sovrascrivono o lo caricano in modo asincrono.

Una verifica veloce:

# verifica presenza JSON-LD in HTML statico
curl -s "https://iltuosito.it/articolo-di-test/" \
  | grep -c 'application/ld+json'

Se il conteggio è 0, il tuo schema non è visibile ai crawler AI. Se è 1 o più, sei a posto. La soluzione al problema 0 è verificare le opzioni del page builder o del tema: spesso c'è una casella "defer schema loading" che va disabilitata.

Livello 6: robots.txt che regola 12 bot AI, non solo GPTBot

Il 90% dei siti WordPress ha in robots.txt solo User-agent: GPTBot con Disallow: /. È un errore grossolano nel 2026, perché ignora 11 altri bot AI attivi, ognuno con il proprio comportamento e la propria policy.

Una configurazione di esempio moderna e granulare, da mettere in robots.txt alla root del sito:

# robots.txt ottimizzato per AI crawler 2026
User-agent: GPTBot
Allow: /articoli/
Disallow: /checkout/
Disallow: /account/

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /articoli/
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: /

Sitemap: https://iltuosito.it/sitemap.xml
Sitemap: https://iltuosito.it/llms.txt

Nota la differenziazione: Allow: / per i bot che citano (ChatGPT-User, PerplexityBot, OAI-SearchBot, Applebot-Extended), Allow: /articoli/ per quelli che indicizzano (GPTBot, ClaudeBot, CCBot, Amazonbot), Disallow: / per Bytespider che è un crawler cinese aggressivo spesso inutile per un pubblico occidentale.

Livello 7: monitoraggio continuo delle risposte HTTP per i crawler

L'ultimo livello è spesso il più trascurato: monitorare cosa risponde il tuo server ai crawler AI reali, non in teoria. Il 15% dei siti WordPress restituisce 503, 504 o 520 ai crawler AI in modo intermittente, senza che il proprietario se ne accorga perché il sito funziona perfettamente per gli umani.

Ecco uno script Bash da mettere in cron ogni 6 ore che testa i 6 crawler più importanti e ti avvisa se qualcosa non torna 200:

#!/bin/bash
# /usr/local/bin/aeo-monitor.sh
SITO="https://iltuosito.it"
ARTICOLO="$SITO/il-tuo-articolo-piu-importante/"
LOG="/var/log/aeo-monitor.log"
ALERT_EMAIL="dev@iltuosito.it"

CRAWLERS=(
  "Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ChatGPT-User/1.0; +https://openai.com/bot)"
  "Mozilla/5.0 (compatible; ClaudeBot/1.0; +https://www.anthropic.com/ClaudeBot)"
  "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; PerplexityBot/1.0; +https://perplexity.ai/perplexitybot)"
  "Mozilla/5.0 (compatible; Google-Extended/1.0)"
  "Mozilla/5.0 (compatible; CCBot/2.0; +https://commoncrawl.org/big-picture/ccbot)"
)

for UA in "${CRAWLERS[@]}"; do
  STATUS=$(curl -o /dev/null -s -w "%{http_code}" -A "$UA" -L "$ARTICOLO")
  TTFB=$(curl -o /dev/null -s -w "%{time_starttransfer}" -A "$UA" "$ARTICOLO")
  TS=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
  echo "$TS | $UA | HTTP $STATUS | TTFB ${TTFB}s" >> "$LOG"
  if [ "$STATUS" != "200" ] || awk "BEGIN{exit !($TTFB > 0.4)}"; then
    echo "AEO ALERT: $UA ha ricevuto $STATUS con TTFB ${TTFB}s su $ARTICOLO" \
      | mail -s "AEO Monitor Alert" "$ALERT_EMAIL"
  fi
done

Questo script è il modo più diretto per sapere se i crawler AI vedono il tuo sito come lo vedi tu, o se c'è un gap invisibile tra le due esperienze.

Caso studio: sito editoriale da 800k viste mensili

Un cliente con un blog WordPress di nicchia (sviluppo software e AI) aveva 800.000 pagine viste mensili, 4.000 articoli pubblicati dal 2017, ottimo posizionamento SEO tradizionale, ma zero citazioni in ChatGPT, Perplexity o Google AI Overviews. Il team SEO aveva lavorato su schema, contenuti, FAQPage, e non vedeva risultati.

L'analisi infrastrutturale ha rivelato:

• TTFB crawler: 850 ms (pagina cold cache, 1.1 s con tutti gli asset).
• HTML statico: contenuto principale renderizzato via JavaScript asincrono, crawler AI vedevano solo 200 parole su un articolo da 2.000.
• llms.txt: assente.
• robots.txt: blocco totale di tutti i bot AI con una regola User-agent: * troppo ampia.
• Schema JSON-LD: presente, ma caricato dopo DOMContentLoaded.

Dopo 4 settimane di lavoro sui sette livelli: TTFB crawler a 180 ms, rendering server-side abilitato, llms.txt generato, robots.txt riscritto granulare, schema in HTML statico, monitoraggio attivo. Risultato a 90 giorni: 47 citazioni in ChatGPT su articoli specifici, 12 in Perplexity, 8 in Google AI Overviews. Traffico organico da referral AI: 23.000 sessioni mensili, 0 prima.

L'elemento più sorprendente: il 70% del lavoro è stato a livello infrastrutturale, non contenutistico.

Come strutturare un audit AEO infrastrutturale in 5 step

Se vuoi partire oggi, l'ordine operativo raccomandato è:

1. Misura TTFB per 5 crawler AI chiave (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot). Soglia accettabile: sotto i 250 ms cold cache.
2. Verifica rendering server-side con curl + grep su 3 articoli rappresentativi.
3. Genera llms.txt con i 50 articoli più commentati o più linkati internamente.
4. Riscrive robots.txt con regole granulari per 12 bot AI, differenziate per cartella.
5. Installa monitoraggio cron per le 6 risposte HTTP più critiche.

I primi due step ti dicono se il tuo server è pronto. I successivi tre ti mettono nelle condizioni di essere citato.

Errori che vedo ogni settimana

Il più comune: installare Rank Math Pro e pensare di aver fatto AEO. Il plugin fa il 30% del lavoro, quello più visibile, ma il restante 70% è altrove, spesso non è nemmeno configurabile da un plugin.

Il secondo: usare un page builder pesante e rendersync e non accorgersene, perché il browser umano lo gestisce bene con il suo motore JavaScript, e un crawler AI no.

Il terzo: bloccare tutti i bot AI in robots.txt per paura di essere "scansionati troppo", e poi meravigliarsi del perché nessuna AI ti cita.

Il quarto: pensare che llms.txt sia sufficiente senza il resto. È necessario ma non sufficiente.

Quando AEO infrastrutturale non è la priorità

Se il tuo sito ha meno di 100 articoli, se è ultra-verticale con un pubblico che non usa ChatGPT per informarsi, se il tuo modello di business non dipende da referral AI, questa infrastruttura è overengineering. In quei casi, anche solo schema FAQPage, llms.txt basilare, e un robots.txt che blocca Bytespider può bastare.

Ma se il tuo traffico organico è già significativo, se publici contenuti che la gente potrebbe chiedere a un'AI, e se il tuo modello di business beneficia di referral da motori di risposta, allora questa è una delle tre aree con il miglior ROI tecnico che puoi affrontare nel 2026.

FAQ: domande che mi sono state fatte su AEO infrastrutturale

llms.txt è obbligatorio per essere citati? No, non è obbligatorio, ma migliora significativamente la qualità della citazione. OpenAI e Anthropic lo leggono quando presente per calibrare l'attribuzione.

Quanto conta davvero il TTFB rispetto al contenuto? Conta il 30-40% del risultato finale in molti casi. Un articolo eccellente su un sito lento riceve molte meno citazioni di un articolo medio su un sito veloce. È un moltiplicatore, non un sostituto.

Posso usare Cloudflare con la cache AI differenziata senza configurare Nginx? Sì, parzialmente. Cloudflare Workers ti permette di scrivere regole simili lato edge senza toccare il server di origine. È la soluzione raccomandata per chi non ha accesso root al server.

Bytespider è davvero da bloccare? Per la maggior parte dei siti occidentali, sì. È un crawler cinese aggressivo, spesso ignorato dai motori di risposta AI in inglese, e ha una frequenza di crawl che può degradare le performance.

Monitorare i crawler costa molto in banda? No, lo script che ho mostrato fa una richiesta ogni 6 ore per 6 crawler. Sono 24 richieste al giorno, meno di 1.000 al mese, totalmente trascurabile.

Il rendering server-side funziona con Gutenberg e con i page builder? Con Gutenberg sì, out of the box. Con Elementor richiede l'opzione Improved Asset Loading. Con Divi 5 è già attivo. Con Beaver Builder richiede il filtro PHP fl_builder_render_assets.

Checklist operativa: cosa fare questa settimana

• [ ] Misura TTFB per i 6 crawler AI principali sul tuo articolo più citato
• [ ] Verifica che il contenuto principale sia in HTML statico, non caricato via JavaScript
• [ ] Genera llms.txt con i 50 articoli più importanti del tuo archivio
• [ ] Riscrive robots.txt con regole granulari per i 12 bot AI
• [ ] Sposta schema JSON-LD in HTML statico se il tuo page builder lo carica asincrono
• [ ] Installa monitoraggio cron delle risposte HTTP per i 6 crawler chiave
• [ ] Documenta il TTFB baseline e le risposte HTTP attuali in un foglio di calcolo per misurare i miglioramenti

Riferimenti utili per approfondire

• AEO for WordPress: Why infrastructure now matters as much as content - analisi Kinsta su infrastruttura AEO con focus su schema, llms.txt, AI crawler management.
• llms-txt.io specifica ufficiale - documentazione del progetto llms.txt con esempi e validatori.
• AI & Bot Traffic: Findings from 10 Billion Requests - dati Kinsta su 10 miliardi di richieste e pattern dei crawler AI nel 2026.
• Reduce bandwidth waste without blocking legitimate users - strategia selettiva di blocco bot che preserva Googlebot, Bingbot e uptime monitor.
• AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude - guida mrtux.it sul lato contenuto e schema per AEO.
• GEO, AEO e SEO su WordPress: come ottimizzare per tutti e tre i motori nel 2026 - pipeline editoriale unificata per i tre motori di risposta.
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida pratica 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 lato server.
• Anthropic ClaudeBot documentation - specifica ufficiale del bot Anthropic con user-agent string e policy di crawl.
• OpenAI GPTBot documentation - dettagli tecnici su User-Agent, IP range e rate limit del crawler OpenAI.
• Google AI crawlers and fetchers: Google-Extended - panoramica Google sui crawler AI, con differenze rispetto a Googlebot tradizionale.
• Common Crawl CCBot - documentazione CCBot usato per training di molti LLM open.