Googlebot: limite 2MB per HTML, l’AI spinge a ottimizzare il crawl
Il gigante della ricerca sta infatti riallocando le sue immense risorse computazionali, spostando l’attenzione dal web tradizionale verso un futuro sempre più dominato dall’intelligenza artificiale
Google ha appena messo un limite di velocità a come esplora il web, e potrebbe costringere molti siti a fare una dieta drastica. L’azienda ha infatti aggiornato silenziosamente la sua documentazione ufficiale, specificando che il suo crawler, Googlebot, per l’indicizzazione nella Ricerca elaborerà solo i primi 2 megabyte di una pagina HTML o di un file di testo.
Oltre quella soglia, il contenuto viene semplicemente ignorato.
Un cambiamento tecnico, apparentemente minuto, che però svela molto di più di una semplice ottimizzazione: è il segnale di come Google stia riallocando le sue immense risorse computazionali, spostando l’attenzione (e i soldi) dal web tradizionale verso il suo futuro sempre più dominato dall’intelligenza artificiale.
Per capire la portata, bisogna fare un passo indietro. Fino a poco fa, la documentazione parlava di un limite di dimensione predefinito di 15MB per i crawler di Google. Quel limite generale esiste ancora per altre parti del sistema, ma per il cuore della Ricerca web, la forbice si è stretta bruscamente a 2MB.
In pratica, se il codice HTML della tua homepage, articolo o scheda prodotto supera quella dimensione, Google potrebbe non “vedere” tutto.
Immaginate di inviare un romanzo a un editore che legge solo i primi due capitoli: se la trama si dipana dopo, per lui semplicemente non esiste.
Perché proprio ora?
La domanda sorge spontanea: perché imporre un tale vincolo nel 2026, quando la potenza di calcolo sembra illimitata? La risposta, come spesso accade a Mountain View, ha a che fare con i costi e le priorità. Googlebot scandaglia miliardi di pagine ogni giorno. Processare, analizzare e indicizzare gigabyte su gigabyte di codice HTML ha un prezzo, in termini di energia, server e tempo.
Quei cicli di calcolo sono diventati una risorsa preziosissima nell’era della ricerca generativa.
Features come gli AI Overviews o la modalità AI integrata non si accontentano di estrarre parole chiave: devono comprendere, sintetizzare e generare risposte. Questa operazione è di gran lunga più “costosa” per i server di Google rispetto al restituire una lista di link blu.
Riducendo la quantità di dati grezzi da processare per la ricerca tradizionale, l’azienda libera capacità per alimentare il suo motore AI.
È un calcolo strategico: sta scommettendo che il valore futuro sta nel rispondere direttamente alle domande degli utenti, non solo nel catalogare il web.
Il crawler tradizionale, in questa visione, diventa quasi un servizio di base, da mantenere efficiente e a basso costo.
Chi rischia di rimanere tagliato fuori?
La buona notizia è che la stragrande maggioranza dei siti non dovrà preoccuparsi. La dimensione mediana di una pagina HTML, secondo vari rapporti del settore, si aggira intorno ai 33KB, ben lontana dal limite di 2MB.
I problemi sorgono per quegli angoli del web dove il codice è particolarmente “gonfio”. Pensate a portali di e-commerce con migliaia di righe di script in linea, applicazioni web complesse (le cosiddette Single Page App) che generano tutto il loro contenuto via JavaScript, o siti corporate zeppi di codice non ottimizzato.
Se il tuo codice HTML supera i 2MB, Googlebot smetterà di scansionare il file una volta raggiunto quel limite. Non c’è alcun avviso quando il contenuto viene tagliato.
— Documentazione ufficiale di Google Search Central
Il rischio concreto è che contenuti importanti, magari posizionati in fondo al codice come dati strutturati JSON-LD per i rich snippet, vengano troncati. Se Google interrompe la lettura a metà di uno di questi blocchi, l’intero script diventa illeggibile e il sito perde potenziali feature speciali nei risultati di ricerca.
È un problema subdolo, difficile da diagnosticare, perché gli strumenti SEO tradizionali potrebbero continuare a vedere una pagina perfettamente funzionante, mentre Google ne vede solo una fetta.
La spinta (nascosta) verso un web più performante
C’è però un altro lato della medaglia, che parla direttamente all’esperienza utente. Da anni Google spinge i webmaster a creare siti veloci e leggeri, introducendo metriche come i Core Web Vitals.
Questo nuovo limite di crawl è un’enorme leva in quella direzione. In un colpo solo, rende l’ottimizzazione del codice non solo una buona pratica, ma una potenziale necessità per essere visibili.
Le raccomandazioni tecniche dell’azienda suonano ora come un manuale di sopravvivenza: abilitare la compressione Gzip o Brotli per i file di testo, rimuovere il CSS inutilizzato e ritardare il caricamento delle immagini fuori dallo schermo non sono più solo consigli per un voto più alto in PageSpeed Insights.
Sono strategie per assicurarsi che il contenuto fondamentale sia posizionato entro i primi, preziosissimi 2 megabyte.
In questo senso, la mossa di Google ha un effetto collaterale positivo: potrebbe finalmente costringere quei siti pesanti e lenti, spesso costruiti con framework JavaScript poco attenti al peso, a fare le pulizie di primavera.
Un web più leggero è un web più accessibile per tutti, specialmente per chi ha connessioni lente o dispositivi meno potenti.
La tensione, quindi, è tutta qui. Da un lato, vediamo un gigante tecnologico che razionalizza una sua attività fondamentale, forse per finanziare la corsa all’AI. Dall’altro, questa stessa mossa potrebbe accidentalmente migliorare il web per gli utenti finali, premiando siti ben fatti e punendo il codice pigro.
Ma ci si può fidare di un’azienda che decide unilateralmente quanto del nostro contenuto vale la pena di essere letto?
E fino a che punto la ricerca di efficienza finirà per appiattire la diversità del web, penalizzando quei siti di nicchia, ricchi di testo e dati, che per loro natura potrebbero superare la fatidica soglia?
La risposta, come spesso accade, non sarà nei comunicati stampa, ma in quello che Googlebot, leggendo solo due megabyte alla volta, deciderà di farci vedere.