Come Funziona il Crawling di Googlebot nel 2026: Limiti, Byte e Web Rendering Service

Googlebot tronca la scansione a 2 MB per pagina HTML, header HTTP inclusi. A confermarlo è Gary Illyes di Google il 31 marzo 2026, nel blog post ufficiale "Inside Googlebot" e nell'episodio 105 del podcast Search Off the Record.

La mediana di una pagina HTML senza compressione è di circa 20 kilobyte: la stragrande maggioranza dei siti non si avvicinerà mai a quel limite. Ma se il tuo HTML contiene immagini base64 inline, blocchi di CSS/JavaScript incorporati o mega-menu con migliaia di link, il contenuto testuale e i dati strutturati in fondo alla pagina potrebbero non essere mai letti. Per Google, non esistono.

In questo articolo analizzo i dati tecnici che Google ha reso pubblici, cosa significano per la SEO tecnica e quali azioni concrete puoi intraprendere oggi per assicurarti che Googlebot legga tutto il contenuto che conta.

Googlebot non è un programma singolo

Gary Illyes chiarisce un equivoco storico. Nei primi anni 2000, Google aveva un solo prodotto (la ricerca) e un solo crawler. Il nome "Googlebot" è rimasto, ma oggi descrive solo uno dei client di una piattaforma di crawling centralizzata.

Quando vedi Googlebot nei log del server, stai guardando Google Search. Ma la stessa infrastruttura serve decine di altri servizi: Google Shopping, AdSense, e molti altri. Ognuno di questi client usa un proprio user-agent, le proprie regole di robots.txt e i propri limiti di byte per URL. La lista completa è documentata sulla pagina ufficiale dei crawler Google.

Il 20 marzo 2026, Google ha aggiunto un'altra distinzione: Google-Agent, un crawler che si attiva solo su azione dell'utente, a differenza dei crawler autonomi come Googlebot che scoprono e indicizzano contenuti indipendentemente.

Il limite di 2 MB: cosa succede ai byte della tua pagina

Ogni client della piattaforma di crawling imposta le proprie soglie. Per Googlebot (Google Search), il limite è 2 MB per singolo URL. Questo include gli header della risposta HTTP.

Cosa succede quando una pagina HTML supera 2 MB:

1. Googlebot ferma il download esattamente a 2 MB. Non rifiuta la pagina, la tronca.
2. I primi 2 MB vengono passati ai sistemi di indicizzazione e al Web Rendering Service (WRS) come se fossero il file completo.
3. I byte oltre la soglia non vengono scaricati, renderizzati o indicizzati. Per Google, non esistono.
4. Le risorse referenziate nel codice HTML (CSS, JavaScript, esclusi media e font) vengono scaricate separatamente dal WRS, ciascuna con il proprio contatore di byte indipendente. Non contano verso i 2 MB della pagina principale.

Il troncamento è silenzioso: Google non invia nessun avviso. Non trovi errori in Search Console, non ricevi notifiche. L'unico modo per accorgersene è misurare il peso del tuo HTML e verificare che il contenuto critico stia nei primi 2 MB.

Quanto pesa una pagina web nel 2026

Per contestualizzare il limite, servono i dati reali. Secondo l'HTTP Archive Web Almanac 2025 (la fonte pubblica più completa sulle dimensioni del web), la pagina web mediana pesa circa 2,4 MB in totale, ma quel numero include tutte le risorse: immagini, JavaScript, CSS, font.

Il dato chiave è un altro: il peso mediano del solo HTML senza compressione è di circa 20 kilobyte. Al 90esimo percentile, siamo a 392 KB. Lontanissimo dai 2 MB. Nella pratica, solo una piccola percentuale di pagine web raggiunge quella soglia con il solo HTML.

Chi rischia di superarla: siti e-commerce con mega-menu che contengono migliaia di link di categoria, pagine con immagini base64 incorporate direttamente nell'HTML, single-page application che includono blocchi enormi di CSS e JavaScript inline, pagine generate da CMS che inseriscono markup ridondante.

Il Web Rendering Service: come Google esegue il JavaScript

Dopo il download, Googlebot passa i byte al WRS. Dal 2019 (annuncio a Google I/O, Martin Splitt), il WRS usa una versione evergreen di Chromium, aggiornata periodicamente. "Evergreen" non significa ultima release: esiste sempre un gap di settimane o mesi tra la versione del WRS e la Chromium stable corrente. Il WRS processa JavaScript, CSS ed esegue richieste XHR per ricostruire lo stato finale della pagina.

Tre caratteristiche del WRS sono rilevanti per la SEO tecnica.

Il WRS è stateless

Ogni richiesta parte da zero: local storage, session storage e cookie vengono cancellati tra una pagina e l'altra. Se il tuo sito dipende da dati in sessione per mostrare contenuto (ad esempio un popup di login che nasconde il testo principale), Googlebot non vedrà quel contenuto.

Il WRS non scarica immagini e video

Il WRS processa HTML, CSS, JavaScript e richieste XHR, ma non scarica file media (immagini e video). Per ogni risorsa testuale che scarica (file JS, CSS), il limite per URL si applica separatamente.

Crawling e rendering operano su code separate

Dopo il download, le pagine entrano in una coda di rendering. Il WRS non processa immediatamente ogni pagina scaricata. Per i siti JavaScript-heavy, questo significa che il contenuto puo impiegare giorni o settimane per essere indicizzato dopo il primo crawl. Crawling e rendering hanno budget indipendenti: un sito puo essere crawlato spesso ma renderizzato raramente.

E gli altri motori? Il caso Bing

Google non è l'unico con limiti di dimensione. Bing applica un limite soft di 1 MB per il codice HTML. A differenza di Google, Bing segnala il problema: se la pagina supera la soglia, Bing Webmaster Tools mostra un errore "HTML size is too long". Google invece tronca silenziosamente.

Se ottimizzi per il limite di 2 MB di Google, sei automaticamente dentro anche per Bing. Il consiglio pratico resta lo stesso: HTML snello, risorse pesanti in file esterni.

Cinque azioni concrete per restare sotto il limite

1. Misura il peso del tuo HTML

Prima di ottimizzare, misura. Apri il terminale e scarica la pagina:

curl -s -o /dev/null -w "%{size_download}" https://tuosito.it/pagina

Oppure usa Screaming Frog: la colonna "HTML Size" mostra il peso dell'HTML senza compressione per ogni URL. Se qualche pagina supera 1,5 MB, intervieni prima che diventi un problema.

2. Sposta CSS e JavaScript in file esterni

Ogni risorsa esterna ha il proprio contatore di byte separato. Un blocco di 500 KB di CSS inline conta verso i 2 MB della pagina. Lo stesso CSS in un file .css esterno no. La stessa logica vale per JavaScript: se usi framework come Next.js o Nuxt, il code splitting è già attivo. Se hai un sito custom con script inline, questo è il primo intervento.

3. Elimina le immagini base64 dall'HTML

Le immagini codificate in base64 direttamente nell'HTML possono aggiungere centinaia di kilobyte o megabyte al documento. Sostituiscile con tag img che puntano a file esterni: le immagini vengono scaricate dal crawler immagini con soglie separate, non dal crawler HTML.

4. Metti il contenuto critico in alto nel documento

Google elabora i primi 2 MB come se fossero l'intero file. Se il tuo tag title, i canonical, i meta tag, i dati strutturati e il contenuto testuale principale sono in fondo alla pagina, dopo migliaia di righe di menu e sidebar, rischi che finiscano oltre la soglia. Sposta meta tag, canonical, structured data e contenuto primario il più in alto possibile nel codice sorgente.

5. Monitora i tempi di risposta e il crawl budget

Se il server impiega troppo tempo a servire i byte, i crawler di Google rallentano automaticamente la frequenza di scansione per non sovraccaricare l'infrastruttura. Il risultato: meno pagine scansionate per sessione, un crawl budget meno efficiente. Nella community SEO tecnica, un Time to First Byte sotto i 200 millisecondi e considerato il target ottimale; le Core Web Vitals di Google indicano 800 ms come soglia "good" per il server response time.

Il crawl budget è la quantità di risorse che Google dedica alla scansione del tuo sito in un dato periodo. Pagine HTML più pesanti richiedono più tempo per essere generate e trasmesse, riducendo il numero totale di URL che Googlebot riesce a visitare. Per siti con migliaia di pagine, mantenere l'HTML snello e eliminare redirect chain e URL parametrizzati duplicati ha un impatto diretto sulla copertura dell'indice.

Limiti di questa analisi

• Il limite non è definitivo.: Gary Illyes scrive esplicitamente che il limite di 2 MB "non è scolpito nella pietra" e potrebbe cambiare con l'evoluzione del web.
• I dati riguardano solo Googlebot.: I limiti di altri crawler sulla stessa piattaforma Google (Shopping, AdSense) non sono tutti documentati pubblicamente.
• Non sappiamo quanto traffico perde chi supera il limite.: Google non pubblica dati sull'impatto del troncamento su ranking e indicizzazione. Spotibo e DebugBear hanno condotto test che confermano il troncamento, ma non l'effetto sul posizionamento.
• Non è chiaro se il limite si applica ai byte compressi o decompressi.: Gary Illyes parla di "byte scaricati", ma test indipendenti (Spotibo, DebugBear) suggeriscono che il troncamento avvenga sul contenuto decompresso. Finché Google non chiarisce, il margine di sicurezza è mantenere l'HTML non compresso sotto i 2 MB.

Prossimi passi

Il 90% delle pagine web ha un HTML sotto i 400 KB (dati HTTP Archive 2025): per la maggior parte dei siti, il limite di 2 MB non è un problema. I siti a rischio sono e-commerce con mega-menu, pagine con contenuto generato dinamicamente e applicazioni single-page con JavaScript inline massiccio. Il primo passo è misurare il peso dell'HTML e intervenire dove serve.

Per un'analisi completa della SEO tecnica del tuo sito, puoi partire dalla guida all'audit SEO in 7 passi. Se vuoi capire come automatizzare la scansione con strumenti AI,

leggi come ho integrato Screaming Frog con Claude Code per l'audit SEO tecnico.

Per approfondire i dati strutturati che Google consiglia di posizionare in alto nel documento, la guida pratica a Schema.org e dati strutturati copre tutti i tipi di markup rilevanti.

Hai domande sulla SEO tecnica del tuo sito? Scrivimi dalla pagina contatti.