Nei log puoi leggere le richieste ricevute dal server e i campi registrati: indirizzo, orario, risposta e user-agent, secondo la configurazione. Affiancano Search Console quando vuoi capire come vengono visitati gli URL.
La log file analysis SEO mostra le richieste osservate nel periodo analizzato. Aiuta a riconoscere percorsi frequenti o pagine poco visitate dai crawler, ma non spiega da sola perché una pagina perde posizioni.
Risposta breve: cosa si scopre dai log?
Verifica prima l’identità dei crawler e la copertura dei log. Poi confronta URL, risposte e frequenza delle richieste con catalogo, sitemap e priorità del sito. Senza questo contesto rischi di contare eventi senza sapere se sono utili.
Log raw, Crawl Stats e URL Inspection
| Fonte | Punto di forza | Limite |
|---|---|---|
| Access log | Richieste reali e filtrabili per URL | Richiede accesso, parsing e verifica bot |
| Crawl Stats | Trend Google per host, tipo e risposta | Mostra esempi, non una cronologia URL completa |
| URL Inspection | Diagnosi approfondita di una pagina | Non è adatta all’analisi massiva storica |
Quali campi raccogliere
Un formato utile include almeno:
- timestamp con fuso orario;
- host e URL richiesto;
- metodo HTTP;
- status code;
- byte trasferiti;
- tempo di risposta;
- user agent;
- IP client;
- referrer, se disponibile;
- cache status e upstream time, quando configurati.
Con più CDN, load balancer e origin, chiarisci quale livello conserva l’IP reale e come vengono uniti i file. Proteggi dati personali, limita accessi e applica la retention prevista dalle policy aziendali.
Un file di log diventa informazione SEO quando ogni richiesta può essere collegata a una URL normalizzata e a un tipo di pagina. Conserva almeno timestamp con fuso orario, metodo, path, query string, status, byte trasferiti, user agent, IP e tempo di risposta. Aggiungi poi dati dell’inventario: canonical, indexability, template, data di modifica, presenza in sitemap, click e conversioni.
Questa unione crea il contesto che manca al conteggio grezzo. Cento richieste su una directory possono essere normali per prodotti aggiornati ogni ora e anomale per parametri di ordinamento senza valore. Lo stesso status 404 può rappresentare un vecchio backlink da recuperare oppure scansioni casuali che non richiedono alcun intervento.
Verificare Googlebot
Il nome Googlebot nello user-agent può essere copiato. Per le richieste che entrano nel campione, usa gli intervalli IP aggiornati oppure la procedura DNS inversa e diretta indicata da Google per verificare Googlebot. Nel percorso DNS, controlla anche il dominio previsto e che la risoluzione diretta riconduca all’indirizzo di partenza.
Conserva metodo, esito e data della verifica. Usa una cache controllata per non ripetere lookup costosi su ogni riga, e aggiorna le fonti secondo la pipeline adottata. Mantieni distinguibili i diversi crawler: richieste a documenti, immagini e risorse non rispondono sempre alla stessa domanda SEO.
Preparare e normalizzare i dati
Converti timestamp, decodifica URL, separa path e parametri e normalizza host, protocollo e casing secondo il comportamento reale del sito. Non cancellare subito query string: spesso sono proprio il segnale di crawl waste.
Rimuovi asset o bot soltanto dopo aver salvato una vista raw riproducibile. Un’analisi che cambia i filtri senza versionamento non può essere confrontata nel tempo.
Controllare dove termina la visibilitĂ dei log
Un access log dell’origine non contiene necessariamente le richieste soddisfatte dalla cache CDN. Prima di calcolare frequenze di crawl, documenta punto di raccolta, periodo conservato, eventuale campionamento, fuso orario e richieste escluse. Se unisci edge e origine, usa un identificatore di richiesta per evitare di contare due volte lo stesso accesso.
Una risposta 200 nel log prova che quel livello ha registrato una risposta di successo, non che il contenuto fosse completo, renderizzato o indicizzato. Conserva separatamente percorso, query string, status e byte; aggrega i parametri solo dopo aver distinto quelli che cambiano la pagina da quelli di tracking. Per confermare il bot usa la procedura ufficiale di verifica di Googlebot, senza affidarti al solo user-agent.
Dal record grezzo a una decisione verificabile
Campione di test interamente simulato. L’indirizzo 203.0.113.10 è riservato alla documentazione: non è un IP Googlebot verificato. Un nome nello user-agent non cambia questo fatto.
2026-09-22T09:00:00Z 203.0.113.10 GET /categoria/?sort=price 200 18420 "Googlebot"
# Campi derivati da conservare separatamente:
# source=edge; request_id=demo-001; bot_verified=false
# template=category; parameter_class=sorting| Passaggio | Output illustrativo | Cosa non concludere |
|---|---|---|
| Verifica identitĂ | bot_verified=false per la riga dimostrativa. | Non sommarla alle richieste Googlebot autentiche. |
| Aggregazione di un diverso campione già verificato | 40 richieste sorting su 100 documenti = 40%; conteggi simulati. | Il 40% non misura la quota indicizzata né un benchmark di spreco. |
| Decisione | Verificare come i link generano il sorting e se serve una destinazione organica. | Non bloccare parametri utili senza analizzare intento e controlli. |
Per dati reali usa gli intervalli IP o la verifica DNS ufficiale. Registra punto di raccolta, fuso orario, campionamento e deduplicazione edge/origine: senza questi campi un confronto prima/dopo può misurare cambiamenti della pipeline anziché del crawling.
Segmentare per template e directory
Una tabella per URL è troppo rumorosa. Classifica richieste in segmenti:
- home e pagine istituzionali;
- categorie;
- prodotti o schede;
- articoli;
- filtri e parametri;
- paginazione;
- redirect e 404;
- API, CSS e JavaScript;
- sitemap e robots.txt.
Il confronto per template mostra se Googlebot spende richieste sulle pagine prioritarie o su spazi di URL secondari.
Metriche fondamentali
- crawl hits per giorno e segmento;
- URL uniche richieste;
- frequenza media e distribuzione dei recrawl;
- quota 2xx, 3xx, 4xx, 5xx e 429;
- tempo di risposta per crawler e template;
- percentuale di URL con parametri;
- richieste su pagine non canoniche;
- URL in sitemap mai richieste nel periodo;
- pagine organiche senza crawl recente.
Non trasformare la frequenza in un obiettivo assoluto. Google chiarisce che piĂą crawling non garantisce posizioni migliori.
Status code: leggere il pattern
Un 301 può essere corretto durante una migrazione; migliaia di richieste ricorrenti su redirect interni indicano link o sitemap da aggiornare. Un 404 può essere normale per una risorsa rimossa; un picco su URL appena pubblicati segnala un problema di routing.
I 5xx e 429 richiedono attenzione: errori e rate limiting possono portare i crawler a ridurre la frequenza. Segmenta per host, orario e endpoint per trovare la capacitĂ insufficiente.
Crawl waste e spazi infiniti
Cerca parametri di sort, sessioni, calendari infiniti, filtri, URL di ricerca, duplicati, ID traccianti e combinazioni vuote. La navigazione a faccette è una fonte frequente di espansione.
Prima di bloccare, verifica come Google scopre gli URL e se sono già indicizzati. Robots.txt controlla il crawling, non garantisce la rimozione dall’indice.
Pagine importanti poco scansionate
Una pagina mai vista nei log può essere nuova, orfana, troppo profonda, esclusa dalla sitemap, bloccata o priva di domanda di crawl. Controlla anche canonical e status.
Collega la diagnosi alla guida sulle orphan pages e all’internal linking. Richiedere indicizzazione manualmente non sostituisce una struttura stabile.
Confrontare log e sitemap
Una sitemap segmentata consente di misurare:
- URL inviate e mai richieste;
- URL richieste ma non presenti nelle sitemap;
- pagine non canoniche inserite per errore;
- template con scoperta lenta;
- effetto di aggiornamenti
lastmodaffidabili.
La guida alla sitemap XML approfondisce segmentazione e qualità dell’inventario.
Analisi prima e dopo un rilascio
Annota migrazioni, modifiche robots, nuovi filtri, cambi di rendering e release infrastrutturali. Confronta finestre equivalenti e controlla variazioni per status, template e tempo di risposta.
Per una migrazione, conserva i log del vecchio e nuovo ambiente e monitora richieste agli URL precedenti, redirect e adozione delle nuove pagine.
Log analysis per JavaScript
Le richieste al documento e alle risorse possono mostrare se Googlebot e il Web Rendering Service recuperano script e API essenziali. I log non dicono da soli se il DOM finale è corretto: abbinali a test di rendering, ispezione del DOM e verifica delle risorse bloccate.
Nota editoriale: finché la guida JavaScript è in bozza, usa i controlli tecnici già pubblicati e non creare link interni verso URL non live.
Trasformare l’analisi in una roadmap
Una percentuale di richieste verso URL di ordinamento è un punto di partenza. Aggiungi quali componenti generano quei link e quale modifica vuoi testare. Dichiarane la fonte: un dato d’esempio non è una misura del sito.
Evita soglie universali. Un sito editoriale, un marketplace e un catalogo stagionale hanno pattern diversi.
Dashboard minima
- richieste e URL uniche nel tempo;
- status code per template;
- tempo di risposta;
- Googlebot smartphone, desktop e altri crawler;
- crawl su parametri e non canoniche;
- copertura sitemap;
- top directory e anomalie;
- annotazioni di rilascio.
Errori frequenti
- fidarsi dello user agent senza verifica;
- analizzare pochi giorni senza stagionalitĂ ;
- confondere richieste e URL uniche;
- ignorare CDN, cache e host secondari;
- rimuovere parametri prima dell’analisi;
- considerare ogni 404 uno spreco;
- promettere ranking attraverso piĂą crawl;
- conservare log sensibili senza governance.
Vedere ciò che il crawler fa davvero
I log sostituiscono le ipotesi con richieste osservate. Il loro valore nasce quando vengono collegati a struttura, qualitĂ delle pagine e capacitĂ del server.
Esempio di segmentazione che porta a una decisione
| Segmento | Evidenza nei log | Verifica successiva | Azione possibile |
|---|---|---|---|
| Prodotti attivi | Crawl raro dopo variazioni di stock | Link interni e lastmod | Migliorare discovery e aggiornamenti |
| Filtri non strategici | Molte richieste, nessuna domanda organica | Origine degli href e parametri | Ridurre la generazione di URL |
| Redirect | Catene o richieste ripetute sul vecchio URL | Mappa redirect e link interni | Puntare direttamente alla destinazione |
| 5xx | Picchi per template o fascia oraria | Deploy, cache e infrastruttura | Aprire un incidente tecnico |
La tabella non trasforma una correlazione in causa. Se il crawl cala insieme al traffico, verifica prima domanda, ranking, indexability e modifiche tecniche. I log dicono che una richiesta è avvenuta; non spiegano da soli perché Google ha scelto di effettuarla o come valuta la pagina.
Prima e dopo: il confronto che rende il dato azionabile
Definisci una baseline precedente al cambiamento e annota deploy, migrazioni, regole robots, modifiche ai filtri e aggiornamenti della sitemap. Confronta quote, non solo volumi assoluti: percentuale di crawl su URL canonici, quota di 2xx/3xx/4xx/5xx, tempo fino alla nuova scansione e distribuzione per template.
Chiudi l’analisi con un controllo che puoi ripetere. Indica il gruppo di URL, la causa ipotizzata e chi verificherà l’intervento. “Googlebot spreca risorse” è troppo generico per guidare una correzione.
