SEO per JavaScript: perché le tue pagine diventano invisibili per Google

La SEO per JavaScript è la pratica che serve a far sì che Google e gli altri motori di ricerca possano scansionare, renderizzare e indicizzare i contenuti che un browser costruisce con JavaScript invece che con semplice HTML. Google esegue il rendering delle pagine in un passaggio separato e differito rispetto alla scansione iniziale, quindi i contenuti possono restare non visti per settimane.

Se hai costruito il tuo sito con React o Vue, oppure con un framework come Next.js, il divario tra "scansionata" e "renderizzata" è probabilmente il motivo principale per cui le pagine restano non indicizzate. Di solito la soluzione non è complicata, una volta che sai dove si crea il problema.

Che cos'è la SEO per JavaScript e perché mette in difficoltà Google?

La SEO per JavaScript è un ramo della SEO tecnica che si concentra su un solo problema: rendere le pagine costruite con JavaScript scansionabili e indicizzabili quanto le pagine in semplice HTML. Un sito HTML tradizionale consegna a Google tutto ciò che gli serve in un'unica risposta. Un sito JavaScript spesso consegna un guscio quasi vuoto e costruisce il contenuto vero nel browser.

Google è in grado di eseguire JavaScript e lo dice da anni. Farlo, però, costa risorse di calcolo, e Google deve razionarle su miliardi di pagine. È qui che iniziano i guai.

Come Google scansiona e indicizza una pagina JavaScript

La documentazione di Google su Search Central descrive il rendering come un passaggio distinto dalla scansione, non come qualcosa che avviene durante la prima visita. Il processo si articola in tre parti:

1. Scansione (crawling): Googlebot richiede la pagina e legge l'HTML grezzo. Per una pagina ricca di JavaScript, quell'HTML può contenere poco più di un <div id="root"></div> e un tag script.
2. Rendering: la pagina entra in una coda di rendering, dove il Web Rendering Service di Google, basato su un motore Chromium sempre aggiornato, esegue il JavaScript per costruire la pagina finale.
3. Indicizzazione: solo dopo il completamento del rendering Google indicizza i contenuti, i link e i metadati che trova.

Il Web Rendering Service ora tenta di renderizzare quasi il 100% delle pagine HTML che Google scansiona. Tentare il rendering non significa però farlo in fretta. Il tempo che passa tra scansione e rendering può andare da poche ore su un sito consolidato a diverse settimane su un sito con meno autorevolezza, e per una nuova pagina prodotto o per un articolo legato a un momento preciso può significare perdere la finestra di traffico.

Il problema dell'indicizzazione in due fasi

È la parte che coglie di sorpresa la maggior parte dei proprietari di siti. La tua pagina viene scansionata quasi subito, ma il contenuto al suo interno non viene visto fino a molto più tardi, sempre che venga visto.

Fase	Cosa succede	Tempi tipici	Impatto SEO
Scansione iniziale	Googlebot scarica l'HTML grezzo ed estrae testo statico, link e tag	Immediata	Viene indicizzato subito solo il contenuto che non dipende da JS
Coda di rendering	Chromium esegue il JavaScript e costruisce la pagina finale	Da qualche ora a diverse settimane, di più sui siti con poca autorevolezza	Contenuti, link e dati strutturati costruiti dagli script restano invisibili finché questa fase non finisce
Errore di rendering	Un errore di script, una risorsa bloccata o un timeout impediscono il completamento del rendering	Imprevedibili	Il contenuto non viene mai indicizzato

Diversi fattori spingono una pagina verso la parte lenta di questo intervallo: bundle JavaScript di grandi dimensioni, script bloccati nel file robots.txt, errori JavaScript non gestiti, script di terze parti che non si caricano e scarsa autorevolezza del sito. Il crawl budget viene assegnato in modo non uniforme, quindi i siti più grandi o più recenti spesso aspettano più a lungo nella coda.

Rendering lato client o lato server: quale scegliere?

Per qualsiasi pagina che vuoi far indicizzare, usa il rendering lato server (SSR) o la generazione di siti statici (SSG) anziché il rendering lato client (CSR). Con il CSR, Google deve aspettare la coda di rendering. Con SSR o SSG, Google riceve l'HTML già pronto alla prima richiesta e non c'è alcuna attesa.

Approccio	Come il contenuto arriva al browser	Adeguatezza SEO	Ideale per
Rendering lato client (CSR)	Il browser (o Googlebot) esegue JavaScript per costruire la pagina dopo il caricamento	Debole per le pagine pubbliche; dipende dalla coda di rendering	Dashboard con accesso riservato, strumenti interni
Rendering lato server (SSR)	Il server costruisce l'HTML completo a ogni richiesta	Forte; il contenuto è nella prima risposta	Pagine prodotto, blog, landing page
Generazione di siti statici (SSG)	L'HTML viene precostruito al momento del deploy	Forte, e il più veloce da servire	Siti di marketing, documentazione, portfolio
Incremental static regeneration (ISR)	Pagine statiche che si aggiornano a intervalli o su richiesta	Forte	Cataloghi e-commerce, contenuti aggiornati di frequente
Snapshot pre-renderizzati per i bot	Uno snapshot HTML separato viene servito solo ai bot	Accettabile come soluzione ponte, non a lungo termine	Vecchi siti CSR in fase di migrazione

Google ha dichiarato che servire ai bot uno snapshot pre-renderizzato non è cloaking, purché bot e utenti vedano alla fine contenuti equivalenti. È però esplicito nel dire che dovrebbe essere un ripiego temporaneo. Far funzionare due percorsi di rendering in parallelo comporta una complessità in più, che devi tenere sincronizzata a tempo indeterminato.

La maggior parte dei team di sviluppo finisce per adottare una soluzione ibrida: SSR o SSG per tutto ciò che i motori di ricerca o i motori di risposta basati su AI devono trovare, e CSR per le esperienze con accesso riservato, dove l'indicizzazione non è mai stata l'obiettivo. Un progetto Next.js permette questa scelta a livello di singola pagina, e i dettagli sono spiegati in questa guida alle impostazioni SEO di Next.js.

I segnali che il tuo sito ha un problema di SEO per JavaScript

Non serve uno sviluppatore per accorgersi dei primi campanelli d'allarme. Cerca questi schemi in Google Search Console e nei tuoi strumenti di analisi:

• Le pagine restano "Discovered, currently not indexed" per settimane dopo la pubblicazione.
• La vista renderizzata di una pagina in Search Console non mostra testi, link o immagini che nel browser si vedono chiaramente.
• I link interni costruiti come gestori JavaScript onClick invece che con veri tag <a href> non compaiono come "linked from" in Search Console.
• I title tag o le meta description nei risultati di ricerca non corrispondono a ciò che c'è nella pagina.
• I dati strutturati iniettati lato client non vengono convalidati nel Rich Results Test.
• Una paginazione costruita sullo stato di JavaScript invece che su URL univoci impedisce la scansione delle pagine più profonde.

Quando più di questi segnali compaiono insieme, la causa è quasi sempre un divario di rendering e non un problema di contenuti o parole chiave. Un audit SEO tecnico che confronta l'HTML renderizzato con quello grezzo lo confermerà rapidamente.

Cosa deve esserci nell'HTML iniziale

Per quanto JavaScript arricchisca la pagina in un secondo momento, alcuni elementi devono esistere nella prima risposta HTML. Senza di essi, Google può considerare la pagina quasi vuota durante la scansione, anche se la versione renderizzata appare completa.

Elemento	Perché conta per la SEO per JavaScript	Rischio se è solo in JS
Title tag e meta description	Segnale fondamentale per il posizionamento e per il tasso di clic	Può non comparire nei risultati di ricerca per settimane
Titoli H1, H2 e H3	Danno a Google la struttura tematica della pagina	Indicizzazione ritardata, perdita di idoneità per gli snippet
Testo del corpo	Stabilisce pertinenza e profondità tematica	Alla prima scansione la pagina risulta vuota
Link interni (<a href>)	Il percorso che Googlebot segue verso le altre pagine	Le pagine collegate potrebbero non essere mai scoperte
Dati strutturati (JSON-LD)	Idoneità per i risultati avanzati e per le citazioni nelle risposte delle AI	Esclusi del tutto dai risultati avanzati
Tag canonical	Evitano la confusione dei contenuti duplicati	Viene indicizzata la versione sbagliata dell'URL

Affianca ai controlli sul rendering un audit dello schema markup. Il JSON-LD iniettato esclusivamente da JavaScript lato client è una delle cose che più spesso spariscono dalla versione indicizzata da Google.

Core Web Vitals: dove JavaScript fa più danni

Un JavaScript pesante ritarda l'indicizzazione e rallenta anche la pagina per i visitatori reali, il che pesa su di te come fattore di posizionamento. I Core Web Vitals di Google misurano proprio il tipo di lentezza causata da script non ottimizzati.

Metrica	Cosa misura	Soglia buona	Causa tipica legata a JavaScript
Largest Contentful Paint (LCP)	Quanto in fretta compare il contenuto principale	Meno di 2,5 secondi	Grandi bundle JS ritardano il rendering del contenuto visibile
Interaction to Next Paint (INP)	Quanto la pagina risponde a clic e tocchi	Meno di 200 millisecondi	Lunghi task JavaScript bloccano il thread principale del browser
Cumulative Layout Shift (CLS)	Quanto il layout si sposta durante il caricamento	Meno di 0,1	Elementi iniettati in ritardo da JavaScript spostano il contenuto

L'INP ha sostituito il First Input Delay come Core Web Vital ufficiale a marzo 2024, un cambiamento trattato nella documentazione di Google su web.dev. È una misura della reattività più severa e più realistica della precedente, e penalizza gli script a lunga esecuzione che i siti ricchi di JavaScript tendono a distribuire.

Un obiettivo citato di frequente è un bundle iniziale compresso sotto i 200KB, con ogni task più lungo di 50 millisecondi suddiviso in blocchi più piccoli, in modo da non bloccare il thread principale. Google non applica nessuno dei due numeri come soglia rigida, ma entrambi sono strettamente legati ai siti che superano senza problemi i Core Web Vitals. Una breve checklist copre la maggior parte del lavoro:

• Rimanda gli script che non servono per il primo rendering visibile.
• Elimina dal bundle il JavaScript inutilizzato.
• Spezza i task lunghi, così il thread principale resta libero per clic e tocchi.
• Correggi gli errori degli script e sblocca le risorse che robots.txt nasconde attualmente a Googlebot.

Perché conta ancora di più per i siti SaaS e B2B

Le piattaforme SaaS, i portali aziendali e i marketplace tecnologici sono spesso costruiti fin dall'inizio come applicazioni JavaScript. L'indicizzazione ritardata delle pagine prodotto, i dati strutturati invisibili e dei Core Web Vitals deboli li danneggiano tutti insieme, e spingono il sito sotto i concorrenti nelle ricerche ad alta intenzione, quelle in cui gli affari si vincono o si perdono.

L'errore più comune è un sito di marketing e un'app di prodotto che condividono un'unica base di codice renderizzata lato client. Un'impostazione più sicura renderizza le pagine pubbliche (prezzi, funzionalità, documentazione, blog) sul server o in fase di build, e riserva il CSR all'app con accesso riservato, dove l'indicizzazione non conta.

Le soluzioni piattaforma per piattaforma

La soluzione giusta dipende da ciò su cui stai costruendo.

• I temi Shopify si appoggiano a JavaScript per filtri, selezione delle varianti e aggiornamenti del carrello. Per la SEO va per lo più bene, purché titoli dei prodotti, descrizioni e tag canonical restino nell'HTML renderizzato dal server. Le impostazioni da controllare sono illustrate in questa guida alla SEO per Shopify.
• Wix ha migliorato in modo significativo la gestione del rendering, ma le sezioni interattive generate dall'editor possono comunque ritardare l'indicizzazione se caricano i contenuti in modo asincrono. Le impostazioni rilevanti sono spiegate passo per passo in questa guida alla SEO per Wix.
• Le app Lovable sono spesso costruite per impostazione predefinita come single-page app React, il che le colloca nel territorio del CSR a meno che tu non le configuri diversamente. Questa guida alla SEO per i siti Lovable spiega come far indicizzare i contenuti del blog in un sito creato da un singolo prompt.
• I siti WordPress sono di solito già pensati prima di tutto per l'HTML, ma temi pesanti di JavaScript, page builder e alcuni plugin reintroducono il rischio di rendering. Le soluzioni sono trattate in questa guida alle impostazioni SEO di WordPress.
• I siti basati su Git, costruiti con generatori di siti statici e distribuiti tramite GitHub, tendono a usare SSG per impostazione predefinita, che è la scelta di rendering più sicura a disposizione. I dettagli su deploy e indicizzazione sono in questa guida alla SEO per i siti distribuiti con GitHub.
• Next.js ti dà il maggior controllo, permettendoti di scegliere SSR, SSG o ISR pagina per pagina. Metadati, sitemap e robots.txt contano quanto la modalità di rendering, e la guida alla SEO per Next.js li affronta.

La ricerca con AI cambia la posta in gioco

La SEO per JavaScript era una questione che riguardava solo Google. La maggior parte dei crawler delle AI, compresi i bot di ChatGPT, Claude e Perplexity, non esegue affatto JavaScript. Gemini è l'eccezione degna di nota perché usa lo stack di rendering di Google, anche se viene descritto come sperimentale e non come qualcosa su cui fare affidamento.

Una pagina che dipende da JavaScript lato client per mostrare i propri contenuti può quindi essere invisibile ai motori di risposta basati su AI, anche quando Googlebot alla fine la vede. Per essere idonei alla citazione nelle risposte generate dalle AI, il contenuto deve esistere nell'HTML grezzo. Lo stesso principio attraversa l'answer engine optimization: scrivi la risposta dove qualsiasi crawler, umano o AI, possa leggerla.

Come testare e monitorare la SEO per JavaScript

Puoi verificare se Google vede la tua pagina come intendi tu, senza andare a tentoni.

1. Confronta l'HTML grezzo con quello renderizzato. Usa "visualizza sorgente" per la versione grezza, poi mettila accanto a ciò che Chrome DevTools mostra dopo il caricamento completo della pagina. Grandi differenze indicano una dipendenza dal rendering.
2. Usa lo strumento URL Inspection di Search Console. Mostra lo screenshot renderizzato e l'HTML usati da Google, oltre a eventuali errori della console JavaScript in cui è incappato.
3. Esegui la scansione con JavaScript disattivato. Una modalità di scansione "solo testo" rivela ciò che vede un bot che non esegue il rendering, e questo conta, visto quanti crawler delle AI saltano JavaScript.
4. Osserva nel tempo i file di log del server. Esaminare la frequenza di scansione su un arco di tre-sei mesi mostra se i template importanti vengono rivisitati abbastanza spesso, e se le correzioni al rendering hanno poi migliorato l'attività di scansione.
5. Ripeti un audit tecnico dopo i grandi cambiamenti di framework. La migrazione a un nuovo framework è il momento in cui le regressioni di rendering passano inosservate, e un audit SEO tecnico prima e dopo le intercetta quando correggerle costa poco.

Puoi risolvere da solo la SEO per JavaScript?

In parte sì. Verificare se i tuoi title tag e i titoli compaiono nell'HTML grezzo richiede cinque minuti e un clic su "visualizza sorgente". Aggiungere l'attributo defer agli script non critici, eliminare il JavaScript inutilizzato e assicurarsi che i link interni usino veri tag <a href> sono tutte modifiche che un proprietario di sito può chiedere a uno sviluppatore senza rifare il sito da capo.

Spostare un'app CSR su SSR, o impostare snapshot pre-renderizzati come soluzione provvisoria, è un progetto più grosso. Di solito serve uno sviluppatore che conosca il tuo framework, perché un'implementazione sbagliata può rompere le funzionalità che stai cercando di preservare. Se il sospetto è che il colpevole sia l'architettura di rendering, coinvolgi uno sviluppatore prima che qualcuno tocchi il codice in produzione, e usa un piano SEO strutturato per mettere in sequenza le correzioni, in modo che una non annulli l'altra.

Dove si inserisce nel tuo lavoro SEO più ampio

Un sito con problemi di rendering ha spesso lacune anche nella visibilità locale, nei dati strutturati o nella salute tecnica in generale. Se servi zone specifiche, affianca alle correzioni sul rendering delle pagine di local SEO costruite attorno ai quartieri in cui vuoi posizionarti. Se il tuo framework genera anche URL duplicati o canonical incoerenti, cosa che i router lato client fanno di frequente, intercettali nello stesso intervento tecnico invece di trattarli più avanti come un progetto a parte.

Domande frequenti

Google penalizza i siti JavaScript?

No. Google non penalizza un sito perché usa JavaScript. Il problema è indiretto: se JavaScript ritarda il rendering o nasconde i contenuti, le pagine vengono indicizzate in ritardo o non vengono indicizzate affatto, e questo sembra un problema di posizionamento ma in realtà è un problema di indicizzazione.

Quanto tempo ci mette Google a indicizzare una pagina JavaScript?

Varia molto. I siti consolidati e molto autorevoli possono vedere il rendering avvenire entro poche ore, mentre i siti più recenti o meno autorevoli possono aspettare settimane perché la stessa pagina attraversi la coda, secondo la descrizione che Google stesso dà del processo.

React è dannoso per la SEO?

React in sé no, ma lo è un'app React renderizzata interamente lato client. Abbinare React a un framework che supporta il rendering lato server o la generazione statica, come Next.js, elimina la maggior parte del rischio.

Qual è la differenza tra SSR e pre-rendering?

L'SSR costruisce l'HTML completo sul server a ogni richiesta, in tempo reale. Il pre-rendering genera in anticipo (o alla prima richiesta di un bot) uno snapshot HTML statico e serve ai crawler quella versione in cache. Costa meno da gestire, ma va aggiornato per restare accurato.

I chatbot AI come ChatGPT leggono i contenuti JavaScript?

In genere no. La maggior parte dei crawler delle AI non esegue JavaScript, quindi i contenuti che compaiono solo dopo l'esecuzione di uno script sono di norma invisibili per loro. Gemini di Google è l'eccezione perché usa l'infrastruttura di rendering di Google, anche se viene ancora considerato un caso limite.

Fai controllare il rendering prima che ti costi altre posizioni

I problemi di SEO per JavaScript sono silenziosi. Le pagine non generano errori, semplicemente non compaiono, e nulla nella tua dashboard segnala un ritardo di rendering finché non sai che devi andare a cercarlo. Il modo più rapido per capire a che punto sei è confrontare ciò che Google renderizza con ciò che il tuo sito serve. Parla con il team e ricevi un report SEO di esempio che mostra cosa sta succedendo ora sulle tue pagine.

Risorse / Riferimenti

1. Search Central
2. web.dev

Letture correlate: Infinite Scroll SEO: How to Stop Hiding Pages From Google.

Letture correlate: Dynamic Rendering: What It Fixes on a JavaScript Site (and What It Doesn't).

Fonti

• The Complete JavaScript SEO Guide
• JavaScript SEO: 6 Best Practices to Boost Rankings
• Mastering JavaScript SEO: pre-rendering and log analysis
• Get the Best Javascript SEO Practices
• What is JavaScript SEO?