Analisi dei log dei crawler AI

TL;DR — L’analisi dei log dei crawler AI consiste nell’esaminare i log di accesso grezzi del server per vedere quali bot AI — come GPTBot di OpenAI o ClaudeBot di Anthropic — hanno visitato davvero il sito, con quale frequenza e cosa hanno ricevuto. I log sono l’unico luogo che registra tutto questo. Google Search Console non mostra i bot AI e Google Analytics vede solo le persone che fanno clic per arrivare al sito, non i bot. Il problema è che molto traffico si dichiara un famoso bot AI senza esserlo: non puoi fidarti del solo nome.

Che cos’è un file di log

I log di accesso del server registrano le richieste arrivate al server, compresi user agent, ora, percorso e dettagli della risposta quando sono configurati. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files La documentazione dei crawler dei vendor identifica gli user agent, ma una stringa da sola non dimostra che il richiedente sia autentico. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Ogni volta che qualcosa — il browser di una persona, Googlebot, GPTBot — chiede una pagina al server, il server scrive una riga in un file di log. Ogni riga registra l’ora, l’indirizzo IP del visitatore, ciò che ha chiesto, lo “user agent” (un’etichetta con cui il visitatore si identifica, come GPTBot) e il codice di risposta inviato dal server (200 per successo, 404 per pagina non trovata e così via).

L’analisi dei log dei crawler AI consiste semplicemente nel leggere quelle righe e filtrare i bot AI. Risponde a domande a cui letteralmente non puoi rispondere in nessun altro modo:

• Un bot AI ha visitato davvero il sito?
• Quali pagine ha recuperato e quali pagine importanti ha ignorato?
• Era il bot reale o qualcosa che fingeva di esserlo?
• Cosa ha ricevuto: i contenuti reali o una pagina di errore?

Se vuoi conoscere tutti i bot AI e il loro scopo (bot di addestramento, bot di ricerca o bot che ricevono il comando “recupera subito questa pagina”), è un argomento separato: vedi Crawlers AI. Questa pagina riguarda il come: estrarre i log e leggerli.

Perché le tue dashboard non bastano

• Google Search Console ha un rapporto Statistiche di scansione, ma riguarda solo Googlebot. Non mostra nulla su GPTBot, ClaudeBot o PerplexityBot.
• Google Analytics (GA4) registra solo i visitatori che fanno clic su un link verso il sito e arrivano con un “referrer”. Un crawler che recupera la pagina in background non compare mai.

Quindi i log sono la fonte di verità. Nessun altro strumento vede il bot.

L’unica cosa che i principianti trascurano

Un’etichetta GPTBot nei log non dimostra che sia davvero OpenAI. Chiunque può inserire qualunque stringa user agent in una richiesta: è come scrivere un indirizzo del mittente su una busta. Molti scraper appiccicano il nome di un bot famoso al proprio traffico per sembrare legittimi. L’unico modo per avere certezza è confrontare l’indirizzo IP del visitatore con l’elenco degli indirizzi reali pubblicato dall’azienda AI. Questo passaggio di verifica è il cuore del metodo corretto e la scheda Advanced lo illustra in dettaglio.

TL;DR — Estrai i log di accesso di Apache/Nginx o del CDN, poi fai quattro cose: verifica (abbina lo user agent e conferma l’IP rispetto all’elenco pubblicato da ogni operatore — i tassi di spoofing vanno dal 5,7% di HUMAN Security all’81,8% verificato personalmente da Duane Forrester); scegli uno strumento in base alla scala (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); misura la frequenza di scansione per bot, le pagine visitate, crawl rispetto a rendering e codici di stato; interpreta con onestà — il recupero è necessario ma non sufficiente, quindi “più scansioni = più citazioni” non è dimostrato. Questo è il metodo gemello di Crawlers AI (che descrive quali sono i bot), Attribuzione del traffico AI (il lato dei clic) e Visibilità LLM (il modello recuperato → menzionato → citato di cui qui osservi solo il primo stadio).

Di cosa si occupa questo articolo — e di cosa no

I log dimostrano le richieste, non se il contenuto sia stato usato per l’addestramento, il recupero o una risposta. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Verifica i bot usando i meccanismi pubblicati dai provider quando disponibili e considera l’attribuzione come un’evidenza circoscritta. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Il fratello Crawlers AI si occupa già della tabella bot per bot, della tassonomia in tre categorie (addestramento / ricerca AI / recupero avviato dall’utente), della distinzione tra Google-Extended come token e non come bot e delle ricette robots.txt. Qui non sto ricostruendo nulla di tutto questo. Attribuzione del traffico AI si occupa del lato GA4/referrer — ciò che il bot ha rimandato. Questo articolo è il lato opposto del funnel: ciò che il bot ha prelevato. E Visibilità LLM si occupa del modello recuperato → menzionato → citato; l’analisi dei log è il modo per osservare nello specifico la fase recuperato, e niente oltre.

Questo è il seguito nell’era AI della classica analisi dei file di log SEO. Quando ho esaminato How to Do an SEO Log File Analysis di Ahrefs, le dimensioni erano frequenza di scansione, URL scansionati, codici di stato e verifica dei bot rispetto agli IP pubblicati da Google. Qui lo scheletro è lo stesso, ma rivolto a una popolazione di bot che per lo più non esegue JavaScript, viene imitata continuamente e scansiona a raffiche irregolari invece di seguire un flusso costante.

Passaggio 1 — Recupera i log

I log si trovano in uno di due luoghi, oppure in entrambi:

• Log del server origin. Apache (access.log), Nginx (access.log) o il server applicativo. Ogni riga contiene almeno: timestamp, IP del client, metodo + percorso della richiesta, codice di stato, byte, referrer e user agent.
• Log CDN / edge. Se il sito è dietro Cloudflare, Fastly, Akamai e così via, molto traffico dei bot viene gestito all’edge e potrebbe non raggiungere mai l’origin: perciò il log edge è il registro più completo. Cloudflare lo espone tramite Logpush (e un’API GraphQL); Fastly tramite lo streaming dei log in tempo reale.

I campi che ti servono davvero per l’analisi dei bot AI sono: timestamp, IP del client, user agent, percorso della richiesta, codice di stato, e idealmente byte e referrer.

Il problema pratico è la conservazione. L’articolo di Lauren Busby su Search Engine Land indica direttamente la soluzione: un’acquisizione programmata trasforma una finestra breve in qualcosa che puoi analizzare nel tempo; un job SFTP pianificato, costruito in uno strumento di workflow come n8n o sotto forma di script, basta a trasformare una finestra di conservazione breve in dati analizzabili nel tempo (Busby, SEL). Configuralo prima di averne bisogno.

Tieni presente fin dall’inizio anche un limite onesto: come dice Busby, i file di log mostrano ciò che ha raggiunto il sito, ma non sempre ciò che ha tentato di raggiungerlo (SEL): le richieste bloccate o risposte a monte potrebbero non comparire affatto.

Passaggio 2 — Verifica prima di fidarti dello user agent

Questo è il passaggio che distingue l’analisi dei log dei bot AI dalla versione classica e che la maggior parte delle guide concorrenti salta. Le stringhe user agent sono banalmente falsificabili. Due dati indipendenti mostrano quanto può essere grave:

• HUMAN Security ha analizzato due settimane di traffico che dichiarava di provenire da uno dei 16 crawler AI più noti e ha rilevato che il 5,7% era falsificato, circa 1 richiesta su 18 (riportato da SEJ).
• Duane Forrester ha eseguito lo stesso controllo sui propri log e ha trovato un risultato molto peggiore. Delle 33 richieste con un nome di recupero live, sei provenivano da un IP pubblicato dal vendor e ventisette no: un tasso di spoofing dell’81,8% tra le richieste verificabili (SEJ). Il suo dato su Googlebot era ancora peggiore: delle 799 richieste con il nome Googlebot, solo 107 provenivano da un indirizzo Google verificato; le altre, circa l’87%, non erano Google (SEJ).

Considera questi numeri come indicativi di campioni e metodi diversi, non come un unico numero universale. Ancora più importante: non generalizzare il metodo di verifica di un provider a tutti i bot. Alcuni operatori pubblicano intervalli di indirizzi; altri documentano token user agent senza un intervallo pubblico corrente o un contratto di verifica DNS (SEJ).

Il metodo di verifica:

1. Abbina la stringa user agent. GPTBot si identifica come Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBot e ChatGPT-User contengono i propri token (documentazione bot OpenAI).
2. Usa l’attuale metodo ufficiale di verifica del provider quando ne esiste uno. OpenAI pubblica openai.com/gptbot.json, searchbot.json e chatgpt-user.json. L’attuale documentazione sui crawler di Anthropic dice che un indirizzo nell’elenco pubblicato proviene da un crawler Anthropic. Usa il metodo specifico e corrente del provider; non trasformarlo in una regola universale di verifica dei bot.
3. Non inventare un fallback. Il DNS inverso più diretto è valido per un provider solo quando quel provider pubblica il suffisso hostname previsto e la procedura di verifica. Un generico match PTR dimostra il controllo del DNS, non l’identità dichiarata del bot. Log File Analyser di Screaming Frog può applicare gli elenchi pubblicamente confermati quando disponibili; la sua funzione di verifica all’importazione esegue una ricerca rispetto a elenchi IP pubblicamente confermati per verificare che i bot siano autentici (Screaming Frog).

La verifica deve guidare policy precise e la risposta agli incidenti. Preferisci il token robots documentato dal provider per una policy di scansione; riserva i controlli di rete ai casi di abuso o sicurezza e indicateli separatamente dalla conformità a robots.

Passaggio 3 — Scegli lo strumento

Adatta lo strumento alla dimensione del lavoro, più o meno da gratuito a pagamento e da fonte di verità a gestito:

• grep / PowerShell — conteggio rapido una tantum e filtro consapevole della verifica. L’articolo Crawlers AI contiene lo snippet di base per contare i bot; la scheda Scripts qui lo estende alla verifica degli IP, alla suddivisione per codice di stato e al rilevamento crawl rispetto a rendering.
• Screaming Frog Log File Analyser — importatore desktop con preset integrati per i bot AI (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) e un’opzione “Verify Bots When Importing”. La scheda Response Codes divide 2XX/3XX/4XX/5XX per URL, User Agents mostra richieste e tassi di errore per bot, URLs ordina per Num Events (le pagine più recuperate) e IPs permette di esaminare le fonti sospette (tutorial).
• ELK Stack (Elasticsearch / Logstash / Kibana) o Splunk — acquisizione continua su scala maggiore, dashboard e avvisi quando un import desktop singolo diventa troppo lento o vuoi monitorare costantemente invece di esportare periodicamente.
• BigQuery — conservazione a lungo termine e query SQL su scala, alimentato di solito da Cloudflare Logpush o da una query GraphQL pianificata sul dataset httpRequestsAdaptiveGroups di Cloudflare, così puoi interrogare l’attività dei bot per pagina, data e codice di stato senza reimportare file piatti.
• Cloudflare AI Crawl Control (per i siti dietro Cloudflare) — dashboard gestita per l’attività e i pattern delle richieste dei crawler, la verifica dei bot e il monitoraggio della conformità alle direttive, senza costruire una pipeline proprietaria (documentazione).

Passaggio 4 — Cosa misurare e come leggerlo

Frequenza di scansione per bot. Hit al giorno/settimana per nome del bot. I bot AI scansionano a raffiche, non con flussi regolari. Nel caso di studio sui log CDN di 48 giorni di WISLR, GPTBot era assente per settimane, poi ha effettuato 187 richieste in una sola settimana — 152 in una raffica di tre minuti, con un picco di 114 richieste al minuto (WISLR). Leggi la frequenza come un pattern, non solo come un totale.

Quali pagine vengono visitate e quali importanti no. Ordina per numero di richieste. Busby osserva che i crawler AI spesso restano superficiali: è comune vederli limitati alle pagine di primo livello, cioè homepage, navigazione principale e pochi URL di alto livello (SEL); poi il traffico cala nettamente sulle pagine profonde anche quando sono quelle che contano di più per le citazioni. Una pagina profonda che non compare mai nei log non può essere recuperata.

Dipendenza dall’HTML grezzo — misurala, non universalizzarla. La documentazione dei provider non definisce un unico contratto condiviso di rendering JavaScript per GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot e gli altri agenti. Un segnale osservato resta utile: nel campione WISLR, ChatGPT-User ha recuperato solo HTML — zero richieste di immagini, CSS o file JS — mentre Googlebot e OAI-SearchBot hanno recuperato anche immagini (WISLR). Se i log mostrano bot AI che insistono su pagine il cui HTML grezzo è quasi solo uno shell JS, è un rischio di dipendenza verificabile, non la prova che ogni provider si comporti sempre così. Confronta l’HTML consegnato con i risultati o con test di recupero specifici del provider. (Per i fondamenti del rendering, vedi SEO JavaScript.)

Suddivisione per codice di stato / blocco. Osserva: 200 (successo), 304 (non modificato — ricrawl efficiente), 404 (link non funzionanti seguiti dal bot) e 403/429 (bloccato / soggetto a rate limit). Busby sottolinea nello specifico che i file di log fanno emergere dove i crawler incontrano problemi, comprese risposte 403 (richieste bloccate) e 429 (rate limiting) (SEL). Controlla se il blocco è intenzionale o accidentale.

Richieste robots.txt e llms.txt come segnale autonomo. Incrocia quali bot richiedono /robots.txt prima di scansionare: nel campione WISLR GPTBot e Meta-WebIndexer non lo hanno mai controllato in 48 giorni, e verifica se vengono visitati percorsi non consentiti. WISLR ha inoltre registrato zero richieste a /llms.txt da qualunque bot AI negli stessi 48 giorni (WISLR), in linea con il risultato di circa il 97% di mancata lettura discusso nell’articolo Crawlers AI. Non aspettarti richieste a llms.txt nei log come prova che “funziona”.

Più scansioni significano più citazioni? Sii onesto.

Nessun dato consolidato dimostra “più scansioni, più citazioni”. Il recupero è una condizione necessaria per una citazione, ma ben lontana dall’essere sufficiente: le pagine vengono scansionate continuamente senza essere mai citate, per esempio a causa del rendering lato client, di paywall, contenuti sottili o duplicati, oppure semplicemente perché il modello sceglie una fonte migliore nella fase di recupero/ranking. La cornice che tiene insieme il ragionamento è nell’articolo Visibilità LLM: recuperato → menzionato → citato; l’analisi dei log osserva solo il primo stadio.

Il modo onesto di chiudere il ciclo è affiancare il lato dell’input di scansione (i log) al lato dell’output delle citazioni. Il rapporto AI Performance di Bing (anteprima pubblica, febbraio 2026) è il primo strumento ufficiale a esporre dati sulle citazioni insieme alle query di grounding: le frasi chiave che l’AI ha usato durante il recupero dei contenuti poi citati nelle risposte generate dall’AI (Bing Webmaster Blog). I log dicono cosa è stato prelevato; query di grounding e conteggi delle citazioni dicono cosa ne è derivato. Nessuno dei due offre il quadro completo: consulta l’hub di misurazione e reportistica per capire come si sovrappongono questi livelli.

La complicazione dello stealth crawling

La verifica non è un audit da fare una sola volta. Secondo Clint Spaulding di Seer Interactive, dopo essere stati bloccati i crawler stealth possono ricomparire con header generici del browser e IP non correlati: nei log queste sessioni sembrano umane, quindi i conteggi delle sessioni si gonfiano, il traffico dei bot viene sottostimato e la segmentazione GEO diventa meno affidabile (Seer). La sua sintesi diretta è: se non riesci a vedere questi crawler stealth, non puoi misurarne l’impatto. Ecco perché l’analisi dei log richiede verifiche periodiche e nuove baseline, non un solo passaggio.

Riepilogo AI

Una sintesi della versione Advanced:

• Analisi dei log dei crawler AI = lettura dei log grezzi del server/CDN per le richieste dei bot AI, così da verificare con dati di prima parte quali bot hanno raggiunto il sito, se sono autentici e cosa hanno ricevuto. GSC (solo Googlebot) e GA4 (solo referrer) non lo vedono.
• Perimetro: questo articolo descrive il metodo. Cosa sono i bot è materia di Crawlers AI; il lato dei clic è in Attribuzione del traffico AI; il modello recuperato → menzionato → citato è in Visibilità LLM (i log osservano soltanto il recuperato).
• Separa l’identità verificata dallo user agent dichiarato. Gli user agent vengono falsificati: HUMAN Security ha misurato il 5,7% su 16 bot; Duane Forrester ha verificato personalmente l’81,8% di falsi tra le richieste di recupero live (87% per Googlebot). Abbina lo UA e controlla l’IP sorgente rispetto all’elenco ufficiale corrente dell’operatore quando esiste (per esempio openai.com/gptbot.json o claude.com/crawling/bots.json di Anthropic). Non inventare un fallback DNS inverso generico.
• Strumenti per scala: grep → Screaming Frog LFA (preset AI + verifica all’importazione) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• Misura: frequenza di scansione per bot (a raffiche, per esempio le 152 richieste GPTBot di WISLR in 3 minuti), pagine visitate, dipendenza dall’HTML grezzo (nel campione WISLR ChatGPT-User ha recuperato zero immagini/CSS/JS), codici di stato (403/429) e richieste robots.txt/llms.txt (WISLR ha registrato zero hit llms.txt in 48 giorni).
• Scansione ≠ citazione. Il recupero è necessario, non sufficiente: “più scansioni = più citazioni” non è dimostrato. Affianca i log alle query di grounding di Bing per chiudere il ciclo.
• Ripeti periodicamente la verifica: i crawler stealth bloccati riemergono con sembianze umane.

Documentazione ufficiale

Fonti primarie: i file di verifica dei gestori dei bot e la documentazione delle piattaforme.

OpenAI

• Documentazione OpenAI su bot e crawler — stringhe user agent e comportamento di GPTBot, OAI-SearchBot, ChatGPT-User e OAI-AdsBot.
• Elenchi IP pubblicati per la verifica: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• Come Anthropic esegue il crawling del web — nomi correnti dei bot, scopi, controlli robots e indicazione che un indirizzo nell’elenco pubblicato proviene da un crawler Anthropic.
• Elenco IP dei crawler Anthropic — fonte di verifica condivisa e corrente per ClaudeBot, Claude-SearchBot e Claude-User.

Google

• Rapporto Statistiche di scansione — la vista proprietaria di Google sull’attività di scansione (solo Googlebot; non copre i bot AI di terze parti, motivo per cui per loro servono i log grezzi).

Cloudflare

• AI Crawl Control — dashboard gestita per attività dei crawler AI, verifica dei bot e conformità alle direttive.

Bing / Microsoft

• Presentazione di AI Performance in Bing Webmaster Tools (anteprima pubblica) — il corrispettivo dell’esito delle citazioni rispetto all’analisi dei log: citazioni totali, pagine citate medie, query di grounding e attività delle citazioni a livello di pagina.

Citazioni dalla fonte

Dichiarazioni pubbliche di operatori e professionisti nominati.

Anthropic — perimetro corrente

• L’attuale pagina di supporto di Anthropic distingue ClaudeBot, Claude-SearchBot e Claude-User, documenta come si applicano i controlli robots e afferma che un indirizzo nell’elenco pubblicato indica un crawler Anthropic. Fonte

Lauren Busby, cofondatrice di Trebletree — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (traduzione) «I file di log sono ciò che più si avvicina a quello strato mancante. Non riassumono né interpretano l’attività: la registrano, richiesta per richiesta, URL per URL, crawler per crawler.»
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (traduzione) «Strumenti come Screaming Frog Log File Analyzer permettono di elaborare rapidamente quei dati.»
• Sulla profondità: “It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (traduzione) «È comune vederli limitati alle pagine di primo livello: homepage, navigazione principale e pochi URL di alto livello.»
• Sugli errori: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (traduzione) «I file di log mostrano anche dove i crawler incontrano problemi, comprese risposte 403 per richieste bloccate e 429 per limitazione della frequenza.»
• Sulla conservazione: “A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (traduzione) «Un processo SFTP pianificato, creato in uno strumento come n8n o tramite script, basta a trasformare una breve finestra di conservazione in dati analizzabili nel tempo.»
• Il limite: “Log files show you what reached your site. They don’t always show you what tried to.” (traduzione) «I file di log mostrano ciò che ha raggiunto il sito, ma non sempre ciò che ha tentato di farlo.» Fonte

Duane Forrester — Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (traduzione) «Su 33 richieste con uno di quei nomi di recupero live, sei provenivano da un IP pubblicato dal fornitore e ventisette no: l’81,8% delle richieste verificabili era falsificato.»
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (traduzione) «Il controllo effettivo non è complicato: i principali operatori pubblicano gli indirizzi IP usati dai bot e una richiesta è legittima solo se il nome corrisponde e l’indirizzo rientra nell’elenco pubblicato.»
• Per Googlebot: “Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (traduzione) «Su 799 richieste con il nome Googlebot, solo 107 provenivano da un indirizzo Google verificato; le altre 692, circa l’87%, non provenivano da Google.»
• Metodo: “Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (traduzione) «Non prendete i miei numeri, prendete il metodo: estraete un intervallo di date, abbinate i nomi, verificate gli IP rispetto agli elenchi pubblicati e calcolate la vostra percentuale reale.» Fonte

Clint Spaulding, responsabile tecnico SEO, Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (traduzione) «Dopo essere stati bloccati, i crawler stealth possono ricomparire con header generici del browser e IP non correlati.»
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (traduzione) «Nei log queste sessioni sembrano umane: il conteggio delle sessioni si gonfia, il traffico dei bot viene sottostimato e la segmentazione GEO diventa meno affidabile.»
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (traduzione) «Se non riesci a vedere questi crawler stealth, non puoi misurarne l’impatto.» Fonte

Screaming Frog — tutorial Log File Analyser (documentazione del prodotto)

• Sulla verifica durante l’importazione: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (traduzione) «I bot dei motori di ricerca vengono spesso falsificati; questa funzione confronta gli IP con elenchi pubblicamente confermati per verificarne l’autenticità.»
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (traduzione) «Se osservi volumi elevati di richieste da IP non verificati, probabilmente si tratta di traffico bot falso da bloccare a livello server.» Fonte

Bing Webmaster Tools — rapporto AI Performance (anteprima pubblica di febbraio 2026)

• Query di grounding: “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (traduzione) «Mostra le frasi chiave usate dall’IA per recuperare contenuti poi citati nelle risposte generate dall’IA.»
• Citazioni totali: “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (traduzione) «Mostra il numero totale di citazioni visualizzate come fonti nelle risposte generate dall’IA durante l’intervallo selezionato.» Fonte

”Questa richiesta del bot AI è reale? E cosa devo farne?”

Segui una singola riga di log sospetta — o tutto il traffico di un bot — usando questo percorso. È la logica di verifica del Passaggio 2 trasformata in un flusso.

Checklist per l’analisi dei log dei crawler AI

Un passaggio ripetibile, dall’estrazione dei log alla loro lettura:

• I log vengono acquisiti con i campi necessari: timestamp, IP del client, user agent, percorso della richiesta, codice di stato (byte e referrer sono utili).
• Stai estraendo dal livello giusto: log CDN/edge se sei dietro Cloudflare/Fastly (molto traffico dei bot non raggiunge mai l’origin).
• Un’acquisizione programmata (SFTP/n8n/script) supera la finestra di conservazione, così hai una storia e non solo gli ultimi giorni.
• Ogni richiesta di un bot AI è verificata: user agent abbinato e IP sorgente confrontato con l’elenco pubblicato dall’operatore (DNS inverso come supporto).
• Le richieste falsificate/non verificate sono escluse dalle metriche di scansione AI e non conteggiate come il bot dichiarato.
• La frequenza di scansione è baselined per bot (osserva pattern a raffiche rispetto a flussi costanti).
• Sono state identificate le pagine più recuperate e confermato che le pagine profonde importanti vengano effettivamente scansionate.
• È stato controllato crawl rispetto a rendering: i bot AI recuperano solo HTML su pagine il cui contenuto è renderizzato in JS? (Registralo come test di dipendenza dall’HTML grezzo; il comportamento del provider è specifico dell’agente e potrebbe non essere documentato.)
• I codici di stato sono stati esaminati: 200/304 sani; 404 link non funzionanti; 403/429 confermati intenzionali o corretti.
• È stata controllata la presenza di richieste a robots.txt (i bot lo recuperano prima di scansionare?) e l’assenza di hit inattesi su percorsi non consentiti.
• I dati sono stati affiancati a quelli del lato citazioni (query di grounding Bing / funzioni AI di GSC) prima di trarre conclusioni su “funziona o no”.
• È stata pianificata una nuova verifica: non è un audit una tantum (i crawler stealth riemergono con sembianze umane).

Scheda rapida per l’analisi dei log dei crawler AI

File di verifica (mettili nei segnalibri)

Codici di stato da osservare

Verifica, non fidarti

• Il solo user agent = non verificato. Abbina UA e dati di verifica pubblicati dal provider quando disponibili; altrimenti conserva l’incertezza.
• Tassi di spoofing osservati sul campo: 5,7% (HUMAN, 16 bot) → 81,8% (log di recupero live di Forrester); 87% di Googlebot falso nello stesso audit.

Segnale di dipendenza dall’HTML grezzo

• Un bot che recupera solo HTML con zero richieste .js/.css/immagini mostra un pattern osservato. Su una pagina dipendente da JS è un segnale di rischio, non una prova universale delle capacità del bot.

Fatti rapidi

• Frequenza di scansione ≠ probabilità di citazione. Il recupero è necessario, non sufficiente.
• Usa i token robots documentati per la policy di scansione; mantieni il blocco di rete come controllo separato per abuso/sicurezza.

Script per l’analisi dei log dei crawler AI

L’articolo Crawlers AI contiene lo snippet di base per “contare gli hit del bot”. Questi script fanno un passo in più: estrazione, verifica, suddivisione per codice di stato e rilevamento del crawl rispetto al rendering.

1. Estrai ogni riga di bot AI (grep + regex)

macOS / Linux — una sola alternanza sugli user agent AI più comuni:

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

Versione Windows PowerShell:

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. Verifica un IP GPTBot dichiarato rispetto all’elenco pubblicato da OpenAI

Il solo user agent non dimostra nulla: controlla l’IP. Questo comando scarica l’elenco OpenAI e verifica se un IP dei log rientra in uno dei CIDR pubblicati:

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Per Anthropic, recupera l’elenco corrente https://claude.com/crawling/bots.json e adatta il percorso jq alla struttura documentata. Se un altro operatore non pubblica un feed di verifica corrente, conserva il risultato come user agent dichiarato.

3. Fallback DNS inverso + diretto (IP fuori elenco)

Usalo solo quando il provider nominato pubblica un suffisso hostname previsto e la procedura di verifica inversa + diretta. Non è una prova generica dell’identità del bot:

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. Suddivisione dei codici di stato per bot

Individua i blocchi 403/429 e le pagine non trovate incontrate dai bot:

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. Segnale di dipendenza dall’HTML grezzo — quali tipi di file recupera il bot?

Se un bot dichiarato recupera sempre e solo .html// e mai .js/.css/immagini, mentre il contenuto dipende dal rendering JS, è un segnale di dipendenza da indagare:

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Console Chrome DevTools — individua i fetcher AI su una pagina live

Non è una query di log, ma un controllo rapido di ciò che la pagina consegna nell’HTML grezzo rispetto a ciò che consegna dopo JS (cioè ciò che un bot AI potrebbe o non potrebbe vedere). Incollalo nella Console:

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. Bookmarklet — apri in una volta tutti gli elenchi IP dei bot

Trascinalo nei segnalibri per aprire in schede i file di verifica e consultarli rapidamente:

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP: revisione mensile dei log dei crawler AI

Una procedura ricorrente da eseguire a intervalli regolari (mensile per la maggior parte dei siti; settimanale se il traffico AI è importante). Produce ogni volta una baseline confrontabile.

Preparazione

1. Estrai la finestra di log dall’ultima revisione dal livello corretto (log CDN/edge se sei dietro un CDN, altrimenti log origin). Conferma che l’acquisizione SFTP pianificata tramite n8n sia stata eseguita: eventuali lacune interrompono silenziosamente le linee di tendenza.
2. Carica i dati nello strumento di riferimento (Screaming Frog LFA per importazioni periodiche; BigQuery/ELK se usi una pipeline).

Verifica (mai saltarla) 3. Aggiorna ogni fonte di verifica pubblicata dal provider corrente (gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json e claude.com/crawling/bots.json di Anthropic): cambiano. 4. Attiva la verifica all’importazione (Screaming Frog) oppure esegui il controllo IP-in-CIDR (scheda Scripts) su ogni richiesta di un bot AI. 5. Separa il traffico in verificato e non verificato. Riporta la frazione non verificata: è il tasso di spoofing del periodo. Un aumento è già di per sé un risultato.

Misura (solo traffico verificato) 6. Frequenza di scansione per bot rispetto al periodo precedente: annota bot nuovi, scomparsi e raffiche. 7. Pagine più recuperate; conferma che le pagine prioritarie/profonde vengano effettivamente scansionate. 8. Controllo puntuale della dipendenza dall’HTML grezzo su 2–3 template con molto JS (i bot recuperano solo HTML?). 9. Suddivisione dei codici di stato per bot; indaga nuovi gruppi 403/429/404. 10. Presenza di richieste a robots.txt / llms.txt ed eventuali hit su percorsi non consentiti.

Riporta e agisci 11. Registra i numeri del periodo in un foglio aggiornato (hit verificati per bot, spoof %, pagine principali, gruppi di errori) per avere una tendenza, non istantanee isolate. 12. Affianca i dati al lato citazioni (query di grounding Bing / funzioni AI di GSC) prima di trarre conclusioni sulla visibilità. 13. Inserisci correzioni concrete: blocchi intenzionali rispetto ad accidentali, lacune di rendering JS, link non funzionanti, regole user agent precise per gli impersonatori confermati.

Nota sulla cadenza: ripeti la verifica a ogni periodo: non memorizzare un elenco IP “noto e buono”. I crawler stealth riemergono con nuovi IP e user agent generici del browser.

Playbook: “GPTBot (o ClaudeBot) riceve 403/429 e non so se sia intenzionale”

Un runbook lineare per l’incidente comune: un bot AI verificato incontra errori nei log. Seguilo nell’ordine.

Passaggio 1 — Conferma prima che sia il bot reale. Prima di tutto, usa il metodo ufficiale corrente di verifica del provider nominato. Se non esiste, l’identità resta non verificata: non promuoverla silenziosamente ad autentica né declassarla a falsificata. Il 403 potrebbe comunque essere il tuo WAF che sta facendo il proprio lavoro.

Passaggio 2 — Identifica la risposta esatta e la sua provenienza. Recupera la suddivisione dei codici di stato per quel bot (scheda Scripts). È 403 (bloccato), 429 (rate-limited) o 503? Annota se il blocco proviene dal CDN/WAF, dalla configurazione del server o da regole vicine a robots.txt.

Passaggio 3 — Decidi: il blocco è intenzionale?

• Volevi bloccare questo bot (per esempio un crawler di addestramento da cui hai scelto di escluderti) → il 403 funziona come progettato. Mantieni separata la policy robots documentata da qualsiasi regola di abuso/sicurezza a livello di rete. Fine.
• NON volevi bloccarlo (per esempio è OAI-SearchBot / PerplexityBot e vuoi visibilità nella ricerca AI) → continua.

Passaggio 4 — Trova la regola accidentale. Colpevoli comuni: una regola WAF “bot” troppo ampia, una soglia di rate limit troppo bassa per un crawler a raffiche (ricorda il picco di 114 richieste/minuto di GPTBot osservato da WISLR: un limite al minuto può scattare durante raffiche legittime), un disallow in robots.txt che avevi dimenticato o un blocco per area geografica/ASN che intercetta gli intervalli dell’operatore.

Passaggio 5 — Correggi con precisione. Inserisci in whitelist il bot verificato usando user agent + intervallo IP pubblicato, oppure alza il limite di rate limit solo per quel bot verificato. Non allentare la protezione per tutti.

Passaggio 6 — Verifica la correzione nei log. Dopo il deploy, estrai di nuovo i log per quel bot. Vuoi che il gruppo 403/429 si trasformi in 200/304 sulle pagine che ti interessano.

Passaggio 7 — Crea una nuova baseline e osserva. Annota il cambiamento nel foglio aggiornato. Ricontrolla nel periodo successivo e resta attento alla ricomparsa del bot con uno UA diverso se avevi davvero scelto di bloccarlo (stealth crawling).

Errori di analisi dei log che producono conclusioni sbagliate

Ognuno è una convinzione diffusa, il motivo per cui è sbagliata e cosa fare invece.

Mito: “Se robots.txt blocca un bot, non sarà nei log / non è un problema.” Perché è sbagliato: robots.txt è una richiesta, non un meccanismo di enforcement. I fetcher avviati dall’utente si sottraggono esplicitamente e alcuni crawler sono stati segnalati come capaci di aggirare i blocchi (stealth crawling di Perplexity, Cloudflare agosto 2025). Il blocco potrebbe essere ignorato del tutto. Fai invece: usa i log per controllare se la regola viene rispettata: cerca hit su percorsi non consentiti e verifica se il bot richiede almeno /robots.txt.

Mito: “Uno user agent GPTBot / ClaudeBot nei log significa che è davvero OpenAI / Anthropic.” Perché è sbagliato: gli user agent sono banalmente falsificabili: HUMAN Security ha misurato il 5,7% di falsi su 16 bot e Duane Forrester ha trovato l’81,8% di falsi tra le proprie richieste di recupero live. Fai invece: abbina lo user agent e usa il metodo ufficiale corrente di verifica dell’operatore quando esiste; altrimenti contrassegna l’identità come non verificata.

Mito: “Più hit dei crawler AI = più probabilità di essere citati.” Perché è sbagliato: nessun dato consolidato di causalità o correlazione lo dimostra. Il recupero è necessario ma non sufficiente: le pagine fortemente scansionate restano continuamente senza citazioni. Fai invece: considera i log come visibilità soltanto sulla fase recuperato e affiancali a dati sul lato citazioni (query di grounding Bing, funzioni AI di GSC).

Mito: “Ogni crawler AI ha lo stesso comportamento di rendering.” Perché è sbagliato: i provider non pubblicano un unico contratto condiviso per JavaScript e sotto-risorse, e il comportamento osservato cambia in base all’agente e al campione. Fai invece: confronta la risposta grezza con la pagina renderizzata, esamina le richieste di sotto-risorse per bot nominato e descrivi il risultato come osservato, non universale.

Mito: “I bot AI controllano almeno il mio llms.txt.” Perché è sbagliato: il campione WISLR di 48 giorni ha registrato zero richieste /llms.txt da qualunque bot AI, in linea con il risultato di circa il 97% di mancata lettura riportato nell’articolo Crawlers AI. Fai invece: non considerare le richieste llms.txt una validazione attesa; misura ciò che i bot recuperano davvero.

Mito: “Il blocco di rete e la policy robots sono lo stesso controllo.” Perché è sbagliato: robots comunica preferenze di scansione; un firewall impone l’accesso di rete e può influire su traffico non correlato. Fai invece: usa la regola user agent documentata per la policy e riserva il blocco di rete a una risposta di abuso/sicurezza giustificata separatamente.

Casi reali

Duane Forrester — tassi di spoofing misurati sui propri log. Forrester ha applicato questo metodo al proprio sito e ha pubblicato i numeri. Tra 33 richieste di recupero live, solo 6 provenivano da un IP pubblicato dal vendor: un tasso di spoofing dell’81,8%; tra 799 richieste con nome Googlebot, solo 107 erano verificate — circa l’87% era falso (SEJ). Prima: fidandosi dello user agent, il traffico del suo “assistente AI” sembrava autentico. Dopo: abbinando i nomi agli elenchi IP pubblicati, la maggior parte era impersonificazione. Lezione: il metodo conta più dei numeri specifici del suo campione; come dice lui, estrai il tuo intervallo di date e trova la tua frazione reale.

WISLR — 48 giorni di log CDN, il segnale crawl rispetto a rendering. Tony Castillo ha analizzato 288 566 righe di log CDN (12 099 richieste AI/bot) in 48 giorni (WISLR). Risultati concreti: GPTBot era assente per settimane, poi ha generato una raffica di 152 richieste in tre minuti (picco di 114 richieste/minuto); ChatGPT-User ha recuperato zero immagini, CSS o JS — pura estrazione HTML; e nell’intera finestra ci sono state zero richieste /llms.txt. Prima: avresti ipotizzato scansione costante e bot consapevoli del JS. Dopo: i log mostrano un comportamento a raffiche e solo HTML — n=1, dati di un solo sito, ma un quadro vivido di ciò che può far emergere un’analisi reale. Lezione: il pattern di recupero senza JS è l’evidenza diretta alla base del controllo crawl rispetto a rendering.

Cloudflare — rapporto crawl-to-referral, su scala di rete. I dati aggregati di Cloudflare mostrano quanto poco crawling si traduca in traffico: per ogni visitatore che Anthropic rimanda a un sito, i suoi crawler hanno già visitato decine di migliaia di pagine (Cloudflare). Prima: l’intuizione che molto crawling significhi engagement. Dopo: su scala di rete il rapporto è sbilanciato: l’addestramento genera ormai la maggior parte dell’attività dei bot AI e i bot di addestramento non hanno lo scopo di rimandare traffico (Cloudflare). Lezione: una pagina scansionata intensamente senza alcun referral è normale, non un segnale di successo — proprio per questo la frequenza di scansione non predice le citazioni.

Prompt AI pronti all’uso

Prompt da copiare e incollare per usare un LLM e velocizzare l’analisi dei log dei crawler AI. Controlla sempre il risultato rispetto ai log grezzi: gli LLM allucinano e una pipeline di verifica che si fida di un match IP allucinato è peggiore di nessuna pipeline.

Crea un parser dei log consapevole della verifica

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

Riassumi un report di codici di stato + crawl rispetto a rendering

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

Classifica un IP sospetto

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

Strumenti per l’analisi dei log dei crawler AI

Più o meno da gratuito/fonte di verità a pagamento/gestito:

• grep / PowerShell — il modo più rapido per contare gli hit dei bot e applicare un filtro consapevole della verifica a un log di accesso grezzo. Nessuna configurazione; vedi la scheda Scripts.
• Screaming Frog Log File Analyser — importatore desktop con preset integrati per i bot AI e un’opzione “Verify Bots When Importing” che confronta gli IP con elenchi pubblicamente confermati. Schede Response Codes, User Agents, URLs (ordina per Num Events) e IPs. Ideale per importazioni periodiche.
• ELK Stack (Elasticsearch / Logstash / Kibana) o Splunk — acquisizione continua, dashboard e avvisi quando un import desktop è troppo lento o vuoi monitorare in modo costante.
• BigQuery — conservazione a lungo termine e SQL su scala, alimentato di solito da Cloudflare Logpush o da un pull GraphQL pianificato dal dataset httpRequestsAdaptiveGroups di Cloudflare.
• Cloudflare AI Crawl Control — per i siti dietro Cloudflare: viste gestite su attività dei crawler, verifica dei bot e conformità alle direttive senza una pipeline proprietaria.
• Google Search Console — Statistiche di scansione — non per i bot AI (solo Googlebot), ma il modello della suddivisione per crawler e codice di risposta che stai ricostruendo dai log grezzi.
• Bing Webmaster Tools — AI Performance — il corrispettivo del risultato delle citazioni: affianca query di grounding e conteggi delle citazioni ai log dell’input di scansione per chiudere il ciclo.

Traffico dichiarato dei bot AI che aumenta durante la notte

Sintomo: le richieste con lo user agent di un crawler famoso aumentano improvvisamente. Causa probabile: spoofing, traffico di monitoraggio o un vero cambiamento della scansione. Correzione: verifica gli IP sorgente con il metodo corrente pubblicato dall’operatore prima di attribuire il traffico, poi segmenta per ASN, percorso, stato e ora.

I log mostrano scansioni ma i contenuti non vengono mai citati

Sintomo: i bot verificati recuperano pagine senza guadagni visibili nelle citazioni. Causa probabile: la scansione è solo un’evidenza di idoneità; recupero e selezione della risposta sono fasi separate. Correzione: conferma che il bot abbia ricevuto HTML sostanziale, poi valuta indicizzabilità, qualità dei passaggi, adeguatezza alla query e corroborazione esterna senza trattare il conteggio delle scansioni come ranking.

Ogni richiesta sembra restituire 200

Sintomo: URL mancanti e contenuti bloccati vengono registrati come successi. Causa probabile: uno shell applicativo, una regola CDN o una pagina di errore personalizzata restituisce un soft 404. Correzione: campiona i corpi delle risposte e gli header finali, poi correggi la gestione degli stati invece di fidarti solo del codice.

I bot verificati ricevono uno shell vuoto

Sintomo: il browser renderizza il contenuto, ma i fetch abbinati ai log ricevono poco HTML utile. Causa probabile: la pagina dipende da JavaScript lato client che il crawler non esegue. Correzione: confronta output grezzo e renderizzato e servi contenuti e link essenziali nell’HTML tramite SSR, rendering statico o un’altra strategia di consegna affidabile.

Metriche per i log dei crawler AI

Risorse che meritano il tuo tempo

I miei contenuti correlati

• Come eseguire un’analisi SEO dei file di log (Ahrefs, revisionato da Patrick Stox e Michal Pecánek) — il modello dell’era pre-AI di cui questo articolo è il seguito specifico per l’AI: cosa misurare, strumenti e verifica dei bot.
• What is Log File Analysis? (glossario Ahrefs) — il contenuto di riferimento per la definizione.
• I nuovi crawler web: i bot IA si avvicinano ai bot dei motori di ricerca — la mia analisi di Cloudflare Radar sulla quota di scansione dei bot AI.
• I bot IA più bloccati da circa 140 milioni di siti — dati sui tassi di blocco robots.txt nel web aperto.
• L’80% del nostro traffico dalla ricerca IA arriva a homepage, pagine prodotto e strumenti gratuiti — analisi per tipo di pagina dell’attività AI, l’analogo di “quali pagine vengono scansionate”.

I miei interventi

• How Search Works (SlideShare) — il mio percorso su scansione, rendering, indicizzazione e ranking, utile come contesto per leggere ciò che fanno i bot nei log. (Vale la precisazione abituale: questa è la mia comprensione dei sistemi, non la garanzia che sia completa o accurata al 100%.)

Dal settore

• Perché l’analisi dei log conta per i crawler IA e la visibilità nella ricerca — Lauren Busby: il tema dei “log come strato mancante”, della finestra di conservazione e di 403/429.
• L’81,8% del traffico dei miei assistenti IA era falso; per Googlebot era peggio — Duane Forrester, Search Engine Journal: il caso di studio e il metodo di verifica in prima persona più significativo.
• Perplexity, crawling IA stealth e impatti su GEO e analisi dei log — Clint Spaulding: perché i bot bloccati ricompaiono con sembianze umane.
• Come monitorare i bot IA in Log File Analyser — Screaming Frog: guida pratica allo strumento con verifica all’importazione.
• Il divario tra crawling e clic nei dati Cloudflare — Cloudflare: rapporti crawl-to-referral a livello di rete e separazione tra addestramento e ricerca.
• Come Anthropic esegue il crawling del web — documentazione corrente di Anthropic sugli scopi dei bot e i controlli robots.
• OpenAI bots / crawlers docs — stringhe user agent e file IP pubblicati per la verifica.

Statistiche da citare

• Tasso di spoofing — 5,7% su 16 crawler AI. L’analisi di due settimane di HUMAN Security sul traffico che dichiarava di provenire da uno dei 16 crawler AI più noti ha rilevato che circa 1 richiesta su 18 era falsificata (dato del vendor, riportato da SEJ).
• Tasso di spoofing — 81,8% nei log personali di un professionista. L’audit di Duane Forrester ha rilevato che 27 delle 33 richieste di recupero live provenivano da IP non pubblicati dai vendor; il suo dato Googlebot era falso per circa l’87% (SEJ).
• Crawl-to-referral, ClaudeBot rispetto a OpenAI. I dati Cloudflare (settimana dal 25 maggio al 1° giugno 2026) indicavano circa 11 122 pagine scansionate per referral per ClaudeBot e 857:1 per OpenAI, contro circa 5:1 per Googlebot (Cloudflare).
• L’addestramento genera la maggior parte dell’attività dei bot AI. Secondo Cloudflare, l’addestramento genera ormai quasi l’80% dell’attività dei bot AI, rispetto al 72% dell’anno precedente: un contesto per cui molto crawling senza referral è normale (Cloudflare).
• Una finestra reale di log: 288 566 righe, 12 099 richieste bot, 48 giorni. Il caso di studio WISLR, con la raffica di 152 richieste GPTBot in 3 minuti e i recuperi zero immagini/CSS/JS di ChatGPT-User (WISLR).

Mettiti alla prova: analisi dei log dei crawler AI

Cinque domande rapide sull’estrazione e la lettura dei log dei bot AI. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche