Crawl budget: guida pratica per grandi piattaforme

Il crawl budget è il numero di pagine che Googlebot è disposto a scansionare sul tuo sito in un dato periodo. Sui siti piccoli è praticamente illimitato. Sulle piattaforme con milioni di URL diventa una risorsa strategica: il bot lo spreca su filtri, paginazione, template vuoti e pagine di staging invece di scansionare i contenuti prioritari. Il risultato: indicizzazione ritardata dei nuovi prodotti, copertura debole del catalogo, posizionamenti persi.

zoom_in

Passo 1: raccolta e analisi dei log dei crawler

I log del server web sono la fonte di verità primaria su ciò che Googlebot scansiona davvero. L'analisi dei log rivela la frequenza reale delle richieste, quali sezioni il bot ignora o dove si impantana, e quali risposte HTTP restituisce il server. Senza log, ogni ottimizzazione è un azzardo.

Estrarre le richieste di Googlebot da Nginx / Apache

# Filter only Googlebot requests from the last 7 days
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# HTTP status codes seen by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top URLs returning 404 to Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '$9 == "404" {print $7}' \
  | sort | uniq -c | sort -rn | head -30

Per l'analisi strutturata di grandi volumi di log usa strumenti dedicati: Screaming Frog Log File Analyser, Semrush Log Analyser o uno stack ELK (Elasticsearch + Kibana). Raggruppano automaticamente gli URL per pattern e tracciano il crawl rate nel tempo.

Passo 2: Google Search Console e analisi delle risposte del server

Google Search Console fornisce dati aggregati di scansione senza richiedere accesso ai log del server. Il report Statistiche sulla scansione è il punto d'ingresso chiave. Mostra il numero medio di richieste giornaliere, la velocità di caricamento percepita e la distribuzione dei codici di risposta.

• GSC → Impostazioni → Statistiche sulla scansione: grafico delle richieste, ripartizione per tipo di file e codice di risposta. Cerca picchi di 404/500 e cali dopo i deploy.
• GSC → Indicizzazione → Pagine: numero di URL indicizzati e motivi di non indicizzazione. «Scoperta — attualmente non indicizzata» è un segnale diretto di crawl budget.
• GSC → Controllo URL: verifica manuale dello stato di una pagina specifica — quando è stata scansionata l'ultima volta, cosa ha visto Googlebot.
• GSC → Impostazioni → Frequenza scansione: puoi limitare il crawl rate se il bot sovraccarica il server. Di norma non serve — limita solo quando hai problemi di performance misurabili.

Fonti di spreco del crawl budget

Su una grande piattaforma il bot perde budget in sei fonti tipiche. Identificale nei tuoi log e stima i volumi — avrai l'ordine di priorità per l'ottimizzazione.

zoom_in

Parametri URL e duplicati: rimedi

Gli URL parametrici sono la fonte di spreco più grande sulle piattaforme e-commerce. Non esiste un proiettile d'argento unico — la soluzione giusta dipende dalla natura del parametro.

# robots.txt — blocking parametric URLs
User-agent: *

# Sort and filter parameters
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Pagination deeper than page 3 (Allow/Disallow approach)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Session and tracking parameters
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview and drafts
Disallow: /*?preview=
Disallow: /*?draft=

Filtri, facet e paginazione

La navigazione a facet è il caso più complesso. Crea un'esplosione combinatoria di URL: 10 filtri con 5 valori ciascuno generano potenzialmente oltre un milione di combinazioni. L'obiettivo è tenere i facet di valore (marca + categoria) e bloccare le combinazioni inutili.

1. Identifica i facet di valore: pagine con traffico organico alto o contenuti SEO unici (ad es. /catalog/nike/ con un testo dedicato alla marca) — tienile nell'indice con self-canonical.
2. Aggiungi noindex + follow alle combinazioni di poco valore: la pagina viene renderizzata (i link vengono seguiti) ma non entra nell'indice. Usa <meta name="robots" content="noindex, follow"> nel template quando è attivo più di un facet.
3. Disallow per i parametri puramente tecnici: ordinamento, colore, taglia — se non portano valore SEO — bloccali via robots.txt.
4. Facet caricati via AJAX: se i facet si caricano via JavaScript senza riflettersi nell'URL, il bot non vede URL aggiuntivi. Il problema si risolve a livello di architettura.

Paginazione: canonical o Disallow

La strategia ottimale per la paginazione dipende dalla scala: fino a 10 pagine — consenti la scansione e aggiungi un canonical alla pagina 1 sulle pagine 2+. Per centinaia di pagine paginate — Disallow oltre la pagina 3–5. Lo scroll infinito senza parametri URL viene trattato dal bot come pagina unica — bene per il budget.

Pagine temporanee: webinar, mockup, demo

Le pagine temporanee sono un dissipatore nascosto di budget sulle piattaforme con team di marketing attivi. Landing di webinar, mockup di demo, pagine di anteprima per i clienti, varianti di test A/B — nascono in fretta e spesso restano per sempre, consumando silenziosamente crawl budget.

• meta robots noindex: aggiungi <meta name="robots" content="noindex, nofollow"> al template di tutte le pagine temporanee. Il bot visita, legge la direttiva ed esclude l'URL dall'indice. Il metodo più semplice quando hai accesso al template.
• Header HTTP X-Robots-Tag: se le pagine temporanee non hanno un template HTML dedicato (ad es. PDF o file generati), usa l'header di risposta HTTP: X-Robots-Tag: noindex, nofollow.
• Disallow per prefisso di percorso: se le pagine temporanee vivono sotto prefissi prevedibili, bloccale in robots.txt. Nessuna garanzia di rimozione per un URL già indicizzato, ma i nuovi URL non verranno scansionati.
• Autenticazione HTTP: per pagine di staging e preview è l'unico metodo affidabile di isolamento totale. Googlebot non ha credenziali e non scannerà la pagina.

# robots.txt — patterns for temporary pages
User-agent: *

# Webinars and events
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Mockups and previews
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B tests and experiments
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Template preview parameters
Disallow: /*?preview=
Disallow: /*?draft=
Disallow: /*?revision=

Sitemap index su larga scala

Con milioni di URL una singola sitemap XML è impraticabile: è limitata a 50.000 URL e 50 MB. Un Sitemap Index è un file indice che punta alle sitemap figlie. Permette di strutturare le priorità e dirigere il budget dove serve di più.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Priority sections — crawled first -->
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <!-- Lower-priority sections -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- Do NOT include noindex pages or duplicates! -->
</sitemapindex>

• Dividi le sitemap per tipo di contenuto: prodotti, categorie, blog, pagine statiche — un file separato per ciascuno. Così vedi in GSC le statistiche di indicizzazione per sezione.
• Mantieni lastmod onesto: lastmod segnala al bot la freschezza. Metti la data dell'ultima modifica reale, non quella di oggi — altrimenti il bot smette di fidarsi del segnale.
• Escludi gli URL bloccati: le pagine con noindex o Disallow non devono comparire nella sitemap — mandano al bot segnali contraddittori.
• Limite delle sitemap figlie: ogni file figlio — massimo 50.000 URL o 50 MB (compressi). Superato il limite, dividi in parti: sitemap-products-1.xml, sitemap-products-2.xml.

Configurazione del server e rate limiting

Il lato server influenza il crawl budget in entrambe le direzioni: risposte lente spingono Googlebot a ridurre l'intensità di scansione, mentre gli errori 5xx fanno perdere tempo al bot in attese e tentativi. L'ottimizzazione del server migliora direttamente l'efficienza della scansione.

# Nginx: return 429 when any crawler sends too many requests
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... other settings
}

KPI e monitoraggio

Il crawl budget richiede monitoraggio continuo: qualsiasi deploy può esporre per sbaglio migliaia di nuovi URL parametrici. Prepara una dashboard settimanale e una revisione mensile delle metriche seguenti.

• Ogni settimana: confronta le richieste di scansione GSC della settimana corrente con la precedente. Un picco improvviso segnala nuovi duplicati introdotti da un deploy recente.
• Ogni mese: controlla GSC → Pagine → «Scoperta — attualmente non indicizzata». Crescita con dimensione del sito invariata = problema di crawl budget.
• Dopo ogni deploy importante: lancia Screaming Frog sul sito, verifica il numero di URL unici. Confronta con lo snapshot precedente.
• Ogni trimestre: analisi completa dei log su 30 giorni. Cerca nuovi pattern di URL parametrici introdotti da codice aggiornato.
• Avvisi: imposta una notifica se le risposte 5xx superano l'1% delle richieste Googlebot in una giornata.

Quick win e roadmap

L'ottimizzazione del crawl budget non è un compito una tantum — è un processo. Dividi il lavoro in quick win (effetto in 1–2 settimane) e cambiamenti sistemici (1–3 mesi).

Checklist dei quick win

• noindex aggiunto a tutti i template di pagine temporanee (webinar, mockup, demo)
• Disallow per ?preview=, ?draft=, ?sessionid=, ?utm_ in robots.txt
• Canonical verso URL puliti su tutte le pagine parametriche (ordinamento, paginazione 2+)
• Pagine con noindex e Disallow rimosse dalla Sitemap
• Sitemap index suddiviso per sezione con lastmod accurato
• Catene di redirect ridotte a un solo salto
• 404 nei log Googlebot < 5% — link morti rimossi
• Dashboard di monitoraggio settimanale configurata in GSC

FAQ