Crawl budget: cos'è, quando diventa un problema SEO e come ottimizzarlo

Quando Googlebot arriva su un sito non scarica indiscriminatamente ogni URL che riesce a trovare. Google determina quanto può scansionare senza sovraccaricare il server e quanto ritiene utile effettuare nuove scansioni.

Google descrive il crawl budget come il risultato principalmente di due componenti: crawl capacity limit e crawl demand. La distinzione è descritta nella documentazione ufficiale di Google sul crawl budget.

Il crawl budget effettivo nasce dall'incontro di queste due esigenze: Google deve voler effettuare la scansione e il sito deve essere in grado di sostenerla.

Questo chiarisce anche perché non esiste un numero universale di URL che Googlebot dovrebbe visitare ogni giorno.

Due siti con un milione di pagine possono presentare comportamenti di scansione molto diversi in base alla qualità e alla frequenza di aggiornamento dei contenuti, all'architettura, alla risposta del server, alla quantità di URL duplicati o inutili e alla domanda che Google associa alle varie pagine.

Google gestisce inoltre la capacità di scansione a livello di hostname: sottodomini e host differenti possono quindi avere comportamenti differenti.

Crawling, indicizzazione e ranking non sono la stessa cosa

Uno degli errori più frequenti parlando di crawl budget SEO è usare crawling e indicizzazione come sinonimi.

Il percorso, semplificando, è questo:

scoperta dell'URL → scansione → elaborazione → eventuale indicizzazione → eventuale posizionamento

Una pagina che Google non scopre difficilmente potrà essere scansionata. Una pagina scansionata non viene automaticamente indicizzata. Una pagina indicizzata non ha automaticamente diritto a posizionarsi.

Google specifica espressamente che il fatto che una pagina sia stata scansionata non garantisce che venga inserita nell'indice.

Se il problema riguarda soprattutto pagine escluse dall'indice, conviene quindi distinguere prima le cause di scansione da quelle di indicizzazione. Su questo punto è disponibile l'approfondimento NetStrategy sull'indicizzazione di un sito web.

Questa distinzione impedisce di “ottimizzare il crawl budget” quando, in realtà, Google raggiunge regolarmente gli URL ma decide di non indicizzarli.

Per la maggior parte dei siti piccoli e medi il crawl budget non dovrebbe essere la prima preoccupazione tecnica.

Nella documentazione aggiornata, Google indica la propria guida avanzata alla gestione del crawl budget soprattutto per siti con circa un milione o più di pagine che cambiano con moderata frequenza, siti con circa 10.000 o più pagine che cambiano molto rapidamente e siti che presentano una quota considerevole di URL classificati in Search Console come “Rilevata, attualmente non indicizzata”. Google precisa che si tratta di indicazioni approssimative.

Il problema diventa quindi interessante soprattutto quando la dimensione o il modo in cui vengono generati gli URL crea una distanza molto grande tra:

URL che il crawler può raggiungere e URL per i quali il motore dovrebbe realmente spendere risorse per scansionarli.

Un eCommerce può avere 80.000 prodotti utili ma mettere a disposizione del crawler diversi milioni di combinazioni prodotte da colore, taglia, ordinamento, prezzo, disponibilità e parametri di tracking.

Un marketplace può moltiplicare ogni pagina attraverso filtri geografici.

Un portale immobiliare può creare combinazioni pressoché infinite di località, fasce di prezzo, metrature e caratteristiche.

Un sito editoriale storico può continuare a esporre tag, archivi, paginazioni e URL obsolete accumulate in quindici anni.

In situazioni del genere la dimensione apparente del sito per il crawler può diventare enormemente superiore al suo reale patrimonio SEO.

Un sito piccolo con pagine non indicizzate non ha necessariamente un problema di crawl budget

Un caso pubblicato da NetStrategy aiuta a capire la differenza.

Il sito analizzato aveva soltanto 60 pagine, ma circa la metà non risultava presente nell'indice. L'analisi evidenziò una sitemap assente e collegamenti verso alcune pagine gestiti tramite JavaScript. Dopo aver migliorato i meccanismi di discovery, le pagine mancanti furono scansionate e indicizzate rapidamente.

Definire quella situazione un problema di crawl budget sarebbe stato fuorviante.

Google non aveva davanti milioni di URL concorrenti per la scansione. Doveva semplicemente essere aiutato a scoprire e raggiungere correttamente le pagine.

La domanda corretta, quindi, non è:

“Perché Google non aumenta il mio crawl budget?”

ma:

“Cosa impedisce a Google di arrivare in modo rapido agli URL che mi interessano?”

Solo una delle possibili risposte è il crawl budget.

Non esiste in Google Search Console un indicatore chiamato “crawl budget disponibile” con una percentuale da ottimizzare. La diagnosi deve mettere insieme più fonti.

Partire dalle Statistiche di scansione di Google Search Console

Il report con le Statistiche di scansione mostra informazioni come numero di richieste effettuate da Googlebot, dimensione complessiva dei download, tempo medio di risposta e distribuzione delle richieste in base a risposta HTTP, tipo di file, finalità della scansione e tipo di Googlebot. Consente inoltre di individuare eventuali problemi di disponibilità dell'host.

Google ha descritto le caratteristiche del report nel proprio approfondimento sulle Crawl Stats di Search Console.

Il numero assoluto di richieste, da solo, dice però poco.

Se Googlebot effettua 500.000 richieste al giorno e 350.000 finiscono su combinazioni di filtri senza valore SEO, il problema non è necessariamente ottenere 600.000 richieste. È capire perché gran parte delle 500.000 disponibili viene utilizzata male.

Confrontare scansione e inventario SEO

Serve quindi un inventario degli URL che il sito vuole realmente rendere disponibili alla ricerca.

Per ogni grande famiglia di URL bisogna poter distinguere almeno:

È questa classificazione che rende leggibili i dati di crawl.

Senza sapere quali URL hanno valore, anche un file di log con milioni di righe rimane soltanto un elenco di richieste.

Quando servono i log del server

Search Console fornisce una visione aggregata. I server log, invece, permettono di osservare nel dettaglio quali URL vengono richiesti dai crawler, con quale frequenza e con quale risposta.

Su siti molto grandi la log analysis può rispondere a domande impossibili da affrontare efficacemente pagina per pagina:

• Googlebot visita più spesso le categorie importanti o le combinazioni di filtri?
• Quanto crawling viene assorbito da URL con parametri?
• Gli URL appena pubblicati vengono scoperti in ore, giorni o settimane?
• Google continua a richiedere vecchie pagine eliminate?
• Quali sezioni ricevono pochissima attenzione nonostante siano importanti per il business?

L'audit SEO tecnico è il contesto corretto in cui collegare questi dati all'architettura, all'indicizzazione e alle performance organiche.

Un KPI operativo utile può essere la quota delle richieste Googlebot destinate agli URL strategici rispetto alle richieste complessive osservate nei log. Non è una metrica ufficiale di Google e non esiste una soglia valida per tutti i siti; serve piuttosto a confrontare la distribuzione della scansione prima e dopo gli interventi.

I segnali che meritano un'analisi più approfondita

Il crawl budget diventa un'ipotesi concreta quando diversi segnali convergono.

• Un numero elevato di URL importanti rimane a lungo nello stato “Rilevata, attualmente non indicizzata”.
• Le nuove pagine strategiche vengono scoperte molto lentamente nonostante siano correttamente collegate.
• Una porzione consistente delle richieste Googlebot finisce su filtri, parametri, ricerche interne, paginazioni anomale o duplicati.
• La scansione delle aree importanti diminuisce mentre cresce quella di sezioni senza valore organico.
• I tempi di risposta o gli errori del server limitano la capacità del crawler.
• L'architettura produce un numero di URL enormemente superiore al numero di pagine che si desidera effettivamente indicizzare.

Nessun segnale, isolatamente, prova l'esistenza di un problema di crawl budget. È la combinazione tra inventario URL, dati di Search Console e comportamento effettivo del bot a permettere una diagnosi attendibile.

Nei siti di grandi dimensioni il problema raramente è una singola pagina. È quasi sempre un meccanismo che moltiplica gli URL.

Filtri e navigazione a faccette

La navigazione a faccette è uno dei casi più evidenti.

Un catalogo con filtri per brand, colore, prezzo, taglia, materiale e disponibilità può generare un numero enorme di combinazioni. Se ogni combinazione produce un URL tecnicamente raggiungibile, il crawler può trovarsi davanti a uno spazio praticamente infinito.

Google dedica una documentazione specifica al problema e avverte che la navigazione a faccette può causare overcrawling e rallentare la scoperta degli URL utili. Per approfondire è disponibile la guida ufficiale sulla faceted navigation.

Non significa che ogni filtro debba essere bloccato.

Alcune combinazioni possono intercettare una domanda organica molto utile: ad esempio una categoria “scarpe running uomo” potrebbe meritare una landing indicizzabile, mentre “scarpe ordinate per prezzo crescente” normalmente no.

La decisione va quindi presa sulla base del valore di ricerca, non semplicemente del fatto che l'URL contenga parametri o si trova all'interno del filtro.

Per gli eCommerce complessi questo tipo di scelta fa parte di una strategia più ampia di SEO per eCommerce.

Ricerche interne

Anche un motore di ricerca interno può produrre migliaia o milioni di pagine.

Se ogni query digitata dagli utenti genera un URL crawlable, Google può iniziare a esplorare un inventario incontrollabile di risultati, varianti, combinazioni e ricerche quasi duplicate.

È uno dei casi in cui bisogna distinguere tra poche landing di ricerca con valore consolidato e l'intero universo delle query generate dagli utenti.

URL con parametri e duplicazioni

Parametri di tracking, ordinamenti, session ID e combinazioni equivalenti possono esporre lo stesso contenuto attraverso molti indirizzi differenti.

La canonicalizzazione aiuta Google a comprendere quale versione sia preferibile, ma non deve essere considerata un interruttore che impedisce automaticamente la scansione di tutti gli URL duplicati.

Quando l'obiettivo è ridurre seriamente uno spazio URL enorme, bisogna intervenire alla fonte: generazione degli URL, linking interno, parametri, regole di crawling e architettura.

Soft 404 e URL eliminati gestiti male

Un prodotto definitivamente rimosso che continua a restituire 200 OK con una pagina quasi vuota può essere interpretato come una soft 404 e continuare a impegnare inutilmente sistemi di crawling ed elaborazione.

Google raccomanda di utilizzare risposte 404 o 410 per gli URL definitivamente rimossi e di correggere le soft 404.

Non si tratta di “recuperare budget” istantaneamente. Significa rendere più chiaro e stabile l'inventario tecnico del sito nel tempo.

Catene di redirect

Un redirect necessario non è un problema. Catene come:

A → B → C → D → E

aggiungono richieste e complessità senza offrire valore.

Quando possibile, i riferimenti interni dovrebbero puntare direttamente alla destinazione finale e le vecchie catene essere consolidate. Google include espressamente la riduzione delle lunghe catene di redirect tra le pratiche utili alla gestione del crawling.

Spazi URL praticamente infiniti

Calendari navigabili senza limite temporale, ID generati dinamicamente e combinazioni di parametri prive di una fine determinata possono creare vere e proprie crawl trap.

Qui il problema non è ottimizzare una pagina, ma eliminare il meccanismo che consente al crawler di continuare a generare percorsi senza valore.

Nel caso del problema, per ottimizzare il crawl budget serve perima trovare la causa e solo dopo pensare alla soluzione. Per fare questo, non esiste un'unica tecnica valida per tutti i siti.

1. Ridurre l'inventario inutile

La prima domanda dovrebbe essere:

quanti URL può generare il sito e quanti di questi hanno un ruolo reale nella strategia SEO?

Su un grande portale la differenza può essere di diversi ordini di grandezza.

Un catalogo da 100.000 prodotti non dovrebbe trasformarsi senza una ragione precisa in uno spazio crawlable da 20 milioni di URL.

Prima di modificare robots.txt, canonical o sitemap è quindi utile mappare le diverse tipologie di URL e decidere quali devono essere indicizzabili e crawlable, crawlable ma non indicizzabili per esigenze specifiche oppure completamente fuori dai percorsi destinati ai crawler.

2. Usare robots.txt per il crawling, non come strumento di deindicizzazione

Il file robots.txt può impedire al crawler di richiedere determinate sezioni.

È quindi utile quando una vasta classe di URL non deve essere scansionata.

Ma bloccare un URL con robots.txt non equivale a rimuoverlo dall'indice. Se Google non può accedere alla pagina, non può nemmeno leggere eventuali direttive presenti al suo interno.

La scelta tra robots.txt, noindex, canonical, redirect e status HTTP deve quindi dipendere dall'obiettivo tecnico.

3. Non usare noindex come tecnica per “risparmiare crawl budget”

È un equivoco particolarmente diffuso.

Google dice esplicitamente di non utilizzare noindex con l'obiettivo di riallocare crawl budget, perché Googlebot deve comunque richiedere la pagina per poter leggere la direttiva.

noindex è corretto quando si vuole impedire l'indicizzazione di una pagina che il crawler può visitare.

È un problema diverso.

Questa distinzione è confermata anche da casi reali: rimuovere milioni di pagine dall'indice tramite noindex può richiedere numerose scansioni proprio perché Google deve tornare sugli URL per scoprire che non devono più essere indicizzati.

4. Rendere la sitemap una rappresentazione pulita degli URL importanti

Una sitemap XML non aumenta magicamente il crawl budget.

Aiuta invece i motori a conoscere gli URL che il sito considera rilevanti, soprattutto quando il sito è grande, complesso o aggiornato frequentemente.

Per Google, <priority> e <changefreq> vengono ignorati. Il valore <lastmod> può invece essere utilizzato se viene mantenuto in maniera accurata e coerente. Anche l'ordine degli URL nel file non determina una priorità di scansione.

Le indicazioni aggiornate sono disponibili nella documentazione Google dedicata alla creazione e gestione delle sitemap.

La sitemap dovrebbe quindi riflettere un inventario pulito di pagine canoniche che si desidera rendere disponibili alla ricerca, non contenere URL solo perché tecnicamente esistono.

All'interno della nostra guida dedica sitemap e il suo ruolo nella SEO, abbiamo approfondimenti sulla gestione e la sua importanza per il sito.

5. Migliorare il linking interno degli URL strategici

Google deve poter raggiungere le pagine importanti attraverso normali link HTML crawlable.

Una pagina presente soltanto nella sitemap, isolata dall'architettura del sito, invia un segnale molto diverso da una pagina correttamente integrata nelle categorie e nei percorsi di navigazione.

Il linking interno aiuta contemporaneamente discovery, comprensione della struttura e distribuzione dell'importanza interna.

Per il crawl budget la logica è semplice: non rendere difficili da trovare proprio gli URL sui quali vuoi che Google concentri attenzione.

6. Rendere efficiente il server

La capacità di scansione dipende anche dalla risposta dell'infrastruttura.

Se il server rallenta o restituisce errori, Google può ridurre le richieste per evitare di compromettere il servizio. Google raccomanda quindi di mantenere buone prestazioni del server e supportare, quando appropriato, risposte come 304 Not Modified, che consentono di evitare il trasferimento completo di contenuti invariati.

Migliorare la capacità tecnica può aumentare la quantità di crawling possibile quando il server costituisce effettivamente il limite.

Non crea però automaticamente una domanda di scansione.

Attenzione a questo dettaglio, un sito velocissimo con milioni di pagine prive di valore non diventa interessante per Google semplicemente perché riesce a servirle più rapidamente.

7. Misurare cosa cambia dopo l'intervento

Una modifica al crawl budget dovrebbe avere una conseguenza osservabile.

Se vengono eliminate milioni di combinazioni inutili ma la frequenza di scansione degli URL importanti rimane identica, potrebbe significare che Google non stava esaurendo la propria capacità oppure che il vero collo di bottiglia era altrove.

Google avverte infatti che liberare capacità di scansione non significa automaticamente che quella capacità verrà trasferita ad altri URL quando il crawler non stava già raggiungendo il proprio limite.

È una precisazione importante perché impedisce di trasformare il crawl budget in una metrica da “massimizzare”.

L'obiettivo non è vedere più richieste.

L'obiettivo è ottenere una scansione coerente con le priorità del sito.

Uno dei casi interessanti pubblicati sul tema è quello di Skroutz, comparatore ed eCommerce greco di grandi dimensioni.

Il team stimava circa 6,5 milioni di URL che avrebbero dovuto rappresentare il proprio inventario utile, ma Google ne aveva indicizzati circa 25 milioni. Una parte enorme proveniva dal motore di ricerca interno e dalle combinazioni generate dalle query degli utenti. Più della metà della scansione giornaliera finiva proprio sulle pagine di ricerca interna.

Il problema non era quindi “ottenere più crawl budget”.

Il problema era che una quantità considerevole del crawling disponibile veniva assorbita dal posto sbagliato.

Il team analizzò milioni di query, mantenne le ricerche considerate strategiche, ne reindirizzò altre verso categorie o filtri più appropriati e applicò noindex a un'enorme quantità di risultati senza valore.

L'intervento coinvolse circa 2,7 milioni di keyphrase associate a circa 14 milioni di URL: circa 2,2 milioni furono gestite con noindex, 300.000 reindirizzate e circa 200.000 mantenute.

Il numero stimato di URL indicizzati scese da circa 25 milioni a 7,6 milioni, una riduzione nell'ordine del 70%.

Parallelamente diminuì il crawling delle pagine di ricerca e aumentò quello delle aree considerate più utili. Il team riportò inoltre che nuovi URL che in precedenza potevano richiedere due o tre mesi per essere indicizzati e iniziare a posizionarsi arrivavano a farlo nell'arco di pochi giorni.

Il valore del caso non sta nel replicare le stesse direttive su qualsiasi sito.

Sta nella sequenza utilizzata durante l'analisi e il ragionamento:

misurare dove va Googlebot → individuare lo spazio URL inutile → ridurre quello spazio → verificare dove si sposta la scansione → osservare gli effetti sugli URL strategici.

È un metodo molto più robusto di una checklist applicata senza diagnosi.

Ed evidenzia anche un'altra lezione: le pagine in noindex continuarono a richiedere scansioni per un periodo significativo. Il noindex risolveva un problema di indicizzazione, ma non costituiva un interruttore immediato del crawling.

Perché i log diventano importanti quando il sito cresce

Uno dei casi recenti pubblicato da JetOctopus mostra un approccio basato proprio sull'analisi sistematica dei log in un ecosistema composto da più prodotti e milioni di pagine.

Secondo il case study pubblicato, dopo gli interventi focalizzati sul crawl budget il volume complessivo di crawling aumentò di circa tre volte, le visite dei bot e le pagine visitate raddoppiarono e la scoperta di nuove pagine aumentò del 200%.

Essendo un case study prodotto dal fornitore dello strumento, questi numeri vanno letti come risultati dichiarati dal progetto e non come un esperimento indipendente.

Rimane però utile il principio: oltre una certa dimensione non è realistico capire come Googlebot utilizza il sito osservando manualmente qualche URL in Search Console. Serve lavorare sui pattern.

Non direttamente.

Il crawl budget non è una leva attraverso la quale “comprare” posizioni aumentando il numero di richieste di Googlebot.

Il suo impatto è indiretto ma, nei siti giusti, importante.

Se Google dedica una parte eccessiva della scansione a milioni di URL inutili e scopre con grande ritardo nuove categorie, prodotti o contenuti strategici, quella lentezza può ostacolare il processo necessario perché tali pagine arrivino alla fase di valutazione e indicizzazione.

Ottimizzare il crawl budget significa quindi rimuovere un possibile collo di bottiglia tecnico.

Una volta che la pagina viene correttamente scoperta e scansionata, restano però tutte le altre condizioni della SEO: qualità e utilità del contenuto, corrispondenza con l'intento di ricerca, struttura del sito, autorevolezza, segnali interni ed esterni, concorrenza.

Più crawling non equivale automaticamente a più ranking.

Il concetto di crawl budget descritto fin qui appartiene soprattutto al modo in cui Google documenta il comportamento di Googlebot.

Altri sistemi hanno crawler e controlli propri.

Bingbot, ad esempio, è il crawler principale utilizzato da Bing. Bing Webmaster Tools mette a disposizione anche strumenti di Crawl Control con cui il proprietario del sito può intervenire sulla velocità di scansione nelle diverse ore della giornata.

La relativa documentazione è disponibile nella guida Bing dedicata al Crawl Control.

Non è corretto presumere che ogni crawler utilizzi lo stesso modello di crawl budget di Google.

La distinzione diventa ancora più importante con i sistemi AI.

OpenAI identifica OAI-SearchBot come il crawler utilizzato per la ricerca: un sito pubblico che vuole consentire ai propri contenuti di essere scoperti e potenzialmente mostrati o citati in ChatGPT Search non dovrebbe bloccarlo. Il controllo relativo alla ricerca è distinto da quello associato a GPTBot, utilizzato per finalità legate ai modelli.

Per approfondire è disponibile la documentazione OpenAI per publisher e sviluppatori.

Anche Google-Extended viene talvolta interpretato erroneamente come un nuovo crawler. Google chiarisce invece che non è un user agent HTTP indipendente: è un token di controllo utilizzabile in robots.txt per gestire alcuni utilizzi dei contenuti nei sistemi Gemini, senza modificare l'inclusione o il ranking in Google Search.

La distinzione è descritta nella documentazione Google sui crawler comuni.

Per la GEO – Generative Engine Optimization, la conclusione utile non è quindi che esista un fantomatico “crawl budget AI” uguale per tutti.

È più concreta:

un sito dovrebbe sapere quali crawler vuole autorizzare, quali contenuti rende tecnicamente accessibili e come questi contenuti possono essere scoperti dai sistemi che intende presidiare.

La crawlability rimane quindi una componente dell'accessibilità tecnica anche oltre la ricerca tradizionale, ma va analizzata crawler per crawler e avere chiaro l'obbiettivo finale che si vuole raggiungere.

Per approfondire questo ambito è disponibile la consulenza GEO di NetStrategy e la guida dedicata all'AI Search Optimization.

Prima di aprire robots.txt o cambiare una sitemap, conviene rispondere a poche domande concrete.

• Il sito dispone di decine di migliaia, centinaia di migliaia o milioni di URL?
• Il numero di URL tecnicamente generabili è molto superiore alle pagine che si desidera indicizzare?
• Googlebot dedica una quota significativa delle proprie richieste a URL senza valore SEO?
• Gli URL strategici vengono scoperti o riscansionati con ritardi rilevanti?
• Search Console evidenzia problemi di disponibilità dell'host o un ampio numero di URL rilevati ma non ancora scansionati?
• I log confermano che il crawler sta impiegando gran parte delle richieste su sezioni marginali?

Se le risposte sono prevalentemente negative, probabilmente esistono problemi SEO più prioritari del crawl budget.

Se diverse risposte sono positive, allora ha senso analizzare con precisione come il sito genera, collega e serve gli URL.

Il crawl budget diventa importante quando il sito è sufficientemente grande o complesso da costringere Google a scegliere continuamente dove spendere le proprie richieste.

In quel momento filtri, duplicazioni, ricerche interne, URL obsolete e inefficienze architetturali smettono di essere soltanto problemi di ordine tecnico: competono con categorie, prodotti e contenuti strategici per l'attenzione del crawler.

Su siti piccoli, invece, parlare subito di crawl budget rischia di far perdere tempo. Prima vanno escluse cause più semplici come pagine non raggiungibili, linking debole, errori di indicizzazione o direttive tecniche incoerenti.

La corretta ottimizzazione parte quindi dalla diagnosi.

Prima si misura dove sta andando Googlebot. Poi si decide dove dovrebbe andare. Solo alla fine si interviene sull'architettura, sui filtri, sul linking, sulle sitemap, sulle risposte HTTP o sulla capacità del server.

Quando il sito ha dimensioni o complessità tali da richiedere analisi dei log, architettura tecnica e controllo sistematico dell'indicizzazione, il crawl budget diventa parte di un lavoro SEO più ampio. In questi casi un'agenzia SEO può collegare i dati di scansione agli URL che generano realmente opportunità organiche e valore per il business.