Statistiche di scansione in Search Console: cosa guardare e come smascherare il finto Googlebot

Le statistiche di scansione di Search Console sono il rapporto che quasi nessun imprenditore apre, e spesso nemmeno il suo fornitore. Raccontano quante richieste fa Google al tuo sito, quanto risponde in fretta il server e se qualcosa ha impedito a Googlebot di entrare. Questa settimana Google ha dato due motivi per riprenderlo in mano: uno riguarda la salute del sito, l'altro i bot che usano il nome di Google per passare dove non dovrebbero.

01Perché Google torna a parlare delle statistiche di scansione

Il 29 ottobre Search Engine Roundtable ha riassunto un'intervista di David Iwanow a John Mueller. Tra i molti temi, Mueller ha definito il rapporto Statistiche di scansione poco usato e ha consigliato di controllarlo ogni tanto, per notare attività di scansione insolite o un aumento improvviso del tempo che Google impiega a scansionare le pagine. Ha aggiunto che i sistemi di IA scansionano i siti per addestrare i modelli o recuperare informazioni fresche, e che per lui questo resta SEO tecnica.

Il giorno dopo, sempre su Search Engine Roundtable, è uscito un estratto dell'intervista di Aneta Samkoff a Gary Illyes nell'Odys Podcast. Illyes attribuisce all'IA l'aumento dei bot che si fingono crawler legittimi: sempre più aziende cercano testi per addestrare i propri modelli e alcuni scraper si presentano come Googlebot perché "puoi dire di essere Googlebot e ti fanno entrare". Secondo l'articolo, Illyes ha anche predisposto delle trappole (honeypot) e ha visto richieste firmate "Googlebot" da indirizzi IP che con Google non avevano niente a che fare. Indica di non fidarsi del nome dichiarato dal bot (lo user-agent) e di verificare con il DNS inverso e gli indirizzi IP.

02Le statistiche di scansione ti servono davvero?

La guida di Search Console sul rapporto lo dice senza giri di parole: è pensato per utenti esperti e, se il sito ha meno di mille pagine, di solito non serve usarlo. La guida di Google sul crawl budget, cioè la quantità di scansione che Google dedica a un sito, indica come casi a rischio i siti molto grandi (dal milione di pagine) o quelli medi (dalle 10.000) con contenuti che cambiano ogni giorno. Il sito vetrina di uno studio di Bergamo non rientra in nessuna delle due categorie.

Non vuol dire che il rapporto sia inutile per una PMI. Vuol dire che non va guardato ogni settimana, ma in momenti precisi:

• Dopo un eventoCambio di hosting, rifacimento del sito, migrazione di dominio (in quel caso parti dalla nostra guida sul calo di traffico dopo la migrazione del sito), attivazione di un CDN o di un firewall, periodo offline.
• Con un sintomoPagine nuove che restano a lungo in "Rilevata, ma attualmente non indicizzata", sito lento, hosting che segnala picchi di consumo o di banda.
• Con un catalogoE-commerce o cataloghi con filtri, varianti e ricerca interna, dove gli URL possibili sono molti più delle pagine vere.

Una condizione tecnica: il rapporto esiste solo per le proprietà di tipo Dominio o per le proprietà con prefisso URL a livello di radice del sito, non per una sottocartella. Se hai solo una proprietà come "https://www.tuosito.it/shop/", il rapporto non c'è.

03Come leggere le statistiche di scansione di Search Console

Il rapporto copre gli ultimi 90 giorni e ha tre blocchi. Per leggerlo bene serve sapere come Google decide quanto scansionare. La guida sul crawl budget descrive due grandezze. Il limite di capacità è il tempo massimo che il server dedica alle connessioni con Google: parte da un valore prudente, sale se i tempi di risposta restano stabili o migliorano, scende se il server risponde con errori 5xx o chiede di rallentare con un 429. La domanda di scansione dipende invece da dimensioni, frequenza di aggiornamento, qualità e popolarità delle pagine. La stessa guida precisa che il limite di capacità è condiviso tra tutti i crawler di Google.

• Il grafico Richieste di scansione totali, dimensioni dei download e tempo medio di risposta. Le richieste comprendono anche quelle fallite e le risorse della pagina (immagini, CSS, JavaScript), e ogni risorsa conta come una risposta a sé. Per questo il numero non coincide con le pagine scansionate.
• Stato host Tre controlli: recupero del robots.txt, risoluzione DNS, connettività del server. Verde vuol dire nessun problema rilevante negli ultimi 90 giorni; "problemi non recenti" vuol dire almeno un problema negli ultimi 90 giorni ma non nell'ultima settimana; "problema recente" vuol dire almeno un problema nell'ultima settimana. Nel grafico di ogni controllo una linea rossa tratteggiata indica la soglia oltre la quale Google lo considera un problema.
• Le ripartizioni Per risposta (validi, 404, non validi), per tipo di file, per scopo (rilevamento di URL nuovi o aggiornamento di quelli noti) e per tipo di Googlebot (smartphone, computer, immagini, AdsBot, StoreBot, carico delle risorse e altri). Cliccando una voce si vedono URL di esempio, che Google stesso definisce non esaustivi.

Il controllo del robots.txt merita attenzione particolare, perché è quello con le conseguenze più pesanti. Secondo la guida, una risposta 200, 403, 404 o 410 va bene; un 429 o un 5xx no. Se il recupero fallisce, Google sospende la scansione del sito per le prime 12 ore e poi usa l'ultima versione valida per un massimo di 30 giorni. Un robots.txt che il firewall blocca a intermittenza può quindi fermare la scansione di tutto il sito, anche se le pagine funzionano.

04Cosa fare in pratica: controllo in sette passi e criteri di decisione

I primi cinque passi li può fare il titolare con l'accesso a Search Console. Gli ultimi due richiedono chi gestisce server o hosting, perché servono i log, cioè il registro di tutte le richieste ricevute dal sito.

• 1 · ApriIn Search Console vai in Impostazioni (in fondo al menu a sinistra) → Statistiche di scansione → Apri rapporto. Usa la proprietà Dominio, se ce l'hai: include anche i sottodomini (nell'elenco Host compaiono i primi 20 con traffico).
• 2 · Stato hostSe uno dei tre controlli segnala un problema recente, aprilo e annota le date. Tutto il resto viene dopo.
• 3 · AndamentoGuarda le linee di richieste e tempo medio di risposta sui 90 giorni. Cerca gradini, non oscillazioni: un cambio netto che coincide con una data (aggiornamento, nuovo plugin, cambio di hosting) è un indizio.
• 4 · RisposteApri il raggruppamento per risposta. I 404 sono classificati come "potenzialmente corretti" (abbiamo spiegato perché gli errori 404 di solito non sono un problema); contano errori del server (5xx), errori DNS, timeout, 401 e robots.txt non disponibile.
• 5 · EsempiNel raggruppamento per scopo, apri "Rilevamento" e scorri gli URL di esempio. Se vedi soprattutto filtri, ordinamenti, calendari o ricerche interne, Googlebot sta spendendo tempo su indirizzi che non ti servono.
• 6 · LogFornitore: estrae dai log le richieste con "Googlebot" nello user-agent per due o tre giorni e le confronta con il rapporto negli stessi giorni, sullo stesso host e solo per i tipi di Googlebot che hanno quella parola nel nome (smartphone, computer, immagini, video). Se c'è un CDN, usa i log del CDN, non quelli del server di origine.
• 7 · IPFornitore: se i numeri non tornano, o comunque su un campione degli IP più attivi, verifica gli indirizzi come descritto nella sezione successiva e decide se bloccare a livello di firewall o CDN.

Con i dati in mano, questi sono i criteri che usiamo nel lavoro di SEO tecnico per decidere se intervenire:

• Robots.txt KOErrori nel recupero del robots.txt: priorità assoluta. Di solito la causa è un firewall, un plugin di sicurezza o una regola di riscrittura che risponde 5xx o 429 a quel file.
• Lento e in caloTempo medio di risposta in salita per settimane e richieste in calo: è il quadro tipico di un limite di capacità che si abbassa. Il problema è il server (hosting sottodimensionato, cache assente, pagine pesanti da generare), non i contenuti.
• Calo senza erroriRichieste in calo, tempi stabili, nessun errore: guarda prima il robots.txt (una regola nuova troppo ampia è una causa citata da Google), poi la domanda: contenuti poco aggiornati o poco collegati.
• Picco di filtriRichieste in forte aumento e URL di esempio pieni di parametri: si interviene su link e robots.txt per filtri e ordinamenti, sapendo che il robots.txt blocca la scansione ma non toglie dall'indice ciò che c'è già.
• Picco e bastaRichieste in aumento senza errori né URL inutili: di solito non serve fare nulla. Pagine nuove, una sitemap aggiornata o un cambio di risorse bastano a spiegarlo.

Due semplificazioni circolano molto e vanno evitate. La prima è "più scansione vuol dire che Google apprezza il sito": le richieste possono salire perché Googlebot gira a vuoto su URL di filtri. La seconda è "il tempo di risposta del rapporto è un fattore di ranking": quel numero misura quanto il server regge la scansione e non è un fattore di ranking in sé. Un server lento pesa però anche sul tempo di caricamento percepito dagli utenti, e quindi sui Core Web Vitals. Per la scansione Google non indica una soglia ufficiale: le cifre che circolano sono indicazioni informali, non documentazione. Noi guardiamo la tendenza e il confronto con la stessa misura prima di un intervento.

Se dopo una migrazione o un periodo offline la scansione non riparte, i tempi di recupero tipici sono quelli che abbiamo descritto nell'articolo sui tempi di indicizzazione di Google; per i fermi programmati vale quanto spiegato su come mettere il sito in manutenzione con un 503.

05Googlebot falso: come scoprire i bot che si spacciano per Google

Lo user-agent è una riga di testo che ogni programma scrive da sé. Chiunque può scrivere "Googlebot" e molti sistemi di protezione lasciano passare quel nome per non rischiare di bloccare Google. Anche il robots.txt è un'indicazione che i bot rispettano per scelta: Illyes lo ricorda proprio parlando di chi lo ignora.

Qui il rapporto di Search Console diventa utile in un modo che le guide italiane non spiegano. I dati delle statistiche di scansione vengono dai sistemi di Google, non dal tuo server: un bot che si presenta come Googlebot da un IP qualsiasi non ci finisce mai. Se nei log, nello stesso giorno e sullo stesso host, le richieste con user-agent Googlebot sono molte di più di quelle che Search Console attribuisce ai tipi di Googlebot corrispondenti, la differenza è un primo indizio di traffico falso. Il confronto non sarà mai identico al numero: la guida avverte che possono esserci lievi differenze con i log, il rapporto include richieste fallite per errori DNS o di connessione che il server non registra, e un CDN davanti al sito risponde a una parte delle richieste senza che arrivino all'origine. Per questo noi consideriamo sospetta una differenza di più volte, non di qualche punto percentuale, e la usiamo solo come prima scrematura: la prova è la verifica degli IP.

Il passo successivo è la verifica, che Google descrive nella pagina Verifica le richieste dei crawler e dei fetcher di Google. Per pochi indirizzi basta il terminale (su Windows si usa nslookup al posto di host):

• 1 · DNS inversoDall'IP preso dai log, per esempio host 66.249.66.1, si ottiene un nome: nell'esempio di Google è crawl-66-249-66-1.googlebot.com.
• 2 · DominioIl nome deve appartenere a googlebot.com, google.com o googleusercontent.com. Un nome di un provider cloud qualsiasi o nessun nome: non è Google.
• 3 · DNS direttoSi interroga quel nome (host crawl-66-249-66-1.googlebot.com) e si controlla che restituisca lo stesso IP di partenza. Questo passaggio serve perché chi controlla un IP può configurarne il DNS inverso come vuole.

Per volumi grandi Google pubblica gli intervalli di IP in file JSON: common-crawlers.json per i crawler comuni come Googlebot, special-crawlers.json per quelli speciali come AdsBot, e tre file per i fetcher attivati dagli utenti, che il robots.txt lo ignorano per definizione. Molti CDN e firewall applicativi hanno già una regola per i "bot verificati" basata su questi elenchi: chiedi al fornitore se è attiva.

L'errore da non fare è bloccare lo user-agent "Googlebot" nel firewall o nel robots.txt per fermare gli impostori: si blocca anche quello vero. La regola corretta è il contrario: accettare le richieste con nome Googlebot solo dagli IP verificati, e trattare le altre come qualsiasi bot sconosciuto. Illyes stesso, sempre secondo l'articolo, dice che la maggior parte dei siti piccoli non deve agire subito: prima va accertato che quel traffico crei davvero un problema. Diventa un problema SEO quando rallenta il server: in quel caso i tempi di risposta salgono anche per il Googlebot vero e il limite di capacità può abbassarsi. È un'ipotesi che si controlla proprio nel grafico del tempo medio di risposta.

06Crawler IA: cosa le statistiche di scansione non ti dicono

Il rapporto elenca solo i crawler di Google. GPTBot, OAI-SearchBot e ChatGPT-User di OpenAI, PerplexityBot, ClaudeBot, Bingbot (che alimenta anche Copilot) e i bot di Meta non ci sono. Per sapere se un assistente IA riesce a leggere il tuo sito servono i log del server o le statistiche del CDN.

La logica del falso Googlebot vale anche qui. OpenAI pubblica nella sua pagina sui crawler un elenco di IP per ciascun bot (searchbot.json, gptbot.json, chatgpt-user.json) e consiglia di consentire le richieste di OAI-SearchBot da quegli intervalli per restare visibili nelle risposte di ChatGPT con ricerca. Una richiesta che si dichiara GPTBot da un IP fuori elenco va trattata come sconosciuta. L'errore opposto è più frequente: protezioni anti-bot che bloccano tutto ciò che non è Google, compreso OAI-SearchBot, con il risultato che il sito sparisce dalle citazioni senza che nessuno se ne accorga. Ne abbiamo parlato nell'articolo su come farsi indicizzare da ChatGPT e, per i bot di Meta, in quello sui crawler di Meta.

Per Google il discorso è diverso. Secondo la pagina di Google sulle funzioni IA della Ricerca, per comparire come link in AI Overview e AI Mode una pagina deve essere indicizzata e idonea a mostrare uno snippet, senza requisiti tecnici aggiuntivi. Statistiche di scansione sane sono quindi una condizione necessaria, non sufficiente. Google-Extended, che Illyes cita come esempio di controllo separato, secondo la documentazione sui crawler di Google è un token da indicare nel robots.txt che limita l'uso dei contenuti per addestrare Gemini e per il grounding nelle app Gemini; non incide sulla presenza nella Ricerca e non compare nel rapporto, perché non ha un user-agent proprio. Questa divisione è il punto di partenza di ogni analisi che facciamo nel lavoro di GEO: Search Console per Google, i log per tutti gli altri.

07Cosa ne pensiamo

Siamo d'accordo con Mueller sul fatto che il rapporto sia poco usato, ma per un sito di cinquanta pagine controllarlo ogni settimana produce soprattutto falsi allarmi, come un picco di richieste dopo un aggiornamento del tema. Il valore sta nell'aprirlo nei momenti giusti sapendo cosa cercare.

La parte che riteniamo più sottovalutata è un'altra: questo rapporto è l'unico dato sul traffico dei bot che arriva da Google e non dal tuo server. Con i bot che si fingono Google in aumento, è il riferimento per capire quanto del traffico "Googlebot" nei log sia vero. Per questo, quando un'azienda ci dice che l'hosting segnala consumi anomali, il primo confronto che facciamo è tra log e statistiche di scansione, prima di toccare robots.txt o firewall.

Ultima cosa, rivolta a chi riceve report dai fornitori: il numero di richieste di scansione non è un indicatore di successo e non dovrebbe comparire da solo in un report mensile. Le domande da fare al fornitore: lo stato host è verde? Il tempo di risposta è stabile? Googlebot passa il suo tempo sulle pagine che contano?

→In sintesi

Le statistiche di scansione di Search Console si leggono in quest'ordine: stato dell'host, andamento di richieste e tempo di risposta, risposte non valide, URL di esempio. Per un sito piccolo servono dopo un cambio di hosting, una migrazione, un periodo offline o quando le pagine nuove non vengono scansionate; per cataloghi ed e-commerce vanno guardate con più regolarità.

Il rapporto conta solo il Googlebot vero. Se i log mostrano molte più richieste "Googlebot", gli IP si verificano con DNS inverso e diretto o con i file JSON di Google, e si filtra per IP, mai per nome. Per i crawler di ChatGPT, Perplexity e Claude il rapporto non dice nulla: servono i log.

FAQDomande frequenti sulle statistiche di scansione

• →Dove si trovano le statistiche di scansione in Search Console?

  In Impostazioni, in fondo al menu a sinistra, alla voce Statistiche di scansione → Apri rapporto. Il rapporto è disponibile solo per le proprietà di tipo Dominio o con prefisso URL a livello di radice del sito, non per le sottocartelle, e copre gli ultimi 90 giorni.

• →Cosa vuol dire "problema recente" nello stato dell'host?

  Che nell'ultima settimana Google ha avuto almeno un problema nel recuperare il robots.txt, nel risolvere il DNS o nel collegarsi al server. Va aperto il controllo segnalato per vedere le date e capire se il problema si ripete. Gli errori sul robots.txt sono i più urgenti, perché possono sospendere la scansione dell'intero sito.

• →Un tempo medio di risposta alto penalizza il posizionamento?

  Nel rapporto il tempo di risposta indica quanto il server regge la scansione: se sale in modo stabile, Google riduce il limite di capacità e scansiona meno. Google non indica una soglia ufficiale da rispettare. Conta la tendenza, soprattutto dopo un cambio di hosting o di piattaforma.

• →Come faccio a sapere se un Googlebot nei log è vero?

  Con una ricerca DNS inversa sull'IP, che deve restituire un nome in googlebot.com, google.com o googleusercontent.com, seguita da una ricerca DNS diretta su quel nome, che deve restituire lo stesso IP. Per molti indirizzi si confrontano gli IP con gli elenchi JSON pubblicati da Google. Lo user-agent da solo non prova nulla.

• →Perché i log del server mostrano più richieste di Googlebot rispetto a Search Console?

  Piccole differenze sono normali: Google avverte che i valori del rapporto possono discostarsi un po' dai log, e un CDN o più sottodomini cambiano i conti. Una differenza di più volte sullo stesso host, invece, fa pensare a bot che usano il nome di Googlebot senza esserlo, perché il rapporto conta solo le richieste dei crawler di Google. In quel caso vanno verificati gli IP.

• →Le statistiche di scansione mostrano anche GPTBot e gli altri crawler IA?

  No, il rapporto mostra solo i crawler di Google, come Googlebot smartphone e computer, Googlebot Immagini, AdsBot e StoreBot. Per GPTBot, OAI-SearchBot, PerplexityBot o ClaudeBot servono i log del server o le statistiche del CDN, verificando gli IP con gli elenchi pubblicati dai rispettivi gestori.

↗Fonti

• GoogleReport Statistiche di scansione, guida di Search Console
• GoogleVerifica le richieste dei crawler e dei fetcher di Google
• GoogleOptimize your crawl budget (aggiornata il 22 luglio 2026)
• SE RoundtableGary Illyes From Google: AI Made Bot Impersonation Worse (30 ottobre 2026)
• SE RoundtableGoogle's John Mueller: Eventually Systems Will Catch The AI Spam & Tricks (29 ottobre 2026)
• GoogleAI features and your website
• GoogleList of Google's common crawlers (Google-Extended)
• OpenAIOverview of OpenAI Crawlers