Server-side rendering e SEO

I tuoi contenuti possono essere eccellenti, ma se un crawler riceve una shell HTML vuota e un bundle JavaScript, non valgono nulla. La strategia di rendering — dove e quando viene costruito l'HTML — decide silenziosamente se Google vede una pagina completa o un palcoscenico vuoto. Per qualsiasi prodotto che dipende dal traffico organico, questa è la decisione SEO che viene prima delle keyword, dei link o dei contenuti. Si può fare tutto il resto nel modo giusto e rimanere comunque invisibili, se il crawler non vede mai le tue parole.

Le tre strategie di rendering

• CSR (client-side rendering): il server invia un file HTML quasi vuoto più un bundle JavaScript. Il browser scarica, analizza ed esegue quel JavaScript, che a quel punto costruisce la pagina. Rapido da sviluppare e poco costoso da ospitare, ma l'HTML iniziale — quello che un crawler legge per primo — è essenzialmente vuoto.
• SSR (server-side rendering): il server esegue il codice dell'applicazione e genera l'HTML completo per ogni richiesta, inviandolo già pronto per la visualizzazione. Il browser lo mostra immediatamente, quindi lo "idrata", collegando JavaScript per renderlo interattivo.
• SSG (static site generation): le pagine vengono renderizzate in HTML una sola volta, al momento della build, e servite come file statici da una CDN. La più veloce in assoluto e praticamente inattaccabile da servire, ma i contenuti rimangono bloccati fino alla build e al redeploy successivi.

La distinzione che conta per la SEO è semplice: SSR e SSG consegnano entrambi ai crawler HTML completo alla prima richiesta. Il CSR no. Con il CSR, i contenuti significativi esistono solo dopo l'esecuzione di JavaScript, e se ciò avvenga in modo affidabile — per ogni crawler, su ogni pagina — è fuori dal tuo controllo. Questo singolo fatto è all'origine di tutti i problemi descritti di seguito. Tutto il resto di questo articolo ne è una conseguenza.

Perché il CSR penalizza la SEO in pratica

Google può eseguire JavaScript, quindi molti danno per scontato che il CSR vada bene. In realtà è fragile, e la fragilità è il problema centrale. L'indicizzazione di Google avviene in due fasi: prima esegue la scansione dell'HTML grezzo, poi mette in coda la pagina per un secondo rendering pass differito, in cui JavaScript viene effettivamente eseguito. Questo secondo passaggio può subire ritardi di giorni quando il crawl budget è limitato, e se i tuoi contenuti esistono solo dopo l'esecuzione di JS, non vengono indicizzati finché — e a meno che — quel passaggio non venga completato.

E Google è il crawler nel migliore dei casi. L'ecosistema più ampio è più problematico: molti bot per i preview social (quelli che generano la card quando si condivide un link), diversi crawler AI e Bing in varie configurazioni gestiscono JavaScript in modo approssimativo o per nulla. Vedono la shell vuota e passano oltre.

Questa fragilità si manifesta in sintomi concreti che incidono sui ricavi:

• Indicizzazione ritardata o incoerente delle nuove pagine: si pubblica, e per settimane non appare nulla in ricerca
• Preview social mancanti o rotte quando i link vengono condivisi, con un calo del click-through
• Meta tag, URL canonici e dati strutturati che non vengono mai letti perché iniettati da JavaScript
• Contenuti che finiscono silenziosamente sotto i competitor con server rendering, che hanno offerto al crawler un lavoro più semplice

Quando il tuo posizionamento — e il traffico che genera fatturato — dipende da ciò, "di solito funziona" non è una strategia. È proprio per questo che privilegiamo i framework con server rendering di prima classe; fa parte del ragionamento in Next.js vs React e in come scegliere uno stack tecnologico.

Scegliere tra SSR e SSG

Entrambi sono SEO-friendly: il crawler riceve HTML reale in entrambi i casi. La scelta dipende dalla frequenza con cui i contenuti cambiano e dal fatto che siano personalizzati:

1. SSG per i contenuti stabili tra una deploy e l'altra: pagine marketing, landing page, documentazione, la maggior parte dei post del blog (come questo). È il più veloce e il meno costoso da servire, scala all'infinito da una CDN e ha una superficie d'attacco quasi nulla.
2. SSR per i contenuti personalizzati o in continuo cambiamento: pagine prodotto con disponibilità e prezzi in tempo reale, risultati di ricerca e filtri, qualsiasi contenuto specifico per l'utente con un URL pubblico. Si paga un render lato server per ogni richiesta, ma i contenuti sono sempre aggiornati.
3. ISR (incremental static regeneration), offerto da framework come Next.js, unisce i due approcci: serve HTML statico veloce, ma rigenera le singole pagine in background secondo uno schedule o su richiesta quando i dati cambiano. È il punto di equilibrio ideale per i grandi siti di contenuti e i cataloghi e-commerce: migliaia di pagine che si aggiornano periodicamente ma non richiedono un render per ogni richiesta.

Non è necessario scegliere un'unica strategia per l'intero sito. Il setup migliore di solito mescola tutte e tre, scelto per route: pagine marketing statiche, ISR per il catalogo prodotti, SSR per la ricerca.

Non si tratta solo dei crawler

Il server rendering migliora anche le metriche percepite dagli utenti reali, e che Google ora misura direttamente. Un HTML che arriva già pronto per la visualizzazione produce un Largest Contentful Paint più veloce e un layout shift decisamente inferiore rispetto a una pagina assemblata da zero nel browser dopo il download di JavaScript. Gli utenti su telefoni lenti e reti instabili — una quota significativa del web — lo avvertono maggiormente, e sono proprio quelli più propensi ad abbandonare uno schermo vuoto.

Poiché i Core Web Vitals sono un segnale di ranking, SSR e SSG ti aiutano due volte: i crawler vedono i tuoi contenuti e gli utenti ottengono una pagina misurabilmente più veloce, il che migliora sia il posizionamento che la conversione. I due obiettivi puntano nella stessa direzione. La nostra guida ai Core Web Vitals illustra come misurarli e raggiungere le soglie, e se il payload stesso è il collo di bottiglia, le strategie di caching sono la leva successiva.

E la ricerca AI e la condivisione social?

La SEO un tempo significava Google, e Google alla fine poteva eseguire il tuo JavaScript. Non è più l'unico scenario rilevante. Una quota crescente di discovery avviene tramite assistenti AI e answer engine che scansionano il web per fondare le proprie risposte, tramite piattaforme social che generano preview dei link e tramite Bing, che alimenta più superfici di quanto la sua quota di mercato lasci intendere. Molti di questi crawler sono meno capaci di Googlebot con JavaScript, non di più: leggono l'HTML grezzo e si fermano.

Questo sposta ulteriormente il calcolo verso il server rendering. Se vuoi che i tuoi contenuti vengano citati da un assistente AI, visualizzati correttamente quando condivisi e indicizzati da ogni motore anziché solo dal più sofisticato, la mossa sicura è inserire i contenuti effettivi — testo, metadati, dati strutturati — nell'HTML inviato dal server, ogni volta. La strategia di rendering è ormai il requisito minimo per essere trovati, non solo per posizionarsi su Google.

Gli errori comuni anche dei siti con server rendering

Rendere lato server è necessario, non sufficiente. Auditando regolarmente siti "SSR", troviamo ancora perdite SEO ricorrenti:

• Hydration mismatch che fanno divergere l'output renderizzato lato client dall'HTML del server, a volte svuotando i contenuti dopo il caricamento.
• Meta tag e dati strutturati impostati lato client, vanificando lo scopo: vanno impostati nella risposta del server.
• Invio di un bundle JS massiccio comunque, così l'idratazione è lenta e la pagina diventa interattiva molto dopo che appare pronta.
• Crawler bloccati nel robots.txt o da protezioni bot aggressive che respingono anche Googlebot.
• Soft-404 e redirect lato client che i crawler interpretano come pagine rotte o inesistenti.

Come vedere cosa vede davvero il crawler

Non è necessario fare supposizioni. Verificalo direttamente, in ordine crescente di impegno:

1. Visualizza il sorgente, non l'inspector di DevTools. Il pannello Elements mostra il DOM idratato dopo l'esecuzione di JavaScript, che appare sempre corretto. Fai clic destro e "Visualizza sorgente pagina" (oppure esegui curl sull'URL) per vedere l'HTML grezzo che il server ha effettivamente inviato. Se titolo e corpo del testo non sono presenti, non li vedrà né il primo passaggio di Googlebot né un bot social.
2. Usa lo strumento di Ispezione URL di Google Search Console. Mostra l'HTML renderizzato e lo screenshot prodotto da Google, oltre a eventuali problemi di indicizzazione. È la fonte di verità per ciò che Google ha ricevuto nello specifico.
3. Testa il preview social incollando il tuo URL in un debugger (LinkedIn, Facebook e Slack espongono tutti il proprio). Una card rotta è un segnale immediato che i tuoi meta tag sono renderizzati lato client.
4. Disabilita JavaScript nel browser e ricarica la pagina. Se la pagina diventa vuota, lo è anche per ogni crawler che non esegue JS.

Esegui questi controlli prima del lancio e dopo qualsiasi modifica al framework o alla strategia di rendering: le regressioni in questo ambito sono silenziose, e spesso le si scopre settimane dopo, quando il traffico smette silenziosamente di arrivare.

La regola pragmatica

Se una pagina deve essere trovata dalla ricerca o condivisa sui social, renderizzala sul server o al momento della build, senza eccezioni. Se una pagina si trova dietro un login e nessun crawler la vedrà mai, il CSR va benissimo ed è spesso più semplice: non c'è SEO da perdere. La maggior parte dei prodotti reali è un mix deliberato: una shell pubblica con server rendering — pagine marketing, contenuti, pagine prodotto — che racchiude un'app autenticata con client rendering dove la SEO è irrilevante.

Se il traffico organico è importante per il tuo prodotto e non sei certo che il tuo stack attuale renderizzi correttamente per i crawler, contattaci: verificare esattamente cosa riceve Googlebot è una delle prime cose che auditoriamo, ed è spesso il miglioramento SEO più economico che un sito possa fare.