Analisi dei log per la SEO: le dritte per trovare i dati che contano

Nella guida su come leggere il log del web server ho spiegato le basi: dove stanno i file, l’anatomia di una riga, i formati, gli status code, gli strumenti. Quella è la fase in cui impari a decifrare il log. Qui saliamo di livello: cosa cercarci dentro per trovare i problemi reali, quali KPI sono critici e quali pattern riconoscere. Sono le dritte operative che uso quando apro il log di un sito e devo tirare fuori qualcosa di azionabile in mezz’ora.

Il pretesto è il video qui sotto, in cui mostro un report HTML che ho costruito con Claude Code per analizzare i log di questo blog. Il video ti fa vedere lo strumento in azione; questo articolo ti spiega il metodo di analisi che c’è sotto — quello vale a prescindere dal tool che usi.

Un avvertimento in apertura, perché è il concetto attorno a cui ruota tutto il resto: il log grezzo non dice la verità sul crawling. Dice la verità sulle richieste HTTP che il server ha registrato, che è una cosa diversa. Tra le due c’è tutto il lavoro di pulizia e arricchimento del dato di cui parliamo adesso.

Perché il log grezzo non basta: arricchire il dato prima di analizzarlo

Una riga di access log nginx in Combined Log Format ti dà IP, timestamp, request line, status code, byte serviti, referer e user-agent. Sono i sette campi che hai imparato a leggere nella guida precedente. Per un’analisi SEO professionale non bastano, per quattro motivi concreti:

• L’user-agent mente. È testo libero: chiunque può presentarsi come Googlebot. Senza un passaggio di verifica, un buon 20% di quello che il log chiama Googlebot non è Google (numero reale, misurato sul log di questo blog — ci torno tra un attimo).
• Con milioni di righe non “vedi” niente a occhio. Un log di un sito con traffico serio ha decine di migliaia di user-agent distinti e centinaia di migliaia di URL. Senza raggruppamenti non tiri fuori nessun trend.
• Manca il contesto di business. Il log sa che Googlebot ha chiesto /blog/pagina-x/ dieci volte, ma non sa che quella pagina fa 4.000 impression al mese in Search Console. Quel dato è quello che trasforma un numero in una decisione.
• Le “sezioni” e il “tipo di risorsa” non esistono nel log. Vanno costruiti in fase di analisi, altrimenti la classifica degli URL più richiesti è dominata da CSS, JS e immagini.

Da qui la regola metodologica: prima di analizzare, si arricchisce. I cinque arricchimenti che considero non negoziabili:

1. Identità verificata del bot — non l’user-agent dichiarato, ma l’esito di una verifica su IP e reverse DNS.
2. Categorizzazione del bot — motori di ricerca, AI training, AI agent, scraping, tool SEO, browser/generici.
3. Classificazione dell’URL — sezione (da allow-list) e tipo di risorsa (HTML vs asset vs URL tecnico).
4. Dati di Search Console — click e impression per URL, sullo stesso periodo del log.
5. Tagging di sonde e attacchi — per poterli escludere dall’analisi SEO senza perderli per l’analisi di sicurezza.

Ogni sezione che segue è un pezzo di questo lavoro, con la relativa dritta.

Verifica l’identità dei bot: l’user-agent è solo una stringa

Questo è il passaggio zero. Se lo salti, ogni numero che calcoli dopo è sporco.

L’user-agent è una stringa di testo nell’header HTTP, che nginx copia nel log così com’è. Nessuno ti garantisce che dietro Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) ci sia davvero Google. Scraper, script e tool SEO si mascherano da Googlebot ogni giorno, per aggirare i blocchi o per non farsi riconoscere. Sul log di questo blog, quando isolo l’user-agent Googlebot e poi filtro i soli verificati, circa un quinto delle richieste sparisce: era traffico camuffato.

Il metodo di verifica è quello che documenta Google stesso e si basa su due controlli combinati:

• Reverse DNS + forward confirm. Fai una PTR lookup sull’IP: deve risolvere a un hostname del dominio ufficiale (googlebot.com o google.com). Poi confermi facendo una lookup diretta di quell’hostname: deve tornare all’IP di partenza.
• Match su IP range ufficiali. Google pubblica gli intervalli in JSON (googlebot.json, più le liste special-crawlers e user-triggered-fetchers). OpenAI, Bing, AWS e altri pubblicano file analoghi.

La verifica a mano su un singolo IP:

# 1) reverse DNS: chi dice di essere questo IP?
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com.

# 2) forward confirm: quell'hostname torna allo stesso IP?
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

Su scala, questo non lo fai a mano: costruisci in fase di setup un database unico degli IP range di tutti i bot noti (scaricato dai file JSON ufficiali) e ci fai il join. host, grep e compagnia restano comunque i ferri del mestiere per i controlli puntuali — li ho raccolti nella guida alla SEO da terminale. Ogni richiesta finisce così in una di queste classi:

• VERIFIED — l’IP appartiene al range ufficiale e/o il reverse DNS conferma. È il vero bot.
• SPOOFED — l’user-agent dichiara un crawler noto, ma la PTR risolve altrove o restituisce un NXDOMAIN definitivo. È traffico camuffato.
• NON VERIFICABILE — non hai una lista IP per quel bot (es. un tool SEO minore), quindi non puoi né confermare né smentire.

Attenzione a non confondere SPOOFED con errore DNS temporaneo: un timeout o un SERVFAIL sul resolver non è un camuffamento, è solo una lookup fallita da ritentare. Trattarli allo stesso modo gonfia il conteggio dei falsi.

La dritta: non trarre mai conclusioni sull’user-agent dichiarato. Prima di qualsiasi analisi su Googlebot — frequenza, status code, copertura — applica il filtro sui verificati. E occhio all’istinto di bloccare i “bot cattivi” via user-agent nel firewall: rischi di bloccare il vero Googlebot (che ruota gli IP e a volte cambia stringa) e di lasciar passare lo scraper che si è semplicemente rinominato.

Riduci il rumore: categorie bot, sezioni e tipo di risorsa

Verificata l’identità, il secondo lavoro è rendere leggibile un file da milioni di righe. Si fa clusterizzando su tre assi.

Categoria del bot. Raggruppa gli user-agent verificati in macro-categorie: bot dei motori di ricerca, bot di AI training, bot di AI agent, scraping, tool SEO, browser/generici. La distinzione più interessante è quella tra AI training e AI agent: i primi scansionano in modo massivo per costruire i dataset; i secondi si attivano on-demand quando un utente fa una domanda a un chatbot e l’agente va a recuperare la tua pagina. Sono due segnali diversi e più avanti vedremo che si comportano in modo diverso anche negli orari. Su come governarli — bloccarli, limitarli o assecondarli — ho scritto una guida dedicata alla gestione dei crawler AI.

Tipo di risorsa. Separa l’HTML dagli asset (CSS, JS, immagini, font) e dagli URL tecnici. Se non lo fai, la classifica degli “URL più richiesti da Googlebot” è dominata dai file statici e non ti dice niente di utile. Per l’analisi SEO delle pagine, filtra sul tipo HTML.

Sezione dell’URL — e qui c’è una trappola. L’istinto è ricavare la sezione dal primo segmento del path (/blog/... → sezione “blog”). Su un sito reale non funziona: gli scanner generano decine di migliaia di primi-segmenti diversi, quasi tutti inventati. Il risultato è un elenco di “sezioni” ingestibile e privo di senso. La soluzione è una allow-list: definisci a mano le sezioni vere del sito (blog, category, product, tag…), tutto ciò che non è in lista finisce in (other), il traffico di attacco in (probe).

Le sonde. Il traffico di scanner e brute-force — chiamate ripetute a URL di login inventati, tentativi su /wp-login.php, /.env, /.git/config — è spesso enorme e intasa il log. Va taggato ed escluso di default dall’analisi SEO (un filtro “sonde escluse”), ma non cancellato: serve per il monitoraggio di sicurezza, di cui parliamo più avanti.

I grafici da leggere per primi: trend, status code, pattern orari

Con il dato pulito e arricchito, ci sono tre viste che apro sempre per prime.

Il trend globale è il tuo sismografo

Il grafico delle richieste nel tempo, filtrato per Googlebot verificato, è il primo posto dove leggere l’effetto dei tuoi interventi. Reagisce a:

• Migrazioni e interventi sul server — dopo una migrazione controlli se il crawl riprende ai volumi precedenti o crolla.
• Velocità di risposta — se abbassi il TTFB, Google può permettersi di scansionare di più: il crawl rate è funzione anche della salute del server. Lo dice la documentazione di Google sul crawl budget: risposte lente o errori 5xx fanno rallentare il crawling.
• Aggiornamenti di massa — dopo aver aggiornato molte pagine importanti, monitora se nei giorni successivi la frequenza di scansione sale.
• Attività di link building — nuovi link esterni possono anticipare un aumento delle visite di Googlebot.

La dritta: ogni volta che ti aspetti un cambiamento — in più o in meno — nell’attività di Googlebot, il trend è il primo elemento da guardare. È il grafico che trasforma “ho fatto una migrazione” in “la migrazione ha avuto questo effetto sul crawl”.

La distribuzione degli status code, per bot verificato

Non guardare la distribuzione status globale: guardala per singolo bot verificato. Per Googlebot ti aspetti la maggioranza di 200, una fetta di 301/304, e poco altro. Nel log di questo blog Googlebot sta intorno al 75% di 200 e a un 10-11% di 3xx: profilo sano.

I campanelli d’allarme:

• 4xx elevati serviti a Googlebot — sta scansionando URL morti o inventati: crawl budget sprecato. Vai a vedere quali URL sono e da dove arrivano (link interni rotti? vecchie URL mai reindirizzate?).
• 5xx serviti a Googlebot — il più grave. Il server va in difficoltà proprio mentre Google scansiona, e Google reagisce rallentando. Se vedi i 5xx correlati ai picchi di crawl, hai un problema di capacità del server, non di SEO.

I pattern orari: umani contro macchine

La heatmap ora-del-giorno per giorno-della-settimana rivela la natura del traffico. Filtra i bot di AI agent (quelli che si attivano quando un utente chatta): si scaldano negli orari d’ufficio, 9–12 e 14–17, spariscono nel weekend. Sono pattern umani, perché dietro c’è una persona che sta facendo una domanda a un LLM e l’agente sta recuperando la tua pagina in tempo reale.

Filtra invece Googlebot verificato o i bot di training: la distribuzione è uniforme. Googlebot, una volta che conosce il sito e ha calcolato il suo crawl budget, spalma le visite nel tempo senza concentrarsi su fasce orarie e senza saturare il server. Un picco di crawl concentrato in poche ore, quindi, è un segnale: uno scraper, un attacco — o un bot legittimo ma aggressivo, come nel caso di facebookexternalhit e Amazonbot che saturano il server, diagnosticato e risolto proprio partendo dai log.

Il caso pratico che vale l’analisi: le pagine che Google trascura

Questa è l’analisi che, da sola, giustifica tutto il lavoro di setup. Serve a rispondere a una domanda precisa: quali pagine, che a Google interessano, Googlebot ha smesso di visitare?

Il setup dei filtri:

1. Categoria = search engine bot, e solo i verificati.
2. Tipo risorsa = HTML — esclusi feed, asset, allegati e media.
3. Status = 200 (solo pagine che esistono davvero).

Poi lavori su due colonne, che sono il cuore di tutto:

• Giorni dall’ultima visita di Googlebot — 0 significa visitata nell’ultimo giorno di log; 135 significa che Googlebot non passa da 135 giorni.
• Impression di Search Console per quell’URL, sullo stesso periodo.

Incrociando le due colonne ottieni una matrice di priorità:

Impression	Ultima visita	Interpretazione e azione
Alte	Recente	Pagina sana. Monitora e basta.
Alte	Vecchia	Priorità massima. Google la mostra ma non la rivisita: contenuto stantio o poco linkato internamente. Aggiorna il contenuto, rinforza i link interni, ricondividila.
Basse/zero	Vecchia o mai	Candidata a consolidamento/potatura — oppure a un rilancio, se è strategica.
—	Riceve crawl ma è un URL inesistente	Non è roba tua: vecchi link o scanner. Verifica il 404 e non sprecarci tempo.

Il ragionamento dietro la seconda riga è quello che spiego nel video: più una pagina fa impression organiche, più Googlebot tende a visitarla di frequente, e viceversa. L’organico è però solo uno dei canali. Se Google percepisce interesse verso un URL — magari perché lo rilanci sui social o guadagna un link — può rimandare Googlebot a rivisitarlo. Ecco perché su una pagina di valore trascurata l’intervento non è solo “riscrivi il contenuto”, ma anche “riportaci attenzione”.

Per avere il quadro d’insieme, classifica gli URL in fasce di freschezza: visitati negli ultimi 30 giorni, 30–60, oltre 60, mai visitati. È una lettura immediata dell’interesse di Google sul sito, sezione per sezione. Concentri gli interventi sulle fasce “>30 giorni” e “mai”, filtrando però le pagine che ti aspetti davvero come strategiche: che la pagina 10 dell’archivio blog non venga vista da 301 giorni è fisiologico; che un tuo articolo evergreen sia fermo da settimane è un’azione da mettere in lista.

Il rovescio della medaglia di questa analisi è la caccia al crawl sprecato: gli URL su cui Googlebot spende budget senza motivo — parametri, faccette, paginazioni infinite, feed, /wp-admin, asset. Isolando i primi URL per volume di crawl tra i non HTML o tra le sezioni (other), vedi dove il budget se ne va. Tagliarlo con robots.txt, canonical e gestione dei parametri libera scansioni per le pagine che contano.

Le trappole che falsano l’analisi (e come evitarle)

Queste sono le cose che ho imparato costruendo lo strumento e che nel video non ho avuto modo di approfondire. Sono gli errori che distinguono un’analisi che sembra giusta da una che lo è.

• La rotazione dei file NON è cronologica. Con logrotate configurato a dimensione (size) e delaycompress, access.log.2 può coprire un periodo più vecchio di access.log.2.gz. Ordinare i file per nome produce una timeline sbagliata. E non risolvi con un sort ingenuo sul campo data, perché il $time_local di default di nginx (10/Oct/2000:13:55:36 +0000) non è ordinabile lessicograficamente — il mese è una parola. L’ordine va sempre stabilito dai timestamp effettivi parsati riga per riga, mai dal nome del file.
• Il double-logging dietro proxy e CDN. Un’architettura a due livelli può loggare la stessa richiesta due volte (l’edge in HTTP/2, poi 127.0.0.1 in HTTP/1.1): i conteggi raddoppiano. E dietro una CDN come Cloudflare il remote_addr è l’IP dell’edge, non del client reale: se non leggi il vero IP (da X-Forwarded-For / CF-Connecting-IP) e non dichiari l’edge come trusted, la verifica ti segnala come spoofed anche i crawler legittimi. Nel mio setup il server riceve l’IP diretto, senza CDN a monte; ma se il tuo traffico passa da un proxy, il log giusto da analizzare è quello a monte, o quello configurato per registrare l’IP reale. Conosci la tua infrastruttura prima di fidarti degli IP.
• Le metriche di unicità non sono additive. URL unici e IP unici non si sommano tra filtri o tra intervalli di tempo: gli unici di oggi più quelli di ieri non fanno gli unici del biennio (gli stessi si ripetono). Vanno ridotti per massimo, mai per somma. Una dashboard che somma gli unici mente.
• Il byPage di Search Console gonfia i totali. Quando estrai i dati GSC raggruppati per pagina, la somma di click e impression per-URL supera il totale del sito: la stessa pagina compare per molte query e l’aggregazione conta più volte lo stesso evento su dimensioni diverse. Usa i valori per-pagina per il confronto relativo tra URL, non come totale assoluto del sito.

Sonde, scanner e attacchi: cosa isolare

Il traffico ostile va tenuto fuori dall’analisi SEO ma dentro quella di sicurezza. I pattern da riconoscere e taggare:

• POST ripetute a /wp-login.php e /xmlrpc.php (brute force).
• Richieste a file sensibili mai pubblicati: /.env, /.git/config, /wp-config.php.bak.
• Payload di SQL injection o path traversal nella query string.
• Ondate di 404 su URL inventati in sequenza (scanning di vulnerabilità note).

Isolando questi pattern in un filtro dedicato monitori la frequenza degli attacchi e pianifichi le contromisure (fail2ban, regole a livello di firewall o CDN). Per la parte difensiva vera e propria — cosa cercare e come reagire — rimando alla sezione dedicata nella guida su come leggere il log, che copre l’argomento in dettaglio.

Come ho costruito il report (e come replicarlo)

Il report che vedi nel video l’ho sviluppato in vibe coding con Claude Code, e il metodo conta quanto il risultato.

• Prima il prompt, in modalità pianificazione. Ho aperto una cartella vuota come progetto e ho scritto un prompt il più completo possibile — cosa deve analizzare il report, come mostrarlo, quali arricchimenti servono, quali vincoli tecnici. Poi ho lasciato che l’agente producesse un piano (piano.md), l’ho letto, corretto e approvato prima che scrivesse una riga di codice. Partire da un prompt strutturato è più efficiente che affinare pian piano un prompt superficiale.
• Output = un unico HTML autocontenuto. I dati aggregati sono incorporati nel file e ri-aggregati nel browser man mano che filtri. È portabile: lo salvi su Drive o Dropbox e lo apri su qualsiasi PC con un browser, senza server né database.
• Applicativo agnostico rispetto al sito. Una configurazione per dominio, con il parser generato dalla stringa log_format di nginx: lo stesso strumento analizza log di siti diversi.
• Stack minimo. Python 3.12, Polars e PyArrow per reggere i milioni di righe in colonnare, dnspython per il reverse DNS, il client Google API per Search Console.

Il codice, il prompt e il piano sono nel repository su GitHub, così puoi lanciarlo sui tuoi log. È un progetto work-in-progress (v0.1.0, ancora senza licenza), pensato come base da estendere. Il punto che voglio lasciare non è “usa il mio tool”: è che oggi, con un agente di coding, un report di analisi log dinamico e su misura te lo costruisci senza pagare software dedicati. La parte difficile non è più il codice — è avere le idee chiare su cosa analizzare. Che è esattamente ciò di cui parla questo articolo.

La checklist operativa

Le dritte di questo pezzo, in forma spuntabile, da tenere aperta quando apri un log:

1. Verifica l’identità di ogni bot (IP range + reverse DNS) prima di contarlo.
2. Filtra sempre i verificati prima di decidere qualsiasi cosa su Googlebot.
3. Clusterizza i bot e separa l’HTML dagli asset.
4. Escludi le sonde dall’analisi SEO (ma tienile per la sicurezza).
5. Leggi il trend come sismografo dei tuoi interventi su sito e server.
6. Controlla la distribuzione status code per bot verificato (allarme su 4xx/5xx a Googlebot).
7. Incrocia giorni dall’ultima visita × impression per trovare le pagine trascurate.
8. Taglia il crawl sprecato per liberare budget verso le pagine che contano.
9. Ordina i file per timestamp reale, mai per nome.
10. Conosci la tua infrastruttura (CDN/proxy) prima di fidarti degli IP nel log.

Se hai dubbi, domande o un caso limite che non rientra in queste dieci, lascia un commento: i casi reali sono la parte più interessante.