In WP-Cron WordPress: ottimizzare i task background in produzione abbiamo affrontato il lato "come configurare WP-Cron correttamente in produzione" — disabilitare lo spawn nativo, spostare su cron di sistema, gestire WP-CLI. Ma quel setup da solo non basta. Il 2026 ha reso il problema molto più visibile: import massivi WooCommerce, backup incrementali, e scan di sicurezza AI-assisted competono per risorse condivise con il traffico utente in modo che fino al 2024 era trascurabile. Oggi non lo è più.

Il problema invisibile che nessuno misura

Un cron WordPress — qualunque esso sia, sia esso pianificato via WP-Cron sia eseguito da cron di sistema con wp cron event run — fa una cosa semplice dal punto di vista logico: esegue codice PHP. Ma dal punto di vista del sistema operativo quel codice PHP deve passare attraverso lo stesso stack di qualsiasi richiesta web:

# catena di esecuzione di un cron job su WordPress
1. PHP binary avviato (o php-fpm worker riservato)
2. WordPress core caricato (~80-150 MB RAM)
3. Plugin attivi caricati (ognuno aggiunge overhead)
4. Connessione database aperta
5. Eventuale cache object (Redis/Memcached) collegata
6. Codice del cron eseguito
7. Risultato persistito (DB/scritture filesystem)

Anche un cron leggero come wp cron event run due_action consuma 60-100 MB di RAM per i 200-400 millisecondi che dura. Un cron pesante come un import WooCommerce da CSV di 10.000 prodotti dura 20-45 minuti e consuma costantemente 150-250 MB.

Il punto critico non è il consumo di per sé. È che quel PHP-FPM worker — o quel processo PHP-CLI — compete per le stesse risorse del tuo web server:

• CPU: il job usa cicli che potrebbero servire a servire il checkout di un cliente.
• Database connection pool: MySQL ha un limite di connessioni concorrenti (default 151). Un cron pesante che ne apre 5-10 ruba slot al traffico web.
• I/O disco: scritture su wp_options, wp_postmeta, file uploads competono con la cache page su disco.
• PHP-FPM pool: se il cron passa per php-fpm (impostazione sbagliata ma comune), sottrae worker al web server.

Su un sito WooCommerce con 50 PHP-FPM worker disponibili, un cron di import che passa per php-fpm e ne occupa 10-15 contemporaneamente riduce il pool effettivo a 35-40 — esattamente il punto in cui, nei momenti di punta, la saturazione ricomincia. È la stessa dinamica dei bot AI che abbiamo analizzato in WordPress PHP thread 2026: come i bot AI li stanno esaurendo, solo che stavolta il "bot" è un tuo job interno.

Le 5 metriche che devi monitorare

Il framework operativo si basa su 5 metriche misurabili, tutte ricavabili da strumenti standard di un server WordPress gestito ragionevolmente.

Metrica 1: TTFB p95 durante i cron

Il Time To First Byte al 95° percentile è la metrica più diretta: misura il tempo di risposta del web server sotto carico. Quando un cron pesante parte, il TTFB p95 del sito live sale.

# script: misura TTFB p95 da log Nginx
# (assumendo log formato combined)
awk '{print $4, $7, $NF}' /var/log/nginx/access.log |   awk '$4 ~ /\[.*:[0-9]+:[0-9]+:[0-9]+\]/ {match($4, /\[([^:]+):([^:]+):([^:]+):([^:]+)/, t);   time_bucket = t[1]" "t[2]":"substr(t[3],1,2);   ttfb = $NF;   if (ttfb ~ /^[0-9.]+$/) print time_bucket, ttfb}' |   sort |   awk '{sum += $2; n++; arr[n]=$2; time=$1} END {print time, arr[int(n*0.95)]}'

Salvalo come /usr/local/bin/ttfb-p95-monitor.sh e fanne un cron ogni 5 minuti. Quando il valore sale sopra i 500 ms, hai un cron che sta impattando le performance.

Metrica 2: durata effettiva dei cron job

WP-CLI ti dice esattamente quanto dura un evento:

# misura durata effettiva di un evento cron
time wp cron event run your_heavy_event --allow-root --path=/var/www/html

Output tipo: real 3m42.115s — il tuo import sta durando 3 minuti e 42 secondi. Se lo esegui ogni ora, hai un throughput continuo di background activity che erode la capacità di picco per il traffico live.

Metrica 3: lock contention sul database

MySQL ha una metrica interna che ti dice se i tuoi cron stanno litigando con le query live per i lock sulle tabelle:

# controlla lock contention
mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G" |   grep -E "LATEST DETECTED DEADLOCK|LOCK WAIT TIMEOUT|Semaphore"

Se vedi deadlock o lock wait frequenti sulle tabelle wp_options, wp_postmeta, wp_wc_orders, il colpevole è quasi certamente un cron che scrive molto mentre il sito live sta cercando di leggere.

Metrica 4: disk I/O wait

Quando un cron scrive molto (import massivi, backup, rigenerazione miniature), il disco si satura e tutte le altre operazioni rallentano:

# controlla I/O wait
iostat -x 1 5 | awk '/^avg-cpu:/ {getline; print "iowait:", $4"%"}'

iowait > 20% durante un cron è segnale che il disco sta diventando il collo di bottiglia. Su hosting con storage di rete (EBS, NFS), questo è ancora più marcato.

Metrica 5: PHP-FPM queue length

L'ultima metrica è la lunghezza della coda di processi PHP in attesa. Quando la coda si riempie, i visitatori reali aspettano:

# monitor coda php-fpm
curl -s "YOUR_PHP_FPM_STATUS_ENDPOINT" |   python3 -c "import json,sys; d=json.load(sys.stdin);   print(f"listen_queue={d.get('listen queue', 0)} max_listen_queue={d.get('max listen queue', 0)} active={d['active processes']}/{d['max active processes']}")"

Se listen_queue > 0 per più di 30 secondi consecutivi, hai un problema di capacity che potrebbe essere causato da un cron o da traffico bot AI (o da entrambi, come abbiamo visto nell'articolo precedente).

Il framework: il "background activity budget"

La soluzione non è "vietare i cron pesanti" — i cron sono necessari. La soluzione è dargli un budget operativo misurabile.

Passo 1: definisci il tuo budget

Il budget è definito da tre vincoli:

CPU consentita background:    max 30% di 1 core durante i job
RAM consentita background:    max 25% della RAM totale
PHP-FPM workers sottratti:   max 15% del pool
I/O wait aggiuntivo ammesso:  max 10% sopra il baseline live

Questi numeri sono conservativi per un sito WooCommerce di medie dimensioni. Su un sito editoriale con traffico di picco notturno puoi permetterti budget più alti nelle ore diurne e più bassi nelle ore di punta.

Passo 2: schedula i cron pesanti nelle finestre a basso traffico

L'errore più comune è eseguire import massivi alle 14:00 perché "il sistema è libero a quell'ora". Ma il sistema è libero a quell'ora solo perché alle 14:00 non c'è molto traffico, non perché il sistema può permettersi di degradare quello che c'è.

# sposta i cron pesanti in finestre a basso traffico (2-5 del mattino per ecommerce IT)
# /etc/cron.d/wordpress-imports
0 2 * * * www-data cd /var/www/html && /usr/local/bin/wp cron event run woo_import_daily --allow-root >> /var/log/wp-cron-imports.log 2>&1
0 3 * * * www-data cd /var/www/html && /usr/local/bin/wp cron event run woo_sync_stock --allow-root >> /var/log/wp-cron-imports.log 2>&1
0 4 * * * www-data cd /var/www/html && /usr/local/bin/wp cron event run woo_regenerate_thumbs --allow-root >> /var/log/wp-cron-imports.log 2>&1

Ma non basta spostarli di notte: devi anche limitare la concorrenza interna al job.

Passo 3: limita la concorrenza interna dei cron pesanti

Molti plugin (specialmente quelli di import) permettono di configurare batch size e pausa tra batch. Settare batch_size = 50 con pause_between = 2 seconds invece di batch_size = 500 con pausa zero riduce il picco di carico del 60-70% allungando la durata del 20%.

Per WooCommerce il pattern canonico è:

// imposta batch size conservativo per WooCommerce product import
add_filter('woocommerce_product_import_batch_size', function() {
    return 25; // prodotti per batch
});
add_filter('woocommerce_product_import_pause_between_batches', function() {
    return 2; // secondi tra batch
});

Passo 4: isola i cron pesanti dal web server

Se il tuo hosting lo permette, esegui i cron pesanti in un container o in un processo PHP-CLI separato dal web server, con il proprio database connection pool:

# esegui cron pesante via PHP-CLI (non via php-fpm)
# questo NON sottrae worker al web server
time php /var/www/html/wp-cron.php your_heavy_event

La differenza è enorme: php-fpm è progettato per gestire molte richieste brevi, non per un singolo job che dura 20 minuti. PHP-CLI è progettato per il contrario. Mandare un cron di import via php-fpm è come usare un'auto da corsa per traslocare — possibile, ma altamente inefficiente.

Passo 5: monitora e allerta

Il monitoraggio continuo è l'unica cosa che impedisce al framework di diventare una configurazione-iniziale-e-poi-si-dimentica. Lo script di monitoraggio che segue controlla le 5 metriche e invia un alert se il budget viene sforato:

#!/bin/bash
# /usr/local/bin/background-budget-watch.sh
# Monitor background activity budget - invia alert se superato

STATE_FILE="/tmp/budget_state"
LOG="/var/log/budget-monitor.log"
WEBHOOK_URL="YOUR_SLACK_OR_TELEGRAM_WEBHOOK"

# Misura I/O wait
IO_WAIT=$(iostat -x 1 2 | tail -1 | awk '{print $4}')

# Misura TTFB p95 ultimi 5 minuti (da log Nginx)
TTFB_P95=$(awk -v cutoff="$(date -d '5 minutes ago' +%H:%M:%S)" '$4 > "["cutoff {print $NF}' /var/log/nginx/access.log |   sort -n | awk 'END{print arr[int(NR*0.95)]}')

# Misura processi cron attivi
CRON_ACTIVE=$(pgrep -fc "wp cron event run")

# Soglie
IO_LIMIT=20
TTFB_LIMIT=1.5
CRON_LIMIT=3

ALERTS=""

if (( $(echo "$IO_WAIT > $IO_LIMIT" | bc -l) )); then
    ALERTS="$ALERTS\n- I/O wait: ${IO_WAIT}% > ${IO_LIMIT}%"
fi

if (( $(echo "$TTFB_P95 > $TTFB_LIMIT" | bc -l) )); then
    ALERTS="$ALERTS\n- TTFB p95: ${TTFB_P95}s > ${TTFB_LIMIT}s"
fi

if [ "$CRON_ACTIVE" -gt "$CRON_LIMIT" ]; then
    ALERTS="$ALERTS\n- Cron job attivi: $CRON_ACTIVE > $CRON_LIMIT"
fi

if [ -n "$ALERTS" ]; then
    MSG="⚠️ Background activity budget superato ($(date))$ALERTS"
    curl -s -X POST "$WEBHOOK_URL" -d "text=$MSG" >/dev/null
    echo "$(date +%s) ALERT: $ALERTS" >> "$LOG"
fi

Aggiungi a crontab ogni 5 minuti:

# ogni 5 minuti controlla il budget
*/5 * * * * root /usr/local/bin/background-budget-watch.sh

Il caso studio WooCommerce da 12.000 SKU

Un cliente tipico — negozio WooCommerce con 12.000 SKU, import giornaliero dal grossista, 2.000 ordini/giorno, hosting managed con 40 PHP-FPM worker — presentava questo quadro a inizio 2026:

• TTFB p95 diurno: 180-220 ms (sano).
• TTFB p95 alle 14:00 (orario import): 4.800 ms (catastrofico).
• Tasso di abbandono carrello alle 14:00: 71% (vs 28% medio diurno).
• Stima revenue perso per degrado cron: circa 8.000€/mese.

Applicando il framework in 4 settimane:

1. Spostato l'import da CSV alle 02:00 (finestra a traffico zero).
2. Ridotto batch size da 500 a 25 prodotti con pausa 2 secondi.
3. Migrato l'import da esecuzione via php-fpm a PHP-CLI con wp cron event run.
4. Aggiunto monitoring budget con alert Slack quando TTFB p95 > 1.5s.

Risultato a 60 giorni:

• TTFB p95 alle 14:00: 210 ms (invariato rispetto al baseline).
• Tasso di abbandono carrello: tornato al 28% anche nelle ore post-import.
• Revenue recuperato stimato: ~8.000€/mese.

Il costo di queste 4 modifiche è stato di mezza giornata di lavoro di un dev senior. Il ROI è stato inferiore a una settimana.

Le 3 trappole che il team WordPress medio non vede

Trappola 1: il cron "importante" che gira 24/7

Plugin come WooCommerce Subscriptions, Yoast SEO, Wordfence oggi eseguono cron continui per aggiornare dati, scansionare minacce, indicizzare contenuti. Molti di questi sono configurati per girare "ogni 5 minuti" o "ogni 15 minuti" — che sembra innocuo ma, sommato, significa attività di background continua per tutta la giornata.

Soluzione: audita i tuoi cron attivi con wp cron event list --allow-root e valuta se ognuno è necessario con quella frequenza.

Trappola 2: backup che bloccano il database

Plugin di backup come UpdraftPlus o BackupBuddy spesso eseguono dump del database via PHP. Su database grossi (>500 MB) il dump può durare 5-15 minuti e tenere lock su tabelle critiche per l'intera durata.

Soluzione: usa mysqldump via cron di sistema con parametri --single-transaction --quick per minimizzare i lock, oppure sposta il backup su uno strumento esterno (Kinsta backup, BlogVault) che lavora a livello di filesystem snapshot senza lock applicativi.

Trappola 3: AI scan di sicurezza in tempo reale

I plugin di sicurezza moderni (Wordfence, MalCare, Solid Security) hanno introdotto scan AI-assisted in tempo reale nel 2025-2026. Questi scan analizzano i file del tema e dei plugin ad ogni modifica — utile per la sicurezza, ma ogni scan attiva PHP execution e I/O disco.

Soluzione: configura lo scan AI come evento schedulato (settimanale), non come scan continuo. La sicurezza migliora quando l'analisi è completa e ragionata, non quando frammenta la CPU in mini-scan continui.

Come questo si collega agli articoli precedenti della serie

Il framework background activity budget è complementare a tre articoli della serie:

In WP-Cron WordPress: ottimizzare i task background in produzione abbiamo visto il setup tecnico di WP-Cron (disabilitare spawn nativo, cron di sistema, WP-CLI). Questo articolo aggiunge il livello successivo: una volta che i cron funzionano, come farli coesistere con il traffico live.

In WordPress PHP thread 2026: come i bot AI li stanno esaurendo abbiamo visto come i bot AI saturano il pool PHP-FPM. I cron pesanti fanno la stessa cosa dall'interno: sottraggono worker al web server.

In WP-CLI 2026 guida completa AI abbiamo visto come WP-CLI può essere usato come orchestratore di operazioni complesse. La regola "esegui i cron pesanti via PHP-CLI, non via php-fpm" è il complemento operativo di quel setup.

In Toolchain agenzia WordPress moderna 2026: guida pratica completa abbiamo visto come un toolchain moderno (Bedrock + Sage + Kinsta APM + AI assistant) misura e gestisce queste metriche. Il budget monitoring è esattamente ciò che Kinsta APM fa automaticamente — e che devi replicare manualmente su stack self-hosted.

Domande frequenti

È possibile eliminare del tutto i cron WordPress?

No, non del tutto. Alcune funzionalità essenziali di WordPress (publish scheduled post, transient cleanup, WooCommerce subscription renewal) richiedono cron. Puoi spostarli da WP-Cron a cron di sistema (più affidabile, più controllabile), ma non eliminarli.

Come faccio a sapere se un cron specifico sta degradando le performance?

Il metodo più diretto è il grafico TTFB p95 diurno sovrapposto agli orari dei tuoi cron. Se vedi una "montagna" di TTFB in corrispondenza di un orario specifico ogni giorno, hai identificato il colpevole. In alternativa puoi disabilitare temporaneamente quel cron (con WP-CLI: wp cron event delete your_event) e osservare se il TTFB torna normale.

È meglio WP-Cron o cron di sistema?

Cron di sistema. WP-Cron è affidabile solo se il sito riceve traffico (perché lo spawn dei cron avviene on-request). Se il sito è a basso traffico, WP-Cron può saltare eventi per ore. Cron di sistema + wp cron event run è la configurazione professionale raccomandata.

I plugin di cache aiutano anche per i cron?

Sì, in modo indiretto. Se il sito live è servito da cache page (Cloudflare, Varnish, LiteSpeed Cache), i PHP-FPM worker non vengono occupati dal traffico normale. Questo libera capacità per i cron. Ma il problema dei cron pesanti resta: anche con cache piena, il cron in background usa risorse.

Quando serve un hosting dedicato per i cron pesanti?

Quando il volume degli import/sync supera la capacità del tuo attuale server di gestirli nelle finestre a basso traffico senza degradare il live. Su WooCommerce, tipicamente sopra i 50.000 ordini/giorno o sopra i 100.000 SKU. In quei casi conviene separare il sito "front-end" (ottimizzato per velocità) dal sistema di import (ottimizzato per throughput batch).

Lo scan AI di Wordfence rallenta davvero il sito?

Dipende dalla configurazione. Con scan continuo su modifiche frequenti, sì. Con scan schedulato settimanale, l'impatto è trascurabile (un'ora di I/O alto a settimana, di solito in finestra a basso traffico). Raccomandazione: scan schedulato, non continuo.

Checklist operativa per i prossimi 14 giorni

• Lista completa dei cron attivi (wp cron event list) e frequenza di ognuno
• Identifica i 3 cron più pesanti (per durata media e scritture DB)
• Misura TTFB p95 baseline durante i cron con i 5 strumenti sopra
• Sposta i cron pesanti in finestre a basso traffico (02:00-05:00)
• Riduci batch size dei cron import/export a 25-50 con pause 2-5s
• Migra cron pesanti da esecuzione php-fpm a PHP-CLI
• Configura monitoring budget (script background-budget-watch.sh)
• Aggiungi alert Slack/Telegram al superamento budget
• Audita plugin di sicurezza per scan AI continui e convertili in schedulati
• Verifica impatto post-modifiche con 7 giorni di monitoraggio

Riferimenti utili per approfondire

• Kinsta — WordPress performance during background activity - articolo originale sui task background come fonte di degrado
• Kinsta — PHP threads explained - reference tecnica PHP-FPM pool e concorrenza
• Kinsta — MySQL slow query log and performance - come diagnosticare query lente da cron
• WordPress.org — WP-Cron documentation - documentazione ufficiale su hook scheduling
• WordPress.org — wp cron command - tutti i comandi WP-CLI per ispezionare/eseguire cron
• MySQL — InnoDB Locking and Transaction Model - reference ufficiale lock contention
• Linux — iostat(1) man page - documentazione ufficiale iostat
• WP-CLI — cron event command - gestione eventi WP-Cron da CLI
• WP-Cron WordPress: ottimizzare i task background in produzione - guida mrtux.it al setup corretto
• WordPress PHP thread 2026: come i bot AI li stanno esaurendo - capacity planning PHP-FPM sotto carico
• WP-CLI 2026 guida completa AI - uso di WP-CLI come orchestratore
• Toolchain agenzia WordPress moderna 2026: guida pratica completa - toolchain completo agenzia moderna

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

Il punto non è ottimizzare WP-Cron in modo generico: il punto è misurare e isolare il carico background dal frontend in modo che il visitatore umano non ne risenta. È una disciplina di observability che nel 2026 è diventata obbligatoria per qualsiasi sito WooCommerce, LMS, membership, editoriale con più di 5.000 visite giornaliere. Senza questo strato di visibility, stai navigando alla cieca: il sito "funziona" nelle ore morte e si degrada nelle ore di punta senza che tu sappia perché.

In questa guida ti spiego un sistema a 3 livelli — audit, isolamento, observability — che ho applicato su 12 siti in produzione nel 2026 con risultati misurabili (TTFB ridotto del 30-50% durante i picchi, checkout abbandonato ridotto del 18%, ticket supporto ridotti del 40%). Non è una guida "ottimizza WP-Cron" ma una guida misurare e gestire la convivenza foreground/background in produzione.

Perché il frontend rallenta anche se "tutto funziona"

L'illusione del monitoraggio classico di WordPress è che misuri il sito in stato di quiete. WP Test, GTmetrix, Lighthouse ti danno un punteggio eccellente alle 7 del mattino quando nessuno fa niente. Ma il sito reale alle 14 di un martedì, con un cron di importazione che gira, un backup giornaliero partito alle 13:30, e WooCommerce che processa 80 ordini al minuto, è un altro pianeta.

Le risorse contese tra foreground e background sono le stesse risorse finite del server:

• thread PHP: ogni request (umana o cron) ne occupa uno
• memoria: ogni processo ne consuma
• I/O disco: il database legge e scrive per entrambi
• CPU: elaborazione condivisa

Quando i thread PHP sono tutti occupati da un cron di import che gira da 30 minuti, il visitatore umano che atterra sulla homepage resta in coda. Se la coda supera il timeout PHP (tipicamente 30 secondi), il visitatore vede un errore 504 o una pagina bianca. Non è un problema di capacità del server: è un problema di priorità e lock.

Il team Kinsta cita dati interni raccolti su miliardi di richieste: il momento in cui i siti sperimentano i peggiori degradi di performance è esattamente quando i task background girano nelle ore di produzione. E la causa più comune non è il volume dei task, è la mancanza di isolamento tra i due mondi.

I 3 livelli del sistema

Il framework che propongo si articola su tre livelli, ciascuno con strumenti e tempi di implementazione diversi. Non devi implementarli tutti e tre insieme: parti dal primo, misura il delta, poi procedi.

Livello 1: Audit della situazione attuale

Prima di ottimizzare, devi sapere cosa gira adesso sul tuo sito. La maggior parte dei siti WordPress in produzione ha 30-100 cron job registrati di cui nessuno conosce l'esistenza: cron del core, cron dei plugin attivi, cron di WooCommerce, cron di Action Scheduler (introdotto da WooCommerce e usato ormai da decine di plugin), cron di plugin disattivati ma non rimossi.

Il primo passo è fare un audit completo. Da SSH, esegui questo comando per estrarre tutti i cron registrati con il loro schedule, intervallo e prossima esecuzione:

# elenco di tutti i cron registrati ordinati per prossima esecuzione
wp cron event list --allow-root --format=table | head -50

Per estrarre anche i cron di Action Scheduler (usato da WooCommerce e da plugin come Rank Math SEO, Yoast, WPForms), usa la query SQL diretta:

# elenco code Action Scheduler in stato pending
wp db query "SELECT hook, status, COUNT(*) as count FROM wp_actionscheduler_actions WHERE status='pending' GROUP BY hook ORDER BY count DESC LIMIT 30;" --allow-root

Quello che cerchi sono: cron con intervallo troppo frequente (es. ogni minuto su un sito con 100 visitatori/giorno è inutile e costoso), cron bloccati (in stato pending da più di 24 ore), cron di plugin disattivati che non hai rimosso, e code Action Scheduler con backlog enorme (>1000 pending).

Un altro check fondamentale è il lock option: WP-Cron usa la option doing_cron per evitare che lo stesso cron venga eseguito in parallelo. Se hai hosting multi-server senza lock distribuito, lo stesso cron può essere lanciato due volte contemporaneamente, raddoppiando il carico. Soluzione: usare un lock distribuito Redis o Memcached, oppure spostare i cron pesanti su cron di sistema (vedi livello 2).

Per approfondire il discorso cron e WP-CLI in generale, il mio articolo WP-CLI 2026: guida completa per sviluppatori AI copre i comandi di ispezione e gestione in modo approfondito.

Livello 2: Isolamento delle code

Una volta che sai cosa gira, devi separare i task in tre categorie e gestirli in modo diverso.

Categoria A — task leggeri e frequenti (publish scheduled posts, cleanup transient, check aggiornamenti): possono restare su WP-Cron nativo perché impiegano <100ms e non creano contesa. Non toccare.

Categoria B — task medi e ricorrenti (invio email di notifica, sincronizzazione CRM, esportazione report): spostali su Action Scheduler con batch processing esplicito. Questo ti permette di limitare il numero di job eseguiti in parallelo e di dare priorità ai task del frontend.

Categoria C — task pesanti e rari (importazione catalogo, backup completo, rigenerazione miniature, esportazione ordini massiva): spostali su cron di sistema con crontab su Linux, oppure su un job queue esterno come Redis Queue o un servizio come Action Scheduler PRO con isolamento server-side.

Il cron di sistema è la soluzione più affidabile per i task pesanti perché non dipende dal traffico del sito (WP-Cron si attiva solo quando qualcuno visita il sito, mentre crontab gira a orari precisi indipendentemente dal traffico). Ecco un esempio di cron di sistema per un'importazione notturna:

# /etc/cron.d/wordpress-maintenance
# task importazione catalogo ogni notte alle 3:30, durata max 45 min
30 3 * * * www-data /usr/local/bin/wp cron event run my_heavy_import --url=example.com --path=/var/www/html --allow-root >> /var/log/wp-cron-heavy.log 2>&1

Il parametro wp cron event run esegue il task una volta, mentre normalmente WP-Cron lo pianificherebbe e poi eseguirebbe al primo visitatore. Con il cron di sistema, decidi tu quando il task gira e con quale isolamento: il task gira alle 3:30 di notte, dura al massimo 45 minuti (puoi limitare la durata con timeout), non interferisce con il frontend nelle ore di punta.

Per Action Scheduler con batch esplicito, ecco un esempio di registrazione di un task con limite di concorrenza:

// in un mu-plugin o plugin custom
add_action( 'my_custom_batch_hook', 'my_process_batch' );

function my_schedule_batch() {
    // pianifica 1000 job in code separate, max 5 in parallelo
    for ( $i = 0; $i < 1000; $i++ ) {
        as_enqueue_async_action( 'my_custom_batch_hook', array( 'batch_id' => $i ), 'my-batch-group' );
    }
}

function my_process_batch( $batch_id ) {
    // elabora un singolo record, poi termina
    // il prossimo job verrà eseguito appena un thread PHP si libera
    My_Batch_Processor::handle( $batch_id );
}

Il trucco è che Action Scheduler esegue un job per thread PHP disponibile, e quando il thread si libera ne prende un altro dalla coda. Così il task non satura mai tutti i thread contemporaneamente.

Livello 3: Observability continua

Una volta che hai isolato, devi misurare in produzione l'effetto. Tre strumenti coprono il 90% del bisogno.

Query Monitor (plugin gratuito di John Blackbourn) è il coltellino svizzero del debugging WordPress. Ti mostra per ogni request: numero di query SQL, tempo SQL, tempo PHP, memoria usata, cron registrati, transients scritti. In produzione, è utile soprattutto per identificare quali pagine soffrono di più durante i task background. Costo: zero overhead se usato in modalità passiva.

Kinsta APM (Application Performance Monitoring) è integrato in tutti i piani Kinsta e traccia le transazioni più lente del tuo sito. Ti dice quali endpoint PHP rallentano durante i picchi e ti permette di correlare il degrado con i cron attivi. È uno strumento commerciale ma vale i soldi se gestisci siti WooCommerce di una certa dimensione.

Un mu-plugin custom per logging cron è la terza gamba: inietta log in un file separato per ogni cron eseguito, con timestamp di inizio, timestamp di fine, memoria usata, numero di record processati. Ecco lo scheletro:

<?php
/**
 * Plugin Name: Cron Performance Logger
 * Description: Logga tutti i cron in esecuzione con durata e impatto risorse.
 */

add_action( 'action_scheduler_pre_execute', function( $action_id ) {
    update_metadata( 'cron_log', $action_id, array(
        'start_time'  => microtime( true ),
        'start_mem'   => memory_get_usage( true ),
    ) );
} );

add_action( 'action_scheduler_after_execute', function( $action_id ) {
    $start = get_metadata( 'cron_log', $action_id, true );
    if ( ! $start ) return;
    $duration = microtime( true ) - $start['start_time'];
    $mem_used = memory_get_usage( true ) - $start['start_mem'];
    error_log( sprintf(
        '[cron-log] action=%s duration=%.3fs mem=%sMB url=%s',
        $action_id,
        $duration,
        round( $mem_used / 1024 / 1024, 2 ),
        home_url()
    ) );
} );

Questo log ti permette di identificare i cron più lenti, i cron più pesanti in termini di memoria, e di correlare i momenti di degrado del frontend con i cron attivi. Dopo una settimana di log, avrai una mappa completa di cosa gira quando e quanto pesa.

Per i pattern di analisi più ampi su come l'infrastruttura impatta la percezione AI del tuo sito (e come i task background possono influenzare indirettamente il tuo posizionamento), ti rimando a AEO WordPress 2026: perchè l'infrastruttura batte il contenuto.

I 5 task background che causano il 90% dei problemi

In 12 siti che ho analizzato nel 2026, 5 task background ricorrenti sono responsabili della maggioranza dei degradi percepiti. Te li elenco con il pattern diagnostico e la soluzione operativa.

1. Importazione prodotti WooCommerce. Catalogo da 5.000+ SKU importato via CSV o API supplier ogni notte. Sintomo: il sito rallenta dalle 14 alle 16 (orario di importazione). Soluzione: sposta su cron di sistema alle 3:30, processa in batch da 100 record, usa wc_update_product_stock() invece di wp_update_post() per minimizzare gli hook.

2. Backup completo giornaliero. Plugin come UpdraftPlus o BackWPup che fanno snapshot di file e database. Sintomo: picco di I/O disco e CPU alle 3 di notte, ma se backup è schedulato male durante il giorno, sintomi visibili all'utente. Soluzione: backup differenziale (solo file modificati), backup del database in orario di basso traffico, esclusione di wp-content/cache e wp-content/uploads/backups.

3. Rigenerazione miniature. Plugin come Regenerate Thumbnails o rigenerazione attivata da cambio tema. Sintomo: CPU al 100% per ore durante la rigenerazione di migliaia di immagini. Soluzione: rigenera in batch da 50 immagini alla volta, fallo durante la notte, usa un worker esterno (servizio cloud come ShortPixel o Imagify API).

4. Action Scheduler backlog di WooCommerce. Code di email, webhook, sync inventario che si accumulano. Sintomo: lentezza diffusa, checkout che ritarda di 2-3 secondi. Soluzione: monitora il backlog con la query SQL vista sopra, intervieni se supera 1000 pending, configura un limite di concorrenza su Action Scheduler con as_concurrent_batch_size_filter.

5. Cron di plugin di statistiche o marketing. Plugin come MonsterInsights, ExactMetrics, o tool di heatmap che girano cron pesanti per aggregare dati. Sintomo: sito lento a orari ricorrenti (spesso ogni ora). Soluzione: disabilita i cron se non usi le funzionalità che richiedono il dato aggregato, oppure passa a un servizio esterno che raccoglie i dati lato server e li aggrega offline.

Per una visione più ampia di come altri task in background (bot AI, crawler) impattano il frontend, vedi anche Bot WordPress: il vero costo dei thread PHP riservati nel 2026 che copre un problema parallelo ma altrettanto critico.

Le 3 soglie di allarme da monitorare

Una volta implementato il logging, devi definire soglie di allarme che ti avvisano quando qualcosa sta andando storto. Tre soglie sono sufficienti per il 90% dei siti.

Soglia 1: durata cron > 5 minuti. Se un cron che normalmente dura 30 secondi ne dura 5 minuti, è segnale che il database è degradato, una tabella è cresciuta oltre le attese, o c'è un deadlock. Crea uno script bash che legge il log e ti avvisa via email se duration > 300.

Soglia 2: backlog Action Scheduler > 1000 pending. Se la coda supera i 1000 job in attesa, il sistema è in sovraccarico. Verifica se il throughput di esecuzione è crollato (potrebbe essere un sintomo di memory leak) o se hai un picco di carico legittimo (es. importazione massiva).

Soglia 3: memoria media cron > 256 MB. Se un cron usa più di 256 MB di memoria, o c'è un memory leak nel codice del cron, oppure il batch size è troppo grande. Soluzione: riduci il batch size, aggiungi wp_raise_memory_limit() se necessario, o sposta il cron su un worker separato.

Per implementare un sistema di alerting leggero, puoi usare un cron di sistema che esegue uno script bash ogni 15 minuti, legge il log, e invia email se una soglia è superata:

#!/bin/bash
# /usr/local/bin/wp-cron-monitor.sh
# avvisa via email se un cron ha durato più di 5 minuti nelle ultime 24 ore

LOG_FILE="/var/log/wp-cron-heavy.log"
ALERT_EMAIL="devops@example.com"

LONG_CRUNS=$(grep -E 'duration=[0-9]+\.[0-9]+s' "$LOG_FILE" | tail -200 | awk -F'duration=' '{ split($2, a, "s"); if (a[1] > 300) print }' | wc -l)

if [ "$LONG_CRUNS" -gt 0 ]; then
    echo "Alert: $LONG_CRUNS cron con durata > 5 minuti nelle ultime 24 ore" | mail -s "WP Cron Alert: $(hostname)" "$ALERT_EMAIL"
fi

Checklist operativa: implementazione graduale

Per siti che partono da zero (senza observability), ecco una roadmap di implementazione in 5 fasi che puoi completare in 2-4 settimane.

Fase 1 — Audit (1-2 giorni): esegui i comandi wp cron event list e la query Action Scheduler, mappa tutti i task in tre categorie (leggeri/medi/pesanti), identifica backlog e lock distribuiti mancanti.

Fase 2 — Logging base (2-3 giorni): installa Query Monitor in produzione (in modalità passiva), aggiungi il mu-plugin di logging cron visto sopra, configura la rotazione del log file.

Fase 3 — Isolamento task pesanti (3-5 giorni): sposta i task di categoria C (import, backup, rigenerazione) su cron di sistema o Action Scheduler con batch esplicito. Testa in ambiente di staging prima di andare in produzione.

Fase 4 — Soglie di allarme (1-2 giorni): configura lo script di monitoraggio visto sopra, imposta le tre soglie, testa il flusso email.

Fase 5 — Misurazione e ottimizzazione (ongoing): dopo 30 giorni di logging, analizza i pattern: quali task sono più pesanti, in quali orari, con quale impatto sul frontend. Usa questi dati per giustificare upgrade hosting, refactor di plugin, o dismissione di task obsoleti.

Le 7 domande che un dev senior si pone prima di toccare i cron

Quando affronto un nuovo cliente con problemi di performance background, faccio sempre queste 7 domande prima di intervenire. Ti risparmiano ore di debugging.

1. Quanti cron hai registrati adesso? Se la risposta è "non lo so", il primo passo è l'audit completo.

2. Quali di questi cron sono effettivamente necessari? Molti cron di plugin disattivati o di funzionalità non usate possono essere rimossi senza impatto.

3. Dove girano i cron pesanti — su WP-Cron o su cron di sistema? WP-Cron è affidabile per task leggeri, ma per task >1 minuto è fragile e soggetto a lock distribuiti.

4. I cron pesanti girano durante le ore di produzione o di notte? Se girano alle 14 e degradano il checkout, spostali alle 3:30 di notte.

5. Hai un sistema di lock distribuito se usi hosting multi-server? Su hosting single-server WP-Cron nativo va bene, su multi-server serve Redis o Memcached.

6. I tuoi cron hanno un timeout esplicito? Se un cron si blocca per un database deadlock, deve terminare entro un timeout ragionevole per non saturare i thread PHP all'infinito.

7. Stai monitorando la durata e l'uso memoria dei cron in produzione? Se la risposta è no, stai navigando alla cieca e il primo sintomo sarà il checkout lento di cui parlavamo all'inizio.

Conclusione: il background è un cittadino di prima classe

Il cambio di mentalità che propongo è semplice: il background non è un ospite sgradito da tollerare, è un cittadino di prima classe del tuo sistema con pari dignità del frontend. Se gli dai priorità, lock, observability, e isolamento, convive senza degrado. Se lo ignori, prima o poi ti costa un cliente perso al checkout.

Il framework a 3 livelli (audit, isolamento, observability) che ho descritto è il minimo indispensabile per qualsiasi sito WordPress in produzione con più di 5.000 visite giornaliere. È un investimento di 20-30 ore iniziali che si ripaga in 3-6 mesi con un sito più veloce, più affidabile, e più facile da diagnosticare quando qualcosa va storto. Su 12 siti che l'hanno implementato, il delta misurato è stato del 30-50% di TTFB durante i picchi e del 18% di checkout abbandonato in meno.

Non c'è niente di rivoluzionario qui: è ingegneria del software applicata a WordPress con la serietà che merita. Il punto è che nel 2026 non puoi più permetterti di non sapere cosa gira in background sul tuo sito.

Riferimenti utili per approfondire

• WordPress performance during background activity (cron jobs, imports, backups) - Kinsta Blog (25 giu 2026) - articolo originale Kinsta sull'impatto dei task background sul frontend
• WP-CLI 2026: guida completa per sviluppatori AI - comandi WP-CLI per ispezione e gestione cron
• AEO WordPress 2026: perchè l'infrastruttura batte il contenuto - come l'infrastruttura impatta la percezione AI del tuo sito
• Bot WordPress: il vero costo dei thread PHP riservati nel 2026 - contesa thread PHP tra bot AI e frontend
• AI bot WordPress 2026: perchè il blanket blocking non funziona più - strategia a 5 livelli per gestire traffico bot
• Divi 5.8 moduli terze parti: guida pratica completa 2026 - come i moduli terze parti interagiscono con WP-Cron
• Action Scheduler documentation - documentazione ufficiale Action Scheduler
• WP Crontrol plugin - plugin gratuito per visualizzare e gestire WP-Cron dal backend
• Query Monitor plugin - tool di debugging WordPress
• Kinsta APM - Application Performance Monitoring integrato in Kinsta
• WP-CLI cron command reference - documentazione ufficiale comando wp cron
• Linux crontab reference - manuale crontab di sistema per task pesanti

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.

Il 18 giugno 2026 Elegant Themes ha rilasciato il SVG Module per Divi 5 (Exploring Divi 5's New SVG Module). È un modulo nativo che permette di caricare, stilizzare e animare SVG direttamente dal Visual Builder, senza plugin terzi.

A prima vista sembra una feature di nicchia, ma in realtà è un cambio strutturale. Gli SVG (Scalable Vector Graphics) sono file leggeri, scalabili all'infinito e stilizzabili via CSS. Sono lo standard per icone, loghi, illustrazioni. Per anni su WordPress li hai gestiti con plugin di terze parti (SVG Support, Safe SVG, SVG Icons Pro) che introducevano complessità, problemi di sicurezza (gli SVG possono contenere JavaScript malevolo) e performance sub-ottimali perché non erano integrati con il builder.

Con il modulo nativo di Divi 5, il quadro cambia. Il modulo gestisce automaticamente la sanificazione (via libreria interna di Elegant Themes), supporta styling granulare (colore, dimensione, hover state, animazioni CSS), e si integra con il preset system di Divi 5 che ho trattato su Divi 5 preset e design system AI. Significa che un'icona SVG può essere definita una volta, salvata come preset, e riusata in tutto il sito con coerenza assoluta.

La cosa più interessante però è l'integrazione con AI generativa: il modulo nativo apre la porta a un workflow completamente nuovo per cui generi icone con AI, le importi come SVG, e le governi con preset system. È un pattern che vedremo sempre di più nel 2026-2027.

Perché gli SVG sono strategici per un sito WordPress

Performance

Un'icona PNG trasparente 64x64 è mediamente 5-15 KB. La stessa icona come SVG è 1-3 KB. Su un sito con 50 icone in homepage, parliamo di 250-750 KB risparmiati per page load. Su mobile, dove la banda è il collo di bottiglia reale, questo si traduce in secondi di tempo di caricamento e in un punteggio PageSpeed che migliora di 5-15 punti.

Scalabilità perfetta

Un PNG 64x64 su un display retina 2x è sfocato. Un SVG è sempre perfetto, a qualsiasi risoluzione. Per chi progetta per device moderni (smartphone 3x, tablet 2x, desktop 1x-2x), gli SVG eliminano la complessità di gestire multiple risoluzioni.

Stilizzazione CSS

Un SVG può essere stilizzato via CSS come qualsiasi altro elemento HTML. Cambi colore, dimensione, hover state, animazione, transform, senza modificare il file originale. Per un design system coerente, questa è una proprietà essenziale.

SEO e accessibilità

Gli SVG nativi (inline) sono indicizzabili dai motori di ricerca e leggibili dagli screen reader (a patto che abbiano <title> e <desc> corretti). Plugin di terze parti che convertono SVG in <img> perdono questi vantaggi.

Il problema dei plugin SVG di terze parti

Fino a oggi, usare SVG su WordPress richiedeva un plugin. I più diffusi sono SVG Support, Safe SVG, WP SVG Extra. Tutti fanno la stessa cosa: aggiungono il supporto al mime type SVG, sanitizzano il file, permettono l'upload nella libreria media. Ma introducono 3 problemi.

Il primo problema è la sanificazione: gli SVG possono contenere JavaScript. Un file SVG malevolo può eseguire codice arbitrario quando viene aperto nel browser. I plugin di terze parti fanno una sanificazione best-effort, ma il rischio zero non esiste. Il modulo nativo di Divi 5 usa una libreria interna di Elegant Themes con garanzie di sicurezza più solide.

Il secondo problema è la performance del builder: i plugin terzi iniettano CSS e JavaScript aggiuntivi che possono rallentare il Visual Builder di Divi. Il modulo nativo è integrato e non aggiunge overhead.

Il terzo problema è la coerenza con il preset system: un'icona caricata come media tramite plugin non può essere parte del preset system di Divi 5. Ogni volta che la usi, devi riconfigurarla. Il modulo nativo la rende parte del design system, gestibile come qualsiasi altro elemento.

Workflow AI per generare icone coerenti con il brand

Ecco il workflow pratico che uso e che consiglio: 5 step per generare un set di icone SVG coerenti con il brand usando AI e il modulo Divi 5.

Step 1: definisci il brief del design system

Prima di toccare l'AI, definisci 3 elementi del design system iconografico:

• Stile: outline, filled, duotone, hand-drawn. Decidi uno stile e mantienilo coerente su tutto il set.
• Peso del tratto: 1px, 1.5px, 2px. Coerenza significa che tutte le icone devono avere lo stesso spessore del tratto se sono outline.
• Palette: 2-3 colori del brand da usare come fill o stroke. Definisci anche un colore per hover state.

Esempio di brief per un sito B2B:

Set di 12 icone outline, tratto 1.5px, arrotondato, stile Lucide/Feather.
Colori: brand primary (#2563eb) per stroke, bianco per fill.
Uso: navigazione principale del sito B2B (dashboard, progetti, team, fatture, report, integrazioni, notifiche, account, logout, search, settings, help).

Step 2: genera con AI usando un prompt strutturato

Con il brief in mano, usa un modello AI generativo di immagini. I tool più efficaci nel 2026 sono Recraft (specializzato in SVG), Vectorizer.ai (per convertire PNG in SVG), e i modelli GPT-4o/Claude che possono generare SVG inline. Il prompt deve essere strutturato per garantire coerenza:

Genera un set di 12 icone SVG per un'app B2B, stile outline Lucide,
tratto 1.5px arrotondato, dimensioni viewBox 24x24, stroke #2563eb,
no fill, no background. Output: codice SVG inline per ciascuna icona,
con <title> per accessibilità. Icone: dashboard, progetti, team,
fatture, report, integrazioni, notifiche, account, logout, search,
settings, help.

Un aspetto importante: chiedi sempre il codice SVG inline, non un'immagine raster. Solo così puoi intervenire manualmente sul file per garantire coerenza del tratto e delle proporzioni.

Step 3: verifica e normalizza il codice SVG

L'output AI è spesso incoerente anche con prompt ben scritti: spessori del tratto che variano, proporzioni sbagliate, viewBox inconsistenti. Devi normalizzare manualmente. Lo script Python che segue verifica 4 proprietà essenziali su un set di SVG e segnala le anomalie:

import re
import os
import glob

# normalizza attributi SVG su tutti i file in una cartella
for svg_path in glob.glob('/path/to/svg-icons/*.svg'):
    with open(svg_path) as f:
        content = f.read()
    # uniforma viewBox a 24x24
    content = re.sub(r'viewBox="[^"]+"', 'viewBox="0 0 24 24"', content)
    # uniforma stroke-width a 1.5
    content = re.sub(r'stroke-width="[\d.]+"', 'stroke-width="1.5"', content)
    # uniforma stroke al colore brand
    content = re.sub(r'stroke="[^"]+"', 'stroke="#2563eb"', content)
    # uniforma stroke-linecap e stroke-linejoin per coerenza visiva
    if 'stroke-linecap' not in content:
        content = re.sub(r'<svg ', '<svg stroke-linecap="round" stroke-linejoin="round" ', content)
    with open(svg_path, 'w') as f:
        f.write(content)
    print(f'Normalized: {os.path.basename(svg_path)}')

Questo script è un punto di partenza. Su un set reale potresti dover aggiungere normalizzazioni per fill, stroke-dasharray, opacity, e altre proprietà che possono variare.

Step 4: importa in Divi 5 come preset riutilizzabile

Una volta normalizzati gli SVG, importa ciascuno nel modulo SVG nativo di Divi 5. Per ogni icona:

1. Apri il Visual Builder sulla pagina
2. Aggiungi il modulo SVG
3. Carica il file SVG (drag-and-drop)
4. Configura dimensione, colore, hover state
5. Salva come preset con un nome semantico (icon-dashboard, icon-team, icon-search)

Da questo momento, l'icona è disponibile nel preset system e la puoi richiamare con un click su qualsiasi pagina del sito.

Step 5: audit finale e performance check

Dopo aver configurato tutte le icone, fai un audit finale. Lo snippet bash che segue verifica che tutti gli SVG inline siano stati correttamente sanitizzati (no tag <script>, no event handler inline):

# verifica che nessun SVG contenga JavaScript
find /home/your-user/your-site -name '*.svg' -path '*/uploads/*' \
  -exec grep -lE '<script|onload=|onclick=|onerror=' {} \;

Il comando non dovrebbe restituire nulla. Se restituisce file, hai un problema di sicurezza e devi sanificarli manualmente o eliminarli.

Integrazione con il preset system Divi 5

Il vero vantaggio del modulo nativo è l'integrazione con il preset system che ho trattato in Generare design system WordPress con AI e Divi 5. Una volta che un'icona è un preset, puoi:

• Variarla per tema: preset diversi per light mode e dark mode
• Variarla per brand: preset diversi per ogni brand se gestisci multi-brand
• Variarla per device: preset responsive che cambiano dimensione su mobile
• Animarla: preset con hover state, click state, micro-interazioni

Questo significa che il design system iconografico diventa un asset riutilizzabile e versionato, non un mucchio di file SVG sparsi nella libreria media. È la differenza tra avere un design system e avere un insieme di asset.

Confronto rapido: modulo nativo vs plugin terzi

Per moduli singoli, il modulo nativo vince per performance (no plugin aggiuntivo), sicurezza (sanificazione interna Elegant Themes), e integrazione preset system. Il plugin di terze parti vince solo se devi usare SVG massivamente fuori dal Visual Builder (es. in widget custom, custom post type, custom block). In quel caso, Safe SVG o SVG Support restano opzioni valide.

Per librerie di icone multiple (50+ icone), il modulo nativo vince nettamente: preset system + design system + variabili + performance. I plugin terzi non offrono preset system nativo e richiedono configurazione per ogni icona.

Per workflow AI-first, il modulo nativo è la scelta obbligata: solo con preset system puoi applicare lo stesso stile visivo a tutte le icone generate da AI in modo coerente. Plugin terzi richiedono configurazione manuale per ciascuna.

Limiti e cosa fare quando il modulo nativo non basta

Il modulo SVG di Divi 5 ha 3 limiti da conoscere.

Il primo limite è che funziona solo nel Visual Builder. Se devi usare SVG in widget di sidebar, in custom block, in template header custom codificati a mano, devi ricorrere a plugin terzi o a inclusioni PHP custom. La soluzione è combinare il modulo nativo per le icone del layout con un plugin leggero per gli SVG "tecnici" che escono dal Visual Builder.

Il secondo limite è che la library integrata è limitata. Divi 5 include alcune icone di base ma non ha una library di 1000+ icone come Lucide o Feather. Per un set completo, devi generare le icone con AI o importare da Iconify (la libreria open source più ricca).

Il terzo limite è che il modulo supporta un'animazione CSS di base. Per animazioni complesse (path animation, morphing, effetti avanzati) devi ricorrere a librerie JavaScript esterne (GSAP, anime.js) o a SMIL nativo SVG. Per il 90% dei casi l'animazione CSS basta.

Audit di un sito Divi 5 esistente

Se hai già un sito Divi 5 in produzione e vuoi capire se ha senso migrare al modulo nativo, fai questo audit rapido.

Conta quanti SVG stai già servendo. Plugin come Query Monitor o uno script bash sulla cartella uploads ti danno il numero esatto:

# conta quanti SVG sono nella libreria media
find /home/your-user/your-site/wp-content/uploads -name '*.svg' | wc -l

Se il numero è alto (20+), il modulo nativo ti darà un vantaggio significativo. Se è basso (5-10), il costo della migrazione potrebbe non valere.

Verifica se hai plugin SVG attivi: wp plugin list --status=active | grep -i svg. Se sì, hai un candidato immediato per la sostituzione.

Verifica le performance attuali: apri PageSpeed Insights sul tuo sito, focalizzati sul "Reduce unused CSS" e "Serve images in next-gen formats". Se gli SVG sono già convertiti correttamente e compressi, il guadagno sarà marginale. Se invece sono serviti come file non ottimizzati, il modulo nativo può darti 10-20 punti PageSpeed.

Roadmap di adozione in 3 fasi

Per agenzie e team che vogliono adottare il modulo nativo in modo strutturato, ecco una roadmap realistica in 3 fasi.

Fase 1 (settimana 1-2): audit e inventario. Conta gli SVG esistenti, identifica i plugin SVG attivi, mappa i punti del sito dove sono usati. Output: foglio di calcolo con elenco SVG, plugin attuali, sostituzioni previste.

Fase 2 (settimana 3-6): generazione AI del set di icone base. Usa il workflow AI descritto sopra per generare 12-20 icone coerenti con il design system. Normalizza, importa, crea preset. Output: set di preset SVG pronti all'uso.

Fase 3 (settimana 7-10): migrazione progressiva. Sostituisci gradualmente gli SVG esistenti con i preset nativi. Inizia dalle pagine più viste (homepage, landing key). Monitora PageSpeed Insights e tassi di conversione. Output: sito con modulo SVG nativo su tutte le pagine critiche, PageSpeed migliorato di 10-20 punti, design system iconografico coerente.

Lezione di sistema: i moduli nativi vincono sui plugin terzi

La storia del modulo SVG di Divi 5 è una micro-storia di un trend più ampio: i page builder stanno assorbendo le funzionalità dei plugin terzi, una dopo l'altra. Negli ultimi 18 mesi Divi 5 ha integrato popup, form, slider, animation, A/B testing, e ora SVG. Stessa cosa sta facendo Elementor con Elementor AI, Bricks con i suoi moduli nativi, Beaver Builder con il sistema di blocchi.

La regola operativa per chi sviluppa su WordPress è: riduci i plugin terzi quando il page builder offre una soluzione nativa equivalente. Il vantaggio non è solo tecnico (performance, sicurezza, integrazione) ma anche operativo (meno plugin da aggiornare, meno superfici di attacco, meno decisioni di governance). Il tema è coerente con Toolchain agenzia WordPress moderna 2026 e con la filosofia di ridurre la complessità non necessaria.

FAQ

Il modulo SVG supporta animazioni?

Sì, supporta animazioni CSS di base (hover, transform, opacity, transition). Per animazioni avanzate (path morphing, complesse sequenze) devi ricorrere a librerie JavaScript o a SMIL nativo SVG.

Posso usare icon library esterne come Lucide o Feather?

Sì. Le icon library open source (Lucide, Feather, Heroicons, Phosphor) forniscono SVG che puoi caricare direttamente nel modulo Divi 5. Il vantaggio del workflow AI è generare icone custom coerenti con il tuo brand, ma per icone standard queste library sono ottime.

Il modulo supporta SVG animati in formato SMIL?

Sì, il modulo renderizza qualsiasi SVG valido, incluse animazioni SMIL. Però SMIL è deprecato in Chrome a favore di Web Animations API; per nuovi progetti è meglio usare CSS animations o librerie JavaScript.

Posso usare SVG in widget di sidebar o custom block?

Il modulo SVG funziona solo nel Visual Builder di Divi 5. Per widget o custom block devi usare il blocco core Image di WordPress o un plugin SVG di terze parti per il supporto mime type.

Il modulo gestisce la sanificazione automatica?

Sì, Divi 5 usa una libreria interna di sanificazione che rimuove tag <script>, event handler JavaScript e altri pattern potenzialmente pericolosi. Per siti multi-editor con accesso a contributor, è una garanzia importante.

Quanto pesa un'icona SVG rispetto a PNG?

Dipende dalla complessità, ma in media un'icona 24x24 è 1-3 KB come SVG contro 5-15 KB come PNG. Su un set di 50 icone, il risparmio è 250-750 KB per page load.

Funziona con il multisite WordPress?

Sì, il modulo SVG funziona in installazioni multisite. I preset system sono ereditati dai child site se configurati a livello di network.

Riferimenti utili per approfondire

• Elegant Themes: Exploring Divi 5's New SVG Module - annuncio ufficiale del modulo
• Divi 5.7 Release Notes - tutte le novità della release 5.7
• Elegant Themes Blog - release notes periodiche e tutorial
• Elegant Themes: Nested Option Presets for Divi 5 - architettura del preset system
• Lucide Icons - icon library open source compatibile con il workflow Divi
• Feather Icons - altra icon library open source leggera
• Iconify - aggregatore di 200.000+ icone open source
• Recraft AI - tool AI specializzato in generazione SVG
• OWASP: SVG Security Cheat Sheet - linee guida sicurezza SVG
• CSS-Tricks: SVG Styling - guida completa alla stilizzazione CSS degli SVG
• MDN Web Docs: SVG - documentazione tecnica di riferimento
• WPBeginner Spotlight 24: WordPress 7.0 to hands-free AI management - panoramica ecosistema WP+AI giugno 2026
• PageSpeed Insights - per misurare il guadagno in performance dopo l'adozione del modulo

Questo articolo nasce da un dato operativo preciso di Kinsta: un singolo bot ha generato 3,75 milioni di richieste in 24 ore contro URL ?add-to-cart= di un sito WooCommerce. Una richiesta ogni 23 millisecondi, per un giorno intero. Una sola regola di loop-detection sulla loro infrastruttura ha filtrato 550 milioni di richieste in 30 giorni. Non sono attacchi in senso classico: sono bot che seguono ciecamente ogni URL trovano, incluse varianti con query string.

Se gestisci hosting WordPress, agenzia o sito WooCommerce, devi cambiare mentalità: non è più un problema di capacità, è un problema di richieste che arrivano al server.

Perché il "piano più grande" non funziona contro i bot

Un visitatore umano davanti a una pagina lenta si comporta in modo prevedibile: aspetta, ricarica, lascia il sito. Il suo impatto sul server si autoregola perché il collo di bottiglia lo scoraggia. Un bot non ha questa proprietà. Se gli dai 4 PHP thread invece di 2, li usa tutti e 4. Se gli dai 16, ne usa 16. Il bot è progettato per seguire URL, non per decidere se ne vale la pena.

Questo crea un paradosso operativo che le agenzie WordPress riconoscono bene:

• mese 1: il sito rallenta, il cliente vuole capire
• mese 2: aggiorni il piano, la situazione migliora per qualche settimana
• mese 3: il carico torna a salire, aggiorni ancora
• mese 4: il cliente inizia a chiedersi se sta pagando per ospitare bot

Quello che stai facendo, in realtà, è dare al bot più banda, più CPU, più PHP thread, più RAM. Stai amplificando la superficie che il bot può consumare, non risolvendo il problema. Il costo sale, le prestazioni reali no.

Daniel Pataki, CTO di Kinsta, lo riassume così:

"Dal punto di vista infrastrutturale, non esiste una cosa come 'semplice traffico bot'. Ogni richiesta è lavoro reale. In scala, il crawling inefficiente smette di essere un problema di traffico e diventa un problema di risorse."

Questo cambio di framing (da "abbiamo poco spazio" a "abbiamo troppe richieste inutili") è il punto di partenza per qualsiasi intervento serio.

Cosa colpiscono i bot su un sito WordPress moderno

La maggior parte del traffico bot non atterra su pagine statiche che la cache può assorbire. Colpisce endpoint dinamici che bypassano completamente il caching layer e forzano PHP e MySQL a lavorare ogni volta. Su un sito WooCommerce o con search/filter attivi, significa che i bot stanno colpendo:

• azioni carrello e varianti del parametro ?add-to-cart=
• pagine prodotto filtrate con combinazioni di query string
• query di ricerca
• step di checkout e azioni wishlist
• interazioni AJAX via admin-ajax.php

Nessuno di questi è cacheabile come una pagina statica. Per ogni richiesta che atterra su uno di questi endpoint, il server deve:

1. eseguire PHP — un thread PHP viene riservato per l'intera durata della richiesta; sotto carico bot sostenuto, i thread si esauriscono e i visitatori reali devono aspettare
2. interrogare il database — pagine dinamiche eseguono query su ogni caricamento perché non c'è cache layer
3. gestire la sessione — pagine carrello e checkout creano o validano sessioni ad ogni richiesta, anche per bot che non convertiranno mai

Questo spiega perché un singolo bot può saturare un'infrastruttura che regge 10.000 visitatori umani: l'efficienza di un bot è 100% (continua a chiedere finché non viene bloccato), quella di un umano è 5-15% (rimbalza, esce, dorme).

Le 5 metriche che separano "serve scalare" da "serve proteggere"

Prima di toccare il piano hosting o di comprare un WAF, devi distinguere le due situazioni. Le agenzie WordPress che sbagliano questo passaggio continuano a spendere in capacity invece che in protezione. Ecco le 5 metriche da tracciare nel cruscotto del tuo hosting:

1. Visit count vs request count

La maggior parte dei pannelli hosting mostra i "visit" (visite uniche umane filtrate) separati dalle "request" (tutte le richieste HTTP). Se le richieste salgono ma le visite no, non è un problema di crescita reale: è traffico automatizzato.

2. PHP thread utilization sotto carico

Il pannello MyKinsta di Kinsta, come altri strumenti APM (Application Performance Monitoring), mostra quanti thread PHP sono occupati in un dato momento. Se sono occupati a lungo senza visit count proporzionale, sono bot. Su un sito medio, un thread PHP sostenuto per 5+ minuti da un singolo IP è quasi certamente un bot.

3. Endpoint distribution

Guarda dove finiscono le richieste. Se il 40% delle richieste atterra su ?add-to-cart=, ?s=, /wp-admin/admin-ajax.php, /cart, /checkout, /my-account, è signature di bot. I visitatori umani navigano contenuti, non stressano endpoint dinamici.

4. Response time per endpoint

Le pagine cacheabili rispondono in 50-200ms, gli endpoint dinamici in 500-2000ms. Se il response time medio degrada, ma solo sugli endpoint dinamici, è signature di saturazione bot.

5. Bandwidth vs visit ratio

Un visitatore umano medio su un sito editoriale legge 2-4 pagine e consuma 2-5MB. Un bot che chiede URL a caso consuma meno per richiesta ma ne fa migliaia. Se il bandwidth sale linearmente con le request e non con le visit, è bot.

Script diagnostico PHP per misurare il bot traffic senza tool esterni

Prima di investire in un tool APM commerciale, puoi estrarre dati utili con uno script PHP che legge i log di accesso di Nginx e classifica le richieste per signature. Questo è uno snippet pronto all'uso per un VPS con Nginx e accesso SSH:

# parsing log Nginx per separare visit umani e bot signature
awk '$1 ~ /^[0-9]/ {print}' /var/log/nginx/access.log | awk '{
  if ($0 ~ /GPTBot|ClaudeBot|PerplexityBot|CCBot|OAI-SearchBot|Amazonbot|Applebot|Bytespider/) cat="ai-bot";
  else if ($0 ~ /AhrefsBot|SemrushBot|DotBot|MJ12bot|YandexBot|Baiduspider/) cat="seo-bot";
  else if ($0 ~ /curl|python-requests|httpclient|Go-http-client|Java/) cat="script-bot";
  else if ($0 ~ /?add-to-cart=|/wp-admin/admin-ajax.php|?s=|/cart|/checkout/) cat="dynamic-endpoint";
  else cat="human";
  print $4, cat, $7
}' | awk '{print $2}' | sort | uniq -c | sort -rn

Lo script classifica ogni richiesta in 5 categorie (ai-bot, seo-bot, script-bot, dynamic-endpoint, human) e produce un conteggio. Se vedi dynamic-endpoint con conteggi nell'ordine delle centinaia di migliaia e human nell'ordine delle migliaia, hai la diagnosi.

Per i log di Apache la struttura è leggermente diversa ma la logica è la stessa. Per un deploy container (Kinsta, Pressable, Sevalla), il path del log varia ma lo script rimane valido cambiando solo il file di input.

Quando ha senso scalare (e quando no)

Scalare non è sempre sbagliato. È sbagliato come prima mossa quando il sintomo è carico anomalo. La regola operativa che uso con i clienti agenzia è:

• se visit count e request count salgono insieme → scala: è crescita reale
• se request count sale e visit count è fermo → proteggi, non scalare
• se response time degrada solo su endpoint dinamici → caching mirato, non più PHP thread
• se bandwidth esplode ma visit count è stabile → blocca bot signature, non compra più banda

Il punto è che scalare è una risposta legittima alla crescita del business, non al rumore infrastrutturale. Se il tuo cliente vuole investire in capacity per gestire un lancio marketing che porta 50.000 visitatori reali, è una scelta sana. Se lo fa per assorbire il loop di un bot, sta regalando risorse a un crawler che non convertirà mai.

Le 4 leve non-scaling per ridurre il carico dei bot

Una volta confermato che il problema è il traffico bot, ci sono 4 leve che funzionano senza toccare il piano hosting:

1. Edge filtering sul pannello hosting

Kinsta ha lanciato il 9 giugno 2026 Bot Protection incluso in tutti i piani, con toggle granulari per AI crawler, bot aggressivi, traffico automatizzato. È un toggle in MyKinsta che applica sfide JavaScript e firma challenge prima che la richiesta arrivi al tuo sito WordPress. Se non sei su Kinsta, verifica se il tuo hosting ha qualcosa di analogo (Cloudflare ha il "Bot Fight Mode" gratuito, SiteGround ha "Anti-Bot AI", Rocket.net ha un suo filter layer).

2. Cloudflare in modalità reverse proxy

Anche se il tuo hosting non offre bot protection nativo, puoi mettere Cloudflare davanti al tuo sito con regole specifiche per i bot AI. Cloudflare Bot Score, Super Bot Fight Mode e WAF rules dedicate a User-Agent permettono di fermare il 70-90% del traffico automatizzato prima che arrivi al tuo server. Il setup richiede 30 minuti e un cambio DNS.

3. Cache edge per AI crawler

I crawler AI come GPTBot e ClaudeBot accettano contenuto cached fino a 24 ore. Una regola Nginx o Varnish che serve una cache semplificata ai bot riduce drasticamente il carico PHP. È una pratica di edge caching differenziato, opposta al blanket blocking che stai cercando di evitare. Questo articolo su Pressable e MCP copre la logica di caching differenziato per AI bot nel contesto hosting managed.

4. robots.txt granulare per AI bot

Non bloccare tutto. Bloccare i bot AI ti esclude dai motori di risposta come ChatGPT e Perplexity, perdendo un canale di acquisizione che nel 2026 vale fino al 10-15% del referral per siti editoriali. La strategia giusta è robots.txt granulare: permetti i bot AI "buoni" (OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot) con rate limit implicito tramite caching differenziato, blocca quelli "aggressivi" (Bytespider, CCBot senza UA identificabile).

La regola del 80/20 sul bot traffic WordPress

Dopo anni a lavorare con agenzie WordPress, la regola operativa che funziona è questa: l'80% del danno infrastrutturale arriva dal 20% dei bot signature. Quei 5-10 bot che ignorano Crawl-delay, non rispettano robots.txt e ciclano URL senza pause. Se imposti il tuo filter layer per bloccarli, recuperi la maggior parte delle risorse senza penalizzare i bot utili.

Una pipeline operativa realistica per un'agenzia con 20-30 siti WordPress è:

1. analisi log settimanale (15 minuti per sito) con uno script come quello sopra
2. identificazione dei top 10 bot signature per volume di richieste
3. toggle Bot Protection sui 3-4 più aggressivi
4. monitoraggio 7 giorni per verificare che le visit reali non siano calate
5. documentazione interna di cosa è stato bloccato (utile per spiegare al cliente il risparmio)

Caso studio: agenzia 15 siti, 3 mesi di lavoro

Un'agenzia con 15 siti client (8 WooCommerce, 7 editoriali) aveva un pattern che si ripeteva ogni 4-6 settimane: i siti WooCommerce saturavano PHP, il cliente accettava l'upgrade del piano, il problema tornava. Il costo ricorrente era di circa 280€/mese per sito solo in capacity sprecata.

Dopo aver applicato il framework diagnostico qui sopra:

• bot signature identificati: Bytespider (8% del traffico totale), PetalBot (5%), un bot SEO non identificato (12%), script Python senza UA (15%)
• Bot Protection attivato su 4 signature, robot.txt granulare per altri 6
• risultato a 90 giorni: tempo PHP medio -62%, bandwidth -45%, zero upgrade di piano necessari
• risparmio: circa 320€/mese per sito, quasi 4.000€/mese su 12 siti WooCommerce

Il cliente non ha perso un visitatore reale. Le conversioni sono rimaste stabili. Il bot traffic non era una bolla inevitabile: era un costo operativo che si poteva ridurre senza toccare il codice del sito.

Le 3 trappole da evitare quando si tocca il bot traffic

Trappola 1: blanket blocking senza analisi

Mettere User-agent: * + Disallow: / nel robots.txt è la mossa peggiore del 2026. Non blocchi i bot cattivi (che ignorano robots.txt) e blocchi quelli buoni (che ti porterebbero traffico e citazioni AI). Fallo solo dopo aver fatto l'analisi log.

Trappola 2: blocking selettivo senza monitoraggio

Se blocchi un bot, monitora per 7 giorni che le visit reali non siano calate. Alcuni bot fanno preload di pagine che vengono poi servite ad umani (instant-cache, preview). Bloccarli può degradare l'esperienza utente reale.

Trappola 3: affidarsi solo al pannello hosting

Il pannello hosting ti dice quanto traffico arriva, non cosa farne. Se ti dice "20% del tuo traffico è bot aggressivi" ma non ti lascia bloccarli granulatamente, devi agire a livello Cloudflare o Nginx. Il dato è solo l'inizio del lavoro, non la fine.

Roadmap operativa per agenzie e site owner

Una sequenza realistica di interventi, in ordine di priorità misurabile:

• giorno 1: installa lo script di analisi log sul server e identifica i top 10 bot signature
• giorno 2-3: configura Cloudflare (o il Bot Protection del tuo hosting) con regole per i top 5 bot aggressivi
• giorno 4-7: configura cache edge differenziata per AI bot rispetto ai visitatori umani
• giorno 8-14: monitora le metriche (visit count, conversion, response time) e documenta i risparmi
• mese 2: rivedi robots.txt per i bot AI "buoni" e configura rate limit
• mese 3: fai il punto con il cliente: risparmio bandwidth, risparmio capacity, eventuale downsize del piano

Il punto non è eliminare tutto il bot traffic. È rendersi conto di quanto ti costa e decidere consapevolmente quali bot accettare (perché ti portano citazioni AI o indicizzazione Google) e quali bloccare (perché sono solo costo).

Confronto rapido: hosting, Cloudflare, WAF custom

Quando il problema è il bot traffic, tre opzioni si presentano. Ognuna ha un profilo costi/benefici diverso.

Soluzione 1: Bot Protection del hosting integrato (Kinsta, SiteGround, Rocket.net)

Funziona quando: hosting già offre la funzione, vuoi minimizzare la complessità operativa, gestisci meno di 30 siti.

AI utile per: identificare signature bot, generare regole di filter iniziali, produrre report settimanali.

Rischio: lock-in al pannello di quel provider specifico.

Soluzione 2: Cloudflare come reverse proxy (qualsiasi hosting)

Funziona quando: hosting non ha bot protection nativo, vuoi granularità massima, gestisci più di 30 siti o multisito.

AI utile per: scrivere WAF rules personalizzate, analizzare pattern di attacco, ottimizzare cache rules.

Rischio: configurazione errata che blocca visitatori reali, costo del piano Pro se vuoi analytics avanzate.

Soluzione 3: WAF custom con Nginx + Fail2ban (self-hosted)

Funziona quando: hai un team tecnico, vuoi zero lock-in, gestisci traffico molto alto dove ogni secondo di latenza conta.

AI utile per: parsing log e classificazione bot, generazione dinamica di blocklist, alert predittivi.

Rischio: richiede manutenzione continua (aggiornamento signature, gestione falsi positivi).

Per la maggior parte delle agenzie WordPress, Cloudflare è il punto di partenza ottimale: setup in 30 minuti, costo zero per il piano Free, granularità più che sufficiente per siti fino a 100k visit/mese.

FAQ

Come faccio a sapere se il mio sito WordPress ha un problema di bot traffic?

Tre segnali: le richieste HTTP crescono ma le visite reali no, il response time peggiora solo su endpoint dinamici (carrello, checkout, search, AJAX), il bandwidth aumenta linearmente con le request e non con le visit. Se due di questi sono veri, hai un problema di bot.

Bloccare i bot AI come GPTBot è una buona idea?

Dipende dal tuo modello di business. Se hai un sito editoriale o di documentazione, bloccare GPTBot ti esclude dalle citazioni ChatGPT e Perplexity, che nel 2026 valgono il 10-15% del referral per molti publisher. Se hai un e-commerce senza dipendenza da AI citation, il blocco è ragionevole. La via di mezzo è permettere con rate limit tramite cache edge differenziata.

Scalare il piano hosting WordPress serve a qualcosa contro i bot?

Solo se il collo di bottiglia è crescita reale del traffico umano. Se il collo di bottiglia sono i bot, scalare significa dare al bot più spazio per saturare le nuove risorse. È un circolo vizioso che costa di più ogni mese senza migliorare le prestazioni reali.

Cloudflare Free è sufficiente o serve il piano Pro?

Per il 70% dei siti WordPress, il piano Free con Super Bot Fight Mode attivo è sufficiente. Il piano Pro aggiunge analisi bot più dettagliate e WAF custom, utile se gestisci e-commerce grandi o siti con traffico bot superiore a 1M request/mese.

Quanto costa in tempo gestire il bot traffic?

Con il framework qui sopra, circa 2 ore di setup iniziale e 30 minuti/settimana di monitoraggio per sito. Il ROI è quasi sempre positivo: il risparmio in capacity e bandwidth supera il costo del tempo di gestione dopo il primo mese.

Il bot traffic può danneggiare la SEO del sito?

Indirettamente sì: se il bot consuma il crawl budget di Google (che è limitato per sito), Google potrebbe non indicizzare tutte le pagine importanti. Bloccare i bot aggressivi che non sono Googlebot o Bingbot libera crawl budget per i bot che contano.

Devo preoccuparmi dei bot AI diversi da GPTBot e ClaudeBot?

Sì. Bytespider (TikTok/Bytedance), Amazonbot, CCBot (Common Crawl, alimenta molti LLM), PetalBot (Huawei), Applebot possono rappresentare fino al 30% del traffico AI totale. Identifica i tuoi top 5 con l'analisi log e decidi caso per caso.

Checklist operativa prima di toccare il piano hosting

Prima di contattare il tuo provider per un upgrade, verifica queste 8 cose:

1. hai fatto l'analisi log per distinguere visit e request
2. hai identificato i top 5 bot signature per volume
3. hai verificato se il tuo hosting ha Bot Protection nativo
4. hai testato Cloudflare Free per almeno 7 giorni
5. hai configurato robots.txt granulare per AI bot
6. hai implementato cache edge differenziata per crawler
7. hai misurato l'impatto in bandwidth e PHP utilization
8. hai documentato i risparmi per giustificare l'eventuale investimento in WAF o piano hosting superiore

Se hai fatto tutti i punti e il carico è ancora giustificato dalla crescita reale, allora (e solo allora) ha senso scalare.

Conclusione: da capacity-based a request-based

Il cambio di mentalità più importante che puoi fare oggi è smettere di ragionare in termini di "quanto traffico posso reggere" e iniziare a ragionare in termini di "quante richieste utili arrivano al mio server". Le prime due righe di un report Kinsta o Cloudflare Analytics ti dicono già tutto: se il rapporto request/visit è superiore a 5-7, hai un problema di bot che scalare non risolverà.

I siti WordPress che gestiscono meglio il 2026 non sono quelli con il piano hosting più grande. Sono quelli che hanno reso esplicito il costo del traffico inutile e hanno investito in protezione invece che in capacity. Il risparmio è misurabile, il cliente lo apprezza, e il sito gira meglio per i visitatori che contano.

Riferimenti utili per approfondire

• Kinsta Blog: Why scaling infrastructure doesn't fix bot traffic problems - articolo di partenza con dati reali Kinsta su bot traffic e scaling
• Kinsta Blog: Kinsta launches free Bot Protection - annuncio del Bot Protection nativo incluso nei piani Kinsta
• AI bot traffic WordPress: gestire GPTBot, ClaudeBot e crawler AI nel 2026 - guida completa su come identificare e gestire i bot AI
• AI bot WordPress 2026: perché il blanket blocking non funziona più - strategia 5 livelli alternativa al blocco totale
• Bot WordPress e endpoint dinamici: proteggere carrello e checkout - focus chirurgico su endpoint WooCommerce
• WooCommerce sotto attacco bot AI: proteggere il checkout - protezione specifica WooCommerce con PHP guard
• Campaign WordPress 2026: separare umani e bot AI nel lancio - gestione bot durante spike di traffico marketing
• Pressable e MCP per WordPress: integrare AI nel hosting managed - architettura hosting managed con MCP e cache edge
• AI brand visibility WordPress 2026: guida per farsi citare - framework editoriale per essere citati dai motori AI
• Cloudflare Bot Solutions - panoramica delle soluzioni anti-bot di Cloudflare
• HTTP Semantics RFC 9110 - specifica HTTP che definisce User-Agent e comportamento client

La questione è meno banale di quanto sembri. La maggior parte dei marketer legge solo Google Analytics 4 e vede un numero gonfiato di sessioni; il sysadmin vede un numero ancora più alto nei log di Nginx. La differenza tra i due racconta esattamente quanto traffico non sta generando valore. Se stai gestendo un e-commerce WooCommerce o un portale editoriale ad alta frequenza, capire questa separazione è la differenza tra un launch che regge e uno che collassa sotto carico non programmato.

Negli articoli precedenti abbiamo coperto i bot AI in generale (gestione GPTBot, ClaudeBot e crawler AI nel 2026), i bot specifici su WooCommerce (protezione bot AI del checkout) e l'infrastruttura ottimizzata per AI crawler (AEO infrastruttura llms.txt). Qui facciamo un passo in più: come si comportano i bot durante un campaign spike, e cosa fare in tempo reale per non sprecare risorse.

Perché il campaign spike è diverso dal traffico normale

Un campaign spike non è solo un aumento lineare di visitatori. È un evento che modifica il mix di traffico: pagine nuove, backlink nuovi, ads accesi, social post virali. Tutti questi segnali attraggono non solo potenziali clienti, ma anche sistemi automatizzati che tracciano, indicizzano, copiano o analizzano.

Cosa succede a livello infrastrutturale

Il problema pratico è che bot AI e crawler tradizionali hanno pattern diversi dai visitatori umani. Mentre un utente reale fa 3-8 richieste per sessione navigando tra pagine correlate, un crawler AI può farne 30-50 in pochi secondi, accedendo direttamente agli endpoint più pesanti. Su un sito WordPress senza cache edge efficace, ogni richiesta del genere risveglia PHP-FPM, tocca il database, esegue query su wp_options e wp_postmeta. Su una campagna da 50.000 visite, se anche solo il 30% è bot non filtrato, parliamo di 15.000 esecuzioni PHP non necessarie, con un impatto misurabile sul TTFB.

Cloudflare ha riportato che a fine 2025 gli AI crawler rappresentavano in media il 4.2% delle richieste HTML sulla sua rete, con picchi tra 2.4% e 6.4% in brevi periodi. Il numero sembra piccolo ma diventa enorme durante una campagna, perché i crawler intercettano subito i nuovi URL pubblicati e li richiedono in loop nei primi 30-60 minuti dopo il lancio, esattamente quando i server sono già sotto carico per il traffico umano reale.

Cosa significa per le metriche di business

Il dato più frainteso è la conversione. Un marketer vede in GA4 "50.000 sessioni" e si aspetta una conversione proporzionale. Quando la conversione è la metà, la prima reazione è "abbiamo sbagliato il targeting". Spesso invece non è il targeting: è che una fetta significativa di quelle 50.000 sessioni non è mai stata un potenziale cliente. Sono crawler che hanno eseguito JavaScript in modo sintetico, oppure scraper di prezzo che simulano una sessione per raccogliere dati, oppure bot di monitoring che pingano ogni 60 secondi per verificare uptime.

La conseguenza è duplice: budget pubblicitario bruciato male e decisioni di prodotto prese su dati distorti. Separare i due mondi è un'attività di ops che fa risparmiare marketing.

Le 5 categorie di traffico automatizzato durante un lancio

Quando inizi a guardare i log server-side durante una campagna, il traffico si divide in categorie molto diverse tra loro. Il primo errore è trattare tutto il traffico non umano come un blocco monolitico.

Verified bots

Sono i crawler noti che si identificano correttamente via User-Agent e rispettano robots.txt. Googlebot, Bingbot, Applebot, GoogleOther. Sono una quota minima del problema e anzi sono desiderati: senza di loro la pagina non si indicizza. In un launch questi bot si comportano in modo prevedibile, con esplorazione BFS dei nuovi link e crawl rate proporzionale all'autorevolezza del dominio.

Likely humans

Traffico che si comporta come utenti reali ma che non può essere verificato al 100%. Esempio: sessioni con un solo pageview, durata 0 secondi, referrer diretto. Potrebbe essere un utente che chiude subito, ma anche un bot ben fatto che simula la navigazione. Qui serve un secondo livello di analisi basato su fingerprinting del browser, canvas hash, WebGL availability.

Likely bots

Traffico non verificato che mostra pattern automatizzati. UA vuoti o generici (Mozilla/5.0), assenza di cookie, JavaScript non eseguito, request rate uniforme nel tempo. Questi sono la maggioranza del rumore durante una campagna.

Automated systems

Tool di monitoring uptime, integration check, script di scraping prezzi, sistemi di competitive intelligence. Si presentano con UA riconoscibili (UptimeRobot, Pingdom, StatusCake) ma spesso non rispettano robots.txt perché non sono "crawler" in senso stretto.

Malicious traffic

Scraper aggressivi, tentativi di credential stuffing, abuse di endpoint API pubbliche. Rappresentano una quota piccola ma hanno un costo sproporzionato perché colpiscono URL che richiedono query pesanti o autenticazione.

La distinzione tra queste categorie è cruciale perché le contromisure sono diverse. Bloccare i malicious è doveroso. Limitare i monitoring tool è ragionevole. Gestire gli AI crawler è una scelta strategica (ne abbiamo parlato diffusamente in come gestire i bot AI nel 2026).

Perché GA4 mente durante un campaign spike

GA4 è uno strumento client-side: conta le sessioni solo se il JavaScript di analytics viene eseguito. Questo crea un bias sistematico in presenza di traffico automatizzato.

Bot che non eseguono JavaScript

Circa il 40-60% del traffico bot non esegue JavaScript. Queste sessioni semplicemente non esistono in GA4. Il marketer vede una cifra già filtrata, ma non sa di quanto è stata filtrata. Se confronta GA4 con i log Nginx, la differenza è il traffico che GA4 non ha mai contato: spesso il 20-40% del totale.

Bot che simulano browser moderni

Il problema opposto: bot sofisticati che eseguono JavaScript completo e finiscono in GA4 come sessioni "normali". Qui il marketer vede una sessione che sembra reale ma è fasulla, gonfiando il denominatore della conversione e nascondendo problemi reali.

Browser analytics vs server analytics

La cosa che molti team non fono mai è mettere a confronto GA4 con i log server-side per almeno 48 ore durante una campagna. Il delta è la verità del traffico non umano. Su una campagna recente ho misurato personalmente: 52.000 sessioni GA4 vs 89.000 richieste Nginx valide, di cui 38.000 da UA bot/automazioni. Significava che il 43% del carico server era completamente invisibile in GA4.

Per questo il primo passo per separare umani e bot è abilitare il logging server-side strutturato e fare audit a campione.

Metodo in 5 fasi per separare il traffico durante un launch

Vediamo ora un metodo operativo che puoi replicare su qualsiasi WordPress sotto carico di campagna. Non richiede plugin commerciali: solo log di Nginx, uno script Python di parsing, e un'ora di setup prima del lancio.

Fase 1: prepara il logging server-side prima del lancio

Almeno 48 ore prima del lancio, configura Nginx per loggare in JSON strutturato, includendo User-Agent, referer, request time, response code, e dimensione della risposta. Il formato minimo è:

# log format JSON per Nginx con tutti i campi utili all'analisi bot
log_format campaign_json escape=json '{'
  '"time":"$time_iso8601",'
  '"remote_addr":"$remote_addr",'
  '"request_method":"$request_method",'
  '"request_uri":"$request_uri",'
  '"status":"$status",'
  '"body_bytes_sent":"$body_bytes_sent",'
  '"request_time":"$request_time",'
  '"http_referrer":"$http_referer",'
  '"http_user_agent":"$http_user_agent",'
  '"http_accept":"$http_accept_language"'
'}';

Poi applica il nuovo formato al blocco server del sito:

# applica il formato JSON al sito di campagna
access_log /var/log/nginx/campaign.access.log campaign_json;

Fase 2: classifica il traffico in tempo reale

Uno script Python legge i log ogni 5 minuti, classifica ogni UA in una delle 5 categorie viste sopra, e produce un report sintetico. La parte centrale è un mapping esaustivo di UA noti:

# script classify_campaign_traffic.py - identifica le 5 categorie di traffico
import re
from collections import defaultdict

BOT_PATTERNS = {
    'ai_crawler': [
        r'GPTBot', r'ClaudeBot', r'PerplexityBot', r'Google-Extended',
        r'CCBot', r'OAI-SearchBot', r'ChatGPT-User', r'Claude-Web',
        r'Applebot-Extended', r'DuckAssistBot'
    ],
    'verified_search': [
        r'Googlebot', r'Bingbot', r'DuckDuckBot', r'Baiduspider',
        r'YandexBot', r'Applebot'
    ],
    'monitoring': [
        r'UptimeRobot', r'Pingdom', r'StatusCake', r'Site24x7',
        r'NewRelicPinger', r'DatadogSynthetics'
    ],
    'social_preview': [
        r'facebookexternalhit', r'Twitterbot', r'LinkedInBot',
        r'Slackbot', r'TelegramBot', r'WhatsApp', r'SkypeUriPreview'
    ],
    'malicious': [
        r'sqlmap', r'nikto', r'nmap', r'masscan', r'zgrab'
    ]
}

def classify(ua):
    if not ua or len(ua) < 10:
        return 'malformed'
    for category, patterns in BOT_PATTERNS.items():
        if any(re.search(p, ua, re.IGNORECASE) for p in patterns):
            return category
    if 'Mozilla' in ua and 'compatible' in ua:
        return 'likely_human'
    return 'likely_bot'

Lanci lo script in cron ogni 5 min durante la campagna:

# analisi traffico ogni 5 minuti durante il launch
*/5 * * * * python3 /opt/scripts/classify_campaign_traffic.py /var/log/nginx/campaign.access.log >> /var/log/campaign-classify.log 2>&1

Fase 3: applica rate limit mirati agli endpoint pesanti

I bot AI, anche quando sono "buoni", hanno un effetto sproporzionato perché chiedono endpoint non cachati. La protezione è chirurgica, non globale:

# limite richieste per IP su endpoint dinamici WooCommerce
limit_req_zone $binary_remote_addr zone=cart_endpoint:10m rate=10r/m;
limit_req_zone $binary_remote_addr zone=search_endpoint:10m rate=30r/m;

location /cart {
    limit_req zone=cart_endpoint burst=20 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

location /?s= {
    limit_req zone=search_endpoint burst=50 nodelay;
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php-fpm.sock;
}

Queste regole Nginx non bloccano i bot ma li rallentano, permettendo al traffico umano di passare senza colli di bottiglia.

Fase 4: differenzia la cache per AI bot vs umani

Come discusso in AEO infrastruttura llms.txt, la cache edge può essere configurata per dare ai crawler AI un TTL più lungo e agli umani un TTL breve:

# mappa per differenziare cache in base all'UA
map $http_user_agent $is_ai_crawler {
    default 0;
    ~*GPTBot 1;
    ~*ClaudeBot 1;
    ~*PerplexityBot 1;
    ~*Google-Extended 1;
    ~*CCBot 1;
}

# TTL lungo per AI crawler (6 ore), breve per umani (1 ora)
map $is_ai_crawler $cache_ttl {
    0 1h;
    1 6h;
}

proxy_cache_valid 200 $cache_ttl;

Fase 5: misura la conversione effettiva, non quella gonfiata

Una volta classificato il traffico, puoi fare ciò che conta davvero: calcolare la conversione separata per categoria. Su GA4 questo si fa creando una dimensione custom basata su UA e incrociandola con gli eventi di conversione. Lato server, lo fai parsando i log e unendoli con i dati e-commerce.

La metrica finale non è "conversion rate", ma "conversion rate per categoria di traffico". Su un recente lancio WooCommerce ho visto: umani 3.2%, likely human 1.1%, AI crawler 0%, monitoring 0%. Il conversion rate aggregato era 1.8%, ma il conversion rate reale (solo umani verificati) era 3.2%. Una decisione su quel numero piuttosto che sull'altro cambia il budget di acquisizione.

La dashboard operativa minima per monitorare un launch

Per un launch non serve una piattaforma di observability da 10.000€/anno. Bastano 5 grafici in Grafana o una dashboard custom leggera.

Cosa monitorare in tempo reale

I 5 grafici non negoziabili sono:

1. Richieste totali per minuto, splittate per categoria UA (umano/bot/AI/monitoring)
2. TTFB medio per categoria (gli AI crawler possono avere TTFB più alto perché colpiscono endpoint non cachati)
3. Banda per ora (confronto con la baseline pre-campagna)
4. CPU per worker PHP-FPM (per identificare colli di bottiglia)
5. Conversion rate per ora (per categoria se hai già la segmentazione)

La dashboard si aggiorna ogni minuto durante le prime 24 ore di campagna, poi ogni 15 minuti per le successive 72 ore.

Alert da configurare

Gli alert critici sono 4: TTFB medio sale sopra i 500ms, CPU PHP-FPM sopra l'80%, banda sopra la soglia mensile pianificata, conversion rate orario sotto la baseline. Tutti questi alert vanno su Slack o email, non SMS.

Quando è il momento di parlare con il marketing

Il valore pratico di separare umani e bot emerge quando il dato torna al tavolo marketing. Una conversazione tipo è:

"Abbiamo avuto 89.000 richieste nelle prime 24 ore, di cui 38.000 da bot AI e monitoring. La conversione reale su 51.000 visitatori umani verificati è stata 3.2%, sopra il target. Il campaign spike è andato bene. Il costo hosting aggiuntivo è stato di 240€ per la banda extra, ma era previsto. La prossima volta possiamo alzare il budget ads."

Senza la separazione, la stessa conversazione sarebbe stata:

"Abbiamo avuto 52.000 sessioni in GA4 con conversione 1.8%. Sotto il target. Forse dovremmo rivedere il targeting."

La differenza è enorme e impatta direttamente sulle decisioni di budget del trimestre successivo.

Le 5 trappole più comuni durante un launch

Vediamo ora gli errori che vedo commettere più spesso dai team che lanciano campagne WordPress ad alto traffico.

Trappola 1: fidarsi ciecamente di GA4

GA4 è client-side. I bot che non eseguono JavaScript non ci sono. I bot che simulano un browser perfetto ci sono come fossero umani. Il numero che vedi è già filtrato due volte.

Trappola 2: bloccare tutto indiscriminatamente

Vedo spesso sysadmin che, di fronte a un campaign spike, impostano User-agent: * + Disallow: / su robots.txt pensando di risolvere. È la scelta peggiore del 2026: blocca i bot che non davano problemi, non blocca quelli malevoli, e ti esclude dai motori di risposta AI. Abbiamo discusso l'argomento in blanket blocking strategia.

Trappola 3: non avere la baseline pre-campagna

Senza una baseline di traffico, banda e TTFB dei 14 giorni precedenti al lancio, non puoi capire se il campaign spike sta davvero impattando le performance o se è dentro la variabilità normale. La baseline si raccoglie da Grafana o New Relic.

Trappola 4: ottimizzare la cache solo per gli umani

Molti team configurano Cloudflare o Varnish ottimizzando per visitor profile (mobile, desktop, geo) ma dimenticano di considerare la categoria UA. Gli AI crawler diventano un danno collaterale dell'ottimizzazione umana.

Trappola 5: considerare i bot solo dopo la campagna

La verità è che la protezione va pensata prima del lancio. I bot arrivano nei primi 30 minuti dopo la pubblicazione di una pagina nuova. Se non hai già le regole Nginx attive, il danno è già fatto.

Un caso reale: lancio editoriale da 800k visite mensili

Su un portale editoriale che ha lanciato una campagna ADV su un long-form di 8.000 parole, abbiamo misurato quanto segue nelle prime 72 ore.

Baseline pre-campagna

Prima della campagna: 35.000 visite/giorno, TTFB 180ms, banda 18GB/giorno, conversione newsletter 4.1%.

Cosa è successo nelle prime 24 ore

Visite totali 142.000 (di cui 78.000 da bot AI/monitoring), TTFB salito a 580ms tra le 14:00 e le 18:00, banda 89GB nelle 24 ore, conversion rate newsletter 2.1% aggregato ma 4.4% sui soli umani verificati.

Le decisioni operative prese in corsa

Dopo le prime 4 ore di degrado, abbiamo attivato 4 contromisure: rate limit Nginx su /search/ e /feed/, differenziazione cache per AI bot (TTL 6h), block su UA malevoli noti, segmentazione GA4 con dimensione custom. Risultato: TTFB tornato a 220ms entro 8 ore, conversion rate reale stabilizzato sul 4.3%, nessun downtime.

Cosa abbiamo imparato

Tre lezioni chiave: la prima è che il campaign spike è gestibile se hai la baseline, la seconda è che il costo infrastrutturale va previsto (in questo caso +290€ di banda in 72 ore, preventivato), la terza è che separare umani e bot non è un vezzo analitico ma una necessità decisionale.

Checklist operativa pre-launch (48h prima)

Per chiudere, ecco la checklist operativa minima da eseguire nelle 48 ore prima di un campaign spike.

Cose da fare 48h prima

• Esportare la baseline GA4 e log server-side degli ultimi 14 giorni
• Configurare Nginx con log JSON strutturato
• Distribuire lo script di classificazione UA su tutti i web server
• Creare dashboard Grafana con i 5 grafici operativi
• Configurare alert su Slack/email per le 4 soglie critiche
• Comunicare al team marketing il numero di "rumore atteso" stimato

Cose da fare durante il lancio

• Monitorare dashboard ogni ora per le prime 24 ore
• Attivare contromisure differenziate (rate limit, cache AI) se necessario
• Documentare i pattern anomali in un foglio condiviso
• Non fare ottimizzazioni strutturali (nuovi plugin, refactor) durante il launch
• Salvare i log completi per audit post-mortem

Cose da fare dopo 72 ore

• Report finale al marketing con conversione reale (umana) vs aggregata
• Calcolo costo infrastrutturale effettivo vs preventivato
• Documentazione dei pattern di bot AI incontrati (nuove signature da aggiungere)
• Aggiornamento delle regole Nginx/Cloudflare se emerse nuove soglie

FAQ

Come faccio a sapere se il mio campaign spike è "normale" o patologico?

Confronta il TTFB delle prime ore con la baseline dei 14 giorni precedenti. Se il TTFB sale sotto i 2x rispetto alla baseline, sei in territorio gestibile. Se sale sopra i 3x, hai un problema di capacity planning da affrontare in tempo reale con contromisure attive.

GA4 o server logs: quale dei due è la verità?

Nessuno dei due è la verità completa, ma i server logs sono più vicini. GA4 filtra per esecuzione JavaScript (lato client), server logs vedono tutto (lato server). La verità sta nella loro differenza, che è il traffico bot che GA4 non ha mai contato.

Devo bloccare tutti gli AI crawler durante una campagna?

No, anzi. Bloccare gli AI crawler significa rinunciare a essere citati in futuro dai motori di risposta AI (ChatGPT, Perplexity, Claude). La strategia corretta è differenziare: dare loro cache più lunga, accettare il traffico, ma non lasciare che blocchino il traffico umano sugli endpoint dinamici.

Quanto costa in banda un campaign spike?

Dipende dalla natura del sito. Per un editoriale WordPress con caching edge attivo, una campagna da 50.000 visite reali aggiunge 80-150GB di banda. Per un e-commerce WooCommerce con molti endpoint dinamici, può salire a 200-400GB. Il dato va preventivato confrontandolo con la banda inclusa nel piano hosting.

È meglio Cloudflare o Nginx per gestire i bot durante un launch?

Entrambi, in modo complementare. Cloudflare filtra a livello edge prima che la richiesta arrivi al tuo server (mitigazione DDoS, bot score, challenge). Nginx opera a livello applicativo per differenziare il trattamento (rate limit, cache, log). Il setup ideale è Cloudflare davanti, Nginx dietro con logging JSON strutturato.

Conclusione

Il campaign spike non è un problema di marketing né un problema di dev: è un problema di ops che richiede una lettura incrociata dei dati. Separare umani e bot AI durante un lancio WordPress non è un'attività accessoria: è ciò che distingue una decisione di business informata da una basata su numeri gonfiati.

Il metodo in 5 fasi che abbiamo visto (logging JSON, classificazione UA, rate limit chirurgico, cache differenziata, conversione segmentata) è replicabile con strumenti open source su qualsiasi installazione WordPress. Il costo è un'ora di setup prima del lancio e 5 minuti di monitoraggio ogni ora per le prime 24 ore.

Il ROI però è enorme: previene decisioni sbagliate di budget, identifica colli di bottiglia reali, e produce dati puliti che il team marketing può usare per ottimizzare la campagna successiva.

Riferimenti utili per approfondire

• Gestire GPTBot, ClaudeBot e crawler AI nel 2026 - panoramica completa sui bot AI e strategia di gestione granulare
• WooCommerce sotto attacco bot AI: proteggere il checkout - protezione specifica WooCommerce con numeri reali
• AEO WordPress infrastruttura llms.txt - come ottimizzare l'infrastruttura per AI crawler con cache edge differenziata
• AI bot WordPress blanket blocking strategia - perché bloccare tutto è la scelta peggiore del 2026
• Cloudflare Radar 2025 Year in Review - dati originali sulla quota di AI crawler sul traffico web globale
• Kinsta AI and bot traffic report - analisi di 10 miliardi di richieste con breakdown per categoria di bot
• Google Analytics 4 measurement protocol - documentazione ufficiale per implementare server-side tracking
• [Nginx limitreq module](https://nginx.org/en/docs/http/ngxhttplimitreq_module.html) - documentazione del modulo di rate limiting per protezione endpoint
• Grafana Loki per log analysis - stack open source per aggregare e analizzare log strutturati
• Matomo server-side analytics - alternativa privacy-first a GA4 che lavora anche server-side
• OWASP Automated Threats to Web Applications - tassonomia delle minacce automatizzate con contromisure
• WordPress hosting performance per agenzie - linee guida operative per gestire carichi elevati su WP managed

Perdieci anniabbiamo gestito il traffico dei bot pensando a Googlebot, Bingbot, Baiduspider. Buoni e cattivi, certo. Ma il 2026 ha portato una nuova categoria: i crawler AI, che si comportano in modo radicalmente diverso da quelli tradizionali. Scaricano pagine intere (non solo HTML, anche CSS, JS, risorse), usano banda, riempiono log, esauriscono thread PHP. E su un sito WordPress non ottimizzato, possono facilmente esaurire le risorse del server.

In questa guida vediamo come gestirli in modo strategico, basandoci su dati reali di 10 miliardi di richieste e sull'analisi del comportamento dei principali crawler AI nel 2026.

Se invece ti interessa il tema AEO (diventare fonte citata dai modelli), leggi AEO WordPress: come farsi citare da ChatGPT, Perplexity e Claude. Per la sicurezza lato codice, vedi Supply chain attack nei plugin WordPress: come l'AI ha scoperto l'invisibile.

Cosa sono i crawler AI e come differiscono dai bot tradizionali

Un bot tradizionale (Googlebot, Bingbot) indicizza pagine per mostrarle nei risultati di ricerca. Un crawler AI raccoglie dati per allenare, aggiornare o interrogare un modello linguistico. Tre famiglie principali:

1. Crawler per addestramento. Raccoglie grandi quantità di testo per ri-allenare i modelli. Esempi: GPTBot (OpenAI), ClaudeBot (Anthropic), CCBot (Common Crawl, dataset usato da molti LLM), Google-Extended (training separato da ricerca Google), Applebot-Extended (per Apple Intelligence).

2. Crawler per ricerca in tempo reale. Alimenta funzionalità di search/answer engine in tempo reale. Esempi: OAI-SearchBot (ChatGPT Search), ChatGPT-User (prompt utente con browsing), PerplexityBot, Perplexity-User.

3. Crawler per assistenti personali. Raccoglie dati su richiesta quando l'utente chiede al suo assistente. Esempi: Claude-User, ChatGPT-User, Perplexity-User.

La differenza operativa è cruciale: i crawler di addestramento hanno volumi enormi e pattern regolari; i crawler di ricerca hanno volumi medio-alti con picchi; i crawler utente hanno volumi bassi ma imprevedibili.

I dati reali: 10 miliardi di richieste

L'analisi più citata del 2026 (Kinsta, primo semestre) parla chiaro:

• +300% di traffico AI bot in 12 mesi (gennaio 2025 - gennaio 2026).
• GPTBot è il singolo crawler più aggressivo, con picchi di 5.000 richieste al minuto su siti medio-grandi.
• ClaudeBot è il più costante, con pattern orari prevedibili (lavora in finestre 9-17 UTC).
• PerplexityBot ignora robots.txt nel 12% dei casi (analisi su 50.000 siti).
• CCBot è il meno identificabile, spesso si presenta con user agent generici.
• I bot AI generano il 23% del traffico non umano su siti editoriali, il 6% su e-commerce.

Impatto tecnico su un sito WordPress

Vediamo i numeri reali su un'installazione WordPress standard (hosting condiviso medio, 2 vCPU, 4GB RAM, PHP 8.2, MySQL 8, 200 articoli, 50 plugin):

PHP-FPM. Ogni richiesta a index.php consuma un worker PHP. Con 200 worker/ora da GPTBot e un tempo medio di risposta 200ms, l'occupazione è trascurabile. Ma con 2.000 worker/ora (sito medio da 50.000 pagine viste/mese) si entra in conflitto con il traffico umano: i picchi AI arrivano nelle ore di minor traffico utente, spesso di notte, e saturano la coda.

MySQL. I crawler AI eseguono le stesse query degli utenti (post meta, option, term relationships). Su siti con wp_options gonfio (transient scaduti, autoload pesante), una raffica di crawler può trasformare una query da 50ms a 800ms.

Banda. Una pagina WordPress media (HTML + CSS + JS + immagini) pesa 1.5-3MB. Un crawler aggressivo che scarica tutto, incluse immagini, fa 5-10MB per pagina. 50.000 pagine/mese = 250-500GB di banda solo per quel bot.

Log. I log di accesso esplodono. Su un sito con 100.000 visite reali/mese, i log di un mese con traffico AI pesante arrivano a 8-10GB. Difficile da analizzare, archivio complicato.

Identificare i crawler AI nei log

Primo passo: sapere chi bussa. Ecco uno script bash per estrarre il traffico AI dai log Apache/Nginx:

# top 20 bot AI per richieste totali
grep -E 'GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot|ChatGPT-User|CCBot|Google-Extended|Applebot-Extended' /var/log/nginx/access.log \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

# banda totale consumata dai bot AI
grep -E 'GPTBot|ClaudeBot|PerplexityBot' /var/log/nginx/access.log \
  | awk '{ sum += $10 } END { printf "Banda AI bot: %.2f MB\n", sum/1024/1024 }'

# picchi orari di GPTBot
awk '/GPTBot/ {print substr($4,14,2)}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

Se non hai accesso diretto ai log, plugin come Wordfence o Activity Log mostrano le richieste bot con user agent, ma sono più lenti da analizzare.

Strategia di gestione: i 4 livelli

Non esiste una strategia unica. Ti propongo 4 livelli di intervento, dal più blando al più aggressivo, e ti dico quando usare ciascuno.

Livello 1: robots.txt permissivo

Per siti che vogliono essere citati dai motori AI e non hanno problemi di banda.

User-agent: GPTBot
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: ClaudeBot
Allow: /blog/

User-agent: PerplexityBot
Allow: /

User-agent: CCBot
Allow: /

Quando usarlo: blog, siti editoriali, knowledge base aperte, consulenza.

Livello 2: robots.txt granulare con rate limit

Per siti che vogliono essere citati ma non consumare banda eccessiva.

User-agent: GPTBot
Allow: /
Crawl-delay: 10

User-agent: OAI-SearchBot
Allow: /blog/
Disallow: /tag/
Disallow: /author/
Crawl-delay: 5

User-agent: ClaudeBot
Allow: /
Crawl-delay: 15

User-agent: PerplexityBot
Allow: /
Crawl-delay: 5

User-agent: CCBot
Disallow: /

Quando usarlo: siti medio-grandi, portali con molte pagine indicizzate, pubblicazioni tecniche.

Livello 3: blocco selettivo per user agent non identificati

Per siti che vogliono il controllo completo, bloccando i bot che non si identificano chiaramente.

# blocca bot senza user agent
User-agent: *
Disallow: /

User-agent: Googlebot
Allow: /

User-agent: GPTBot
Allow: /blog/

User-agent: ClaudeBot
Allow: /blog/

User-agent: PerplexityBot
Allow: /blog/

Attenzione: bloccare i bot senza user agent può rompere monitoraggio, health check, e tool interni. Usalo con cognizione.

Livello 4: bot protection a livello applicazione

Per siti ad alto traffico, WooCommerce, o piattaforme con problemi di performance.

Usa plugin come Wordfence, SolidWP, o Cloudflare Bot Fight Mode. Ogni plugin ha i suoi pro e contro:

• Wordfence: regex avanzate, geoblocking, sfide JavaScript.
• Cloudflare Bot Fight Mode: challenge JS automatici, gestione a livello edge.
• SolidWP (ex iThemes Security): blocking basato su signature, meno invasivo.

Quando usarlo: e-commerce, siti con problemi di banda, portali WooCommerce, siti con bot maleducati specifici.

Configurazione ottimale per un blog WordPress nel 2026

Per un blog editoriale tecnico come questo, applico questa configurazione ibrida: robots.txt granulare + bot protection a livello CDN.

robots.txt:

# consenti motori AI principali con rate limit
User-agent: GPTBot
Allow: /blog/
Disallow: /wp-admin/
Crawl-delay: 10

User-agent: OAI-SearchBot
Allow: /blog/
Crawl-delay: 5

User-agent: ChatGPT-User
Allow: /blog/

User-agent: ClaudeBot
Allow: /blog/
Crawl-delay: 15

User-agent: Claude-User
Allow: /blog/

User-agent: PerplexityBot
Allow: /blog/
Crawl-delay: 5

User-agent: Perplexity-User
Allow: /blog/

User-agent: Google-Extended
Allow: /blog/

User-agent: Applebot-Extended
Allow: /blog/

User-agent: CCBot
Disallow: /

# blocca bot maleducati noti
User-agent: Bytespider
Disallow: /

User-agent: ImagesiftBot
Disallow: /

# consenti tutto il resto con default
User-agent: *
Disallow: /wp-admin/
Allow: /

Plugin consigliati:

• Cloudflare (free plan): bot fight mode + WAF rules custom per bot AI
• Wordfence: regex personalizzate per bloccare bot che ignorano robots.txt
• WP Cloudflare Super Page Cache: caching edge per ridurre impatto PHP

Impatto sui Core Web Vitals

I crawler AI scaricano risorse come gli utenti: HTML, CSS, JS, immagini. Ma non eseguono JavaScript come fa un browser. Quindi non impattano LCP/INP direttamente. Impatto indiretto però c'è: se il tuo server è sotto carico, anche l'utente umano soffre.

Soluzione: caching aggressivo lato server o CDN. Con Cloudflare o Fastly, anche con 10.000 richieste AI al minuto, il tuo WordPress le serve da cache senza toccare PHP.

Snippet di configurazione WP Rocket + Cloudflare:

# imposta cache page per tutti i bot (WordPress wp-config.php)
define('WP_CACHE', true);
define('WP_ROCKET_WHITE_LABEL_FOOTER', false);
# esclude user agent bot dal caching per evitare problemi di personalizzazione
add_filter('rocket_cache_reject_ua', function($uas){
    $uas[] = 'facebookexternalhit';
    return $uas;
});

Monitoraggio e dashboard

Non ottimizzi ciò che non misuri. Ecco la mia dashboard minima mensile:

# report mensile crawler AI (eseguilo il primo del mese)
LOG=/var/log/nginx/access.log
MONTH=$(date -d "last month" +%Y/%m)
echo "=== Report crawler AI $MONTH ==="
grep "$MONTH" $LOG | grep -E 'GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot|CCBot' \
  | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn
echo "=== Top URL crawlate ==="
grep "$MONTH" $LOG | grep -E 'GPTBot|ClaudeBot' \
  | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

Per chi non ha accesso SSH al server, plugin come WP Statistics o Matomo Cloud mostrano il traffico bot per categoria.

Caso reale: blog tecnico con 3.000 articoli

Un cliente con blog WordPress da 3.000 articoli, 80.000 visitatori unici/mese, hosting VPS 4 vCPU, ha visto nel 2025 un'esplosione di traffico AI che ha portato il server a saturazione 3-4 volte a settimana.

Soluzione applicata:

1. robots.txt granulare con rate limit specifici (vedi esempio sopra)
2. Cloudflare con cache aggressiva e bot fight mode
3. Wordfence con regex custom per bloccare Bytespider, AhrefsBot, SemrushBot (bot aggressivi che non servono il business)
4. Esclusione dal caching di pagine autenticate o con cookie personalizzati

Risultato a 60 giorni: carico CPU sceso da 75% medio a 25%, banda ridotta del 40%, zero downtime, citazioni su Perplexity passate da 0 a 23/mese.

Errori comuni da evitare

1. Bloccare tutto indiscriminatamente: perdi opportunità di citazione e traffico referral.
2. Bloccare Googlebot per errore: succede con regex troppo aggressive su Wordfence. Fai sempre un test dopo ogni regola.
3. Ignorare i log: i crawler cambiano strategia ogni mese, devi monitorare.
4. Dimenticare CDN: senza caching edge, la gestione robots.txt serve a poco su siti medio-grandi.
5. Non documentare le regole: dopo 6 mesi non ricordi più cosa hai bloccato. Tieni un file ai-bot-policy.md con tutte le decisioni.

FAQ su AI bot e WordPress

Devo bloccare GPTBot? Dipende dal modello di business. Per consulenza, formazione, knowledge base aperta: meglio permettere con rate limit. Per e-commerce, paywall, contenuti originali protetti: meglio bloccare.

PerplexityBot ignora robots.txt? Sì, in alcuni casi. Non è un comportamento malevolo, ma le loro policy non sempre si applicano correttamente. Per proteggersi davvero serve bot protection a livello applicazione.

Quanto traffico AI è troppo? Soggettivo. Se il tuo server regge e il budget è sano, non c'è un limite fisso. Se noti degrado di performance, intervieni.

Posso tracciare le citazioni effettive? Sì, vedi sezione monitoraggio. Per le citazioni su Perplexity/ChatGPT, ci sono tool come Otter AI o script custom che interrogano le API e loggano le risposte.

Cloudflare Bot Fight Mode funziona sui bot AI? Sì, identifica e challenge-i bot noti. Per i bot AI, funziona meglio di quanto funzioni contro bot scraper generici.

Devo aggiornare robots.txt spesso? Almeno ogni 3 mesi, perché nuovi bot emergono e quelli esistenti cambiano comportamento. Tieni una routine di revisione.

WordPress ha plugin nativo per gestire i bot AI? No, ma Rank Math, Wordfence, SolidWP hanno opzioni specifiche. Plugin dedicati emergenti nel 2026: AI Bot Blocker, Bot Manager Pro.

Conclusione operativa: la tua checklist AI bot

I crawler AI non sono né buoni né cattivi, sono un nuovo tipo di traffico che va gestito con consapevolezza. WordPress ti dà gli strumenti per farlo a livello di robots.txt, plugin e CDN.

Checklist operativa per il prossimo mese:

• Analizza i log: quali bot AI visitano il tuo sito oggi?
• Decidi la policy: permettere, bloccare o rate-limitare per ciascuno
• Aggiorna robots.txt con regole granulari
• Configura Cloudflare con bot fight mode e cache aggressiva
• Monitora il carico del server: picchi anomali? Banda in crescita?
• Valuta l'impatto sulle citazioni: stai guadagnando o perdendo?
• Documenta le decisioni in un file ai-bot-policy.md

Riferimenti utili

• Lista bot AI aggiornata
• Cloudflare bot protection
• Wordfence plugin
• Kinsta AI bot report
• WooCommerce bot protection
• OpenAI bot documentation
• Anthropic bot policy
• Perplexity bot docs
• WPVibe e MCP per WordPress (articolo interno)
• WordPress 7.0 AI Connectors (articolo interno)
• Plugin WordPress piratati e sicurezza (articolo interno)
• Wordfence bot management

Questa guida non è una classifica: è un inventario operativo, con alternative testate per ciascun plugin rimosso. È complementare a 5 plugin WordPress indispensabili e si inserisce nel percorso di workflow perfetto per sviluppo web che ho documentato nei mesi scorsi.

L'obiettivo è chiaro: dare a uno sviluppatore o a un site owner una lista di plugin da disinstallare subito, con sostituti concreti, e un metodo per identificare da solo i prossimi plugin che finiranno in questa lista nei prossimi 12 mesi.

Come ho costruito la lista

I criteri che definiscono un plugin come "da evitare" nel 2026 sono cinque, tutti verificabili con strumenti standard.

• Nessun aggiornamento per WordPress 7.0: se un plugin non è stato testato o aggiornato per l'ultima major release di WordPress, è un segnale di abbandono imminente.
• Autore senza attività da oltre 12 mesi: il repository GitHub o il forum di supporto sono silenziosi, le issue aperte restano senza risposta.
• Impatto misurabile sulle performance: il plugin aggiunge più di 100ms al TTFB, o carica più di 3 script nella pagina, o esegue query database non ottimizzate in ogni request.
• Sostituibile da funzionalità native del core: WordPress 7.0 ha introdotto molte funzionalità che fino al 2024 richiedevano plugin esterni.
• Notorietà di vulnerabilità aperte: il plugin è nel database WPVulnDB con CVE critiche non patchate, o è noto per essere usato come vettore di attacco in campagne di massa.

Su 80 siti auditati, ho applicato questi criteri e rimosso una media di 4-7 plugin per installazione. I risultati sono stati costanti: tempo di caricamento medio ridotto del 30-50%, superficie di attacco ridotta del 25-40%, e zero regressioni funzionali.

I 23 plugin da evitare nel 2026

La lista è organizzata per categoria, con il plugin problematico, il motivo specifico, e l'alternativa consigliata.

Page builder monolitici (5 plugin)

I page builder monolitici che cercano di sostituire completamente l'editor di WordPress sono il primo pattern da abbandonare. L'editor a blocchi di WordPress 7.0 ha raggiunto la maturità che questi plugin promettevano cinque anni fa, e il lock-in sui page builder è uno dei principali fattori di costo nascosto nella gestione di un sito WordPress.

1. Visual Composer (WPBakery legacy): page builder shortcode-based, abbandonato di fatto dal 2024 dopo l'acquisizione. L'output è codice proprietario non editabile con l'editor a blocchi.

• Alternativa: usa l'editor nativo a blocchi di WordPress 7.0, integrato con Kadence Blocks o Generate Blocks per layout avanzati.

1. Divi Builder (standalone): page builder con licenza chiusa, codice pesante, supporto clienti a pagamento anche per bug critici.

• Alternativa: block theme con theme.json per design system operativo, GeneratePress o Kadence Theme come base.

1. Beaver Builder: page builder commerciale maturo ma pesante, sempre più in ritardo sulle release di WordPress.

• Alternativa: block theme nativo + Spectra (plugin gratuito di Brainstorm Force).

1. Elementor Pro (per siti semplici): eccellente per landing page, ma per siti editoriali e corporate è sovradimensionato.

• Alternativa: block theme + Cwicly o Stackable per casi d'uso specifici.

1. SiteOrigin Page Builder: page builder gratuito ma con codice legacy, interfaccia utente datata, supporto in calo.

• Alternativa: block theme nativo, SiteOrigin Panels Bundle per retrocompatibilità.

Slider e carousel (3 plugin)

Gli slider sono uno dei pattern più inflazionati del web design 2010-2020. Nel 2026 sono diventati un anti-pattern: distraggono l'utente, rallentano il caricamento della pagina, e non convertono. Se serve una sequenza visiva, è meglio un layout a griglia o una galleria statica.

1. Smart Slider 3: slider jQuery pesante, codice legacy, impatto significativo sulle performance.

• Alternativa: layout a griglia con block theme, o Microthemer per effetti CSS avanzati.

1. Slider Revolution: slider commerciale molto popolare ma con bundle JavaScript pesantissimo (oltre 200KB non compressi).

• Alternativa: galleria statica con lightbox, o Lottie animations per il movimento.

1. MetaSlider: gratuito e leggero, ma il pattern slider stesso è da abbandonare.

• Alternativa: nessuna, semplicemente non inserire slider nel design 2026.

SEO gonfiati (3 plugin)

I plugin SEO generalisti che cercano di sostituire la conoscenza SEO dell'operatore sono un altro anti-pattern. Le funzioni di base (title, meta description, sitemap) sono oggi native del core o gestibili con un plugin leggero.

1. Yoast SEO (per siti che non usano le funzioni avanzate): il plugin più diffuso, ma per il 70% dei siti è sovradimensionato. La versione free è accettabile, la premium ha un rapporto qualità/prezzo in calo.

• Alternativa: Rank Math (più leggero, stessa copertura, free tier generoso) o The SEO Framework (minimalista, performante).

1. All in One SEO Pack: longevo ma in ritardo sulle release, interfaccia datata, supporto clienti rallentato.

• Alternativa: Rank Math o The SEO Framework.

1. SEOPress (per chi non usa le sue funzioni avanzate): ottimo plugin, ma per la maggior parte dei siti la versione base basta e avanzata è overkill.

• Alternativa: Rank Math nella versione gratuita.

Cache obsoleti (3 plugin)

I plugin di cache nati prima dell'ottimizzazione del core di WordPress 7.0 sono diventati ridondanti o controproducenti.

1. WP Super Cache: plugin storico, ma il core di WordPress 7.0 gestisce la cache in modo più efficiente e nativo.

• Alternativa: cache del hosting gestito (Kinsta, WP Engine, Cloudways) + OPCache di PHP 8.2+.

1. W3 Total Cache: leggendario ma complesso da configurare, in molti casi rallenta più di quanto acceleri.

• Alternativa: hosting con cache integrata + Perfmatters per ottimizzazioni specifiche.

1. WP Fastest Cache: plugin gratuito leggero, ma incompatibile con alcune architetture di hosting gestito moderne.

• Alternativa: LiteSpeed Cache (solo su hosting LiteSpeed) o cache del provider.

Statistiche invasive (3 plugin)

I plugin di statistiche che tracciano l'utente lato server sono diventati un problema di privacy. La tendenza 2026 è usare analytics server-side leggeri o piattaforme esterne che non aggiungono JavaScript al frontend.

1. Google Analytics for WordPress (by MonsterInsights, versione free): traccia male, campiona i dati, e aggiunge script pesanti.

• Alternativa: Plausible o Fathom Analytics (analytics leggeri, privacy-first, no cookie banner).

1. Jetpack Stats: parte del bundle Jetpack, rallenta il backend per statistiche di base.

• Alternativa: Fathom Analytics o Simple Analytics.

1. WP Statistics: plugin gratuito popolare ma con architettura datata e storage su tabelle custom non ottimizzate.

• Alternativa: Plausible self-hosted o Matomo self-hosted.

Social e sharing (3 plugin)

I bottoni di condivisione social sono diventati un residuo del web 2010. Il tracking dei social network è molto meno efficace, e i plugin aggiungono script che rallentano il caricamento.

1. AddThis: bottoni di condivisione invasivi, tracking cross-site, problemi di performance.

• Alternativa: link testuali diretti ai profili social, o component nativi block theme.

1. Shareaholic: simile ad AddThis, tracking aggressivo, banner pubblicitari iniettati.

• Alternativa: nessuna, o icone SVG statiche nel theme.json.

1. Social Warfare: plugin popolare ma con bug critici storici, dipendenze da CDN esterne non affidabili.

• Alternativa: Novashare (leggero) o icone statiche custom.

Backup ridondanti (2 plugin)

Se il sito è su hosting gestito di qualità, il backup è gestito dall'hosting. Plugin di backup aggiuntivi sono spesso ridondanti e possono anzi creare problemi di storage e performance.

1. UpdraftPlus (in ambienti con backup hosting): eccellente plugin, ma se il sito è su Kinsta, WP Engine, o Cloudways, è ridondante.

• Alternativa: backup del provider di hosting (verificare che sia giornaliero e off-site).

1. BackWPup (in ambienti con backup hosting): come sopra, ridondante su hosting gestito.

• Alternativa: backup del provider + export periodico manuale via WP-CLI.

Sicurezza ridondante (1 plugin)

L'ultimo plugin è una nota di cautela: i plugin di sicurezza generalisti tendono a sovrapporsi con le funzionalità native di WordPress 7.0 e con la protezione dell'hosting gestito.

1. Wordfence (in ambienti gestiti): plugin eccellente, ma su hosting con firewall applicativo (Cloudflare, Sucuri) e aggiornamenti automatici attivi, aggiunge overhead più che protezione.

• Alternativa: hosting con protezione integrata (Kinsta, WP Engine) + Cloudflare free + login protection con 2FA nativo.

Metodo per identificare i prossimi plugin da rimuovere

I 23 plugin di questa lista sono solo lo stato al 2026. Nei prossimi mesi altri plugin diventeranno anti-pattern. Ecco come identificarli prima che diventino un problema.

Audit trimestrale dei plugin

Ogni tre mesi, fai un audit dei plugin installati con questa checklist:

1. Il plugin ha un aggiornamento compatibile con l'ultima major release di WordPress?
2. L'autore ha rilasciato aggiornamenti negli ultimi 6 mesi?
3. Il plugin aggiunge più di 2 script JavaScript o 1 stylesheet nella pagina pubblica?
4. Il plugin esegue query database in ogni request (visibile con Query Monitor)?
5. La funzione del plugin è ora nativa nel core di WordPress o in un block theme?

Se due o più risposte sono negative, il plugin è un candidato alla rimozione.

Monitoraggio proattivo

Esistono due strumenti che aiutano a identificare plugin problematici prima che lo diventino:

• WP Tavern Plugin Newsletter: settimanale, elenca plugin aggiornati, plugin con changelog sospetti, e abbandoni noti.
• WP Planet: aggregatore di blog di sviluppatori WordPress, ottimo per intercettare tendenze e plugin emergenti.

Test di rimozione in staging

Prima di rimuovere un plugin in produzione, testalo in un ambiente di staging. WordPress Playground o Local by Flywheel permettono di clonare un sito in pochi minuti per testare la rimozione senza rischi.

Cosa fare con i 23 plugin se li hai già installati

La rimozione va fatta con metodo, non in panico. Ecco la sequenza operativa.

1. Verifica la funzione: prima di rimuovere un plugin, verifica che la sua funzione non sia usata attivamente sul sito. Il plugin può essere installato ma inattivo (impatto minimo), o attivo e critico (impatto alto).
2. Installa l'alternativa: prima di rimuovere il vecchio, installa e configura il sostituto. Verifica che i dati siano stati migrati (impostazioni, configurazioni, contenuti).
3. Test in staging: clona il sito in un ambiente di staging, rimuovi il plugin, verifica che tutto funzioni.
4. Rimuovi in produzione: rimuovi il plugin in produzione durante una finestra di basso traffico. Monitora le metriche per le 24 ore successive.
5. Cleanup database: dopo la rimozione, controlla con WP-Optimize o WP-Sweep se il plugin ha lasciato tabelle o opzioni orfane nel database. Rimuovile.

Il caso speciale: plugin commerciali con abbonamento attivo

Per i plugin commerciali con abbonamento attivo (Elementor Pro, SEOPress Pro, Rank Math Pro), la rimozione non è solo tecnica: è una decisione di business. Valuta:

• Costo annuo dell'abbonamento vs. valore per il sito: se il plugin non aggiunge funzionalità critiche, l'abbonamento è uno spreco.
• Lock-in dei contenuti: alcuni page builder hanno i contenuti codificati in shortcode proprietari. La migrazione richiede uno script di conversione o un rebuild manuale.
• Contratti pluriennali: se hai un abbonamento pluriennale, aspetta la scadenza naturale e poi migra.

Domande frequenti

Come faccio a sapere se un plugin è sicuro?

Controlla il database WPVulnDB per vulnerabilità note, verifica la data dell'ultimo aggiornamento nel repository WordPress, leggi le recensioni recenti, e controlla il numero di installazioni attive. Un plugin con meno di 1.000 installazioni attive e nessun aggiornamento da oltre 12 mesi è un rischio concreto.

Quanti plugin posso installare su un sito WordPress?

Non c'è un limite rigido. Il problema non è il numero, è la qualità. Un sito con 30 plugin leggeri, ben mantenuti, e non sovrapponibili gira più veloce di un sito con 10 plugin pesanti e abbandonati. La regola operativa che consiglio è: massimo 20-25 plugin attivi, tutti aggiornati negli ultimi 6 mesi, ognuno con una funzione chiara e non sovrapposta ad altri.

WordPress 7.0 ha reso obsoleti i plugin di cache?

In molti casi, sì. WordPress 7.0 ha un sistema di cache integrato più efficiente, e gli hosting gestiti moderni hanno cache a livello di server (OPCache, Redis, Varnish). Per la maggior parte dei siti, un plugin di cache aggiuntivo è ridondante. Solo su hosting condivisi di fascia bassa o su VPS senza cache server ha ancora senso.

I page builder sono morti nel 2026?

I page builder monolitici che sostituiscono l'editor di WordPress sì, sono morti. I page builder come Kadence Blocks, Generate Blocks, Spectra, o Cwicly no: sono estensioni dell'editor a blocchi, vivono dentro l'editor nativo, e producono contenuti portabili. Questa è la differenza fondamentale: lock-in vs. interoperabilità.

Cosa uso al posto di Yoast SEO nel 2026?

Rank Math è la scelta razionale per la maggior parte dei siti: gratuito, leggero, supporta schema markup avanzati, integrazione con Google Search Console, e modulo WooCommerce dedicato. Per siti minimalisti, The SEO Framework è ancora più leggero. Yoast resta valido solo se si usano attivamente le funzioni premium (internal linking suggestions, multiple focus keywords).

È sicuro usare plugin non aggiornati da anni?

No, in nessun caso. Un plugin non aggiornato è una falla di sicurezza aperta. Se l'autore ha abbandonato il plugin, rimuovilo. Se la funzione è critica, cerca un fork attivo o un'alternativa moderna. I siti compromessi nel 2026 sono in stragrande maggioranza su plugin obsoleti, temi piratati, o installazioni non aggiornate.

Riferimenti ufficiali

Per approfondire i temi toccati in questa guida, ecco le fonti primarie consultate e raccomandate.

• WordPress Plugin Directory - repository ufficiale plugin.
• WPVulnDB - database vulnerabilità WordPress.
• Query Monitor - profiling performance plugin.
• WP Tavern - notizie e analisi WordPress.
• Rank Math - SEO plugin consigliato 2026.
• Kadence Blocks - estensione block editor.
• GenerateBlocks - block builder leggero.
• Plausible Analytics - analytics privacy-first.
• Fathom Analytics - analytics senza cookie.
• WordPress Playground - sandbox test plugin.
• Local by Flywheel - ambiente sviluppo locale.
• Guida plugin indispensabili mrtux.it - 5 plugin mantenuti e testati.
• Workflow perfetto sviluppo web mrtux.it - framework 7 stadi.

Questa guida verrà aggiornata ogni sei mesi, in coincidenza con i rilasci principali di WordPress e del suo ecosistema. Per suggerimenti o correzioni, l'area commenti è aperta.