Il crawling è il processo con cui un motore di ricerca scopre l'indirizzo di una pagina, lo richiede al server e ne scarica il contenuto. In italiano si chiama scansione ed è il primo dei passaggi che portano una pagina nei risultati.
La cosa da sapere prima di mettere mano a qualsiasi cosa: una pagina non scansionata non può essere indicizzata, ma una pagina scansionata non entra automaticamente nell'indice. Sono due problemi distinti, si leggono in due report diversi di Search Console e si risolvono in modi diversi. Confonderli è il motivo per cui capita di vedere siti da duecento pagine impegnati a ottimizzare il crawl budget mentre il problema sta altrove.
Cosa succede quando Googlebot passa sul sito
Googlebot è il nome generico di due crawler: Googlebot Smartphone e Googlebot Desktop. Per quasi tutti i siti Google indicizza la versione mobile del contenuto, quindi la maggior parte delle richieste arriva dal crawler mobile e solo una minoranza da quello desktop. I due rispondono allo stesso token nel robots.txt, quindi non si possono scrivere regole diverse per l'uno e per l'altro: capita di trovare file che ci provano, e non funzionano.
Dentro una singola visita succedono tre cose separate. Il crawler scopre un URL, nella maggioranza dei casi seguendo un link su una pagina già scansionata. Lo richiede al server e scarica la risposta. Poi consegna quello che ha raccolto alla coda di indicizzazione, dove la pagina viene eventualmente renderizzata, cioè aperta eseguendo il JavaScript, e valutata. Il rendering è una fase successiva con una coda propria: per questo una pagina può risultare scansionata e contenere comunque parti che Google non ha mai letto. Su chi passa davvero sul tuo sito e su come si verifica che sia Googlebot e non qualcuno che si spaccia per lui, c'è la voce dedicata ai web crawler.
I limiti di scansione che Google dichiara per iscritto
Non sono stime della comunità SEO: stanno nella documentazione di Google Search Central e in RFC 9309, lo standard IETF che dal 2022 definisce il protocollo di esclusione dei robot. Due valori sono stati aggiornati a febbraio 2026, quindi conviene riguardarli anche se pensi di conoscerli.
| Limite | Valore dichiarato | Dove è scritto |
|---|---|---|
| Porzione di un file HTML recuperata | primi 2 MB, il resto non viene scaricato | Google Search Central, pagina Googlebot |
| Porzione di un PDF recuperata | primi 64 MB | Google Search Central, pagina Googlebot |
| Frequenza media di accesso | non più di una richiesta ogni pochi secondi, per la maggior parte dei siti | Google Search Central, pagina Googlebot |
| Porzione di robots.txt analizzata | 500 KiB, il resto viene ignorato | Google, interpretazione del REP |
| Durata della cache del robots.txt | fino a 24 ore, di più in caso di timeout o errori 5xx | Google, interpretazione del REP |
| Redirect seguiti sul robots.txt | almeno 5, poi il file viene trattato come un 404 | Google, interpretazione del REP |
Il limite dei 2 MB si applica ai dati non compressi e vale separatamente per ogni risorsa richiamata nell'HTML: un bundle JavaScript o un foglio di stile sopra quella soglia viene troncato esattamente come una pagina. Quando il limite scatta, Googlebot interrompe il download e manda all'indicizzazione solo la parte che ha già scaricato.
Come Google scopre un indirizzo nuovo
La documentazione è netta: Googlebot trova i nuovi URL soprattutto dai link contenuti in pagine già scansionate. La sitemap è un supporto, non un sostituto. Una pagina presente in sitemap ma che nessun'altra pagina del sito collega viene scoperta con priorità bassa e può restare lì per settimane. È il motivo per cui i link interni sono prima di tutto una leva di scansione, e solo dopo una leva di posizionamento.
Sul tag lastmod vale una regola semplice: Google consiglia di includerlo, ma un lastmod che si aggiorna a ogni deploy senza che il contenuto sia cambiato smette di valere come segnale. Sui siti che cambiano spesso c'è una leva più trascurata, il codice 304 (Not Modified). Dice a Google che la pagina non è cambiata dall'ultima richiesta, gli fa riusare la copia che ha già e libera richieste per gli URL che invece sono cambiati davvero. Nel report Statistiche di scansione il 304 compare tra i codici di risposta validi, non tra i problemi.
Quando il robots.txt non risponde, Google smette di scansionare
Il punto più fragile di tutta la catena è il file che dovrebbe governarla. Google considera accettabili tre risposte per il robots.txt: un 200 con un file qualsiasi, anche vuoto o con errori di sintassi, e un 403, 404 o 410, che significano semplicemente che il file non esiste. Tutto il resto è un problema di connessione, e la documentazione di Search Console descrive nel dettaglio cosa succede dopo.
| Da quanto il robots.txt non dà una risposta valida | Cosa fa Google |
|---|---|
| Meno di 24 ore dall'ultimo recupero riuscito | usa il file in cache e scansiona normalmente |
| Prime 12 ore di indisponibilità | interrompe la scansione del sito, continua a richiedere il file |
| Da 12 ore a 30 giorni | riprende a scansionare usando l'ultimo robots.txt recuperato correttamente |
| Oltre 30 giorni, home page raggiungibile | si comporta come se il robots.txt non esistesse e scansiona senza restrizioni |
| Oltre 30 giorni, home page non raggiungibile | interrompe la scansione del sito |
Le due righe in fondo meritano attenzione: un robots.txt rotto abbastanza a lungo non blocca il sito, lo apre. Tutte le regole che pensavi di aver messo smettono di valere e le sezioni che avevi escluso tornano scansionabili.
Quanto è diffuso il problema? I dati del Web Almanac 2025 di HTTP Archive, raccolti su milioni di siti in tutto il mondo, dicono che l'85% delle richieste di robots.txt restituisce 200, il 13% restituisce 404, circa l'1% va in timeout e lo 0,1% risponde con un errore 5xx. Quello 0,1% è poca cosa in percentuale ed è esattamente il caso in cui la scansione si ferma senza che nessuno se ne accorga, perché il sito per gli utenti continua a funzionare.
Gli altri freni sono meno drammatici e molto più comuni. Errori 5xx e risposte 429 sulle pagine abbassano il limite di capacità di scansione che Google calcola per il sito. Le catene di redirect consumano richieste, e nel report ogni salto viene contato come una richiesta a sé: se la pagina 1 rimanda alla 2 che rimanda alla 3, Google registra tre richieste. Un tempo medio di risposta che peggiora riduce il numero di pagine recuperate nella stessa finestra.
Il crawl budget riguarda molti meno siti di quanti ne parlino
Google dice con precisione a chi si rivolge la propria guida sul crawl budget: siti oltre il milione di pagine uniche con contenuti che cambiano circa una volta a settimana, siti oltre le 10.000 pagine uniche con contenuti che cambiano ogni giorno, e siti con una quota consistente di URL classificati come "Rilevata, attualmente non indicizzata". Per tutti gli altri la stessa pagina suggerisce di tenere aggiornata la sitemap e controllare il report Indicizzazione delle pagine. Niente di più.
La soglia dichiarata per il report Statistiche di scansione è ancora più bassa: Google scrive che se il sito ha meno di mille pagine non dovrebbe servire guardare le scansioni a quel livello di dettaglio. Il report, tra l'altro, è disponibile solo per le proprietà a livello di directory principale, quindi una proprietà impostata su una sottocartella non lo mostra affatto.
Il budget è la somma di due componenti. Il limite di capacità dipende dalla salute del server: sale se il sito risponde in modo stabile, scende se rallenta o restituisce errori. La domanda di scansione dipende da popolarità, frequenza di aggiornamento e qualità percepita delle pagine. Sul primo si interviene con l'infrastruttura, sulla seconda riducendo il numero di URL inutili esposti al crawler, a partire da filtri, parametri e contenuti duplicati. L'ordine in cui conviene affrontare questi lavori è nella guida alla SEO tecnica.
Tre cose che si continuano a ripetere e che la documentazione smentisce
La prima: la direttiva crawl-delay nel robots.txt non è supportata da Google. I campi riconosciuti sono quattro, user-agent, allow, disallow e sitemap, e la documentazione dice esplicitamente che gli altri vengono ignorati. Se devi ridurre la frequenza di scansione per qualche ora o un paio di giorni, Google indica di restituire 500, 503 o 429, e avverte di non insistere oltre i due o tre giorni perché il segnale diventa permanente.
La seconda: rispondere 403 o 404 a Googlebot per rallentarlo non serve. I codici 4xx diversi dal 429 non hanno alcun effetto sulla frequenza di scansione e in compenso portano alla rimozione dei contenuti dalla Ricerca. Vale anche il contrario: un 404 su una pagina rimossa davvero è la risposta giusta, come spiega la voce sull'errore 404.
La terza: bloccare un URL nel robots.txt non lo fa uscire dall'indice. Se la pagina è bloccata il crawler non può leggere il noindex che ci hai messo dentro, e l'indirizzo può continuare a comparire nei risultati senza descrizione. Le due direttive agiscono su fasi diverse: una sulla scansione, l'altra sull'indicizzazione.
C'è un dato del Web Almanac che racconta la gestione della scansione meglio di qualsiasi guida: il 97,5% dei file robots.txt pesa meno di 100 byte, il 77% contiene solo la wildcard, e googlebot compare esplicitamente in circa il 6% dei file. Per la quasi totalità dei siti, quindi, la scansione non la governa nessuno: è quella che il CMS ha generato da solo il giorno dell'installazione e che poi nessuno ha più aperto. Se il tuo sito è abbastanza grande perché la cosa abbia conseguenze sul fatturato, aprire quel file e leggerlo è il primo controllo da cui partiamo in ogni progetto SEO.
Domande frequenti sul crawling
Il crawling è il recupero della pagina da parte del crawler. L'indicizzazione è la decisione successiva di archiviarla nell'indice. Senza scansione non c'è indicizzazione, ma la scansione da sola non garantisce nulla: in Search Console lo stato «Scansionata, attualmente non indicizzata» descrive esattamente questo caso.
Google scrive che per la maggior parte dei siti Googlebot non dovrebbe accedere più di una volta ogni pochi secondi in media. La frequenza reale dipende dal limite di capacità calcolato sulla salute del server e dalla domanda di scansione. Il report Statistiche di scansione mostra l'andamento del sito nel periodo considerato.
Lo strumento Controllo URL di Search Console permette di richiedere una scansione, senza garanzie sui tempi. Nella pratica pesa di più collegare la pagina da URL che Google visita già spesso e includerla nella sitemap. Google precisa che non è possibile chiedere un aumento della frequenza di scansione.
Secondo la guida di Google riguarda i siti oltre il milione di pagine uniche aggiornate ogni settimana, quelli oltre le 10.000 pagine aggiornate ogni giorno e quelli con molti URL in stato Rilevata, attualmente non indicizzata. Sotto queste soglie Google stessa consiglia di limitarsi a tenere aggiornata la sitemap e a controllare il report sull'indicizzazione.
No. I campi supportati sono user-agent, allow, disallow e sitemap; gli altri vengono ignorati. Per ridurre la frequenza di scansione per un tempo breve Google indica di restituire 500, 503 o 429, senza insistere oltre i due o tre giorni.
