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

Se il tuo WordPress con WooCommerce brucia CPU e banda senza convertirli in fatturato, il colpevole probabilmente non è il traffico umano. È un'orda di bot AI che martella /cart/, /checkout/, /?s=... e /my-account/ senza generare un solo ordine.

Una ricerca Kinsta del giugno 2026 ha misurato che le pagine con endpoint dinamici (cart, checkout, ricerca, account) costano da 10 a 50 volte di più in termini di CPU rispetto a pagine statiche cache-abili. Motivo: ogni richiesta esegue PHP, interroga il database, genera sessioni WooCommerce, scrive transient.

Quando un bot come GPTBot, ClaudeBot o un crawler SEO scansione 5.000 URL di un catalogo, non colpisce solo esempio di URL prodotto (pagine statiche e cache-friendly). Colpisce:

• esempio di URL search (search con query parameter)
• esempio di URL cart (cart sempre dinamico)
• esempio di URL checkout (checkout sempre dinamico)
• esempio di URL add-to-cart (AJAX endpoint)
• esempio di URL account (account privato)

Ognuna di queste URL, se non protetta strategicamente, diventa una vora-di-risorse che erode il budget hosting e peggiora l'esperienza utente reale.

Su mrtux.it abbiamo già trattato i bot AI generici e la protezione specifica WooCommerce. Oggi scendiamo nel dettaglio: come costruire un'architettura di protezione chirurgica sugli endpoint dinamici senza rompere la UX reale del checkout.

Anatomia di un endpoint dinamico WordPress

Capire perché certi URL sono costosi è il primo passo per proteggerli in modo intelligente. Tre sono i fattori di costo.

Costo PHP: esecuzione del core WordPress + plugin

Una richiesta a /cart/ esegue:

1. Bootstrap WordPress (file wp-load.php, connessione DB, caricamento plugin)
2. Inizializzazione WooCommerce (cart object, session handler)
3. Query al database per recuperare il carrello (transient wc_cart_hash_*)
4. Render del template con i prodotti aggiunti
5. Invio headers di cache (o non-invio, se configurato male)

Su un'installazione WooCommerce tipica con 30 plugin attivi, questo costa tra 80 e 250 millisecondi per richiesta. Un bot che esegue 1.000 richieste al minuto consuma 1.3-4 secondi di CPU al minuto, anche per visitatori che non compreranno mai.

Costo database: query non indicizzate

WooCommerce salva il carrello in transients (opzioni autoload yes per default fino a WordPress 6.4). Ogni richiesta a /cart/ esegue:

# esempio codice
SELECT option_value FROM wp_options WHERE option_name = '_transient_wc_cart_hash_abc123' LIMIT 1

Con decine di migliaia di carrelli abbandonati, la tabella wp_options cresce fino a 1-2 GB e ogni query diventa un LIKE '%wc_cart%' non indicizzato. Su articoli precedenti abbiamo trattato l'ottimizzazione Docker PHP per ambienti di sviluppo, ma qui il problema è anche in produzione.

Costo banda: pagine non compresse, asset non minificati

Le pagine cart/checkout non sono quasi mai abilitate alla compressione GZIP perché contengono nonce anti-CSRF e token dinamici. Una pagina checkout può pesare 200-400 KB. Un bot che ne chiede 10.000 al giorno consuma 2-4 GB di banda senza valore.

I 5 pattern di attacco bot su endpoint dinamici

I bot che colpiscono cart, checkout e search hanno pattern diversi dai crawler generici. Riconoscerli è essenziale per bloccarli senza falsi positivi.

Pattern 1 — Scraping di prezzi e stock

Bot che confrontano prezzi tra competitor colpiscono /?s=prodotto e /prodotto-x/ per estrarre prezzo corrente, disponibilità, variazioni. Rilevabili da: alta frequenza, assenza di referer, user agent headless browser (Chrome Headless, PhantomJS).

Pattern 2 — Credential stuffing su /my-account/

Bot che provano coppie username/password rubate contro il form di login. Rilevabili da: alta frequenza di POST a /wp-login.php, assenza di cookie, distribuzione anomala di IP.

Pattern 3 — Inventory hoarding su /cart/

Bot che aggiungono prodotti al carrello per poi abbandonarli, creando stock fantasma e confusione nel gestionale. Rilevabili da: sequenza POST /?add-to-cart=... ripetuta senza successivo /checkout/.

Pattern 4 — Card testing su /checkout/

Bot che testano carte di credito rubate con transazioni di pochi centesimi. Rilevabili da: alta frequenza di POST a /checkout/ con errori 402/403, IP distribuiti, assenza di completamento ordine.

Pattern 5 — Search spam per indicizzare URL parametrizzate

Bot SEO che generano migliaia di URL /?s=keyword per scoperte di long-tail. Rilevabili da: richieste a /?s=* con keyword senza senso, alta frequenza.

Strategia di protezione a 4 livelli

La protezione degli endpoint dinamici non è blocco totale: è differenziazione intelligente tra traffico umano e traffico bot. Quattro livelli, dal meno invasivo al più aggressivo.

Livello 1 — Edge caching differenziato per URL pattern

Cloudflare, Fastly e Varnish permettono regole di cache specifiche per URL pattern. La regola chiave: non bloccare, ma non eseguire PHP.

# Cloudflare Page Rules (Dashboard → Caching → Configuration)
# Pattern 1: Cache search ma solo per bot AI noti
URL pattern: *tuosito.it/?s=*
Cache eligibility: Eligible for cache
Edge cache TTL: 1 hour
Browser cache TTL: 5 minutes
Bypass cache on cookie: wordpress_logged_in|woocommerce_cart_hash|woocommerce_items_in_cart

# Varnish VCL alternativa (se usi Varnish davanti a nginx)
sub vcl_recv {
    # Non cachare mai cart e checkout
    if (req.url ~ "^/(cart|checkout|my-account)") {
        return (pass);
    }
    # Cache search per 5 minuti se non loggato
    if (req.url ~ "\?s=" && !req.http.Cookie ~ "wordpress_logged_in") {
        unset req.http.Cookie;
        return (hash);
    }
}

Livello 2 — WAF rules specifiche per pattern sospetti

Cloudflare WAF o AWS WAF permettono regole mirate. Ecco 5 regole pronte all'uso per WooCommerce:

# Cloudflare WAF Custom Rules (Dashboard → Security → WAF → Custom Rules)

# Regola 1: Blocca POST a wp-login.php senza referer interno
(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST" and not cf.client.referer contains "tuosito.it")
Action: Challenge (Managed)

# Regola 2: Blocca richieste a /cart/ con user agent bot noto
(http.request.uri.path eq "/cart/" and cf.client.bot) or
(http.request.uri.path eq "/cart/" and http.user_agent contains "GPTBot" or http.user_agent contains "ClaudeBot" or http.user_agent contains "PerplexityBot")
Action: Block

# Regola 3: Rate limit su /?add-to-cart= (max 10/min per IP)
(http.request.uri.query contains "add-to-cart")
Rate limit: 10 requests / 60 seconds / IP
Action: Challenge

# Regola 4: Rate limit su /checkout/ (max 5/min per IP)
(http.request.uri.path eq "/checkout/" and http.request.method eq "POST")
Rate limit: 5 requests / 60 seconds / IP
Action: Block (soft = JS challenge)

# Regola 5: Blocca user agent senza browser identity
(http.user_agent eq "" or http.user_agent contains "Python" or http.user_agent contains "curl" or http.user_agent contains "wget")
And not ip.src in {<IP ammessi per monitoring interni>}
Action: JS Challenge

Livello 3 — PHP guard con priorità alta su init

Per i bot che sfuggono al WAF (user agent spoofato, IP distribuiti), serve un guard a livello applicativo. Ecco un'implementazione robusta in functions.php del tema o in un plugin custom:

<?php
/**
 * Bot Guard per endpoint dinamici WooCommerce
 * Plugin: mrtux-bot-guard
 */

add_action( 'init', 'mrtux_bot_guard_init', 1 );

function mrtux_bot_guard_init() {
    // Non applicare a utenti loggati admin
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }

    $request_uri = $_SERVER['REQUEST_URI'] ?? '';
    $user_agent  = strtolower( $_SERVER['HTTP_USER_AGENT'] ?? '' );
    $ip          = $_SERVER['REMOTE_ADDR'] ?? '';

    // Lista bot AI noti da rifiutare su endpoint dinamici
    $ai_bots = array(
        'gptbot', 'chatgpt-user', 'oai-searchbot', 'claudebot',
        'perplexitybot', 'perplexity-user', 'google-extended',
        'ccbot', 'applebot-extended', 'amazonbot', 'meta-externalagent',
    );

    $is_ai_bot = false;
    foreach ( $ai_bots as $bot ) {
        if ( strpos( $user_agent, $bot ) !== false ) {
            $is_ai_bot = true;
            break;
        }
    }

    // Blocca AI bot su endpoint dinamici (non sulla homepage)
    $dynamic_patterns = array( '/cart/', '/checkout/', '/my-account/', '/?add-to-cart=', '/?s=' );
    $is_dynamic       = false;
    foreach ( $dynamic_patterns as $pattern ) {
        if ( strpos( $request_uri, $pattern ) !== false ) {
            $is_dynamic = true;
            break;
        }
    }

    if ( $is_ai_bot && $is_dynamic ) {
        // Log per analisi
        error_log( sprintf(
            'mrtux-bot-guard: blocked %s on %s from %s',
            $user_agent, $request_uri, $ip
        ) );
        // Risposta 403 con messaggio
        status_header( 403 );
        nocache_headers();
        wp_die(
            'AI bot access to dynamic endpoints is restricted. Please use static URLs only.',
            'Access Denied',
            array( 'response' => 403 )
        );
        exit;
    }

    // Rate limit applicativo su /?add-to-cart= (anti inventory hoarding)
    if ( strpos( $request_uri, 'add-to-cart=' ) !== false ) {
        mrtux_check_rate_limit( $ip, 'add_to_cart', 10, 60 );
    }

    // Rate limit applicativo su /checkout/ POST (anti card testing)
    if ( strpos( $request_uri, '/checkout' ) !== false && $_SERVER['REQUEST_METHOD'] === 'POST' ) {
        mrtux_check_rate_limit( $ip, 'checkout_post', 5, 60 );
    }
}

function mrtux_check_rate_limit( $ip, $action, $limit, $window_seconds ) {
    $key = "mrtux_rl_{$action}_{$ip}";
    $count = get_transient( $key );
    if ( $count === false ) {
        set_transient( $key, 1, $window_seconds );
        return;
    }
    if ( $count >= $limit ) {
        status_header( 429 );
        nocache_headers();
        wp_die( 'Too many requests. Please slow down.', 'Rate Limited', array( 'response' => 429 ) );
        exit;
    }
    set_transient( $key, $count + 1, $window_seconds );
}

Livello 4 — Cleanup transient orfani per ridurre il carico DB

Anche con protezione attiva, il danno pregresso va sanato. Script di cleanup da eseguire via WP-CLI ogni settimana:

#!/bin/bash
# cleanup_transients.sh - esegui settimanalmente via wp-cron
# Pulizia carrelli abbandonati più vecchi di 7 giorni

wp transient delete --expired --allow-root

# Pulizia specifica transient WC orfani
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_transient_wc_cart_%' AND option_name NOT LIKE '%_timeout%'" --allow-root

# Pulizia sessioni WC più vecchie di 24h
wp db query "DELETE FROM wp_options WHERE option_name LIKE '_wc_session_%' AND option_name NOT LIKE '%_timeout%' AND autoload = 'no'" --allow-root

# Statistiche post-cleanup
wp db query "SELECT COUNT(*) as total_transients FROM wp_options WHERE option_name LIKE '_transient_%'" --allow-root

Architettura completa: dal CDN all'application server

Una protezione efficace richiede coordinazione tra layer. Ecco lo stack raccomandato per un WooCommerce medio (5.000-50.000 ordini/mese).

Stack tipo

• CDN/Edge: Cloudflare Pro o Business (WAF incluso) o Fastly (VCL configurabile)
• Reverse proxy: Nginx con microcaching (opzionale, intermedio)
• Application: PHP-FPM 8.2+ con OPCache abilitato, OPcache.validate_timestamps=0 in produzione
• Database: MySQL 8.0 con Redis per object cache (transient, sessioni WC)
• Monitoring: Kinsta APM, New Relic o un self-hosted come Tideways

Confronto rapido: protezione per profilo di sito

Stack consigliato per WooCommerce medio

Caso studio reale: WooCommerce con 12.000 SKU

Un cliente reale (negozio B2B con 12.000 SKU, 30.000 ordini/mese) aveva un problema critico: CPU al 75% sustained, banda in eccesso di 400 GB/mese, checkout lento (1.8 secondi medi). Audit iniziale: il 65% del traffico era bot AI.

Diagnosi

# Analisi log per user agent (top 20 bot)
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

Risultato: GPTBot 38%, ClaudeBot 17%, AhrefsBot 14%, PerplexityBot 9%, altri bot SEO 22%.

Intervento applicato

1. Blocco AI bot su /cart/, /checkout/, /my-account/ (livello 3 PHP guard)
2. Cache Cloudflare differenziata per pattern URL (livello 1)
3. WAF rules su 5 pattern sospetti (livello 2)
4. Redis per object cache (sostituzione transients)
5. Cleanup transient orfani schedulato (livello 4)

Risultati a 30 giorni

Configurazione PHP-FPM ottimizzata per WooCommerce con bot

Un aspetto spesso sottovalutato: il worker pool di PHP-FPM va dimensionato sul traffico REALE, non sul traffico totale. Con bot filtrati al 65%, il dimensionamento cambia radicalmente.

; /etc/php/8.2/fpm/pool.d/woocommerce.conf
[woocommerce]
user = www-data
group = www-data
listen = /run/php/php8.2-fpm-woocommerce.sock
listen.owner = www-data
listen.group = www-data

pm = dynamic
pm.max_children = 50        ; 50 worker processi (era 120 prima)
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500       ; ricicla ogni 500 richieste per memory leak

; Timeout aggressivi perché bot timeout-spam non deve bloccare worker
request_terminate_timeout = 15s

; Slow log per identificare bottleneck
slowlog = /var/log/php-fpm-woocommerce-slow.log
request_slowlog_timeout = 3s

Monitoring: cosa misurare e come

Tre sono i KPI critici da tracciare nel tempo per capire se la protezione funziona.

KPI 1 — Rapporto bot/totale per endpoint

# Conta richieste bot per endpoint specifico
awk -F'"' '/cart\// {print $6}' /var/log/nginx/access.log | \
    grep -iE 'bot|crawl|spider' | wc -l
awk '/cart\//' /var/log/nginx/access.log | wc -l

Target: bot/totale < 10% su /cart/, /checkout/, /my-account/.

KPI 2 — Tempo medio di risposta per endpoint

Tracciare con Kinsta APM, New Relic o NGINX Plus. Target: P95 < 500ms su /cart/, P95 < 800ms su /checkout/.

KPI 3 — Tasso di conversione per sessione

Se il tasso di conversione reale sale dopo l'intervento, i bot stavano effettivamente interferendo con utenti reali (es. esaurendo stock, sovraccaricando server).

Errori da evitare

• Bloccare TUTTI i bot AI indiscriminatamente: ti tagli fuori da AEO/GEO. Blocca solo su endpoint dinamici specifici, non su tutto il sito
• Affidarsi solo a robots.txt: i bot malevoli lo ignorano. Serve difesa multi-layer
• Ignorare i transient orfani: degradano performance anche con bot bloccati
• Dimensionare PHP-FPM sul traffico totale: senza separare bot da umani, spendi risorse in worker inutili
• Non loggare le decisioni del guard: senza log non puoi distinguere falsi positivi da attacchi reali

FAQ

I bot AI rispettano robots.txt?

I bot AI noti (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) rispettano robots.txt, ma con sfumature. Google-Extended ad esempio permette di disabilitare l'uso per AI training mantenendo l'indicizzazione per AI Overviews. Vedi il nostro articolo dedicato per la configurazione completa.

Conviene bloccare i bot su /cart/ e /checkout/ o lasciarli indicizzare?

Bloccare. Cart e checkout contengono dati sensibili (sessioni, carrelli, CSRF token) e non devono essere indicizzati da nessun bot, né AI né SEO. Nessun motore di ricerca serio tenta di indicizzare /checkout/ perché riconosce la natura dinamica.

Come distinguo bot AI da bot SEO legittimi?

Verifica il user agent contro le liste ufficiali: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot sono AI bot. Googlebot, Bingbot, DuckDuckBot sono SEO bot. I SEO bot tradizionali non hanno motivo di colpire /cart/ o /checkout/. Vedi il caso studio WooCommerce per numeri specifici.

Redis è obbligatorio per WooCommerce con bot?

Non obbligatorio ma fortemente consigliato se superi i 5.000 ordini/mese o se hai più di 30 plugin attivi. Redis sposta transients e sessioni WC fuori dalla tabella wp_options (che diventa enorme con migliaia di carrelli abbandonati), riducendo drasticamente il carico DB.

Cloudflare Bot Protection vale i 20€/mese Pro?

Sì, per qualsiasi WooCommerce con traffico > 50k req/mese. La protezione automatica inclusa nel piano Free identifica solo i bot più ovvi. Bot Protection (Pro+) usa modelli ML addestrati su traffico reale e intercetta il 60-80% in più di bot senza falsi positivi.

Devo applicare la stessa protezione anche su /?s= (search)?

Sì, ma con regole diverse. Search è cachable se l'utente non è loggato. Implementa edge cache con TTL breve (5-15 minuti) e consenti ai bot AI di accedervi (è contenuto pubblico e utile per la citazione). Blocca invece i bot SEO spam che generano migliaia di URL ?s=keyword-spam.

Come gestisco i falsi positivi sui clienti che usano headless browser?

Whitelist per IP noti o per user agent custom. Conserva sempre un log delle decisioni del guard per identificare pattern e correggere le regole. Una buona pratica è iniziare con azioni "Challenge" (JS challenge) invece di "Block" duro per i primi 30 giorni, analizzare i log, poi passare a "Block" per le sorgenti chiaramente bot.

Conclusione operativa: il piano d'azione in 7 giorni

Gli endpoint dinamici WooCommerce sono il vero fronte caldo del 2026. I bot AI sono qui, si moltiplicano, e senza protezione chirurgica erodono budget hosting e UX reale.

In 7 giorni puoi mettere in sicurezza il tuo store:

• Giorno 1-2: audit log per identificare i bot attivi e i pattern URL
• Giorno 3: edge caching differenziato su Cloudflare
• Giorno 4: WAF rules su 5 pattern critici
• Giorno 5: PHP guard con priorità alta
• Giorno 6: cleanup transient orfani + setup Redis
• Giorno 7: monitoring KPI + tuning PHP-FPM

L'obiettivo non è bloccare tutto: è dare priorità al traffico umano che converte. I bot AI hanno il loro spazio (articoli, documentazione, pagine prodotto statiche). Cart e checkout sono territorio umano.

Riferimenti utili per approfondire

• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - panoramica gestione bot AI
• WooCommerce sotto attacco bot AI: proteggere il checkout - caso studio specifico WooCommerce
• Container Docker per PHP: setup minimale per sviluppare in locale - ambiente dev PHP ottimizzato
• Kinsta - Why dynamic endpoints are the most expensive part of bot traffic - articolo fonte Kinsta 2026-06-04
• Kinsta - How to reduce bandwidth waste without blocking legitimate users - guida pratica riduzione banda
• Cloudflare WAF Custom Rules documentation - documentazione WAF Cloudflare
• Cloudflare Bot Solutions - panoramica prodotti bot management
• WooCommerce - High Performance Order Storage (HPOS) - guida HPOS per WooCommerce
• WordPress Transients API documentation - API transients ufficiale
• OWASP - Credential Stuffing Prevention - linee guida sicurezza OWASP
• Nginx microcaching guide - microcaching con Nginx
• Varnish VCL documentation - documentazione Varnish VCL