C'è un voce di costo che pochi SEO leggono e che oggi pesa più di prima: la quantità di richieste che i bot fanno al tuo server. Negli ultimi mesi, su molti siti italiani di medie dimensioni i crawler degli assistenti AI — GPTBot, ClaudeBot, PerplexityBot, Google-Extended e Amazonbot — hanno superato in volume Googlebot stesso. Su un e-commerce con cataloghi profondi non è raro trovare nei log che oltre un terzo delle richieste automatizzate non arriva più dal motore che ti porta traffico, ma da modelli che addestrano o citano i tuoi contenuti senza inviarti quasi nessun click. Questo cambia il calcolo del crawl budget, e ignorarlo significa lasciare che pagine importanti vengano scansionate meno spesso di quelle inutili.
La domanda da porsi non è più solo "Google indicizza tutto?", ma "il mio server sta spendendo risorse di scansione dove serve, o le sta bruciando su URL parametrici e bot che non ricambiano?".
Cos'è davvero il crawl budget (e quando conta)
Il crawl budget è la combinazione di due fattori che Google definisce da anni: il crawl rate limit (quante richieste il tuo server tollera senza degradare) e il crawl demand (quanto Google desidera scansionare le tue URL, in base a popolarità e freschezza). Per un sito da poche centinaia di pagine il crawl budget non è un problema: Googlebot le visita tutte senza fatica. Diventa critico sopra le 10.000 URL indicizzabili, o quando hai molte pagine generate dinamicamente — filtri di categoria, ordinamenti, calendari, ricerche interne.
Il segnale d'allarme classico è il divario tra pagine "scoperte ma non indicizzate" e pagine effettivamente in indice nella Search Console. Quando quel numero cresce e i tempi di indicizzazione di contenuti nuovi si allungano da ore a giorni, il crawl budget è quasi sempre la causa. E i bot AI, aggiungendo carico al server, possono abbassare indirettamente il crawl rate che Google si concede.
I bot AI: chi sono e come trattarli
Non tutti i bot vanno trattati allo stesso modo. Alcuni alimentano l'addestramento dei modelli, altri servono a recuperare in tempo reale i contenuti da citare in una risposta. La distinzione è strategica: bloccare il secondo gruppo significa rinunciare alle citazioni in ChatGPT, Perplexity o nelle AI Overviews.
| Bot | Operatore | Funzione | Vale la pena permetterlo? |
|---|---|---|---|
| Googlebot | Indicizzazione classica | Sempre | |
| Google-Extended | Training Gemini / AI | Dipende dalla strategia GEO | |
| GPTBot | OpenAI | Training modelli | Solo se vuoi contribuire al training |
| OAI-SearchBot | OpenAI | Citazioni in ChatGPT Search | Sì, se punti alle citazioni |
| ClaudeBot | Anthropic | Training / fetch | Valutare per dominio |
| PerplexityBot | Perplexity | Indicizzazione e citazioni | Sì, genera traffico reale |
| Amazonbot | Amazon | Alexa / assistenti | Spesso aggressivo, da limitare |
Il robots.txt resta lo strumento di controllo principale: la maggior parte di questi crawler dichiara di rispettarlo. Una configurazione sensata blocca i bot di puro training se non vuoi cedere contenuti, lascia passare quelli che generano citazioni, e applica un Crawl-delay ai più voraci. Attenzione però: robots.txt non è un firewall. Per i bot che lo ignorano serve un blocco a livello di server o CDN (regole su user-agent in Cloudflare, Fastly o nginx).
Leggere i log: l'unico dato che non mente
Search Console ti mostra come Google vede il tuo sito, ma non ti dice quante richieste arrivano dagli altri. L'unica fonte di verità è l'analisi dei log del server. Esporta gli access log di almeno 30 giorni e segmenta le richieste per user-agent: vedrai immediatamente la proporzione tra Googlebot, bot AI e traffico umano, quali sezioni del sito assorbono più scansioni e quali pagine importanti vengono visitate raramente.
I pattern più comuni da individuare sono tre. Primo: Googlebot che spreca migliaia di richieste su URL con parametri di tracciamento o filtri sfaccettati — sintomo di un problema di architettura, non di budget. Secondo: bot AI che martellano lo stesso sottoinsieme di pagine ad alta frequenza, gonfiando il carico server. Terzo: pagine strategiche (categorie chiave, contenuti aggiornati di recente) con una frequenza di crawl bassissima rispetto al loro valore. Una volta che hai questi tre dati, sai esattamente dove intervenire.
Rendering JavaScript: il moltiplicatore di costo nascosto
Il crawl budget non riguarda solo quante URL vengono scansionate, ma quanto costa scansionarle. Una pagina che richiede rendering JavaScript per mostrare il contenuto principale impone a Google due passaggi: prima il download dell'HTML, poi il rendering nel Web Rendering Service, che avviene in una coda separata e con ritardo. Per un sito client-side rendering puro, questo significa indicizzazione più lenta e, in periodi di carico, contenuti che Google semplicemente non riesce a renderizzare in tempo.
Il punto critico nel 2026 è che i crawler AI sono molto meno capaci di Googlebot nel rendering. Diversi di essi non eseguono JavaScript del tutto: se il tuo contenuto compare solo dopo l'idratazione lato client, per GPTBot o PerplexityBot la pagina è di fatto vuota, e non verrai mai citato. È la ragione tecnica per cui il server-side rendering o il rendering statico sono tornati centrali: non per moda, ma perché sono l'unico modo per garantire che sia Google sia i modelli AI leggano il contenuto reale al primo passaggio.
Cosa fare in pratica
Tradurre tutto questo in interventi concreti significa lavorare su quattro fronti, in ordine di impatto.
Sul fronte architettura, gestisci i parametri URL con rel="canonical" coerenti, blocca via robots.txt le combinazioni di filtri che generano URL infinite e mantieni una sitemap XML pulita con solo le pagine indicizzabili e l'attributo lastmod aggiornato in modo affidabile — Google lo usa davvero per prioritizzare le ricrawl.
Sul fronte bot, decidi una policy esplicita per ciascun crawler AI invece di lasciare il robots.txt di default. Se l'obiettivo è apparire nelle risposte generative, lascia passare OAI-SearchBot e PerplexityBot e monitora se le citazioni aumentano; se temi solo il carico, applica rate limit a livello di CDN sui più aggressivi.
Sul fronte rendering, verifica con il test "Controllo URL" della Search Console che il contenuto chiave sia presente nell'HTML renderizzato, e dove possibile sposta verso SSR o generazione statica le pagine che oggi dipendono dal JavaScript per mostrare testo e link.
Sul fronte monitoraggio, imposta un'analisi dei log ricorrente — mensile è sufficiente per la maggior parte dei siti — così da accorgerti in tempo se la proporzione tra bot utili e bot inutili sta peggiorando.
Il takeaway
Il crawl budget è passato da preoccupazione di nicchia per soli siti enterprise a metrica che riguarda chiunque produca molte pagine o punti alle citazioni AI. La logica di fondo è semplice: ogni richiesta che il tuo server gestisce per un bot che non ti restituisce valore è una richiesta sottratta a Googlebot e ai crawler che ti citano. Apri i log, misura la proporzione reale, scrivi una policy bot consapevole e assicurati che il contenuto sia leggibile senza JavaScript. Sono interventi tecnici, poco visibili, ma sono esattamente il tipo di lavoro che separa un sito che viene scansionato bene da uno che resta indietro mentre l'indice — umano e artificiale — si muove sempre più in fretta.