HTML pronto alla prima richiesta
Con SSR il server prepara l'HTML prima che il browser lo mostri. Il crawler riceve così una pagina già leggibile, mentre CSR rimanda il contenuto all'esecuzione JavaScript e SSG lo prepara in anticipo al build.
SEO tecnica
Server Side Rendering per SEO: perché il rendering lato server conta per Google
La differenza tra SSR, CSR e SSG non è solo tecnica: influenza come Googlebot legge il tuo sito, quanta latenza aggiunge al rendering, e i tuoi Core Web Vitals. Questa guida spiega quale rendering scegliere, come verificare come Google vede le tue pagine, e quando investire in architetture ibride.
A cura di ContatPubblicato il 11 min di lettura
SSR, CSR, SSG: cosa sono davvero
Il rendering è il processo di convertire il codice (HTML, JavaScript, CSS) in una pagina visibile nel browser. Esistono tre approcci principali, ognuno con trade-off diversi per SEO.
Client-Side Rendering (CSR)
Il server invia al browser un file HTML minimale, quasi vuoto. Il browser scarica JavaScript (di solito pesante: 100-500 KB), lo esegue, e solo allora il contenuto appare. Esempio: applicazioni React pure, SPA (Single Page Applications).
Pro: Interattività immediata dopo il caricamento, facile aggiornare il contenuto senza reload di pagina.
Contro: Il server HTML non contiene contenuto, quindi i crawler vedono inizialmente una pagina vuota. Anche Googlebot, che esegue JavaScript, impiega 5-10 secondi extra per ogni pagina. Questo rallenta la indicizzazione e aumenta il carico sui server di Google.
Server-Side Rendering (SSR)
Il server esegue il JavaScript e genera l'HTML completo prima di mandarlo al browser. Il browser riceve una pagina già renderizzata, pronta da visualizzare. Esempio: Next.js con renderizzazione lato server, Nuxt in SSR mode, PHP/Laravel tradizionali.
Pro: L'HTML contiene tutto il contenuto: Googlebot lo vede subito, senza aspettare JavaScript. La pagina è visibile velocemente (First Contentful Paint basso). Ottimo per SEO.
Contro: Il server deve eseguire JavaScript per ogni richiesta. Con 1 milione di visitatori, servono server potenti. Latenza maggiore rispetto a HTML statico.
Static Site Generation (SSG)
Il contenuto viene generato una volta (durante il build) e salvato come file HTML statici. Ogni volta che qualcuno richiede la pagina, il server restituisce l'HTML pre-renderizzato. Esempio: blog con Hugo, Nuxt in SSG mode, Next.js con Static Generation.
Pro: Velocità massima: nessun rendering a runtime, solo file statici serviti da CDN. Costo inferiore e scalabilità infinita.
Contro: Se il contenuto cambia ogni minuto (e-commerce con inventario dinamico, notizie in tempo reale), devi rigenerare tutto il sito. Non adatto per dati dinamici.
Rendering Ibrido
Combinazione di SSG + SSR (Incremental Static Regeneration in Next.js) o SSR + CSR (hydration). Generi in statico le pagine più importanti, le altre in SSR al primo accesso, e le meno critiche rimangono CSR. È l'approccio moderno consigliato.
Come Googlebot esegue il rendering
Google non legge il tuo sito come un browser umano. Googlebot ha un processo complesso di indicizzazione che include il rendering JavaScript, ma non è istantaneo.
Fase 1: Fetch (0-30 minuti) - Googlebot scarica il file HTML.
Fase 2: Render (ore o giorni dopo) - Googlebot esegue il JavaScript in una "rendering queue". Se il sito è lento o c'è troppo JS, Google attende. Se il sito è veloce e ben strutturato, processa in poche ore.
Se usi CSR puro:
- Fase 1 vede un HTML vuoto.
- Fase 2 deve eseguire tutto il JavaScript.
- Se il rendering impiega 30 secondi (browser lenti, server overloaded), Google potrebbe dare un timeout e indicizzare la versione vuota.
Verdict: Con CSR, c'è un rischio di indicizzazione incompleta, specialmente per siti lenti.
Se usi SSR:
- Fase 1 vede subito l'HTML completo con il contenuto.
- Fase 2 esegue comunque il JavaScript per verificare comportamento dinamico, ma il contenuto è già indicizzato.
- Anche se il rendering fallisce, il contenuto è già nel primo HTML.
Verdict: SSR è il metodo più affidabile per garantire indicizzazione completa.
Chiarimento importante: Google non legge il JavaScript "male". Legge e esegue una versione moderna di Chromium. Il problema non è che Google non capisce JS, ma che il rendering JavaScript è costoso per Google (server, power, tempo). Riducendo la dipendenza da JS a runtime, aiuti Google (e gli utenti).
Impatto sulla indicizzazione e il ranking
L'architettura di rendering influenza direttamente quanto velocemente Google indicizza il tuo sito e quanto bene lo classifica.
Crawl Efficiency (efficienza del crawl)
Se usi CSR, Google vede prima l'HTML vuoto e deve aspettare il rendering prima di capire il contenuto reale. Questo significa che per lo stesso budget crawl, Google indicizza meno pagine su un sito CSR rispetto a SSR. Se hai 10.000 pagine e un budget crawl di 500 pagine/giorno, con CSR Google brucerà il budget in fetching HTML vuoti e aspettando il rendering, mentre con SSR processa il contenuto direttamente.
Time to First Index
Un sito SSR si indicizza più velocemente perché Google non deve aspettare il rendering JavaScript. Pagine nuove in SSR vengono indicizzate in 24-48 ore; in CSR puro, possono impiegare giorni perché Google deve schedulare il rendering.
Ranking Signal
Direttamente? Rendering non è un fattore di ranking. Google non penalizza CSR o premia SSR per scelta architetturale.
Indirettamente? Sì. Perché:
- Core Web Vitals: SSR solitamente ha LCP migliore (Largest Contentful Paint), perché il contenuto è nell'HTML iniziale, non caricato via JavaScript. Google considera Core Web Vitals nel ranking.
- Crawl Efficiency: Se il rendering lento ti permette di indexare solo 500 pagine invece di 5000, il tuo sito è meno visibile. Più pagine indexate = più opportunità di ranking.
- Mobile Performance: CSR su 3G lento è penalizzato. SSR è più veloce in condizioni di rete scarsa.
Metadata in HTML
Con SSR, i meta tag (og:title, og:image, description) sono nell'HTML iniziale. Con CSR dinamico, se sono aggiunti via JavaScript, Google potrebbe perderli se il rendering fallisce o viene interrotto. Per social sharing e SEO, SSR è più affidabile.
Rendering e Core Web Vitals
I Core Web Vitals (LCP, FID/INP, CLS) sono fattori di ranking di Google. La scelta di rendering influenza direttamente questi metriche.
LCP (Largest Contentful Paint) < 2.5s
SSR: L'elemento più grande (solitamente un'immagine o un contenitore di testo) è direttamente nell'HTML. Il browser lo vede subito, senza aspettare JavaScript. LCP è basso di default (1-1.5s).
CSR: L'elemento più grande è caricato via JavaScript. Tempo totale: fetch HTML → parse HTML → fetch JS → parse/execute JS → rendering elemento = 3-5 secondi. LCP è alto.
FID/INP (Interaction to Next Paint) < 100ms
SSR: La pagina è interattiva subito. JavaScript è già eseguito. Primo click risponde rapidamente.
CSR: Mentre il JavaScript grande si sta ancora caricando, il primo click rimane in attesa. INP è alto durante l'idratazione.
CLS (Cumulative Layout Shift) < 0.1
Indipendente da rendering, ma più semplice da gestire in SSR dove il layout è fisso nell'HTML. In CSR dinamico, i cambiamenti layout durante l'idratazione causano shift.
Implicazione pratica
Un sito SSR ben ottimizzato avrà Core Web Vitals migliori di uno CSR, e quindi ranking migliore in Google. Questo è il legame diretto tra architettura e SEO.
Quale architettura scegliere: SSR, CSR o ibrido
Non esiste una scelta universale. Dipende dal tuo caso d'uso.
Scegli SSR se:
- Il sito è pubblico e orientato alla SEO (blog, e-commerce, portale informativo).
- Il contenuto cambia raramente (notizie aggiornate poche volte al giorno).
- Vuoi tempi di indicizzazione veloci.
- La user base è su mobile con rete variabile.
- Hai budget per server di produzione.
Framework consigliati: Next.js (React), Nuxt (Vue), SvelteKit.
Scegli CSR se:
- Il sito è privato dietro login (app web, admin panel).
- Puoi sacrificare SEO per interattività (non hai bisogno di ranking).
- Il contenuto è altamente dinamico (dashboard in tempo reale, editor collaborativi).
- Vuoi ridurre il carico server.
Scegli SSG se:
- Il contenuto è statico (blog personale, documentazione, portafoglio).
- Vuoi massima velocità e costo minimo.
- Puoi fare rebuild frequenti (Netlify, Vercel supportano rebuild automatici).
Scegli Ibrido se:
- Hai pagine critiche per SEO (homepage, category pages) renderizzate staticamente.
- Pagine meno critiche in SSR.
- Sezioni private rimangono CSR.
- È il compromesso moderno consigliato dai framework.
Trend 2026: La maggior parte dei siti moderni opta per ibrido: SSG per pagine pubbliche statiche, SSR per quelle dinamiche, CSR per UI interattiva.
Come verificare come Google vede il tuo sito
Non puoi indovinare come Google indicizza il tuo sito. Devi verificare.
Google Search Console: URL Inspection Tool
Accedi a Google Search Console, inserisci un URL del tuo sito, clicca "Inspect." Google mostra:
- Indexed Version (versione indicizzata): Quale HTML ha indicizzato Google. Se vedi il contenuto qui, Google l'ha visto.
- Live URL Test (test live): Cosa vede Google adesso se crawla la pagina. Se il contenuto non appare, hai un problema rendering.
Come leggerlo: Se l'HTML indicizzato contiene il tuo
, i tuoi paragrafi, i tuoi link interni, allora Google l'ha indicizzato correttamente. Se vedi solo HTML vuoto o parziale, hai un problema di rendering o CSR non gestito bene.
Google Search Console: Core Web Vitals Report
Mostra i tuoi Core Web Vitals attuali e storici. Se sono rossi (cattivi), è spesso una conseguenza di scelte di rendering. Clicca sui singoli URL cattivi e vedi il pattern: mobile? pagine CSR-heavy? Immagini non ottimizzate?
Chrome DevTools: Network Tab
Apri il sito da DevTools (F12), vai a Network, ricarica. Osserva:
- Il file HTML iniziale è grande (200+ KB) = probabilmente SSR con contenuto completo.
- Il file HTML è piccolo (< 30 KB) e poi scarica file JS grandi (500 KB+) = probabilmente CSR. In questo caso, attendi il caricamento JS e verifica che il contenuto appaia.
Lighthouse Test
Accedi a PageSpeed Insights (https://pagespeed.web.dev), inserisci il tuo URL. Lighthouse esegue il rendering come Googlebot e mostra:
- LCP, FID, CLS: I tuoi Core Web Vitals effettivi.
- Performance Score: Valutazione complessiva. Se è sotto 75, hai problemi di rendering/caricamento.
- Cumulative Layout Shift dettagli: Quali elementi si stanno spostando? Spesso è dovuto a caricamento asincrono di JS.
Implementazione pratica: checklist SEO rendering
Non basta sapere la teoria. Ecco una checklist pratica per verificare e ottimizzare il rendering del tuo sito per SEO.
Checklist: Verifica Rendering SEO-Friendly
- [ ] HTML iniziale contiene H1 e paragrafi? Apri il source della pagina (Ctrl+U), cerca la tua H1. Se è nell'HTML, sei in SSR o SSG. Se non c'è, sei in CSR e devi verificare che JavaScript lo aggiunga.
- [ ] Meta tag sono nell'HTML iniziale? og:title, og:image, description devono essere nel prima di JavaScript. Se sono aggiunti via JS, Google potrebbe perderli.
- [ ] Canonical tag è presente? . Se usi SSR con URL dinamici, verifica che canonical punti all'URL corretto.
- [ ] LCP è sotto 2.5 secondi? Testa con PageSpeed Insights. Se LCP > 3s, il tuo rendering è troppo lento.
- [ ] INP è sotto 200ms? Click sulla pagina: quanto impiega a rispondere? Se hai lag, è spesso JavaScript pesante.
- [ ] CLS è sotto 0.1? Osserva lo schermo mentre la pagina carica. Elementi si muovono? Se sì, fisssa le dimensioni delle immagini e pre-alloca spazio.
- [ ] JavaScript essenziale è inline, non asincrono? Script fondamentali (hydration, tracking) devono essere caricati presto. Script di terze parti (ads, analytics) devono essere lazy o async.
- [ ] Sitemap XML è aggiornata? Includi tutte le pagine rilevanti. Se usi SSG, regenera la sitemap dopo il build.
- [ ] Robots.txt non blocca il rendering? Verifica che robots.txt non blocchi l'accesso ai tuoi file CSS e JS. Se Googlebot non può caricare le dipendenze, non può renderizzare.
- [ ] Test with URL Inspection in GSC: Per almeno 5 URL rappresentativi, apri Google Search Console, usa URL Inspection, e verifica che la versione live mostri il contenuto corretto.
- [ ] Core Web Vitals sono verdi? Accedi a Google Search Console, vai a Core Web Vitals report. Se hai URL "Poor" (rossi), investigali: sono pagine CSR? Immagini non ottimizzate? Script bloccanti?
- [ ] Tempo di indicizzazione è ragionevole? Pubblica una nuova pagina. Aspetta 24 ore. Se non è indexata, controlla se il rendering è la causa (via URL Inspection).
Ciclo di revisione: Ripeti questa checklist ogni mese o dopo cambiamenti architetturali.
SSR non è una scelta di rendering, è una scelta di velocità. Quando Googlebot non deve aspettare JavaScript, indicizza più velocemente, i tuoi Core Web Vitals migliorano, e il ranking segue.
FAQ
Domande su server side rendering e SEO
SSR genera l'HTML server-side. Hydration è il processo di attaccare JavaScript interattivo a quell'HTML nel browser. Tutti i framework moderni usano SSR + hydration.
Sì, è il rendering ibrido. Homepage e category pages in SSR, area utente (account) in CSR. Ottimale per costi e SEO.
No. Cambio migliora i Core Web Vitals e la indicizzazione, ma il ranking dipende dai contenuti, backlink, e altri fattori. Miglioria è indiretta, non immediata.
Entrambi sono excellenti per SEO. Next.js (React) ha comunità più grande, Nuxt (Vue) è leggermente più snello. La scelta dipende dalle tue preferenze, non dal SEO.
Articoli correlati
Approfondisci gli argomenti di questo articolo:
Ottimizza il rendering del tuo sito per SEO
Rendering architetture, Core Web Vitals, indexazione veloce: ti aiutiamo a scegliere e implementare il setup corretto per il tuo sito.