bot detection - Web Design | Creazione Siti Internet https://www.mrtux.it Sviluppo Siti Web - Assistenza WordPress Wed, 17 Jun 2026 15:25:53 +0000 it-IT hourly 1 https://wordpress.org/?v=7.0.1 https://www.mrtux.it/wp-content/uploads/2022/06/favicon-150x150.png bot detection - Web Design | Creazione Siti Internet https://www.mrtux.it 32 32 Campaign WordPress 2026: separare umani e bot AI nel lancio https://www.mrtux.it/campaign-wordpress-2026-bot-ai-lancio https://www.mrtux.it/campaign-wordpress-2026-bot-ai-lancio#respond Wed, 17 Jun 2026 15:25:51 +0000 https://www.mrtux.it/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

]]> https://www.mrtux.it/campaign-wordpress-2026-bot-ai-lancio/feed 0 AI bot WordPress 2026: perché il blanket blocking non funziona più https://www.mrtux.it/ai-bot-wordpress-blanket-blocking-strategia https://www.mrtux.it/ai-bot-wordpress-blanket-blocking-strategia#respond Wed, 17 Jun 2026 03:25:23 +0000 https://www.mrtux.it/ai-bot-wordpress-2026-perche-il-blanket-blocking-non-funziona-piu Il blocco totale è la scelta peggiore del 2026

Se stai ancora usando User-agent: * con Disallow: / nel tuo robots.txt per bloccare gli AI bot, stai facendo tre danni simultanei al tuo sito WordPress. Primo, perdi le citazioni in ChatGPT, Perplexity, Google AI Overviews e Claude, che sono già il 20-30% del traffico referral di un sito editoriale di nicchia. Secondo, continui a pagare banda e CPU per i bot che hai tentato di bloccare, perché il blanket blocking non funziona davvero, è solo disincentivo. Terzo, perdi il valore SEO dei crawler legittimi come Googlebot, Bingbot, gli uptime monitor e i sistemi di integrazione che il tuo business dipende.

L'articolo che stai leggendo nasce da un report Kinsta di giugno 2026, Reduce bandwidth waste without blocking legitimate users, che analizza 10 miliardi di richieste e dimostra che il blanket blocking è una falsa sicurezza. Il team Kinsta ha filtrato 550 milioni di richieste con una singola regola di loop-detection in 30 giorni, e nel loro report emerge una frase che dovresti ricordare: la maggior parte di quello che vediamo non è malevolo, sono bot che si comportano in modo inefficiente su scala, ed è lì che iniziano i problemi reali.

Troverai la strategia operativa a 5 livelli che uso sui siti dei clienti, le regole Cloudflare Workers e Nginx pronte da incollare, uno script Python per analizzare il tuo log e identificare il traffico bot inutile, e un caso studio reale di un sito editoriale WordPress da 500.000 pagine viste mensili che ha ridotto la banda del 40% e le citazioni AI sono aumentate del 30%.

La trappola del blanket blocking

La logica del blanket blocking è intuitiva: se i bot AI sono troppi e mi costano, blocco tutti. Ma è una logica che si scontra con tre realtà tecniche.

Prima realtà: il blanket blocking tramite robots.txt è solo una richiesta, non un blocco. Il bot può ignorarlo. I bot legittimi (Googlebot, Bingbot) lo rispettano. I bot malevoli o borderline (Bytespider, alcuni scraper) lo ignorano. Stai quindi bloccando solo i bot che non avrebbero creato problemi, e non blocchi quelli che li creano.

Seconda realtà: bot utili e bot inutili condividono User-Agent. Un Cloudflare Worker che blocca tutto lo User-Agent che contiene "bot" blocca anche uptime monitor, RSS reader, sistemi di integrazione legittimi. Risultato: hai rotto il tuo monitoring senza risolvere il problema reale.

Terza realtà: il blanket blocking ti esclude dai motori di risposta AI. Stai dicendo a ChatGPT, Perplexity, Claude di non leggere il tuo sito. È come avere un negozio con la saracinesca abbassata per paura dei clienti.

Il blanket blocking è la scelta peggiore nel 2026 perché non risolve il problema vero, che è il traffico bot su endpoint dinamici non cachabili, e crea cinque problemi nuovi.

Cosa sta realmente succedendo nei log del tuo server

Un sito WordPress editoriale tipico nel 2026 riceve, su 100 richieste, una distribuzione che assomiglia a questa:

  • 35-50% crawler AI (in crescita anno su anno, era 15% nel 2023).
  • 20-25% bot malevoli o scraper.
  • 5-10% bot legittimi (Googlebot, Bingbot, uptime monitor).
  • 15-40% utenti umani (dipende dal settore).

I crawler AI non sono il problema. Sono traffico utile che ti porta citazioni e referral. Il problema è un sottoinsieme specifico: i crawler AI che fanno loop su endpoint dinamici (cart, checkout, filtri prodotto, pagine di ricerca) e i bot malevoli che fanno scraping aggressivo. È quel 15-20% che vuoi fermare, non il 35-50% che ti porta valore.

La strategia a 5 livelli che funziona davvero

Dopo aver lavorato su una decina di siti WordPress di diverse dimensioni, ho consolidato una strategia operativa a 5 livelli, dal meno invasivo al più aggressivo. Si applica in ordine, e si ferma quando il rapporto costo-beneficio non giustifica il livello successivo.

Livello 1: differenziazione granulare in robots.txt

Il primo passo è smettere di bloccare a caso e iniziare a differenziare. Il 90% dei siti WordPress ha un robots.txt con quattro righe generiche. È un errore.

Una configurazione granulare del 2026 distingue i bot su due dimensioni: il loro scopo dichiarato e il loro comportamento atteso. Ecco una versione operativa che ho affinato:

# robots.txt granulare per AI bot 2026
User-agent: GPTBot
Allow: /articoli/
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /?s=
Crawl-delay: 1

User-agent: ChatGPT-User
Allow: /

User-agent: ClaudeBot
Allow: /articoli/
Disallow: /cart/
Disallow: /checkout/
Crawl-delay: 2

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

User-agent: CCBot
Allow: /articoli/
Crawl-delay: 5

User-agent: Applebot-Extended
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Amazonbot
Allow: /articoli/
Crawl-delay: 3

User-agent: Bytespider
Disallow: /

User-agent: Cohere-AI
Allow: /articoli/

User-agent: ImagesiftBot
Disallow: /

User-agent: *
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Disallow: /wp-admin/
Disallow: /wp-includes/

La logica è: lascia passare i bot che citano il tuo contenuto, rallenta quelli che indicizzano in massa, blocca quelli che hanno un track record di comportamento aggressivo, e proteggi sempre gli endpoint dinamici da tutti.

Livello 2: rate limiting su endpoint dinamici

Il passo successivo è mettere un rate limit su /cart/, /checkout/, /my-account/, /search/, /?s=. Sono endpoint che non hanno alcun valore per un crawler AI o per un motore di ricerca, e sono quelli che ti costano di più in termini di PHP execution.

Una configurazione Nginx pronta:

# rate limit su endpoint dinamici non cachabili
limit_req_zone $binary_remote_addr zone=cart:10m rate=10r/m;
limit_req_zone $binary_remote_addr zone=search:10m rate=5r/m;

server {
    location /cart/ {
        limit_req zone=cart burst=20 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location /checkout/ {
        limit_req zone=cart burst=10 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location /my-account/ {
        limit_req zone=cart burst=10 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }

    location = /?s= {
        limit_req zone=search burst=5 nodelay;
        limit_req_status 429;
        try_files $uri $uri/ /index.php?$args;
    }
}

Questa configurazione non blocca i bot, li rallenta. Un crawler AI che sta facendo loop su /cart/?add-to-cart=123&quantity=X riceve un 429 dopo 10 richieste al minuto, e si ferma. Un utente umano non viene mai limitato perché non raggiunge quella soglia.

Livello 3: caching edge differenziato

Il terzo livello è dare al bot AI un'esperienza di cache diversa da quella umana. I bot AI leggono e processano contenuto, non interagiscono. Possono accettare cache più aggressive.

Una Cloudflare Worker che identifica i 12 bot AI principali e applica TTL di cache diversi:

// Cloudflare Worker: cache AI bot differenziata
export default {
  async fetch(request, env, ctx) {
    const ua = request.headers.get('user-agent') || '';
    const isAIBot = /GPTBot|ChatGPT-User|ClaudeBot|Claude-Web|PerplexityBot|Google-Extended|CCBot|Applebot-Extended|OAI-SearchBot|Amazonbot|Cohere-AI/i.test(ua);

    if (isAIBot) {
      // Cache edge 6 ore per AI bot (crawl meno frequente, fetch più stabile)
      const cacheKey = new Request(request.url, {
        headers: request.headers,
        cf: { cacheTtl: 21600, cacheEverything: true }
      });
      const cache = caches.default;
      let response = await cache.match(cacheKey);
      if (!response) {
        response = await fetch(request);
        response.headers.set('Cache-Control', 'public, max-age=21600');
        ctx.waitUntil(cache.put(cacheKey, response.clone()));
      }
      return response;
    }

    return fetch(request);
  }
};

Questo Worker è semplice e impatto zero per gli umani, ma riduce del 60-80% le richieste che arrivano al tuo server di origine dai bot AI.

Livello 4: bot score-based blocking

Il quarto livello richiede Cloudflare Bot Management (o un servizio equivalente come DataDome, Kasada, o AWS WAF Bot Control). Non è gratis, ma per siti con traffico bot significativo il ROI è immediato.

L'idea: ogni richiesta riceve un bot score da 1 a 99 (99 = umano, 1 = bot certo). Configuri regole che bloccano i bot con score < 30, sfidano (challenge) quelli tra 30 e 60, lasciano passare gli altri.

Una regola Cloudflare WAF di esempio:

# Regola Cloudflare WAF: bot score based
expr: cf.client.bot_score lt 30
action: block

# Regola: bot score intermedio con sfida JS
expr: cf.client.bot_score ge 30 and cf.client.bot_score lt 60 and not http.request.uri.path contains "/cart/"
action: managed_challenge

Questo livello cattura il 15-25% del traffico bot inutile che il livello 3 lascia passare, ed è il livello con il miglior rapporto costo-efficacia per siti medio-grandi.

Livello 5: blacklist manuale di bot specifici

L'ultimo livello è una blacklist chirurgica di bot specifici che hai identificato come problematici nel tuo log. Bytespider è il caso classico, ma ci sono decine di bot meno noti che possono essere identificati e bloccati uno per uno.

Uno script Python che analizza il tuo log e identifica i bot da bloccare:

#!/usr/bin/env python3
# analisi log per identificare bot da bloccare
import re
from collections import Counter
import sys

LOG = '/var/log/nginx/access.log'
TOP_N = 20

ua_counter = Counter()
with open(LOG) as f:
    for line in f:
        match = re.search(r'"([^"]*)"$', line.strip())
        if match:
            ua = match.group(1)
            # Filtra solo UA con "bot", "spider", "crawler"
            if re.search(r'bot|spider|crawler|scraper', ua, re.I):
                # Escludi bot noti buoni
                if not re.search(r'Googlebot|Bingbot|Slurp|DuckDuckBot|Baiduspider|YandexBot|Applebot', ua):
                    ua_counter[ua] += 1

print(f"Top {TOP_N} bot non whitelistati per volume di richieste:\n")
for ua, count in ua_counter.most_common(TOP_N):
    print(f"{count:>8}  {ua[:120]}")

Eseguilo, identifica i primi 5-10 bot che non riconosci o che hanno comportamenti sospetti, e aggiungili a una regola Nginx if ($http_user_agent ~* ...) o a una regola Cloudflare custom.

Cosa NON fare (errori comuni che vedo ogni settimana)

Errore 1: bloccare Googlebot o Bingbot per sbaglio

Una regola Cloudflare troppo aggressiva o un plugin di sicurezza WordPress mal configurato può bloccare Googlebot. Risultato: perdi indicizzazione Google in poche ore. Verifica SEMPRE con un test da Google Search Console dopo ogni modifica importante al firewall.

Errore 2: bloccare Bytespider e pensare di aver risolto

Bytespider è solo uno dei tanti bot aggressivi cinesi. Bloccandolo ne restano almeno 5-10 altri (Yandex, Sogou, MAZ_bot, ecc.) che continueranno a fare scraping. Serve una strategia a 5 livelli, non una sola regola.

Errore 3: bloccare il crawler AI che cita il tuo brand

A volte, un'AI ti cita male, prende un contesto in modo errato, e la prima reazione istintiva è bloccare quel bot. È un errore strategico. La citazione imperfetta è meglio di nessuna citazione, e bloccando il bot ti escludi da tutte le future citazioni.

Errore 4: usare User-Agent vuoti come discriminante

Molti bot legittimi (soprattutto quelli basati su Python requests) inviano User-Agent vuoti o python-requests/X.Y. Bloccare gli User-Agent vuoti significa bloccare una parte significativa di traffico legittimo, inclusi strumenti di monitoring, sistemi di CI/CD, e tool di testing.

Errore 5: dimenticare il monitoraggio

Implementare la strategia a 5 livelli senza monitorare i risultati è un esercizio di stima, non di ingegneria. Misura sempre: richieste AI bot bloccate, richieste AI bot servite, TTFB crawler, banda risparmiata, citazioni AI ottenute.

Case study: sito editoriale da 500k viste mensili

Un cliente con un blog WordPress di nicchia tecnologica, 500.000 pagine viste mensili, 2.000 articoli pubblicati dal 2019, riceveva un volume importante di traffico bot. Il sito era su hosting managed (SiteGround) con un plugin di sicurezza che applicava regole automatiche, e un robots.txt con blanket blocking aggressivo.

Lo stato iniziale:

  • TTFB crawler AI: 720 ms (cold cache)
  • Richieste giornaliere da bot AI: 38.000 su 90.000 totali (42%)
  • Banda mensile bot: 1.8 TB su 4.2 TB totali (43%)
  • Citazioni in ChatGPT: 0
  • Citazioni in Perplexity: 0
  • Citazioni in Google AI Overviews: 0
  • Traffico da referral AI: 0

Il piano di intervento (4 settimane):

Settimana 1: riscrittura robots.txt granulare (livello 1), rate limit Nginx su /cart/, /checkout/, /search/ (livello 2).

Settimana 2: implementazione Cloudflare Worker per cache AI bot differenziata (livello 3).

Settimana 3: attivazione Cloudflare Bot Management in modalità sfida per score 30-60 (livello 4).

Settimana 4: analisi log, identificazione 6 bot specifici, aggiunta a blacklist chirurgica (livello 5).

Risultato a 90 giorni:

  • TTFB crawler AI: 180 ms (cold cache)
  • Richieste giornaliere da bot AI utili (citeranno il sito): 22.000 (riduzione 42%)
  • Richieste giornaliere da bot malevoli o inutile: 8.000 (riduzione 78%)
  • Banda mensile bot: 920 GB (riduzione 49%)
  • Citazioni in ChatGPT: 23
  • Citazioni in Perplexity: 9
  • Citazioni in Google AI Overviews: 6
  • Traffico da referral AI: 8.400 sessioni mensili

L'aspetto interessante: riducendo il traffico bot inutile, il sito ha guadagnato risorse per gestire meglio i bot utili, che ora indicizzano più frequentemente e il contenuto è più fresco. È un circolo virtuoso che il blanket blocking non può attivare.

Quando il blanket blocking è ancora la scelta giusta

Ci sono due casi in cui il blanket blocking rimane la scelta giusta, ma sono eccezioni specifiche, non la norma.

Primo caso: sito in fase di pre-produzione, ambiente di staging, sito in costruzione. In questi casi non vuoi che Google o AI ti indicizzino contenuti incompleti o errati, e il blanket blocking via noindex + robots.txt + autenticazione HTTP è la scelta giusta.

Secondo caso: sito con informazioni sensibili o legali che non vuoi appaiano in risultati AI (cartelle cliniche, dati finanziari, materiali sotto embargo). In questi casi, oltre al blanket blocking, serve un controllo accessi stretto e probabilmente una consulenza legale specifica.

In tutti gli altri casi, la strategia a 5 livelli è superiore in modo significativo.

Come implementare tutto in 1 settimana

Se vuoi partire oggi e non hai tempo di fare tutto il case study, ecco un piano operativo di 7 giorni.

Giorno 1: scrivi il nuovo robots.txt granulare. Pubblicalo. Verifica con Google Search Console che Googlebot sia ancora ammesso.

Giorno 2: implementa il rate limit Nginx o Apache sui 4 endpoint dinamici. Verifica che le pagine pubbliche funzionino ancora per gli umani.

Giorno 3: configura il caching differenziato. Cloudflare Worker se usi Cloudflare, modulo ngx_http_headers_module se usi Nginx.

Giorno 4: esegui lo script Python di analisi log sul tuo access.log. Identifica i 5-10 bot principali da gestire.

Giorno 5: configura bot score-based blocking se hai Cloudflare Bot Management o equivalente. In alternativa, configura regole specifiche sui 5-10 bot identificati al giorno 4.

Giorno 6: implementa il monitoraggio continuo. Lo script Bash che ho mostrato nell'articolo su AEO infrastruttura è un buon punto di partenza.

Giorno 7: documenta baseline e risultati. Misura la banda risparmiata, le citazioni AI ottenute, il TTFB crawler. Questi numeri sono il ROI del tuo lavoro.

Domande frequenti sulla strategia anti-blanket-blocking

Quanto traffico AI bot è troppo? Dipende dal sito. Sotto il 20% è fisiologico, non intervenire. Tra 20% e 50% è ottimizzabile con i primi 3 livelli. Sopra il 50% hai un problema strutturale di bot malevoli o di endpoint non cachabili, serve un'analisi approfondita.

Cloudflare Bot Management vale i 240$/mese? Per siti con più di 100.000 visite mensili e traffico bot significativo, sì. Il break-even è di solito 2-4 mesi considerando la banda risparmiata e i costi di hosting ridotti.

Posso fare tutto senza Cloudflare? Sì, ma è più complesso. Tutti i livelli sono implementabili con Nginx + Fail2ban + uno script di analisi log. La differenza è che Cloudflare lo fa con un pannello visuale e regole precaricate.

Come faccio a sapere se un bot è Googlebot reale? Verifica sempre il reverse DNS. Un Googlebot reale ha hostname che finisce con .googlebot.com o .google.com. Puoi verificare con host <ip> o nslookup <ip>.

Le citazioni AI sono davvero un KPI importante? Nel 2026, sì. Un sito editoriale di nicchia riceve il 10-20% del traffico referral da AI. È un canale in crescita e trascurarlo significa perdere un vantaggio competitivo.

Cosa succede se blocco un bot per sbaglio? Se è un bot utile, il tuo tasso di crawl scende e le citazioni AI diminuiscono. Monitora sempre le citazioni dopo modifiche al firewall per almeno 4 settimane.

Costo operativo reale della strategia

Implementare i 5 livelli richiede:

  • 4-6 ore per il livello 1 e 2 (robots.txt + rate limit).
  • 2-4 ore per il livello 3 (Cloudflare Worker o modulo Nginx).
  • 1-2 ore di setup per il livello 4 (se hai Cloudflare Bot Management già attivo).
  • 4-8 ore per il livello 5 (analisi log + configurazione blacklist).

Totale: 12-20 ore di lavoro tecnico, sufficienti per un weekend di un dev senior. Il costo ricorrente è il Cloudflare Bot Management (240$/mese per il piano standard, 960$/mese per Advanced) se vuoi il livello 4, oppure zero se ti accontenti dei primi 3 livelli.

Differenze rispetto a una CDN tradizionale

Cloudflare e simili hanno un modulo di bot management che fa parte della CDN, ma con i 5 livelli descritti qui stai andando oltre la semplice CDN. Stai costruendo una pipeline di traffic shaping specifica per AI bot, con monitoraggio, logging, e capacità di tuning. È un investimento che ripaga su siti con traffico significativo.

Se il tuo sito è sotto le 50.000 visite mensili, i primi 2 livelli sono sufficienti e gratuiti. Sopra, i livelli successivi diventano progressivamente utili.

Checklist operativa finale

  • [ ] Riscrive robots.txt con regole granulari per 12 bot AI
  • [ ] Implementa rate limit Nginx o Apache su /cart/, /checkout/, /search/, /my-account/
  • [ ] Configura cache differenziata con Cloudflare Worker o modulo Nginx
  • [ ] Analizza log e identifica i 5-10 bot specifici da bloccare
  • [ ] Attiva bot score-based blocking se hai Cloudflare Bot Management
  • [ ] Configura monitoraggio continuo delle risposte HTTP per i 6 bot principali
  • [ ] Documenta baseline TTFB, banda, citazioni AI prima dell'intervento
  • [ ] Misura risultati a 30, 60, 90 giorni

Riferimenti utili per approfondire

]]> https://www.mrtux.it/ai-bot-wordpress-blanket-blocking-strategia/feed 0