Analisi dei log per la SEO: leggi i log del server e correggi lo spreco di scansione

Quiz veloce

La SEO fa per te, e come iniziare?

Domanda 1 di 425%

Le persone cercano su Google ciò che vendi?

Sì, credo di sìNo, è nuovo o molto di nicchiaNon lo so

Cosa registra un log del server e perché batte i tuoi altri dati

Ogni volta che qualcosa richiede un file al tuo server, quest'ultimo scrive una riga nel suo log di accesso. La maggior parte dei server usa un formato simile al "combined" di Apache. Una richiesta di Googlebot appare così:

66.249.66.1 - - [13/Nov/2026:08:14:22 +0100] "GET /products/red-running-shoes HTTP/1.1" 200 18342 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Leggila da sinistra a destra: l'indirizzo IP, il timestamp, il metodo HTTP e l'URL, il codice di stato (200 qui), il numero di byte inviati, il referrer e lo user agent. Ci sono tutte le richieste, comprese quelle che non compaiono mai come visualizzazione di pagina nel tuo strumento di analisi: immagini, file CSS, redirect ed errori 404.

Le altre fonti di dati ne vedono ciascuna una parte. Il report Statistiche di scansione della Search Console è aggregato e copre solo i crawler di Google. Gli strumenti di analytics registrano solo i visitatori il cui browser esegue il tuo JavaScript. Un crawler di siti come Screaming Frog mostra ciò che riesce a raggiungere seguendo i tuoi link, che non è la stessa cosa di ciò che Google ha scelto di richiedere. Solo il log del server registra ciò che è accaduto davvero.

Perché l'analisi dei log conta: il crawl budget in parole semplici

Il crawl budget è l'insieme degli URL che Google può e vuole scansionare sul tuo sito. Google lo descrive con due fattori. Il primo è il limite di capacità di scansione: quante connessioni i crawler di Google possono tenere aperte verso il tuo server senza sovraccaricarlo. Quel limite sale quando il sito è in salute e scende quando le risposte rallentano o restituiscono errori 5xx o 429. Il secondo è la domanda di scansione, che dipende dalle dimensioni del sito, da quanto spesso cambia il contenuto, dalla sua qualità e dalla popolarità delle pagine.

Google presenta l'argomento come una guida avanzata per i siti grandi. Le sue soglie indicative sono i siti con 1 milione o più di pagine uniche il cui contenuto cambia circa una volta a settimana, e i siti con 10000 o più pagine uniche il cui contenuto cambia ogni giorno. Rientrano nel perimetro anche i siti con molti URL nello stato "Rilevata, attualmente non indicizzata". I siti più piccoli possono in genere affidarsi a una sitemap aggiornata e a controlli regolari del report Indicizzazione delle pagine. Questo non rende inutili i log per loro. Quando qualcosa non va nella scansione, il log è il modo più rapido per vedere esattamente dove.

Se il tuo sito rientra in quell'intervallo, la domanda non è più se leggere i log ma con quale frequenza. Un audit una tantum mostra gli sprechi di oggi. Un export mensile mostra se le correzioni hanno cambiato su cosa Googlebot spende il suo tempo. Per il lessico di base, la voce del glossario sul crawl budget copre i fondamenti, e la guida su Rilevata, attualmente non indicizzata spiega lo stato che di solito innesca questo tipo di verifica.

Il metodo, passo dopo passo

Il flusso qui sotto funziona con qualsiasi server e qualsiasi strumento. Le sezioni successive spiegano ogni passaggio nel dettaglio e riportano i comandi da eseguire oggi su un file di log grezzo.

Procurati i log dal livello giusto

Chiedi al tuo sviluppatore o al provider di hosting i log di accesso grezzi del web server (Apache, Nginx o IIS). Prima di iniziare verifica tre cose: il formato del log, il fuso orario e il periodo di conservazione. A seconda della configurazione, i log vecchi possono essere eliminati dopo pochi giorni o settimane, quindi chiedi l'export adesso e non più avanti.

Il livello conta più di quanto si pensi. Se una CDN risponde a una richiesta dalla sua cache, il server di origine non la vede mai. Googlebot può scansionare un URL che non compare mai nel log dell'origine, quindi un export solo dell'origine sottostima l'attività di scansione sui contenuti in cache. Esporta anche i log della CDN e confronta le due fonti su alcuni URL prima di fidarti di uno dei due totali.

Filtra e conta Googlebot con pochi comandi

In un log in formato combined, il codice di stato è il 9° campo e il percorso dell'URL il 7°. Quelle due colonne rispondono alla maggior parte delle prime domande. Questo comando conta le richieste di Googlebot per codice di stato:

grep "Googlebot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn

Questo elenca i 20 percorsi più richiesti da Googlebot, senza la query string, così le varianti di filtro si raggruppano:

grep "Googlebot" access.log | awk '{print $7}' | cut -d '?' -f1 | sort | uniq -c | sort -rn | head -20

Il primo comando legge il testo dello user agent, che chiunque può falsificare. Trattane l'output come una lista di candidati finché non hai completato la sezione seguente. Inoltre, se il tuo log usa un formato personalizzato, i numeri dei campi cambiano: controlla una riga a occhio prima di fidarti delle colonne.

Verifica Googlebot nel modo descritto da Google

Il metodo ufficiale di Google per confermare che un visitatore è Googlebot usa il DNS. Esegui una ricerca DNS inversa sull'indirizzo IP del tuo log, verifica che l'hostname termini con googlebot.com, google.com o googleusercontent.com, poi esegui una ricerca diretta su quell'hostname e controlla che restituisca l'IP originale. La documentazione di Google usa questo esempio, dove 66.249.66.1 risolve in crawl-66-249-66-1.googlebot.com:

host 66.249.66.1

Il controllo diretto è il secondo comando, e deve restituire lo stesso IP:

host crawl-66-249-66-1.googlebot.com

Se elabori milioni di righe, le ricerche DNS diventano lente. Google pubblica anche file JSON con gli intervalli IP dei suoi crawler, tra cui common-crawlers.json per Googlebot. Confrontare con quegli intervalli è più veloce, e la guida ufficiale alla verifica descrive entrambi i metodi nella guida di Google sulla verifica di Googlebot.

Raggruppa, misura e leggi i risultati

I conteggi grezzi per URL sono difficili da usare. Raggruppa prima gli URL per template, perché una correzione di solito riguarda un template e non una singola pagina. Poi misura quattro cose per ogni gruppo. Quanti hit di Googlebot riceve rispetto alla sua importanza per il business. La composizione dei codici di stato. Quanto in fretta le nuove pagine ricevono il primo hit dopo la pubblicazione. E se gli hit si concentrano sulle pagine che vuoi posizionare.

Leggi i risultati come uno schema, non come un numero isolato. Se la maggior parte degli hit di Googlebot cade su URL di filtro e solo pochi sulle pagine prodotto, il crawl budget sta perdendo, e il problema è probabilmente nei link interni o nella gestione dei parametri, non nelle pagine prodotto. La sezione successiva elenca i segnali da cercare.

I sette segnali nascosti nei log

Una volta verificate e raggruppate le righe di Googlebot, sette segnali spiegano la maggior parte dei problemi di scansione. La tabella indica lo schema da cercare e la correzione tipica. Ogni correzione è una modifica al sito, quindi confermala nell'export successivo.

Segnale	Cosa mostrano i log	Cosa fare
Spreco di scansione	Hit di Googlebot su filtri, ordinamenti, ricerca interna e URL di sessione	Consolidare con i canonical, rimuovere i link interni verso questi URL e bloccare nel robots.txt le varianti inutili che non si possono consolidare
Redirect	Hit su risposte 301 o 302 e catene di due o più salti	Collegare direttamente all'URL finale. La guida 301 vs 302 ti aiuta a scegliere il tipo di redirect giusto
Errori	Hit ripetuti su 404 o 410 e picchi di risposte 5xx	Ripristinare o reindirizzare le pagine che contano ancora, e correggere gli errori del server, perché le risposte 5xx riducono quanto Google scansiona
Scansioni mancanti	URL importanti senza alcun hit di Googlebot nel periodo	Verificare i link interni, le voci della sitemap e le regole del robots.txt che potrebbero tenere lontani i crawler
Duplicati	Lo stesso contenuto raggiunto con più URL, con slash finali, maiuscole o parametri	Scegliere un URL canonico e collegarlo ovunque
Tempo alla prima scansione	Tempo tra la pubblicazione di una nuova pagina e il primo hit di Googlebot	Collegare le nuove pagine da pagine già scansionate spesso, e mantenere pulita la sitemap
Tempo di risposta	Risposte lente sui template che Googlebot colpisce di più	Accelerare prima questi template, perché Google dice che risposte lente lo portano a scansionare meno

La riga «scansioni mancanti» è quella che la gente salta, ed è spesso la più costosa. Una pagina che non compare mai nel log può non posizionare nulla, anche se il suo contenuto è eccellente. Se un URL è nella tua sitemap ma non compare mai nei log, la pagina è probabilmente raggiungibile solo tramite un percorso che i crawler non seguono. La guida su Scansionata, attualmente non indicizzata copre l'altro lato di questa situazione, quando Googlebot passa ma ancora non indicizza.

Tre modi per svolgere l'analisi, a confronto

Puoi fare l'analisi dei log con script, con un'applicazione desktop o con una piattaforma. Ognuna si adatta a un volume e a un team diversi. La scelta dipende meno dalle dimensioni del sito che da quanto spesso ti serve la risposta e da chi la leggerà.

Riga di comando: grep, awk e Python

Principio: analizzi i file grezzi con script e scrivi i risultati in un file o in un foglio di calcolo. Quando usarlo: controlli una tantum, siti piccoli o uno sviluppatore che vuole il pieno controllo. Vantaggi: è gratuito, vedi ogni riga e puoi automatizzarlo con un job pianificato. Limiti: richiede tempo per scriverlo e mantenerlo, va alla velocità della tua macchina, non ha grafici e devi verificare tu i bot.

Esempio: i comandi della sezione sul metodo, eseguiti una volta al mese sullo stesso export, ti danno la composizione dei codici di stato e i percorsi principali di Googlebot. Uno script Python breve può fare lo stesso e aggiungere il controllo DNS, più lento ma più preciso.

Strumento desktop: Screaming Frog Log File Analyser

Principio: importi i log grezzi in un progetto desktop, lo strumento raggruppa i bot, controlla la loro identità e disegna i grafici. Quando usarlo: un consulente o un analista interno che lavora su un sito con decine di migliaia di URL. Vantaggi: legge i log di Apache, IIS e Nginx in formato W3C Extended, verifica i bot dei motori di ricerca e segnala le pagine grandi o lente. Limiti: la versione gratuita ha un tetto, e la quantità di dati che puoi caricare dipende dal disco.

Leggi la pagina di Log File Analyser di Screaming Frog prima di acquistare. Per un percorso completo sul crawler che si abbina a questo strumento, consulta la nostra guida a Screaming Frog SEO Spider. L'analizzatore di log fa una cosa che il crawler non può fare: mostra cosa hanno richiesto i bot nel mondo reale, non ciò che suggeriscono i tuoi link.

Piattaforma: monitoraggio continuo dei log

Principio: la piattaforma riceve i tuoi log con una pianificazione, spesso dalla CDN o dal server, e li incrocia con una scansione del sito e con i dati di indicizzazione. Quando usarlo: grandi e-commerce o team enterprise che monitorano la scansione ogni settimana su più mercati. Vantaggi: scala a log molto grandi, conserva lo storico e permette a più team di condividere dashboard. Limiti: costa di più, richiede tempo per l'onboarding, e il vincolo con il fornitore è reale, quindi verifica come puoi esportare i dati prima di impegnarti. Tra i fornitori di questa categoria ci sono Oncrawl e Botify, e vale la pena chiedere a ciascuno come verifica i bot.

Criterio	Riga di comando	Strumento desktop	Piattaforma
Costo	Gratuito	Gratuito fino a 1000 eventi di log, 99 £ l'anno per la licenza completa	Abbonamento, prezzo in base al volume
Configurazione	Scrivi e mantieni gli script	Installa, importa, avvia	Connettori e onboarding
Volume	Limitato dalla tua macchina	Limitato dal disco e dalla licenza	Pensata per log molto grandi
Verifica dei bot	Manuale, con controllo DNS o degli intervalli IP	Integrata	Chiedilo al fornitore
Ideale per	Controlli una tantum e siti piccoli	Consulenti e siti medi	Team enterprise ed e-commerce con monitoraggio settimanale

Il report Statistiche di scansione di Google: utile, ma non basta

Prima di esportare un singolo log, apri il report Statistiche di scansione nella Search Console. Mostra le richieste di scansione totali, la dimensione totale scaricata, il tempo medio di risposta, le risposte raggruppate per tipo, i tipi di file, lo scopo della scansione e il tipo di Googlebot che ha effettuato ogni richiesta. Per un controllo di tendenza è la vista più veloce che hai, e il tutorial su Google Search Console spiega dove trovarla.

I suoi limiti spiegano perché i log contano ancora. Il report è disponibile solo per le proprietà di dominio e per le proprietà a prefisso URL di primo livello. Copre solo i crawler di Google, quindi GPTBot, ClaudeBot e gli altri mancano. Raggruppa i dati invece di elencare ogni URL, quindi può dirti che le richieste di scansione sono calate, ma non quali template le hanno perse. Usalo per notare che qualcosa è cambiato, poi usa i log per scoprire cosa.

La guida di Google sul report Statistiche di scansione descrive ogni raggruppamento. Quando il grafico e il tuo export di log non concordano, non fidarti di nessuno dei due finché non hai controllato la finestra temporale e il passaggio di verifica. La maggior parte di queste discrepanze deriva da una finestra diversa, da una CDN che risponde dalla cache o da un conteggio di bot che include richieste non verificate.

Correggere lo spreco di scansione una volta individuato

Le correzioni derivano dai segnali. La maggior parte si riduce a tre mosse: smettere di mandare i crawler verso pagine che non contano, indirizzarli direttamente all'URL finale quando una pagina è stata spostata e rendere più veloci le pagine che contano.

Navigazione a faccette. Filtri e ordinamenti generano molti URL con contenuto quasi identico. Consolidali con i canonical dove puoi, e rimuovi i link interni alle varianti senza valore di ricerca. Quando una variante non si può consolidare e deve restare fuori dalla scansione, bloccala nel robots.txt. La linea guida di Google è precisa su questo punto: non usare noindex per questo, perché Google deve comunque richiedere la pagina prima di poter vedere il tag. Ecco il tipo di regola da testare:

User-agent: Googlebot
Disallow: /*?sort=
Disallow: /*?color=

Mantieni la modifica al robots.txt nella giusta proporzione. Google dice che bloccare degli URL non libera crawl budget per le altre pagine, a meno che il sito non abbia già raggiunto il limite di capacità. Il blocco serve per URL senza valore, non per spostare il budget sulle tue pagine migliori. La nostra voce del glossario su robots.txt spiega come il file viene letto.

Catene di redirect. Quando una pagina è stata spostata due volte, il crawler attraversa entrambi i redirect ogni volta. Aggiorna i link interni perché puntino all'URL finale, e mantieni i vecchi redirect per i link esterni. La scelta tra redirect permanente e temporaneo conta per lo stesso motivo, e la guida 301 vs 302 lo spiega nel dettaglio.

Pagine eliminate. Restituisci un 404 o un 410 per le pagine rimosse in modo permanente. Google dice che i soft 404 continuano a essere scansionati e sprecano crawl budget, quindi un messaggio di «pagina non trovata» servito con stato 200 è peggio di un vero 404.

Tempo di risposta e cache. Google dice che risposte lente o in errore lo portano a scansionare di meno. Supporta le risposte 304 (Not Modified), così le pagine invariate possono essere servite dalla cache. Poi guarda i template che ricevono più hit di Googlebot e rendi più veloci quelle risposte per primi.

Gli errori che costano di più, e come evitarli

La maggior parte delle analisi di log che vanno male commette uno di un piccolo insieme di errori. Ciascuno di quelli sotto ha un sintomo che puoi individuare nei dati e una correzione che puoi applicare nella stessa settimana.

Fidarsi della stringa dello user agent

Cos'è: contare come scansione di Google ogni richiesta che si dichiara «Googlebot». Come riconoscerlo: hit di Googlebot da indirizzi IP che non si risolvono negli hostname di Google, oppure un balzo improvviso da un singolo indirizzo. Come correggerlo: esegui la verifica della sezione sul metodo prima di contare qualsiasi cosa, e tieni gli hit non verificati in un gruppo separato, così puoi continuare a vedere l'attività degli scraper.

Leggere solo le risposte 200

Cos'è: concentrarsi sulle pagine che restituiscono 200 e ignorare il resto. Come riconoscerlo: il tuo report non ha una sezione per 3xx, 4xx o 5xx, oppure la composizione dei codici di stato non viene mai discussa. Come correggerlo: parti sempre dalla distribuzione dei codici di stato. Un aumento di hit 404 può rivelare un link interno rotto, e un aumento di hit 5xx può rivelare un problema del server che rallenta tutta la scansione.

Bloccare una pagina che vuoi deindicizzare

Cos'è: aggiungere una regola del robots.txt a una pagina che ha anche un tag noindex. Come riconoscerlo: la pagina resta nell'indice, e il log non mostra hit di Googlebot, perché il crawler è bloccato nel richiederla. Come correggerlo: rimuovi il blocco così Google può leggere il tag noindex, aspetta che la pagina esca dall'indice, poi ripristina il blocco se ti serve ancora. La guida su Bloccata dal robots.txt spiega lo stato della Search Console che compare in questo caso.

Confrontare finestre di durata diversa

Cos'è: confrontare un export di 3 giorni prima di una correzione con uno di 30 giorni dopo. Come riconoscerlo: i totali si muovono molto, ma la quota per template non cambia. Come correggerlo: confronta lo stesso numero di giorni, possibilmente nello stesso periodo dell'anno, e confronta quote invece di totali grezzi quando il volume cambia.

Misurare gli hit invece del valore

Cos'è: festeggiare un aumento degli hit di Googlebot senza controllare se quegli hit raggiungono pagine indicizzate. Come riconoscerlo: gli hit si concentrano su URL non indicizzati o che non generano mai traffico. Come correggerlo: incrocia i tuoi gruppi di log con lo stato di indicizzazione dello strumento di ispezione URL della Search Console, e considera una correzione un successo solo quando la scansione si sposta verso le pagine che contano.

Dove si collocano i bot IA negli stessi log

Gli stessi log mostrano cosa fanno i crawler IA sul tuo sito, e il metodo è lo stesso: raggruppali, verificali dove il fornitore offre un modo per farlo, e leggi i codici di stato. La nostra guida ai log dei crawler IA copre quali bot cercare e in cosa si differenziano da Googlebot. Questo articolo approfondisce il metodo Googlebot, e la sezione IA qui sotto mostra come unire i due in un solo report.

Tipo di bot	Esempi	Cosa controllare nei log	Dove approfondire
Crawler di ricerca	Googlebot	Hit per template, composizione dei codici di stato, tempo alla prima scansione delle nuove pagine	Le sezioni precedenti di questo articolo
Crawler di addestramento	GPTBot, ClaudeBot, CCBot	Se richiedono i tuoi contenuti e se rispettano il tuo robots.txt	Robots.txt per i crawler IA
Crawler di recupero	ChatGPT-User, PerplexityBot	Brevi raffiche di visite legate alle domande degli utenti, e le pagine che raggiungono	Log dei crawler IA

La distinzione tra addestramento e recupero deriva da come sono documentati i crawler IA. I crawler di addestramento raccolgono contenuti per i modelli, quelli di recupero prelevano pagine quando un utente fa una domanda. Il tuo report dovrebbe tenerli separati, perché una decisione di policy per uno non si applica automaticamente all'altro.

Se vuoi vedere traffico Google e traffico IA affiancati mentre applichi queste correzioni, la dashboard GEO / SEO di Sorank li mostra in un'unica vista. Usala per verificare se le modifiche che fai a partire dai log muovono il traffico, e non solo i conteggi di scansione.