SEO per JavaScript

TL;DR — La SEO JavaScript riguarda una sola domanda: i motori di ricerca riescono a vedere i tuoi contenuti? I siti moderni costruiscono gran parte della pagina nel browser con JavaScript. Se i tuoi testi e link importanti compaiono solo dopo l’esecuzione degli script, devi verificare che Google possa comunque raggiungerli. Di solito Google ci riesce — il problema sta nei dettagli.

Che cos’è la SEO JavaScript

Molti siti costruiscono parte (o tutta) della pagina nel browser con JavaScript. Il server invia un po’ di HTML, e poi gli script vengono eseguiti per riempire il contenuto, caricare più elementi, o cambiare vista senza un ricaricamento completo della pagina. JavaScript SEO è la pratica di assicurarsi che i motori di ricerca possano ancora eseguire la scansione, il rendering e l’indicizzazione di quel contenuto.

Ecco l’ordine in cui le cose accadono per Google:

1. Scansione — Google scarica l’HTML grezzo del tuo URL.
2. Rendering — Google esegue il JavaScript della pagina in un browser per costruire la pagina finale (il passaggio di rendering).
3. Indicizzazione — Google legge quella pagina finale e la archivia.

Google documenta queste come le tre fasi principali per l’elaborazione delle app web JavaScript.

Se il tuo contenuto appare solo dopo l’esecuzione di JavaScript, Google deve renderizzare la pagina con successo prima di poterla vedere. Nella maggior parte dei casi lo fa. Quando non lo fa, il tuo contenuto può sparire silenziosamente dalla ricerca.

Prima le buone notizie

JavaScript non è dannoso per la SEO. Google esegue una versione aggiornata di Chrome e può eseguire lo stesso JavaScript che usano i tuoi visitatori. La vecchia paura — “Google non può leggere JavaScript” — semplicemente non è più vera.

Ciò che può andare storto è più specifico:

• I tuoi contenuti richiedono un clic o uno scorrimento per essere caricati, e Google non clicca né scorre. Prova a sostegno di questa affermazione Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Ambito: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Fix lazy-loaded content
• I tuoi link non sono link reali (sono pulsanti o gestori di clic), quindi Google non può seguirli. Prova a sostegno di questa affermazione Google can reliably discover links only when they are HTML anchor elements with an href attribute. Ambito: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Make your links crawlable
• Hai accidentalmente bloccato i tuoi file JavaScript o CSS in robots.txt, quindi Google non può eseguire correttamente il rendering della pagina.
• La pagina appare corretta nel tuo browser, ma i contenuti non compaiono mai nella vista renderizzata di Google.

La semplice checklist

• Confronta il tuo HTML grezzo (tasto destro → Visualizza sorgente) con l’HTML renderizzato (strumento Controllo URL di Google Search Console). Se mancano contenuti importanti nella vista renderizzata, quello è il tuo problema.
• Assicurati che i link siano veri link <a href>, non gestori di clic su un <div>.
• Non bloccare i tuoi file JavaScript o CSS in robots.txt.
• Se una funzionalità richiede un clic o uno scorrimento per caricare contenuti, assicurati che quel contenuto sia anche raggiungibile in un altro modo.
• Per contenuti che devono assolutamente posizionarsi, preferisci il rendering lato server o una build statica/prerenderizzata, dove il contenuto è già nell’HTML grezzo. Prova a sostegno di questa affermazione Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Ambito: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Vuoi la versione più approfondita — i veri scenari di errore, la trappola dello scorrimento infinito che fa indicizzare due pagine come una sola, e come testare l’HTML renderizzato? Passa alla scheda Avanzate. Per capire come funziona il renderer di Google e quale configurazione di rendering scegliere, consulta la pagina rendering.

TL;DR — Google può eseguire il tuo JavaScript, quindi “Google può leggere JS?” è la domanda sbagliata. Le modalità di errore sono parità (DOM grezzo vs. renderizzato), interazione (Google non scorre né clicca), stato (il renderer è senza stato) e tempistica. Mantieni i link come veri anchor <a href>, non bloccare JS/CSS, carica in modo differito sul viewport non sull’interazione, restituisci stati reali per i 404 lato client e ricorda che un noindex grezzo può impedire il rendering prima che JavaScript possa rimuoverlo. Combina direttive che sono state effettivamente elaborate, ma non assumere un vincitore universale grezzo/renderizzato. Osserva lo scorrimento infinito in particolare: un viewport di rendering alto può attivare il loader e unire due URL in una sola pagina indicizzata. Per i dettagli interni del renderer e su quale modalità di rendering scegliere, vedi rendering.

Google è in grado di leggere JavaScript? Sì — non è questa la domanda

Google elabora le app JavaScript in tre fasi: “Google elabora le app web JavaScript in tre fasi principali: 1. Scansione 2. Rendering 3. Indicizzazione.” La fase intermedia esegue il tuo JS in una versione sempre aggiornata di Chrome headless per costruire il DOM che viene indicizzato. “Il rendering è importante perché i siti web spesso si affidano a JavaScript per portare contenuti alla pagina, e senza rendering Google potrebbe non vedere quel contenuto.”

Quindi Google può eseguire il tuo JavaScript. Le domande utili sono più specifiche:

• Parità — il DOM renderizzato contiene davvero ciò che pensi che contenga?
• Interazione — qualcosa richiede uno scorrimento o un clic che Google non eseguirà?
• Stato — stai facendo affidamento su cookie/localStorage che il renderer senza stato cancella?
• Tempistica — il contenuto critico è rimandato dietro JavaScript lento o tardivo?

Per quanto riguarda i tempi nello specifico: Google mette in coda una pagina scansionata (che ha restituito un 200) per il rendering, e “la pagina potrebbe rimanere in questa coda per alcuni secondi, ma può volerci più tempo di così.” Non esiste un ritardo o un timeout fisso pubblicato — e una pagina che restituisce uno stato non-200, o che inizia con una direttiva noindex, può saltare la coda di rendering invece di attendere che JavaScript la modifichi.

I meccanismi di come Google esegue il rendering — il Web Rendering Service, l’assenza di stato, la cache, il mito delle “due ondate” — sono trattati nella pagina rendering. Qui mi concentrerò sui problemi pratici e sulle soluzioni.

I link devono essere ancore <a href> reali

Questo è il bug JS-SEO singolo più comune. “Google può scoprire i tuoi link solo se sono elementi HTML <a> con un attributo href.” Un <div> cliccabile con un handler onclick è invisibile a Google come link — non verrà seguito, e le pagine che dipendono da esso per la scoperta possono rimanere non scansionate. È perfettamente accettabile iniettare link con JavaScript, purché finiscano come ancore <a href> reali nel DOM renderizzato. Quelle ancore renderizzate vengono analizzate dopo l’esecuzione di JavaScript, però — finire nel DOM renderizzato rende un link scopribile, ma non è una promessa che l’URL venga scansionato, indicizzato o trattato allo stesso modo di un link presente nell’HTML grezzo.

Contenuti con caricamento differito e subordinati all’interazione

Il renderer non si comporta come un utente curioso: “Google Search non interagisce con la tua pagina.” Nessuno scorrimento, nessun clic, nessun passaggio del mouse. Quindi qualsiasi contenuto che si carica solo su uno di questi eventi non verrà visto.

Linee guida di Google: carica il contenuto quando entra nel viewport, non quando l’utente agisce — “assicurati che la tua implementazione del caricamento differito carichi tutto il contenuto rilevante ogni volta che è visibile nel viewport,” e “non aggiungere il caricamento differito a contenuti che potrebbero essere immediatamente visibili quando un utente apre una pagina.” Usa IntersectionObserver o il nativo loading="lazy" per le immagini — mai un gestore di scorrimento o clic — così il contenuto viene caricato durante un rendering normale.

Scorrimento infinito: quando due pagine vengono indicizzate come una sola

Questo è il punto che quasi nessuno spiega, e vale l’intera sezione.

Googlebot può eseguire il rendering con un viewport considerevolmente più alto rispetto a una finestra del browser tipica. Google non pubblica una dimensione esatta del viewport di rendering — e può cambiare — quindi non progettare in base a un numero specifico; testa invece la tua implementazione. Ciò che conta è il meccanismo: se il tuo loader di scorrimento infinito si attiva in base alla posizione di scorrimento o all’altezza del viewport, un viewport di rendering più alto del previsto può attivare il loader durante il rendering stesso — e il contenuto del prossimo articolo o della pagina prodotto viene aggiunto nello stesso DOM. Ora il contenuto di due URL distinti è stato renderizzato insieme, e Google può indicizzarli come una pagina. Nella mia esperienza, “a volte, due pagine vengono indicizzate come una” — ho avuto pagine segnalate come “non indicizzate” che erano in realtà indicizzate come parte di un’altra pagina (di solito il post precedente nel feed), perché “quando Google ha ridimensionato il viewport per renderlo più lungo … ha attivato lo scorrimento infinito e ha caricato un altro articolo durante il rendering.” Conferma se la tua configurazione fa questo controllando l’HTML renderizzato nell’URL Inspection per una pagina che ti aspetteresti si fermi prima — non assumere una dimensione e non dare per scontato di essere al sicuro.

Ci sono due livelli per fare questo nel modo giusto.

Rendi lo scorrimento infinito indicizzabile fin dall’inizio. Supporta il caricamento paginato sotto lo scorrimento infinito. Ogni blocco dovrebbe avere “il proprio URL univoco e persistente,” il contenuto su ciascun URL dovrebbe rimanere lo stesso a ogni caricamento, dovresti evitare parametri relativi come ?date=yesterday, dovresti “collegare in sequenza agli URL individuali così che i motori di ricerca possano scoprire gli URL in un set paginato,” e quando un nuovo blocco viene caricato durante lo scorrimento dovresti “aggiornare l’URL visualizzato usando la History API.” Usa veri link di paginazione <a href> e URL univoci — “non usare identificatori di frammento URL” (la parte dopo un #) per i numeri di pagina, perché Google li ignora. Come dico nella mia guida SEO per JavaScript, “se hai una configurazione con scorrimento infinito, consiglio comunque una versione paginata della pagina così che Google possa ancora eseguire la scansione correttamente.”

Se un loader difettoso sta attivamente unendo le pagine, la soluzione più rapida è drastica: “blocca il file JavaScript che gestisce lo scorrimento infinito così la funzionalità non può attivarsi.” Se il loader non può eseguire durante il rendering, non può aggiungere il contenuto della pagina successiva, e ogni URL viene renderizzato come sé stesso di nuovo.

Soft-404 dopo il routing lato client

Le app a pagina singola possono sostituire i contenuti senza modificare il codice di stato HTTP, quindi una vista “non trovato” può comunque restituire 200. Google potrebbe classificare quella risposta come soft 404 dopo aver valutato il contenuto restituito, ma un fetch statico da solo non può dimostrare che Google abbia effettuato quella classificazione. Due soluzioni: naviga con l’History API e, per uno stato di non trovato reale, instrada verso un URL che restituisce un vero codice 404 oppure aggiungi un tag noindex. E non affidarti ai frammenti URL per il routing — “lo schema di scansione AJAX è stato deprecato dal 2015, quindi non puoi contare sui frammenti URL per funzionare con Googlebot.”

Un reindirizzamento lato client presenta lo stesso problema di evidenza: la risposta iniziale può rimanere 200 finché JavaScript non viene eseguito. Google supporta i reindirizzamenti JavaScript solo come fallback quando i reindirizzamenti lato server o meta-refresh non sono possibili. Segnala separatamente lo stato statico e la navigazione renderizzata osservata; non riscrivere lo stato HTTP nell’audit né chiamare ogni modifica dell’URL renderizzato un reindirizzamento.

Non bloccare JavaScript o CSS in robots.txt

Google non eseguirà il rendering di JavaScript da file bloccati o su pagine bloccate. Una regola robots.txt che disallowa il tuo bundle (o la directory /_next/, /static/, /assets/ in cui risiede) può compromettere completamente il rendering — Google recupera la shell, non riesce a eseguire gli script e indicizza una pagina vuota. Controlla le risorse della pagina nell’URL Inspection per qualsiasi elemento bloccato.

Parità DOM e direttive robots sensibili allo stadio

Confronta il tuo HTML grezzo (Visualizza sorgente) con l’HTML renderizzato (Ispezione URL). I contenuti presenti solo nell’HTML renderizzato vengono comunque indicizzati — se vengono renderizzati. I contenuti assenti in entrambi non esistono per Google.

C’è un rischio legato all’ordine delle fasi che Google documenta direttamente: “Quando Google incontra il tag noindex, può saltare il rendering e l’esecuzione di JavaScript, il che significa che usare JavaScript per modificare o rimuovere il tag robots meta da noindex potrebbe non funzionare come previsto.” Se il tuo HTML grezzo include un noindex iniziale che intendevi sostituire con JavaScript, Google può agire su quel noindex grezzo e non eseguire mai lo script che lo avrebbe rimosso.

Non trasformare questo in una regola universale del tipo “vince il rendering”. La riconciliazione è specifica per campo:

Questa matrice è il motivo per cui un revisore dovrebbe mantenere distinti lo stato di origine, quello renderizzato, quello delle intestazioni di risposta e quello osservato nella ricerca, invece di comprimerli in un unico valore “effettivo”.

Scegli una modalità di rendering che inserisca i contenuti nel DOM

La maggior parte del rischio SEO legato a JavaScript dipende da come viene prodotto l’HTML. In breve: SSR, rendering statico/pre-rendering e idratazione inseriscono i contenuti nel DOM (o li inseriscono rapidamente), riducendo quanto la tua visibilità dipenda dal successo del renderer; il rendering completamente lato client lascia più peso al completamento corretto e puntuale del rendering, ogni volta. Il rendering dinamico è una soluzione temporanea, non un’opzione equivalente — secondo le linee guida di Google aggiornate a dicembre 2025, viene descritto come un espediente anziché come una soluzione a lungo termine, e Google raccomanda invece rendering lato server, rendering statico o idratazione. Come ho scritto nella mia guida SEO su JavaScript, “qualsiasi configurazione con SSR, rendering statico e pre-rendering andrà bene per i motori di ricerca.” Il menu completo — CSR, SSR, SSG, idratazione, ISR, edge, streaming e rendering dinamico — con una tabella dei compromessi è nella pagina rendering. Google descrive separatamente il rendering lato server o il pre-rendering come una buona idea per utenti e crawler. Prova a sostegno di questa affermazione Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Ambito: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics

Come testare

L’ispezione URL in Search Console è il riferimento principale: esegui un test in tempo reale, poi esamina l’HTML renderizzato, lo screenshot e le risorse della pagina / messaggi della console per vedere cosa è stato caricato e cosa ha fallito. Il Rich Results Test offre un rapido controllo dell’HTML renderizzato. Su larga scala, usa un crawler che esegue JavaScript (Ahrefs Site Audit, Screaming Frog in modalità rendering JS) per confrontare l’HTML grezzo con quello renderizzato su tutto il sito.

JavaScript non è dannoso per la SEO, e non è nemmeno malvagio. È solo diverso da ciò a cui molti specialisti SEO sono abituati. Collabora con i tuoi sviluppatori, porta i tuoi contenuti importanti nel DOM, e lascia che siano gli strumenti di Google — non le tue supposizioni — a decidere cosa viene renderizzato.

Dove andare dopo: il cluster SEO per JavaScript

Questo hub è la mappa. Ogni argomento qui sotto è un approfondimento a sé:

Rendering e architettura

• SEO per un CMS headless — come i frontend disaccoppiati influenzano la scansione, il rendering, i metadati, le sitemap e i tag canonical; quale modalità di rendering scegliere; e le modalità di errore specifiche delle architetture headless che devi conoscere.

Guide specifiche per framework

• SEO per React — perché React con CSR-first crea rischi di indicizzazione, come Google esegue il rendering delle app React, React Router e History API, react-helmet-async per i meta tag e quando passare a Next.js.
• SEO per Angular — le impostazioni predefinite SPA di Angular, @angular/ssr (il successore di Angular Universal), i servizi integrati Title e Meta, il prerendering e l’idratazione incrementale in Angular moderno.
• SEO per Next.js — Pages Router vs App Router, Metadata API, next/image e CWV, tempistiche ISR e Googlebot, sitemap e gli errori SEO più comuni con Next.js.
• SEO per Nuxt — SSR per impostazione predefinita, useSeoMeta(), le modalità di rendering di Nuxt, l’ecosistema di moduli @nuxtjs/seo e come Nuxt si confronta con Vue semplice per l’indicizzabilità.
• SEO per Vue — l’impostazione predefinita CSR di Vue 3 e cosa significa per i crawler, createWebHistory(), @unhead/vue, opzioni di prerendering senza meta-framework e quando Nuxt è la scelta giusta.
• SEO per Svelte — Svelte vs SvelteKit, SSR per impostazione predefinita in SvelteKit, <svelte:head>, la trappola adapter-static + ssr: false, scelte degli adapter e implicazioni per i crawler AI.
• SEO per Astro — zero-JS per impostazione predefinita, architettura a isole, @astrojs/sitemap, astro:assets, View Transitions e History API, comportamento di fallback delle Server Islands e vantaggi di Astro per i Core Web Vitals.

Riepilogo AI

Una sintesi condensata della versione avanzata:

• “Google sa leggere JS?” è la domanda sbagliata — sì, lo sa. Le modalità di errore sono parità (HTML grezzo vs. renderizzato), interazione (Google non scorre né clicca), stato (renderer senza stato) e tempistiche.
• Le tempistiche non hanno un ritardo fisso — Google accoda una pagina 200 per il rendering e può attendere “alcuni secondi” o più, senza un timeout pubblicato; uno stato non-200 o un noindex iniziale può saltare del tutto la coda di rendering.
• I link devono essere veri anchor <a href> — onclick su un <div> è invisibile come link. Iniettare link con JS va bene se finiscono come anchor, ma gli anchor renderizzati vengono analizzati dopo l’esecuzione di JS — rilevabili, non una garanzia di scansione/indicizzazione.
• Caricamento differito sul viewport, non sull’interazione — Google “non interagisce con la tua pagina”. Usa IntersectionObserver / caricamento differito nativo; non bloccare i contenuti dietro scorrimento o clic.
• Lo scorrimento infinito può fondere due pagine in una — Googlebot può eseguire il rendering con un viewport più alto di un browser tipico (nessuna dimensione pubblicata esatta — testa la tua configurazione), e quel divario può attivare il loader e aggiungere il contenuto della pagina successiva. Soluzione: URL impaginati + veri link <a href> + History API; se un loader sta fondendo le pagine, blocca il suo file JS.
• Soft 404 dopo il routing lato client — restituisci un vero 404 o noindex; non indicizzare shell vuote; non fare affidamento su frammenti URL (AJAX-crawling deprecato nel 2015).
• Non bloccare JS/CSS in robots.txt — Google non eseguirà il rendering da file bloccati.
• noindex può bloccare la propria rimozione — Google potrebbe saltare il rendering quando vede un noindex iniziale, quindi il JS destinato a rimuoverlo potrebbe non essere mai eseguito.
• Parità DOM + ordine delle fasi (meta tag robots) — confronta HTML grezzo vs. renderizzato, ma ricorda che un noindex grezzo iniziale può fermare il rendering. Applica le regole di combinazione solo alle direttive effettivamente elaborate; testa la parità canonica secondo le proprie regole.
• La modalità di rendering cambia la dipendenza, non il risultato — SSR/statico/prerendering/idratazione mettono i contenuti nel DOM prima, riducendo la dipendenza dal rendering; il CSR completo si affida maggiormente a esso; il rendering dinamico è un espediente datato indicato da Google, non un’opzione equivalente. Analisi completa nella pagina sul rendering.
• Testa con URL Inspection (HTML renderizzato + screenshot + console), Rich Results Test e un crawler con rendering JS.

Documentazione ufficiale

Documentazione di prima mano proveniente dai motori di ricerca.

Google

• Comprendi le basi della SEO per JavaScript — le tre fasi, i link scansionabili e il test dell’HTML renderizzato.
• Risolvi i problemi JavaScript legati alla Ricerca — gestione dei soft 404, API History e vincoli del renderer.
• Risolvi i contenuti con caricamento differito — caricamento al viewport (non all’interazione) e scorrimento infinito ottimizzato per la Ricerca.
• Paginazione e caricamento incrementale delle pagine per l’ecommerce — URL univoci, link <a href> e perché Google ignora i frammenti identificativi.
• Guida approfondita su come funziona la Ricerca Google — dove si colloca il rendering nel percorso scansione → indicizzazione → pubblicazione.

Bing / Microsoft

• bingbot Series: JavaScript, Dynamic Rendering, and Cloaking. Oh My! — Il punto di vista di Bing su rendering JS e rendering dinamico.

Citazioni dalla fonte

Dichiarazioni ufficiali di Google (più alcune tratte dai miei scritti). Ogni link del motore di ricerca porta direttamente al passaggio citato nella pagina di origine.

Google — rendering e link

• “Google elabora le app web JavaScript in tre fasi principali: 1. Scansione 2. Rendering 3. Indicizzazione.” Vai alla citazione
• “Google può scoprire i tuoi link solo se sono elementi <a> HTML con un attributo href.” Vai alla citazione
• “Il rendering è importante perché i siti web spesso si affidano a JavaScript per portare contenuti alla pagina, e senza rendering Google potrebbe non vedere quel contenuto.” Vai alla citazione
• “La pagina può rimanere in questa coda per alcuni secondi, ma può richiedere più tempo di così.” — sulla tempistica della coda di rendering, nessun ritardo fisso pubblicato. Vai alla citazione
• “Quando Google incontra il tag noindex, può saltare il rendering e l’esecuzione di JavaScript, il che significa che usare JavaScript per cambiare o rimuovere il tag meta robots da noindex potrebbe non funzionare come previsto.” Vai alla citazione

Google — interazione, caricamento differito e scorrimento infinito

• “Google Search non interagisce con la tua pagina.” Vai alla citazione
• “…carica tutti i contenuti pertinenti quando sono visibili nel viewport.” Vai alla citazione
• “Assegna a ogni blocco il suo URL univoco e persistente.” — scorrimento infinito ottimizzato per i motori di ricerca. Vai alla citazione
• “Non utilizzare identificatori di frammento URL (il testo dopo un # in un URL) per i numeri di pagina in una raccolta. Google ignora gli identificatori di frammento.” Vai alla citazione

Google — soft-404 e routing

• “Consigliamo di utilizzare la History API per caricare viste diverse.” Vai alla citazione

Patrick Stox (lavoro mio — JavaScript SEO: Una Guida Definitiva)

• Per quanto riguarda nello specifico i tag meta robots: “Con i tag meta robots, Google adotterà sempre l’opzione più restrittiva che vede — indipendentemente dalla posizione… Google sceglierà le dichiarazioni più restrittive tra l’HTML e la versione renderizzata di una pagina.”
• “Se hai una configurazione con scorrimento infinito, consiglio comunque una versione della pagina con paginazione, così che Google possa ancora eseguire la scansione correttamente.”
• Sull’unione: “occasionalmente, due pagine vengono indicizzate come una sola” — causata quando “Google ha ridimensionato il viewport per renderlo più lungo … ha attivato lo scorrimento infinito e caricato un altro articolo durante il rendering.” La soluzione: “blocca il file JavaScript che gestisce lo scorrimento infinito, così la funzionalità non può attivarsi.”

Checklist SEO per JavaScript

Una rapida verifica per confermare che Google possa eseguire il rendering e indicizzare i tuoi contenuti dipendenti da JavaScript:

• I contenuti importanti compaiono nell’HTML renderizzato (controlla URL Inspection, non solo Visualizza sorgente).
• I link sono ancore <a href> reali — non gestori onclick su <div>/<span>.
• I file JavaScript e CSS non sono bloccati in robots.txt.
• Nessun contenuto è nascosto dietro un clic, scorrimento o passaggio del mouse (Google non interagisce); carica in modo differito nel viewport tramite IntersectionObserver o loading="lazy".
• I contenuti sopra la piega non vengono caricati in modo differito.
• Le direttive Robots corrispondono tra HTML grezzo e renderizzato (nessun noindex iniettato via JS) — Google applica la più restrittiva.
• Le modifiche di rotta lato client che incontrano una risorsa mancante restituiscono un vero 404 o noindex (niente shell soft-404).
• Lo scorrimento infinito ha una versione paginata con URL <a href> univoci e aggiornamenti dell’API History — e non unisce le pagine in un viewport alto.
• I contenuti che devono posizionarsi usano SSR / statico / prerendering, non CSR completo (vedi la pagina sul rendering).
• Hai verificato a campione lo screenshot renderizzato e gli errori della console nel test in tempo reale di URL Inspection.

I modelli mentali

1. “Google riesce a eseguire il mio JS?” è la domanda sbagliata. Sì, può farlo. Le domande reali riguardano parità, interazione, stato e tempistiche:

• Parità — il DOM renderizzato contiene ciò che pensi che contenga?
• Interazione — qualcosa richiede uno scorrimento o un clic che Google non eseguirà?
• Stato — stai facendo affidamento su cookie o localStorage che il renderer senza stato cancella?
• Tempistiche — il contenuto critico è rimandato dietro a JS lento o tardivo?

2. Se non è nel DOM renderizzato, non esiste. Visualizza sorgente mostra l’HTML grezzo; Ispezione URL mostra il DOM renderizzato. Le decisioni di indicizzazione si basano sul DOM renderizzato — quindi è quello l’elemento da controllare, ogni volta.

3. Link reali o nessun link. La scoperta si basa sugli anchor <a href>. I gestori di clic, i pulsanti e la navigazione JS che non producono mai un anchor sono vicoli ciechi per la scansione.

4. Progetta per un bot che non tocca mai la pagina. Niente scorrimento, niente clic, niente passaggio del mouse. Se il contenuto richiede un’azione per apparire, presupponi che Google non lo veda — caricalo invece nel viewport.

5. Test per la trappola del viewport alto nello scorrimento infinito. Googlebot può eseguire il rendering con un viewport più alto di un browser tipico (non viene pubblicata una dimensione fissa, quindi non progettare in base a un numero specifico), quindi un loader attivato da scorrimento/altezza può scattare durante il rendering e unire la pagina successiva. Progetta per questo: URL paginati + link reali + History API; se sta unendo attivamente, blocca il JS del loader.

6. Lascia che gli strumenti arbitrino. Il tuo browser non è Googlebot. L’HTML renderizzato, lo screenshot e la console di URL Inspection sono la fonte di verità — non “sul mio computer sembra a posto”.

Insidie SEO di JavaScript — scheda rapida

Quale modalità di rendering? (dipendenza dal successo del rendering)

Questo non è una garanzia di risultato: SSR/SSG/hydration devono comunque eseguire il rendering correttamente e superare ogni altro controllo in questo articolo. Analisi completa (ISR, edge, streaming, rendering dinamico e i relativi compromessi) nella pagina rendering.

Scopri cosa vede Googlebot

I bug di rendering si nascondono nel divario tra l’HTML grezzo (ciò che il server invia) e l’HTML renderizzato (ciò che esiste dopo l’esecuzione di JS). Alcuni rapidi controlli da riga di comando prima di ricorrere a un crawler completo.

Recupera l’HTML grezzo (ciò che viene restituito prima che venga eseguito qualsiasi JavaScript)

macOS / Linux:

# Raw HTML as the server sends it — this is the "first fetch"
curl -sL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
  https://example.com/page/ -o raw.html

# Is your important text actually in the raw HTML? (empty result = JS-dependent)
grep -o "Your headline text" raw.html

Windows (PowerShell):

$ua = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
Invoke-WebRequest -Uri "https://example.com/page/" -UserAgent $ua -OutFile raw.html
Select-String -Path raw.html -Pattern "Your headline text"

Se il testo manca da raw.html ma è visibile nel tuo browser, viene aggiunto da JavaScript — quindi dipende dal rendering. (Per l’HTML renderizzato, usa “Visualizza pagina indicizzata → HTML renderizzato” di URL Inspection, oppure un crawler headless-Chrome — un semplice curl non può eseguire JS.)

Conferma di non bloccare JS/CSS in robots.txt

macOS / Linux:

curl -sL https://example.com/robots.txt | grep -iE "disallow.*\.(js|css)|Disallow:\s*/(_next|static|assets|dist)"

Windows (PowerShell):

(Invoke-WebRequest "https://example.com/robots.txt").Content |
  Select-String -Pattern "Disallow.*\.(js|css)","Disallow:\s*/(_next|static|assets|dist)"

Un Disallow che corrisponde al tuo JavaScript o CSS significa che Google non può eseguire il rendering della pagina correttamente — quasi sempre un errore. (L’ispezione dell’URL elenca anche le risorse di pagina bloccate; il grep cattura rapidamente solo quelle ovvie.)

Strumenti per il debug della SEO JavaScript

Scopri la differenza tra HTML grezzo e ciò che Google renderizza con Render Gap:

1. Incolla l’URL completo della pagina che vuoi testare — una pagina template con molto JavaScript mostra il massimo.
2. Supera il controllo anti-abuso e premi Testa pagina; recupera prima l’HTML grezzo e lo renderizza in Chrome headless solo quando quell’HTML sembra una shell vuota.
3. Leggi il verdetto con codice colore, poi esamina la tabella HTML iniziale vs DOM renderizzato per le righe contrassegnate come modificate.
4. Passa alla scheda Diff grezzo vs renderizzato per vedere riga per riga cosa JavaScript ha aggiunto o rimosso.

• URL Inspection (Google Search Console) — la fonte di verità. Esegui un test in tempo reale, poi controlla l’HTML renderizzato, lo screenshot, le risorse della pagina (cosa è stato caricato vs. cosa è stato bloccato) e i messaggi della console JavaScript.
• Rich Results Test — un modo rapido per verificare l’HTML renderizzato e i dati strutturati di un URL senza dover autenticare il sito.
• Chrome DevTools — confronta Visualizza sorgente (HTML grezzo) con il pannello Elements (DOM renderizzato); la Console evidenzia errori JS che possono svuotare il contenuto.
• Crawler con rendering JavaScript — Ahrefs Site Audit e Screaming Frog SEO Spider (modalità rendering JS) eseguono JS così puoi confrontare la versione grezza con quella renderizzata su larga scala.
• Strumenti di visualizzazione sorgente renderizzata — estensioni del browser che mostrano il DOM renderizzato affiancato all’HTML grezzo per controlli rapidi.
• Analisi dei log del server — conferma che Googlebot sta effettivamente recuperando le tue risorse JS/CSS (vedi analisi dei file di log).

Prompt per la diagnosi SEO di JavaScript

Confronta HTML grezzo e HTML renderizzato

Incolla la risposta grezza e il DOM renderizzato per lo stesso URL. Rimuovi prima i dati dei clienti e i token.

Act as a technical SEO reviewer. Compare RAW_HTML and RENDERED_HTML below. Report only
meaningful differences in title, meta robots, canonical, headings, body copy,
structured data, and crawlable <a href> links. For each difference, label its likely
indexing impact, show the exact conflicting snippets, and give a verification step.
Do not infer content that is not present.

RAW_HTML:
[paste]

RENDERED_HTML:
[paste]

Analizza un esempio di route

Review this CSV of JavaScript routes with columns URL, HTTP_STATUS, RAW_TITLE,
RENDERED_TITLE, RAW_CANONICAL, RENDERED_CANONICAL, RAW_WORDS, RENDERED_WORDS. Group
failures into shared-shell duplicates, restrictive-directive conflicts, soft 404s,
and likely render timeouts. Rank groups by affected URL count. Return the exact rows
that support each conclusion and a test to confirm it; do not invent thresholds.

[paste CSV]

Validare una modifica SEO JavaScript

Verifica che il contenuto della route esista prima del JavaScript

Test da eseguire: Recupera rotte rappresentative con curl e ispeziona il corpo della risposta. Risultato atteso: Ogni risposta contiene il proprio titolo univoco, intestazione principale, testo e link scansionabili. Interpretazione del fallimento: La distribuzione serve ancora una shell applicativa condivisa. Finestra di monitoraggio: Immediata. Trigger di rollback: Una rotta precedentemente visibile lato server diventa dipendente dal rendering.

Le prove direttive concordano tra le fasi di elaborazione

Test da eseguire: Confronta l’HTML grezzo con l’HTML renderizzato di URL Inspection per i tag robots e canonical. Risultato atteso: Un set di direttive intenzionale appare in entrambi, senza valore più restrittivo nel guscio grezzo. Interpretazione del fallimento: JavaScript sta cercando di sovrascrivere un segnale di indicizzazione troppo tardi. Finestra di monitoraggio: Immediata nel rendering locale; dopo la nuova scansione in Search Console. Trigger di rollback: noindex o un canonical errato appare in entrambe le fasi.

Le prove che i link rimangono scansionabili

Test da eseguire: Disabilita JavaScript e ispeziona la navigazione verso rotte rappresentative. Risultato atteso: Le destinazioni rimangono in attributi href reali degli anchor. Interpretazione del fallimento: I gestori client, non i link, possiedono la scoperta. Finestra di monitoraggio: Immediata. Trigger di rollback: Le rotte importanti scompaiono dal grafico dei link quando gli script falliscono.

Risorse che meritano il tuo tempo

I miei scritti correlati

• JavaScript SEO: Una Guida Definitiva — la mia guida completa su rendering, parità DOM, la regola della direttiva più restrittiva, scorrimento infinito e il problema delle due pagine come una sola. Questo articolo è la versione condensata con fonti collegate.
• La Guida per Principianti alla SEO Tecnica — dove la SEO JavaScript si inserisce nel quadro più ampio.

I miei interventi

• Come funziona la ricerca (SlideShare) — la mia panoramica su scansione, rendering, indicizzazione e ranking. (Vale la mia consueta precisazione: “Questa è la mia comprensione dei sistemi… non sarà completa o accurata al 100%.”)

Da altri

• r/TechSEO — la community per il debug di problemi di rendering e indicizzazione.
• web.dev — Rendering sul Web — la spiegazione canonica dei compromessi di rendering del team di Chrome.
• Google Search Central — SEO JavaScript — documentazione ufficiale di prima fonte sul processo in tre fasi, link scansionabili e test dell’HTML renderizzato.
• Onely — Hub SEO JavaScript — articoli tecnici approfonditi su rendering, indicizzazione a due ondate e audit SEO JS da un’agenzia specializzata.
• Playlist SEO JavaScript di Martin Splitt — la serie video ufficiale di Google che illustra ogni concetto di SEO JavaScript, prodotta dal team dell’ecosistema web di Google.
• Search Engine Journal — Copertura SEO JavaScript — notizie di settore e guide pratiche sui problemi di rendering JS man mano che emergono.

Podcast

• Search Off the Record (Google Search Relations) — Martin Splitt, John Mueller, e Gary Illyes trattano regolarmente la SEO JavaScript e il rendering dall’interno. Ascolta

Video

• Google Search Central (YouTube) — La serie JavaScript SEO di Martin Splitt è la migliore guida video ufficiale su come Google gestisce il tuo JS. Canale

Statistiche degne di essere citate

• Attuale inquadramento ufficiale: nessun ritardo fisso. La documentazione di Google (aggiornata il 2026-03-04) afferma che una pagina 200 scansionata “può rimanere in questa coda per alcuni secondi, ma può richiedere più tempo” — non esiste un ritardo o timeout fisso pubblicato, e le pagine che restituiscono uno stato non-200 o iniziano con noindex possono saltare del tutto il rendering. Vai alla citazione
• Punto dati storico (datato) — ritardo di rendering mediano di ~5 secondi. In precedenti osservazioni in conferenze, il personale di Google (Martin Splitt e Tom Greenaway) ha descritto pagine che raggiungono il renderer con una mediana di ~5 secondi, con il 90° percentile in minuti — non le “settimane” che la vecchia paura implicava. Cito questo nella mia guida SEO JavaScript. Trattalo come un punto dati storico di quel discorso, non una metrica pubblicata attuale — Google non l’ha ripubblicato come cifra in corso, e la citazione sui tempi di coda sopra è l’ attuale inquadramento ufficiale.
• “Due ondate di indicizzazione” sta svanendo, secondo Martin Splitt (osservazioni del 2019). In una conversazione dell’agosto 2019 con John Mueller, Splitt ha detto che l’indicizzazione a due ondate “gioca un ruolo sempre minore” man mano che il rendering diventa più economico e scansione, rendering e indicizzazione convergono — senza una tempistica fornita per quando potrebbe fermarsi del tutto. Copertura Questa è la caratterizzazione di Splitt da quella conversazione specifica, non una specifica Google datata e citabile — usala come contesto direzionale, non come garanzia attuale in entrambi i casi.

Google elabora le app JavaScript attraverso scansione, rendering e indicizzazione. Prova a sostegno di questa affermazione Google processes JavaScript web apps in three main phases: crawling, rendering, and indexing; without rendering, Google might not see JavaScript-provided content. Ambito: Google Search's processing of JavaScript pages; successful rendering does not guarantee indexing or ranking. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics Generalmente scansiona i link quando sono ancore con attributi href. Prova a sostegno di questa affermazione Google can reliably discover links only when they are HTML anchor elements with an href attribute. Ambito: Link discovery by Google Search; this does not claim that every discovered URL will be crawled or indexed. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Make your links crawlable Google descrive il rendering lato server o il pre-rendering come una buona idea per utenti e crawler. Prova a sostegno di questa affermazione Google describes server-side rendering or pre-rendering as a good idea because it makes a website faster for users and crawlers. Ambito: Google Search guidance for JavaScript sites; the source does not prescribe one framework or guarantee indexing. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Understand the JavaScript SEO basics La Ricerca Google inoltre non interagisce con una pagina per attivare contenuti. Prova a sostegno di questa affermazione Google Search does not interact with a page, so lazy-loaded content should load when it becomes visible in the viewport rather than requiring user interaction. Ambito: Google Search's documented rendering behavior for lazy-loaded content; other crawlers can behave differently. Attendibilità: alta · Verificato: 2026-07-14 Google Search Central: Fix lazy-loaded content

Cronologia modifiche