Il crawl budget è la quantità di risorse e il numero di URL che Google dedica alla scansione di un sito in un determinato periodo. Riguarda chiunque gestisca un sito web, ma diventa critico per e-commerce e portali con migliaia di pagine. Si misura in Google Search Console e si ottimizza riducendo gli sprechi su pagine inutili, gestendo robots.txt, sitemap e contenuti duplicati. Nel 2026 è una variabile, importantissima, riguarda anche i crawler degli LLM, che seguono logiche simili a Googlebot.

Cos’è il crawl budget?

Il crawl budget, o budget di scansione, è il numero di URL che Googlebot può e vuole scansionare su un determinato sito in un dato arco di tempo. La definizione ufficiale di Google, pubblicata già nel 2017 da Gary Illyes, usa deliberatamente due verbi distinti: can (può, legato alla capacità del server) e wants (vuole, legato all’interesse percepito per il contenuto). Questa distinzione è il cuore del problema: non basta avere un server veloce se i contenuti non valgono l’attenzione del crawler, e viceversa. Come per la SEO in generale, il crawl budget è il risultato dinamico di più fattori che interagiscono tra loro.

Il web è uno spazio praticamente infinito. Google non può scansionare tutto, quindi assegna a ogni sito un “budget” di attenzione. Questo budget si definisce tecnicamente attraverso due componenti:

• crawl rate limit: il numero massimo di connessioni simultanee che Googlebot può usare senza sovraccaricare il server del sito. Se il sito risponde in meno di 200ms, il limite sale; se risponde lentamente o restituisce errori di server, il limite scende
• crawl demand: la “domanda” di scansione, determinata dalla popolarità del sito, dalla frequenza di aggiornamento dei contenuti e dalla qualità percepita delle pagine. Un blog di notizie viene scansionato più spesso di un sito statico sulla storia del kimono

A cosa serve il crawl budget?

Il crawl budget serve a garantire che Google trovi, scansioni e indicizzi le pagine più importanti del sito, evitando che il crawler sprechi tempo su URL inutili o di bassa qualità.

Per i siti piccoli, con poche centinaia di pagine che cambiano raramente, il crawl budget non rappresenta problema reale. Google riesce a coprire tutto senza difficoltà. Il discorso cambia radicalmente per:

• e-commerce con migliaia di schede prodotto, filtri di navigazione e varianti URL
• portali editoriali con archivi storici profondi e contenuti che si aggiornano quotidianamente
• siti con generazione dinamica di URL da parametri (ordinamento, sessioni, tracking)

In questi casi, se Googlebot spreca il suo budget scansionando URL duplicati, pagine filtrate o sezioni irrilevanti, le pagine nuove o strategicamente importanti rischiano di non essere indicizzate in tempi ragionevoli. Il risultato è visibile in Google Search Console sotto la voce “rilevata ma attualmente non indicizzata”: pagine che Google ha trovato ma ha scelto di non inserire nell’indice perché non aveva risorse o interesse sufficiente per farlo.

È importante chiarire una distinzione: scansione e indicizzazione non sono la stessa cosa. Google può scansionare una pagina senza indicizzarla (se la ritiene di bassa qualità), e può conoscere l’esistenza di una pagina senza averla mai scansionata (se l’ha scoperta tramite link ma non ha ancora risorse per visitarla). Il crawl budget riguarda la prima fase del processo, ma influenza direttamente anche la seconda.

Perché è importante il crawl budget?

Il crawl budget è importante perché determina quali pagine Google riesce a scansionare e con quale frequenza: un budget sprecato su URL irrilevanti significa pagine strategiche indicizzate in ritardo o non indicizzate affatto.

Non si tratta di un fattore di ranking diretto, ma ha un’incidenza concreta sulla visibilità organica. Ecco i principali impatti:

• indicizzazione ritardata: le nuove pagine rimangono invisibili più a lungo se il crawler è impegnato su URL senza valore
• aggiornamenti non recepiti: se Google non rileva le modifiche ai contenuti, le pagine rimangono posizionate sulla versione precedente, anche se ormai obsoleta
• copertura incompleta: su siti grandi, alcune sezioni potrebbero non essere mai scansionate, restando fuori dall’indice a tempo indeterminato

Google stessa chiarisce nella documentazione ufficiale che il crawl budget non dovrebbe preoccupare tutti gli utenti che gestiscono, a diverso titolo, un sito web. Chi gestisce un blog con qualche centinaio di articoli, dove le nuove pagine vengono indicizzate lo stesso giorno della pubblicazione, può tranquillamente ignorare questo aspetto. Chi gestisce un e-commerce con centomila prodotti o un portale con filtri e parametri URL che moltiplicano gli URL, no.

In che modo ottimizzare il crawl budget?

Ottimizzare il crawl budget significa ridurre gli sprechi su URL a basso valore e migliorare la velocità di risposta del server, così che Googlebot possa dedicare più risorse alle pagine che contano.

Gestire il file robots.txt

Il file robots.txt è il primo strumento per controllare cosa Googlebot scansiona. Bloccare sezioni inutili libera budget per le pagine strategiche. Le categorie di URL da bloccare più comunemente sono:

• pagine di ricerca interna del sito
• URL con parametri di sessione, tracking UTM o ordinamento dei risultati
• pagine di checkout, carrello e area utente riservata
• paginazione profonda, dalla quinta pagina in poi sugli archivi

Attenzione a un punto tecnico importante: bloccare una pagina con robots.txt impedisce la scansione, ma non la rimozione dall’indice se la pagina è già stata indicizzata in passato. Per rimuovere pagine dall’indice serve il tag noindex (che però richiede che la pagina sia scansionabile per essere letto). I due strumenti hanno funzioni distinte e vanno usati in modo coordinato.

Eliminare i contenuti duplicati

I contenuti duplicati sono tra i principali responsabili dello spreco di crawl budget: Google scansiona URL diversi che mostrano lo stesso contenuto, consumando risorse senza ottenere informazioni nuove.

Il tag canonical indica a Googlebot quale URL preferire tra versioni duplicate o quasi-duplicate. Va implementato su tutte le pagine, incluse le varianti con parametri, ad esempio su pagine con filtri attivi che mostrano lo stesso catalogo in ordine diverso). La sitemap XML deve includere solo URL canonici, indicizzabili e che rispondono con codice 200.

Gestire le sitemap XML

Una sitemap XML aggiornata non aumenta il crawl budget, ma migliora la qualità della distribuzione delle risorse di scansione, guidando Googlebot verso le pagine prioritarie.

Le regole pratiche sono:

• includere solo URL canonici con risposta HTTP 200
• aggiornare il campo lastmod (ultima modifica) solo quando il contenuto principale cambia davvero, non come aggiornamento di facciata
• escludere pagine con redirect, noindex o errori 404
• per siti grandi, segmentare per tipo di contenuto (prodotti, categorie, articoli) e raccogliere in un sitemap index.

Velocizzare il server

La velocità del server è il fattore che più direttamente produce conseguenze sul crawl rate limit. Un server con TTFB (Time To First Byte) inferiore a 200ms riceve significativamente più richieste giornaliere da Googlebot rispetto a uno con tempi superiori al secondo.

Gli interventi più efficaci sono: cache lato server (per servire pagine già generate senza ricalcolarle), CDN per distribuire il carico, ottimizzazione delle query del database. Non è necessario un’infrastruttura enterprise: anche per siti WordPress di medie dimensioni, attivare la cache delle pagine riduce il TTFB in modo misurabile.

Correggere gli errori tecnici

Alcune tipologie di errori consumano crawl budget senza produrre nulla di utile:

• errori 5xx (errori del server): riducono automaticamente il crawl rate, anche dopo la risoluzione del problema. Il recupero può richiedere giorni
• soft 404: pagine che restituiscono HTTP 200 ma mostrano un messaggio del tipo “prodotto non trovato”. Google le scansiona ripetutamente perché non riesce a capire che sono vuote
• catene di redirect: ogni hop è una richiesta separata. Una catena A → B → C consuma il triplo del budget di una singola richiesta diretta
• pagine orfane: URL presenti in sitemap ma senza link interni. Google li trova ma li considera di scarsa rilevanza, dedicando loro meno attenzione

Esempi concreti di crawl budget sprecato e ottimizzato

Nella pratica, gli sprechi di crawl budget seguono sempre gli stessi schemi. Conoscerli permette di intervenire con precisione invece di ottimizzare alla cieca.

Di seguito una tabella con i casi più frequenti, l’impatto sul budget di scansione e l’azione correttiva raccomandata.

Problema	Impatto sul crawl budget	Soluzione
Navigazione faceted (filtri colore, taglia, prezzo)	Genera milioni di URL quasi identici che Google scansiona individualmente.	Bloccare via robots.txt i parametri combinati; canonical verso la pagina base.
Parametri di sessione e tracking negli URL	URL diversi per lo stesso contenuto, moltiplicano le richieste inutilmente.	Bloccare via robots.txt; rimuovere parametri dal lato server per Googlebot.
Pagine out-of-stock con risposta 200	Google le riscansiona indefinitamente pensando che il contenuto possa cambiare.	Restituire 404 o 410 se il prodotto è rimosso; noindex se temporaneamente assente.
Archivi storici profondi su blog editoriali	Pagine di archivio dalla decima pagina in poi consumano budget senza traffico.	Noindex sulle pagine di archivio profonde; ridurre il numero di pagine aumentando gli articoli per pagina.
Redirect chain A → B → C → D	Ogni hop è una richiesta separata. Googlebot può abbandonare la catena.	Consolidare tutti i redirect in un unico salto diretto verso la destinazione finale.
Staging o versioni di test accessibili a Googlebot	Google scansiona contenuti duplicati del sito principale.	Bloccare con robots.txt e/o protezione con autenticazione HTTP.

Un esempio reale: un e-commerce di moda con 15.000 prodotti e filtri per colore, taglia e materiale può generare oltre 2 milioni di URL combinati. Se non vengono gestiti, Googlebot può impiegare settimane a scansionare quelle combinazioni, nel frattempo le nuove schede prodotto restano non indicizzate. La soluzione non è eliminare i filtri, ma decidere quali combinazioni hanno valore SEO reale (es. “scarpe da donna rosse” ha ricerche, “scarpe filtrate per rosso XS in saldo” no) e trattare le due categorie in modo diverso.

Crawl budget e AI

Il crawl budget non riguarda più solo Googlebot: nel 2026 i siti vengono scansionati anche da crawler specifici degli LLM, che seguono logiche diverse ma ugualmente rilevanti per chi produce contenuti.

Modelli come quelli alla base di ChatGPT Search, Perplexity e Google AI Overview usano crawler propri (GPTBot per OpenAI, ClaudeBot per Anthropic, Google-Extended per il training dei modelli Google) per raccogliere contenuti dal web. Questi bot non hanno un crawl budget nel senso tecnico di Google, ma operano con logiche di prioritizzazione simili: visitano più frequentemente i siti con contenuti aggiornati, strutturati e facilmente leggibili, e tendono a ignorare quelli con molte pagine di scarso valore o struttura caotica.

Il punto di connessione con il crawl budget tradizionale è la scrapability: la capacità di un contenuto di essere estratto, compreso e riutilizzato da un sistema automatico. Un sito ottimizzato per il crawl budget di Google lo è anche per i crawler AI, perché entrambi privilegiano:

• pagine veloci con struttura HTML pulita e headings gerarchici
• contenuti senza duplicazioni eccessive che diluiscono il segnale informativo
• URL stabili e significativi, non generati dinamicamente da parametri
• dati strutturati (Schema.org) che facilitano la comprensione semantica del contenuto

Chi lavora sulla GEO (Generative Engine Optimization) per essere citato dagli LLM deve sapere che la qualità tecnica del sito è un prerequisito tanto quanto la qualità del contenuto. Un articolo ben scritto su un sito lento, con URL caotici e duplicati, ha meno probabilità di essere scansionato e citato di uno equivalente su un sito tecnicamente curato. La gestione del crawl budget e l’ottimizzazione per i sistemi AI non sono percorsi separati: convergono sugli stessi interventi tecnici.

Una nota pratica: il file robots.txt consente di bloccare i crawler AI singolarmente, usando le direttive user-agent specifiche (GPTBot, ClaudeBot, ecc.). Questa è una scelta legittima, ma chi vuole essere citato dagli LLM deve evitare di bloccarli. Bloccare Googlebot con robots.txt impedisce la scansione SEO ma non impedisce ai crawler AI di passare, e viceversa. Le direttive vanno pensate separatamente per ciascun tipo di bot.

FAQ

Il crawl budget riguarda tutti i siti?

No. Per siti con poche centinaia di pagine che vengono indicizzate lo stesso giorno della pubblicazione, il crawl budget non è un problema concreto. Diventa rilevante per siti con più di 10.000 URL, e-commerce con navigazione faceted, portali editoriali con archivi profondi o qualsiasi sito con una porzione significativa di URL classificati come “rilevata ma non indicizzata” in Google Search Console.

Come si controlla il crawl budget in Google Search Console?

In Google Search Console, sotto Impostazioni > Statistiche di scansione, si trovano i dati degli ultimi 90 giorni: numero di richieste giornaliere di Googlebot, tempo medio di risposta del server, dimensione media del download e distribuzione dei codici di risposta (200, 301, 404, ecc.). Un tempo di risposta elevato o un’alta percentuale di risposte non-200 sono segnali di problema.

Il crawl rate limit si può impostare manualmente?

In parte. Google Search Console permette di ridurre il crawl rate (utile se il sito va in crisi durante le scansioni), ma non di aumentarlo oltre il valore che Google ritiene appropriato. L’unico modo per aumentare il crawl rate è migliorare la qualità dei contenuti e la velocità del server: Google lo farà automaticamente.

Bloccare pagine con robots.txt aumenta il budget disponibile per le altre?

Non in modo automatico e immediato. Google non trasferisce il budget liberato da pagine bloccate ad altre pagine, a meno che non stia già raggiungendo i limiti di capacità del server. L’effetto benefico si manifesta nel medio periodo: Googlebot smette di sprecare tempo su URL inutili e, nel tempo, aumenta la frequenza di scansione delle sezioni di valore.

Aggiornare la data nella sitemap aiuta a far scansionare le pagine prima?

No, anzi è controproducente. Se si aggiorna il campo lastmod senza che il contenuto sia effettivamente cambiato, Google se ne accorge e riduce la fiducia nella sitemap. Il lastmod deve riflettere modifiche reali al contenuto principale della pagina, non variazioni cosmetiche o update automatici della data.