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.

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