# Search Console: errore nel test dell'URL live, la causa

Source: <https://www.nfw.run/articoli/search-console-pagina-pesante>

[Home](https://www.nfw.run/)[Articoli](https://www.nfw.run/articoli)

// articolo

Pubblicato: 27 ottobre 2026Scritto da [Enrico Pasetto](https://www.linkedin.com/in/enrico-pasetto) (<enrico@nfw.run>)

- [Lo studio](https://www.nfw.run/articoli/argomento/lo-studio)
- [Stato del web](https://www.nfw.run/articoli/argomento/stato-del-web)

![Google Search Console: An error occurred, try again in a few hours (messaggio di errore di Google, in inglese).](https://www.nfw.run/blog/google-search-console-heavy-page/cover-it.webp)

## In breve: cosa significa per la tua attività

Google Search Console ha un pulsante che chiede a Google di caricare una tua pagina in quel momento e di mostrarti cosa vede. Ispezionando i nostri report delle città, Search Console diceva "URL is not on Google" (l'URL non è su Google), e il test live è fallito con "An error occurred, try again in a few hours" (si è verificato un errore, riprova tra qualche ora). È fallito di nuovo riprovando ore dopo.

Il messaggio di errore è generico: non dà nessun motivo. Ma sullo stesso sito le nostre pagine più leggere hanno superato il test live e hanno potuto essere indicizzate, mentre le pagine pesanti dei report sono fallite. Stesso server, stessa proprietà di Search Console: la differenza evidente tra le pagine che hanno passato il test e quelle che sono fallite era il peso. Dopo aver alleggerito molto le pagine dei report, il test si è completato. Google non indica la causa, quindi non possiamo citarla, ma le prove vanno in una sola direzione.

Cosa è cambiato: il JavaScript che il browser di un visitatore deve scaricare per una pagina dei nostri report è passato da 2,81 MB a 1,04 MB, e il peso totale trasferito (HTML più JavaScript, compressi) da 947 KB a 461 KB. I visitatori vedono le stesse pagine. I grafici e le mappe sono semplicemente disegnati in modo più leggero.

Cosa portarsi a casa, se hai un sito:

1. **Una pagina può sembrare a posto a chi la visita ed essere comunque troppo pesante perché Google la testi.** Un portatile veloce con un buon wifi nasconde il problema.
1. **Esegui il test live sulle tue pagine più pesanti, non solo sulla home.** Se fallisce, chiedi allo sviluppatore cosa viene caricato prima che la pagina possa mostrare qualcosa.
1. **Parti dal nostro [audit SEO gratuito](https://www.nfw.run/audit-seo).** È il primo controllo che facciamo su qualsiasi sito, anche sul nostro.

Continua a leggere per i passaggi esatti, i numeri e cosa abbiamo cambiato.

## Il sintomo

Le pagine coinvolte sono i report delle città del nostro Stato del web, per esempio il [report di Verona](https://www.nfw.run/stato-del-web/verona-citta). Volevamo che Google le testasse e poi le indicizzasse, quindi abbiamo fatto quello che Google documenta:

1. Apri Google Search Console, poi Pagine.
1. Ispeziona un qualsiasi URL del dominio.
1. Il risultato dice "URL is not on Google" (l'URL non è su Google).
1. Premi "Test live URL" (testa l'URL live).
1. Il test fallisce con "An error occurred, try again in a few hours".

Abbiamo aspettato, come dice il messaggio, e riprovato ore dopo: stesso errore. (Citiamo le scritte in inglese: l'interfaccia di Search Console può mostrarle nella tua lingua.)

## Cosa pensiamo stesse succedendo

Qui vogliamo essere prudenti, perché Google non documenta cosa fa fallire il test live e il messaggio di errore non dà nessun motivo. Quello che abbiamo è un confronto dentro lo stesso sito. Le pagine più leggere hanno superato il test live e hanno potuto essere indicizzate. Le pagine pesanti dei report sono fallite. Stesso sito, stesso server, stessa proprietà di Search Console: l'unica differenza che abbiamo trovato era il peso delle pagine. L'errore è anche sparito sulle pagine dei report dopo averne ridotto il peso.

Quello che è noto pubblicamente è che Google esegue il rendering di una pagina con JavaScript prima di giudicarla, e lo fa con un tempo e risorse limitati. Una pagina che richiede megabyte di script prima di poter mostrare il contenuto è un modo plausibile di esaurire quel budget. Google non l'ha confermato, ma il peso è l'unica differenza tra le pagine che hanno passato il test e quelle che sono fallite.

L'altro sospettato ovvio era l'HTML stesso. Googlebot ha un limite su quanto legge di un file, 15 MB al momento in cui scriviamo ([documentazione di Google](https://developers.google.com/search/docs/crawling-indexing/googlebot)). Il nostro HTML era di 857 KB non compresso, molto sotto. Il problema quindi non era l'HTML, ma gli script che lo accompagnavano.

## Cosa abbiamo misurato

Abbiamo misurato il report di Verona il 27 ottobre 2026, prima e dopo la modifica:

|                           | Prima   | Dopo    |
| ------------------------- | ------- | ------- |
| HTML, non compresso       | 857 KB  | 852 KB  |
| HTML, gzip                | 107 KB  | 126 KB  |
| File di script caricati   | 30      | 25      |
| JavaScript, non compresso | 2,81 MB | 1,04 MB |
| JavaScript, gzip          | 840 KB  | 335 KB  |
| HTML + JavaScript, gzip   | 947 KB  | 461 KB  |

![Grafico a barre che confronta il peso della pagina del report di Verona prima e dopo: JavaScript non compresso 2,81 MB poi 1,04 MB, JavaScript gzip 840 KB poi 335 KB, HTML più JavaScript gzip 947 KB poi 461 KB](https://www.nfw.run/blog/google-search-console-heavy-page/figure-it.webp)

La pagina del report di Verona, prima e dopo la modifica

Il JavaScript è calato del 63% (da 2,81 MB a 1,04 MB non compresso) e il peso totale trasferito si è più o meno dimezzato.

L'HTML è rimasto circa della stessa dimensione, e compresso è anche cresciuto un po', da 107 KB a 126 KB. È normale: i grafici e le mappe ora sono disegnati nell'HTML stesso come SVG invece che dagli script, quindi la pagina ha 212 elementi SVG invece di 122. Abbiamo spostato il peso dagli script, che vanno scaricati ed eseguiti prima che compaia qualcosa, al markup, che il browser può mostrare man mano che arriva.

## Da dove veniva il peso

Due librerie venivano caricate in anticipo su ogni pagina dei report:

- **MapLibre GL**, la libreria per le mappe interattive: un solo script da 1,08 MB.
- **Recharts**, la libreria per i grafici: 476 KB.

Sono due ottimi strumenti, e sono quelli a cui si ricorre quando si vuole una mappa da trascinare o un grafico che reagisce al mouse. Ma la pagina di un report è soprattutto da leggere. La maggior parte dei visitatori non trascina mai la mappa, e Google di certo no.

## Cosa abbiamo cambiato

Il commit si chiama "rewritten heavy pages to have less html and js" e fa due cose:

- **I grafici sono disegnati sul server come semplice SVG.** L'SVG è un'immagine fatta di testo, quindi il grafico fa parte della pagina quando arriva e non serve nessuna libreria per mostrarlo.
- **Le mappe sono immagini statiche generate in fase di build**, al posto di una mappa interattiva che il browser deve montare. Né MapLibre né Recharts vengono più scaricate sulle pagine dei report.

Quello a cui abbiamo rinunciato è il trascinamento e gli effetti al passaggio del mouse su quelle pagine. Per un report ci sembra uno scambio giusto.

Dopo la modifica, il test live in Search Console si completa.

## Cosa fare sul tuo sito

- **Esegui il test live sulle tue pagine più pesanti.** In Search Console ispeziona l'URL, poi "Test live URL". Una pagina che funziona per i visitatori può comunque fallire qui.
- **Guarda cosa viene caricato prima che la pagina possa mostrare qualcosa.** Gli strumenti per sviluppatori del browser, scheda Network, elencano gli script e il loro peso. Una libreria per mappe, per grafici o un page builder usato in una sola sezione è il colpevole più comune.
- **Non caricare una libreria pesante su ogni pagina per un solo widget.** Caricala dove serve, o sostituiscila con qualcosa di più semplice dove basta un'immagine.
- **Tieni il contenuto nell'HTML.** Se ciò che vuoi far leggere a Google arriva solo dopo l'esecuzione degli script, stai cercando guai.

Se vuoi una prima occhiata al tuo sito, fai il nostro [audit SEO gratuito](https://www.nfw.run/audit-seo). Se preferisci che qualcuno sistemi quello che emerge, è per questo che esiste la nostra [agenzia SEO](https://www.nfw.run/agenzia-seo).

## Servizi collegati

Se vuoi passare dalla lettura al lavoro:

- [Agenzia SEO](https://www.nfw.run/agenzia-seo)

## Altri articoli

[Tutti gli articoli](https://www.nfw.run/articoli)

![Copertina del video: PHP2Shell, due falle di PHP, NFW Web Studio](https://www.nfw.run/blog/php2shell-php-vulnerability/video-poster-it.webp)Video

22 ottobre 2026SicurezzaStato del web

### [PHP2Shell: due falle di PHP su metà dei siti analizzati](https://www.nfw.run/articoli/php2shell-vulnerabilita-php)

Due falle gravi di PHP possono dare il controllo di un sito senza password. Cosa chiedere all'hosting, versioni coinvolte e cosa mostrano i nostri dati.

Guarda il video

![Aziende di Milano: velocità, Google e AI misurate a ottobre 2026, con il contorno della città](https://www.nfw.run/blog/milan-websites-state-of-the-web/cover-it.webp)

20 ottobre 2026Stato del webPresenza online

### [I siti web delle aziende di Milano: cosa abbiamo trovato](https://www.nfw.run/articoli/siti-web-aziende-milano-stato-del-web)

Abbiamo scansionato 27.460 siti di attività di Milano: le stesse pagine mobile lente di Verona, un divario nella leggibilità AI, pochi dati strutturati.

Leggi l'articolo

![Aziende di Verona: velocità, Google e AI misurate a ottobre 2026, con il contorno della città](https://www.nfw.run/blog/verona-websites-state-of-the-web/cover-it.webp)

14 ottobre 2026Stato del webPresenza online

### [I siti web delle aziende di Verona: cosa abbiamo trovato](https://www.nfw.run/articoli/siti-web-aziende-verona-stato-del-web)

Abbiamo scansionato quasi 5.000 siti di attività di Verona: pagine mobile lente, pochi dati strutturati, immagini in formati vecchi e siti senza HTTPS.

Leggi l'articolo

## Hai un progetto in mente? Parliamone.

[Tutti gli articoli](https://www.nfw.run/articoli) [Prenota una chiamata](https://www.nfw.run/contatti)
