Il sito funzionava, ma Google vedeva quasi nulla: cosa ho imparato sulla SEO di una SPA
Un caso reale tra rendering client-side, robots.txt, crawling e diagnosi tecnica.
Un sito può essere perfettamente funzionante per un utente e, allo stesso tempo, offrire pochissimo contenuto utile a un crawler. È una delle situazioni più ingannevoli della SEO tecnica moderna, soprattutto quando frontend e backend sono separati logicamente e il contenuto viene renderizzato nel browser.
Il sintomo: tutto sembra a posto
Il sito risponde, le pagine si aprono, gli articoli esistono, i meta tag sono presenti e la sitemap contiene gli URL. A prima vista, non c'è nulla che faccia pensare a un problema grave.
Eppure il traffico organico resta quasi fermo. È qui che conviene smettere di guardare solo ciò che vede il browser e controllare invece ciò che riceve davvero il crawler al primo caricamento.
CSR: la pagina esiste, ma il contenuto arriva dopo
Con il rendering client-side, il server può restituire un documento HTML molto leggero. Il contenuto vero viene costruito solo quando JavaScript viene scaricato ed eseguito.
Per l'utente non è necessariamente un problema. Per un crawler, invece, significa dipendere dalla fase di rendering JavaScript. Se qualcosa impedisce quella fase, la pagina diventa di fatto quasi vuota.
Il dettaglio che può sabotare tutto: robots.txt
Nel mio caso, il punto critico era il rapporto tra il file robots.txt e gli asset del frontend. Se il crawler deve eseguire JavaScript per vedere il contenuto, bloccare la directory che contiene quei bundle è una contraddizione architetturale.
Il crawler riceve l'HTML, ma non può caricare il codice necessario per completare la pagina. Il risultato è semplice: l'applicazione funziona per l'utente, ma il motore di ricerca può interpretarla come una pagina povera o incompleta.
La prima correzione non richiede SSR
Prima di introdurre una soluzione più complessa, conviene correggere il problema più semplice: consentire ai crawler di scaricare gli asset necessari al rendering.
La lezione importante è che noindex e Disallow non sono la stessa cosa. Un asset JavaScript può non essere indicizzato come risultato di ricerca e restare comunque scaricabile dal crawler per renderizzare la pagina.
Proteggere la correzione con un test
Una modifica di una sola riga in robots.txt è facile da fare e altrettanto facile da perdere in futuro. Per questo ho aggiunto un test automatico che verifica due condizioni:
- gli asset pubblici necessari al rendering restano accessibili ai crawler;
- le aree che devono restare escluse continuano a esserlo.
Questo trasforma una correzione SEO in un requisito verificabile dal codice.
Perché non basta dire “Google esegue JavaScript”
È vero che i motori moderni possono renderizzare JavaScript. Ma questo non significa che affidarsi completamente al rendering client-side sia sempre la scelta migliore.
Ci sono più passaggi, più punti di errore e più dipendenze: download del bundle, esecuzione, eventuali chiamate successive, gestione del tempo di rendering. Inoltre non tutti i crawler, strumenti di anteprima e sistemi automatici hanno le stesse capacità.
La diagnosi viene prima della tecnologia
La cosa più utile di questa esperienza non è stata “aggiungere SSR”, ma capire la sequenza corretta:
- verificare cosa riceve realmente un crawler;
- controllare che gli asset necessari siano accessibili;
- testare sitemap e URL pubblici;
- solo dopo valutare se il rendering lato server porta un vantaggio concreto.
Conclusione
La SEO tecnica non è una lista di meta tag da spuntare. È il risultato del modo in cui l'applicazione viene realmente servita, renderizzata e scoperta.
Quando una SPA ha poco traffico organico, la domanda non dovrebbe essere soltanto “ho impostato title e description?”, ma anche: che cosa riceve un crawler prima che il browser faccia il resto?