Cosa il firewall nasconde ai log: il punto cieco dei blocchi all'edge

Un responsabile di sito apre i suoi log, cerca GPTBot, ClaudeBot o PerplexityBot, non trova nulla e conclude che le IA non si interessano ai suoi contenuti. La conclusione è spesso falsa, e per una ragione meccanica: quando un firewall o un CDN rifiuta una richiesta, questa si ferma alla periferia della rete, all'edge, e non raggiunge mai il server di origine. Non esiste quindi in nessun log di origine. Il silenzio dei log non significa che i robot siano assenti; può significare esattamente il contrario.

Come una richiesta può sparire

Su un sito servito dietro un CDN come Cloudflare, ogni richiesta attraversa più livelli prima di arrivare al server. Il firewall applicativo, descritto nella documentazione del WAF di Cloudflare, valuta regole e può bloccare, reindirizzare o mostrare un challenge. Un modulo di gestione dei robot, dettagliato nella documentazione Bots, classifica il traffico automatizzato e gli applica una politica. Dal 2024 queste piattaforme propongono di bloccare i robot di IA con un clic, come annunciava Cloudflare nel suo post sul blocco dei robot di IA, e molti siti hanno attivato l'opzione senza misurare che cosa facesse.

Ogni richiesta fermata a questo livello riceve una risposta fabbricata dal CDN, di norma un codice 403 o una pagina di challenge. Il server di origine non ne vede nulla. I log di Apache, di nginx o dell'applicazione non la contengono, e uno strumento di analisi dei log che legge soltanto l'origine non può contarla.

I tre errori di ragionamento che ne derivano

1. «Nessuna IA viene da noi.» È il più diffuso. Il sito in realtà viene visitato, ma ogni visita è rifiutata a monte. Una regola attivata per precauzione, a volte da un fornitore, a volte da una casella spuntata in un'interfaccia, taglia in silenzio ogni possibilità di essere citati.
2. «Il nostro tasso di successo del crawl è del 100%.» Una dashboard che conta le risposte 200 servite dall'origine mostra un punteggio perfetto, dato che vi arrivano solo le richieste accettate. Il tasso reale, blocchi compresi, può essere molto basso.
3. «Il robot non rispetta il nostro robots.txt.» Se il robots.txt è servito dall'origine ma la prima richiesta del robot viene bloccata all'edge, il robot non l'ha mai letto. Si accusa il robot di un comportamento la cui causa è locale.

Come verificare che cosa succede all'edge

I controlli, dal più semplice al più completo:

• Rileggere la configurazione del CDN. Regole WAF, modalità di gestione dei robot, opzioni «bloccare i robot di IA», elenchi di user-agent rifiutati. Va letta com'è, non come si crede di averla impostata: su un sito su cui abbiamo svolto un audit quest'estate, una regola di blocco ereditata da una configurazione precedente tagliava robot che nessuno nel team pensava di bloccare.
• Testare con gli user-agent reali. Inviare di persona una richiesta a una pagina pubblica dichiarando lo user-agent di ogni robot di IA, dall'esterno della rete, e guardare il codice di risposta e chi lo emette. Un 403 firmato dal CDN mentre l'origine risponde 200 è la prova diretta del blocco all'edge.
• Leggere i log del CDN, non soltanto quelli dell'origine. I grandi CDN espongono statistiche di traffico che includono le richieste rifiutate, per regola e per user-agent, e a volte per percorso. È lì che si vedono i robot che si credevano assenti. Su Cloudflare questi dati sono accessibili dall'interfaccia e tramite API con un token che disponga del diritto di lettura Zone Analytics; su un piano gratuito la ripartizione per percorso obbliga a passare dall'API.

Un caso misurato

Su un altro sito, industriale, sottoposto ad audit nella stessa estate, i log di origine non mostravano alcuna richiesta di un robot di IA per diverse settimane, e la dashboard del crawl indicava un tasso di successo perfetto. I log del CDN raccontavano un'altra storia: diverse centinaia di richieste di robot di IA rifiutate con un 403 da una regola di firewall, di cui nessuno aveva traccia. La conclusione iniziale, «le IA non vengono», era l'esatto contrario della realtà: venivano, con regolarità, e ripartivano senza leggere nulla. Il sito non compariva in nessuna risposta generata, non per mancanza di interesse dei motori, ma per un'impostazione di sicurezza. La diagnosi ha richiesto un'ora; poteva non essere mai fatta.

La trappola dell'indirizzo IP

Un secondo effetto del CDN complica la lettura dei log di origine: l'indirizzo IP che il server vede è quello del CDN, non quello del visitatore, a meno che il server non sia configurato per leggere l'header che trasporta l'indirizzo di origine. Quando questa impostazione manca, tutti i visitatori, umani e robot, sembrano venire da qualche decina di indirizzi appartenenti al CDN. Le verifiche di autenticità descritte nel nostro articolo sul reverse DNS e sugli intervalli di IP diventano impossibili, e un robot autentico può essere preso per un impostore, o il contrario. Un header proprietario aggiunto dal CDN sopravvive di norma a tutti i salti intermedi là dove un header generico può essere sovrascritto. In Cloudflare è CF-Connecting-IP; l'header generico, X-Forwarded-For, può essere riscritto da qualunque intermediario. Chiedete al vostro provider il nome esatto di quello che aggiunge, e verificate che arrivi davvero fino al log di origine.

Quale politica tenere

La questione di fondo è editoriale: una testata che vuole essere citata dalle IA non ha alcuna ragione di bloccare all'edge i loro robot di ricerca e di lettura. Bloccare l'addestramento è una decisione legittima, ma si prende nel robots.txt, user-agent per user-agent, come spieghiamo in «robots.txt e IA», non con un interruttore che rifiuta tutto ciò che somiglia a un'IA. Un blocco all'edge ha senso solo per traffico abusivo accertato: volumi anomali, usurpazione d'identità, scraper che ignorano il robots.txt.

Resta una precauzione da tenere: non bloccare nemmeno gli impostori con una regola larga sullo user-agent. Una regola che rifiuta ogni «GPTBot» proveniente da un indirizzo fuori dagli intervalli pubblicati da OpenAI sembra prudente; in pratica rifiuta anche le richieste legittime il giorno in cui OpenAI aggiunge un intervallo che l'elenco locale non ha ancora. La risposta giusta all'usurpazione d'identità è la misura e la limitazione della frequenza, non il rifiuto cieco.

Che cosa significa misurare, una volta tolto il blocco

Quando l'edge lascia passare, i log di origine tornano a essere una fonte affidabile, a condizione che trasportino l'indirizzo di origine e conservino lo user-agent completo. Si può allora contare, per robot e per uso (addestramento, ricerca, lettura su richiesta), che cosa le IA leggono davvero: quali pagine, con quale frequenza, con quale codice di risposta. È questa lettura, e non una dashboard di origine, a permettere di affermare che un contenuto viene raggiunto dai motori generativi. Dettagliamo il metodo in «Leggere un access log in 30 minuti».

Il principio è questo: un log di origine prova soltanto ciò che è arrivato fino all'origine. Tutto ciò che è stato rifiutato prima non vi lascia alcuna traccia, ed è esattamente quello che bisogna andare a cercare altrove prima di concludere qualunque cosa sulle IA.