Crawl Budget: Quando Conta Veramente (e Quando No)

Cercate “crawl budget” e la pagina dei risultati vi fa fare una piccola commedia. Il primo risultato organico è la documentazione ufficiale di Google, che inizia dicendo alla maggior parte dei lettori di chiudere la scheda: se il vostro sito ha meno di qualche migliaio di URL, sarà sottoposto a crawling in modo efficiente, e non c’è nulla qui per voi da ottimizzare. Ogni guida classificata sotto di essa insegna a quei stessi lettori a ottimizzarla comunque — potate il vostro blog di 40 pagine, bloccate il vostro CSS, preoccupatevi di un “budget” che non potreste esaurire nemmeno se lo provaste. Il risultato è una generazione di piccoli proprietari di siti che fanno interventi chirurgici su crawl budget su siti che Google non ha mai avuto difficoltà a sottoporre a crawling, a volte tagliando cose che stavano effettivamente aiutando.

Questa guida crede alla parola di Google. Il crawl budget è reale, ha un’importanza enorme — per una classe specifica di sito — e per quella classe ci sono esattamente quattro leve che vale la pena azionare: eliminare le crawl trap, correggere i link interni, l’igiene della sitemap e la salute del server, diagnosticate dai Crawl Stats e dai log del server piuttosto che da sensazioni. Per tutti gli altri, la risposta onesta è che il vostro problema è quasi certamente qualcosa di più economico da risolvere. Questo è il livello di crawling del nostro pilastro SEO agentico, e un complemento alla guida più ampia di audit tecnico SEO — la stessa regola si applica qui come lì: nessuna correzione è fatta fino a quando Search Console non dice che ha fatto qualcosa.

Cosa è veramente il crawl budget

Il crawl budget non è una quota che Google vi assegna come un piano telefonico. È l’intersezione di due forze che Google documenta esplicitamente. La prima è il limite di capacità di crawl: la velocità massima con cui Googlebot recupererà le vostre pagine senza danneggiare il vostro server. È elastico — rispondete rapidamente e in modo sano e il limite aumenta; rispondete lentamente, o con errori del server, e Googlebot si ritira. La vostra infrastruttura fissa questo massimale, non il vostro SEO.

Il secondo è la domanda di crawl: quanto Google vuole sottoporre a crawling il vostro sito, guidato da quanti URL conosce, da quanto sono popolari e da quanto vecchie sono diventate le sue copie. Un sito che pubblica quotidianamente e riceve link costruisce la domanda; un sito di mille pagine statiche che non cambiano mai non ha bisogno di ricrawling, e Google non sprecherà le visite. Il crawl budget è quello dei due che si esaurisce per primo — e questo è il dettaglio che le guide di panico saltano: per un sito piccolo,nessuno dei due si esaurisce mai. Il limite di capacità non viene mai avvicinato e la domanda è facilmente soddisfatta. Non c’è un budget da ottimizzare perché nulla viene razionato.

Quando il crawl budget conta veramente: le soglie di Google

La guida per grandi siti sulla crawl budget di Google nomina il suo pubblico in numeri, che quasi nessuno cita perché i numeri escludono quasi tutti. La guida è scritta per siti con oltre un milione di pagine univoche il cui contenuto cambia settimanalmente, o oltre diecimila pagine univoche il cui contenuto cambia quotidianamente — più un caso basato sui sintomi: siti in cui Search Console classifica una grande percentuale di URL come “Scoperto — attualmente non indicizzato,” il che significa che Google sa che le pagine esistono e ha scelto di non recuperarle ancora. Il post del 2017 sulla crawl budget di Googlebot dal team di ricerca di Google abbassa ancora il minimo: poche migliaia di URL o meno, sottoposti a crawling in modo efficiente, nulla di cui preoccuparsi — e se le vostre nuove pagine tendono a essere sottoposte a crawling lo stesso giorno in cui le pubblicate, smettete di leggere.

Chi supera davvero la barra? Cataloghi di e-commerce con navigazione sfaccettata, annunci e job board con alto turnover di annunci, editori con archivi profondi e output quotidiano, e qualsiasi piattaforma che genera pagine a livello di codice — una matrice locale × categoria × filtro si compone in milioni di URL rapidamente. Il filo conduttore non è il numero di pagine grezzo ma lo spazio URL che cresce più velocemente della value. Un sito di 500 pagine con percorsi puliti non ha un problema di crawl budget per definizione. Un negozio di 50.000 prodotti i cui filtri generano un nuovo URL per combinazione può affamare le sue pagine di denaro mentre Googlebot vaga per la combinatoria.

Il panico del piccolo sito, confutato

Il manuale del panico è riconoscibile al primo sguardo: un blog di 200 pagine che blocca il suo CSS e JS per “risparmiare budget,” indicizzando la paginazione, disabilitando le pagine di categoria, potando i post che stavano tranquillamente guadagnando clic a coda lunga. Ognuno di questi movimenti ha un costo reale e nessuno ha un beneficio di crawl a quella scala. Bloccare le risorse di rendering rende le pagine più difficili da valutare per Google. E il trucco noindex non fa nemmeno quello che i suoi utenti pensano: Googlebot deve sottoporre a crawling una pagina per vedere il tag noindex, quindi non risparmia nessun crawl — la documentazione sulla crawl budget di Google lo dice apertamente.

Quando le pagine di un sito piccolo non vengono indicizzate, il vincolo è quasi mai il crawl budget. È la domanda di crawl — Google ha recuperato la pagina, l’ha valutata, e ha rifiutato. Questo è un problema di qualità e rilevanza che indossa i vestiti di un problema di impianto idraulico.

La distinzione è importante perché i due problemi hanno correzioni opposte. Un problema di budget viene risolto con la sottrazione: meno URL spazzatura in competizione per i recuperi. Un problema di domanda viene risolto con l’addizione: pagine più forti, veri link interni, prove che il contenuto vale la pena di archiviare. Il piccolo proprietario di sito che pota e blocca sta applicando la cura per grandi siti alla malattia dei piccoli siti — e se quello che viene effettivamente razionato è l’attenzione in una pagina dei risultati mediata da AI piuttosto che i recuperi di Googlebot, la soluzione si trova nel territorio del SEO zero-click, non in robots.txt.

Diagnosticate prima di ottimizzare: Crawl Stats e log del server

Se potreste davvero avere un problema di crawl budget, la diagnosi è osservabile — nessuno dovrebbe ottimizzare il crawl per intuizione. Il report Crawl Stats di Search Console (sotto Impostazioni, facile da perdere) è il primo strumento gratuito: richieste di crawling totali su 90 giorni, tempo di risposta medio e tre analisi che portano la maggior parte del segnale. Per risposta — una quota significativa di recuperi trascorsa su 404, redirect o errori del server è un budget bruciato per nulla. Per scopo — scoperta rispetto aggiornamento ti dice se Google sta trovando nuovi URL o rileggendo i vecchi. Per tipo di file — migliaia di recuperi di rifiuti parametrizzati si mostrano qui prima di apparire da qualche altra parte.

I log del server sono il secondo strumento, e oltre una certa dimensione quello decisivo: l’unico record di ogni URL che Googlebot ha effettivamente richiesto, non un campione. La domanda da porre ai log è brutale e semplice — quale percentuale delle richieste di Googlebot colpisce URL che voglio indicizzare? Su grandi siti la risposta è di routine una minoranza. Su un sito che abbiamo sottoposto a audit, il crawl era dominato da URL di combinazione di filtri che nessun ricercatore avrebbe mai voluto, mentre le pagine di prodotto genuinamente nuove sono rimaste non scoperte per settimane — il problema di crawl budget in una frase: Google ha lavorato duramente e recuperato le cose sbagliate.

Le quattro leve che spostano veramente il crawl budget

Per siti oltre le soglie, quattro leve fanno quasi tutto il lavoro, in ordine decrescente di impatto. Ognuna dovrebbe lasciare la diagnosi come un compito con una metrica impegnata in anticipo — lo stesso contratto di prova che ogni correzione porta in un sistema SEO a circuito chiuso.

Uccidere le crawl trap

Una crawl trap è uno schema qualsiasi che genera URL più velocemente di quanto possano portare valore: navigazione sfaccettata che trasforma ogni combinazione di filtri in un indirizzo, ID di sessione e parametri di tracciamento nei link interni, paginazione infinita del calendario e ordini di ordinamento che duplicano un’intera categoria con una nuova stringa di query. L’elenco stesso di Google dei tipi di URL che sprecano crawl è guidato esattamente da questi. La gerarchia di correzione: smettete di generare gli URL dove possibile, smettete di collegarvi a loro dove no, e disabilitate i modelli residui in robots.txt — che, a differenza di noindex, previene effettivamente il recupero. Una trappola a livello di template supera in peso mille pagine potate individualmente.

Correggere i link interni

La domanda di crawl segue i link. Le pagine sepolte cinque clic in profondità, o raggiungibili solo attraverso la sitemap, vengono sottoposte a crawling tardi e raramente; le pagine orfane si offrono efficacemente di essere dimenticate. La leva è architettonica, non cosmetica: pagine importanti a pochi clic dalla home page, pagine hub che concentrano i link interni su quello che dovrebbe classificarsi, e nessun link interno che punta a redirect, URL morti o duplicati parametrizzati — ogni tale link è un’istruzione a Googlebot di spendere un recupero per nulla.

Igiene della sitemap

La sitemap è una dichiarazione di quello che volete sottoposto a crawling, e la maggior parte dei grandi siti la lascia marcire in una bugia: annunci scaduti, URL reindirizzati, pagine noindexate, duplicati sottili. Una sitemap che Google ha imparato a non fidarsi smette di essere un segnale di scoperta utile. Lo standard è rigoroso — URL canonico, indicizzabile, solo stato 200, con valori lastmod accurati, in modo che una pagina modificata sia un invito di ricrawl e una invariata no. Su siti generati, questo è un’unica correzione di template, non un progetto editoriale.

Salute del server e velocità di risposta

La leva che tutti dimenticano perché appartiene a un team diverso: il limite di capacità di crawl è impostato dal comportamento del vostro server. Le risposte lente sostenute lo riducono; errori 5xx e 429 fanno sì che Googlebot si ritiri completamente — Google documenta entrambi. Risposte più veloci alzano il massimale su ogni altra leva. Qui è anche dove vivono le catene di redirect e i soft 404: ogni hop in una catena è un recupero separato, e un soft 404 è il peggio di entrambi i mondi — budget speso e un segnale di bassa qualità registrato.

Repo-first: le crawl trap sono scritte nel codice

Ecco quello che le guide crawl-first mancano strutturalmente: ogni crawl trap è poche righe di codice sorgente. La trappola di navigazione sfaccettata è un gestore di percorsi che accetta combinazioni di parametri arbitrarie e un template che si collega a loro. Il calendario infinito è un componente di paginazione senza limite superiore. La sitemap marcita è un generatore di sitemap che interroga il set sbagliato. Un crawler vi mostra centomila URL sintomatici; il repository vi mostra i cinque file che li generano — e il diff che lo ferma. Se voi o il vostro agent potete leggere la codebase, l’audit di crawl budget è principalmente letture di file, esattamente come sostenuto nel metodo di audit repo-first.

Il repository è anche dove la correzione diventa esaustiva invece di statistica. Potare gli URL spazzatura da un export di crawl tratta i sintomi uno alla volta; cambiare il template che li genera tratta ogni istanza attuale e futura in un unico commit. Questa asimmetria è il motivo per cui un agent che lavora all’interno della codebase effettiva — leggendo percorsi, modificando template, aprendo un PR — batte un dashboard che esporta i risultati affinché qualcun altro li interpreti.

Verificatelo: nessuna correzione di crawl è fatta finché Crawl Stats non dice così

Il lavoro di crawl budget ha una proprietà che la maggior parte dell’SEO manca: feedback insolitamente veloce, insolitamente diretto. Bloccate un modello di trappola e il mix di recupero in Crawl Stats cambia nel giro di giorni — potete guardare la percentuale spazzatura cadere e la media del tempo di risposta migliorare. Questo lo rende indifendibile saltare la verifica qui, e tuttavia il playbook standard lo fa: la modifica robots.txt va in diretta, il ticket si chiude, e nessuno legge il report che mostrerebbe se il comportamento di Googlebot ha effettivamente cambiato.

Il flusso di lavoro onesto impegna la metrica prima della correzione, in due fasi. La fase uno, meccanica: il segnale Crawl Stats dalla tabella sopra — il crawl si è effettivamente redistribuito? La fase due, quella che giustifica il lavoro: le pagine che erano affamate di crawl hanno iniziato a guadagnare impressioni? Quella seconda lettura ha bisogno di circa tre settimane di dati di Search Console, la stessa fisica di ogni verdetto nella disciplina di movimento causale verificato — e mantiene gli obiettivi onesti, perché un crawl che si è redistribuito senza alcuna pagina che guadagni visibilità è un interessante nullo, non una vittoria.

Eseguite questo come una board piuttosto che come un progetto e il loop si chiude da solo: la trappola atterra come un compito con il suo impatto atteso e verifica della metrica, il link PR registra esattamente quello che è andato in diretta, e il monitor settimanale legge Search Console e scrive il verdetto. Il crawl budget smette di essere un argomento folclorico e diventa quello che dovrebbe essere sempre stato — un vincolo misurabile che vincola il vostro sito o no, con la risposta nei dati piuttosto che in un post di blog scritto per un sito mille volte più grande del vostro.

Il modo più veloce per scoprire da che parte della soglia siete è guardare i vostri stessi numeri. Un report SEO gratuito collega il vostro Search Console e mostra dove siede il vero vincolo — pagine che Google non sta mostrando, pagine mostrate ma mai scelte, e se il crawl è da qualche parte su quella lista. E se è così, e preferiremmo che l’intero loop si eseguisse da solo — le trappole trovate nel sorgente, le correzioni inviate come PR, i verdetti letti da Crawl Stats e impressioni — prenotate una chiamata e vi mostreremo la board che fa esattamente questo.