Search Console mostra una parte dell’attività di crawling. I log del server registrano invece ogni richiesta ricevuta: URL, orario, status code, user agent, risposta e altri campi configurati.
La log file analysis SEO usa questi dati per capire cosa i crawler richiedono davvero, quali aree ignorano e dove il sito spreca risorse. Non indica direttamente perché una pagina non posiziona, ma rende osservabile il primo passaggio del processo.
Risposta breve: cosa si scopre dai log?
Puoi verificare frequenza di crawl, directory e template visitati, status code, redirect, parametri, risorse, tempi di risposta e comportamento prima e dopo un rilascio. Devi però autenticare i crawler, normalizzare gli URL e collegare i log a inventario, sitemap, canonical, traffico e priorità di business.
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.
Verificare Googlebot
Il nome “Googlebot” nello user agent non basta: può essere copiato. Google pubblica intervalli IP e procedure di verifica. Un metodo prevede reverse DNS, controllo del dominio atteso e forward DNS verso lo stesso IP.
Per pipeline ricorrenti, usa fonti ufficiali aggiornate e conserva il risultato della verifica. Non eseguire DNS lookup costosi su ogni riga durante ogni query.
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.
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
Ogni insight deve contenere segmento, evidenza, impatto, causa probabile e test. Esempio: “Il 28% delle richieste del campione riguarda URL di sort” non basta; serve indicare come vengono scoperte, quale regola le genera e quale modifica ridurrà lo spazio.
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.
Il dataset minimo per una log file analysis utile
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.
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.
Verificare davvero Googlebot
Lo user agent può essere falsificato. Per analisi sensibili, valida gli indirizzi usando gli intervalli IP pubblicati da Google oppure la procedura DNS inversa e diretta descritta nella documentazione su come verificare Googlebot. Mantieni separati Googlebot Smartphone, Googlebot Image e altri crawler quando il comportamento richiesto è diverso.
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 ogni analisi con una domanda falsificabile, un proprietario e una verifica. “Googlebot spreca crawl” è troppo vago; “il 38% delle richieste del campione raggiunge parametri di sorting senza impression, generati dal componente X” descrive invece che cosa ricontrollare. La percentuale deve provenire dai propri dati, non da un benchmark inventato.
