Analisi dei log SEO: come leggere i log del server

Search Console ti dice quante impression ha avuto una pagina, in modo aggregato e con qualche giorno di ritardo. Uno strumento di scansione simula un crawler e ti mostra cosa succederebbe se Googlebot visitasse il tuo sito. Il file di log del server è l'unica cosa, tra queste tre, che non stima né aggrega niente: registra un evento realmente accaduto, scritto dal server nello stesso istante in cui rispondeva alla richiesta. Se Googlebot ha chiesto quell'URL alle 3:14 di notte e ha ricevuto un 500, il log lo dice; Search Console magari te lo mostra tre giorni dopo, sommato ad altri dieci errori simili, oppure non te lo mostra affatto perché sotto la soglia di campionamento.

Questo articolo si occupa specificamente di come leggere e usare questi file: cosa contiene una riga di log, dove procurarseli e in quali formati si presentano, come verificare che un hit che dichiara di essere Googlebot lo sia davvero, cosa la scansione reale può rivelare che nessun altro strumento rivela, come impostare una prima analisi su un sito di dimensioni normali, e quando, onestamente, non vale la pena farlo.

Cosa contiene una riga di log (ed è per questo che conta)

Un server web scrive una riga per ogni richiesta HTTP che riceve, bot o umano che sia. Nel formato più comune (Combined Log Format, quello di default su Apache e su gran parte delle configurazioni Nginx) una riga assomiglia a questa:

66.249.66.1 - - [03/Mar/2025:03:14:22 +0100] "GET /prodotti/scarpe-running.html HTTP/1.1" 200 18422 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Ogni campo racconta un pezzo diverso della storia: l'indirizzo IP che ha fatto la richiesta (da verificare, non da fidarsi a occhio), il timestamp esatto al secondo, il metodo e il percorso richiesto — qui sta l'URL reale che il crawler ha chiesto, non quello che pensavi gli arrivasse —, il codice di stato restituito dal server, i byte trasferiti (utile per capire se una pagina pesante rallenta la scansione), il referrer, spesso vuoto per i bot, e lo user-agent dichiarato dal client.

Nessuno di questi dati è un'inferenza. Non è "probabilmente Google ha visto questa pagina", è "il server ha risposto a questa richiesta, con questo codice, a quest'ora". È l'unico registro di prima parte che possiedi sul comportamento reale dei crawler: tutto il resto — report di terze parti, simulazioni, dashboard — è ricostruzione a posteriori.

Dove trovare i log e in che formato arrivano

Su hosting condiviso o cPanel, i log grezzi si scaricano di solito da una sezione tipo "Raw Access Logs" o "Metriche": file di testo, uno per dominio, spesso ruotati e cancellati dopo un periodo breve — in molti hosting economici anche solo 24-48 ore, in altri 30 giorni. Se il tuo piano non conserva abbastanza storico, la prima cosa da fare non è l'analisi, è impostare un cron o uno script che scarichi e archivi il log grezzo ogni giorno, prima che il pannello lo elimini.

Su un server gestito direttamente (VPS, dedicato), i log stanno tipicamente nei percorsi standard di Apache o Nginx, nello stesso Common o Combined Log Format dell'esempio sopra. Chi sta dietro un CDN o un proxy come Cloudflare ha un problema diverso: il server d'origine vede l'IP del proxy, non quello del crawler, a meno che l'header di passthrough non sia configurato correttamente. In quel caso serve attivare l'esportazione dei log lato edge — per esempio Cloudflare Logpush, che restituisce righe in formato JSON con più campi del Combined Log Format classico, incluso l'IP client reale — oppure verificare che il server d'origine registri l'header con l'IP originale invece di quello del proxy.

Il formato in sé non è mai un ostacolo insormontabile: Common, Combined e JSON contengono sostanzialmente le stesse informazioni. Va però identificato prima di scrivere qualunque script di parsing, perché l'ordine e la presenza dei campi cambiano da un formato all'altro.

Per il parsing vero e proprio non serve partire da zero: strumenti da riga di comando generici come grep e awk bastano per filtrare e aggregare file di log di dimensioni moderate, ed esistono analizzatori di log dedicati alla SEO che automatizzano il filtro sullo user-agent, la verifica reverse-DNS e l'incrocio con la sitemap in un'unica interfaccia. La scelta dello strumento conta comunque meno del metodo: senza la verifica dell'IP, qualunque software finisce per contare bot falsi insieme a quelli veri.

Verificare che sia davvero Googlebot, non un impostore

Questo è il passaggio che quasi tutti saltano, ed è un errore. Lo user-agent è una stringa di testo che il client dichiara da solo: chiunque può scrivere uno scraper che si presenta come "Googlebot/2.1" senza essere minimamente collegato a Google. Se filtri i log per user-agent e ti fermi lì, stai probabilmente contando anche traffico di bot di terze parti travestiti, il che falsa ogni numero a valle — frequenza di scansione, pagine coperte, tutto.

Il modo corretto per verificare un hit è la conferma incrociata via DNS, e va fatta in batch sull'insieme degli IP unici presenti nel log, non riga per riga: si risolve ogni IP e si incrocia il risultato con gli intervalli IP che Google pubblica ufficialmente per i suoi crawler, oppure con lo script di verifica che Google stessa mette a disposizione. Bing usa lo stesso meccanismo, con hostname che terminano in search.msn.com. I due passaggi sono:

• Reverse DNS lookup sull'IP che ha fatto la richiesta: deve risolvere a un hostname che termina in googlebot.com o google.com.
• Forward DNS lookup su quell'hostname: deve risolvere di nuovo esattamente allo stesso IP di partenza. Se anche un solo passaggio fallisce, quella richiesta non viene dal crawler dichiarato, indipendentemente da cosa dice lo user-agent.

Cosa dicono i log che nessun altro strumento ti dice

Una volta isolato il traffico verificato, l'analisi dei log risponde a domande a cui nessun altro strumento risponde con la stessa precisione:

• Quali URL sono davvero scansionati, e quanto spesso. Non quali URL potrebbero essere scansionati secondo una simulazione: quali lo sono stati, con che frequenza, in un periodo reale. Confrontare questo elenco con la sitemap mostra subito due cose distinte: pagine in sitemap che il crawler ignora sistematicamente, e pagine scansionate spesso che in sitemap non ci sono nemmeno.
• Quanto crawl budget viene speso su URL che non contano. Filtri di ricerca interna, parametri di tracciamento, combinazioni di faccette su un e-commerce, pagine di paginazione infinita: nei log si vedono come volume di richieste concentrato su pattern che non hanno alcun valore SEO, spesso una quota sorprendentemente alta del totale.
• Pagine orfane che vengono scansionate lo stesso. Se un URL non è linkato da nessuna parte del sito ma compare comunque nei log come richiesto dal bot, Google l'ha trovato altrove — un vecchio link esterno, una sitemap dimenticata, un redirect residuo — e continua a tornarci anche se per te quella pagina non esiste più nel percorso di navigazione.
• Pattern di errori nel tempo, non solo un totale. Un report di errori mostra quanti 404 o 500 ci sono oggi. I log mostrano quando sono comparsi: se un picco di 500 coincide esattamente con un deploy o un cambio di hosting, la causa si trova in un minuto invece che per congetture.
• Il ritardo tra pubblicazione e prima scansione. Confrontando il timestamp di pubblicazione di una pagina con il timestamp del primo hit verificato del crawler su quell'URL si ottiene un numero concreto — ore o giorni — su quanto velocemente il sito viene davvero scoperto, un dato che nessuna dashboard aggregata riporta a livello di singola pagina.

Una prima analisi pratica, passo per passo

Su un sito di dimensioni medie, qualche migliaio di URL, un primo giro di analisi non richiede strumenti sofisticati, solo un metodo ordinato:

• Recupera almeno 30 giorni di log grezzi, meglio 90 se il volume di traffico bot lo consente senza file ingestibili.
• Filtra per user-agent contenente "Googlebot" (o il bot che ti interessa), poi applica la verifica reverse-DNS/forward-DNS per scartare gli impostori: questo passaggio non è opzionale, saltarlo vanifica tutto quello che segue.
• Aggrega i colpi verificati per URL e conta le occorrenze: ottieni la lista reale delle pagine più scansionate, ordinata per frequenza.
• Aggrega per codice di stato: quanti 200, quanti 404, quanti redirect, quanti errori server. Un volume alto di 404 o 5xx su URL scansionati spesso merita priorità immediata.
• Confronta l'insieme degli URL scansionati con l'insieme degli URL nella sitemap XML: le due liste che non coincidono — scansionati-ma-non-in-sitemap, in-sitemap-ma-mai-scansionati — sono la parte più utile dell'intera analisi.
• Raggruppa gli URL per pattern, con espressioni regolari su segmenti di percorso o su parametri di query, per individuare in un colpo solo intere categorie di spreco, invece di scorrere migliaia di righe una per una.

Cosa fare con i risultati e come incrociarli con altri segnali

Il risultato di questo primo giro, anche fatto con un foglio di calcolo e qualche formula, è quasi sempre più utile di un audit tecnico generico, perché non dice cosa potrebbe succedere: dice cosa è successo davvero.

I log da soli raccontano cosa il crawler ha fatto sul server, non cosa è successo dopo: quella parte arriva incrociando i dati. Search Console aggiunge lo stato di indicizzazione dichiarato per ogni URL, utile per capire se una pagina scansionata spesso viene poi effettivamente indicizzata o scartata come duplicata o di bassa qualità. Google Analytics, o l'equivalente in uso, aggiunge il traffico organico reale che quell'URL genera una volta indicizzato.

Messi insieme, i tre livelli rispondono a una domanda che nessuno dei tre da solo può dare per intero: quali pagine vengono scansionate spesso, indicizzate, ma non portano visite — il segnale più chiaro che un contenuto va rivisto o eliminato piuttosto che continuare a consumare crawl budget.

Quando ha senso farlo, e quando è tempo perso

Va detto con onestà, perché non è uno strumento che serve sempre. Su un sito vetrina di poche decine di pagine, con struttura semplice e nessuna generazione dinamica di URL, l'analisi dei log quasi certamente non fa emergere nulla che il rapporto Indicizzazione delle pagine di Search Console non mostri già in modo più comodo. Il costo di procurarsi i log grezzi, verificarli e analizzarli supera il beneficio: è tempo speso a confermare quello che sapevi già.

Ha senso investirci quando la scala o la complessità del sito rende inaffidabile ogni stima aggregata: e-commerce con faccette e filtri che generano combinazioni di URL, siti editoriali con migliaia di articoli pubblicati nel tempo, qualunque sito appena passato per una migrazione o un cambio di piattaforma dove serve sapere in fretta se il crawler sta trovando la struttura nuova o si è impantanato in quella vecchia. Vale la pena anche come controllo puntuale, non necessariamente ricorrente: un pull di log di un mese subito dopo un lancio importante, seguito da un'analisi una tantum, spesso basta a rispondere alla domanda che conta senza dover mantenere una pipeline permanente.