Googlebot tronca a 2 MB: quanto pesano le categorie PrestaShop

Googlebot legge i primi 2 MB di ogni pagina HTML, misurati sul file non compresso e con gli header HTTP dentro: quello che viene dopo non esiste, né per l’indice né per il rendering. Da quando Google l’ha messo nero su bianco, all’inizio del 2026, la domanda che mi fanno è sempre la stessa: le categorie di PrestaShop ci stanno dentro? La risposta breve è sì, oggi ci stanno. Quella lunga è che il margine è più stretto di quanto dica DevTools, e che la prima cosa a restare fuori sarebbero i link alle pagine successive della categoria.

Invece di rispondere a occhio ho misurato, il 27 settembre 2026, tutte le 454 categorie linkate dal menu di due shop PrestaShop reali che seguo, più una demo pubblica di PrestaShop 8.2 come riferimento: peso dell’HTML non compresso e compresso, nodi del DOM, peso totale con le risorse, tempo di risposta. Solo pagine pubbliche, con curl e un Chromium headless: i comandi sono più sotto, così li rifai sul tuo shop.

🛠️ Cosa dice davvero Google sul limite dei 2 MB

Le fonti primarie sono tre, e conviene leggerle insieme perché dicono cose diverse.

La pagina Googlebot della documentazione Search Central (aggiornata il 3 febbraio 2026) dice che Googlebot scansiona i primi 2 MB di un file supportato e i primi 64 MB di un PDF, che una volta raggiunto il limite interrompe il recupero e manda all’indicizzazione solo la parte già scaricata, e che il limite si applica ai dati non compressi. Ogni risorsa collegata, CSS e JavaScript, viene recuperata a parte con il suo limite.

La panoramica dei crawler di Google (aggiornata il 12 giugno 2026) mette il contesto: il default dell’infrastruttura è 15 MB per file, e un crawler come Googlebot può averne uno più basso, “per esempio 2 MB”. Nella stessa pagina ci sono le compressioni supportate: gzip, deflate e Brotli.

Il post Inside Googlebot di Gary Illyes sul blog Search Central, del 31 marzo 2026, aggiunge i dettagli che mancano alla documentazione:

• il limite di 2 MB vale per ogni singolo URL, header HTTP compresi;
• oltre la soglia Googlebot non rifiuta la pagina: si ferma esattamente ai 2 MB, e quella parte passa all’indicizzazione e al Web Rendering Service come se fosse il file completo;
• i byte dopo la soglia non vengono scaricati, renderizzati né indicizzati;
• le risorse richiamate dall’HTML hanno un contatore separato e non si sommano al peso della pagina;
• il consiglio è tenere l’HTML snello, spostare CSS e JavaScript pesanti in file esterni e mettere in alto title, meta, canonical e dati strutturati.

L’ultima riga del post dice che il limite non è scolpito nella pietra e può cambiare nel tempo. Date di consultazione di tutte e tre: 27 settembre 2026.

La mediana del web non è sopra la soglia

In giro si legge che la pagina mediana del web pesa già più di 2 MB, e quindi che il taglio colpisce mezzo internet. Il numero esiste, ma è un’altra cosa: il capitolo Page Weight del Web Almanac 2025 misura il peso totale, immagini, JavaScript e font compresi, che per Googlebot hanno ciascuno il proprio contatore. La risposta HTML mediana, nello stesso capitolo, è di 33 KB su mobile e 35 KB su desktop, e al novantesimo percentile resta sotto i 160 KB. Il limite dei 2 MB riguarda una minoranza di pagine: il punto è capire se le tue categorie sono in quella minoranza.

🛠️ Quanto pesano le categorie PrestaShop: le misure

Due shop PrestaShop reali, entrambi dietro LiteSpeed Cache, anonimi: lo shop A ha 344 categorie nel menu, lo shop B 110. Per ognuna ho scaricato l’HTML una volta; sulle più indicative ho aggiunto le misure complete in un Chromium headless in emulazione di uno smartphone (Pixel 7). Tutto il 27 settembre 2026, pagine servite dalla cache dove la cache c’era.

Sull’intero catalogo di categorie:

Come si leggono. “HTML non compresso” è il numero che conta per il limite, gli header aggiungono poco (da 0,7 a 1,9 KB sulle pagine misurate). Lo stesso URL può cambiare di qualche KB fra un download e l’altro, per blocchi dinamici e token: per questo la categoria più pesante dello shop B vale 534 KB nella prima tabella e 537 KB nello sweep. Il TTFB è la mediana di tre richieste con la cache in hit: su una categoria dello shop A una richiesta capitata su un miss ha impiegato 1,2 secondi, quindi il numero vero per Googlebot dipende da quanto spesso trova la cache fredda. Il “totale con risorse” è il trasferito in rete, e lì dentro ci sono gli 8 MB di immagini di una categoria sola: un problema serio di Core Web Vitals su PrestaShop, che però con il limite di Googlebot non c’entra, perché ogni immagine ha il suo contatore.

I comandi per rifarlo sul tuo shop

Il peso che conta, senza compressione, si ottiene non mandando l’header Accept-Encoding; quello trasferito, mandandolo come fa Googlebot:

URL="https://www.tuoshop.it/3-categoria"
UA="Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0 Mobile Safari/537.36"

# HTML non compresso: il numero da confrontare con i 2 MB (header a parte)
curl -s -A "$UA" -o /dev/null -w "HTML %{size_download} byte, header %{size_header} byte\n" "$URL"

# HTML compresso, come lo chiede Googlebot (gzip, deflate, br)
curl -s -A "$UA" -H "Accept-Encoding: gzip, deflate, br" -o /dev/null \
  -w "compresso %{size_download} byte, TTFB %{time_starttransfer} s\n" "$URL"

# Cache in hit o miss (LiteSpeed; con Cloudflare cerca cf-cache-status)
curl -s -A "$UA" -D - -o /dev/null "$URL" | grep -i "x-litespeed-cache"

Per i nodi del DOM e il peso con le risorse serve un browser vero. Questo è lo script Playwright che ho usato, ridotto all’essenziale:

import { chromium, devices } from 'playwright';

const browser = await chromium.launch();
const context = await browser.newContext({ ...devices['Pixel 7'] });
const page = await context.newPage();
const cdp = await context.newCDPSession(page);
let bytes = 0, requests = 0;
await cdp.send('Network.enable');
cdp.on('Network.loadingFinished', (e) => { bytes += e.encodedDataLength; requests++; });

await page.goto(process.argv[2], { waitUntil: 'load' });
await page.waitForTimeout(4000);
const dom = await page.evaluate(() => document.getElementsByTagName('*').length);
console.log({ dom, requests, totalMB: (bytes / 1e6).toFixed(1) });
await browser.close();

Se lo lanci su tutte le categorie, fallo con una pausa fra una richiesta e l’altra e fuori dagli orari di punta: su uno shop senza cache ogni categoria è una pagina generata da PHP.

⚠️ Il numero che inganna: DevTools mostra il peso compresso

La colonna “Trasferiti” di DevTools, e qualsiasi strumento che misura i byte in rete, riporta l’HTML compresso. Sulle categorie dei due shop il rapporto va da 7 a 12: la categoria da 534 KB dello shop B viaggia in 45 KB. Chi guarda DevTools vede 45 KB e pensa di avere margine per quaranta volte tanto; per Googlebot la pagina pesa già un quarto della soglia.

Il motivo per cui PrestaShop comprime così bene è che gran parte del suo HTML è aria. Fra il 34% e il 42% dei byte delle categorie dei due shop sono spazi e a capo lasciati dall’indentazione dei template Smarty: la compressione li riduce a quasi niente, il limite di Googlebot li conta tutti. Sulla demo pulita la quota è del 28%. Non vale la pena combatterli a mano, ma è il motivo per cui il numero giusto si prende sempre con il curl senza compressione.

Su PrestaShop DevTools ti mostra un decimo del peso che conta.
Il limite di Googlebot si misura sull’HTML aperto, spazi compresi.

⚠️ Cosa gonfia una categoria PrestaShop

Ho scomposto l’HTML delle categorie più pesanti per blocco, e ogni causa l’ho verificata sul codice sorgente del tema Classic, di Hummingbird e del modulo ps_facetedsearch prima di scriverla.

Le faccette mostrano tutti i valori

Nel modulo ps_facetedsearch, per ogni filtro, c’è l’opzione “Filter result limit”: il default è “No limit”, in alternativa un numero da 2 a 20. Nel codice del modulo (src/Filters/Converter.php) i valori oltre il limite vengono marcati come non visualizzati, e il template facets.tpl li salta del tutto: con “No limit” ogni valore con almeno un prodotto finisce nell’HTML, ognuno con la sua casella, l’URL filtrato scritto due volte (nel data-search-url e nell’href) e il conteggio.

Sulle categorie misurate ogni valore di filtro costa circa 1 KB di HTML. Nella categoria più pesante dello shop B un solo gruppo di attributi, usato come contenitore per varianti di natura diversa (colori, taglie, misure), aveva 161 valori, cioè 161 KB, e l’intero blocco dei filtri pesava 242 KB, il 45% della pagina. Una faccetta con 2.000 valori, che su un catalogo con attributi gestiti male non è un’ipotesi da laboratorio, da sola porterebbe una categoria come queste oltre la soglia.

Due effetti collaterali. Il blocco dei filtri nel tema sta nella colonna laterale, che nell’HTML viene prima dei prodotti: sullo shop B il primo prodotto comincia al 74% del file. E ogni valore è anche un link verso una combinazione di filtri: nel template ha rel="nofollow", che per Google è un suggerimento e per gli scraper niente, ed è la stessa superficie che consuma crawl budget e che, nel caso dei bot sulla navigazione a faccette, aveva prodotto oltre seimila URL diverse in un giorno.

Le miniature dei prodotti si portano dietro la descrizione

Nella categoria più pesante dello shop A le 24 miniature dei prodotti pesano 602 KB, 25 KB l’una. Il motivo è la descrizione breve di ogni prodotto, stampata nella miniatura e incollata a suo tempo da un editor, con tabelle e stili in linea: gli attributi style da soli fanno 269 KB, un terzo della pagina. Nelle altre categorie dello stesso shop una miniatura pesa fra 9 e 11 KB, sullo shop B circa 7.

La miniatura standard, nel Classic come in Hummingbird, include le varianti del prodotto (variant-links.tpl) e una serie di hook, a partire da displayProductPriceBlock (e nel Classic anche displayProductListReviews), in cui i moduli aggiungono il loro HTML per ogni prodotto della griglia: un modulo di recensioni o di etichette prezzo moltiplica il suo peso per il numero di prodotti in pagina.

Menu, stili in linea e il resto del contorno

Sullo shop A il mega menu pesa 103 KB ed è identico su ogni pagina, e ci sono 33 KB di CSS in blocchi <style> messi da tema e moduli. Sullo shop B il menu è sui 48 KB. Sono pesi fissi: non fanno sforare da soli, ma si sommano a tutto il resto.

Il JSON dei prodotti nel DOM: su PrestaShop standard no

Fra le cause che si citano spesso c’è il JSON dei prodotti stampato nella pagina. Sulle categorie del core non l’ho trovato: la variabile JavaScript prestashop è il json_encode delle variabili del tema (carrello, cliente, URL, configurazione) e pesa fra 10 e 17 KB sulle pagine misurate, mentre i dati strutturati della lista prodotti stanno in un JSON-LD nell’<head>, già in cima. Se su uno shop trovi un JSON dei prodotti in pagina, l’ha messo un modulo o un tema di terze parti.

resultsPerPage senza tetto

Il controller delle categorie accetta il parametro resultsPerPage e, se è maggiore di zero, lo usa così com’è: il codice è identico nella 8.2.3, nella 9.1.5 e nella 9.2.0-rc.1. Sulla demo 8.2 ?resultsPerPage=100 restituisce tutti i 19 prodotti della categoria invece dei 12 di default. Non l’ho provato sugli shop reali, perché una richiesta così li costringe a generare una pagina enorme, ma il conto è semplice: con miniature da 25 KB, 80 prodotti bastano a superare i 2 MB. Sulla demo il canonical di quella pagina punta già alla categoria pulita, quindi l’indice è protetto; resta lo spreco, di scansione e di server, se un modulo, un tema con il selettore “mostra 12, 24, 48” o un link esterno espone il parametro. In quel caso va bloccato.

⚠️ Cosa perde Googlebot per primo se una pagina sfora

Il taglio avviene a una posizione precisa del file, quindi conta l’ordine. Ho misurato dove cominciano i blocchi principali, in percentuale dei byte dell’HTML:

La parte alta è al sicuro: nel tema standard title, meta, canonical e dati strutturati della lista stanno nell’<head>, che qui finisce entro il primo 8% del file. Con un’eccezione vista sul campo: nella categoria più pesante dello shop A c’è un secondo blocco JSON-LD, una FAQ della categoria, al 93% del file, subito dopo la paginazione. Quello che sta in fondo sono i link alla pagina 2 e successive e i link del footer. Una categoria che sfora non sparisce dall’indice: perde per prima la strada verso i prodotti delle pagine successive, e poi i prodotti in fondo alla griglia. Se il sintomo che vedi è “i prodotti vecchi non vengono più scansionati”, il peso delle categorie è uno dei controlli da fare, insieme alla sitemap.

✅ Come alleggerire una categoria PrestaShop

L’ordine che seguo, dal più redditizio:

1. Metti un limite alle faccette lunghe. In ps_facetedsearch, per i filtri con decine di valori, un “Filter result limit”. Attenzione: con il limite il template standard non mostra un “vedi altri”, i valori oltre la soglia spariscono anche per il cliente. Per filtri come la marca, dove il cliente cerca un valore preciso, c’è il tipo a tendina: ho controllato il template, la tendina ignora il limite e stampa comunque tutti i valori, ma con un solo URL ciascuno e senza la casella, quindi alleggerisce senza togliere niente al cliente. E se un gruppo di attributi raccoglie varianti di natura diversa, la vera correzione è separarlo.

2. Pulisci le descrizioni brevi. Via tabelle e stili in linea incollati da Word o da un altro sito, oppure togli la descrizione dalla miniatura nel template. Sulla categoria più pesante dello shop A, riportare le miniature ai 9-11 KB delle altre categorie la porterebbe sotto i 500 KB, circa il 40% in meno.

3. Controlla cosa aggiungono i moduli nella griglia. Si apre il sorgente di una categoria e si guarda un solo product-miniature: tutto quello che non è nome, immagine, prezzo e link è peso moltiplicato per il numero di prodotti.

4. Guarda il menu. Un mega menu da 100 KB su ogni pagina è peso per Googlebot e nodi DOM per il telefono del cliente. Spesso basta togliere dal menu le sottocategorie di terzo livello.

5. Blocca i parametri che moltiplicano le pagine. resultsPerPage, ordinamenti e combinazioni di filtri: per la parte sui bot ho già scritto la regola .htaccess nel caso sulle faccette.

Gli spazi dei template, invece, li lascio stare: sotto i 2 MB non spostano niente e la compressione li annulla sul trasferimento. Diventano un tema solo su una pagina già vicina alla soglia.

🛠️ Dove guardarlo in Search Console

Senza toccare il server, due posti. Il report Statistiche di scansione (in Impostazioni) mostra le dimensioni totali del download e il tempo medio di risposta; nella tabella per tipo di file, cliccando sulla riga HTML, la guida del report dice che si vedono URL di esempio con la dimensione della risposta per ciascuno. È il modo più rapido per trovare le pagine più pesanti che Googlebot sta davvero scaricando. Il secondo è il Controllo URL: la pagina sottoposta a scansione mostra l’HTML che Google ha elaborato, e su una pagina sospetta si controlla che arrivi fino al footer.

⚠️ E i crawler delle AI

I crawler delle AI non hanno un limite dichiarato come quello di Googlebot, ma hanno un problema in più: secondo l’analisi di Vercel del dicembre 2024 i principali non eseguono JavaScript, quindi vedono solo l’HTML servito dal server, e in quello studio oltre un terzo delle richieste di ChatGPT e Claude finiva su un 404, contro l’8% di Googlebot. Il dato ha quasi due anni e non è PrestaShop, ma la conseguenza pratica è la stessa: quello che conta sta nell’HTML, e più è in alto meglio è.

✅ Prima di preoccuparti del limite

I 2 MB non sono un’emergenza per una categoria PrestaShop normale: le 454 che ho misurato ci stanno tutte, e la più pesante ne usa circa il 40%. Diventano un problema quando si sommano tre cose che su un catalogo cresciuto negli anni si sommano davvero: filtri senza limite, descrizioni pesanti nelle miniature, parametri che moltiplicano i prodotti in pagina. Misurare le proprie categorie con i comandi qui sopra richiede mezz’ora, ed è uno dei controlli che faccio come assistenza PrestaShop insieme alle faccette, alla cache e ai log. Scrivimi da uno dei canali qui sotto: mandami l’indirizzo dello shop e la categoria che ti sembra più lenta.

Fonti primarie: Googlebot, documentazione Google Search Central (aggiornata il 3 febbraio 2026), panoramica dei crawler e fetcher di Google (aggiornata il 12 giugno 2026), Inside Googlebot: demystifying crawling, fetching, and the bytes we process (Gary Illyes, 31 marzo 2026), guida al report Statistiche di scansione, tutte consultate il 27 settembre 2026; Web Almanac 2025, capitolo Page Weight; codice di ps_facetedsearch (src/Filters/Converter.php, views/templates/front/catalog/facets.tpl, branch di sviluppo, ultima release 5.1.0 del 10 settembre 2026), tema Classic e Hummingbird (miniatura prodotto, javascript.tpl, JSON-LD della lista), ProductListingFrontController della 9.2.0-rc.1; Vercel, The rise of the AI crawler (17 dicembre 2024). Il limite dei 2 MB era stato ripreso in italiano anche da SeoZoom. Misure del 27 settembre 2026 su pagine pubbliche: 344 categorie dello shop A e 110 dello shop B (due shop PrestaShop reali con LiteSpeed Cache, anonimi) e una demo pubblica di PrestaShop 8.2 (ps8.2.demopresta.it).