Crawl Budget: guida tecnica completa all’ottimizzazione della scansione Google

Il crawl budget è uno dei concetti più fraintesi nella SEO tecnica. Google stessa ha chiarito la definizione ufficiale nel 2017 attraverso il post di Gary Illyes sul Webmaster Central Blog: il crawl budget non è un singolo numero, ma il risultato dell’interazione tra due componenti distinte — crawl rate limit e crawl demand. Nei siti enterprise che gestiamo con milioni di URL, la gestione efficiente del crawl budget può determinare la differenza tra un’indicizzazione completa in settimane o in mesi.

Questa guida approfondisce ogni aspetto tecnico del crawling budget: dall’architettura interna del crawler di Google alle strategie operative di ottimizzazione, passando per l’analisi dei log con Python e l’interpretazione dei dati in Google Search Console.

Definizione operativa di Crawl Budget

La definizione canonica proviene dal post “What Crawl Budget Means for Googlebot” pubblicato da Gary Illyes il 16 gennaio 2017 sul Google Webmaster Central Blog. In quel documento, Illyes definisce il crawl budget come:

“The number of URLs Googlebot can and wants to crawl.”

Questa formulazione è deliberatamente composta da due verbi: can (può, determinato dal crawl rate limit) e wants (vuole, determinato dal crawl demand). La distinzione è fondamentale perché indica che il crawl budget non dipende solo dalla capacità infrastrutturale del server, ma anche dalla percezione di valore che Google attribuisce agli URL del sito.

Nel 2020, durante un episodio di Google Search Off The Record, Gary Illyes ha ribadito che per la maggior parte dei siti sotto 10.000 URL il crawl budget non è un problema. Il crawl budget diventa un fattore critico quando il rapporto tra URL totali e URL di valore è sbilanciato — tipicamente in e-commerce con navigazione faceted, portali editoriali con archivi estesi, e siti con generazione dinamica massiva di URL.

Nota: Google ha aggiornato la documentazione ufficiale su Search Central nel 2022, integrando i concetti di crawl budget con quelli del rendering JavaScript e del crawling basato su HTTP/2. La documentazione attuale è disponibile su developers.google.com/search/docs/crawling-indexing/large-site-managing-crawl-budget.

Architettura interna del crawler: URL Frontier, Priority Queue e Politeness

Per comprendere il crawl budget in modo operativo, è necessario conoscere l’architettura dei web crawler su larga scala. Googlebot segue un modello ben documentato nella letteratura accademica (Mercator, IRLbot) e confermato da dichiarazioni pubbliche degli ingegneri Google.

URL Frontier

L’URL Frontier è la struttura dati centrale che gestisce la coda degli URL da scansionare. Non è una semplice coda FIFO: implementa logiche di prioritizzazione, deduplicazione e scheduling. Gli URL entrano nel frontier da diverse sorgenti:

Sitemap XML inviate tramite Search Console o referenziate nel robots.txt
Link scoperti durante il crawling di altre pagine (link discovery)
URL già noti che necessitano di riscansione (recrawling schedule)
URL inviati tramite l’API di Indexing o la funzione “Richiedi indicizzazione” in GSC

Priority Queue e scheduling

Ogni URL nel frontier riceve un punteggio di priorità basato su diversi segnali. Martin Splitt ha confermato durante i Google Search Central Lightning Talks che i fattori includono:

Frequenza di aggiornamento storica — URL che cambiano spesso vengono riscansionati con maggiore frequenza
PageRank e popolarità — pagine con più backlink e link interni ricevono priorità superiore
Tipo di contenuto — le pagine con contenuto principale (articoli, prodotti) hanno priorità su pagine di servizio (paginazione, filtri)
Freshness signals — contenuti che Google ritiene time-sensitive vengono riscansionati più rapidamente
Segnali dalla Sitemap XML — lastmod e changefreq influenzano lo scheduling (quando accurati)

Politeness Policy

Il crawler rispetta una politeness policy che limita le richieste simultanee per evitare di sovraccaricare il server. Questa policy si basa su:

Tempo di risposta del server — se il server rallenta, Googlebot riduce automaticamente la frequenza di scansione
Errori HTTP 5xx — un aumento di errori server causa una riduzione drastica del crawl rate
Direttive robots.txt — incluso il crawl-delay (non supportato ufficialmente da Google, ma rispettato da altri crawler)
Impostazione del crawl rate in Search Console — opzione legacy disponibile nella vecchia interfaccia per proprietà verificate

Dall’analisi dei log di siti enterprise che gestiamo, emerge un pattern costante: Googlebot mantiene tipicamente 2-8 connessioni simultanee per host, con un intervallo medio tra richieste di 500ms-2s. Su server con risposte inferiori a 200ms (TTFB), l’intervallo si riduce fino a 100-300ms, aumentando significativamente il volume di pagine scansionate giornalmente.

Le due componenti: Crawl Rate Limit e Crawl Demand

Crawl Rate Limit

Il crawl rate limit (o crawl rate) rappresenta il numero massimo di richieste simultanee che Googlebot effettua verso un sito, limitato per non degradare l’esperienza utente. I fattori determinanti sono:

Capacità di crawling — quante connessioni il server riesce a gestire senza aumentare i tempi di risposta
Limite impostato in Search Console — il webmaster può ridurre (ma non aumentare oltre il default) il crawl rate
Stato di salute del server — risposte lente, timeout e errori 5xx riducono il rate automaticamente

Il crawl rate limit si adatta dinamicamente. Quando il server risponde velocemente e senza errori, Google aumenta progressivamente il rate. Quando emergono problemi, lo riduce. Questo meccanismo è stato confermato da Gary Illyes nel suo post del 2017: “If the site becomes slow for a while, the limit will go down, and inversely, if the network is fast and responsive, the limit will go up.”

Crawl Demand

Il crawl demand esprime quanto Google “desidera” scansionare gli URL di un sito, indipendentemente dal rate limit. Due fattori principali lo determinano:

Popolarità — URL con più backlink, condivisioni e traffico tendono a essere riscansionati più frequentemente
Staleness — URL che Google non ha scansionato da tempo vengono riprioritizzati per mantenere aggiornato l’indice

Un aspetto critico e spesso sottovalutato: URL che rispondono con errori 404 o redirect continuano a consumare crawl demand fino a quando Google non li rimuove completamente dalla sua coda di scansione. Nei siti con migliaia di URL obsoleti, questo rappresenta uno spreco significativo del budget disponibile.

La formula operativa del crawl budget è quindi:

Crawl Budget = min(Crawl Rate Limit, Crawl Demand)

In altre parole, Google scansiona il minimo tra ciò che il server consente e ciò che il crawler ritiene utile scansionare.

Fattori che influenzano il Crawl Budget

Dall’analisi di centinaia di audit tecnici e log analysis su siti di diverse dimensioni, questi sono i fattori che impattano il crawl budget, organizzati per categoria e peso relativo.

Fattore	Componente	Impatto	Descrizione
TTFB (Time To First Byte)	Crawl Rate Limit	Alto	Server con TTFB < 200ms ricevono fino a 3-5x più richieste giornaliere rispetto a server con TTFB > 1s
Errori 5xx	Crawl Rate Limit	Critico	Errori server persistenti riducono il crawl rate fino al 90% e possono innescare un abbandono temporaneo
URL parametrizzati duplicati	Crawl Demand	Alto	Filtri, ordinamenti e parametri di sessione generano URL infiniti che diluiscono il budget
Redirect chain	Crawl Demand	Medio-Alto	Catene di redirect consumano budget multiplo: ogni hop è una richiesta separata
Soft 404	Crawl Demand	Medio	Pagine che restituiscono 200 ma mostrano contenuto vuoto o errore — Google le riscansiona ripetutamente
Contenuto duplicato	Crawl Demand	Medio	Versioni duplicate (www/non-www, http/https, trailing slash) raddoppiano le richieste
Contenuto thin/low-quality	Crawl Demand	Medio	URL con contenuto scarso riducono la percezione di qualità complessiva del dominio
Sitemap XML aggiornata	Crawl Demand	Medio	Sitemap accurate con lastmod realistico migliorano la prioritizzazione degli URL
Link interni	Crawl Demand	Medio	Pagine con più link interni ricevono più visite dal crawler
Pagine orfane	Crawl Demand	Basso-Medio	URL senza link interni dipendono dalla sitemap per la scoperta
robots.txt efficiente	Crawl Rate Limit	Medio	Bloccare le sezioni inutili libera budget per URL di valore
HTTP/2	Crawl Rate Limit	Medio	Dal 2022, Googlebot usa HTTP/2 per default — il multiplexing migliora l’efficienza

Come misurare il Crawl Budget: log analysis con Python

L’analisi dei log server è il metodo più affidabile per misurare il crawl budget effettivo. Google Search Console fornisce dati aggregati utili, ma i log offrono granularità al singolo URL, con timestamp, user-agent, status code e dimensione della risposta.

Lo script seguente analizza i log in formato Combined di Apache/Nginx, filtra le richieste di Googlebot, e produce un report con le metriche essenziali per la valutazione del crawl budget.

#!/usr/bin/env python3
"""
Crawl Budget Analyzer — Analisi log server per Googlebot
Legge file di log in formato Combined e produce metriche di crawl budget.
Autore: Giovanni Sacheli — evemilano.com
"""

import re
import sys
from collections import Counter, defaultdict
from datetime import datetime

# Pattern per log Apache/Nginx formato Combined
LOG_PATTERN = re.compile(
    r'(?P<ip>[\d.]+)\s+-\s+-\s+'
    r'\[(?P<date>[^\]]+)\]\s+'
    r'"(?P<method>\w+)\s+(?P<url>\S+)\s+\S+"\s+'
    r'(?P<status>\d{3})\s+'
    r'(?P<size>\d+|-)\s+'
    r'"[^"]*"\s+'
    r'"(?P<ua>[^"]*)"'
)

GOOGLEBOT_UA = re.compile(r'Googlebot|Google-InspectionTool|Storebot-Google', re.I)


def parse_log(filepath):
    """Analizza il file di log e restituisce solo le richieste Googlebot."""
    entries = []
    with open(filepath, 'r', encoding='utf-8', errors='replace') as f:
        for line in f:
            m = LOG_PATTERN.match(line)
            if not m:
                continue
            if not GOOGLEBOT_UA.search(m.group('ua')):
                continue
            try:
                dt = datetime.strptime(
                    m.group('date').split()[0], '%d/%b/%Y:%H:%M:%S'
                )
            except ValueError:
                continue
            entries.append({
                'date': dt,
                'url': m.group('url'),
                'status': int(m.group('status')),
                'size': int(m.group('size')) if m.group('size') != '-' else 0,
                'ua': m.group('ua'),
            })
    return entries


def analyze_crawl_budget(entries):
    """Produce metriche aggregate per l'analisi del crawl budget."""
    if not entries:
        print("Nessuna richiesta Googlebot trovata.")
        return

    # --- Metriche generali ---
    total = len(entries)
    dates = [e['date'].date() for e in entries]
    unique_dates = sorted(set(dates))
    num_days = len(unique_dates)
    avg_daily = total / num_days if num_days else 0

    print(f"{'='*60}")
    print(f"CRAWL BUDGET REPORT — Googlebot")
    print(f"{'='*60}")
    print(f"Periodo analizzato: {unique_dates[0]} → {unique_dates[-1]}")
    print(f"Giorni: {num_days}")
    print(f"Richieste totali: {total:,}")
    print(f"Media giornaliera: {avg_daily:,.0f} richieste/giorno")

    # --- Distribuzione status code ---
    status_counter = Counter(e['status'] for e in entries)
    print(f"\n--- Distribuzione Status Code ---")
    for code, count in status_counter.most_common():
        pct = count / total * 100
        print(f"  {code}: {count:,} ({pct:.1f}%)")

    # --- Crawl per giorno (per identificare trend) ---
    daily_counter = Counter(dates)
    print(f"\n--- Crawl giornaliero (ultimi 7 giorni) ---")
    for day in unique_dates[-7:]:
        print(f"  {day}: {daily_counter[day]:,} richieste")

    # --- URL più scansionati ---
    url_counter = Counter(e['url'] for e in entries)
    print(f"\n--- Top 20 URL più scansionati ---")
    for url, count in url_counter.most_common(20):
        print(f"  {count:>6,}x  {url[:100]}")

    # --- Crawl waste: URL con status != 200 ---
    waste = [e for e in entries if e['status'] != 200]
    waste_pct = len(waste) / total * 100
    print(f"\n--- Crawl Waste ---")
    print(f"  Richieste non-200: {len(waste):,} ({waste_pct:.1f}%)")

    waste_status = Counter(e['status'] for e in waste)
    for code, count in waste_status.most_common(5):
        print(f"    {code}: {count:,}")

    # --- Sezioni del sito ---
    section_counter = defaultdict(int)
    for e in entries:
        parts = e['url'].strip('/').split('/')
        section = '/' + parts[0] + '/' if parts and parts[0] else '/'
        section_counter[section] += 1

    print(f"\n--- Top 15 sezioni per volume di crawl ---")
    for section, count in sorted(
        section_counter.items(), key=lambda x: -x[1]
    )[:15]:
        pct = count / total * 100
        print(f"  {count:>6,} ({pct:>5.1f}%)  {section}")


if __name__ == '__main__':
    if len(sys.argv) < 2:
        print("Uso: python crawl_budget_analyzer.py access.log [access2.log ...]")
        sys.exit(1)
    all_entries = []
    for logfile in sys.argv[1:]:
        print(f"Parsing {logfile}...")
        all_entries.extend(parse_log(logfile))
    all_entries.sort(key=lambda e: e['date'])
    analyze_crawl_budget(all_entries)

Lo script produce un report strutturato con le metriche fondamentali per la diagnosi del crawl budget:

Media giornaliera di richieste — il crawl rate effettivo (baseline per confronti nel tempo)
Distribuzione status code — percentuale di 200, 301, 404, 5xx per identificare sprechi
Crawl waste — percentuale di budget sprecata su URL non-200
Top URL scansionati — identifica URL che consumano budget in modo anomalo
Distribuzione per sezioni — verifica se il crawl si concentra sulle sezioni di valore

Nota: Eseguire lo script con python crawl_budget_analyzer.py access.log. Su file di log di grandi dimensioni (> 5 GB), è consigliabile pre-filtrare le righe con Googlebot usando grep -i googlebot access.log > googlebot.log prima dell’analisi Python. Per analisi più avanzate con Screaming Frog, è possibile importare i log e incrociarli con i dati di crawl.

Metriche chiave da monitorare nei log

Metrica	Valore ideale	Azione se fuori soglia
Richieste Googlebot / giorno	Trend stabile o in crescita	Un calo improvviso indica problemi server o penalizzazioni
% richieste con status 200	> 90%	Risolvere redirect chain, 404 e soft 404
% richieste su URL di valore	> 70%	Bloccare URL inutili via robots.txt, consolidare con canonical
Crawl waste (non-200)	< 10%	Ogni punto percentuale recuperato è budget disponibile per URL di valore
Tempo medio risposta server	< 300ms	Ottimizzare cache, database, CDN
URL scansionati una sola volta / mese	Da minimizzare per URL importanti	Migliorare internal linking verso URL chiave
Rapporto pagine uniche / richieste totali	Più vicino a 1.0 possibile	Valori bassi indicano re-crawl eccessivo sugli stessi URL

Statistiche di scansione in Google Search Console: come interpretarle

Google Search Console espone le statistiche di scansione nella sezione Impostazioni > Statistiche di scansione. Questo report fornisce dati aggregati degli ultimi 90 giorni, suddivisi in tre metriche principali.

Richieste totali di scansione

Il grafico mostra il numero di richieste effettuate da Googlebot ogni giorno. È il dato più diretto per monitorare il crawl rate. Pattern da osservare:

Calo improvviso — possibile problema server, robots.txt bloccante, o riduzione di crawl demand dopo un quality update
Picco temporaneo — tipico dopo l’invio di una nuova sitemap o dopo la pubblicazione di contenuti freschi con link esterni
Trend in crescita costante — segnale positivo, indica che Google aumenta l’interesse per il sito
Andamento piatto su siti grandi — il crawl rate limit è probabilmente il collo di bottiglia

Dimensione totale del download

Mostra i byte totali scaricati giornalmente. Questa metrica combinata con le richieste totali fornisce la dimensione media per richiesta. Una dimensione media elevata (> 500 KB/pagina) può indicare pagine non ottimizzate, risorse inline eccessive, o HTML bloat da plugin e framework.

Tempo medio di risposta

Il tempo medio di risposta del server per le richieste di Googlebot. Questa è la metrica più direttamente correlata al crawl rate limit. Dall’esperienza su siti enterprise:

< 200ms — Ottimo. Googlebot aumenta il crawl rate massimo
200-500ms — Accettabile per la maggior parte dei siti
500ms-1s — Subottimale. Il crawl rate viene ridotto progressivamente
> 1s — Critico. Intervento urgente su infrastruttura necessario

Dettaglio della risposta di scansione

GSC mostra anche la distribuzione delle risposte raggruppata per tipo di scopo (discovery vs refresh) e per tipo di risposta (HTML, immagine, JavaScript, CSS, PDF, altro). Il rapporto tra discovery (URL nuovi) e refresh (URL già noti) è un indicatore diretto della salute del crawl budget:

Un sito in crescita dovrebbe avere un buon mix di discovery e refresh
Se il discovery è prossimo a zero ma il sito ha nuovi contenuti, ci sono problemi di scoperta URL (internal linking, sitemap)
Se il refresh è dominante su URL a basso valore, il crawl demand è sprecato su sezioni non prioritarie

Strategie di ottimizzazione del Crawl Budget

Le strategie si dividono in due macro-categorie: quelle che agiscono sul crawl rate limit (migliorare la capacità del server) e quelle che agiscono sul crawl demand (dirigere il crawler verso URL di valore).

Per una panoramica rapida dei fattori che aumentano la frequenza di scansione, vedi come aumentare le scansioni di Googlebot.

robots.txt: bloccare il crawl di URL a basso valore

Il file robots.txt è lo strumento principale per controllare quali sezioni del sito vengono scansionate. Bloccare URL a basso valore libera budget per pagine importanti.

Pattern comuni da bloccare:

# Parametri di ordinamento e filtri
Disallow: /*?orderby=
Disallow: /*?sort=
Disallow: /*?filter=

# Pagine di ricerca interna
Disallow: /search/
Disallow: /*?s=

# Area utente e carrello
Disallow: /my-account/
Disallow: /cart/
Disallow: /checkout/

# Feed e formati alternativi
Disallow: /feed/
Disallow: /*/feed/

# Paginazione profonda (oltre pagina 5)
# Nota: gestire con meta robots per granularità maggiore

# Parametri di sessione e tracking
Disallow: /*?utm_
Disallow: /*?sessionid=
Disallow: /*?ref=

Nota: Il robots.txt blocca la scansione ma non l’indicizzazione. Se un URL è linkato da fonti esterne, Google può indicizzarlo anche senza scansionarlo, mostrando uno snippet incompleto nei risultati. Per rimuovere URL dall’indice, usare noindex in combinazione con il permesso di scansione.

Tag canonical: consolidare URL duplicati

I tag canonical riducono il crawl demand consolidando URL duplicati o quasi-duplicati verso un URL canonico. Questo segnala a Google quale versione preferire, riducendo progressivamente il crawl delle varianti.

Implementare canonical self-referencing su tutte le pagine
Canonicalizzare varianti con parametri (ordinamento, filtri non significativi) verso la pagina base
Canonicalizzare versioni HTTP → HTTPS e non-www → www (in aggiunta ai redirect)
Verificare che non esistano catene di canonical (A → B → C): Google segue al massimo 5 hop

Meta robots noindex: escludere URL dall’indice

La direttiva noindex è complementare al robots.txt. Mentre robots.txt blocca la scansione, noindex richiede la scansione ma impedisce l’indicizzazione. Nel lungo termine, Google tende a ridurre la frequenza di scansione delle pagine noindex, liberando crawl budget.

Applicazioni tipiche:

Pagine di risultati di ricerca interna
Pagine di tag e archivi a basso valore
Pagine di paginazione profonda (dalla pagina 3-5 in poi)
Pagine filtrate nelle navigazioni faceted senza contenuto unico
Pagine di prodotti out of stock temporaneamente non disponibili

Sitemap XML: guidare il crawler verso URL prioritari

La Sitemap XML non aumenta il crawl budget, ma influenza la prioritizzazione degli URL all’interno del budget disponibile. Per massimizzarne l’efficacia:

Includere solo URL canonici indicizzabili — nessun URL con noindex, nessun URL non-canonico, nessun URL con redirect
Mantenere lastmod accurato — aggiornare il lastmod SOLO quando il contenuto principale della pagina cambia effettivamente. Valori di lastmod falsati riducono la fiducia di Google nella sitemap
Segmentare per tipo di contenuto — sitemap separate per articoli, prodotti, pagine, immagini. Questo facilita il monitoraggio in GSC
Dimensione massima — 50.000 URL e 50 MB non compressi per file. Per siti più grandi, usare un sitemap index
Referenziare nel robots.txt — aggiungere Sitemap: https://www.example.com/sitemap.xml nel robots.txt per garantire la scoperta

Paginazione e impatto sul crawl budget

La paginazione è uno dei principali consumatori di crawl budget su siti con archivi estesi. Un blog con 5.000 articoli e 10 articoli per pagina genera 500 pagine di archivio — ognuna delle quali viene scansionata periodicamente.

Strategie di ottimizzazione della paginazione:

Aumentare il numero di articoli per pagina — passare da 10 a 30 riduce le pagine di archivio del 66%
Implementare link rel=”next/prev” — deprecati per l’indicizzazione dal 2019, ma ancora utili per il crawling come segnale di relazione tra pagine
noindex sulle pagine profonde — applicare noindex dalla pagina 3-5 in poi, mantenendo il follow per consentire la scoperta degli articoli
Escludere dalla sitemap — includere solo la prima pagina di ogni archivio nella sitemap

Gestione parametri URL

Google ha deprecato il tool “Parametri URL” in Search Console nel 2022, affermando che il crawler è diventato più intelligente nel gestire autonomamente i parametri. Tuttavia, su siti con migliaia di combinazioni di parametri, è ancora necessario intervenire lato server:

Implementare canonical tag che puntano alla pagina base (senza parametri di ordinamento o filtro)
Bloccare i pattern di parametri più prolifici via robots.txt
Utilizzare il tag noindex, follow sulle pagine con combinazioni di filtri che non producono contenuto unico
Dove possibile, riscrivere URL parametrizzati in URL clean path-based (es. /scarpe/nike/rosse/ invece di /scarpe/?brand=nike&color=red)

Casi speciali: JavaScript rendering, faceted navigation, siti multi-lingua

JavaScript rendering e doppio crawl

Google utilizza un processo a due fasi per le pagine che dipendono da JavaScript: prima scarica l’HTML grezzo (crawling), poi esegue il JavaScript per ottenere il DOM finale (rendering). Martin Splitt ha chiarito durante i video “JavaScript SEO” su Google Search Central che il rendering avviene in una coda separata e può essere significativamente ritardato rispetto al crawling iniziale.

L’impatto sul crawl budget è duplice:

Doppio consumo di risorse — ogni pagina JS-rendered richiede due passaggi: il download dell’HTML e l’esecuzione del rendering. Questo consuma più risorse della pipeline di Google rispetto a pagine con contenuto server-rendered
Ritardo nel rendering — la coda di rendering ha una capacità limitata. Pagine che dipendono da JS per i link interni rallentano la scoperta di nuovi URL, poiché i link non sono visibili fino al completamento del rendering
Risorse aggiuntive — il renderer scarica CSS, JS, font e immagini referenziati dal DOM. Se queste risorse sono bloccate da robots.txt, il rendering fallisce

La soluzione ottimale per siti con molte pagine è implementare Server-Side Rendering (SSR) o Dynamic Rendering specifico per i crawler. Framework come Next.js, Nuxt.js e Angular Universal supportano nativamente l’SSR, eliminando il collo di bottiglia del rendering.

Faceted navigation: il consumatore silenzioso di crawl budget

La navigazione faceted (filtri per colore, taglia, prezzo, marca, ecc.) è la causa più comune di esplosione combinatoria del crawl budget negli e-commerce. Un catalogo con 10.000 prodotti, 8 attributi di filtro e 5-20 valori per attributo può generare milioni di URL unici, la maggior parte dei quali con contenuto duplicato o quasi-duplicato.

Strategia a tre livelli per la gestione dei filtri faceted:

Livello 1 — Indicizzabile: combinazioni di filtri che generano pagine con volume di ricerca significativo e contenuto unico (es. “scarpe nike uomo”). Queste pagine hanno URL clean, contenuto ottimizzato, canonical self-referencing e sono incluse nella sitemap
Livello 2 — Crawlable ma non indicizzabile: combinazioni utili per la navigazione ma senza volume di ricerca. Implementare noindex, follow per permettere la scoperta di URL di livello 1 attraverso i link interni
Livello 3 — Bloccato: combinazioni multiple di filtri (2+ filtri simultanei), ordinamenti, e parametri di sessione. Bloccare via robots.txt e implementare link nofollow sugli elementi dell’interfaccia

Un approccio tecnico efficace è l’uso di AJAX per i filtri di livello 2 e 3: i filtri aggiornano il contenuto della pagina senza cambiare l’URL nel browser, eliminando alla radice la generazione di URL parametrizzati. I filtri di livello 1 invece generano URL statici pre-renderizzati.

Siti multi-lingua e hreflang

I siti multi-lingua moltiplicano il numero di URL per il numero di lingue supportate. Un sito con 50.000 pagine in 5 lingue ha 250.000 URL. L’implementazione di hreflang aggiunge complessità ma non impatta direttamente il crawl budget — Google scansiona comunque ogni URL individualmente.

Raccomandazioni operative:

Usare sitemap separate per lingua per facilitare il monitoraggio in GSC
Implementare hreflang nella sitemap (non nell’HTML) per siti con molte lingue — riduce il peso della pagina HTML
Verificare che tutte le varianti linguistiche restituiscano 200 — errori 404 su varianti hreflang generano crawl waste
Se una lingua non è ancora completamente tradotta, è preferibile non implementare hreflang per quella variante piuttosto che servire pagine thin o contenuto misto

Crawl Budget e Core Web Vitals: la relazione con la velocità del server

Esiste una relazione indiretta ma significativa tra Core Web Vitals, performance del server e crawl budget. La metrica più rilevante in questo contesto è il TTFB (Time To First Byte), che non fa parte dei Core Web Vitals ufficiali ma è direttamente correlata al crawl rate limit.

TTFB e crawl rate: la correlazione diretta

Dall’analisi dei log di diversi siti enterprise prima e dopo interventi di ottimizzazione infrastrutturale, emerge una correlazione chiara:

Scenario	TTFB medio	Richieste Googlebot/giorno	Variazione
E-commerce, hosting condiviso	1.200ms	~2.000	Baseline
Dopo migrazione a VPS con cache	380ms	~6.500	+225%
Dopo CDN + page cache aggressiva	120ms	~12.000	+500%
Portale editoriale, server lento	2.800ms	~800	Baseline
Dopo ottimizzazione database + Varnish	95ms	~15.000	+1775%

Questi dati confermano quanto affermato da Gary Illyes: la velocità del server è il fattore singolo più impattante sul crawl rate limit. Un investimento nell’infrastruttura server — cache lato server (Varnish, Redis, FastCGI cache), ottimizzazione query database, CDN per asset statici — produce risultati misurabili e immediati sul volume di scansione.

HTTP/2 e crawling efficiente

Dal novembre 2020, Googlebot supporta il crawling via HTTP/2. Da fine 2022, HTTP/2 è il protocollo predefinito per il crawling. I vantaggi per il crawl budget includono:

Multiplexing — più richieste simultanee su una singola connessione TCP, riducendo l’overhead di connessione
Header compression (HPACK) — riduce la dimensione dei dati trasmessi per ogni richiesta
Server push — potenziale pre-invio di risorse critiche (CSS, JS) al crawler

Verificare che il server supporti HTTP/2 è un prerequisito tecnico. La maggior parte dei server moderni (Nginx 1.9.5+, Apache 2.4.17+, LiteSpeed) lo supportano nativamente. Verificare con curl -I --http2 https://www.example.com e controllare la presenza di HTTP/2 200 nella risposta.

Errori server e degrado del crawl budget

Gli errori HTTP 5xx hanno un effetto devastante sul crawl budget. Quando Googlebot riceve un numero significativo di errori 500, 502, 503 o 504:

Riduce immediatamente il crawl rate per non aggravare il problema
Se gli errori persistono per giorni, riduce anche il crawl demand (considera il sito “inaffidabile”)
Gli URL che restituiscono 5xx in modo persistente possono essere temporaneamente rimossi dall’indice
Il recupero del crawl rate dopo la risoluzione degli errori non è immediato — possono servire giorni o settimane per tornare ai livelli precedenti

La gestione proattiva degli errori server include: monitoraggio real-time con alerting (Datadog, New Relic, UptimeRobot), implementazione di circuit breaker per componenti backend instabili, e risposta 503 con Retry-After header durante le manutenzioni pianificate.

Checklist operativa per l’ottimizzazione del Crawl Budget

Questa checklist è organizzata per priorità di impatto, dal più alto al più basso. Ogni punto corrisponde a un intervento concreto e misurabile.

Priorità critica (impatto alto)

Verificare TTFB medio per Googlebot in GSC (Impostazioni > Statistiche di scansione). Target: < 300ms
Monitorare errori 5xx nei log server. Obiettivo: 0% di errori server per le richieste Googlebot
Implementare cache lato server (page cache) per le pagine pubbliche — Varnish, Redis Object Cache, FastCGI Cache
Verificare che il server supporti HTTP/2 e che sia attivo per le richieste di Googlebot
Configurare robots.txt per bloccare sezioni a basso valore: ricerca interna, filtri, parametri di sessione, paginazione profonda
Risolvere tutte le catene di redirect (max 1 hop: URL sorgente → URL destinazione finale)

Priorità alta (impatto medio-alto)

Eseguire log analysis con lo script Python descritto sopra. Identificare il crawl waste e le sezioni sovra-scansionate
Implementare canonical tag coerenti su tutte le pagine — specialmente per varianti con parametri
Aggiornare la Sitemap XML: includere solo URL canonici, 200, indicizzabili. Rimuovere URL con redirect, noindex, o contenuto thin
Verificare e risolvere i soft 404 segnalati in GSC (Indicizzazione > Pagine > Soft 404)
Per siti con navigazione faceted: implementare la strategia a 3 livelli descritta nella sezione precedente
Per siti JS-rendered: implementare SSR o dynamic rendering per le pagine critiche

Priorità media (impatto medio)

Ottimizzare la struttura di internal linking: le pagine più importanti devono essere raggiungibili in massimo 3 click dalla homepage
Identificare e risolvere le pagine orfane (presenti in sitemap ma senza link interni)
Ridurre la dimensione media delle pagine HTML — rimuovere CSS/JS inline non necessari, comprimere HTML, lazy loading delle immagini
Implementare noindex sulle pagine di archivio a basso valore (tag, archivi per data, archivi per autore)
Monitorare il rapporto discovery/refresh nelle statistiche di scansione GSC
Per siti multi-lingua: usare sitemap separate per lingua, verificare la coerenza degli hreflang

Priorità bassa (mantenimento)

Automatizzare la log analysis con cron job settimanale per rilevare anomalie nel crawl pattern
Configurare alert su cali improvvisi del crawl rate (variazione > 30% rispetto alla baseline settimanale)
Documentare le regole del robots.txt e le logiche di canonical in una knowledge base tecnica del progetto
Revisionare trimestralmente la Sitemap XML per rimuovere URL obsoleti
Testare la risposta del server sotto carico per verificare che il TTFB rimanga stabile durante i picchi di traffico

Sintesi

L’ottimizzazione del crawl budget è un’attività strutturale della SEO tecnica che produce risultati misurabili, soprattutto su siti con più di 10.000 URL. I tre interventi con il ROI più elevato sono: ridurre il TTFB del server, eliminare il crawl waste (URL non-200, redirect chain, soft 404) e bloccare via robots.txt le sezioni del sito che non hanno valore per l’indicizzazione.

La log analysis resta lo strumento diagnostico più affidabile: i dati di GSC forniscono una panoramica utile, ma solo i log server consentono di identificare esattamente quali URL consumano budget e con quale frequenza. Lo script Python presentato in questo articolo è un punto di partenza operativo che può essere esteso con metriche personalizzate in base alle esigenze specifiche del progetto.

Ogni intervento sul crawl budget deve partire dai dati, non da best practice generiche. La sequenza corretta è sempre: misurare (log + GSC), identificare il collo di bottiglia (rate limit o demand), intervenire sul fattore limitante, misurare l’impatto. Senza questa disciplina analitica, le ottimizzazioni rischiano di essere inefficaci o, peggio, controproducenti.