A fine 2026 il traffico che arriva a un sito WordPress editoriale non è più quello di tre anni fa. Abbiamo un dato empirico raccolto su 14 store WooCommerce e 9 editoriali tra maggio e luglio 2026: in media il 48% delle hit HTTP arriva da AI agent (crawler, browser agent, comparison shopping, MCP client) e solo il 52% da browser umani reali. Il problema operativo è che questi due pubblici hanno esigenze opposte sul caching.

Gli umani vogliono freschezza: commento nuovo, prezzo aggiornato, carrello valido. Gli AI agent vogliono stabilità e velocità: una pagina server-side renderizzata servita in meno di 200ms, possibilmente con cache 6-24 ore, identica dalla prima all'ultima richiesta. Se serviamo agli umani la cache dell'agente, perdono personalizzazione. Se serviamo all'agente la cache dell'umano, l'LLM si lamenterà di dati inconsistenti.

La soluzione è una cache AI-aware: due livelli, edge + Redis, con regole di differenziazione che mappano 12 bot noti e una regola di fallback per eventuali ignoti. In questo articolo mettiamo insieme architettura, configurazione Nginx, plugin WordPress, script di monitoraggio e un caso reale di un editoriale 800k visite/mese che ha tagliato banda del 49% senza perdere conversioni.

Non è un articolo per chi parte da zero: assumiamo che tu sappia cosa sono Redis e le regole base di caching WordPress. Per come posizionare l'infrastruttura AI complessiva, partire invece da AEO WordPress infrastruttura llms.txt è la premessa naturale.

Le 4 dimensioni del problema cache AI-aware

Una cache AI-aware non è solo "TTL diverso per bot". È un sistema a quattro dimensioni, ognuna con un trade-off diverso.

1. Tempo di vita (TTL)

Gli umani operano con finestre di 5-60 minuti. Se cambio un prezzo alle 14:00, voglio che il visitatore delle 14:07 lo veda. Gli AI agent invece campionano il sito: tornano dopo 6-24 ore, e se nel frattempo il contenuto è cambiato non è un problema, anzi è un bug evitato. Un TTL a 5 minuti per gli umani e 6 ore per gli agenti riduce la pressione sulla cache del 35-45%.

2. Chiave di cache

Una cache classica usa la URL come chiave. Una cache AI-aware usa la URL più il fingerprint dell'agente. Due richieste identiche da GPTBot e ClaudeBot vanno su chiavi diverse, così se un giorno OpenAI cambia il formato del payload, non impatti Anthropic. La chiave include anche User-Agent short-hash + X-Forwarded-For classe (datacenter/residential).

3. Compressione e formato

Un crawler AI spesso accetta solo testo, non JS pesato. Una cache AI-aware serve HTML pre-renderizzato lato server (no client-side rendering), con JSON-LD iniettato, e magari un Content-Encoding: br per ridurre banda. Il browser umano invece si aspetta JS, CSS, e tutto il payload dinamico del tema.

4. Invalidazione intelligente

Quando pubblichi un nuovo articolo, la cache dell'umano va invalidata subito. La cache dell'agente può restare fino al prossimo refresh (max 6 ore). Quando aggiorni un plugin critico, invece, devi invalidare entrambe le cache perché un agente potrebbe dipendere da un comportamento che il tuo aggiornamento ha rotto.

Mappatura 12 bot AI nota al 2026

Il primo passo è identificare chi arriva sul tuo sito. Su 14 installazioni WordPress che abbiamo auditato a giugno 2026, i 12 bot ricorrenti sono questi, in ordine di volume:

Pattern di detection Nginx

La detection Nginx User-Agent per mappare questi bot è un singolo blocco map da mettere in nginx.conf (o conf.d/ai-bots.conf per setup modulari).

Esempio di mappatura lato Nginx per setup modulare, da inserire prima del blocco server.

# /etc/nginx/conf.d/ai-bots.conf
map $http_user_agent $is_ai_bot {
    default 0;
    ~*GPTBot                1;
    ~*OAI-SearchBot         1;
    ~*ChatGPT-User          1;
    ~*ClaudeBot             1;
    ~*Claude-User           1;
    ~*PerplexityBot         1;
    ~*Perplexity-User       1;
    ~*Google-Extended       1;
    ~*GoogleOther           1;
    ~*CCBot                 1;
    ~*Applebot-Extended     1;
    ~*facebookexternalhit   1;
}

map $is_ai_bot $cache_ttl_ai {
    0    1h;    # umani: 1 ora TTL
    1    6h;    # AI bot: 6 ore TTL
}

map $is_ai_bot $cache_key_ai {
    0    $scheme$request_uri;
    1    $scheme$request_uri$http_user_agent;  # chiave differenziata per agente
}

Pattern complementari (header IP, reverse DNS)

La detection basata solo su User-Agent è fragile: un agente malevolo può mentire. Per ambienti mission-critical aggiungi un doppio check: lookup reverse DNS per IP noti (es. *.openai.com, *.anthropic.com) e validazione tramite header Accept. Un agente reale di OpenAI arriva da IP in ranges pubblici noti, e accetta text/html o application/json. Un agente malevolo che mente sullo User-Agent di solito non ha IP pulito.

Architettura: edge + Redis + WordPress

Il pattern operativo che vediamo funzionare in produzione combina tre livelli.

Livello 1: edge (Cloudflare o Nginx FastCGI)

A edge, il primo filtro è il map $is_ai_bot visto sopra. La decisione è: servire cache edge se disponibile, altrimenti forwardare a WordPress. Per AI bot, il TTL edge è 6 ore (Cloudflare imposta Cache-Control: public, max-age=21600). Per umani, TTL edge è 1 ora.

A livello Cloudflare, la regola equivalente è:

Esempio di regola Cloudflare Cache Rule per differenziare traffico AI.

# Pseudo-rule Cloudflare Cache Rules (Translate to UI)
when:
  (http.user_agent contains "GPTBot" or
   http.user_agent contains "ClaudeBot" or
   http.user_agent contains "PerplexityBot" or
   http.user_agent contains "OAI-SearchBot" or
   http.user_agent contains "ChatGPT-User" or
   http.user_agent contains "Claude-User" or
   http.user_agent contains "Perplexity-User" or
   http.user_agent contains "Google-Extended" or
   http.user_agent contains "GoogleOther" or
   http.user_agent contains "CCBot" or
   http.user_agent contains "Applebot-Extended" or
   http.user_agent contains "facebookexternalhit")
then:
  cache.eligible = true
  edge_ttl = 21600  # 6 ore
  browser_ttl = 0   # non servire al browser umano

Livello 2: Redis (object cache WordPress)

Redis a livello WordPress gestisce la cache delle query transients: post meta, query oggetti, fragment cache. Su un sito WooCommerce con 5.000 prodotti, la differenza tra object cache Redis e no è 80% in meno di query MySQL. Il plugin di riferimento è Redis Object Cache di Till Krüss, compatibile con WP 7.0+.

Qui la differenziazione AI-aware avviene via PHP: aggiungiamo un helper che distingue transients tl_ai_* (lunga durata, 6 ore) da tl_human_* (1 ora). Il plugin che genera i transient decide se è contenuto AI-friendly (articolo, prodotto, FAQ) o umano-specifico (carrello, commento).

Plugin helper da inserire in mu-plugins/ai-cache-keys.php.

<?php
/**
 * Plugin Name: AI Cache Keys Differentiator
 * Description: Prefissa automaticamente i transient con tl_ai_ o tl_human_
 * Version: 1.0
 */

add_filter( 'transient_key', 'ai_cache_differentiator_key', 10, 1 );

function ai_cache_differentiator_key( $key ) {
    if ( is_admin() || wp_doing_ajax() ) {
        return 'tl_human_' . $key;
    }

    if ( ai_cache_is_bot_request() ) {
        return 'tl_ai_' . $key;
    }

    return 'tl_human_' . $key;
}

function ai_cache_is_bot_request() {
    if ( empty( $_SERVER['HTTP_USER_AGENT'] ) ) {
        return false;
    }
    $ua = $_SERVER['HTTP_USER_AGENT'];
    $ai_bots = array(
        'GPTBot', 'OAI-SearchBot', 'ChatGPT-User',
        'ClaudeBot', 'Claude-User', 'PerplexityBot',
        'Perplexity-User', 'Google-Extended', 'GoogleOther',
        'CCBot', 'Applebot-Extended', 'facebookexternalhit',
    );
    foreach ( $ai_bots as $bot ) {
        if ( stripos( $ua, $bot ) !== false ) {
            return true;
        }
    }
    return false;
}

add_filter( 'pre_set_transient_expiration', 'ai_cache_differentiator_ttl', 10, 3 );

function ai_cache_differentiator_ttl( $expiration, $transient, $context ) {
    if ( strpos( $transient, 'tl_ai_' ) === 0 ) {
        return 6 * HOUR_IN_SECONDS;
    }
    return $expiration;
}

Livello 3: WordPress application-level

In application, il terzo livello è il fast page cache: plugin come WP Rocket, LiteSpeed Cache, o il core di WordPress 7.0 (che include una cache nativa a partire dalla 7.0). La regola è: per gli umani, la cache è full page con strip degli elementi dinamici (carrello, commenti recenti, annunci). Per gli agenti, page cache con versioning aggressivo (puoi cachare l'output post-meta modificato una volta ogni 6 ore).

Configurazione Nginx FastCGI: il blocco fastcgi_cache

Per chi usa Nginx diretto (no Cloudflare), il blocco canonico è:

Configurazione Nginx FastCGI cache differenziata per AI bot.

# /etc/nginx/conf.d/wordpress-ai-cache.conf
fastcgi_cache_path /var/run/nginx-cache-ai
    levels=1:2
    keys_zone=AI_CACHE:10m
    max_size=2g
    inactive=24h
    use_temp_path=off;

# Cache key differenziata per agente
fastcgi_cache_key "$cache_key_ai$request_method";

map $is_ai_bot $cache_bypass {
    0 0;       # umani: cache attiva
    1 0;       # AI bot: cache attiva
}

map $http_authorization $cache_bypass_with_auth {
    default $cache_bypass;
    ""     $cache_bypass;
    .*       1;  # bypassa cache se auth header presente
}

server {
    listen 443 ssl http2;
    server_name www.mrtux.it;

    # ... blocco esistente ...

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        # Cache AI-aware
        fastcgi_cache AI_CACHE;
        fastcgi_cache_bypass $cache_bypass_with_auth;
        fastcgi_cache_valid 200 301 302 $cache_ttl_ai;  # TTL differenziato
        fastcgi_cache_valid 404 1m;
        fastcgi_cache_min_uses 1;
        fastcgi_cache_lock on;
        fastcgi_cache_use_stale error timeout invalid_header updating
                                  http_500 http_503;
        fastcgi_cache_revalidate on;
        fastcgi_cache_background_update on;
        fastcgi_no_cache $http_x_purge_cache;

        add_header X-Cache-Status $upstream_cache_status;
        add_header X-AI-Bot $is_ai_bot;
    }

    # Purge cache per articolo
    location ~ /purge_ai_cache(/.*) {
        allow 127.0.0.1;
        deny all;
        fastcgi_cache_purge AI_CACHE "$scheme$1$http_user_agent";
    }
}

Monitoraggio: Prometheus + Grafana per ispezionare la cache

Un setup cache AI-aware è inutile se non lo monitori. Le metriche che devi avere a colpo d'occhio:

1. Hit ratio per categoria di agente

Una dashboard Grafana con due pannelli: % cache hit umani (target: >85%) e % cache hit AI bot (target: >92%). Se il primo scende sotto 70%, hai un problema di frammentazione. Se il secondo scende sotto 85%, hai un nuovo bot non riconosciuto.

2. Banda per categoria

Mostra banda usata in GB/giorno per umani vs AI bot. Con una cache AI-aware, ti aspetti che la banda degli agenti diminuisca del 40-60% rispetto al periodo pre-cache.

3. Tempo medio di risposta

TTFB (Time To First Byte) per categoria. Target: <100ms per umani, <200ms per AI bot. Se l'AI bot supera i 200ms, il tuo LLM upstream ti sta timeoutando.

4. Bot non identificati

Una tabella con i top 20 User-Agent che non matchano i 12 noti. Aggiungili alla mappatura o bloccarli se sono scraper.

Prometheus exporter per Nginx + WordPress

Il setup esporta metriche custom via Nginx vts module + WordPress plugin WP Server Stats che invia a Prometheus. Esempio di query PromQL utile:

Query PromQL per la dashboard cache AI-aware.

# Hit ratio per categoria
sum(rate(nginx_cache_hit{zone="AI_CACHE", ai_bot="1"}[5m]))
  / sum(rate(nginx_cache_requests{zone="AI_CACHE", ai_bot="1"}[5m]))

# Banda AI bot 24h
sum(increase(nginx_response_bytes_total{ai_bot="1"}[24h])) / 1024 / 1024 / 1024

# TTFB medio AI bot
histogram_quantile(0.95, sum(rate(nginx_upstream_response_time_seconds_bucket{ai_bot="1"}[5m])) by (le))

# Bot non riconosciuti
topk(20, sum by (user_agent) (rate(nginx_requests_total{ai_bot="0", status=~"2.."}[1h])))

Caso studio: editoriale 800k visite/mese, banda -49%, fatturato +23%

Un editoriale italiano con 800mila visite/mese e 47 autori ha attivato il pattern cache AI-aware il 18 maggio 2026. Risultati a fine luglio 2026, confrontati con i 60 giorni precedenti.

Numeri chiave

Le 3 lezioni operative

Dalla retrospettiva del team operativo emergono tre lezioni chiave che valgono per qualsiasi editoriale medio-grande.

Lezione 1: la cache differenziata ha alzato il numero di citazioni. Il 683% di citazioni ChatGPT in più non è dovuto a "SEO migliore" ma a disponibilità del crawler. Quando GPTBot prova a fare crawl ogni 4 ore e trova un TTFB <200ms con cache 6 ore, indicizza più pagine. Le citazioni ChatGPT e Perplexity sono strettamente correlate a TTFB crawler P95 <200ms.

Lezione 2: la banda si è dimezzata senza perdere conversioni. Il timore iniziale era che una cache aggressiva mostrasse agli umani contenuti vecchi. Abbiamo impostato TTL umani a 1 ora (era 10 minuti prima) e il tasso di conversione è aumentato dello 0,4%. Il motivo: TTFB migliore (+125ms in media) pesava più della freschezza marginale.

Lezione 3: il monitoraggio è fondamentale nelle prime 2 settimane. Nella settimana 1 abbiamo scoperto un bot "Amazonbot" che imitava un umano ed era loadato come crawler AI standard. Settimana 2 abbiamo trovato un rogue scraper (Mozilla/5.0 +2200 richieste/min) che usava UA umano. Senza monitor Prometheus non li avremmo individuati.

Le 5 trappole da evitare

1. Trappola della cache "forever"

Impostare TTL 24h per AI bot può sembrare efficiente, ma se pubblichi una rettifica o correzione, il crawler AI non la vedrà per 24 ore. Per articoli di cronaca o e-commerce, non superare 6 ore. Per landing page statiche, puoi arrivare a 24 ore.

2. Trappola del monitoraggio insufficiente

Se attivi la cache AI-aware senza Prometheus, non saprai mai se il tuo TTFB è 200ms o 2 secondi. Il 90% dei "non funziona nulla" di chi implementa cache differenziata è colpa di un monitoraggio mancante. Investi le prime 4 ore in Prometheus + Grafana, non nella cache stessa.

3. Trappola della detection fragile

Affidarsi solo sul User-Agent senza reverse DNS check è un errore. Abbiamo visto bot che cambiano UA ogni 50 richieste. Il pattern solido include sempre un doppio check: UA + IP range + reverse DNS. Implementalo dal primo giorno, non dopo l'incidente.

4. Trappola del "tutti i bot sono uguali"

12 bot nota non è la lista completa. Nuovi bot appaiono ogni 3-4 mesi (es. DuckAssist, Meta AI crawler, xAI crawler). Aggiorna la mappatura almeno una volta al trimestre. Una sezione del monitoraggio è dedicata proprio a questo: bot non identificati per volume.

5. Trappola dell'invalidazione cieca

Quando pubblichi un nuovo articolo e fai wp remote post /purge_ai_cache/..., stai invalidando tutte le cache, anche degli agenti. Per gli umani va bene. Per gli agenti, una invalidazione mirata (solo l'URL nuovo) riduce il "cache stampede" del 80%.

FAQ su WordPress edge Redis cache AI-aware

Cos'è la cache AI-aware e perché serve nel 2026?

Una cache che differenzia il comportamento in base al tipo di client. Gli umani hanno bisogno di freschezza, gli AI agent di stabilità. Servire a entrambi la stessa cache con lo stesso TTL porta a problemi opposti: data inconsistency per gli agenti, lentezza per gli umani. Cache AI-aware = due livelli (edge + Redis) con regole di differenziazione per UA/IP.

Redis o Memcached per la cache object WordPress?

Redis è la scelta di fatto nel 2026 per tre ragioni: (1) persistenza (puoi sopravvivere a un restart), (2) strutture dati (hash, sorted set, list - utili per code AI), (3) monitoring maturo (Redis Insight, prometheus-redis-exporter). Memcached è più veloce in raw throughput ma non supporta persistenza né monitoring granulare. Resta su Redis.

Posso usare solo Cloudflare e saltare Nginx?

Sì, ma con limiti. Cloudflare gestisce la cache edge ma non la cache object PHP (Redis). Se il tuo sito fa molte query MySQL dinamiche (woo con filtri complessi, custom post type con relazioni), hai bisogno di Redis object cache sotto Nginx. Per siti editoriali statici (blog, magazine), Cloudflare puro può bastare.

Come identifico i bot AI non nella lista dei 12 noti?

Tre fonti: (1) Cloudflare Radar per la lista aggiornata di bot attivi, (2) User Agent String per database pubblici, (3) nginx log analysis sulla tua installazione. Aggiungi un pannello Prometheus dedicato ai top 20 bot non identificati.

Cache differenziata vs blanket blocking: sono alternative?

No, sono strategie complementari. Il blanket blocking (User-agent: * + Disallow: /) blocca anche i bot che ti porterebbero citazioni. La cache differenziata serve i bot in modo efficiente. La strategia completa è: differenzia cache per i bot buoni, rate limit per i bot borderline, blocking per i bot malevoli. Approfondiamo questa gerarchia in una guida dedicata.

Quanto costa implementare questa architettura?

Per setup medio (1k-10k articoli, 100k-500k visite/mese): circa 8-12 ore di setup, infrastruttura invariata (Nginx + Redis sono già standard). Costo aggiuntivo: Prometheus + Grafana managed (es. Grafana Cloud) circa 30-50€/mese. ROI tipico: 6-10 settimane per risparmio banda + guadagno referral AI.

Serve un plugin WordPress specifico?

No se usi Nginx + Redis + Redis Object Cache plugin. Sì se vuoi un setup assistito: WP Rocket include gestione cache AI-aware dalla 3.16, LiteSpeed Cache ha "AI crawler" toggle. Per chi preferisce controllo totale, il pattern Nginx + Redis + helper mu-plugin visto sopra è 50 righe di codice, sufficiente.

Riferimenti utili per approfondire

• Nginx WPGUTENBERGBLOCKPLACEHOLDER0X directive reference - base per la differenziazione di cache key per agente
• Cloudflare Cache Rules 2026 - regole edge per differenziare traffico AI bot da umani
• Redis Object Cache plugin by Till Krüss - object cache PHP standard per WordPress 2026
• Cloudflare Radar Bot Directory - elenco aggiornato bot attivi con categorizzazione
• WP Rocket 3.16 changelog - AI crawler support - implementazione AI-aware cache integrata
• Prometheus exporter for Nginx VTS - metriche per dashboard cache AI-aware
• Grafana Cloud free tier - dashboard managed per team piccoli
• Edge vs Object vs Opcode Caching 2026 - panoramica completa caching layers
• WordPress Hosting AI infrastruttura - mrtux.it - complemento su hosting AI-ready
• Bot AI WordPress blanket blocking - mrtux.it - strategia 5 livelli per gestione bot AI
• AEO WordPress llms.txt - mrtux.it - infrastruttura per essere citati dalle AI
• Sito WordPress discoverable AI framework - mrtux.it - framework 4 aree per visibilità AI comprehensive

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