Il crawl budget è il numero di URL che Google può e vuole scansionare sul tuo sito. Non è però un “credito giornaliero” fisso e non è un problema che ogni sito deve ottimizzare.
Google oggi lo descrive come l’incontro tra due elementi: la crawl capacity, cioè quanto Google può scansionare senza sovraccaricare il server, e la crawl demand, cioè quanto Google ritiene utile tornare a scansionare gli URL conosciuti.
Su un sito di 50 o 200 pagine, nella maggior parte dei casi non hai un problema di crawl budget. Su un e-commerce con centinaia di migliaia di combinazioni di filtri, un marketplace, un publisher o un sito che genera URL dinamici, invece, Googlebot può spendere molto tempo su URL inutili mentre nuove pagine importanti vengono scoperte più lentamente.
In questa guida vediamo quando il crawl budget SEO conta davvero, come individuare sprechi e quali interventi hanno senso. Se stai già vedendo migliaia di URL indesiderati in Search Console, puoi partire anche da un audit SEO tecnico.
Cos’è il crawl budget?
In termini pratici, il crawl budget rappresenta il perimetro di URL che Googlebot riesce e desidera scansionare in un certo periodo.
Google non può visitare continuamente ogni URL del web. Per ogni hostname deve quindi decidere quanto può caricare il server e quali URL meritano una nuova scansione.
Crawl capacity e crawl demand: due vincoli, non una somma
Il crawl budget riguarda le URL che Google può e vuole scansionare: capacità e domanda agiscono insieme, non si sommano come due quantità di pagine.
Questa distinzione è importante. Aumentare la capacità del server non obbliga Google a scansionare più pagine se la domanda di crawl è bassa. Allo stesso modo, avere molte pagine importanti non aiuta se il server rallenta, restituisce 5xx o limita le richieste.
Crawling e indexing non sono la stessa cosa
Crawlare una pagina non significa indicizzarla. Googlebot può visitare un URL, elaborarlo e poi decidere che non deve entrare nell’indice oppure consolidarlo con un’altra pagina.
Per questo un aumento delle richieste di Googlebot non è automaticamente positivo. Se il crawl aumenta perché Google sta esplorando milioni di filtri inutili, stai consumando risorse senza aumentare le pagine utili in Search.
Crawl capacity: quanto Google può scansionare
La crawl capacity dipende dalla capacità del sito di rispondere alle richieste senza degradare il servizio. Google considera il numero di connessioni, la loro durata, latenza, Time to First Byte e segnali di errore.
Cosa può ridurre la capacità
- Risposte server lente.
- Picchi di latenza.
- Errori HTTP 5xx.
- HTTP 429 e rate limiting.
- Problemi di disponibilità dell’host.
- Rendering costoso o pagine molto pesanti.
Se Googlebot vede che il server fatica, riduce automaticamente la pressione di crawl. Se il sito rimane stabile e c’è domanda, la capacità può aumentare nel tempo.
Crawl demand: quanto Google vuole scansionare
La crawl demand riguarda la priorità che Google assegna agli URL. Per Googlebot, tra i fattori dichiarati ci sono dimensione del sito, frequenza di aggiornamento, qualità e rilevanza delle pagine rispetto ad altri siti.
I fattori su cui puoi incidere maggiormente
- Inventario percepito: quanti URL Google conosce sul sito.
- Duplicazioni: quante varianti portano allo stesso contenuto.
- Freschezza: quanto spesso le pagine cambiano davvero.
- Qualità e utilità delle pagine.
- Collegamenti interni che segnalano le priorità.
- Sitemap che indicano gli URL che vuoi far scansionare.
Google indica l’inventario di URL come una delle leve che puoi controllare meglio. Se il crawler deve attraversare centinaia di migliaia di URL duplicati o inutili, la scoperta delle pagine importanti può diventare meno efficiente.
Crawl rate Google: esiste ancora?
Il termine “crawl rate” è ancora usato comunemente nella SEO, ma la documentazione attuale parla soprattutto di crawl capacity limit e hostload.
Non esiste una frequenza di scansione che dovresti cercare di massimizzare a tutti i costi. L’obiettivo è far sì che Googlebot riesca a raggiungere le pagine utili con una frequenza coerente con il loro valore e aggiornamento.
Non devi ottimizzare il crawl budget su ogni sito
Questa è probabilmente la sezione più importante della guida. Se hai un sito piccolo, non iniziare a modificare robots.txt o canonical solo perché hai letto che devi “risparmiare crawl budget”.
Google definisce la propria guida avanzata soprattutto per siti molto grandi o che cambiano rapidamente. Come riferimento indicativo, cita:
- Siti con circa 1 milione o più di pagine uniche che cambiano con moderata frequenza.
- Siti da circa 10.000 pagine in su con contenuti che cambiano quotidianamente.
- Siti con una grande quota di URL classificati come “Discovered – currently not indexed”.
Google precisa che queste non sono soglie rigide. Ma il messaggio è chiaro: se pubblichi 20 articoli al mese e le nuove pagine vengono scansionate senza problemi, probabilmente non hai bisogno di un progetto di crawl-budget optimization.
Quando invece dovresti indagare
- Le pagine nuove o aggiornate vengono scoperte molto lentamente.
- Search Console mostra molti URL “Discovered – currently not indexed”.
- Googlebot visita in massa filtri, ricerche interne o parametri inutili.
- Il server riceve un volume significativo di richieste crawler.
- Hai centinaia di migliaia o milioni di URL potenziali.
- Una migrazione o un cambio di architettura ha moltiplicato gli URL.
Dove il crawl budget conta davvero
Grandi e-commerce
Su piattaforme come Shopify, app, filtri, collezioni e parametri possono ampliare rapidamente l’inventario. Per progetti di questo tipo, una verifica SEO Shopify dovrebbe controllare anche quali URL il tema e le app rendono scansionabili.
Gli e-commerce possono generare molte più URL delle pagine prodotto realmente vendibili. Filtri per colore, taglia, prezzo, ordinamento, brand, disponibilità e parametri di tracking possono trasformare 100.000 prodotti in milioni di URL scansionabili.
Marketplace
Un marketplace aggiunge utenti, categorie, combinazioni geografiche, listing scaduti, pagine di ricerca, filtri e parametri. Il problema principale è spesso controllare l’inventario, non “convincere Google a fare più crawl”.
Publisher e siti editoriali
News, annunci e grandi archivi editoriali producono molte pagine e aggiornamenti. Qui la freschezza può diventare importante e una sitemap pulita, un’architettura chiara e tempi server stabili aiutano Google a individuare rapidamente i contenuti nuovi.
Esempio: 100.000 prodotti, ma 670.000 URL aggiuntivi
| Inventario | URL |
| Prodotti indicizzabili | 100.000 |
| URL filtrati | +350.000 |
| URL con tracking | +100.000 |
| Ricerca interna | +80.000 |
| Redirect | +40.000 |
| URL totali potenzialmente scoperti | 670.000+ |
Il problema non è che Google “ha solo 100.000 crawl disponibili”. Il problema è che il suo inventario percepito è molto più grande dell’inventario utile.
Googlebot deve scoprire, richiedere e classificare molte varianti prima di capire quali URL hanno valore. Nel frattempo categorie nuove, prodotti importanti o modifiche di stock possono ricevere meno attenzione di quanto vorresti.
Navigazione a faccette: una delle cause principali
La faceted navigation è utile agli utenti, ma può diventare una macchina per generare URL.
Esempio: una categoria scarpe può avere filtri per brand, colore, misura, prezzo, materiale e disponibilità. Ogni combinazione può creare un URL diverso. Con pochi filtri, le combinazioni crescono rapidamente.
Devi decidere quali faccette meritano l’indice
- Filtri con domanda di ricerca reale possono diventare landing page curate.
- Combinazioni senza domanda possono rimanere utili per l’utente ma non per Google.
- Ordinamenti e parametri puramente funzionali raramente meritano indicizzazione.
- La strategia deve essere coerente tra link, canonical, robots.txt e sitemap.
URL con parametri
Tracking, session ID, ordinamenti, filtri e parametri applicativi possono creare URL diversi che mostrano contenuto identico o quasi identico.
Esempi tipici
- ?utm_source=newsletter
- ?sort=price-asc
- ?color=black&size=42
- ?sessionid=…
- ?ref=partner123
Prima di bloccare pattern interi, mappa quali parametri cambiano davvero il contenuto e quali sono solo varianti tecniche. Una regola robots.txt troppo ampia può bloccare pagine che volevi mantenere scansionabili.
URL duplicati
La duplicazione non è soltanto un problema di contenuto. Aumenta anche il numero di URL che Google deve esplorare e consolidare.
Google tende a scansionare più spesso la versione canonical e meno frequentemente i duplicati, ma se continui a generare e linkare nuove varianti, il crawler deve comunque scoprirle e interpretarle.
Calendari infiniti
Un calendario dinamico senza una data massima può creare link verso anni futuri praticamente senza fine.
Google raccomanda di evitare questi spazi infiniti e, quando necessario, impedire al crawler di seguire collegamenti verso date future generate dinamicamente.
URL di ricerca interna
Le ricerche interne possono produrre migliaia di combinazioni con poco valore per Google. Se ogni query genera un URL linkabile, il crawler può trovare una quantità enorme di risultati quasi duplicati.
In molti casi queste URL dovrebbero essere escluse dal crawl o comunque non alimentate attraverso la navigazione interna. Prima di applicare una regola globale, verifica però se alcune pagine di ricerca sono state trasformate intenzionalmente in landing page.
Crawl trap: come riconoscerle
Una crawl trap è un meccanismo che crea uno spazio di URL molto più grande del contenuto utile reale.
- Calendari senza limite.
- Filtri combinabili senza controllo.
- Parametri che possono essere aggiunti ripetutamente.
- Paginazioni praticamente infinite.
- Link relativi errati che generano nuovi percorsi.
- ID di sessione negli URL.
- Ricerca interna indicizzabile e linkata.
Un crawler SEO può aiutarti a riprodurre parte del problema, ma i log server sono spesso decisivi per capire cosa Googlebot sta visitando davvero.
Redirect e catene di redirect
I redirect sono normali, soprattutto dopo migrazioni. Il problema è quando Googlebot deve attraversare lunghe catene o continua a ricevere link verso URL vecchi.
Cosa fare
- Aggiorna i link interni verso la destinazione finale.
- Evita catene A → B → C → D.
- Rimuovi vecchi URL dalle sitemap.
- Controlla che canonical e hreflang puntino alle destinazioni finali.
- Mantieni i redirect necessari, ma elimina quelli creati solo da configurazioni obsolete.
Prestazioni del server
Un server più veloce non garantisce automaticamente più crawl. Ma un server lento o instabile può ridurre la crawl capacity.
Controlla tempo di risposta, picchi di latenza, saturazione delle risorse e differenze tra utenti normali e crawler. Se Search Console mostra problemi di hostload, aumentare capacità o ottimizzare le risposte può permettere a Googlebot di lavorare con meno limitazioni.
Errori 5xx e HTTP 429
Errori 5xx indicano che il server non riesce a servire correttamente la richiesta. HTTP 429 comunica invece che il client sta inviando troppe richieste.
Se Googlebot incontra frequentemente questi segnali, può ridurre la propria attività per non sovraccaricare il sito. Per un grande sito, un aumento di 5xx non è soltanto un problema UX: può rendere meno efficiente la scoperta e l’aggiornamento delle pagine.
URL eliminati: usa status code corretti
Se una pagina è stata rimossa definitivamente e non esiste un sostituto pertinente, un 404 o 410 è un segnale chiaro.
Tenere URL eliminati dietro soft 404, pagine vuote o redirect senza senso mantiene rumore nell’inventario. Google indica esplicitamente i soft 404 come una fonte di crawl sprecato.
Sitemap XML pulita
Se la sitemap contiene URL incoerenti, un controllo della sitemap XML dovrebbe confrontarla con status code, canonical, indicizzabilità e link interni.
La sitemap non aumenta magicamente il crawl budget. Serve a comunicare quali URL vuoi che Google scopra e tenga aggiornati.
Una sitemap utile dovrebbe contenere
- URL canonical.
- URL con status 200.
- Pagine indicizzabili.
- Contenuti importanti per utenti e business.
- lastmod affidabile quando la pagina è cambiata davvero.
Evita sitemap piene di redirect, 404, noindex, filtri o duplicati. Su grandi siti, segmentare le sitemap per tipologia può anche rendere più semplice il monitoraggio.
Internal linking: indica cosa conta
I link interni aiutano Google a scoprire gli URL e a capire quali pagine sono integrate nell’architettura del sito.
Una pagina prodotto nuova che appare solo nella sitemap ma non riceve link da categorie, pagine correlate o navigazione ha segnali di scoperta diversi da una pagina ben integrata nel sito.
Controlla soprattutto
- Pagine orfane.
- Pagine importanti troppo profonde.
- Link verso redirect.
- Link generati da filtri che moltiplicano URL inutili.
- Anchor e contesto dei link verso nuove categorie o prodotti.
Canonical: riduce duplicazioni, ma non è un blocco di crawl
Una verifica dei canonical deve controllare il segnale insieme a redirect, sitemap e internal linking, non isolatamente.
Il canonical aiuta Google a consolidare URL duplicati o molto simili. Nel tempo, le varianti non canoniche possono essere scansionate meno spesso.
Ma canonical non significa “non scansionare questo URL”. Google deve comunque poter vedere molti di questi URL per rilevare e valutare il segnale canonical.
Se hai milioni di faccette inutili, affidarti solo al canonical può essere troppo lento. Devi prima decidere se quelle URL devono essere scansionate, indicizzate o eliminate dall’inventario.
Robots.txt: utile, ma facile da usare male
Prima di bloccare pattern di URL su larga scala, un controllo robots.txt può evitare regole troppo ampie che rendono invisibili sezioni utili al crawler.
robots.txt può impedire a Googlebot di richiedere intere classi di URL inutili, come ricerche interne o alcune combinazioni di filtri.
Ma non usarlo per “liberare crawl budget” a caso. Google chiarisce che bloccare una sezione non significa che il budget liberato verrà automaticamente spostato su altre pagine, a meno che il sito non stia già raggiungendo il limite di capacità.
Un’altra trappola: noindex per risparmiare crawl
Se Google deve leggere il meta noindex, prima deve comunque richiedere la pagina. Per URL che non vuoi vengano scansionati affatto, noindex non è uno strumento di crawl-budget optimization.
Prima di modificare robots.txt su larga scala, tratta la decisione come una modifica tecnica ad alto rischio e testala su pattern precisi.
JavaScript e CSS consumano attività di crawl
Il crawling moderno non riguarda solo documenti HTML. Google può richiedere risorse necessarie al rendering, inclusi JavaScript e CSS.
Googlebot mette le pagine in coda sia per il crawling sia per il rendering. Se blocchi risorse necessarie, Google può non vedere correttamente il contenuto; se generi molte risorse instabili o URL sempre diversi, aumenti il lavoro necessario.
Cosa controllare
- JS e CSS essenziali accessibili a Google.
- URL delle risorse stabili.
- Bundle e API che non generano errori crawler-specific.
- Rendering di contenuti e link importanti.
- Risorse ospitate su hostname diversi, che hanno budget e statistiche separati.
Log-file analysis: cosa sta facendo davvero Googlebot?
Search Console mostra una vista aggregata del crawling. I log server ti permettono di scendere al livello del singolo URL e ricostruire quali pattern Googlebot richiede realmente.
Domande a cui i log possono rispondere
- Quali directory ricevono più richieste?
- Googlebot visita filtri o parametri che non dovrebbero contare?
- Quanto spesso vengono scansionate le pagine commerciali prioritarie?
- Quali status code vede Googlebot?
- Ci sono picchi di 5xx o 429 durante il crawl?
- Quali nuove pagine non risultano ancora richieste?
- Quanto crawl finisce su redirect e URL non canonici?
Su siti grandi, la log analysis è spesso il modo più concreto per trasformare un problema generico di “crawl budget” in una lista di pattern misurabili.
Search Console Crawl Stats: cosa guardare
Il report Crawl Stats mostra lo storico delle richieste di Google, le risposte del server, i problemi di disponibilità e la distribuzione del crawl.
Controlli utili
- Totale richieste di crawl e trend.
- Dimensione totale dei download.
- Tempo medio di risposta.
- Distribuzione per status code.
- Richieste per tipo di file.
- Scopo del crawl: discovery vs refresh quando disponibile.
- Tipo di Googlebot.
- Problemi di host availability.
Google considera questo report avanzato e indica che siti con meno di circa mille pagine normalmente non devono preoccuparsi di questo livello di dettaglio.
Come identificare il crawl sprecato
Il modo più utile è confrontare tre insiemi di URL:
- URL che vuoi indicizzare.
- URL che Google conosce o scansiona.
- URL che generano traffico, conversioni o hanno un ruolo reale nell’architettura.
La differenza tra questi insiemi evidenzia gli sprechi.
Metriche pratiche da costruire
- % richieste Googlebot su URL 200 canonical.
- % richieste su redirect.
- % richieste su 4xx/5xx.
- % richieste su parametri e filtri non indicizzabili.
- % pagine prioritarie scansionate negli ultimi 7/30 giorni.
- Tempo medio tra pubblicazione e prima richiesta Googlebot.
- Numero di URL unici richiesti rispetto all’inventario indexable.
Leggere insieme copertura e frequenza di scansione
Esempio ipotetico: in una settimana i log registrano 20.000 richieste Googlebot HTML, ma soltanto 300 delle 1.000 pagine prioritarie hanno ricevuto almeno una visita. La copertura del gruppo è 30%, non 20.000 scansioni utili. Se poche pagine assorbono molte richieste, il totale può crescere senza migliorare la scoperta del catalogo.
Separa HTML e risorse, controlla che i log includano le risposte servite dalla CDN e documenta come hai verificato il bot. Confronta lo stesso inventario prima e dopo il rilascio; nuove pagine aggiunte nel frattempo cambiano il denominatore. Usa la guida Google al crawl budget per valutare se il problema è capacità, domanda o inventario, senza trattare più crawling come prova di migliori ranking.
Checklist pratica per un audit del crawl budget
| Controllo | Domanda | Problema tipico |
| Crawl Stats | Google sta aumentando o riducendo il crawl? Ci sono problemi host? | 5xx, 429, tempi risposta |
| XML sitemap | Contiene solo URL canonical e indicizzabili? | Redirect, 404, filtri |
| Server logs | Dove Googlebot spende davvero le richieste? | Parametri, search, duplicati |
| Response codes | Quanta parte del crawl finisce su status non utili? | 3xx, 4xx, 5xx |
| Parameter inventory | Quali parametri generano nuovi URL? | Tracking, sort, filtri |
| Canonical consistency | Link, sitemap e canonical indicano la stessa versione? | Varianti duplicate |
| Internal links | Le pagine prioritarie sono raggiungibili e ben collegate? | Orfane, profondità |
| Orphan pages | Esistono URL utili presenti solo in sitemap? | Scoperta lenta |
| Duplicate URLs | Quante varianti mostrano lo stesso contenuto? | Faceted nav, session ID |
Questi controlli sono anche presenti, a livello sintetico, nella checklist SEO tecnica. Questa pagina serve invece come approfondimento specifico sul crawling.
Miti comuni sul crawl budget
Mito 1: ogni sito deve ottimizzare il crawl budget
No. Per la maggior parte dei siti piccoli basta mantenere sitemap, indicizzazione e struttura pulite.
Mito 2: più crawl = più ranking
No. Crawling e ranking sono processi diversi. Google può scansionare molto un sito senza aumentare la visibilità.
Mito 3: bloccare 10.000 URL trasferisce automaticamente 10.000 crawl alle pagine importanti
No. Google non rialloca automaticamente la capacità se il sito non stava già raggiungendo il limite.
Mito 4: noindex fa risparmiare crawl budget
Non direttamente. Google deve richiedere l’URL per leggere il noindex.
Mito 5: canonical impedisce il crawl
No. È un segnale di consolidamento, non una direttiva di blocco.
Mito 6: aumentare il server significa ottenere più crawl
Solo se la capacità era il collo di bottiglia e c’è sufficiente crawl demand.
Mito 7: una sitemap perfetta risolve i crawl trap
No. La sitemap comunica URL importanti, ma Google può continuare a scoprire URL problematici attraverso i link.
Crawl budget e motori AI: cambia qualcosa?
Per Google, le stesse basi di crawling rimangono importanti anche per le funzionalità generative di Search. Google raccomanda esplicitamente ai siti molto grandi e frequentemente aggiornati di applicare le pratiche di crawl-budget optimization.
Questo non crea un “AI crawl budget” separato da ottimizzare. Prima assicurati che le pagine utili siano accessibili, scansionabili e ben integrate nel sito.
Quando serve un’analisi professionale
Se hai poche centinaia di URL e Google scopre le pagine nuove normalmente, probabilmente non ti serve una consulenza specifica sul crawl budget.
Un’analisi specialistica diventa più utile quando:
- Hai migliaia o milioni di URL.
- Filtri e parametri moltiplicano l’inventario.
- Le nuove pagine importanti vengono scoperte lentamente.
- Search Console mostra molti URL discovered ma non scansionati.
- I log evidenziano molto crawl su URL inutili.
- Googlebot incontra 5xx, 429 o problemi di hostload.
- Stai preparando una migrazione di un sito grande.
- Non sai se bloccare filtri, canonicalizzarli o renderli landing page.
Se gestisci un sito con migliaia di URL, filtri o contenuti dinamici, un’analisi dei log e del crawling può mostrare dove Googlebot sta spendendo risorse inutilmente.
