SEO per Single Page App: perché spariscono da Google

La SEO per le single page app va in crisi per un solo motivo: i motori di ricerca spesso vedono una pagina vuota là dove i tuoi utenti vedono un'app interattiva completa. La tua SPA si carica in fretta e sembra un software, ma può comunque sparire da Google perché Googlebot non riceve mai il contenuto da indicizzare. Colma le lacune di rendering, routing e metadati, e la stessa app può posizionarsi.

Che cos'è una single page app

Una single page application, o SPA, carica un unico file HTML e costruisce il resto dell'esperienza con JavaScript. Invece di chiedere al server una pagina nuova a ogni clic su un link, il browser sostituisce i contenuti all'interno della stessa pagina: niente ricaricamento e nessuna attesa della rete.

È proprio questo il suo punto di forza, ed è anche all'origine di ogni problema SEO trattato in questo articolo.

Come si differenziano le SPA da un sito tradizionale

Un sito tradizionale multi-pagina invia un nuovo documento HTML completo per ogni URL. Il lavoro lo fa il server e il browser mostra il risultato, quindi un crawler che legge quell'HTML vede gli stessi contenuti che vede un visitatore umano.

Una SPA ribalta questo schema. Il server invia un guscio HTML quasi vuoto più un bundle JavaScript, e il browser esegue quel codice per recuperare i dati, costruire la pagina e inserire i contenuti nel DOM. Un crawler che si ferma all'HTML grezzo trova un tag script e un contenitore vuoto.

La maggior parte delle SPA è costruita con React o Angular, e anche Vue è diffuso. Si differenziano per sintassi e strumenti, ma hanno in comune un compromesso: velocità e interattività da app in cambio di una strada più in salita verso la visibilità nei risultati di ricerca.

Esempi comuni che usi già

Usi continuamente single page app, spesso senza accorgertene:

• Gmail e Google Maps aggiornano i contenuti sul posto mentre scorri, sposti la mappa o fai zoom.
• Trello e Asana aggiornano schede e bacheche all'istante, senza ricaricare la pagina.
• Il player web di Spotify mantiene navigazione e riproduzione su un'unica pagina continua.
• La ricerca e i filtri di Airbnb aggiornano i risultati mentre modifichi i filtri, senza caricare una nuova pagina.

Questi prodotti funzionano come SPA perché la risposta immediata migliora l'esperienza: una bacheca Trello che si ricaricasse a ogni drag-and-drop sembrerebbe rotta. Nessuno di loro dipende in modo prevalente dal traffico organico verso pagine nuove, come invece accade a un sito di contenuti, a un blog o a un catalogo e-commerce, e molti team capiscono questa differenza solo dopo aver scelto questa architettura per un sito di marketing.

Perché le single page app spariscono dai risultati di ricerca di Google

Le pagine spariscono da Google per uno di tre motivi che si sovrappongono: il crawler non vede il contenuto, il contenuto non si trova a un URL scansionabile, oppure Google indicizza la pagina ma la considera povera di contenuto o duplicata. Le SPA sono soggette a tutti e tre contemporaneamente.

Il problema della scansione

Googlebot richiede una pagina in due fasi. Prima scarica l'HTML grezzo, che in una SPA è per lo più un <div id="root"></div> e una manciata di tag <script>. Poi deve analizzare, compilare ed eseguire il JavaScript prima di poter vedere il tuo contenuto vero e proprio.

La seconda fase non avviene subito. Google mette in coda il rendering del JavaScript separatamente dalla scansione iniziale, e l'intervallo può andare da pochi secondi a diversi giorni, a seconda del crawl budget del tuo sito e dei tempi di risposta del server. Google Search Central documenta questo processo in due ondate: Google scansiona l'HTML, mette la pagina in coda per il rendering, poi scansiona di nuovo il risultato renderizzato quando le risorse lo consentono. Se la pipeline di gestione dei contenuti, la sitemap o i link interni non reggono durante questo intervallo, la pagina può essere segnalata come povera di contenuto, saltata o mai messa in coda per il secondo passaggio. La nostra guida su come funziona davvero l'indicizzazione dei motori di ricerca e perché alcune pagine vengono saltate approfondisce il processo in due fasi.

Il problema del budget di rendering

Renderizzare JavaScript costa molto più che leggere HTML statico. Google deve avviare un ambiente simile a un browser, scaricare ogni script e ogni dipendenza, eseguire il codice e attendere che le chiamate asincrone ai dati si risolvano prima di avere la pagina completa. Su un sito con migliaia di URL, chiedi a Google di spendere molta più potenza di calcolo di quanta ne richieda un concorrente in HTML statico.

L'infrastruttura di scansione di Google ora si basa su un motore di rendering evergreen che segue le versioni moderne di Chromium, quindi è in grado di eseguire gran parte del JavaScript attuale. È un vero progresso rispetto a qualche anno fa, ma "può renderizzarlo" è diverso da "lo renderizzerà in fretta, ogni volta, per ogni pagina". I siti con molte pagine o con segnali di scansione deboli possono vedere le richieste di rendering messe in secondo piano, e questo si traduce in pagine ferme per settimane su "Discovered, currently not indexed" in Search Console.

Il problema degli URL: una pagina, molte viste

Il problema strutturale più profondo è che una SPA classica ha esattamente un solo URL. Puoi passare in rassegna dieci pagine prodotto e la barra degli indirizzi può restare la stessa oppure aggiungere solo un frammento come #/product/42. Per un crawler, un frammento dopo un # significa storicamente "stessa pagina, diversa posizione di scorrimento", non un nuovo documento da indicizzare.

Così Google può vedere un solo URL per tutto il tuo catalogo, il tuo blog o la tua app, per quante pagine distinte possa raggiungere una persona. Un URL significa una voce nell'indice, un title tag, una meta description e una sola possibilità di posizionarsi per una sola query. Tutto il resto è invisibile.

Una single page app va bene per la SEO?

Sì, ma solo con un lavoro tecnico mirato. Una SPA con rendering lato client e senza alcuna modifica è, di default, pessima per la SEO. Lo stesso framework con rendering lato server, URL reali per ogni vista e metadati per vista può posizionarsi bene quanto un sito tradizionale: il problema è dunque la configurazione predefinita, non l'architettura.

Conta anche a cosa serve la pagina. Poche viste di funzionalità dentro una dashboard con accesso riservato non hanno bisogno di posizionarsi, dato che nessuno cerca la tua schermata delle fatture. Un blog pubblico, un catalogo prodotti o un sito di marketing costruiti come pura SPA hanno invece bisogno di posizionarsi, ed è qui che si concentrano la maggior parte dei danni.

Architettura	SEO di base	Caso d'uso tipico	Compromesso principale
SPA (rendering lato client)	Debole: URL unico, HTML iniziale vuoto	Dashboard, strumenti interni, app con accesso riservato	Interazioni in-app più veloci, la più difficile da scansionare
MPA (multi-pagina, renderizzata lato server)	Solida di default	Blog, siti di notizie, cataloghi e-commerce	Semplice da scansionare, ma i ricaricamenti completi sembrano più lenti
SPA con SSR/SSG (ibrida)	Solida, con lavoro di configurazione	Siti di marketing, SaaS, negozi online che vogliono un'esperienza da app e traffico dalla ricerca	Il meglio dei due mondi, ma aggiunge complessità di build e infrastruttura
PWA (progressive web app)	Solida se costruita su SSR/SSG	Prodotti mobile-first che vogliono supporto offline e posizionabilità	Installabile e utilizzabile offline, ma richiede comunque lavoro di rendering per i crawler

Se il tuo sito ha bisogno sia di traffico organico sia di un'esperienza da app, la risposta realistica è un approccio ibrido: SSR o generazione statica sotto un framework SPA.

Il compromesso della velocità: perché i team scelgono comunque le SPA

I team non scelgono l'architettura SPA per caso. La scelgono perché velocità e reattività spostano il fatturato. Una volta caricato il bundle iniziale, la navigazione sembra istantanea perché ogni clic evita il viaggio di andata e ritorno al server, e il tempo di caricamento ha un effetto ben documentato sulla conversione.

Amazon ha dichiarato che un secondo in più di ritardo nel caricamento della pagina può costare circa l'1% delle vendite, una cifra stimata in circa 1,6 miliardi di dollari l'anno alla scala di Amazon. Benchmark più recenti raccontano una storia simile. La ricerca 2025 di Queue-it ha rilevato che ridurre di un secondo il tempo di caricamento può aumentare i tassi di conversione e-commerce di circa il 5,6%, e un benchmark di Portent ha rilevato che ogni secondo aggiuntivo di caricamento tra zero e cinque secondi può far calare i tassi di conversione di circa il 4,42%. La ricerca "Milliseconds Make Millions" di Google e Deloitte ha rilevato che togliere 0,1 secondi al tempo di caricamento su mobile può portare fino a un 10% di aumento della conversione. I dati 2025 di BrowserStack indicano che circa il 40% dei visitatori abbandona un sito che impiega più di tre secondi a caricarsi.

Questo è il motivo economico a favore dell'interattività in stile SPA, ed è anche il motivo per cui rinunciare alla visibilità nella ricerca organica per ottenerla è un compromesso così costoso. Puoi avere velocità e SEO insieme se progetti l'architettura pensando a entrambe, come vedremo nelle prossime sezioni.

Come Google scansiona e renderizza oggi il JavaScript

La capacità di Google di elaborare JavaScript è migliorata molto negli ultimi anni, ma migliorata non significa uguale all'HTML statico. Conoscere i meccanismi ti mostra dove la tua SPA ha più probabilità di perdere visibilità.

L'indicizzazione in due ondate, in pratica

Pensala come due passaggi. Nella prima ondata, Googlebot scarica il tuo HTML ed estrae link, testo e metadati presenti senza JavaScript. Nella seconda ondata, che segue una pianificazione separata, Google renderizza la pagina in un browser headless ed estrae di nuovo il contenuto, compreso tutto ciò che il JavaScript ha inserito.

Se il tuo contenuto esiste solo dopo la seconda ondata, dipendi dalla coda di rendering di Google, che si contende le risorse con tutti gli altri siti basati su JavaScript del web. Uno studio di Vercel e della società di SEO tecnica MERJ, che ha analizzato più di 100.000 richieste di Googlebot, ha rilevato che Google in genere renderizza con successo i contenuti JavaScript, ma con ritardi significativi e lacune occasionali, a seconda di come si carica lo script e di quanto è complesso il percorso di rendering.

Il rendering costa potenza di calcolo reale, tua e di Google

Ogni pagina renderizzata con JavaScript costa più risorse di server e crawler rispetto a una pagina in HTML statico. Per una SPA questo ha due conseguenze:

1. Google può scansionare il tuo sito meno spesso di un sito statico comparabile, perché ogni scansione costa di più da elaborare.
2. I tuoi server e le tue API sopportano più carico se recuperi i dati lato client a ogni richiesta, bot compresi.

Nessuna delle due è fatale da sola. Su un sito grande si sommano e rallentano la velocità con cui le pagine nuove o aggiornate vengono scoperte e re-indicizzate. Per un approfondimento sul perché questo conta su un intero sito e su come l'efficienza della scansione si lega ai posizionamenti, leggi la nostra analisi sull'importanza della SEO tecnica.

Cosa significa per il tuo crawl budget

I siti con migliaia di URL renderizzati lato client sono quelli che hanno più probabilità di vedere pagine rimaste non indicizzate. Un sito di marketing da dieci pagine costruito come SPA verrà probabilmente renderizzato e indicizzato per intero, perché Google ha budget da spendere. Un catalogo e-commerce da 5.000 pagine costruito allo stesso modo è una scommessa molto più rischiosa, dato che l'arretrato di rendering si accumula.

Come risolvere la SEO delle SPA: confronto tra strategie di rendering

Questa è la parte che risolve davvero la SEO per le single page app. Tutte le soluzioni qui sotto condividono un'idea: mettere HTML vero e leggibile davanti al crawler alla prima richiesta, invece che dopo l'esecuzione del JavaScript.

Strategia di rendering	Cosa succede	Scansionabilità	Ideale per
Rendering lato client (CSR)	Il browser costruisce l'intera pagina dal JS dopo il caricamento	La più debole: il contenuto può sfuggire o arrivare in ritardo	Strumenti con accesso riservato, dashboard non pensate per posizionarsi
Rendering lato server (SSR)	Il server renderizza l'HTML completo a ogni richiesta, poi lo "idrata" con il JS	Solida: il crawler riceve subito l'HTML completo	Pagine con contenuti che cambiano spesso o personalizzati
Generazione di siti statici (SSG)	L'HTML viene pre-costruito al momento del deploy per ogni route	La più forte: HTML veloce e completo ogni volta	Blog, pagine di marketing, documentazione, contenuti che cambiano a intervalli programmati
Prerendering	Un browser headless renderizza la SPA una volta e serve HTML in cache ai crawler (o a tutti)	Solida: ripiego efficace per SPA già esistenti	Aggiungere la SEO a un'app che non puoi ricostruire del tutto
Ibrido / Incremental Static Regeneration	Mix di SSG, SSR e rendering on demand per ogni route	Solida e flessibile	Siti grandi con sezioni sia statiche sia dinamiche

Il rendering lato server come soluzione principale

L'SSR renderizza sul server i tuoi componenti React, Vue o Angular in HTML completo e lo invia al browser, che lo "idrata" trasformandolo in un'app interattiva. Il crawler riceve contenuto vero alla prima richiesta, senza un secondo passaggio di rendering. I framework costruiti attorno a questo schema, come Next.js per React, esistono per rendere SSR e generazione statica la scelta predefinita. Se usi o stai valutando Next.js, la nostra guida SEO per Next.js ti accompagna nella configurazione di metadati, sitemap e robots nell'ordine che conta.

Il prerendering come rimedio più rapido ed economico

Se una ricostruzione completa in SSR non è realistica adesso, il prerendering è il compromesso pratico. Un servizio renderizza la tua SPA una volta con un browser headless e mette in cache l'HTML statico. Serve quella versione ai crawler, e spesso a tutti i visitatori alla prima visita, mentre la versione JavaScript interattiva si carica per chi torna sul sito. È meno elegante del vero SSR, ma colma il divario di scansionabilità senza dover migrare framework.

Il progressive enhancement come rete di sicurezza

Il progressive enhancement significa costruire prima l'esperienza di base in modo che funzioni senza JavaScript, e poi aggiungere sopra l'interattività per i browser e i crawler che la supportano. Il feature detection, che verifica se una funzionalità esiste prima di farci affidamento, mantiene la pagina funzionante anche se uno script non si carica o se un crawler non lo esegue del tutto. Non sostituisce SSR o prerendering su un sito ricco di contenuti, ma è un'abitudine difensiva sensata per qualsiasi funzionalità che dipende da JavaScript.

Un esempio di migrazione passo passo da SPA a SSR

Le strategie di rendering in astratto non ti dicono quanto dura una migrazione né in che ordine si svolge il lavoro. Ecco come una tipica SPA di medie dimensioni, ad esempio una directory SaaS da 400 pagine costruita in React con routing lato client, passa a Next.js SSR senza una riscrittura completa.

Passo 1: verifica che cosa vede Google oggi (1-3 giorni). Estrai da Search Console, dal report Page Indexing, tutti gli URL indicizzati e confrontali con l'elenco reale delle tue route. Un sito con 400 viste reali potrebbe averne indicizzate solo 60 o 70, mentre le altre restano ferme su "Discovered, currently not indexed" o "Crawled, currently not indexed". Quel divario è il tuo punto di partenza.

Passo 2: configura Next.js accanto all'app esistente (1-2 settimane). Invece di riscrivere tutti i componenti in una volta, la maggior parte dei team usa Next.js come guscio attorno ai componenti React esistenti. Convertono le route in pagine Next.js (o segmenti dell'app router) un template alla volta, partendo dalle pagine con più traffico.

Passo 3: sposta il recupero dei dati in loader lato server (1-2 settimane, in parallelo al Passo 2). Qualsiasi chiamata useEffect che recupera i dati necessari al rendering di una pagina va spostata in una funzione lato server (getServerSideProps, un route handler o il fetch di un server component), così l'HTML arriva completo alla prima richiesta.

Passo 4: reindirizza i vecchi URL basati su hash o su query string (1-2 giorni). Ogni vecchio indirizzo del tipo #/product/42 ha bisogno di un 301 lato server verso il suo nuovo percorso pulito, /product/42. Saltare questo passaggio è il motivo più comune per cui le migrazioni perdono i posizionamenti esistenti invece di migliorarli, perché i vecchi URL scompaiono senza che nulla indichi ai motori di ricerca il sostituto.

Passo 5: reinvia la sitemap e richiedi l'indicizzazione degli URL prioritari (1 giorno, poi attesa). Invia a Search Console una sitemap XML nuova o aggiornata che elenchi ogni route pulita, subito dopo il rilascio di ogni gruppo di pagine. La documentazione stessa di Google Search Central osserva che reinviare una sitemap accelera la scoperta, ma non garantisce un rendering o un posizionamento più rapidi, perché la priorità di scansione dipende comunque dall'autorevolezza esistente del sito e dal suo crawl budget.

Passo 6: monitora la curva di indicizzazione per 4-8 settimane. I team che la seguono da vicino vedono in genere il numero di "Discovered, currently not indexed" calare con regolarità nell'arco di diverse settimane, man mano che Google ri-scansiona i template convertiti. Una pagina convertita nella prima settimana potrebbe mostrare il nuovo stato di indicizzazione solo alla terza o alla quarta.

Eseguire tutti e sei i passi template per template, anziché tentare una riscrittura unica e totale, evita che la migrazione faccia crollare i posizionamenti esistenti mentre il lavoro è in corso.

Una stima approssimativa dei costi: per un team già a suo agio con React, convertire una SPA di medie dimensioni (qualche centinaio di route) a Next.js SSR richiede in genere da quattro a otto settimane di lavoro ingegneristico concentrato, secondo i casi di studio sulle migrazioni pubblicati dal team di customer engineering di Vercel. La maggior parte di quel tempo va nel Passo 3 e non nel routing o nella configurazione, quindi pianifica di conseguenza invece di promettere agli stakeholder un'esecuzione in due settimane.

Errori comuni dei team durante la migrazione

Anche con la giusta strategia di rendering, una manciata di errori evitabili spiega la maggior parte delle migrazioni SPA arenate o fallite.

Dimenticare di reindirizzare i vecchi URL con hash. Ne abbiamo già parlato, ma è abbastanza comune da ripeterlo: se #/shoes/running non fa un 301 verso /shoes/running, i backlink e i posizionamenti che puntano al vecchio indirizzo finiscono in un vicolo cieco invece di passare al nuovo URL.

Fare SSR del guscio ma continuare a caricare in lazy loading il contenuto che conta. Una pagina può restituire HTML completo per header, footer e navigazione, mentre la descrizione del prodotto o il corpo dell'articolo si caricano ancora con un fetch lato client dopo l'idratazione. Per un crawler è appena meglio del problema originale, perché il contenuto che dovrebbe posizionarsi non è ancora nella risposta iniziale.

Rompere i canonical tag durante la transizione. La maggior parte delle migrazioni fa convivere per un po' i vecchi e i nuovi schemi di URL, e questo crea un rischio di contenuti duplicati se entrambi restano scansionabili senza un canonical tag che indichi quello che vuoi indicizzare. Decidi quale URL vince prima che vadano online entrambi.

Considerare la migrazione finita quando l'HTML sembra giusto in un browser. Vedere tu stesso la pagina renderizzata non conferma che cosa ha ricevuto Googlebot. Usa lo strumento URL Inspection di Search Console, oppure una richiesta HTTP con JavaScript disattivato, per vedere l'HTML effettivo della prima risposta invece del DOM dopo che il tuo browser ha eseguito tutto.

Sottovalutare quanto dura la re-indicizzazione su un sito grande. Una migrazione da dieci pagine può comparire per intero in Search Console nel giro di una settimana, mentre un catalogo da 5.000 pagine può impiegare da due a tre mesi a completare il ciclo, perché Google ri-scansiona e ri-renderizza le pagine a lotti. Pianificare l'annuncio di un lancio o una scadenza di reportistica su tempi più rapidi è una fonte comune di falsi allarmi quando i posizionamenti non si muovono nella prima settimana.

Dai a ogni vista il suo URL

Una pagina senza un URL proprio non può posizionarsi per niente, per quanto buono sia il contenuto. È l'errore strutturale più comune nella SEO delle SPA, ed è anche il più facile da correggere.

History API e routing basato su hash

Le SPA più vecchie usavano spesso il routing basato su hash, con URL come example.com/#/shoes/running, perché la parte dopo il # poteva cambiare senza provocare il ricaricamento completo della pagina. Il problema è che i motori di ricerca hanno storicamente trattato tutto ciò che segue un # come parte dello stesso documento.

La soluzione è la History API del browser, in particolare pushState() e replaceState(). Permettono al tuo JavaScript di aggiornare l'URL con un percorso pulito e reale, come example.com/shoes/running, senza un ricaricamento completo. I motori di ricerca, e gli utenti che salvano nei preferiti o condividono il link, ottengono un indirizzo distinto e scansionabile per quella precisa vista.

Una checklist per un routing utilizzabile dai motori di ricerca:

• Ogni contenuto distinto ha un proprio percorso reale invece di un frammento hash.
• Gli URL sono descrittivi e stabili: /shoes/running e non /view?id=4471.
• Ogni URL restituisce direttamente il contenuto corretto quando un utente o un bot lo carica da zero, senza dipendere dalla cronologia di navigazione lato client.
• Una sitemap XML fatta bene elenca tutte queste route, comprese quelle sotto la radice.
• I canonical tag puntano alla versione pulita dell'URL di ciascuna vista, così i percorsi con parametri e quelli puliti non inviano segnali in conflitto.

Metadati e dati strutturati che si aggiornano a ogni vista

Il più grande fallimento silenzioso di una single page app sono i metadati che non cambiano mai. Se il tuo tag <title> e la meta description sono scritti a mano nell'unico guscio HTML, ogni "pagina" della tua SPA condivide lo stesso titolo e la stessa descrizione nei risultati di ricerca, e per Google questo equivale a contenuto duplicato.

Titoli e descrizioni devono cambiare con la vista

Ogni route ha bisogno del proprio title tag e della propria meta description, aggiornati quando l'utente (o Googlebot) naviga verso quella vista. In pratica, gestisci i tag dell'head del documento attraverso il livello di routing del tuo framework, invece di impostarli una volta sola in un index.html statico. La nostra guida pratica alla SEO on-page spiega come scrivere titoli e descrizioni che ottengono clic una volta resi unici per pagina, e la panoramica della funzione SEO on-page mostra come appare questa verifica eseguita su un intero sito in una volta sola.

I metadati sono uno dei segnali più chiari che controlli direttamente, e un errore a livello di template si moltiplica su ogni vista della tua app. Per il ragionamento più ampio, leggi la reale importanza dei metadati per la SEO. Per sapere quali tag usano i motori di ricerca e quali ignorano in silenzio, leggi il nostro articolo sui meta tag SEO che Google usa davvero prima di costruire la logica dei template.

Open Graph e anteprime social

Lo stesso problema colpisce i tag Open Graph, che controllano l'aspetto di un link quando viene condiviso sui social o nelle app di messaggistica. Se quei tag sono statici, ogni link condiviso dalla tua SPA mostra lo stesso titolo, la stessa descrizione e la stessa immagine, qualunque prodotto o articolo qualcuno abbia condiviso. Aggiorna og:title, og:description e og:image per ogni route, nello stesso modo in cui aggiorni il title tag.

Anche i dati strutturati vanno trattati vista per vista

I dati strutturati JSON-LD, il markup che può far ottenere rich snippet come valutazioni a stelle, menu a tendina di FAQ o prezzi dei prodotti nei risultati di ricerca, vanno generati per ogni vista invece di essere iniettati una sola volta a livello globale. Una SPA con pagine prodotto, per esempio, ha bisogno di uno schema Product che rifletta prezzo e disponibilità di quel prodotto, e non di un unico blocco generico ripetuto ovunque.

Schema.org definisce il vocabolario per questo markup. Uno schema rotto o mancante fa perdere un'opportunità di visibilità che i tuoi concorrenti in solo HTML stanno già sfruttando. La nostra spiegazione del markup schema illustra che cosa fa ciascun tipo di schema per i posizionamenti, e lo strumento di audit del markup schema controlla il tuo JSON-LD e ti dà un markup corretto da incollare nei tuoi template.

Come evitare i soft 404 e altre trappole di indicizzazione

Un soft 404 si verifica quando una pagina restituisce un normale stato "200 OK", ma il suo contenuto appare a Google vuoto, rotto o simile a una pagina di errore. Le SPA sono particolarmente soggette a questo problema, perché una route che non riesce a caricare i propri dati può comunque renderizzare un guscio quasi vuoto. Google lo legge come una pagina difettosa anche se il tuo server non ha mai restituito un errore.

Trappole di indicizzazione tipiche delle SPA:

• Stati vuoti serviti con stato 200. Se un prodotto è esaurito o fuori catalogo, o una route non si risolve, servi un codice di stato corretto oppure un contenuto chiaro e scansionabile, invece di un div vuoto con uno stato di successo.
• Scorrimento infinito senza ripiego paginato. Se il contenuto compare solo dopo un evento JavaScript attivato dallo scorrimento, un crawler che non scorre potrebbe non vederlo mai. Sotto lo scorrimento, prevedi URL paginati reali che si colleghino tra loro.
• Redirect lato client invece che lato server. Un redirect gestito in JavaScript dopo il caricamento della pagina è più lento e meno affidabile per i crawler rispetto a un 301 HTTP dal server.
• Meta tag robots rimasti su noindex dall'ambiente di staging. Un tag <meta name="robots" content="noindex"> usato durante lo sviluppo può finire facilmente in produzione dentro un template condiviso.
• JavaScript o endpoint API bloccati in robots.txt. Se gli script o gli endpoint dei dati da cui dipende la tua SPA sono vietati alla scansione, Googlebot non riesce a renderizzare correttamente la pagina, anche quando ci prova.

La nostra guida alle correzioni di SEO tecnica che fanno davvero salire i posizionamenti spiega come cercare problemi come questi su un intero sito. Su una SPA conta più che su quasi qualsiasi altra architettura, perché un solo errore di template può colpire in silenzio tutte le route insieme.

I punti ciechi di tracciamento e analytics nelle SPA

Gli strumenti di analytics pensati per i siti tradizionali presumono che una nuova visualizzazione di pagina scatti ogni volta che il server invia un nuovo documento. Le SPA rompono questa ipotesi, perché navigare tra le viste non provoca nessun nuovo caricamento di pagina. Gestisce tutto il JavaScript, all'interno di un'unica sessione continua.

In pratica, senza una configurazione aggiuntiva il tuo strumento di analytics può registrare una sola visualizzazione di pagina per visita, a prescindere da quante pagine abbia sfogliato il visitatore. Questo sottostima gravemente il coinvolgimento e rende impossibile capire quali viste funzionano.

La soluzione è far scattare un evento di visualizzazione di pagina virtuale ogni volta che il router cambia l'URL, collegato all'aggiornamento della History API di cui abbiamo parlato prima. Le piattaforme di analytics moderne lo supportano tramite le impostazioni di misurazione avanzata e la configurazione del tag management, ma va impostato in modo deliberato. Quando routing e tracciamento scattano entrambi correttamente, il monitoraggio delle posizioni e i report sul traffico tra Google Analytics, Search Console e fonti di referral AI diventano significativi, perché i dati sulle visualizzazioni di pagina su cui poggiano sono accurati.

Un punto di partenza framework per framework

Tutti i principali framework per SPA hanno un percorso maturo per risolvere questi problemi SEO, anche se il punto di partenza cambia.

Framework	Opzione di rendering per la SEO	Per cosa è conosciuto
React (tramite Next.js)	SSR, generazione statica e rigenerazione incrementale integrati	La community più grande, la scelta più comune per ricostruire SPA pensando alla SEO
Vue (tramite Nuxt)	Rendering lato server e edge integrato nel framework	Leggero, popolare tra i team che vogliono l'SSR senza il peso di React
Angular (tramite Angular Universal)	Componente SSR ufficiale per le app Angular esistenti	Diffuso nelle app enterprise che aggiungono la SEO a un codebase esistente
Svelte (tramite SvelteKit)	SSR e generazione statica di default	Bundle più piccoli e adozione in crescita per i siti sensibili alle prestazioni

Lo schema è lo stesso per tutti. Se puoi scegliere, preferisci il livello di rendering ufficiale del framework a un servizio di prerendering separato. Richiede più lavoro all'inizio ed è meno fragile sul lungo periodo.

La tua checklist di audit SEO per la SPA

Prima di dare per scontato che la tua SPA abbia un problema SEO, o di dichiararlo risolto, scorri questa lista. Questa guida alla SEO per le single page app merita di essere salvata tra i preferiti come riferimento, perché la maggior parte dei team corregge questi punti per fasi.

1. Guarda la tua pagina con JavaScript disattivato. Se il contenuto sparisce, sparisce anche dalla prima visione che ne ha Google.
2. Controlla lo strumento URL Inspection di Google Search Console su una manciata di pagine chiave e confronta l'HTML renderizzato con quello che ti aspetti.
3. Verifica che ogni vista importante abbia un URL unico e scansionabile, senza frammento hash né identificatori presenti solo nella query string.
4. Verifica che titoli e meta description cambino per route e non si limitino alla home page.
5. Controlla che la tua sitemap XML elenchi ogni route indicizzabile e sia indicata correttamente in robots.txt.
6. Testa i tuoi dati strutturati per ogni template, seguendo le indicazioni Rich Results di Google, su più di una pagina di esempio.
7. Conferma che gli analytics facciano scattare una visualizzazione di pagina virtuale a ogni cambio di route, oltre che al caricamento iniziale.
8. Cerca i soft 404 nel report di indicizzazione di Search Console. Gli stati vuoti serviti con stato 200 sono la causa abituale.
9. Misura i Core Web Vitals. web.dev fissa le soglie attuali a circa 2,5 secondi per il Largest Contentful Paint, 200 millisecondi per l'Interaction to Next Paint e 0,1 per il Cumulative Layout Shift. Le SPA tendono a cavarsela bene qui una volta sistemato il rendering, dato che l'interattività di fondo è già veloce.

Eseguire questa checklist a mano su un sito grande è lento ed è facile mancare un template che riguarda centinaia di pagine. Un report SEO di esempio mostra come appare un passaggio automatico completo su scansionabilità, metadati e schema, senza il lavoro manuale sui fogli di calcolo.

Domande frequenti

Una single page app può posizionarsi su Google?

Sì. Google può scansionare e indicizzare i contenuti renderizzati con JavaScript, a patto che il contenuto compaia nell'HTML renderizzato, che ogni vista abbia un proprio URL e che i metadati si aggiornino a ogni vista. La versione che fatica a posizionarsi è la SPA con rendering lato client, senza modifiche e senza rendering lato server.

React è un problema per la SEO?

No, React in sé non è il problema. Un'app React semplice, con rendering lato client e senza rendering lato server, è più difficile da far indicizzare bene, e Next.js o un altro framework che supporti il rendering lato server o la generazione statica risolve la maggior parte dei problemi SEO che le persone associano a React.

Qual è la differenza tra SSR e prerendering per la SEO?

Il rendering lato server costruisce HTML nuovo a ogni richiesta, e gestisce bene i contenuti personalizzati o che cambiano di frequente. Il prerendering renderizza la pagina una sola volta in anticipo e serve una versione statica in cache. È più rapido da implementare, ma meno adatto ai contenuti che cambiano per visitatore o per richiesta.

Perché la mia SPA mostra una pagina vuota nella cache di Google o nello strumento URL Inspection?

Di solito significa che Googlebot non ha ancora renderizzato la pagina, oppure che il JavaScript non è stato eseguito correttamente durante il rendering. Spesso gli script o le chiamate API necessari erano bloccati, sono andati in timeout o dipendevano da qualcosa che non è disponibile nell'ambiente di rendering di Google. Controlla il tuo robots.txt per individuare risorse bloccate e testa la pagina live con URL Inspection in Search Console.

Le single page app hanno bisogno di URL separati per ogni pagina, o basta un URL?

URL separati. Un motore di ricerca può indicizzare e posizionare solo un singolo URL, quindi se l'intera SPA vive a un solo indirizzo, Google ha una sola voce con cui lavorare, per quanto contenuto si nasconda dietro la navigazione lato client. Usa la History API per dare a ogni vista significativa un proprio percorso reale e scansionabile.

Metti a posto la SEO della tua SPA nell'ordine giusto

Sistemare la SEO per le single page app richiede di solito diversi interventi: rendering, routing, metadati e schema, affrontati in quest'ordine sui template che toccano il maggior numero di pagine. Parti dalla vista che sposterebbe più traffico se iniziasse a posizionarsi domani, poi allarga il lavoro. Se vuoi un elenco di priorità su che cosa correggere per primo sul tuo sito, parla con il team e fatti preparare un report SEO di esempio costruito sulle tue pagine reali.

Risorse / Riferimenti

1. Google Search Central
2. web.dev

Letture correlate: SEO per JavaScript: perché le tue pagine diventano invisibili a Google.

Fonti

• What is a Single Page Application? SPA vs MPA 2025
• How single page applications work and when to use them
• How do you optimize a large SPA (single page application) ...
• When to consider Single Page Applications?

Avvertenza: questo articolo contiene informazioni generali sulla salute e non costituisce un parere medico personalizzato. Non può tenere conto della tua storia clinica, dei farmaci che assumi o dei riscontri di una visita. Per un consiglio sui tuoi sintomi, rivolgiti a un medico qualificato; se i sintomi sono gravi o peggiorano, cerca assistenza urgente.