Il crawl budget è uno di quei concetti SEO che vengono spesso citati nei convegni ma raramente compresi davvero. Eppure nel 2026 la sua importanza è cresciuta in modo esponenziale per una ragione che pochissimi imprenditori conoscono: l’esplosione dei crawler AI che stanno consumando enormi quantità di risorse server, mettendo in difficoltà la normale attività di scansione di Googlebot. In questo articolo ti spiego cos’è il crawl budget, come funziona oggi il sistema di scansione di Google, come gestire l’invasione dei nuovi crawler AI come GPTBot, ClaudeBot e PerplexityBot, quali sono le novità tecniche del 2026 che ogni SEO deve conoscere e quali interventi concreti puoi mettere in atto per ottimizzare le risorse di scansione del tuo sito.
Cos’è il crawl budget
Il crawl budget, in italiano “budget di scansione”, indica la quantità di risorse che Google decide di dedicare alla scansione delle pagine di un sito web in un determinato periodo di tempo. È il numero di URL che il motore di ricerca è disposto a visitare e analizzare giorno per giorno.
La definizione ufficiale di Google è netta: “il budget di scansione è il numero di URL che Googlebot può e vuole sottoporre a scansione”. Le due parole chiave qui sono “può” e “vuole”, che corrispondono ai due fattori che determinano il crawl budget di ogni sito.
Senza scansione non c’è indicizzazione, senza indicizzazione non c’è posizionamento, senza posizionamento non c’è traffico organico. Il crawl budget è quindi il primo gradino della catena che porta alla visibilità su Google, e se quel gradino è instabile tutto il resto ne risente.
Va detto subito che il crawl budget non è una preoccupazione per tutti i siti. Se gestisci un blog con qualche decina di pagine o un piccolo sito vetrina, Google ha risorse più che sufficienti per scansionare tutto regolarmente. Il crawl budget diventa un problema operativo solo per siti grandi (oltre le 10.000 pagine) o per portali con contenuti che cambiano molto frequentemente.
Crawl Rate e Crawl Demand: i due pilastri del crawl budget
Il crawl budget di Google è il risultato dell’incrocio tra due variabili: quanto velocemente Googlebot può scansionare il sito e quanto interesse il sito genera nel motore di ricerca.
Il Crawl Rate Limit
Il Crawl Rate Limit è il limite tecnico che Googlebot impone alle proprie richieste per non mettere sotto stress il server del sito. È una misura di prudenza: se il bot si accorgesse di rallentare significativamente il sito, ridurrebbe automaticamente la frequenza delle proprie visite.
Il Crawl Rate dipende da diversi fattori:
- la velocità di risposta del server alle richieste di Googlebot;
- la presenza o assenza di errori 5xx durante la scansione;
- la stabilità complessiva dell’infrastruttura hosting;
- la banda disponibile al server in caso di traffico contemporaneo;
- impostazioni specifiche dichiarate dal sito come gli
Retry-Afterheader.
Tradotto in pratica: più il sito è veloce e stabile, più Google è disposto a scansionarlo intensamente. Un sito lento o instabile riceverà meno visite del bot, con conseguente rallentamento dei tempi di indicizzazione dei nuovi contenuti.
Il Crawl Demand
Il Crawl Demand è la “richiesta di scansione” che Google esprime verso un sito. È sostanzialmente l’interesse del motore di ricerca a venire a vedere cosa c’è di nuovo. Dipende da:
- la popolarità generale del sito;
- la frequenza di aggiornamento dei contenuti esistenti;
- la pubblicazione di nuovi contenuti freschi;
- la qualità complessiva percepita del dominio;
- la rilevanza tematica dei contenuti rispetto alle query di interesse.
Un sito che pubblica costantemente contenuti di valore e ottiene engagement reale dagli utenti genera un crawl demand elevato, indipendentemente dalle sue dimensioni. Al contrario, un sito statico con contenuti obsoleti vede progressivamente ridurre la frequenza delle scansioni, anche se la sua infrastruttura tecnica è perfetta.
La grande novità del 2026: AI Overviews usano lo stesso index di Googlebot
Prima di parlare delle nuove sfide del crawl budget nel 2026, devo chiarire un equivoco molto diffuso. Molti pensano che AI Overviews e AI Mode di Google operino su un index separato rispetto alla ricerca tradizionale. Non è così.
Google ha confermato ufficialmente nei suoi documenti tecnici che AI Overviews e tutte le funzionalità AI generative all’interno della ricerca attingono allo stesso indice popolato da Googlebot Smartphone. Non esistono crawler dedicati all’AI di Google, non esiste un database separato.
Questo ha una conseguenza operativa enorme: se Googlebot non riesce a scansionare correttamente il tuo sito, i tuoi contenuti non saranno disponibili nemmeno per le risposte AI di Google. Ottimizzare il crawl budget non serve quindi solo a migliorare il posizionamento classico, ma è anche il prerequisito assoluto per essere citati negli AI Overviews.
Nota: contrariamente a quanto molti credono, i crawler “AI” di Google come GoogleOther non influenzano direttamente i ranking della ricerca. Sono crawler usati per scopi interni e di ricerca, e la loro presenza nei log del server non ha implicazioni dirette sul posizionamento. L’unica vera porta di ingresso che conta è Googlebot Smartphone, che alimenta tutti i sistemi di ranking compresi quelli basati su AI.
L’invasione dei crawler AI: il problema nuovo del 2026
Qui arriviamo al tema più importante e meno discusso. Nel 2026 il crawl budget non è più una questione che riguarda solo Googlebot. Decine di nuovi crawler AI sono apparsi e stanno consumando enormi quantità di risorse server in cambio di benefici molto variabili.
I principali crawler AI che oggi visitano la maggior parte dei siti web sono:
- GPTBot di OpenAI, che alimenta ChatGPT;
- ChatGPT-User, sempre OpenAI, per il browsing in tempo reale;
- ClaudeBot di Anthropic, per addestrare Claude;
- PerplexityBot, che alimenta il motore di ricerca Perplexity;
- Google-Extended, token che controlla l’uso dei contenuti per Gemini;
- Bytespider di ByteDance (TikTok), particolarmente aggressivo;
- CCBot di Common Crawl, alimenta i dataset di addestramento AI;
- Amazonbot, per i servizi AI di Amazon.
Il problema non è solo la quantità: questi crawler possono consumare bandwidth per migliaia di euro al mese sui siti di grandi dimensioni, e quando saturano le risorse server, Googlebot stesso vede ridurre la propria capacità di scansione.
I dati di settore del 2026 mostrano scenari preoccupanti: per molti siti editoriali e di contenuti, il traffico generato dai crawler AI supera quello degli utenti umani. È una situazione completamente nuova che richiede un approccio strategico.
Come gestire i crawler AI nel 2026
Di fronte all’invasione dei crawler AI, le opzioni operative sono tre, ognuna con pro e contro che vanno valutati in base alla strategia complessiva del sito.
Permettere tutto
Lasciare aperto l’accesso a tutti i crawler AI massimizza le possibilità che i contenuti vengano citati nelle risposte generative. È la scelta che fa visibilità sui motori AI ma comporta:
- costi di banda anche molto elevati;
- contenuti utilizzati per addestrare modelli AI commerciali senza compenso;
- possibile rallentamento delle scansioni di Googlebot per saturazione risorse.
Bloccare tutto
Bloccare tutti i crawler AI tramite robots.txt protegge banda e contenuti ma elimina la possibilità di essere citati nelle risposte generative. Per molti siti questa è una scelta troppo radicale, perché significa rinunciare a una quota crescente di visibilità.
Gestione selettiva (la strategia consigliata)
La strategia che applico nei progetti dei clienti è la gestione selettiva: permettere i crawler che generano effettivi ritorni in termini di traffico e citazioni, limitare quelli a basso valore, bloccare quelli aggressivi e inutili. Un esempio concreto di configurazione robots.txt nel 2026:
User-agent: GPTBot
Allow: /
Crawl-delay: 2
User-agent: ChatGPT-User
Allow: /
User-agent: Google-Extended
Allow: /
User-agent: ClaudeBot
Allow: /
Crawl-delay: 5
User-agent: PerplexityBot
Allow: /
Crawl-delay: 10
User-agent: Bytespider
Disallow: /
User-agent: CCBot
Disallow: /
Questa configurazione permette i crawler che generano valore (ChatGPT, Gemini, Claude, Perplexity) con limiti di frequenza progressivi, e blocca quelli aggressivi senza un ritorno chiaro. Il risparmio di banda può arrivare al 75% mantenendo la visibilità sui principali motori generativi.
Nota: il file robots.txt è una direttiva e non un blocco effettivo. Alcuni crawler ignorano deliberatamente queste indicazioni. Per i siti con esigenze critiche di protezione, è necessario combinare robots.txt con regole di blocco a livello CDN o firewall applicativo.
Il nuovo standard del 2026: il file llms.txt
Tra gli sviluppi tecnici più interessanti del 2026 c’è l’affermazione del file llms.txt, un nuovo standard pensato specificamente per comunicare con i modelli linguistici di grandi dimensioni. Funziona in modo simile a robots.txt ma con un focus diverso.
Mentre robots.txt dice ai crawler cosa possono o non possono visitare, llms.txt dice ai modelli AI quali contenuti rappresentano le fonti più autorevoli e aggiornate del sito su determinati argomenti. Permette ai modelli di andare direttamente al cuore delle informazioni senza dover scansionare centinaia di pagine.
L’effetto sul crawl budget è importante: un llms.txt ben strutturato riduce il consumo di risorse dei crawler AI guidandoli verso le pagine prioritarie. Per i siti di dimensioni medio-grandi è uno strumento ormai indispensabile.
Il limite dei 2,3 MB e perché conta
Un’altra novità tecnica rivelata da Google a marzo 2026 ha sorpreso molti SEO: Googlebot ha un limite di fetch attorno ai 2,3 MB per pagina. Questa è la mediana del peso delle homepage mobile nel 2026, e si avvicina pericolosamente al limite di troncamento del crawler.
Cosa succede quando una pagina supera quel limite? Le parti finali del codice HTML possono essere ignorate da Googlebot, con conseguenze potenzialmente serie:
- contenuti importanti che non vengono indicizzati;
- dati strutturati posizionati in fondo al codice ignorati;
- link interni in fondo alla pagina non seguiti;
- esclusione dalle considerazioni per gli AI Overviews.
La raccomandazione pratica è chiara: i contenuti essenziali devono apparire nelle prime porzioni del codice HTML, prima possibile, in modo da essere sempre catturati anche in caso di troncamento. I dati strutturati vanno collocati nell’head o subito dopo l’apertura del body, non in coda.
Va anche prestata attenzione al peso complessivo delle pagine, riducendo CSS e JavaScript non necessari e ottimizzando le immagini. Per un’analisi approfondita delle metriche di performance che impattano sul crawl, ho scritto un articolo sui Core Web Vitals che spiega cosa controllare e come ottimizzarli.
Mobile-first indexing: ormai unico paradigma operativo
Una conferma importante del 2026 è che il mobile-first indexing è ormai l’unica realtà operativa. A partire da luglio 2024 Google ha smesso di indicizzare i siti non ottimizzati per mobile, e Googlebot Desktop appare ormai solo in casi marginali nei log dei server.
Questo significa che tutto il sistema di crawl budget si basa sulla versione mobile del sito. Se la tua versione mobile è incompleta, mal strutturata o difforme da quella desktop, è quella incompleta che Google scansiona e indicizza. Non c’è più alcun fallback alla versione desktop.
Le conseguenze pratiche per chiunque gestisca un sito sono:
- la versione mobile deve essere identica a quella desktop per contenuti e link;
- tutti i dati strutturati devono essere presenti su mobile;
- le performance mobile sono determinanti per il crawl rate;
- i test devono essere fatti con il Mobile-Friendly Test di Google.
Come ottimizzare il crawl budget nella pratica
Una volta capito come funziona il sistema, vediamo gli interventi concreti che producono risultati misurabili sul crawl budget. Ti presento la sequenza che applico nei progetti dei clienti, dall’analisi alle azioni correttive.
Pulizia degli URL inutili
Il primo passo è capire cosa Google sta sprecando tempo a scansionare senza ritorno. Le tipologie di URL che drenano crawl budget senza generare valore sono:
- contenuti duplicati con parametri URL diversi;
- pagine di filtro di e-commerce con infinite combinazioni;
- pagine di paginazione profonda senza valore aggiunto;
- tag e categorie di blog con pochi contenuti;
- URL di sviluppo o staging accidentalmente esposti;
- contenuti obsoleti mai più aggiornati.
Su tutti questi URL conviene applicare strategie di esclusione: noindex per quelli che devono restare accessibili ma non indicizzati, redirect 301 per quelli sostituiti da altri, disallow su robots.txt per quelli da non scansionare proprio.
Ottimizzazione di sitemap.xml
Una sitemap ben curata indirizza Googlebot direttamente verso le pagine importanti, riducendo gli sprechi. Per essere efficace deve:
- contenere solo URL canonici, mai versioni con parametri o duplicati;
- essere aggiornata regolarmente con nuove pubblicazioni e rimozioni;
- specificare correttamente le date di lastmod delle pagine modificate;
- essere suddivisa in più file se supera i 50.000 URL;
- essere dichiarata in Search Console e linkata nel robots.txt.
Miglioramento dell’architettura interna
Un’architettura piatta con tante pagine isolate ostacola la scansione, mentre una struttura gerarchica ben costruita la facilita. Le regole d’oro restano due: ogni pagina importante deve essere raggiungibile in massimo 3 clic dalla home, e i link interni devono essere strutturati in modo tematicamente coerente.
Velocità del server
Un server veloce permette a Googlebot di scansionare più pagine nel tempo a disposizione. Tempi di risposta sotto i 200 millisecondi sono l’obiettivo da puntare per i siti che vogliono massimizzare il crawl budget. Hosting condivisi economici sono spesso il collo di bottiglia di tutto il sistema.
Gestione corretta degli errori
Gli errori 404 e 5xx in quantità anomala segnalano a Google problemi del sito e portano alla riduzione del crawl rate. Un monitoraggio sistematico tramite Search Console e correzione tempestiva degli errori è quindi parte integrante di una buona gestione del crawl budget.
L’analisi dei file di log: il metodo definitivo
Il modo più preciso per capire come Googlebot e gli altri crawler stanno usando le risorse del tuo sito è l’analisi dei file di log del server. Sono i registri che documentano ogni singola richiesta ricevuta, distinguendo bot da utenti umani.
Dall’analisi dei log si possono ricavare informazioni preziose:
- quali pagine sono più scansionate e quali completamente ignorate;
- quanto tempo Googlebot dedica a URL inutili;
- quali pagine generano errori ricorrenti durante la scansione;
- se ci sono spike anomali di scansione che indicano problemi;
- quanto pesano i crawler AI rispetto a Googlebot.
Lo strumento che uso da anni per questo tipo di analisi è Screaming Frog Log File Analyser. Permette di importare i log del server e analizzarli con filtri per user-agent, IP, codici di stato, periodi temporali, generando grafici e report che facilitano enormemente l’individuazione dei problemi. Su questo strumento ho dedicato un articolo specifico: se vuoi capire in dettaglio come configurarlo e usarlo al meglio, la mia guida completa a Screaming Frog Log Analyser ti accompagna passo passo.
Quando il crawl budget non è il problema
Un’osservazione importante per concludere. Negli anni mi è capitato spesso di sentire imprenditori preoccupati per il “crawl budget” del loro piccolo sito vetrina di 30 pagine. È una preoccupazione fuori luogo.
Per la stragrande maggioranza dei siti web, il crawl budget non rappresenta un problema operativo reale. Google ha abbondanti risorse per scansionare:
- siti vetrina e portali aziendali sotto le 1.000 pagine;
- blog professionali sotto i 5.000 articoli;
- e-commerce di piccole dimensioni sotto i 10.000 prodotti;
- siti istituzionali con aggiornamenti settimanali.
Il crawl budget diventa una preoccupazione strategica quando si parla di e-commerce con cataloghi enormi, portali editoriali con decine di migliaia di articoli, marketplace con inventari dinamici, siti con generazione automatica di pagine. Per tutti gli altri, le energie SEO sono meglio investite altrove: nella qualità dei contenuti, nella struttura del sito, nell’esperienza utente.
Risorse di scansione, AI e futuro dell’indicizzazione
Abbiamo visto cos’è il crawl budget e perché conta, come funzionano i due pilastri Crawl Rate e Crawl Demand, perché nel 2026 i contenuti per AI Overviews passano dallo stesso index di Googlebot e quindi una buona scansione è prerequisito per la visibilità generativa, come gestire l’invasione dei nuovi crawler AI con strategie selettive, perché il file llms.txt è diventato un nuovo standard utile, qual è il limite tecnico dei 2,3 MB rivelato di recente, come ottimizzare concretamente il crawl budget con interventi su URL, sitemap, architettura, velocità, errori, e perché l’analisi dei file di log resta il metodo definitivo per capire cosa sta succedendo davvero sul sito.
Il messaggio chiave da portare a casa è semplice: nel 2026 il crawl budget non è più solo una questione SEO, è diventato un tema di gestione strategica delle risorse digitali. Tra crawler tradizionali, crawler AI in esplosione, costi di banda crescenti e nuovi limiti tecnici, chi gestisce siti di grandi dimensioni non può più ignorare questo aspetto. Per i piccoli siti resta una questione marginale; per quelli grandi è diventata una delle priorità operative dell’anno.
