Analisi dei log del server per i crawler IA: chi è arrivato davvero

L’analisi dei log del server legge user agent e IP già registrati e verifica l’identità prima di contare. Include il comando, le tabelle di campi e token, e i limiti di ciò che un log può provare.

Scansione e indicizzazioneLettura di 5 min1860 visualizzazioni
Analisi dei log del server per i crawler IA: chi è arrivato davvero

L’analisi dei log del server consiste nel leggere due campi che il server registra già, lo user agent e l’indirizzo IP, e nel separare le richieste di un crawler IA reale da quelle che si limitano a dichiararlo. Risponde a una domanda che un test di raggiungibilità non risolve: non «GPTBot poteva raggiungere questa pagina», ma «è arrivato, in quale giorno e quante volte». Un 200 dimostra che la porta si apre. Il log mostra chi è entrato.

Cosa può dire l’analisi dei log del server e cosa no

Può dire quali agenti hanno chiesto quali percorsi, a che ora, con quale codice di stato e da quale IP. Non può dire se il contenuto è stato poi usato in una risposta o nell’addestramento. Non conferma nemmeno l’identità da sola: lo user agent è una dichiarazione e chiunque può copiarla. Solo un IP corrispondente trasforma «una richiesta che dice GPTBot» in «GPTBot».

Per questo il tema richiede un metodo e non un trucco da una riga. Una riga di log ha due metà. La metà che tutti leggono è l’agente. La metà che decide se la riga è vera è l’indirizzo IP.

Prima di iniziare servono accesso in lettura al log del server e un terminale. Se l’hosting non fornisce log, questo metodo non ha sostituti: nessuno strumento esterno vede richieste che non sono mai arrivate al server.

Perché il log batte il controllo dell’agente

Un test di raggiungibilità invia una richiesta con un agente imitato e osserva la risposta. Un log registra ciò che hanno fatto client reali, senza sollecitazione. I due possono contraddirsi in entrambe le direzioni: essere raggiungibili non significa essere visitati, e un test può fallire mentre un crawler passa da un’altra strada.

Il log offre anche il campo che un test non produce mai: il tempo. Un test dà sì o no in un istante. Un log dà un conteggio per giorno e per robot, l’unico modo per distinguere un crawler settimanale da uno arrivato una volta e poi sparito.

Fallo in questo ordine

Cinque passi, ognuno con un controllo prima del successivo.

  1. Trova il log e conferma il formato. In nginx il valore predefinito è combined; in Apache il formato esteso/NCSA combined documenta %h %l %u %t "%r" %>s %b "%{Referer}i" "%{User-agent}i". Fatto quando sai nominare ogni campo su una riga reale.
  2. Conta per agente prima di filtrare. In una riga combined il sesto campo tra virgolette è l’agente. Fatto quando hai un elenco dei trenta agenti più frequenti, non solo di quelli attesi.
  3. Estrai i token dei crawler IA. Le stringhe esatte sono nella tabella più sotto. Fatto quando ogni token ha un numero di richieste e una data di prima comparsa.
  4. Verifica gli IP a cui vuoi credere. DNS inverso e diretto per Google, file JSON pubblicati per OpenAI. Fatto quando ogni riga citata è verificata o marcata come non verificata.
  5. Annota la finestra, non solo il totale. Un conteggio senza giorni non significa nulla. Fatto quando la nota dice «412 richieste, dal 1 al 31 agosto 2026, 5 siti».

Il risultato: un comando e due tabelle

Questo comando trasforma un log in formato combined in un conteggio per agente. Presuppone che nel campo agente non ci siano virgolette con escape, cosa vera per i crawler sotto e falsa per alcuni scraper.

awk -F'"' '{print $6}' access.log \
  | sed 's/;.*compatible;//' \
  | sort | uniq -c | sort -rn | head -30

Il passo sed serve perché i browser nascondono il token reale dietro un prefisso di compatibilità. Conserva anche il sesto campo grezzo, per tornarci quando un conteggio sembra sbagliato.

Il secondo risultato è la tabella dei campi. Quasi tutti conoscono l’agente e si fermano lì, ed è per questo che la prima passata perde i percorsi.

CampoEsempioCosa dice
Indirizzo remoto66.249.66.1L’unico campo verificabile su una lista pubblicata
Riga richiestaGET /pricing HTTP/1.1Il metodo e il percorso richiesti
Stato200Se il crawler ha ricevuto contenuto o blocco
Byte inviati18432Quanto è stato restituito davvero
Referrer-Quasi sempre vuoto per un crawler
User agent... GPTBot/1.4 ...La dichiarazione, falsificabile, troppo creduta

Terzo risultato: la lista dei token pubblicati dagli operatori, riletta il 22 settembre 2026 nella loro documentazione. Non è completa e ne compaiono di nuovi senza preavviso, motivo in più per contare tutto prima di filtrare.

TokenOperatoreScopoVerificabile
GPTBotOpenAICrawl per addestramentoSì, con openai.com/gptbot.json
OAI-SearchBotOpenAIPresenza nella ricercaSì, con openai.com/searchbot.json
ChatGPT-UserOpenAIRichiesta avviata da una personaSì, con openai.com/chatgpt-user.json
GooglebotGoogleCrawl per la ricercaDNS inverso e diretto, più file JSON
Google-ExtendedGoogleToken di controlloNo: non invia richieste proprie
ClaudeBotAnthropicCrawlDocumentato, controlla i range sulla loro pagina
PerplexityBotPerplexityCrawlDocumentato, controlla i range sulla loro pagina

Due righe reggono il ragionamento. Google-Extended è un token di controllo, non un crawler: la documentazione di Google dice che non ha una stringa user agent propria, quindi la sua assenza dal log non è un errore. ChatGPT-User è attivato da una persona, quindi le sue richieste non sono un crawl automatico.

Cosa va storto

Credere all’agente. È l’errore predefinito e produce una risposta sicura e falsa. La verifica di Google richiede due risoluzioni DNS: inversa sull’IP, poi diretta sul nome ottenuto, con corrispondenza obbligatoria. Per OpenAI si confronta l’IP con il file dei range. Per un crawler che non pubblica né l’una né l’altro, scrivi «non verificato» invece di credere o cancellare il conteggio.

Contare le letture di robots.txt come pagine. OpenAI segnala che, leggendo robots.txt, può aggiungere un marcatore all’agente per distinguere quelle richieste. Se il formato elimina il percorso, una lettura di robots.txt e una pagina sembrano uguali. Separa per percorso prima di annunciare un conteggio di crawl.

Leggere una finestra troppo corta. Sette giorni non rispondono a una domanda di trenta, e la rotazione dei log tronca la finestra senza avvisare. Indica il primo e l’ultimo timestamp realmente contati.

Domande frequenti

Si può credere allo user agent nel log?

No. Trattalo come una dichiarazione finché l’IP non corrisponde a un range pubblicato o non supera DNS inverso e diretto. Un log è una prova documentale, non un’identità.

Come so se GPTBot ha visitato il sito?

Cerca il token GPTBot e confronta ogni IP con openai.com/gptbot.json. Un token senza IP corrispondente è un’altra richiesta che ha copiato il nome.

Quanti giorni di log servono?

Quanti bastano a coprire un ciclo completo di crawl, che dipende dal sito e non ha un numero universale. Trenta giorni sono un punto di partenza ragionevole. Se ne hai sette, dillo: una finestra corta sottostima, mai sovrastima.

Il confine da scrivere chiaramente: un log prova che c’è stata una richiesta; non prova che il contenuto sia stato usato, posizionato o citato. Quando vuoi trasformare quel dato in un’azione pubblicata, lì entra QueryWin. Per controllare prima se i crawler riescono a raggiungerti, parti da verificare se l’IA può leggere il sito. E se la domanda è quali robot permetti, la risposta è in robots.txt per i crawler IA.

L’agente si presenta da solo. L’IP decide se dice la verità.

Fa parte di del manuale di QueryWin · Livello 2

Analisi dei log del server per i crawler IA: chi è arrivato davvero