Statistiche di scansione in Search Console: leggerle bene

Il report Statistiche di scansione di Search Console è l'unico punto in cui Google ti mostra, con i suoi numeri, quanto e come Googlebot visita il tuo sito. Non dice se le pagine sono indicizzate e non dice come si posizionano: dice quante richieste sono arrivate, a quali risorse, con quale esito e con quale velocità ha risposto il server. È un dato di processo, non di risultato, ed è proprio per questo che si legge male se lo si tratta come un indicatore di performance.

Il vantaggio pratico è che funziona senza alcun accesso al server. Chi non può scaricare i log di Apache o Nginx, perché il sito sta su un hosting gestito, dietro una CDN o in mano a un fornitore poco collaborativo, ottiene comunque una fotografia abbastanza fedele della scansione degli ultimi novanta giorni. Qui vediamo dove si trova il report, cosa significa ogni grafico, quali pattern indicano un problema e quali sono invece rumore normale.

Dove si trova e cosa copre davvero

Il report sta in Impostazioni, sotto la voce Statistiche di scansione, e si apre con un link che dice di aprire il report. Esiste solo per proprietà a livello di dominio o per proprietà con prefisso dell'URL posizionate alla radice dell'host. Se hai verificato soltanto una sottocartella come prefisso, per esempio il solo blog, il report non sarà disponibile: per questo conviene avere una proprietà di dominio, che inoltre raccoglie tutti i sottodomini e i protocolli in un unico posto.

La finestra temporale è di circa novanta giorni, non modificabile e non esportabile in storico lungo. Se vuoi confrontare un mese di oggi con lo stesso mese dell'anno scorso, non puoi: devi salvare tu i dati a intervalli regolari. Un'abitudine semplice è fare uno screenshot o copiare i totali una volta al mese in un foglio di calcolo, così da costruirti la serie storica che Google non conserva.

In cima trovi tre grafici a linee, ciascuno con il proprio totale: il numero complessivo di richieste di scansione, la dimensione totale scaricata e il tempo medio di risposta. Sono tre letture indipendenti e vanno guardate insieme. Più richieste non significa per forza più pagine nuove scoperte, e una dimensione scaricata in crescita con richieste stabili indica che le risorse sono diventate più pesanti.

Un dettaglio che si tende a dimenticare: il conteggio riguarda le richieste, non gli URL. Una sola pagina può generare decine di richieste, perché Googlebot scarica anche i file CSS, JavaScript, le immagini e le chiamate API necessarie per renderla. Il numero che vedi quindi non è il numero di pagine visitate, ed è un errore confrontarlo direttamente con il totale delle pagine del sito.

Richieste per risposta: il grafico che smaschera gli errori

La suddivisione per risposta raggruppa le richieste in base al codice di stato HTTP restituito. È il grafico più utile per una diagnosi rapida, perché un sito sano ha una distribuzione molto riconoscibile: la grande maggioranza di risposte 200, una quota di 301 o 302 dovuta ai reindirizzamenti, qualche 304 quando le risorse non sono cambiate e una coda minima di errori.

Cliccando su ciascun gruppo vedi la percentuale sul totale e, soprattutto, un elenco di URL di esempio. Non è l'elenco completo, è un campione, ma basta quasi sempre a capire il pattern. Se gli esempi dei 404 sono tutti URL con un parametro di sessione o un vecchio prefisso di categoria, hai trovato la causa senza aprire un solo log.

• Molti 301 e 302: indicano catene di reindirizzamenti o link interni che puntano ancora alla vecchia versione dell'URL. Ogni salto consuma una richiesta che non porta contenuto. Correggi i link interni perché puntino direttamente alla destinazione finale.
• Molti 404: se gli URL compaiono perché altri siti o vecchie mappe li linkano, di solito è innocuo. Se nascono da link interni rotti o da un generatore di URL difettoso, sono sprechi da eliminare.
• Errori 5xx: sono il segnale più serio. Una quota anche piccola ma persistente suggerisce che il server cede sotto carico, e Google tende a ridurre il ritmo di scansione quando incontra errori di server ripetuti.
• Bloccato da robots.txt: se vedi richieste bloccate che non ti aspetti, controlla che la regola nel file non sia più larga del necessario.
• Timeout e altri errori di connessione: compaiono come gruppi separati e sono spesso il primo indizio di un hosting sottodimensionato.

Per tipo di file: dove va il budget di scansione

Il secondo grafico divide le richieste per tipo di file: HTML, JavaScript, CSS, immagini, JSON, PDF, video, XML e altri. Serve a capire se Googlebot spende le sue richieste sulle pagine che contano o su tutto il resto. Su un sito tradizionale ti aspetti una buona parte di HTML; su un sito che carica i contenuti via JavaScript vedrai una quota alta di JS e JSON, e questo è normale.

Il segnale da cercare è lo squilibrio anomalo. Un sito di poche centinaia di pagine che registra una quota enorme di richieste verso file JSON o verso una singola cartella di risorse sta probabilmente esponendo a Google un meccanismo, come una chiamata API con parametri variabili, che genera URL a ripetizione. Un sito con molte richieste verso immagini in formati pesanti potrebbe avere problemi di ottimizzazione che il report dei Core Web Vitals non mostrerà mai.

Anche il valore Altro tipo di file merita attenzione. Se cresce, di solito significa che stanno comparendo estensioni o risposte senza tipo chiaro, ad esempio pagine di errore servite con un content type sbagliato. Apri gli esempi e verifica quali URL finiscono lì.

Per scopo: scoperta contro aggiornamento

Il grafico per scopo distingue due categorie. La scoperta raccoglie le richieste verso URL che Googlebot non aveva mai visto prima. L'aggiornamento raccoglie le richieste verso URL già noti, che vengono riscansionati per controllare se sono cambiati.

Leggere il rapporto tra le due è istruttivo. Un sito editoriale che pubblica ogni giorno dovrebbe mostrare una quota visibile di scoperta nei giorni di pubblicazione. Se hai lanciato cinquanta nuove pagine e la scoperta resta piatta per settimane, significa che Google non le trova: mancano link interni, la sitemap non è stata letta o le pagine sono orfane. Al contrario, un sito statico da anni avrà quasi solo aggiornamento, ed è del tutto fisiologico.

Una quota di scoperta improvvisamente alta senza nuove pagine pubblicate è un campanello d'allarme diverso: qualcosa sta creando URL nuovi. Le cause tipiche sono filtri a faccette, parametri di tracciamento, risultati di ricerca interna o calendari infiniti. In questo caso gli URL di esempio sono preziosi, perché mostrano esattamente la forma dei parametri che si moltiplicano.

Vale anche il ragionamento inverso dopo una migrazione. Subito dopo il cambio di struttura degli URL ci si aspetta un picco di scoperta, seguito da un aumento delle richieste di aggiornamento man mano che Google riassegna i segnali. Se il picco non arriva, le nuove URL non sono state scoperte abbastanza in fretta.

Per tipo di Googlebot e per host

Il grafico per tipo di Googlebot distingue lo smartphone, il desktop, l'immagine, il video e altri crawler di Google che passano dal sito. Per la gran parte dei siti la scansione principale avviene con Googlebot smartphone, perché l'indicizzazione è basata sulla versione mobile. Se vedi una quota rilevante di desktop su un sito ormai completamente responsive, vale la pena capire perché: a volte indica una versione separata per dispositivi diversi, altre volte semplicemente una prima scansione più datata.

Nelle proprietà di dominio trovi anche il dettaglio per host, cioè per sottodominio. È il modo più rapido per scoprire che il sottodominio di staging o una vecchia versione del sito, dimenticati online, consumano una fetta di richieste che non dovrebbe spettare loro. Quando la ripartizione mostra che un host secondario assorbe più traffico di scansione dell'host principale, hai una priorità chiara da gestire, in genere con una protezione tramite autenticazione o con un blocco adeguato.

Stato dell'host: robots.txt, DNS e connettività

Sopra i dettagli c'è la sezione dello stato dell'host, che riporta tre controlli: il recupero del file robots.txt, la risoluzione DNS e la connettività del server. Per ognuno vedi se negli ultimi novanta giorni ci sono stati problemi, con un indicatore di stato e un grafico della percentuale di insuccessi.

Il controllo del robots.txt è il più delicato. Se Googlebot non riesce a recuperare il file, per esempio perché risponde con errori di server, la scansione può essere sospesa in via precauzionale per quel host, dato che Google preferisce non rischiare di scansionare ciò che potresti aver vietato. Un file robots.txt che restituisce 404 è invece trattato come assenza di restrizioni. Quindi un errore 5xx su quell'unico file pesa molto più di decine di 404 su pagine qualsiasi.

Gli altri due controlli guidano l'azione. Problemi di DNS puntano al provider del dominio o alla configurazione dei nameserver, e vanno risolti lì, non nel CMS. Problemi di connettività indicano un server che rifiuta o lascia cadere le connessioni, spesso per limiti di banda, firewall troppo aggressivi o picchi di carico. Un firewall che blocca per errore gli indirizzi di Googlebot è un caso classico: il sito funziona per i visitatori e fallisce solo per Google. Per verificarlo, confronta l'indirizzo di origine con quelli pubblicati da Google, senza fidarti del solo user agent, che chiunque può falsificare.

Per questi segnali esiste una regola pratica di lettura. Un episodio isolato di pochi giorni, già rientrato, è da annotare ma non richiede interventi. Un problema ricorrente, o che dura da settimane, merita un intervento subito, perché degrada la capacità di Google di scansionare l'intero sito.

Il tempo di risposta e cosa farne

Il tempo medio di risposta nel report misura quanto ci mette il server a rispondere alle richieste di Googlebot, non quanto impiega la pagina a caricarsi nel browser. Non è quindi un Core Web Vital e non va confuso con metriche come LCP: riguarda la velocità del server nel consegnare i byte, non il rendering.

Il motivo per cui conta è meccanico. Se il server risponde lentamente, Googlebot riduce da solo il ritmo per non sovraccaricarlo, e nello stesso periodo completa meno richieste. Il grafico del tempo di risposta e quello delle richieste totali si leggono quindi in coppia: un aumento dei tempi seguito da un calo delle richieste è la firma tipica di un sito che rallenta e viene scansionato meno.

Un esempio concreto. Dopo il lancio di un plugin di personalizzazione, il tempo medio passa da poche centinaia di millisecondi a oltre un secondo e le richieste giornaliere scendono in modo netto nell'arco di una settimana. Non serve un log per sospettare il collegamento: basta sovrapporre le date dell'intervento ai due grafici. Annullare o ottimizzare il plugin, e verificare che i tempi tornino alla normalità, permette di vedere il ritmo di scansione risalire gradualmente.

Attenzione alle letture ingenue: una media può nascondere picchi. Se ti risulta un valore accettabile ma senti lamentele di lentezza, cerca correlazioni con i giorni in cui compaiono gli errori 5xx o i timeout nel grafico per risposta.

Limiti del report rispetto ai log del server

Il report è un ottimo punto di partenza ma non sostituisce i log. Mostra soltanto il traffico di Google, non quello di Bing o di altri motori; riporta aggregati e campioni di URL, non il dettaglio di ogni richiesta; copre novanta giorni; e non permette di incrociare le visite di Googlebot con i singoli percorsi di un utente o di segmentare per sezione del sito in modo libero.

Per contro offre due vantaggi: è la versione ufficiale dei dati, quindi non devi verificare l'identità del crawler come fai nei log, dove molti bot si spacciano per Googlebot, e non richiede permessi tecnici. La strategia sensata è usarlo come primo livello di controllo e passare ai log solo quando devi scendere nel dettaglio di una specifica sezione, di un periodo più lungo o di un pattern che il campione non chiarisce.

Nel lavoro quotidiano un metodo semplice funziona bene. Una volta al mese apri il report, annoti i totali, guardi la distribuzione per risposta e per scopo, controlli lo stato dell'host e confronti con il mese precedente. Se nulla si sposta in modo anomalo, hai finito in dieci minuti. Se qualcosa si muove, hai già la direzione: quale gruppo è cambiato, con quali URL di esempio e da quale data.