Sito nuovo in React. Design curato, animazioni fluide, UX impeccabile. Passano le settimane e Google ha indicizzato tre pagine. Forse quattro. Il resto è un buco nero.
Situazione comune, più di quanto si pensi. Il JavaScript SEO resta una delle aree più sottovalutate dell'ottimizzazione tecnica, e nel 2026 sta diventando ancora più critico con l'arrivo dei crawler AI.
Il Problema di Fondo
Google non legge le pagine web come le vede un utente normale. Il browser carica la pagina, esegue JavaScript, costruisce il DOM, e dopo qualche millisecondo mostra il contenuto. Googlebot invece lavora in due fasi separate: prima crawla l'HTML grezzo, poi mette la pagina in coda per il rendering (quando ha risorse disponibili).
Questa coda può essere lunga. Molto lunga.
I dati parlano chiaro: il rendering di contenuti JavaScript richiede a Google circa nove volte più tempo rispetto all'HTML statico. Per pagine JS leggere si parla di minuti, per SPA complesse si arriva tranquillamente a giorni. A volte settimane.
Nel frattempo, il contenuto semplicemente non esiste per Google.
Le Single Page Application: Croce e Delizia
Le SPA hanno rivoluzionato lo sviluppo frontend. L'esperienza utente è incomparabile: navigazione istantanea, niente ricaricamenti, interazioni fluide. Ma dal punto di vista SEO sono un campo minato.
Il motivo è strutturale. Una SPA carica un guscio HTML praticamente vuoto, spesso poco più di un <div id="app"></div>, e poi JavaScript costruisce tutto il resto. Menù, contenuti, link interni: tutto generato client-side.
I crawler vedono quel guscio vuoto. Fine della storia.
O meglio, vedrebbero solo quello senza le giuste contromisure.
Server-Side Rendering: La Soluzione Mainstream
Il Server-Side Rendering (SSR) ribalta l'approccio. Invece di spedire al browser un HTML vuoto con istruzioni JavaScript, il server genera l'HTML completo e lo invia già pronto. Il browser riceve contenuto leggibile, i crawler pure.
I framework moderni hanno reso l'SSR accessibile:
- Next.js per React
- Nuxt per Vue
- SvelteKit per Svelte
Con questi strumenti non serve più scegliere tra esperienza utente e indicizzabilità.
Il meccanismo funziona così:
- Richiesta - L'utente (o Googlebot) richiede una pagina
- Rendering server - Il server esegue JavaScript e genera l'HTML completo
- Invio - L'HTML arriva al client già popolato di contenuti
- Hydration - JavaScript "rianima" la pagina per renderla interattiva
L'hydration è il passaggio chiave. La pagina arriva statica ma funzionale, poi il framework si aggancia e aggiunge l'interattività. L'utente non nota nulla, e Google riceve HTML completo da indicizzare subito.
Il Caso Svelte e SvelteKit
Svelte merita un discorso a parte. A differenza di React e Vue, Svelte compila i componenti in JavaScript vanilla durante la build, eliminando il peso del framework a runtime. Questo si traduce in bundle più leggeri e tempi di rendering più rapidi.
SvelteKit, il meta-framework ufficiale, offre SSR out of the box con una configurazione minima. Supporta anche la generazione statica (SSG) per siti che non richiedono contenuti dinamici, ideale per blog e landing page dove la SEO è prioritaria.
La leggerezza di Svelte gioca a favore anche del crawl budget: pagine più snelle significano rendering più veloce lato Google.
Pre-rendering: L'Alternativa Pragmatica
Non sempre è possibile una migrazione completa a SSR. Progetti legacy, budget limitati, team senza esperienza sui meta-framework: le ragioni sono molte.
Il pre-rendering offre una via di mezzo. Servizi come Prerender.io intercettano le richieste dei bot e servono loro una versione HTML statica pre-generata. Gli utenti normali continuano a ricevere la SPA standard.
Una soluzione tampone, certo, ma che funziona e per molti progetti rappresenta il compromesso giusto tra effort e risultati.
Attenzione però: Google non ama il cloaking, cioè mostrare contenuti diversi a utenti e bot. Il pre-rendering è accettato perché il contenuto è identico, cambia solo il metodo di delivery. Se la versione pre-renderizzata diverge da quella utente, il rischio penalizzazione è concreto.
I Dettagli Che Fanno la Differenza
Oltre alla strategia di rendering, ci sono aspetti tecnici che spesso passano in secondo piano.
Link Interni
I link devono essere veri tag <a> con attributo href. Sembra banale, ma esistono decine di siti con navigazione costruita interamente su onClick e routing programmatico. L'utente naviga senza problemi, ma Google non vede quei collegamenti.
Sbagliato:
<div onClick={() => goto('/prodotti')}>Prodotti</div>
Corretto:
<a href="/prodotti">Prodotti</a>
Tutti i framework moderni (Next, Nuxt, SvelteKit) forniscono componenti Link che generano tag <a> corretti. Usarli è fondamentale.
Metadata
Title, description, canonical: questi tag devono essere presenti nell'HTML iniziale, non iniettati via JavaScript dopo il rendering. Con SSR il problema non si pone. Con una SPA client-side, librerie come react-helmet, vue-meta o svelte-head permettono di gestire i meta tag, ma vanno configurate per il rendering server-side.
Sitemap XML
Per siti JavaScript-heavy la sitemap diventa fondamentale. Non basta affidarsi alla scoperta tramite link interni. Una sitemap completa, aggiornata automaticamente e comprensiva di tutte le pagine dinamiche fa la differenza tra indicizzazione parziale e copertura totale.
Dati Strutturati
Schema.org può essere iniettato via JavaScript, Google lo riconosce. Ma vale lo stesso discorso dei metadata: renderizzarlo server-side elimina variabili e riduce i rischi di mancata lettura.
Come Verificare Se C'è un Problema
Prima di intervenire, serve una diagnosi. Gli strumenti utili:
URL Inspection Tool in Search Console mostra esattamente cosa vede Google: HTML crawlato, HTML renderizzato, screenshot. Se il contenuto manca dalla versione renderizzata, il problema è individuato.
Test dei Risultati Multimediali valida i dati strutturati dopo il rendering JavaScript.
Lighthouse identifica bottleneck di performance che rallentano il rendering e quindi l'indicizzazione.
Un test rapido: aprire la pagina in Chrome, disabilitare JavaScript (DevTools → Settings → Debugger → Disable JavaScript), ricaricare. Quello che appare è più o meno quello che vede Googlebot alla prima passata.
Il Fattore AI: 2026 e Oltre
C'è un elemento nuovo da considerare. Non sono più solo Google e Bing a scansionare il web. ChatGPT, Perplexity e altri sistemi AI stanno costruendo i propri indici. E i loro crawler hanno spesso capacità di rendering JavaScript limitate o nulle.
Un sito che dipende interamente dal client-side rendering taglia fuori una fetta crescente di visibilità, quella che porta traffico da risposte AI, citazioni, snippet generati.
L'HTML pulito e accessibile non è mai stato così strategico.
Quando il JavaScript SEO Non È un Problema
Un sito su CMS tradizionale con qualche script per animazioni o form interattivi probabilmente non ha alcun problema. Il JavaScript SEO diventa critico quando il contenuto principale dipende dall'esecuzione di script.
Blog WordPress con qualche plugin? Nessun allarme. E-commerce Shopify? Gestito dalla piattaforma. Dashboard React/Vue/Svelte che deve rankare su Google? Lì serve intervenire.
Checklist Operativa
- Diagnosi - Usa URL Inspection Tool in Search Console per verificare se Google vede i contenuti
- Rendering - Per le SPA, implementa SSR con Next.js, Nuxt o SvelteKit, oppure valuta pre-rendering
- Link interni - Controlla che tutti usino veri tag
<a href>, non onClick - Metadata - Verifica che title, description e canonical siano nell'HTML iniziale
- Sitemap - Genera e mantieni una sitemap XML aggiornata con tutte le pagine dinamiche
- Structured data - Testa i dati strutturati con il Rich Results Test
- Monitoraggio - Controlla periodicamente il crawl budget in Search Console