SEO per JavaScript: come indicizzare un’app JS

TL;DR: Google può indicizzare JavaScript, ma il rendering lato client introduce un passaggio differito tra crawling e indicizzazione. Inserisci contenuto principale, metadati specifici della route e link scansionabili in HTML renderizzato lato server o in HTML statico. Poi usa lo Strumento di ispezione URL di Google Search Console per verificare il DOM renderizzato, le risorse e gli eventuali errori JavaScript, invece di presumere che il tuo browser rappresenti ciò che Google ha ricevuto.

Se la tua app in React, Vue, Angular o “suppostamente” renderizzata lato server non compare su Google, smetti di chiederti se Googlebot “supporta JavaScript”. Lo supporta. La domanda utile è se Google riesce a recuperare le risorse necessarie, eseguire l’applicazione, scoprire i suoi link e produrre un DOM indicizzabile prima che qualcosa vada storto.

La pipeline che la tua app JavaScript deve riuscire a superare

Google Search Central descrive l’elaborazione di JavaScript in tre fasi distinte:

“Google elabora le web app JavaScript in tre fasi principali: 1. Crawling 2. Rendering 3. Indexing”

Prima, Googlebot richiede l’URL e analizza la risposta. Se quella risposta è praticamente una shell di applicazione vuota, Google non ha ancora il catalogo del tuo prodotto, il corpo dell’articolo, le intestazioni, i metadati generati dal client o i link alle route. Ha un URL, un po’ di impalcatura HTML e riferimenti a risorse.

Google poi accoda le pagine idonee per il rendering. La sua documentazione dice: “La pagina può rimanere in questa coda per pochi secondi, ma può volerci anche di più.” Questo è il modello corretto. Evita la vecchia affermazione secondo cui JavaScript crea sempre un ritardo di indicizzazione di giorni o settimane; Google non lo dice. C’è comunque una coda differita, ma la tua pagina deve comunque renderizzarsi con successo quando arriva in testa.

Quella coda è lo stadio che gli sviluppatori tendono a omettere mentalmente. Nell’ambiente locale l’app sembra completa, mentre la risposta recuperata può contenere ben poco, ad esempio solo un elemento root e i riferimenti ai bundle (view-source è utile qui, anche se è solo metà della diagnosi).

Durante il rendering, Google esegue la pagina in un browser headless. Google conferma che “Google Search esegue JavaScript con una versione evergreen di Chromium”. Quindi, la sintassi moderna dei framework difficilmente sarà il problema. Tra gli indizi più sospetti ci sono risorse bloccate, richieste API fallite, eccezioni a runtime, contenuti controllati da interazioni e una scarsa semantica dei link.

Dopo il rendering, Google può ispezionare il DOM risultante ed estrarre gli URL aggiunti da JavaScript. Questi URL tornano nella coda di crawling. L’indicizzazione avviene poi, più tardi. Le nostre guide su cosa significa crawling in SEO e come funziona l’indicizzazione di Google descrivono i confini tra queste fasi.

Una pagina di categoria renderizzata lato client può quindi essere nota a Google come URL mentre i suoi prodotti, le descrizioni e i link in uscita restano sconosciuti. Scoprire non significa indicizzare. Un URL indicizzato non è nemmeno una prova che Google abbia visto la pagina completa.

CSR funziona, ma è un default fragile per pagine che devono posizionarsi

Addy Osmani e Jason Miller definiscono il rendering lato client su web.dev come il rendering di un’app nel browser usando JavaScript per modificare il DOM. Il server-side rendering invia HTML generato dal server. Il static rendering crea quell’HTML in fase di build. L’hydration aggiunge stato dell’app e gestori di eventi a un HTML che esiste già.

Il problema SEO del CSR è strutturale, non ideologico. Il tuo contenuto importante manca dalla risposta iniziale e dipende da un altro sistema che faccia più lavoro in un secondo momento. Può funzionare benissimo. Io, però, non lo renderei il requisito per ogni route pubblica, quando l’HTML evita un’intera classe di fallimenti.

“In generale, incoraggiamo gli sviluppatori a considerare il server-side rendering o il static rendering rispetto a un approccio di full rehydration.”

Questa è la raccomandazione di Osmani e Miller, non un invito a trasformare ogni applicazione in un sito statico. Un dashboard analytics privato ha requisiti diversi da una categoria di un marketplace pubblico. Esegui sul server o in fase di build ciò che deve posizionarsi, poi aggiungi interattività lato client dove vale davvero il costo.

I framework offrono diverse strade per arrivare a questa architettura. La nostra guida a SEO per Next.js, React e Nuxt copre le scelte specifiche per il framework. Ma un framework compatibile con SSR non garantisce che l’output sia davvero renderizzato lato server. Io l’ho dato per scontato, finché non ho scoperto che i dati utili venivano comunque recuperati dopo il mount (il logo del framework non mi ha salvato).

Non riportare in auge il dynamic rendering

Il dynamic rendering dà ai bot una pagina pre-renderizzata mentre gli utenti ricevono l’app JavaScript. Google lo documentava come workaround, ma la guida attuale è esplicita:

“Il dynamic rendering era un workaround e non una soluzione di lungo periodo per i problemi con contenuti generati con JavaScript nei motori di ricerca.”

La documentazione di Google sul dynamic rendering raccomanda invece server-side rendering, static rendering o hydration. Qui è dove metterei tempo di ingegneria. Il rilevamento dei bot, cache separate e due possibili versioni di ogni pagina creano più opportunità perché contenuto e metadati divergano.

Se il dynamic rendering sostiene già un sito legacy, non rimuoverlo senza un piano di migrazione. Semplicemente non scambiare un workaround tollerato per una nuova architettura davvero sana.

I fallimenti SEO con JavaScript che controllerei per primi

1. Il contenuto principale esiste solo dopo l’esecuzione di JavaScript

Recupera l’URL senza eseguire JavaScript. Se la risposta contiene un’app root, un messaggio di loading e ben poco altro, ogni elemento davvero rilevante dipende dalla fase di rendering di Google. Sposta testo principale della pagina, intestazioni, schede prodotto, corpo dell’articolo e navigazione essenziale nell’output di SSR o SSG.

Non devi eliminare JavaScript. Ti serve una base HTML utile. Mantieni filtri, calcolatori, stato dell’account e controlli interattivi sul client quando ha senso. Il test più efficace è questo: se il bundle principale fallisce, la risposta riesce comunque a spiegare cosa contiene questo URL?

Testa template rappresentativi, non un singolo URL comodo. Una homepage può essere statica mentre le pagine di categoria recuperano tutto solo dopo il mount. Le pagine prodotto possono usare SSR mentre le route filtrate restituiscono la shell generica. Una sola pagina che passa dimostra meno di quanto la maggior parte dei team vorrebbe dimostrare.

Io sistemo questo prima di “rifinire” i metadati. Un title server-rendered non può compensare un corpo dell’articolo vuoto. Viceversa, un articolo completo resta comunque nei guai se Google riceve uno stato di loading permanente. Prima l’architettura.

2. I tuoi “link” sono gestori di eventi

È uno dei problemi più comuni che vediamo sui siti collegati a SEOJuice. Una card o un elemento di menu richiama un metodo del router, ma il markup non contiene alcun tag

“Google può scoprire i tuoi link solo se sono elementi HTML <a> con un attributo href.”

Ispeziona menu, card, paginazione, breadcrumbs, moduli di contenuti correlati, filtri con destinazioni stabili e navigazione del logo. Se interi gruppi di route non sono presenti su Google, fai prima un audit dei link dalle pagine già note, prima di dare la colpa all’indicizzazione. La nostra guida alle best practice SEO per SPA approfondisce la scoperta delle route e la navigazione lato client.

3. robots.txt blocca risorse JavaScript, CSS o API

Google afferma che Search non eseguirà il rendering di JavaScript da file bloccati o su pagine bloccate. Controlla regole generiche di robots.txt per i percorsi degli asset come /static/, /_next/, le directory di build e gli endpoint API “proxati” necessari per costruire contenuti pubblici.

Ispeziona gli URL degli asset effettivamente distribuiti invece di fidarti della configurazione del repository. Una regola CDN, un file robots specifico per l’ambiente, un controllo di autenticazione o un percorso di deployment non aggiornato possono far sì che la produzione si comporti in modo diverso dallo sviluppo locale (in produzione rimane sorprendentemente “inventiva”).

Conferma anche che le risorse restituiscano risposte utili a Googlebot. Un bundle che torna 403, una chiamata API che fallisce senza cookie di sessione o un URL di chunk scaduto può lasciare il crawler con una shell vuota, anche se robots.txt sembra pulito.

4. Il contenuto importante richiede interazione

Se il contenuto viene recuperato solo dopo la selezione di una tab, la pressione di “Carica altro”, l’attivazione di una richiesta dipendente dallo scroll o la concessione di un permesso, potrebbe non comparire nel DOM che Google indicizza. La documentazione di troubleshooting di Google dice agli sviluppatori di “Aspettarsi che Googlebot rifiuti le richieste di permesso degli utenti”.

Rendi indicizzabile il contenuto senza richiedere un percorso utente. Il contenuto paginato dovrebbe avere URL stabili e link scansionabili. Se una tab contiene informazioni distintive da indicizzare, includile nell’HTML iniziale o fornisci una destinazione scansionabile. Un crawler non dovrebbe dover simulare l’uso di un prodotto per ottenere il tuo contenuto principale.

5. Il router mostra un 404 mentre il server restituisce 200

Una SPA può mostrare un componente “Non trovato” curato per una route non valida, mentre il server riporta 200 OK. Google lo tratta come un pattern “soft-404”. Le correzioni documentate sono reindirizzare a un URL dove il server restituisce un vero 404 oppure aggiungere o modificare il meta tag robots per noindex.

Preferisco lo stato corretto lato server, quando lo stack lo permette. I codici di stato comunicano cosa è successo prima dell’avvio dell’app. Sono anche molto più facili da monitorare rispetto allo stato del router.

Controlla URL prodotto malformati, record eliminati, paginazione non valida, route con locale non corretti e percorsi catch-all. Questi edge case spesso ereditano la stessa shell dell’app delle pagine valide e generano in silenzio migliaia di URL di errore “apparentemente riusciti”.

6. L’hydration danneggia un HTML lato server valido

SSR può restituire HTML completo e comunque fallire dopo il caricamento. web.dev segnala che i controlli server-rendered non possono rispondere finché gli script lato client non vengono eseguiti e non agganciano i gestori di eventi. Un’eccezione di hydration può lasciare gli utenti con controlli inutilizzabili; una mancata corrispondenza può sostituire o rimuovere contenuti che erano presenti nella risposta.

Confronta tre stati: HTML grezzo, DOM nel browser dopo l’hydration e DOM renderizzato da Google. Se la risposta grezza è corretta ma il DOM renderizzato perde contenuto, passare a SSR non ha risolto tutto. Ha solo spostato il punto di fallimento.

7. Title, canonical e descrizioni arrivano troppo tardi

Google conferma che JavaScript può impostare o modificare il title e la meta description. Detto questo, i metadati specifici della route dovrebbero stare nella risposta server o statica quando possibile. Se il rendering fallisce, Google potrebbe incontrare il titolo generico dell’app invece della versione specifica della pagina.

Applica la stessa disciplina ai canonical tag e alle direttive robots. Le modifiche lato client possono essere elaborate, ma rendere segnali critici di indicizzazione dipendenti dall’esecuzione offre poco e crea un ulteriore punto in cui i bug di routing possono propagarsi tra template.

Come capire davvero cosa ha renderizzato Google

Lo strumento determinante è l’URL Inspection Tool in Google Search Console. Il browser, i crawler locali e Lighthouse possono evidenziare difetti, ma nessuno di questi rappresenta il risultato registrato da Googlebot.

1. Ispeziona l’URL canonico esatto. Non testare solo la homepage se le pagine mancanti usano un altro template o un percorso di fetch diverso.
2. Apri “View Crawled Page”. Per una pagina non ancora indicizzata, usa Test Live URL e controlla il risultato testato.
3. Leggi l’HTML renderizzato. Cerca una frase distintiva dal contenuto principale, il title specifico della route, l’URL canonico e i link verso pagine più profonde.
4. Controlla lo screenshot. Radici vuote, stati di loading, overlay di consenso e sezioni mancanti possono far emergere subito un rendering fallito.
5. Rivedi messaggi della console e risorse della pagina. Cerca eccezioni, bundle bloccati, chiamate API fallite e errori di caricamento dei chunk.
6. Confrontalo con la risposta grezza. Recupera l’URL con un client HTTP da riga di comando. La differenza tra l’HTML della risposta e l’HTML renderizzato da Google è la dipendenza JavaScript che devi valutare.

La guida di troubleshooting di Google sul JavaScript dice che questi strumenti mettono in evidenza risorse caricate, output della console JavaScript ed eccezioni, DOM renderizzato e altre informazioni diagnostiche. Se un paragrafo o un link importante è assente in quel DOM, aspettare i ranking non è una strategia di test. Devi riparare il percorso di rendering.

Su SEOJuice siamo un team di due persone, Lida e io. L’ispezione diretta conta perché non possiamo permetterci di trasformare ogni problema di indicizzazione in una settimana di debug speculativo. HTML grezzo, HTML renderizzato, risorse, console. Quattro controlli restringono subito il problema.

Abbiamo visto la differenza chiaramente durante la migrazione da seojuice.io a seojuice.com di gennaio 2026. Le pagine sembravano corrette in un browser normale e i test live potevano passare, mentre i crawl registrati da Google per alcune route erano ancora indietro. Un test live riuscito dimostra che Google riesce a renderizzare la pagina in fase di test; non riscrive i crawl storici né garantisce l’indicizzazione (anche io vorrei quel pulsante).

Un gate di rilascio pratico per pagine JavaScript indicizzabili

Non trattare la SEO con JavaScript come un’attività di “pulizia” dopo il lancio. Aggiungi un piccolo gate di rilascio per ogni template pubblico:

• L’URL restituisce lo status code previsto senza affidarsi al routing lato client.
• L’HTML grezzo contiene l’intestazione principale, il testo principale e i metadati specifici della route.
• Navigazione usa elementi anchor con attributi href.
• JavaScript, CSS e le risorse dati pubbliche necessarie sono scansionabili.
• La pagina resta utile se l’hydration fallisce.
• Il DOM renderizzato contiene lo stesso contenuto principale e gli stessi segnali di indicizzazione della risposta.
• Le route non valide ed eliminate restituiscono una risposta di errore reale oppure una direttiva noindex deliberata.

Non è una richiesta di HTML pixel-identico. Lo stato interattivo può differire. Il requisito è che il significato della pagina, le destinazioni scopribili e le istruzioni di indicizzazione sopravvivano a ogni fase della pipeline di Google.

Dove SEOJuice si inserisce e dove no

SEOJuice lavora su un sito live tramite uno snippet JavaScript o un plugin per CMS. Applica continuamente attività on-page come internal link, title e meta description, markup schema e testo alternativo delle immagini (alt text). L’audit può anche evidenziare metadati mancanti, contenuti renderizzati sottili o assenti, risorse bloccate, pattern di link non scansionabili e gap di indicizzazione.

Non converte un’app CSR in SSR. Dato che lo snippet gira lato client, l’output condivide la dipendenza di rendering discussa sopra. Se il contenuto principale manca dall’HTML, sistema prima l’architettura di rendering; l’automazione dovrebbe stare “sopra” a una pagina che Google può elaborare in modo affidabile.

Se l’app renderizza correttamente e vuoi identificare gli errori on-page e di indicizzazione rimasti, esegui free SEO audit. È disponibile un piano gratuito senza carta di credito.

Domande frequenti

Google può indicizzare JavaScript?

Sì. Google Search esegue JavaScript usando una versione evergreen di Chromium. Le pagine JavaScript passano comunque per una fase di rendering differita, quindi il contenuto può essere ritardato o mancato se le risorse sono bloccate, l’esecuzione fallisce o le informazioni importanti richiedono interazione con l’utente.

Perché la mia app React, Vue o Angular non è presente su Google?

La causa più probabile non è il framework in sé. Verifica se contenuto e link essenziali compaiono solo dopo l’esecuzione lato client, se bundle o API non sono disponibili a Googlebot e se errori a runtime impediscono il rendering. Controlla anche i soft 404, i metadati generici impostati dal client e la navigazione senza anchor reali.

Qual è la differenza tra SSR, SSG e CSR per la SEO?

SSG genera HTML in fase di build. SSR genera HTML sul server per ogni richiesta. In entrambi i casi il contenuto principale è presente nella risposta. CSR costruisce la pagina nel browser, quindi quel contenuto dipende dalla fase di rendering successiva di Google. Per pagine pubbliche che ci si aspetta che si posizionino, SSG o SSR sono di solito l’impostazione predefinita più sicura.

Google raccomanda ancora il dynamic rendering?

No. Google definisce il dynamic rendering un workaround, non una soluzione di lungo periodo. Le sue indicazioni attuali indirizzano gli sviluppatori verso server-side rendering, static rendering o hydration. Non iniziare una nuova implementazione basata su output separati per bot e utenti.

Le button JavaScript e la navigazione con onClick contano come link?

Non come link scansionabili. Google documenta la scoperta dei link tramite elementi anchor con attributi href. Usa anchor semantici per le destinazioni navigabili, anche se un router lato client li intercetta per evitare un reload completo della pagina.

Come vedo la pagina che Googlebot ha renderizzato?

Ispeziona l’URL esatto in Google Search Console, apri la pagina crawled oppure quella testata live, e controlla l’HTML renderizzato, lo screenshot, le risorse caricate e i messaggi della console JavaScript. Cerca nell’HTML il testo principale e i link interni. Se non ci sono, allora Google non ha ricevuto la pagina completa durante quel test.