Rendering e SEO

TL;DR — Il rendering è il passaggio in cui un motore di ricerca esegue il codice della tua pagina — incluso JavaScript — in un browser per costruire la pagina finale, così può vedere i tuoi contenuti e i link. Google lo fa praticamente per ogni pagina nel suo Web Rendering Service, e di solito funziona. Come il tuo sito produce il suo HTML (server, browser, o al momento della build) determina quanto sei al sicuro.

Cos’è il rendering

Quando apri una pagina, il tuo browser scarica un po’ di HTML, poi esegue CSS e JavaScript per costruire la pagina che vedi effettivamente. I motori di ricerca fanno lo stesso. Il rendering è il passaggio in cui un motore di ricerca esegue il codice della tua pagina per costruire la versione finale della pagina, così può leggere il contenuto e seguire i link come fai tu.

Si colloca nel mezzo di come Google gestisce una pagina:

1. Crawl — Google scarica l’HTML grezzo del tuo URL.
2. Render — Google esegue il JavaScript della pagina in un browser per costruire la pagina finale.
3. Index — Google legge quella pagina finale e la archivia.

Se il tuo contenuto appare solo dopo l’esecuzione di JavaScript, Google deve eseguire il rendering della pagina con successo prima di poterla vedere. Quindi il rendering è il ponte tra il recupero di una pagina e la sua comprensione.

Google esegue il rendering in un browser reale (ma insolito)

Il renderer di Google si chiama Web Rendering Service (WRS). È un Chrome headless che è “evergreen”, il che significa che tiene il passo con la versione corrente di Chrome e supporta le moderne funzionalità web. Quindi la vecchia paura — “Google non può eseguire JavaScript” — non è vera. Può farlo. Evidence for this claim Google Search runs JavaScript with an evergreen version of Chromium. Scope: Google's Web Rendering Service; browser support does not guarantee that every application-specific interaction or resource will work. Confidence: high · Verified: 2026-07-14 Google Search Central: Fix Search-related JavaScript problems

È solo un browser insolito. Non scorre né clicca, dimentica tutto tra le pagine (non resta connesso), e memorizza nella cache i file in modo aggressivo. Queste stranezze sono la fonte della maggior parte delle sorprese, e la scheda Avanzate le copre.

La grande scelta: dove viene costruito il tuo HTML

La decisione più importante per la SEO è dove viene prodotto l’HTML della tua pagina:

• Nel browser (rendering lato client) — il server invia una pagina quasi vuota e JavaScript costruisce tutto. Il più rischioso per la ricerca.
• Sul server (rendering lato server) — il server invia una pagina completa. Sicuro.
• Al momento della build (statico / prerendering) — le pagine vengono costruite una volta, in anticipo. Il più sicuro e veloce.

La maggior parte dei framework moderni mescola queste opzioni. La regola pratica: se il tuo contenuto importante è nell’HTML prima che qualsiasi JavaScript venga eseguito (o arriva quasi immediatamente), sei in buona forma.

Vuoi la versione più approfondita — come si comporta effettivamente il Web Rendering Service, se “due ondate di indicizzazione” è ancora una cosa, e un confronto completo di ogni opzione di rendering? Passa alla scheda Avanzate. Per i problemi pratici di JavaScript e le soluzioni, vedi JavaScript SEO.

TL;DR — Google esegue il rendering del tuo JS in un Chromium headless evergreen — il Web Rendering Service — per costruire il DOM che indicizza. Succede praticamente per tutte le pagine, di solito entro secondi-minuti, quindi “due ondate di indicizzazione” è in gran parte superato e non c’è un budget di rendering per pagina. Il WRS è stateless, rifiuta i prompt di autorizzazione, non interagisce con la pagina e memorizza nella cache in modo aggressivo. La tua opzione di rendering determina il tuo rischio SEO: SSR / statico / prerendering / hydration sono a basso rischio; il CSR completo è quello rischioso; il rendering dinamico è un workaround che Google sconsiglia. Per i problemi pratici di JS che questo crea, vedi JavaScript SEO.

Dove si colloca il rendering

Google indica tre fasi per le app JavaScript: “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traduzione) «Google elabora le app web JavaScript in tre fasi principali: 1. Crawling, 2. Rendering, 3. Indicizzazione». Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Il rendering fa da ponte: il crawling recupera l’HTML grezzo, il rendering esegue JavaScript per costruire il DOM finale e l’indicizzazione legge quel DOM; i nuovi link trovati tornano al crawling. Google spiega: “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (traduzione) «Durante il crawl, Google renderizza la pagina ed esegue il JavaScript trovato con una versione recente di Chrome, in modo simile al browser».

Il Web Rendering Service

Google renderizza nel Web Rendering Service (WRS), un Chrome headless evergreen. “While Google Search runs JavaScript with an evergreen version of Chromium…” (traduzione) «La Ricerca Google esegue JavaScript con una versione evergreen di Chromium…». Il WRS segue Chrome corrente, quindi supporta le moderne funzionalità JavaScript e CSS.

Il problema è che il WRS è un browser peculiare, e le sue stranezze causano la maggior parte dei problemi reali:

• È stateless. Come scrivo nella guida SEO per JavaScript, “Google loads each page stateless like it’s a fresh load.” (traduzione) «Google carica ogni pagina senza stato, come un nuovo caricamento». La documentazione precisa: “Local Storage and Session Storage data are cleared across page loads” (traduzione) «i dati di Local Storage e Session Storage vengono cancellati tra i caricamenti» e “HTTP Cookies are cleared across page loads.” (traduzione) «i cookie HTTP vengono cancellati tra i caricamenti». Non affidare i contenuti a stato persistente lato client.
• Rifiuta le autorizzazioni. “Expect Googlebot to decline user permission requests.” (traduzione) «Aspettati che Googlebot rifiuti le richieste di autorizzazione». I contenuti dietro richieste di geolocalizzazione, notifiche o fotocamera non vengono renderizzati.
• Non interagisce. Non scorre, non fa clic e non passa il puntatore; i contenuti caricati solo da questi eventi restano invisibili. È la causa di molti errori di lazy loading e infinite scroll; le soluzioni sono nella pagina SEO per JavaScript.
• Usa la cache in modo aggressivo. “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (traduzione) «Googlebot usa intensamente la cache per ridurre richieste di rete e risorse; il WRS può ignorare gli header di cache». Google può quindi eseguire JS o CSS obsoleti. Applica il fingerprint ai nomi, per esempio app.4f2a9c.js, così una modifica impone un nuovo recupero.

Un esperimento del 2026: cinque secondi non sono un muro di esecuzione rigido

Un esperimento WRS di terze parti riportato a luglio 2026 ha testato JavaScript ritardato e attività di rete invece di assumere un timeout di cinque secondi. Il renderer osservato usava un orologio virtuale e completava richieste ritardate che richiedevano circa 6–12 secondi di tempo reale. Il risultato utile è limitato: contraddice la regola di audit comune che qualsiasi cosa avvenga dopo esattamente cinque secondi sia automaticamente invisibile a Google. Non prova che ogni dipendenza ritardata verrà completata, che Google aspetti indefinitamente, o che la consegna lenta lato client sia sicura.

Leggi l’esperimento e la sua metodologia come evidenza di terze parti insieme alla dichiarazione ufficiale di Google che i tempi della coda di rendering non hanno un ritardo fisso pubblicato. In pratica, testa il DOM finale e le risorse richieste. Una risposta API mancante, un requisito di interazione, uno script bloccato o una dipendenza di stato rimangono un vero fallimento di rendering anche quando una “regola dei cinque secondi” basata su cronometro non lo è.

Le “due ondate di indicizzazione” esistono ancora?

Per anni il modello mentale è stato “due ondate di indicizzazione”: Google indicizzava l’HTML raw prima, poi tornava giorni o settimane dopo per renderizzare e indicizzare il contenuto JavaScript. Quel modello è ora in gran parte superato. Martin Splitt ha detto che l’idea delle due ondate ha un ruolo sempre minore, che molte pagine passano attraverso la fase di rendering anche quando non dipendono da JavaScript, e che crawling, rendering e indicizzazione stanno convergendo nel tempo.

In pratica il rendering riguarda quasi ogni pagina ed è normalmente rapido. La documentazione attuale afferma che una pagina sottoposta a crawl “may stay on this queue for a few seconds, but it can take longer than that” (traduzione) «può restare in questa coda per alcuni secondi, ma può richiedere più tempo»: non è pubblicato alcun ritardo o timeout fisso. Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: 2026-07-25 Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. Come dato storico, Martin Splitt e Tom Greenaway indicarono una mediana di circa cinque secondi e un 90° percentile in minuti, non le «settimane» del vecchio timore. Cito il dato nella guida SEO per JavaScript, ma è un dato di conferenza datato, non una metrica corrente ripubblicata da Google; la citazione sulla coda resta l’inquadramento ufficiale.

E non esiste nessun budget di rendering nel modo in cui la gente immagina. Google non tiene traccia di un punteggio per pagina “quanto è costoso renderizzare” che devi conservare. Il rendering è economico alla scala di Google — ottimizza per i tuoi utenti e le prestazioni, non per un fantomatico budget di rendering.

Le opzioni di rendering

“Dove viene costruito l’HTML?” è la domanda che decide il tuo rischio SEO. Il menu completo:

• Rendering lato client (CSR). Il server invia un guscio quasi vuoto e il browser o WRS esegue JavaScript per costruire tutto. È “the most problematic one … full client-side rendering where all of the rendering happens in the browser.” (traduzione) «l’opzione più problematica: il rendering completo lato client, in cui tutto avviene nel browser». Può funzionare, ma dipende interamente dal successo del rendering ed è il più lento da indicizzare.
• Rendering lato server (SSR). Il server costruisce l’HTML completo per ogni richiesta. Il contenuto è nell’HTML grezzo, quindi il rischio per la ricerca è basso.
• Generazione statica (SSG)／prerendering. L’HTML viene costruito una volta al deploy. È il rischio minimo: contenuto nell’HTML grezzo e caricamento rapido.
• Hydration (isomorfa／universale). SSR o SSG produce il primo rendering, poi JavaScript lo rende interattivo nel browser. È il modello di molti framework moderni e ha rischio basso, purché mismatch di hydration non cancellino o sostituiscano contenuti.
• Incremental Static Regeneration (ISR). Pagine statiche rigenerate a intervalli o su richiesta: freschezza maggiore di SSG, utile per cataloghi vasti.
• Edge rendering. SSR sui nodi edge della CDN: stesso rischio basso di SSR e time-to-first-byte più rapido per un pubblico globale.
• Streaming SSR. HTML inviato a blocchi appena pronto. Il rischio è basso, ma il contenuto indicizzabile non deve restare confinato in un blocco tardivo o differito.

La conclusione della mia guida SEO per JavaScript è: “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (traduzione) «Qualsiasi configurazione SSR, statica o di prerendering va bene per i motori di ricerca; Gatsby, Next, Nuxt e simili sono ottimi». Il framework conta meno della modalità distribuita: la stessa app Next.js è sicura con SSR／SSG o rischiosa con CSR completo.

Rendering dinamico — un workaround, non una strategia

Il rendering dinamico rileva i bot e serve loro una versione prerenderizzata senza JavaScript, mentre gli utenti ricevono quella lato client. Google è esplicito: “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines,” (traduzione) «il rendering dinamico era un workaround, non una soluzione a lungo termine ai problemi dei contenuti generati con JavaScript nei motori di ricerca», e “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (traduzione) «è un workaround non consigliato, perché aggiunge complessità e requisiti di risorse». Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: 2026-07-14 Google Search Central: Dynamic rendering as a workaround Concordo: non l’ho mai consigliato e sono lieto che Google lo sconsigli. Servire contenuti diversi a bot e utenti è vicino al cloaking; preferisci SSR, statico o hydration.

Una complicazione: Bing suggerisce ancora il rendering dinamico. Microsoft afferma “bingbot is generally able to render JavaScript” (traduzione) «bingbot è generalmente in grado di renderizzare JavaScript», ma osserva che farlo su vasta scala è difficile; perciò “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (traduzione) «consigliamo il rendering dinamico come valida alternativa per i siti che dipendono fortemente da JavaScript». In pratica, SSR／SSG soddisfa entrambi i motori ed evita il dibattito.

Cosa significa per i tuoi contenuti

Il rendering determina se Google vedrà mai i contenuti JavaScript, ma vederli è solo metà del lavoro. Dopo il rendering, i problemi pratici riguardano link reali <a href>, parità dei singoli campi tra HTML grezzo e renderizzato, ordine delle direttive robots, contenuti lazy, infinite scroll e risposte soft not-found. La pagina SEO per JavaScript tratta questi aspetti e il flusso di test con HTML renderizzato, screenshot e console di URL Inspection.

Questa è la fase di rendering del percorso di ricerca. Per le fasi adiacenti, vedi crawling (come vengono recuperate le pagine) e indexing (cosa succede alla pagina renderizzata successivamente), oppure l’hub Come funziona la Ricerca Google per l’intero percorso.

Una regola di audit vale la pena di tenere a mente qui: renderizzato è uno stato, non un vincitore universale. Per il contenuto del corpo e i link crawlable, il DOM renderizzato mostra cosa il JavaScript riuscito ha aggiunto o rimosso. Per titoli e descrizioni, mostra input aggiuntivi, mentre Google può ancora generare un title link o uno snippet da altre fonti. Per le direttive robots, un noindex grezzo può impedire il rendering, quindi la rimozione tramite JavaScript è asimmetrica. Per il canonical, Google consiglia di usare una sola fonte o un valore impostato tramite JavaScript piuttosto che modificare un valore esistente. E JavaScript non può cambiare lo stato della risposta HTTP già ricevuta. Tieni separate queste colonne nelle prove e usa l’attuale guida JavaScript SEO di Google per il comportamento specifico del campo.

Riepilogo AI

Una sintesi della versione Advanced:

• Il rendering collega crawling e indicizzazione. Google esegue il JS in Chromium headless evergreen, il Web Rendering Service, per costruire il DOM da indicizzare. Le fasi sono crawl → render → index.
• Le «due ondate di indicizzazione» sono in gran parte superate (Splitt). Il rendering riguarda quasi tutte le pagine ed è normalmente rapido. La documentazione attuale dice che una pagina “may stay on this queue for a few seconds, but it can take longer than that” (traduzione) «può restare in questa coda per alcuni secondi, ma può richiedere più tempo»: non è pubblicato un ritardo fisso. La mediana di circa cinque secondi e il 90° percentile in minuti sono dati storici di conferenza, non una metrica corrente. Non esiste un render budget per pagina.
• Il WRS è un browser insolito: è stateless, cancella localStorage e cookie tra i caricamenti, rifiuta le richieste di autorizzazione, non scorre, non fa clic e non passa il puntatore, e memorizza JS/CSS in cache in modo aggressivo. Usa nomi di file con fingerprint.
• Rischio SEO delle opzioni: SSG／prerendering (minimo) ≈ SSR ≈ hydration ≈ ISR ≈ edge／streaming (basso) ≪ CSR completo (massimo). Patrick afferma che SSR, rendering statico e prerendering sono ottimi, mentre il CSR completo è il più problematico.
• Il rendering dinamico è un workaround sconsigliato da Google e vicino al cloaking. Bing lo consiglia ancora, ma SSR／SSG soddisfa entrambi.
• Il rischio dipende dalla modalità di rendering, non dal framework. La stessa app può essere sicura con SSR／SSG o rischiosa con CSR completo.
• Il rendering è metà del lavoro. Link, parità, contenuti lazy, infinite scroll, risposte soft not-found e test sono trattati nella pagina SEO per JavaScript.

Documentazione ufficiale

Documentazione di fonte primaria dai motori di ricerca.

Google

• Comprendi le basi della SEO per JavaScript — le tre fasi (crawl → render → index) e il renderer Chromium evergreen.
• Risolvi i problemi JavaScript legati alla ricerca — i vincoli del WRS: storage/cookie senza stato, permessi rifiutati, caching aggressivo.
• Il rendering dinamico come soluzione alternativa — perché il rendering dinamico è una soluzione alternativa, non una soluzione consigliata a lungo termine.
• Guida approfondita su come funziona la Ricerca Google — dove si colloca il rendering nel percorso crawl → index → serve.

Bing / Microsoft

• Serie bingbot: JavaScript, rendering dinamico e cloaking. Oh mamma! — La posizione di Bing secondo cui può eseguire il rendering di JS ma consiglia il rendering dinamico su larga scala.
• Il nuovo Bingbot evergreen — Rendering di Bingbot su Microsoft Edge basato su Chromium.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google e Bing (più alcune tratte dai miei scritti). Ogni link al motore di ricerca è un deep link che salta al passaggio citato nella pagina di origine.

Google — la pipeline di rendering

• “Google processes JavaScript web apps in three main phases: 1. Crawling 2. Rendering 3. Indexing.” (traduzione) «Google elabora le app web JavaScript in tre fasi principali: crawling, rendering e indicizzazione». Vai alla citazione
• “During the crawl, Google renders the page and runs any JavaScript it finds using a recent version of Chrome, similar to how your browser renders pages you visit.” (traduzione) «Durante il crawl, Google renderizza la pagina ed esegue il JavaScript trovato con una versione recente di Chrome, in modo simile al browser». Vai alla citazione
• “While Google Search runs JavaScript with an evergreen version of Chromium…” (traduzione) «La Ricerca Google esegue JavaScript con una versione evergreen di Chromium…» Vai alla citazione
• “The page may stay on this queue for a few seconds, but it can take longer than that.” (traduzione) «La pagina può restare in questa coda per alcuni secondi, ma può richiedere più tempo». È l’attuale formulazione ufficiale e non pubblica un ritardo fisso. Vai alla citazione

Google — il Web Rendering Service

• “Local Storage and Session Storage data are cleared across page loads.” (traduzione) «I dati di Local Storage e Session Storage vengono cancellati tra i caricamenti delle pagine.» Vai alla citazione
• “HTTP Cookies are cleared across page loads.” (traduzione) «I cookie HTTP vengono cancellati tra i caricamenti delle pagine.» Vai alla citazione
• “Expect Googlebot to decline user permission requests.” (traduzione) «Aspettati che Googlebot rifiuti le richieste di permesso degli utenti.» Vai alla citazione
• “Googlebot caches aggressively in order to reduce network requests and resource usage. WRS may ignore caching headers.” (traduzione) «Googlebot memorizza nella cache in modo aggressivo per ridurre le richieste di rete e l’uso delle risorse. Il WRS può ignorare le intestazioni di cache.» Vai alla citazione

Google — rendering dinamico

• “Dynamic rendering was a workaround and not a long-term solution for problems with JavaScript-generated content in search engines.” (traduzione) «Il rendering dinamico era una soluzione temporanea e non una soluzione a lungo termine per i problemi con i contenuti generati da JavaScript nei motori di ricerca.» Vai alla citazione
• “Dynamic rendering is a workaround and not a recommended solution, because it creates additional complexities and resource requirements.” (traduzione) «Il rendering dinamico è una soluzione temporanea e non una soluzione consigliata, perché crea complessità e requisiti di risorse aggiuntivi.» Vai alla citazione

Microsoft Bing

• “bingbot is generally able to render JavaScript…” (traduzione) «bingbot è generalmente in grado di eseguire il rendering di JavaScript…» Vai alla citazione
• “we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (traduzione) «consigliamo il rendering dinamico come una grande alternativa per i siti web che fanno molto affidamento su JavaScript.» Vai alla citazione

Martin Splitt, Google (trasmesso tramite la trascrizione di Onely di un hangout del Webmaster Central del 2019)

• Sul modello a due ondate: Splitt ha detto che gioca un ruolo sempre minore, che molti siti attraversano la fase di rendering anche senza JavaScript e che crawling, rendering e indicizzazione stanno convergendo. Leggi la copertura

Patrick Stox (mio lavoro — JavaScript SEO: A Definitive Guide)

• “Google loads each page stateless like it’s a fresh load.” (traduzione) «Google carica ogni pagina senza stato, come se fosse un caricamento nuovo.»
• “pages went to the renderer at a median time of five seconds” (90° percentile in minuti) — un dato di un’era di conferenze ormai datato, non una metrica pubblicata attuale; vedi la citazione ufficiale sui tempi di coda sopra. (traduzione) «le pagine sono andate al renderer con un tempo mediano di cinque secondi»
• “The most problematic one is going to be full client-side rendering where all of the rendering happens in the browser.” (traduzione) «Il caso più problematico sarà il rendering completamente lato client, dove tutto il rendering avviene nel browser.»
• “Any kind of SSR, static rendering, and prerendering setup is going to be fine for search engines. Gatsby, Next, Nuxt, etc., are all great.” (traduzione) «Qualsiasi tipo di configurazione SSR, rendering statico o prerendering andrà bene per i motori di ricerca. Gatsby, Next, Nuxt, ecc. sono tutti ottimi.»

I modelli mentali

1. Crawl → render → index. Il rendering è il ponte. Il crawling recupera l’HTML grezzo; il rendering esegue il JS per costruire il DOM; l’indicizzazione legge quel DOM. Quando i contenuti JS mancano, chiediti quale passaggio è fallito — è stato recuperato? è stato renderizzato? il DOM renderizzato conteneva il contenuto?

2. Il renderer è un browser reale con amnesia. Chrome Evergreen, ma senza stato (dimentica cookie/archiviazione tra le pagine), nessuna interazione (non scorre né clicca) e amante della cache (può eseguire JS/CSS obsoleti). Progetta come se ogni visita fosse un primo caricamento nuovo, intatto e mai toccato.

3. La modalità di rendering decide il tuo rischio, non il tuo framework. SSR, statico, prerender e hydration mettono tutti i contenuti nel DOM (o rapidamente) — rischio basso. Il CSR completo scommette tutto sul rendering — rischio massimo. La stessa app Next.js è sicura o rischiosa a seconda della modalità che pubblichi.

4. “Due ondate” è la vecchia mappa. Non pianificare in base a una seconda ondata di rendering differita di giorni. Il rendering avviene per praticamente tutte le pagine, di solito entro secondi o minuti — e non c’è un budget di rendering da razionare.

5. Il rendering dinamico è un campanello d’allarme, non una strategia. Servire ai bot HTML diverso da quello degli utenti è una soluzione temporanea che Google sconsiglia (ed è vicino al cloaking). Se stai ricorrendo a questo, la vera soluzione è di solito SSR/SSG.

6. Porta il contenuto nel DOM, poi verifica. Scegli una modalità che inserisca rapidamente il contenuto nel DOM renderizzato, poi conferma con l’HTML renderizzato di URL Inspection. Il tuo browser non è Googlebot.

Opzioni di rendering — compromessi SEO

Web Rendering Service — fatti rapidi

Checklist di audit per la prontezza del rendering

Una verifica per confermare che i tuoi contenuti importanti sopravvivano effettivamente al rendering:

• Il contenuto primario e i link di navigazione principali sono presenti nell’HTML grezzo (visualizza sorgente, non il DOM ispezionato di DevTools) — non iniettati solo dopo l’esecuzione di JavaScript.
• Ogni link interno che un lettore deve seguire è un vero <a href="..."> — non un <div onclick>, una rotta solo hash (#/page), o un pulsante che spinge lo stato client-side senza un link corrispondente.
• Nessun file JS o CSS critico è bloccato in robots.txt (un bundle bloccato può impedire al WRS di costruire la pagina che deve renderizzare).
• I contenuti che si caricano su scroll, hover o click hanno anche un percorso che renderizza senza alcuna interazione — il WRS non scorre, non clicca, non passa sopra.
• Nulla di importante dipende da localStorage, sessionStorage o cookie persistenti tra le richieste — il WRS è stateless e cancella tutto tra i caricamenti di pagina.
• Nulla di importante si trova dietro un prompt di autorizzazione per geolocalizzazione, notifiche o fotocamera — il WRS li rifiuta per impostazione predefinita.
• I nomi file JS/CSS hanno fingerprint (app.4f2a9c.js) così una modifica al contenuto forza un nuovo fetch invece di essere servita dalla cache aggressiva del WRS.
• L’HTML renderizzato/screenshot di URL Inspection in Google Search Console mostra lo stesso contenuto e gli stessi link che vedi nel tuo browser.
• Il sito non sta usando il rendering dinamico come risposta a un problema CSR — la soluzione è SSR, rendering statico o hydration, non servire ai bot una versione diversa della pagina.

Errori di rendering che mordono davvero

Bloccare il JS o CSS necessario al rendering della pagina, in robots.txt. Se il WRS non riesce a recuperare uno script o un foglio di stile da cui la pagina dipende, non può costruire un DOM renderizzato accurato — ottieni un rendering rotto o vuoto invece della pagina che intendevi. Fai invece: consenti la scansione delle tue risorse JS/CSS; robots.txt dovrebbe tenere i bot fuori dagli spazi a basso valore, non dalle risorse di cui le tue pagine hanno bisogno.

Pubblicare pagine critiche per i contenuti come rendering client-side completo (CSR) senza fallback. Il CSR è “il più problematico … rendering client-side completo dove tutto il rendering avviene nel browser” — scommette l’intera pagina sul successo del rendering, ed è l’opzione più lenta per essere indicizzata. Fai invece: ricorri a SSR, generazione statica/prerendering o idratazione così che i contenuti siano (o entrino molto rapidamente) nell’HTML grezzo.

Affidarsi a rotte basate su hash (#/product/123) come unica navigazione. Il WRS segue veri link <a href>; un frammento hash che cambia solo lo stato client-side, senza un URL equivalente renderizzato lato server, non dà al renderer nulla da seguire. Fai invece: usa percorsi reali a cui il server può rispondere direttamente (/product/123), anche in un’app pesante sul client.

Caricare pigramente contenuti senza un percorso non interattivo per raggiungerli. Poiché il WRS “non scorre, non clicca e non passa il mouse,” i contenuti che appaiono solo dopo uno di questi eventi sono invisibili per impostazione predefinita. Fai invece: carica i contenuti sopra la piega e ragionevolmente vicini al viewport senza richiedere un’interazione, e riserva il vero lazy-loading per contenuti genuinamente sotto la piega con un adeguato fallback non-JS.

Trattare il rendering dinamico come una soluzione a lungo termine invece che come un workaround. Google è esplicito: “il rendering dinamico è un workaround e non una soluzione raccomandata, perché crea complessità aggiuntive e requisiti di risorse” — e servire ai bot contenuti diversi da quelli degli utenti si avvicina pericolosamente al cloaking. Fai invece: correggi la modalità di rendering stessa (SSR/statico/idratazione) piuttosto che costruire un livello di rilevamento bot attorno a un problema CSR.

Test di validazione

Controlli pass/fail per confermare che una correzione del rendering abbia effettivamente avuto effetto — eseguili dopo aver pubblicato la modifica, non come metrica di salute continua.

Test: il contenuto ora appare nel DOM renderizzato

• Test da eseguire — Invia l’URL allo strumento URL Inspection di Google Search Console e usa “Test Live URL,” quindi apri la scheda HTML renderizzato (o esegui la pagina attraverso lo strumento Render Gap per confrontare direttamente HTML grezzo vs. renderizzato).
• Risultato atteso — Il contenuto che hai aggiunto o corretto appare nella vista HTML/DOM renderizzato, non solo negli strumenti di sviluppo del tuo browser.
• Interpretazione del fallimento — Se manca ancora dall’HTML renderizzato ma è presente quando visualizzi la pagina normalmente, il WRS non riesce ancora a costruirlo — controlla una risorsa JS/CSS bloccata, un caricamento solo su interazione o una dipendenza dallo storage client prima di presumere che la correzione abbia funzionato.
• Finestra di monitoraggio — Immediata; il test live di URL Inspection riflette lo stato attuale dell’URL subito.
• Trigger di rollback — L’HTML renderizzato non contiene ancora il contenuto dopo la correzione, o il test live genera un nuovo errore di scansione/rendering che non generava prima.

Test: i link importanti sopravvivono al rendering

• Test da eseguire — Controlla l’HTML renderizzato (URL Inspection o Render Gap) per veri tag <a href> attorno a ogni link che un lettore deve seguire, non solo elementi cliccabili visibili.
• Risultato atteso — Ogni link nel DOM renderizzato ha un href risolvibile che punta a un URL reale e scansionabile.
• Interpretazione del fallimento — Un href mancante o vuoto su quello che sembra un link funzionante di solito significa che è un <div>/<button> con un gestore di clic client-side e nessun percorso renderizzabile lato server — il WRS non può seguirlo.
• Finestra di monitoraggio — Immediata.
• Trigger di rollback — I link che contavano prima della modifica mancano di attributi href o puntano a un frammento solo hash nell’output renderizzato.

Test: la correzione non regredisce silenziosamente al prossimo deploy

• Test da eseguire — Esegui di nuovo il controllo dell’HTML renderizzato (test live di URL Inspection o Render Gap) dopo il prossimo deploy che tocca i template di questa pagina o la pipeline di build.
• Risultato atteso — Gli stessi contenuti e link sono ancora presenti nel DOM renderizzato come quando hai confermato la correzione per la prima volta.
• Interpretazione del fallimento — Se il contenuto che era presente scompare di nuovo, una modifica successiva ha probabilmente reintrodotto una dipendenza solo client o ha rotto un percorso renderizzato lato server.
• Finestra di monitoraggio — Ricontrolla dopo ogni deploy che tocca i template interessati; non è un controllo una tantum.
• Trigger di rollback — Contenuti o link che erano stati confermati presenti escono di nuovo dal DOM renderizzato.

Risorse che meritano il tuo tempo

I miei scritti correlati

• JavaScript SEO: A Definitive Guide — la mia guida completa su rendering, modalità di rendering, parità DOM, scroll infinito e il problema delle due pagine come una sola.
• The Beginner’s Guide to Technical SEO — dove il rendering si colloca tra crawling e indicizzazione.

I miei interventi

• How Search Works (SlideShare) — la mia spiegazione di crawling, rendering (il WRS, caricamenti senza stato, nessuna interazione), indicizzazione e ranking. (Vale la mia dichiarazione standard: “This is my understanding of systems… not going to be 100% complete or accurate.” (traduzione) «Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.»)

Da altri

• web.dev — Rendering on the Web — la spiegazione canonica dei compromessi tra CSR / SSR / SSG / hydration dal team di Chrome.
• Onely — Google’s Two Waves of Indexing — copertura basata sulla trascrizione della sessione di office hours di Martin Splitt che spiega perché il modello delle due ondate sta svanendo; citato nel corpo dell’articolo.
• Search Engine Roundtable — Google: No Per-Page Search Cost — un rappresentante di Google chiarisce che non esiste un costo per pagina di crawl/render/index da razionare.
• Search Engine Journal — JavaScript SEO — copertura di settore delle best practice JS SEO, dei flussi di test e delle considerazioni sui framework.
• Vercel — Rendering Strategies — documentazione su Next.js/edge rendering; utile quando si sceglie tra CSR, SSR, SSG, ISR e streaming SSR per un progetto reale.
• r/TechSEO — la community per il debug dei problemi di render/index.

Video

• Google Search Central (YouTube) — la serie JavaScript SEO di Martin Splitt e gli explainer sul rendering sono i migliori video ufficiali che spiegano come il Web Rendering Service gestisce il tuo JS. Canale

Statistiche da citare

• Inquadramento ufficiale corrente: nessun ritardo fisso. La documentazione dice che una pagina sottoposta a crawl “may stay on this queue for a few seconds, but it can take longer than that” (traduzione) «può restare in questa coda per alcuni secondi, ma può richiedere più tempo». Non è pubblicato alcun ritardo o timeout fisso per la coda.
• Dato storico datato: mediana di circa cinque secondi. In precedenti conferenze Martin Splitt e Tom Greenaway indicarono una mediana di circa cinque secondi, con il 90° percentile in minuti, non le «settimane» associate alle due ondate. Lo cito nella guida SEO per JavaScript, ma come dato storico, non come metrica corrente ripubblicata da Google.
• Le due ondate di indicizzazione stanno svanendo. Secondo Splitt, il modello conta sempre meno mentre crawling, rendering e indicizzazione convergono; oggi il rendering riguarda quasi tutte le pagine. Approfondimento
• Nessun render budget per pagina. Google ha indicato che non registra un costo individuale da conservare per crawl, render, index o serving di una pagina. Approfondimento

Mettiti alla prova: Rendering

Cinque domande rapide su come Google renderizza le pagine. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche