WordPress PHP thread 2026: come i bot AI li stanno esaurendo

Se hai un sito WordPress o WooCommerce che ha cominciato a restituire 504 error improvvisi nel 2026 senza un picco di traffico reale, la causa non è il tuo hosting, non è un attacco DDoS, non è Google: è quasi certamente un singolo bot AI che sta riempiendo il tuo pool di PHP thread con richieste dinamiche ad alta durata. Non è una storia di SEO, non è una storia di sicurezza informatica: è una storia di capacity planning che nessuno aveva previsto prima dell'esplosione dei crawler AI.

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