SSR vs CSR per la SEO: cosa vede Google e come testare l’HTML renderizzato
Search Toolbox
SEO / GEO Editorial
SSR contro CSR viene spesso presentato come una gara tra framework. Per la SEO conta una domanda più concreta: quali informazioni importanti sono già nella prima risposta HTML, quali compaiono solo dopo JavaScript e cosa succede se quel secondo passaggio è lento, bloccato o rotto?
SSR vs CSR vs SSG: confronto pratico
| Modalità | Cosa arriva prima | Adatto spesso a |
|---|---|---|
| SSR | HTML per richiesta | Pagine pubbliche dinamiche e contenuti personalizzati indicizzabili |
| SSG | HTML generato in anticipo | Articoli, documentazione, landing stabili |
| CSR | Il browser costruisce la pagina | App, dashboard, stati privati e molto interattivi |
| Ibrido | Base server/statica + isole idratate | La maggior parte dei siti content ed ecommerce moderni |
SSR, CSR, SSG e ibrido senza zuppa di sigle
Con il server-side rendering il server genera l’HTML a ogni richiesta. Con il client-side rendering il browser riceve un guscio HTML e JavaScript, recupera i dati e costruisce la pagina. La generazione statica prepara l’HTML in anticipo. I framework ibridi combinano questi approcci per rotta o componente.
L’idratazione rende interattivo nel browser l’HTML generato dal server. Una pagina può quindi fornire HTML completo e poi comportarsi come un’app moderna. SSR non significa “senza JavaScript”.
Cosa fa davvero Google con JavaScript
Google descrive tre fasi principali: scansione, rendering e indicizzazione. Prima elabora la risposta HTTP e l’HTML disponibile, poi esegue il rendering con Chromium e analizza di nuovo l’HTML renderizzato. Il contenuto client può quindi essere visto, ma deve superare una catena di dipendenze in più.
La conclusione corretta non è “Google non legge JavaScript”, ma: i contenuti importanti non dovrebbero sparire se falliscono API, bundle, consenso, lazy loading, interazione o runtime. Google consiglia SSR, rendering statico o idratazione invece del dynamic rendering come soluzione permanente.
- JavaScript o pagine bloccate non possono essere renderizzati.
- I link devono restare veri <a href>, non semplici stati al clic.
- I contenuti importanti in lazy loading non devono richiedere scroll o clic.
Dove CSR crea un rischio SEO misurabile
La modalità di rendering non è un fattore di ranking in sé. Conta il risultato. CSR diventa rischioso con una risposta iniziale quasi vuota, molte dipendenze o segnali contraddittori tra sorgente e DOM live.
Controlla contenuto principale, H1, link scansionabili, title, description, robots, canonical, hreflang, dati strutturati, disponibilità, paginazione e contenuti dietro accordion o consenso. Una pagina bella dopo il caricamento non prova che ogni crawler abbia ricevuto lo stesso documento utile.
Come scegliere: proteggi il percorso critico, non l’identità del framework
Per landing, articoli, categorie e prodotti pubblici, SSR o SSG è in genere la base più sicura. CSR resta ottimo per dashboard, filtri, aree autenticate, calcolatori e interazioni senza URL indicizzabile.
Di solito non serve riscrivere tutto. Renderizza lato server shell, meta, contenuto principale, navigazione e canonical; idrata poi le parti interattive. Meno manifesto, più utilità in produzione.
Una diagnosi che non si ferma a “visualizza sorgente”
Il sorgente mostra la risposta del server, il DOM renderizzato lo stato dopo JavaScript e la vista senza JS ciò che resta senza esecuzione client. Servono tutte e tre.
Non allarmarti per il 41% di righe diverse. Un widget di consenso crea molto rumore, mentre un solo link interno mancante può contare di più. Cerca nel diff contenuti e direttive importanti e verifica gli URL di tua proprietà con Controllo URL in Search Console.
Search Toolbox · Render Inspector
Mini guida: testare SSR vs CSR su una pagina reale
Apri in Chrome la pagina da testare. Search Toolbox lavora nel contesto reale: produzione, staging, localhost o pagine autenticate.
- 1Apri Render nella sezione Tecnica.
- 2Clicca Rianalizza dopo il caricamento.
- 3Apri l’analisi completa per il diff.
Search Toolbox · live panels
Leggi le prove, non solo la percentuale
La prima vista riassume DOM, no-JS, sorgente e gap analysis. L’ispettore completo permette di cercare su entrambi i lati e isolare meta, link, Schema e script.
Scorri · tocca per zoomare
Cosa verificare prima del rilascio
- Contenuto principale e H1 esistono nel DOM renderizzato senza clic o scroll.
- Title, description, robots, canonical e hreflang non contraddicono il sorgente.
- I link interni usano href scansionabili e le viste importanti hanno URL distinti.
- I dati strutturati descrivono la pagina visibile e non vengono duplicati dopo l’idratazione.
- API in errore, bundle bloccati o consenso non cancellano i contenuti critici per la ricerca.
Confronta HTML sorgente e DOM sulla pagina che stai analizzando
Gli strumenti Render sono inclusi in Search Toolbox. Nessun crawler separato o URL demo.
Installa Search Toolbox — GratisRimani aggiornato
Ricevi le prossime guide SEO JavaScript
Niente fan club dei framework. Solo controlli riproducibili.
FAQ e ricerche correlate
Domande frequenti
Il client-side rendering è negativo per la SEO?
No. CSR diventa rischioso quando contenuti o direttive importanti dipendono da JavaScript lento, bloccato o in errore. Un HTML renderizzato completo, stabile e scansionabile può essere indicizzato.
Google esegue JavaScript?
Sì. Google usa un renderer Chromium recente, ma scansione, rendering e indicizzazione restano fasi separate. Altri crawler potrebbero non eseguire JavaScript.
Qual è la differenza tra SSR e SSG?
SSR genera HTML alla richiesta; SSG durante build o revalidazione. Entrambi possono fornire subito HTML utile; la scelta dipende da freschezza, scala, personalizzazione e cache.
L’idratazione può creare problemi SEO?
Non di per sé. I problemi iniziano se rimuove contenuto server, cambia canonical o robots, duplica Schema o fallisce prima di rendere disponibili link e testi importanti.
Quale percentuale di contenuto dipendente da JavaScript è eccessiva?
Non esiste una soglia universale e non è un punteggio di ranking. Conta ciò che manca: pochi link prodotto possono valere più di migliaia di righe di interfaccia.
Search Toolbox sostituisce Controllo URL di Search Console?
No. Search Toolbox fornisce prove rapide dalla pagina attiva, anche su staging e localhost. Controllo URL resta il riferimento per vedere come Google ha elaborato un URL di tua proprietà.
Imparare SEO / GEO facilmente
Analizzare una pagina, scheda dopo scheda.
Un percorso guidato dalla prima osservazione al nuovo test. Apri il metodo oppure lo strumento per controllare subito la pagina.
- Passaggio 01
Aprire la pagina e definire la base
Parti dall’URL live e registra URL finale, stato HTTP e indicizzabilità.
- Passaggio 02
Controllare Overview, meta e canonical
Risolvi prima noindex, title, description, robots e conflitti canonical.
- Passaggio 03
Analizzare heading, link e immagini
Controlla gerarchia, anchor interni ed errori immagine ripetuti nel template.
- Passaggio 04
Validare schema e relazioni tra entità
Controlla grafo JSON-LD renderizzato, proprietà ed entità in conflitto.
- Passaggio 05
Verificare hreflang e URL localizzati
Controlla reciprocità, codici lingua, canonical e status HTTP del cluster.
- Passaggio 06
Tracciare redirect e varianti URL
Segui ogni passaggio e conferma che l’URL finale sia indicizzabile e auto-canonical.
- Passaggio 07Sei qui
Capire SSR, CSR e il rischio di rendering
Capisci cosa invia il server, cosa aggiunge JavaScript e quali differenze meritano un controllo.
- Passaggio 08
Analizzare sorgente e DOM renderizzato se serve
Usa questo controllo più profondo solo quando un pannello semplice mostra una contraddizione legata a JavaScript.
- Passaggio 09
Dare priorità, esportare, correggere e ripetere
Trasforma le prove in un piano, cambia una cosa e ripeti gli stessi controlli.
Da applicare al tuo sito
Guida letta. Ora scegli il caso reale.
Questi percorsi applicano il metodo ai problemi reali del CMS e indicano quale pagina e quale scheda di Search Toolbox controllare.
Audit SEO Next.js e React: sorgente, rendering e hydration
Il primo caricamento può essere corretto mentre la navigazione client lascia title, canonical o schema obsoleti.
Apri il percorsoVerificatore HTML renderizzato per JavaScript SEO
Una pagina può sembrare completa mentre link o meta critici mancano nell’HTML iniziale.
Apri il percorsoUsi un altro CMS o cerchi un controllo preciso?
La directory riunisce casi d’uso, strumenti gratuiti e guide diagnostiche.