Technical SEO · ★★★★★ ·
Googlebot: approfondimento sul crawling, il fetching e i limiti di dimensione dei file
Fonte: Google Search Central Blog
Google ha pubblicato un articolo che fa chiarezza sul funzionamento interno di Googlebot, sfatando il mito di un singolo crawler onnipotente. L'articolo evidenzia come Googlebot sia in realtà un client di una piattaforma di crawling centralizzata e spiega i limiti di dimensione dei file, con un focus sul limite di 2MB per le pagine HTML. Viene inoltre chiarito come Googlebot gestisce i file che superano tale limite.
> ANALISI APPROFONDITA
Google ha pubblicato un documento tecnico che ridefinisce la comprensione operativa di Googlebot, smontando l'idea diffusa di un crawler monolitico. La realtà è che Googlebot funziona come client di una piattaforma di crawling centralizzata, un'architettura che spiega comportamenti finora poco documentati e che ha implicazioni dirette su come ottimizzare per il crawl budget e gestire file di grandi dimensioni.
Il punto centrale riguarda i limiti di dimensione dei file. Google conferma ufficialmente che il limite per le pagine HTML è fissato a 2MB. Questo non è un valore indicativo: superata questa soglia, Googlebot interrompe il fetch e indicizza solo la porzione scaricata fino a quel momento. Il resto della pagina viene ignorato, con conseguenze dirette su contenuti, link interni e segnali di ranking presenti oltre il cut-off.
La distinzione tra crawling e fetching diventa operativa. Il crawling è la fase di scoperta degli URL, il fetching è il download effettivo delle risorse. Googlebot può scoprire un URL senza mai scaricarlo completamente, o scaricare solo una parte se il file eccede i limiti. Questo spiega perché alcune pagine risultano indicizzate ma con contenuti incompleti o link interni non seguiti.
L'architettura centralizzata significa che Googlebot non è un'entità autonoma ma un componente che interroga una piattaforma condivisa. Questo modello giustifica variazioni nel comportamento di crawl tra diverse sezioni di un sito o tra crawl consecutivi: le priorità vengono gestite a livello di piattaforma, non dal singolo user-agent. La conseguenza pratica è che ottimizzare per Googlebot significa ottimizzare per un sistema distribuito, non per un bot prevedibile.
Google chiarisce anche come gestisce i file che superano il limite. Per l'HTML, il taglio è netto a 2MB: tutto ciò che segue viene scartato. Per altri tipi di file, come PDF o immagini, esistono limiti diversi ma meno documentati. L'articolo non fornisce una tabella completa, ma conferma che ogni tipo di risorsa ha una soglia specifica oltre la quale il fetch viene interrotto.
La gestione dei redirect e delle catene di reindirizzamento rientra in questo framework. Ogni hop in una catena di redirect consuma risorse di crawl e può contribuire al raggiungimento dei limiti di fetch. Catene lunghe o redirect verso risorse pesanti aumentano il rischio di fetch incompleti, con impatti su indicizzazione e passaggio di PageRank.
L'articolo non introduce nuovi limiti, ma formalizza comportamenti già attivi. Il limite di 2MB per l'HTML è operativo da tempo, ma la conferma ufficiale elimina ambiguità e rende misurabile un parametro finora gestito per approssimazione. Per siti con pagine dinamiche, infinite scroll o contenuti caricati via JavaScript dopo il rendering iniziale, questo limite diventa un vincolo di progettazione, non solo un'indicazione di best practice.
> COSA CAMBIA PER TE
- ▸ Pagine HTML superiori a 2MB vengono troncate: contenuti, link interni e markup strutturato oltre questa soglia non vengono indicizzati. Siti con pagine lunghe o con infinite scroll server-side devono verificare la dimensione effettiva delle risposte HTML.
- ▸ Il crawl budget va ottimizzato considerando l'architettura distribuita di Googlebot, non un comportamento lineare. Priorità di crawl e fetch possono variare tra sezioni dello stesso sito in base a logiche di piattaforma centralizzata.
- ▸ Catene di redirect lunghe o redirect verso risorse pesanti aumentano il rischio di fetch incompleti. Ogni hop consuma risorse e può portare al superamento dei limiti, con perdita di segnali di ranking.
- ▸ La distinzione tra crawling e fetching diventa operativa: un URL può essere scoperto ma non completamente scaricato. Log di server e GSC vanno analizzati incrociando richieste di crawl e dimensioni effettive delle risposte.
- ▸ Siti con contenuti caricati dinamicamente via JavaScript dopo il rendering iniziale devono assicurarsi che l'HTML iniziale resti sotto i 2MB, altrimenti parte del DOM renderizzato potrebbe non essere mai visto da Googlebot.
> ESEMPI CONCRETI
COSA FARE
Un e-commerce con pagine categoria che caricano centinaia di prodotti via server-side rendering genera HTML da 3-4MB. Googlebot tronca a 2MB, perdendo gli ultimi prodotti e i relativi link interni. Soluzione: implementare paginazione lato server o lazy load con URL separati per blocchi di prodotti, mantenendo l'HTML iniziale sotto soglia.
COSA EVITARE
Un blog con infinite scroll implementato lato server concatena decine di post in un'unica risposta HTML. Se la pagina supera 2MB, i post in fondo non vengono indicizzati e i link interni verso articoli correlati vengono ignorati. Evitare: concatenare contenuti illimitati in un'unica risposta. Preferire paginazione canonica o infinite scroll client-side con API separate.
SCENARIO
Un sito di news con catene di redirect da URL brevi a URL canonici lunghi, passando per redirect geografici e A/B test, accumula 4-5 hop. Se l'HTML finale è vicino a 2MB, il fetch può essere interrotto prima del completamento. Caso reale: ridurre la catena a massimo 2 hop e monitorare i log per verificare che Googlebot completi il fetch dell'HTML finale.
> COME TESTARE L'IMPATTO
- Apri Chrome DevTools → Network, carica le pagine principali del sito e ordina per dimensione. Identifica risposte HTML superiori a 2MB.
- Esporta i log di server degli ultimi 30 giorni, filtra per user-agent Googlebot e incrocia URL richiesti con dimensioni delle risposte inviate. Cerca pattern di fetch incompleti o timeout.
- Usa uno script per calcolare la dimensione dell'HTML grezzo (prima del rendering JavaScript) delle pagine strategiche. Confronta con il limite di 2MB e verifica se contenuti critici cadono oltre la soglia.
- In Google Search Console → Copertura, filtra per pagine indicizzate e confronta con la sitemap. Identifica URL scoperti ma non completamente indicizzati, poi verifica la dimensione dell'HTML di quelle pagine.
- Testa le catene di redirect con curl -I -L [URL] e conta gli hop. Se superiori a 2, riduci la catena e verifica che l'HTML finale sia sotto 2MB.
- Configura un alert su log di server per risposte HTML > 1.8MB inviate a Googlebot. Questo margine di sicurezza permette di intervenire prima che il limite venga superato.
> DOMANDE FREQUENTI
Il limite di 2MB si applica all'HTML grezzo o all'HTML dopo il rendering JavaScript?
+
Il limite si applica all'HTML grezzo restituito dal server nella risposta HTTP iniziale. Il rendering JavaScript avviene dopo il fetch: se l'HTML iniziale supera 2MB, Googlebot tronca prima di avviare il rendering. Contenuti iniettati via JS dopo il fetch non contribuiscono al calcolo del limite, ma se l'HTML base è già troncato, il rendering parte da una base incompleta.
Se una pagina supera 2MB, Google indicizza almeno i primi 2MB o scarta l'intera pagina?
+
Google indicizza i primi 2MB scaricati. Il fetch viene interrotto alla soglia, ma la porzione ricevuta viene processata normalmente. Contenuti, link interni e markup strutturato presenti nei primi 2MB vengono considerati; tutto ciò che segue viene ignorato. Non c'è penalizzazione, ma perdita di segnali.
I limiti di dimensione si applicano anche a Googlebot per smartphone o solo alla versione desktop?
+
I limiti si applicano a tutti i client Googlebot, inclusa la versione mobile-first. Con l'indicizzazione mobile-first attiva per la maggior parte dei siti, il limite di 2MB va verificato sull'HTML servito alla versione mobile di Googlebot, che è quella usata per l'indicizzazione primaria.
Catene di redirect contribuiscono al calcolo dei 2MB o il limite si applica solo alla risorsa finale?
+
Il limite di 2MB si applica alla risorsa finale dopo tutti i redirect. Ogni redirect consuma però risorse di crawl e tempo di fetch: catene lunghe aumentano il rischio di timeout o interruzioni prima di raggiungere la risorsa finale. Il limite non è cumulativo tra gli hop, ma l'efficienza del crawl peggiora.
Esistono limiti documentati per altri tipi di file come PDF, immagini o CSS?
+
Google conferma che ogni tipo di risorsa ha limiti specifici, ma non pubblica una tabella completa. Per i PDF, il limite è noto essere intorno ai 100MB, ma il fetch può interrompersi prima per timeout. Per CSS e JavaScript, i limiti sono meno stringenti dell'HTML, ma file superiori a 5-10MB rischiano fetch incompleti.
> IL PUNTO DELLA REDAZIONE
La formalizzazione del limite di 2MB per l'HTML non è una novità tecnica, ma un cambio di paradigma comunicativo. Google ha sempre evitato di pubblicare soglie precise per non incentivare ottimizzazioni al limite; ora le rende esplicite perché l'architettura distribuita del crawling rende impossibile nascondere questi vincoli. Chi ha costruito pagine infinite o concatenato contenuti illimitati lato server deve intervenire subito: il rischio non è una penalizzazione, ma la perdita silenziosa di segnali di ranking e link interni. L'architettura centralizzata di Googlebot spiega comportamenti finora attribuiti a bug o inconsistenze. Variazioni di crawl tra sezioni di un sito, fetch incompleti su pagine strategiche, link interni ignorati: sono conseguenze di un sistema distribuito che ottimizza risorse a livello di piattaforma, non di singolo URL. Ottimizzare per Googlebot significa ora progettare per un sistema che priorizza, tronca e distribuisce il carico in modo non lineare. Se gestisci siti con pagine dinamiche pesanti, infinite scroll server-side o catene di redirect complesse, questo non è il momento di aspettare segnali di calo in GSC. Il limite è attivo, il comportamento è documentato: misura, testa, intervieni. Chi ignora questi vincoli perde visibilità senza accorgersene, perché il troncamento è silenzioso e i log di server non mostrano errori.
> TAGS
Questo articolo include un riassunto della notizia originale e, per gli item critici (5/5), una analisi editoriale prodotta da Osservatorio SEO.
Il riassunto è generato da google/gemini-2.0-flash-001, l'analisi approfondita da anthropic/claude-sonnet-4-5.
Per il testo completo e l'attribuzione della notizia, consulta la fonte originale.