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