Il crawl budget riguarda il tuo sito?
Probabilmente no, se il sito ha poche centinaia di pagine e quelle nuove compaiono su Google in pochi giorni. Il crawl budget diventa un problema reale solo oltre una certa scala. Secondo la guida di Google sulla gestione del budget di scansione, i casi in cui conta sono tre:
- Siti con oltre un milione di pagine univoche i cui contenuti cambiano circa una volta a settimana.
- Siti con oltre 10.000 pagine univoche i cui contenuti cambiano ogni giorno.
- Siti con una quota consistente di URL segnalati in Search Console come “Rilevata, ma attualmente non indicizzata”.
Google stessa precisa che sono stime orientative, non soglie esatte. Il terzo segnale è il più utile in pratica: vuol dire che Google conosce quelle pagine ma non ha ancora speso richieste per leggerle. Da non confondere con “Pagina scansionata, ma attualmente non indicizzata”: lì la pagina è stata letta e scartata, e il problema di solito è la qualità o la duplicazione, non il budget.
Il budget si calcola per nome host. www.esempio.it e blog.esempio.it hanno budget separati.
Da cosa dipende il crawl budget
Google decide quanto scansionare pesando due cose insieme: quanto regge il server senza rallentare e quanto vale la pena tornare su quelle pagine. La prima è una misura tecnica, la seconda una stima di utilità. Google scansiona al massimo quanto il server sopporta, e comunque solo quanto ritiene utile. La maggior parte dei siti perde budget sulla seconda pur avendo la prima in ordine.
Limite di capacità di scansione
È il tempo complessivo che il tuo server può passare a tenere connessioni aperte per Google: contano sia il numero di connessioni in parallelo sia la loro durata. Sale se il sito risponde in modo rapido e stabile. Scende se i tempi di risposta si allungano o se compaiono errori 5xx e risposte 429. Questo limite è condiviso da tutti i crawler di Google: se un crawler ne consuma molto, ne resta meno per gli altri.
Nel conto entra anche il rendering. Come chiarisce Google nella pagina sui miti e fatti sulla scansione, il tempo dedicato al rendering di una pagina viene conteggiato al pari del tempo trascorso per richiederla. Pagine più leggere da elaborare significano più pagine lette a parità di risorse.
Domanda di scansione
È quanto Google vuole scansionare. Dipende soprattutto da:
- Inventario percepito: quanti URL Google conosce sul sito. È il fattore su cui hai più controllo.
- Popolarità: le pagine più linkate e cercate vengono riscansionate più spesso.
- Freschezza: Google torna su una pagina con la frequenza necessaria a cogliere le modifiche.
Così due siti della stessa dimensione possono essere scansionati a ritmi molto diversi. A cambiare non è il numero di pagine, è quante di quelle pagine meritano una seconda visita.
Conta ogni URL che Googlebot richiede, non solo le pagine: versioni alternative come quelle hreflang, file CSS e JavaScript, chiamate XHR. Tutto consuma lo stesso budget.
Dove si disperde il crawl budget
La dispersione non è quasi mai una pagina in più. È la stessa pagina raggiungibile da dieci indirizzi diversi, o una richiesta spesa per non leggere niente di nuovo.
| Dove si disperde | Come si riconosce | Come si corregge | Come verificare |
|---|---|---|---|
| Varianti da parametri e filtri | Molti URL con ? nei log e nel report di scansione | Blocco in robots.txt o URL canonico | Quota di richieste su URL con parametri in calo |
| Catene di redirect | Più di un 301 o 302 prima della pagina finale | Redirect diretto alla destinazione, link interni aggiornati | Meno risposte 3xx nelle Statistiche di scansione |
| Soft 404 | Pagine vuote o rimosse che rispondono 200 | Risposta 404 o 410 | Voce “Soft 404” nel report Indicizzazione in calo |
| Duplicati non consolidati | Stesso contenuto su URL diversi | URL canonico unico, varianti accorpate | Meno URL in “Pagina duplicata senza URL canonico selezionato dall’utente” |
| Pagine orfane e paginazione profonda | URL presenti in sitemap ma senza link interni | Link da pagine già visitate spesso | Frequenza di scansione delle pagine chiave in aumento |
| Server lento o instabile | Tempo medio di risposta alto, errori 5xx | Cache, risorse server, meno risorse per pagina | Tempo medio di risposta in calo, stato host verde |
Nel report Statistiche di scansione ogni passaggio di una catena di redirect conta come una richiesta separata. Una catena da tre passaggi costa tre richieste per leggere una sola pagina.
Navigazione per facet: una regola per decidere
Negli e-commerce i filtri per colore, taglia, prezzo e ordinamento sono la causa più comune di dispersione. Ogni combinazione genera un URL nuovo e il crawler non sa se è utile finché non lo scarica. La domanda da farsi per ogni tipo di filtro è una sola: questa combinazione deve comparire nei risultati di ricerca?
- No, serve solo agli utenti. Blocca quei parametri in robots.txt, oppure gestisci i filtri con frammenti dopo il #, che Google non scansiona. Lascia scansionabili la pagina di categoria senza filtri e le schede prodotto.
- Sì, ha una domanda di ricerca propria (ad esempio “scarpe da trail donna”). Rendila un URL stabile e pulito. Usa sempre lo stesso ordine dei filtri ed evita filtri duplicati nell’URL. Rispondi 404 quando una combinazione non ha risultati.
Nella guida sulla gestione della scansione degli URL di navigazione per facet, Google indica il blocco in robots.txt e i frammenti come i metodi più efficaci. Canonical e nofollow sui link dei filtri riducono la scansione solo nel tempo, e il nofollow funziona solo se è presente su tutti i link verso quell’URL.
Un esempio di regole per i parametri dei filtri:
User-agent: *
Disallow: /*?*colore=
Disallow: /*?*taglia=
Disallow: /*?*ordina=JavaScript e rendering
Google elabora le pagine in tre fasi: scansione, rendering, indicizzazione. Come spiega la guida di base sulla SEO per JavaScript, le pagine che rispondono 200 vengono messe in coda per il rendering, a meno che un meta tag robots o un’intestazione X-Robots-Tag dica a Google di non indicizzarle. Lì possono restare pochi secondi o molto di più, prima che un browser Chromium senza interfaccia esegua il JavaScript. Le pagine bloccate in robots.txt non vengono richieste affatto.
Per il crawl budget ci sono tre conseguenze:
- Se il contenuto o i link compaiono solo dopo il JavaScript, Google li scopre solo dopo il rendering. La scoperta delle pagine nuove rallenta.
- I link devono essere elementi a con attributo href. Pulsanti o eventi JavaScript senza href non vengono seguiti.
- Bloccare in robots.txt i file JavaScript o CSS necessari impedisce a Google di visualizzare la pagina come la vede un utente.
Il rendering lato server o il pre-rendering restano la scelta più sicura. Rendono il sito più veloce per utenti e crawler, e non tutti i crawler eseguono JavaScript.
Come ottimizzare il crawl budget, in ordine di resa
L’ordine conta più della lista. Prima si fermano le varianti alla fonte, poi si accorciano le catene, poi si sistemano i percorsi interni. Altrimenti ottimizzi percorsi verso indirizzi che stanno per cambiare.
- Ferma le varianti alla fonte. Consolida i duplicati indicando l’URL canonico e blocca con il file robots.txt filtri e ordinamenti che non servono in ricerca.
- Porta ogni redirect a un solo passaggio. Aggiorna link interni e sitemap verso la destinazione finale.
- Rispondi 404 o 410 alle pagine rimosse ed elimina i soft 404.
- Tieni la sitemap pulita e aggiornata: solo URL canonici che rispondono 200, con il tag lastmod aggiornato solo quando il contenuto cambia davvero.
- Rendi il server veloce e prevedibile. Riduci il tempo di risposta e supporta il codice 304 Not Modified, così Google riusa la copia già scansionata.
- Alleggerisci il rendering. Meno risorse da caricare per pagina, contenuti e link principali già nell’HTML.
- Porta entro pochi clic dalla home ogni pagina che deve essere scansionata, con link interni da pagine già visitate spesso.
Miti da lasciar perdere
Dalla documentazione di Google sulla scansione:
- “Il noindex fa risparmiare budget.” Solo in parte. Google deve scaricare la pagina per leggere il noindex, quindi quella richiesta è già spesa. Nel lungo periodo, togliere pagine dall’indice può liberare un po’ di budget in modo indiretto. Se l’obiettivo è non farle scansionare, lo strumento giusto è robots.txt.
- “Blocco pagine in robots.txt per spostare budget altrove.” Google non riassegna le richieste liberate ad altre pagine, a meno che il sito non stia già toccando il limite di capacità.
- “Con crawl-delay controllo Googlebot.” Google ignora questa regola.
- “Le pagine 4xx sprecano budget.” No: Google tenta la scansione e riceve solo un codice di stato, senza contenuto. Fa eccezione il 429, che segnala una limitazione di frequenza e fa scendere il limite di capacità.
- “Comprimere la sitemap aumenta il budget.” No, il file va comunque scaricato.
- “Ritoccare le pagine e cambiare la data le fa riscansionare di più.” Google valuta la qualità, non l’età. Le modifiche finte non aggiungono valore.
- “Più scansione significa posizioni migliori.” La scansione è necessaria per comparire, ma non è un fattore di ranking.
Come verificare se funziona
Il risultato di un buon intervento è una redistribuzione, non un aumento: le richieste si concentrano sulle pagine che contano. Per vederlo servono tre fonti.
Statistiche di scansione in Search Console
Si trovano in Impostazioni > Statistiche di scansione e sono disponibili solo per le proprietà Dominio o a livello di directory principale. Google indica il report Statistiche di scansione come utile soprattutto per siti sopra le mille pagine. Cosa guardare:
- Richieste di scansione totali: la curva conta più del numero. Un calo improvviso di solito ha una causa precisa: una nuova regola in robots.txt, un server più lento, più errori.
- Tempo medio di risposta: se sale, il limite di capacità scende.
- Stato host: deve essere verde. Se non lo è, il dettaglio indica se il problema è il recupero di robots.txt, la risoluzione DNS o la connettività del server.
- Risposte alle scansioni: la maggior parte dovrebbe essere 200. Molti 3xx indicano catene di redirect, molti 5xx problemi del server.
- Scopo della scansione: “Rilevamento” sono URL mai visti, “Aggiornamento” sono riletture. Se pubblichi pagine nuove e il rilevamento resta piatto, Google non le sta trovando.
- Tipo Googlebot: un picco di “Carico di risorse della pagina” segnala pagine pesanti da visualizzare.
Log del server
Sono l’unica fonte che mostra ogni richiesta, URL per URL. Il metodo:
- Isola le richieste che si dichiarano Googlebot.
- Verifica che siano vere. Lo user agent si può falsificare. Google indica due metodi nella guida su come verificare le richieste dei crawler: la ricerca DNS inversa dell’IP, che deve risolvere su googlebot.com per i crawler comuni o google.com per quelli speciali, e tornare allo stesso IP con la ricerca diretta; oppure il confronto con gli elenchi di IP pubblicati da Google.
- Raggruppa per sezione o tipo di pagina: categorie, prodotti, filtri, articoli, pagine di servizio.
- Misura quattro cose: la quota di richieste non 200, la quota di richieste su URL che vuoi indicizzati, le pagine importanti mai visitate nel periodo, la frequenza di visita delle pagine chiave.
- Confronta prima e dopo l’intervento, sullo stesso numero di settimane.
Report Indicizzazione delle pagine
Controlla se gli URL “Rilevata, ma attualmente non indicizzata” diminuiscono. È il segnale più diretto che il budget sta arrivando dove serve.
Migrazioni e siti multilingua
Una migrazione aumenta la domanda di scansione, perché Google deve rileggere il sito sui nuovi indirizzi. È il momento in cui catene di redirect e vecchi URL in sitemap costano di più: meglio che ogni vecchio URL punti direttamente alla destinazione finale.
Nei siti multilingua ogni versione linguistica è un URL da scansionare, e le versioni collegate con hreflang consumano budget come tutte le altre. Se una lingua è su un sottodominio, ha anche un budget separato.
Crawl budget e motori di risposta AI
Una pagina che non viene letta non può essere citata. Vale per Google, dove AI Overviews e AI Mode attingono allo stesso indice alimentato da Googlebot. E vale per gli assistenti AI che recuperano pagine web in tempo reale con crawler propri.
Due conseguenze pratiche:
- Le correzioni che liberano budget per Googlebot valgono anche per gli altri crawler. Meno varianti, meno redirect e contenuti già presenti nell’HTML rendono il sito più leggibile per tutti. Molti crawler AI non eseguono JavaScript, quindi un contenuto che compare solo dopo il rendering per loro può non esistere.
- Anche i crawler AI consumano risorse del server. Vanno osservati nei log e gestiti per user agent nel robots.txt, bloccando solo ciò che non deve essere letto.
La scansione è la precondizione di ogni forma di visibilità organica, non solo del posizionamento classico.
Domande frequenti
Cos’è il crawl budget in parole semplici?
È il numero di URL che Google è disposto a richiedere sul tuo sito in un certo periodo: pagine, ma anche risorse come CSS e JavaScript. Dipende da quanto il server regge (limite di capacità di scansione) e da quanto Google ritiene utile tornare sulle pagine (domanda di scansione).
Il crawl budget si può aumentare?
Non direttamente: non si può chiedere a Google di scansionare di più. Secondo Google le leve sono due: più risorse server, se il sito raggiunge il limite di capacità, e contenuti di qualità, unici e utili. Il resto del guadagno arriva dallo smettere di spendere richieste su indirizzi che non servono a nessuno.
Il crawl budget conta anche per un sito piccolo?
Raramente. Se le pagine nuove vengono scansionate lo stesso giorno o nei giorni successivi alla pubblicazione, basta tenere aggiornata la sitemap e controllare il report Indicizzazione delle pagine.
Il noindex fa risparmiare crawl budget?
Non nell’immediato. Google deve scaricare la pagina per leggere il noindex, quindi la richiesta è già consumata. Nel lungo periodo, togliere pagine dall’indice può liberare un po’ di budget in modo indiretto. Per non far scansionare una pagina lo strumento è robots.txt. L’URL canonico serve a consolidare i duplicati e col tempo riduce la scansione delle varianti, ma non la impedisce.
Il crawl budget è un fattore di ranking?
No. La scansione è necessaria perché una pagina compaia nei risultati, ma aumentarla non porta da sola posizioni migliori.
Quanto ci vuole perché si veda un effetto?
Non esiste un tempo ufficiale. Google indica che la frequenza di scansione è in genere relativamente stabile nell’arco di una o due settimane: è su finestre di quella durata che ha senso confrontare le Statistiche di scansione prima e dopo l’intervento. Su un sito grande la redistribuzione completa richiede di più, perché Google riscopre la struttura per gradi.
Vale anche per i motori di risposta AI?
Sì, per lo stesso motivo: una pagina che non viene letta non può essere citata. In più, molti crawler AI non eseguono JavaScript, quindi i contenuti presenti già nell’HTML sono più facili da leggere e citare.