Crawl budget: cos’è e come ottimizzarlo

TL;DR — Il crawl budget è la quantità che un motore di ricerca è disposto a scansionare del tuo sito. È il prodotto di due fattori: quanto il tuo server può gestire e quanto Google vuole scansionare. Scansionare di più non ti fa posizionare più in alto e, per la maggior parte dei siti, non è un problema. Se le pagine vengono scansionate lo stesso giorno in cui le pubblichi, non hai un problema di crawl budget.

Che cos’è il crawl budget

Quando un motore di ricerca scansiona il tuo sito, non lo fa per sempre. Scansiona un certo numero di URL in una determinata finestra temporale e poi passa oltre. Quella quantità è ciò che i professionisti SEO chiamano crawl budget.

Si riduce a due domande a cui il motore di ricerca risponde continuamente:

• Quanto posso scansionare? Il tuo server può gestire solo una certa quantità prima di rallentare o iniziare a restituire errori. Google lo osserva e riduce il ritmo. Questa è la capacità di scansione (nei documenti più vecchi chiamata limite di velocità di scansione).
• Quanto voglio scansionare? Le pagine popolari e quelle che cambiano spesso vengono scansionate di più. Le pagine a cui nessuno collega o che non cambiano mai vengono scansionate raramente. Questa è la domanda di scansione.

Moltiplica i due fattori e ottieni il crawl budget: in termini approssimativi, il numero di URL che Google può e vuole scansionare. Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

È importante chiarire subito una distinzione: il crawl budget riguarda il fatto che Google recuperi o meno un URL. La decisione di indicizzare ciò che trova è successiva e separata. Una pagina può essere scansionata e restare comunque non indicizzata: la scansione non garantisce l’indicizzazione, è solo il passaggio che devi superare per primo.

La prima cosa da capire: probabilmente non devi preoccupartene

È la parte che la maggior parte degli articoli nasconde. La maggior parte dei siti non ha un problema di crawl budget. Google lo dice direttamente: se le pagine vengono scansionate lo stesso giorno in cui vengono pubblicate, oppure il sito non è enorme e soggetto a cambiamenti rapidi, puoi saltare del tutto l’argomento. Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

Un controllo intuitivo: cerca alcuni dei tuoi URL su Google oppure usa lo strumento Controllo URL in Search Console. Se le nuove pagine compaiono entro uno o due giorni, il tuo crawl budget è a posto. Dedica invece il tempo ai contenuti e ai link.

Il crawl budget inizia a contare quando un sito ha centinaia di migliaia o milioni di pagine, soprattutto se molte cambiano continuamente (pensa a un grande ecommerce o a un grande sito di notizie).

Scansionare di più non significa posizionarsi meglio

Vale la pena sfatare subito un mito: scansionare una pagina più spesso non la fa salire nei risultati. La scansione è semplicemente il modo in cui il motore trova e scarica la tua pagina. È un passaggio che devi superare per poter posizionarti, ma una volta superato, la frequenza con cui vieni scansionato di nuovo non è un fattore di ranking.

Quindi l’obiettivo non è “farti scansionare di più”. È assicurarti che le pagine che ti interessano vengano scansionate e che il motore non sprechi tempo su URL inutili.

Cosa spreca il crawl budget

Se hai un sito grande, il budget viene consumato da:

• URL di filtro e ordinamento (navigazione sfaccettata): ogni combinazione di filtri in un ecommerce può generare migliaia di URL quasi identici.
• Pagine duplicate: lo stesso contenuto raggiungibile da più URL (con e senza www, con parametri aggiunti e così via).
• Soft 404s: pagine “non trovate” che restituiscono uno stato 200 OK, quindi il motore continua a scansionarle.
• Catene di redirect interrotte e pagine lente: rendono più costosa ogni scansione.

La soluzione consiste quasi sempre nel rimuovere gli sprechi affinché il budget ricada sulle pagine reali, non nel cercare di convincere Google a scansionare “di più”.

Vuoi il modello completo — capacità e domanda di scansione, soglie esatte delle dimensioni, cosa fare con la navigazione sfaccettata, in che modo Bing gestisce la questione diversamente e come misurarla? Passa alla scheda Advanced.

TL;DR — Crawl budget = limite della capacità di scansione (ciò che il tuo server può gestire) × domanda di scansione (popolarità + obsolescenza + inventario percepito). È una questione di efficienza, non un segnale di ranking. Internamente consiste in una programmazione per importanza, vincolata al carico dell’host, non in una quota fissa per sito. La maggior parte dei siti può ignorarlo: Mueller considera i 100k URL “di solito insufficienti” e Google dice ai siti scansionati nello stesso giorno di saltare la guida. Diventa rilevante con circa 1M+ pagine (cambio settimanale), 10k+ pagine (cambio giornaliero) o quando “Scoperto: attualmente non indicizzato” aumenta rapidamente. La leva più efficace è eliminare gli sprechi — navigazione sfaccettata, duplicati, soft 404s, spazi infiniti — così il budget si concentra sugli URL che contano.

Il modello a due fattori

Google lo definisce in modo chiaro: “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (traduzione) «La quantità di tempo e risorse che Google dedica alla scansione di un sito è comunemente chiamata crawl budget del sito ed è determinata da due elementi principali: il limite della capacità di scansione e la domanda di scansione». La formulazione del 2017 di Gary Illyes è quella a cui ricorro ancora: il crawl budget è “the number of URLs Googlebot can and wants to crawl.” (traduzione) «il numero di URL che Googlebot può e vuole scansionare». Evidence for this claim Google defines crawl budget using crawl capacity limit and crawl demand. Scope: Google Search crawling for larger sites. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide Mantieni il perimetro: il crawl budget regola il recupero, non l’indicizzazione. Un URL scansionato passa comunque attraverso una decisione di indicizzazione separata: fonderle sopravvaluta ciò che il crawl budget controlla.

Limite della capacità di scansione (il lato dell’offerta). È “the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (traduzione) «il numero massimo di connessioni parallele simultanee che Google può utilizzare per scansionare un sito, oltre all’intervallo tra due recuperi». Cambia con lo stato di salute del tuo server. Risposte rapide e pulite fanno aumentare il limite; risposte lente, errori 5xx o 429s fanno arretrare Googlebot. Nel mio deck How Search Works elenco gli stessi fattori che attivano il limite: stabilità del server, risposte lente, errori server 5xx e 429 (troppe richieste). Questo è il “può”.

Domanda di scansione (il lato della domanda). È determinata dalla popolarità (quanto un URL riceve link / quanto è importante) e dall’obsolescenza (da quanto tempo non è stato scansionato e con quale frequenza cambia). Lo stesso deck scompone la domanda in PageRank, frequenza di cambiamento della pagina, tempo dall’ultima scansione e cambiamenti importanti del sito. È fondamentale che Google indichi l’inventario percepito come la leva che controlli di più: “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site. If many of these URLs are duplicates, or you don’t want them crawled for some other reason… this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (traduzione) «Senza indicazioni da parte tua, Google prova a scansionare tutti o quasi tutti gli URL del sito di cui è a conoscenza. Se molti sono duplicati, o non vuoi che vengano scansionati per qualche altro motivo, ciò fa sprecare molto tempo di scansione di Google sul sito. Questo è il fattore sul quale puoi esercitare il maggiore controllo positivo».

Ci sono alcuni fatti strutturali che colgono di sorpresa:

• Il budget è per hostname. “https://www.example.com/ and https://code.example.com/ are two different hostnames, and therefore have separate crawl budgets.” (traduzione) «i due indirizzi indicati appartengono a hostname diversi e hanno quindi crawl budget separati». I sottodomini non condividono il budget.
• I diversi tipi di Googlebot probabilmente attingono a un unico pool. Nei miei report, immagini, notizie, video, annunci e il resto sembrano attingere allo stesso budget per sito; non ho però una fonte primaria Google attuale che lo dimostri con precisione, quindi trattalo come un’osservazione di un professionista, non come una policy documentata. In ogni caso, vale la pena controllare la suddivisione per tipo di crawler nel report Statistiche di scansione se sospetti che un tipo stia sottraendo spazio agli altri.

Che cos’è davvero a livello interno: programmazione per importanza

“Crawl budget” è un termine ombrello coniato dalla SEO. Internamente è più vicino a una programmazione vincolata dal carico dell’host. Come ha descritto Illyes, lo scheduler di Google “sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (traduzione) «crea un insieme di URL ordinati per importanza e GoogleBot li scansiona in quell’ordine, secondo la pianificazione stabilita dal carico dell’host. Se Google ritiene che il server possa reggerlo, scansiona l’intero insieme; altrimenti si ferma».

Questo riformula l’intero argomento. Non è una quota fissa “ricevi N pagine al giorno”: è una coda prioritaria e la scansione segue la domanda di ricerca. Ancora Illyes: “If search demand goes down, then that also correlates to the crawl limit going down,” (traduzione) «se la domanda di ricerca diminuisce, ciò è correlato anche a una riduzione del limite di scansione» e “if you want to increase how much we crawl, then you somehow have to convince search that your stuff is worth fetching, which is basically what the scheduler is listening to.” (traduzione) «se vuoi aumentare la quantità che scansioniamo, devi in qualche modo convincere la Ricerca che valga la pena recuperare i tuoi contenuti, che è sostanzialmente ciò che lo scheduler ascolta». Il team Search Relations ha definito esplicitamente un equivoco l’idea di una “quota giornaliera fissa di pagine”.

Il tuo sito ha davvero un problema di crawl budget?

Questa è la sezione più utile, quindi sarò diretto: la maggior parte dei siti non deve preoccuparsi del crawl budget. La guida ufficiale di Google apre ridimensionando il problema: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide. For Google Search specifically, merely keeping your sitemap up to date and checking your index coverage regularly is adequate.” (traduzione) «Se il sito non contiene un gran numero di pagine che cambiano rapidamente, oppure le pagine sembrano essere scansionate lo stesso giorno in cui vengono pubblicate, non è necessario leggere questa guida. Per la Ricerca Google, è sufficiente mantenere aggiornata la sitemap e controllare regolarmente la copertura dell’indice». Evidence for this claim Google says sites without many rapidly changing pages, or whose pages are crawled the day they publish, generally do not need crawl-budget guidance. Scope: Google's rough applicability guidance, not a guarantee for every site. Confidence: high · Verified: 2026-07-14 Google: Large site crawl budget guide

John Mueller ha fornito il numero concreto: “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (traduzione) «Centomila URL di solito non bastano a influire sul crawl budget: sono meno di uno al minuto nell’arco di tre mesi». Se hai meno di sei cifre di URL e le pagine vengono scansionate rapidamente, passa oltre.

Quando conta davvero, le soglie approssimative di Google sono:

• Siti grandi — 1 milione+ di pagine uniche con contenuti che cambiano con frequenza moderata (circa ogni settimana).
• Siti medi o grandi — 10 000+ pagine uniche con contenuti che cambiano molto rapidamente (ogni giorno).
• Siti con una grande parte di URL classificati come “Discovered – currently not indexed” in Search Console: è la spia che Google conosce gli URL ma non riesce a raggiungerli.

Google aggiunge la precisazione che “the numbers given here are a rough estimate… not exact thresholds.” (traduzione) «i numeri indicati qui sono stime approssimative, non soglie esatte». E anche sui siti grandi resta valida la sfumatura che osservo nel mio lavoro: di solito sono le pagine nuove, con pochi link o statiche a rimanere indietro, non quelle popolari.

Il crawl budget influisce sul ranking? No.

La scansione è necessaria per posizionarsi, ma non è un segnale di ranking. Google nel 2017: “An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (traduzione) «Un aumento della frequenza di scansione non porta necessariamente a posizioni migliori nei risultati della Ricerca. Google usa centinaia di segnali per ordinare i risultati e, sebbene la scansione sia necessaria per comparirvi, non è un segnale di ranking». Lo esprimo allo stesso modo nella mia guida Ahrefs: “More crawling doesn’t mean you’ll rank better, but if your pages aren’t crawled and indexed they aren’t going to rank at all.” (traduzione) «Più scansioni non significano un ranking migliore, ma se le pagine non vengono scansionate e indicizzate non potranno posizionarsi affatto». Considera il crawl budget un problema di efficienza, punto.

Cosa spreca il crawl budget

Illyes ha pubblicato l’elenco canonico degli URL a basso valore aggiunto “in order of significance” (traduzione) «in ordine di importanza»:

1. Navigazione sfaccettata e identificatori di sessione — il principale responsabile, soprattutto le combinazioni di filtro e ordinamento ecommerce che moltiplicano gli URL in modo combinatorio.
2. Contenuti duplicati sul sito — le classiche varianti tecniche: HTTP e HTTPS, non-www e www, slash finale o assente, maiuscole o minuscole, pagine default/index e parametri URL. (Secondo una stima interna di Google, circa il 60 % del web è contenuto duplicato.)
3. Pagine di errore soft — soft 404s che restituiscono 200 continuano a essere scansionate.
4. Pagine compromesse.
5. Spazi infiniti e proxy — calendari, paginazione a scorrimento infinito con duplicati e combinazioni sfaccettate: i classici schemi di trappola per spider.
6. Contenuti di bassa qualità e spam.

Il costo è concreto: “Wasting server resources on pages like these will drain crawl activity from pages that do actually have value, which may cause a significant delay in discovering great content on a site.” (traduzione) «Sprecare risorse del server su pagine simili sottrae attività di scansione alle pagine che hanno davvero valore e può causare un ritardo significativo nella scoperta di ottimi contenuti sul sito». Inoltre, in cima all’elenco, le catene di redirect lunghe “have a negative effect on crawling,” (traduzione) «hanno un effetto negativo sulla scansione» e le pagine lente e pesanti rendono più costoso ogni recupero.

Come ottimizzarlo

L’intero obiettivo è consolidare il budget sugli URL che contano:

• Consolida i duplicati. Google: “Consolidate duplicate content to focus crawling on unique content rather than unique URLs.” (traduzione) «Consolida i contenuti duplicati per concentrare la scansione sui contenuti unici anziché sugli URL unici». Scegli un host, un protocollo e una convenzione per lo slash finale; usa i canonical e gestisci i parametri.
• Blocca i percorsi davvero privi di valore con robots.txt — ma solo quelli che non vuoi mai scansionare. Per la navigazione sfaccettata, le opzioni abituali sono bloccare i percorsi con parametri in robots.txt oppure usare # invece di ?, così gli URL non sono scansionabili in primo luogo.
• Non usare noindex per risparmiare budget. Google: “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (traduzione) «Non usare noindex: Google richiederà comunque la pagina e la scarterà quando rileverà un meta tag noindex o un’intestazione nella risposta HTTP, sprecando tempo di scansione». La richiesta continua a costare. Blocca con robots.txt se non vuoi mai che il percorso venga recuperato.
• Non aspettarti che robots.txt riallochi il budget. “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (traduzione) «Google non trasferirà questo crawl budget appena liberato ad altre pagine, a meno che il sito non stia già raggiungendo il proprio limite di servizio». Bloccare gli scarti è buona igiene, ma non consegna le scansioni liberate alle pagine buone se non eri vincolato dalla capacità.
• Correggi le soft 404s; restituisci 404/410 reali per le pagine rimosse. “A 404 status code is a strong signal not to crawl that URL again.” (traduzione) «Un codice di stato 404 è un segnale forte per non scansionare di nuovo quell’URL».
• Accorcia le catene di redirect, mantieni aggiornate le sitemap (lastmod onesto) e migliora la velocità del server.
• Rafforza i link interni verso le pagine importanti e nuove: è più semplice di qualsiasi altra cosa perché il controllo è completamente tuo.

E sono proprio due — solo due — i modi con cui Google dice che puoi davvero aumentare il budget: “Add more server resources… [and] optimize your content’s quality.” (traduzione) «Aggiungi più risorse al server e ottimizza la qualità dei contenuti». Nota la trappola: un server più veloce alza il limite della capacità, ma se la domanda è bassa Google continua a scansionare meno. Servono entrambi.

Come misurarlo

• Report Statistiche di scansione di GSC > Impostazioni — richieste di scansione totali nel tempo, tempo medio di risposta, stato dell’host e suddivisioni per codice di risposta, tipo di file e tipo di Googlebot. È la visuale di Google su come esegue la scansione.
• Analisi dei file di log del server — la fonte di verità. Mostra gli accessi reali di Googlebot per pattern di URL, così puoi vedere lo spreco di scansioni e le pagine importanti mai scansionate. Verifica che il bot sia davvero Googlebot tramite DNS inverso e diretto oppure gli intervalli IP pubblicati da Google (molti bot falsi contraffanno lo user agent).
• “Discovered – currently not indexed” in GSC — consideralo una spia del crawl budget: Google conosce gli URL ma non riesce a raggiungerli.

Bing e gli altri motori: “crawl efficiency”

Bing riformula l’argomento come crawl efficiency invece che budget. La definizione di Fabrice Canel è: “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (traduzione) «La crawl efficiency misura con quale frequenza scansioniamo e scopriamo contenuti nuovi e aggiornati per ogni pagina scansionata». L’obiettivo è “crawl an URL only when the content has been added (URL not crawled before), updated (fresh on-page context or useful outbound links).” (traduzione) «scansionare un URL solo quando il contenuto è stato aggiunto — quindi l’URL non era mai stato scansionato — oppure aggiornato, con nuovo contesto nella pagina o link esterni utili». La filosofia schietta di Bing è: “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (traduzione) «Per la SEO, meno è meglio. Non dimenticarlo mai. Meno URL da scansionare significa risultati migliori per la SEO».

La soluzione preferita da Bing è IndexNow: invia gli URL modificati così bingbot non deve eseguire scansioni esplorative; Crawl Control in Bing Webmaster Tools consente di programmare per ora la scansione di bingbot per proteggere il carico del server. È una divergenza reale tra Google e Bing: Google ha deprecato il vecchio limitatore della velocità di scansione in Search Console, mentre Bing permette ancora di modellare attivamente il programma di scansione.

Miti sul crawl budget, corretti

• “Every site should optimize crawl budget.” (traduzione) «Ogni sito dovrebbe ottimizzare il crawl budget». No: la maggior parte non dovrebbe farlo. Scansione nello stesso giorno e meno di 100k URL significano che va tutto bene.
• “More crawling = better rankings.” (traduzione) «Più scansioni significano ranking migliori». No. La scansione è necessaria, ma non è un segnale di ranking.
• “It’s a fixed daily page quota.” (traduzione) «È una quota giornaliera fissa di pagine». No: è una programmazione guidata dall’importanza e vincolata al carico dell’host.
• “Use noindex to save budget.” (traduzione) «Usa noindex per risparmiare budget». No: Google richiede comunque prima la pagina.
• “Block pages in robots.txt to give other pages more budget.” (traduzione) «Blocca le pagine in robots.txt per dare più budget alle altre». In generale no, a meno che tu non sia già al limite della capacità di servizio.
• “A faster server alone raises your budget.” (traduzione) «Un server più veloce da solo aumenta il budget». Alza solo il limite della capacità; una domanda bassa significa comunque meno scansioni.

Per la pipeline più ampia in cui questo si inserisce — scoperta, scheduler di scansione, rendering e differenze tra scansione e indicizzazione — consulta l’hub sul crawling. Gli argomenti collegati (velocità di scansione, frequenza di scansione, spider trap e analisi dei file di log) approfondiscono ciascuno un aspetto.

Riepilogo AI

Una sintesi della versione Advanced:

• Formula del crawl budget: limite della capacità di scansione × domanda di scansione. La capacità è ciò che il tuo server può gestire (aumenta con risposte rapide e pulite, diminuisce con 5xx/429); la domanda è popolarità + obsolescenza + inventario percepito. La formula di Google è “the number of URLs Googlebot can and wants to crawl.” (traduzione) «il numero di URL che Googlebot può e vuole scansionare».
• Non è un fattore di ranking. La scansione è necessaria per posizionarsi, ma scansionare di più non aumenta le posizioni: è solo una questione di efficienza.
• Internamente è una programmazione per importanza, vincolata al carico dell’host: una coda prioritaria, non una quota giornaliera fissa. La scansione segue la domanda di ricerca.
• La maggior parte dei siti non deve gestirlo. Mueller: 100k URL di solito non bastano per farlo contare. Google: se le pagine vengono scansionate lo stesso giorno, salta la guida. Diventa rilevante con circa 1M+ pagine (cambio settimanale), 10k+ (cambio giornaliero) o una grande quantità di “Discovered – currently not indexed”.
• Cosa lo spreca (ordine di Google): navigazione sfaccettata / ID di sessione, contenuti duplicati, soft 404s, pagine compromesse, spazi infiniti, contenuti di bassa qualità, oltre a catene di redirect e pagine lente.
• Ottimizza eliminando gli sprechi: consolida i duplicati, blocca i percorsi privi di valore in robots.txt (non noindex: Google li richiede comunque prima), correggi le soft 404s, accorcia i redirect, mantieni pulite le sitemap e rafforza i link interni. Gli unici due modi per aumentare davvero il budget sono più capacità server e maggiore qualità dei contenuti.
• Misuralo con Statistiche di scansione GSC, analisi dei log del server e report “Discovered – currently not indexed” (traduzione) «Scoperto: attualmente non indicizzato».
• Bing lo chiama crawl efficiency (“less is more”) e spinge IndexNow + Crawl Control invece dell’approccio non interventista di Google.

Documentazione ufficiale

Documentazione primaria dei motori di ricerca.

Google

• Ottimizza il tuo crawl budget — il documento canonico (spostato dal vecchio URL della “guida per proprietari di siti grandi” nella documentazione sull’infrastruttura di crawling di Google, aggiornato a dicembre 2025): capacità e domanda di scansione, chi ne ha bisogno, elenco degli sprechi e come ottimizzare. Inizia da qui.
• Cosa significa il Crawl Budget per Googlebot (Gary Illyes, 2017) — la formulazione originale: limite della velocità di scansione + domanda di scansione e categorie di URL a basso valore aggiunto.
• Scansione e indicizzazione — l’hub per robots, sitemap, canonicalizzazione e controlli della scansione.
• Serie Crawling December (2024) — Googlebot, caching HTTP, navigazione sfaccettata e CDN.

Bing / Microsoft

• Serie bingbot: massimizzare la crawl efficiency — la riformulazione di Bing in termini di “crawl efficiency” e il suo principio guida.
• Serie bingbot: ottimizzare la frequenza di scansione — come Bing decide la frequenza delle nuove scansioni.
• Bing Webmaster Tools — Crawl Control — programma per ora la scansione di bingbot.
• IndexNow / indexnow.org — invia gli URL modificati così i motori non devono eseguire scansioni esplorative.

Citazioni dalla fonte

Dichiarazioni pubbliche di Google e Bing. Ogni link è un deep link che porta direttamente al passaggio citato nella pagina sorgente.

Google — la definizione

• “The amount of time and resources that Google devotes to crawling a site is commonly called the site’s crawl budget and it’s determined by two main elements: crawl capacity limit and crawl demand.” (traduzione) «La quantità di tempo e risorse che Google dedica alla scansione di un sito è comunemente chiamata crawl budget del sito ed è determinata da due elementi principali: il limite della capacità di scansione e la domanda di scansione». — Documentazione Google Search Central. Vai alla citazione
• “Google’s crawlers calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site, as well as the time delay between fetches.” (traduzione) «I crawler di Google calcolano un limite della capacità di scansione, cioè il numero massimo di connessioni parallele simultanee che Google può usare per scansionare un sito, oltre all’intervallo tra due recuperi». Vai alla citazione
• “Taking crawl rate and crawl demand together we define crawl budget as the number of URLs Googlebot can and wants to crawl.” (traduzione) «Considerando insieme la frequenza e la domanda di scansione, definiamo il crawl budget come il numero di URL che Googlebot può e vuole scansionare». — Gary Illyes, Google (2017). Vai alla citazione

Google — quando non devi preoccupartene

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (traduzione) «Se il sito non contiene un gran numero di pagine che cambiano rapidamente, oppure le pagine sembrano essere scansionate lo stesso giorno in cui vengono pubblicate, non è necessario leggere questa guida». Vai alla citazione
• “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (traduzione) «Centomila URL, in genere, non sono sufficienti a incidere sul crawl budget: equivalgono a meno di uno al minuto in tre mesi». — John Mueller, Google (2021). Leggi la copertura

Google — cosa controlli e differenza tra scansione e ranking

• “If many of these URLs are duplicates, or you don’t want them crawled for some other reason (removed, unimportant, and so on), this wastes a lot of Google crawling time on your site. This is the factor that you can positively control the most.” (traduzione) «Se molti URL sono duplicati, oppure non vuoi che vengano scansionati perché rimossi, poco importanti o per altri motivi, Google spreca molto tempo di scansione sul sito. È l’elemento su cui puoi intervenire positivamente più di ogni altro». Vai alla citazione
• “An increased crawl rate will not necessarily lead to better positions in Search results. Google uses hundreds of signals to rank the results, and while crawling is necessary for being in the results, it’s not a ranking signal.” (traduzione) «Aumentare la frequenza di scansione non assicura posizioni migliori nella Ricerca. Google ordina i risultati usando centinaia di segnali: la scansione è indispensabile per comparire, ma non costituisce un segnale di ranking». — Gary Illyes, Google (2017). Vai alla citazione

Google — l’elenco degli sprechi e cosa non fare

• “Faceted navigation and session identifiers / On-site duplicate content / Soft error pages / Hacked pages / Infinite spaces and proxies / Low quality and spam content” (traduzione) «Navigazione sfaccettata e identificatori di sessione / Contenuti duplicati sul sito / Pagine di errore soft / Pagine compromesse / Spazi infiniti e proxy / Contenuti di bassa qualità e spam» — le categorie a basso valore aggiunto, in ordine di importanza. — Gary Illyes, Google (2017). Vai alla citazione
• “Consolidate duplicate content to focus crawling on unique content rather than unique URLs.” (traduzione) «Consolida i contenuti duplicati per concentrare la scansione sui contenuti unici anziché sugli URL unici». Vai alla citazione
• “Don’t use noindex, as Google will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time.” (traduzione) «Non usare noindex: Google richiederà comunque la pagina e la scarterà quando rileverà un meta tag noindex o un’intestazione nella risposta HTTP, sprecando tempo di scansione». Vai alla citazione
• “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s serving limit.” (traduzione) «Google non trasferirà questo crawl budget appena liberato ad altre pagine, a meno che il sito non stia già raggiungendo il proprio limite di servizio». Vai alla citazione

Gary Illyes, Google — programmazione e carico dell’host (tramite la copertura di una sessione Q&A di Stone Temple da parte di Search Engine Roundtable)

• “Host load kind of sets a bucket of URLs in importance order and GoogleBot will crawl in that order based on the schedule the host load decided. If Google thinks your server can handle it, it will crawl the whole bucket, if not, it will stop.” (traduzione) «Il carico dell’host forma una sorta di gruppo di URL ordinati per importanza; GoogleBot procede in quell’ordine seguendo la pianificazione determinata dal carico. Se ritiene che il server sia in grado di sostenerlo, completa il gruppo; in caso contrario interrompe la scansione». Vai alla citazione

Fabrice Canel, Microsoft Bing

• “The crawl efficiency is how often we crawl and discover new and fresh content per page crawled.” (traduzione) «La crawl efficiency misura con quale frequenza scansioniamo e scopriamo contenuti nuovi e aggiornati per ogni pagina scansionata». Vai alla citazione
• “Less is more for SEO. Never forget that. Less URLs to crawl, better for SEO.” (traduzione) «Nella SEO vale il principio del meno è meglio: non dimenticarlo. Ridurre gli URL da scansionare favorisce la SEO». Vai alla citazione

Checklist per ottimizzare il crawl budget

Vale la pena seguirla solo dopo aver confermato di avere davvero un problema di budget (sito grande, scansione non avvenuta lo stesso giorno o quantità crescente di “Discovered – currently not indexed”). Poi:

• Ho confermato che il problema è reale: ho controllato Statistiche di scansione GSC e “Discovered – currently not indexed” prima di ottimizzare.
• Ho scelto una convenzione canonical unica (host, protocollo, slash finale, maiuscole/minuscole) e ho consolidato i duplicati su di essa.
• Ho gestito i parametri URL: ho canonicalizzato quelli appropriati oppure bloccato quelli che creano solo varianti duplicate o di basso valore.
• Ho domato la navigazione sfaccettata: ho bloccato le combinazioni di filtro/ordinamento prive di valore in robots.txt oppure le ho spostate dietro un # così non sono scansionabili.
• Ho corretto le soft 404s e restituisco 404/410 reali per gli elementi rimossi definitivamente.
• Ho rimosso o accorciato le catene di redirect.
• Le sitemap elencano solo URL canonical e indicizzabili con un lastmod accurato.
• Non ho usato noindex per “salvare” il budget (Google lo richiede comunque) e non mi aspetto che i blocchi robots.txt riallochino il budget alle altre pagine.
• Ho rafforzato i link interni verso le pagine importanti e appena pubblicate.
• Ho migliorato il tempo di risposta del server e l’efficienza di caricamento della pagina.
• (Bing) Ho adottato IndexNow per inviare le modifiche e usato Crawl Control se il carico del server è il vincolo.

I modelli mentali

1. Budget = capacità × domanda. La capacità di scansione è ciò che il tuo server può gestire; la domanda è popolarità + obsolescenza + inventario percepito. Devono esserci entrambe: un server veloce con domanda bassa viene comunque scansionato meno, mentre una domanda alta viene limitata da un server in difficoltà. Per aumentare il budget effettivo quasi sempre devi rimuovere gli sprechi, non “chiedere di più”.

2. Il cancello “ho davvero un problema?” Esegui questo controllo prima di toccare qualsiasi cosa:

• Pagine scansionate lo stesso giorno in cui vengono pubblicate? → Nessun problema. Fermati qui.
• Meno di circa 100k URL (regola pratica di Mueller)? → Quasi certamente nessun problema.
• 1M+ pagine che cambiano ogni settimana, oppure 10k+ ogni giorno, oppure una grande quantità di “Discovered – currently not indexed”? → Ora vale la pena occuparsene.

3. Rimuovi gli sprechi prima di chiedere a Google di scansionare di più. È l’idea con la leva più alta dell’intera pagina. Google cerca di scansionare tutto ciò che conosce; se metà è costituita da duplicati, facet e soft 404s, sta spendendo il tuo budget su rifiuti. Elimina gli scarti e il budget si concentra sulle pagine che contano: è “the factor that you can positively control the most.” (traduzione) «il fattore sul quale puoi esercitare il maggiore controllo positivo».

4. Scansione ≠ ranking. La scansione è un cancello, non un tabellone. Scansionare di più non alza le posizioni. L’obiettivo è quindi la copertura degli URL giusti, non il volume grezzo di scansioni.

5. È una coda prioritaria, non una quota. Internamente è una programmazione per importanza vincolata al carico dell’host: un insieme prioritario di URL, non una quota fissa di “N pagine al giorno”. Risali la coda diventando più importante (link, domanda) e non sprecando recuperi.

Crawl budget — scheda rapida

Cosa spreca il budget (ordine di importanza di Google)

Inoltre: catene di redirect lunghe e pagine lente o pesanti rendono più costoso ogni recupero.

Devi davvero preoccupartene?

• Scansione nello stesso giorno → no.
• < circa 100k URL (Mueller) → quasi certamente no.
• 1M+ pagine che cambiano ogni settimana, oppure 10k+ ogni giorno, oppure una grande quantità di “Discovered – currently not indexed” → sì.

Correzioni che funzionano

• Consolida i duplicati / usa la canonicalizzazione.
• Blocca i percorsi privi di valore in robots.txt (facet, parametri): non usare mai noindex per “salvare” il budget.
• Correggi le soft 404s; restituisci 404/410 reali.
• Accorcia le catene di redirect; velocizza il server.
• Pulisci le sitemap; rafforza i link interni.

Gli unici due modi per aumentare il budget (secondo Google): più capacità server e maggiore qualità dei contenuti. Uno senza l’altro non basta.

Bing: è “crawl efficiency”: invia gli URL con IndexNow e programma la scansione con Crawl Control.

Strumenti per misurare e gestire il crawl budget

• Google Search Console — report Statistiche di scansione (Impostazioni → Statistiche di scansione) — la visuale di Google: richieste totali nel tempo, tempo medio di risposta, stato dell’host e suddivisione per codice di risposta, tipo di file e tipo di Googlebot. Parti da qui.
• GSC — “Discovered – currently not indexed” (traduzione) «Scoperto: attualmente non indicizzato» (report Pagine) — la spia degli URL che Google conosce ma non sta scansionando.
• Analisi dei file di log del server — la fonte di verità su quali URL i bot visitano davvero e con quale frequenza. Strumenti: Screaming Frog Log File Analyser oppure invia i log a BigQuery o a una piattaforma di log. (Vedi analisi dei file di log.)
• Ahrefs Site Audit / Screaming Frog SEO Spider — simula una scansione per individuare URL duplicati, catene di redirect, soft 404s, URL bloccati e spazi sfaccettati simili a trappole.
• Ahrefs Webmaster Tools — scansione e audit gratuiti per i siti che verifichi.
• Controllo URL (GSC) — controllo rapido della scansione nello stesso giorno per un singolo URL.
• Bing Webmaster Tools — Crawl Control — programma per ora la scansione di bingbot se il carico del server è il vincolo.

Hai un problema di crawl budget?

Controllo mensile dello stato del crawl budget

1. Esporta dai log del server le richieste dei crawler di ricerca per la stessa finestra di rendicontazione ogni mese.
2. Suddividi le richieste per codice di stato, directory, tipo di pagina e indicizzabilità dell’URL.
3. Controlla pattern di parametri ad alto volume, percorsi duplicati, redirect, soft 404s ed errori server.
4. Confronta la quota di scansione dei template preziosi con il periodo precedente e annota lanci o migrazioni.
5. Assegna a ogni nuovo pattern di spreco un responsabile e un controllo: link, parametri, redirect, canonicalizzazione, rimozione o riparazione del server.
6. Ricontrolla il pattern interessato nella finestra di log successiva; la procedura è completata quando gli URL preziosi mantengono l’accesso e lo spreco diminuisce rispetto alla baseline del sito.

Errori sul crawl budget

• Inseguire un numero maggiore di richieste. Scansionare di più non migliora il ranking. Tieni traccia invece del fatto che gli URL importanti vengano scansionati quando serve.
• Bloccare gli sprechi solo in robots.txt. Può impedire il recupero senza eliminare gli URL già scoperti né correggere i link che li generano. Rimuovi i percorsi di scansione e consolida l’inventario quando opportuno.
• Aggiornare lastmod in ogni sitemap a ogni build. Una freschezza falsa insegna ai crawler a non fidarsi del segnale. Cambialo solo per aggiornamenti significativi della pagina.
• Ignorare gli errori server mentre perfezioni i pattern URL. Un problema di capacità limita la scansione utile. Ripara prima timeout e risposte 5xx.
• Trattare ogni URL escluso come uno spreco. Alcune risorse non indicizzate supportano rendering o scoperta. Classifica lo scopo prima di bloccare qualcosa.

Prompt: classifica gli sprechi nei log di scansione

Incolla un CSV derivato dai log con URL, template, stato, bot, accessi, byte e indicizzabilità. Rimuovi prima i valori delle query o i dati degli utenti.

Act as a technical SEO analyst. Classify each URL pattern as valuable crawling, necessary support crawling, redirect/error waste, duplicate/parameter waste, or unclear. Do not infer intent from the URL alone: list the evidence needed for every unclear row. Rank patterns by crawler requests and bytes, propose the safest control, and state what could break if that control is wrong. Return a table plus a short validation plan.

Prompt: metti alla prova una diagnosi di crawl budget

Review the crawl-budget diagnosis below. Separate evidence of capacity, demand, discovery, and URL-inventory problems. Flag claims that confuse crawling with indexing or rankings. Then give the three smallest tests that would confirm or reject the diagnosis. Do not invent thresholds; use changes against the site's own baseline.

[PASTE DIAGNOSIS AND OBSERVATIONS]

Riassumi i codici di stato dei crawler da un log di accesso

Esegui questo comando su un log in stile nginx/Apache dopo aver adattato il pattern del bot al traffico del crawler che hai verificato:

awk 'BEGIN{IGNORECASE=1} /Googlebot|bingbot/ {print $9}' access.log | sort | uniq -c | sort -nr

In PowerShell:

Select-String -Path .\access.log -Pattern 'Googlebot|bingbot' | ForEach-Object { if ($_.Line -match '"\s(\d{3})\s') { $Matches[1] } } | Group-Object | Sort-Object Count -Descending

Estrai le famiglie dei parametri di query

Usa questa regex in un export del crawler o in un editor di testo per catturare il primo nome di parametro della query:

\?([^=&]+)(?:=[^&]*)?

Il gruppo 1 è il nome del parametro. Conteggi di richieste elevati identificano pattern da esaminare, non URL da bloccare automaticamente.

Mettiti alla prova: crawl budget

Risorse che valgono il tuo tempo

I miei contenuti correlati

• Quando dovresti preoccuparti del crawl budget? — la mia guida completa di Ahrefs su questo argomento, con dettagli sull’ottimizzazione e decisioni sulla navigazione sfaccettata.
• Come correggere “Discovered – currently not indexed” — il segnale GSC che funge anche da spia del crawl budget.
• La guida per principianti alla SEO tecnica — il posto in cui il crawl budget si inserisce nel quadro più ampio.
• Strategie SEO enterprise — per la minoranza di siti grandi che deve davvero gestirlo.

I miei interventi

• How Search Works (SlideShare) — il mio percorso sul modello domanda di scansione e limite della velocità di scansione. Vale la precisazione permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi; non sarà completa o accurata al 100 %».

Dal settore

• La serie Crawling December di Google (ufficiale, ma il miglior insieme concentrato di spiegazioni sul crawling, inclusa la navigazione sfaccettata).
• Google spiega cosa significa “crawl budget” per i webmaster (Barry Schwartz, Search Engine Land, 2017) — un riepilogo in inglese semplice del post originale di Google sul crawl budget, utile per il contesto “most sites don’t need to worry” (traduzione) «la maggior parte dei siti non deve preoccuparsi».
• Gary Illyes spiega la differenza tra crawl budget, programmazione e carico dell’host (Search Engine Roundtable) — la fonte dell’inquadramento del “bucket in ordine di importanza” / carico dell’host, che mostra che si tratta di una coda prioritaria, non di una quota fissa.
• Google: 100.000 URL di solito non influenzano il crawl budget (Search Engine Roundtable, 2021) — il riferimento concreto di Mueller ai 100k e il contesto di <1/minuto su 3 mesi.
• Le priorità di scansione di Google: analisi dell’analista Gary Illyes (Search Engine Journal) — tratta la smentita della “quota giornaliera fissa di pagine” e l’idea di convincere la ricerca che valga la pena recuperare i contenuti.
• I cinque cancelli infrastrutturali dietro scansione, rendering e indicizzazione (Search Engine Land) — fonte della frase di Fabrice Canel “Less is more” e della filosofia di Bing sulla crawl efficiency.
• Serie bingbot: ottimizzare la frequenza di scansione (Bing Webmaster Blog, Fabrice Canel) — come Bing decide la cadenza delle nuove scansioni, complemento alla serie sulla massimizzazione della crawl efficiency.
• r/TechSEO — la community per il debugging della scansione e dell’indicizzazione.

Dati statistici da citare

• 100k URL di solito non bastano per farlo contare. Il riferimento concreto di John Mueller: “100k URLs is usually not enough to affect crawl budget (it’s <1/minute over 3 months).” (traduzione) «Centomila URL, in genere, non sono sufficienti a incidere sul crawl budget: equivalgono a meno di uno al minuto in tre mesi». È il numero più utile per ridimensionare la preoccupazione sul crawl budget. Fonte
• Le soglie a partire dalle quali inizia a contare: oltre 1 milione di pagine che cambiano circa ogni settimana oppure oltre 10 000 pagine che cambiano ogni giorno (stime approssimative di Google, non soglie esatte). Fonte
• Circa il 60 % del web è contenuto duplicato — una stima interna di Google, motivo per cui gli URL duplicati sono uno spreco così affidabile di crawl budget. Fonte

Il KPI permanente per la crawl efficiency

Il crawl budget non è un numero che Google ti consegna: lo deduci da dove Googlebot spende effettivamente le sue richieste. Il KPI è la ripartizione: quanta scansione finisce sulle pagine che vuoi indicizzare rispetto alle pagine che sono puro spreco. (Prima, il controllo di onestà: conta solo su scala — Google dice che il crawl budget è una preoccupazione soprattutto per siti intorno a 1M+ pagine o per siti medi che generano molti URL automatici. Un piccolo sito statico può ignorare del tutto questa metrica.)

Allocazione della scansione — richieste preziose e sprecate

• Metrica — La quota delle richieste di Googlebot verificato che colpiscono URL importanti e indicizzabili rispetto a quelli sprecati (duplicati, URL con parametri/facet, varianti non canonical, passaggi di redirect, 4xx/5xx).
• Cosa indica — Se la tua capacità di scansione viene spesa su pagine che possono posizionarsi. Una quota sprecata in aumento è un indicatore anticipatore del ritardo nella scoperta/indicizzazione prima che compaia come problema di ranking.
• Come recuperarla — Passa i log del server attraverso il Log File Analyzer e segmenta gli accessi di Googlebot verificato per classe di URL; confronta il risultato con il report Statistiche di scansione di GSC (richieste totali, per risposta, per finalità del file e stato dell’host).
• Benchmark / intervallo realistico — Situazionale: non esiste una “percentuale di spreco” universale onesta, perché dipende dall’architettura degli URL. Stabilisci la tua baseline e riduci nel tempo la quota sprecata; il segnale è l’andamento, non un assoluto inventato.
• Cadenza — Mensile e più spesso subito dopo un cambiamento strutturale (nuove facet, una migrazione) o quando Statistiche di scansione mostra un picco improvviso nelle richieste o nelle risposte 4xx/5xx. Lo spreco di scansione è una metrica anticipatrice; i conteggi delle pagine indicizzate sono ritardati.

Cronologia modifiche