SEO per SPA nel 2026: una guida HTML-first per Next.js, Nuxt, SvelteKit e Astro

In breve: Le single-page application possono posizionarsi, ma solo se URL, status code, metadati e contenuto primario sono presenti nella prima risposta HTML. Google può eseguire il rendering di JavaScript in ritardo; la maggior parte dei crawler AI non lo esegue affatto. Scegli un modello di rendering per rotta, consegna prima il documento e poi lo stato dell’app, quindi lascia che JavaScript idrati in sovrapposizione. Di seguito: una guida pratica 2026 per i team che usano Next.js, Nuxt, SvelteKit e Astro.

Smetti di chiederti se Google «supporta JavaScript»

La domanda d’apertura per la SEO delle SPA non è più «Googlebot è in grado di fare il rendering di JavaScript?». Sì, lo è. Martin Splitt lo ripete da anni. Eppure molti continuano a fare debug delle SPA fissando view-source: come se fosse quella la pagina indicizzata da Google.

«Molti guardano ancora il view source. Non è quello che usiamo per l’indicizzazione. Utilizziamo l’HTML renderizzato.»

Martin Splitt, Developer Advocate in Google

Una cattiva abitudine in meno. Se controlli solo il sorgente iniziale di un’app React, Vue, Angular, SvelteKit, Nuxt, Remix o Next.js, non vedi ciò che Google vede alla fine. Conta il DOM renderizzato.

Ma la domanda per il 2026 non è se Google possa fare il rendering. È se il documento arrivi abbastanza presto da essere utile per Googlebot, i parser social e i crawler AI che dominano sempre di più il grafo delle citazioni.

Il gap dei crawler AI ha cambiato i conti

Per anni ho trattato il problema come se riguardasse solo Google (errore mio per anni). Poi sono arrivati i crawler AI con un approccio diverso.

«I risultati mostrano costantemente che nessuno dei principali crawler AI esegue attualmente JavaScript.»

Vercel Engineering

GPTBot, ClaudeBot, PerplexityBot, il fetch di addestramento di Gemini: tutti recuperano HTML grezzo. Se il tuo contenuto più importante vive dietro l’idratazione, per quei crawler l’app appare vuota proprio dove dovrebbero esserci tabella prezzi, copy di prodotto, FAQ o contenuti comparativi. Esegui il nostro AI Crawler Inspector su alcune pagine SPA e vedrai quello che vedono loro.

Classifica le rotte prima di classificare il problema di rendering

La maggior parte dei team salta questo passaggio e chiede se l’intera SPA abbia bisogno di SSR. È un modo di porre la questione che spreca tempo di sviluppo.

Una vera SPA mescola due cose: pagine indicizzabili e stati privati dell’app. Pagine prezzi, articoli, documentazione, template, integrazioni, pagine di confronto e landing di prodotto sono pagine. Dashboard, flow di onboarding, modali, filtri, schermate account e report salvati sono stati applicativi.

Parti dalla classificazione. Non chiedere agli ingegneri di «sistemare la SEO dell’app». Chiedi di etichettare quali rotte meritano traffico di ricerca, poi scegli rendering, indicizzazione, canonical e status code per singola rotta.

Tipo di rotta	Dovrebbe posizionarsi?	Scelta di rendering	Regola di indicizzazione
Articolo blog	Sì	SSG o SSR	Index, canonical a sé
Landing di prodotto	Sì	SSG o SSR	Index, canonical a sé
Risultati di ricerca interna	Di solito no	CSR o SSR	Spesso noindex
Rotta dashboard	No	CSR va bene	Bloccata da auth o noindex
URL con filtro a faccette	A volte	SSR solo se curato	Canonical o noindex

Una SPA con 40 URL pubblici e 4.000 stati di dashboard non ha 4.040 pagine SEO. Ne ha 40 e un’interfaccia di prodotto. Le rotte pubbliche hanno bisogno di URL stabili, self-canonical, metadati consegnati dal server, link esplorabili, HTML utile al primo byte e status code corretti. Le rotte dashboard hanno bisogno di interazioni rapide, auth e gestione dello stato. Costringere entrambi i gruppi nello stesso modello di rendering di solito peggiora entrambi.

Scegli il modello di rendering per rotta, non per app

La strategia di rendering è una scelta architetturale, non un’impostazione da plugin. Se sbagli modello, ogni ticket successivo diventa una pezza.

CSR: ok per le dashboard, rischioso per le landing

Il rendering lato client è perfettamente adeguato per schermate software autenticate. Se l’utente deve effettuare login, i crawler non dovrebbero comunque indicizzare la rotta. Il CSR diventa rischioso quando lo stesso guscio dell’app serve pagine prezzi, documenti, articoli e pagine prodotto dove il contenuto appare solo dopo che JavaScript gira e le API rispondono.

SSG: noioso, veloce e spesso la scelta giusta

La generazione statica costruisce le pagine in HTML in fase di build. Per blog, documentazione, changelog, pagine glossario, template e la maggior parte dei contenuti marketing, l’SSG è difficile da battere: veloce, cache-abile, economico, amico dei crawler. Astro 5 spinge forte in questa direzione con l’architettura «islands» e zero-JS di default.

SSR: utile quando il contenuto pubblico cambia spesso

Il rendering lato server è adatto quando il contenuto pubblico varia per richiesta, geolocalizzazione, inventario, permessi o freschezza. Lee Robinson ha descritto il modello base di Next.js in modo chiaro:

«Next.js prerenderizza la pagina in HTML sul server a ogni richiesta.»

Lee Robinson, VP Developer Experience in Vercel

L’SSR offre ai crawler HTML senza attendere il bundle client pur lasciando che la pagina rifletta dati aggiornati.

ISR e PPR: il compromesso pratico per siti grandi

La Rigenerazione Statica Incrementale aggiorna le pagine statiche dopo la pubblicazione. Per SEO programmatica, documentazione e grandi librerie di template, l’ISR evita rebuild infiniti senza ricadere sul CSR completo. Next.js 15 ha portato il Partial Prerendering allo stato stabile: puoi spedire un guscio statico e fare streaming dei buchi dinamici nella stessa rotta. È un mix dei due approcci dentro un URL, più vicino a come si comportano davvero le pagine prodotto.

Dynamic rendering: il workaround che dovrebbe scadere

Il dynamic rendering serve una versione ai crawler e un’altra agli utenti. Può salvare una SPA legacy quando la migrazione non è pronta, ma non progettarei una nuova strategia di ricerca su di esso.

«Lo vedrei come un workaround temporaneo – dove temporaneo può voler dire un paio d’anni – ma resta una soluzione a tempo.»

John Mueller, Search Advocate in Google

Usa il dynamic rendering come ponte. Sostituisci il ponte con rotte pubbliche server-rendered o static-first.

Dettagli di framework che contano nel 2026

La scelta del modello di rendering è anche una conversazione di framework. I default sono cambiati negli ultimi dodici mesi e alcuni di quei cambi influiscono sulle decisioni SEO per le SPA.

• Next.js 15. React 19 stabile, Turbopack dev stabile, fetch e i route handler GET non sono più in cache di default. Il comportamento cache-di-default delle versioni precedenti nascondeva bug di contenuto obsoleto; i nuovi default ti costringono a impostare esplicitamente la cache per rotta. Il Partial Prerendering (PPR) è la feature SEO di punta: guscio statico con buchi dinamici in streaming, che permette alle pagine prodotto di restare crawler-friendly senza rinunciare alla freschezza. Per un approfondimento vedi la nostra guida SEO a Next.js, React e Nuxt.
• Nuxt 4. Il codice dell’app ora vive in app/ per default. Progetti TypeScript separati per app, server, shared e builder riducono i problemi di «type bleed» che facevano trapelare segreti server-only nei bundle client. Nuxt 4.4 (marzo 2026) ha aggiunto vue-router v5 e layout props tipizzati, due piccoli vantaggi per spedire metadati per rotta in modo pulito.
• SvelteKit 2 con Svelte 5 runes. Le pagine sono server-rendered di default; il prerendering è opt-in per rotta. Il modello mentale diventa «ogni rotta è SSR a meno che dica statica», invertendo la trappola SPA-by-default. I bundle restano abbastanza piccoli da non far sì che il costo di idratazione blocchi il first paint.
• Astro 5 (e 6). Zero JavaScript di default, architettura islands, supporto multi-framework per i componenti. Dopo l’acquisizione da parte di Cloudflare (gennaio 2026), la storia di deploy all’edge si è ulteriormente affinata. Astro è la risposta facile per SPA ricche di contenuti che necessitano di componenti React o Vue solo in pagine specifiche.

Il framework conta meno della disciplina per rotta. Ognuno di questi quattro può consegnare una SPA indicizzabile. Tutti e quattro possono consegnarne una invisibile se metti il contenuto pubblico dietro l’idratazione.

I crawl trap che ancora bloccano l’indicizzazione

I fallimenti duri della SEO per SPA sono di solito noiosi. Non misteriose penalizzazioni, ma bug di delivery.

La prima trappola è il guscio universale. Ogni URL restituisce la stessa risposta 200, la stessa root vuota, lo stesso bundle. Il router decide dopo se /pricing, /docs/api o /totally-fake-url esista. Così costringi i crawler a lavorare troppo e crei la seconda trappola: i soft 404.

«Invece di rispondere con 404, risponde con 200 … mostrando sempre una pagina basata sull’esecuzione JavaScript.»

Martin Splitt, Developer Advocate in Google

Le rotte non valide devono restituire veri status code 404 o 410. Un grazioso «page not found» lato client servito con 200 spreca comunque crawl budget e confonde i segnali di indicizzazione.

La terza trappola è una navigazione che i crawler non possono seguire. Bottoni, click handler ed eventi del router vanno bene per l’interazione, ma la scoperta interna ha ancora bisogno di anchor con veri attributi href. Se le tue pagine più importanti sono raggiungibili solo dopo un handler JavaScript, la crawlability è più debole di quanto sembri.

I metadati sono un altro errore comune. Molte SPA aggiornano titoli, descrizioni, canonical, tag robots, Open Graph e schema dopo i cambi rotta. Funziona a livello visivo in una scheda browser. Fallisce comunque per crawler, parser social e bot AI. I metadati per rotta devono stare nell’HTML restituito.

I canonical meritano un avvertimento a parte. Ho visto app idratate sovrascrivere un canonical corretto con un dominio di staging, un URL root o la rotta precedente. Il bug resta silenzioso finché gli URL duplicati si raggruppano male o inizia a posizionarsi la pagina sbagliata.

L’infinite scroll nasconde contenuto dietro stato client. Se pagina due, tre e successive non hanno URL esplorabili, i motori potrebbero non scoprirle mai. Usa URL paginati di fallback per archivi e categorie importanti.

Il contenuto principale caricato via API è fragile. Se H1, body copy, dettagli prodotto, recensioni o link interni richiedono chiamate API dopo l’idratazione, aumentano i punti di rottura: il traffico bot incontra rate limit, le API bloccano user-agent sconosciuti, i timeout lasciano il DOM renderizzato scarno.

Cosa citano davvero gli AI Overview da una SPA

Questa è la particolarità del 2026. Gli AI Overview di Google riassumono le risposte sopra i risultati organici e citano le fonti usate per comporre il sommario. Quelle citazioni sono il nuovo top of funnel e premiano un preciso formato HTML.

Il sistema di citazione prende segnali chiari e statici: testo visibile, heading, liste, tabelle, HTML semantico disponibile alla prima risposta. Non aspetta pazientemente l’idratazione. Se il tuo paragrafo più quotabile compare solo dopo una useEffect, un AI Overview non lo vedrà.

Tre cose contano per le pagine SPA che vogliono essere citate:

1. Paragrafi-risposta HTML-first. I primi 300-400 word di ogni rotta indicizzabile dovrebbero rispondere alla domanda principale senza JavaScript. La maggior parte delle citazioni AIO vive in quelle sezioni iniziali.
2. Struttura semantica per liste e tabelle. Liste puntate, numerate e tabelle HTML vengono estratte direttamente negli Overview. Div che fingono di essere tabelle no.
3. URL stabili che il bot AI può richiamare. Gli AI Overview ricontrollano le fonti citate. Pagine hash-routed, rotte solo query e fork di dynamic rendering rendono il refetch instabile.

La stessa logica vale per le citazioni di Perplexity, le risposte con browsing di ChatGPT e le letture web di Claude. I loro crawler recuperano HTML grezzo; se la risposta non è lì, la pagina non viene citata. Ottimizzare per le citazioni degli AI Overview approfondisce il tema, e la nostra analisi sull’impatto degli AIO spiega perché la perdita di impression sembra peggiore di quella di clic.

Consegna ogni rotta indicizzabile come documento prima

La regola a cui torno sempre: se la rotta merita traffico di ricerca, la prima risposta deve sembrare una pagina.

Significa che ogni URL pubblico restituisce HTML utile con i segnali core già presenti:

• Tag <title> corretto.
• Meta description.
• Canonical autoreferenziale.
• Un H1 chiaro.
• Contenuto principale.
• Link interni esplorabili.
• Dati strutturati dove rilevanti.
• Status code corretto.
• Tag Open Graph e Twitter se la condivisione conta.

JavaScript può poi idratare componenti, personalizzare elementi, tracciare eventi e arricchire l’esperienza. Non dovrebbe essere necessario perché il crawler capisca di cosa parla la pagina.

L’architettura del sito conta anche. Una rotta pubblica senza link esplorabili che puntano a lei è comunque debole, anche se server-rendered. Un documento perfettamente renderizzato sepolto a cinque clic dietro navigazione client-only non performa come uno dentro un sistema di linking interno chiaro.

Testa la SEO della tua SPA con l’HTML renderizzato, non con la speranza

Se testi solo l’esperienza browser, verifichi il percorso più felice. La SEO delle SPA ha bisogno di test più scomodi.

1. Recupera l’URL con JavaScript disabilitato e verifica che il contenuto abbia ancora senso.
2. Ispeziona l’URL in Google Search Console e rivedi l’HTML renderizzato.
3. Confronta l’HTML iniziale con il DOM renderizzato in Chrome DevTools.
4. Testa gli status code direttamente con curl -I https://example.com/missing-route.
5. Crawla il sito con un crawler che supporta JS e uno che non lo supporta.
6. Conferma che title, canonical, tag robots, schema e link interni esistano prima dell’idratazione.
7. Controlla i log server per hit bot, API bloccate, timeout e redirect inattesi.
8. Valida i dati strutturati con il Rich Results Test di Google dopo il rendering.

Il test scomodo è quello dell’H1: se Googlebot ha bisogno di cinque step e due chiamate API per trovare l’H1, la pagina è fragile anche se finisce indicizzata. Applica lo stesso test a GPTBot, ClaudeBot e PerplexityBot: se quei crawler non vedono l’H1 nell’HTML grezzo, la rotta non comparirà come citazione AI.

Checklist SPA SEO per il 2026

Usala a livello di rotta. Un «pass» globale nasconde troppi fallimenti SPA.

• Rendering: Le pagine pubbliche usano SSG, SSR, ISR o PPR. Le schermate private restano in CSR.
• Routing: Ogni URL indicizzabile ha rotta unica, contenuto unico e self-canonical.
• Status code: Le pagine mancanti restituiscono 404 o 410, non 200.
• Link: La navigazione interna usa anchor esplorabili con veri attributi href.
• Metadati: Title, description, canonical, tag robots, Open Graph e schema sono specifici per rotta e presenti in HTML.
• Contenuto: Copia principale, H1, info prodotto e link chiave esistono senza attendere dati client-only.
• Performance: Dimensione bundle, costo idratazione, script di terze parti e code-splitting per rotta sono sotto controllo.
• Controllo indice: Dashboard, rotte private, filtri low-value e pagine di ricerca thin sono bloccate o noindex.
• Testing: HTML iniziale, DOM renderizzato e contenuto indicizzato sono confrontati sui template importanti.
• Visibilità AI: Paragrafi-risposta, liste e tabelle citabili compaiono in HTML grezzo così che AI Overview e motori AI possano citarli.

Search, risposte AI, anteprime link e sistemi di discovery dipendono tutti dall’accesso. I ranking vengono dopo.

L’architettura SPA SEO più semplice che spedirei oggi

Se iniziassi una SPA moderna pensando al traffico di ricerca, non renderei server-side l’intero prodotto. La dividerei.

Area del sito	Approccio consigliato
Sito marketing	Generazione statica
Blog e documentazione	Generazione statica o ISR
Pagine prodotto	SSR, ISR o PPR di Next.js
Pagine SEO programmatica	Generazione statica con forte pruning
Dashboard	CSR dietro auth
Pagine di ricerca e filtro	Noindex a meno che curate manualmente
Rotte non valide	Vero 404 o 410
Layout condiviso	Metadati e navigazione server-rendered

Le pagine marketing e gli articoli devono essere HTML-first. Le superfici di prodotto che richiedono freschezza usano SSR, ISR o PPR. La dashboard resta app-like perché indicizzarla sarebbe inutile. Le pagine SEO programmatica richiedono moderazione: la generazione statica rende facili migliaia di pagine, comprese migliaia che nessuno dovrebbe indicizzare. Genera solo quelle con reale domanda di ricerca, contenuto utile e link interni. Pota il resto prima che Google debba decidere al posto tuo.

La SPA vincente non è quella che dimostra che i crawler possono eseguire JavaScript. È quella che non costringe i crawler a fare lavoro inutile.

FAQ

Una single-page application può posizionarsi su Google nel 2026?

Sì. Una SPA può posizionarsi se le rotte indicizzabili restituiscono contenuto esplorabile, metadati corretti, link interni e status code validi nella prima risposta HTML. Google può fare il rendering di JavaScript, ma affidarsi a esso per tutto rende il sito più fragile e invisibile ai crawler AI che non lo eseguono affatto.

Il rendering lato server è obbligatorio per la SEO di una SPA?

Non per ogni rotta. L’SSR è adatto alle pagine pubbliche con contenuto variabile. L’SSG o l’ISR è spesso preferibile per contenuto stabile. Il Partial Prerendering di Next.js 15 combina entrambi in una rotta. Il CSR va bene per dashboard private e stati applicativi che non dovrebbero essere indicizzati.

Le hash route sono dannose per la SEO?

Le hash route sono una scelta poco indicata per pagine indicizzabili. Possono funzionare per frammenti on-page, ma il contenuto pubblico dovrebbe avere URL puliti, metadati specifici per rotta e status code a livello server.

Le pagine di risultati di ricerca di una SPA vanno indicizzate?

Di solito no. Le pagine di ricerca interna e i filtri a faccette creano spesso URL thin o duplicati. Le pagine filtro curate possono essere indicizzate quando hanno domanda unica, contenuto stabile e una strategia canonical chiara.

Come faccio a sapere se la mia SPA ha un problema di soft 404?

Richiedi un URL fittizio e controlla lo status code. Se /this-page-should-not-exist restituisce 200 con un messaggio not-found lato client, hai un rischio soft 404 che spreca crawl budget.

Gli AI Overview citeranno una SPA renderizzata con JavaScript?

Solo se il contenuto citato esiste in HTML grezzo. La maggior parte dei crawler AI non esegue JavaScript. Server-renderizza o prerenderizza i paragrafi, le liste e le tabelle che vuoi vengano citati.

Serve aiuto per trasformare la tua SPA in pagine esplorabili?

SEOJuice aiuta i team a rafforzare i link interni esplorabili e i segnali HTML-first sulle pagine pubbliche che meritano traffico di ricerca. Se la tua SPA ha rotte orfane, template sepolti o pagine che Google sembra non raggiungere mai, il linking interno automatizzato può rendere il layer documento più accessibile a crawler e bot AI.

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Una single-page application può posizionarsi su Google nel 2026?", "acceptedAnswer": { "@type": "Answer", "text": "Sì. Una SPA può posizionarsi se le rotte indicizzabili restituiscono contenuto esplorabile, metadati corretti, link interni e status code validi nella prima risposta HTML. Google può fare il rendering di JavaScript, ma affidarsi a esso per tutto rende il sito più fragile e invisibile ai crawler AI che non lo eseguono affatto." } }, { "@type": "Question", "name": "Il rendering lato server è obbligatorio per la SEO di una SPA?", "acceptedAnswer": { "@type": "Answer", "text": "Non per ogni rotta. L’SSR è adatto alle pagine pubbliche con contenuto variabile. L’SSG o l’ISR è spesso preferibile per contenuto stabile. Il Partial Prerendering di Next.js 15 combina entrambi in una rotta. Il CSR va bene per dashboard private e stati applicativi che non dovrebbero essere indicizzati." } }, { "@type": "Question", "name": "Le hash route sono dannose per la SEO?", "acceptedAnswer": { "@type": "Answer", "text": "Le hash route sono una scelta poco indicata per pagine indicizzabili. Possono funzionare per frammenti on-page, ma il contenuto pubblico dovrebbe avere URL puliti, metadati specifici per rotta e status code a livello server." } }, { "@type": "Question", "name": "Le pagine di risultati di ricerca di una SPA vanno indicizzate?", "acceptedAnswer": { "@type": "Answer", "text": "Di solito no. Le pagine di ricerca interna e i filtri a faccette creano spesso URL thin o duplicati. Le pagine filtro curate possono essere indicizzate quando hanno domanda unica, contenuto stabile e una strategia canonical chiara." } }, { "@type": "Question", "name": "Come faccio a sapere se la mia SPA ha un problema di soft 404?", "acceptedAnswer": { "@type": "Answer", "text": "Richiedi un URL fittizio e controlla lo status code. Se /this-page-should-not-exist restituisce 200 con un messaggio not-found lato client, hai un rischio soft 404 che spreca crawl budget." } }, { "@type": "Question", "name": "Gli AI Overview citeranno una SPA renderizzata con JavaScript?", "acceptedAnswer": { "@type": "Answer", "text": "Solo se il contenuto citato esiste in HTML grezzo. La maggior parte dei crawler AI non esegue JavaScript. Server-renderizza o prerenderizza i paragrafi, le liste e le tabelle che vuoi vengano citati." } } ] } </script>