Bot WordPress: il vero costo dei thread PHP riservati nel 2026

Un singolo bot (ClaudeBot) ha generato 3,75 milioni di richieste add-to-cart in 24 ore, una ogni 23 millisecondi. Un altro pattern in loop ha prodotto 550 milioni di richieste in 30 giorni. Non stiamo parlando di un attacco DDoS né di un plugin malevolo: sono crawler AI e bot "vibe coded" che si comportano come se il tuo server fosse infinito. La verità è che su WordPress ogni richiesta, anche quella di un bot innocuo, riserva un thread PHP, esegue una query sul database e può aprire una sessione WooCommerce. Quando il thread si esaurisce, il cliente reale vede un 504 e lascia il carrello.

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.