Scalare hosting WordPress contro i bot AI: guida completa

Quando il carico sul sito WordPress sale e i visitatori reali non crescono, la tentazione è una sola: aumentare il piano hosting. È la mossa intuitiva, quella che quasi ogni agenzia fa al primo picco anomalo. Peccato che sia anche la mossa sbagliata. Il bot traffic su WordPress nel 2026 non si autoregola come un visitatore umano: continua a chiedere risorse indipendentemente da quante ne riceve, quindi più capacità significhi solo più spazio per il bot.

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