Campaign WordPress 2026: separare umani e bot AI nel lancio

Quando una campagna marketing parte, metà del traffico può essere rumore. Un lancio che promette 50.000 visitatori in 24 ore ne porta spesso 25.000 reali e 25.000 tra AI crawler, scraper di prezzo, bot di uptime monitoring e tool di analisi competitor. Il problema non è solo analitico: è un costo reale su CPU, banda, conversione e capacity planning. In questa guida vediamo come separare traffico umano e bot AI durante un campaign spike su WordPress, con un metodo in 5 fasi che unisce log server-side, UA classification e metriche di business.

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