Quando un'attività mi chiede un sito, prima ancora del design c'è una scelta che pesa per anni: sito statico, rendering lato server (SSR) o CMS? Invece di spiegarla in astratto, la racconto con il progetto che conosco meglio: questo sito.
Le tre opzioni in due righe
- Sito statico: le pagine sono file HTML già pronti, generati una volta e caricati su un hosting. Velocissimo, economico, difficilissimo da attaccare. Ma ogni modifica richiede una nuova pubblicazione.
- SSR (server-side rendering): un server genera la pagina a ogni richiesta, con dati sempre aggiornati. Flessibile e ottimo per la SEO, ma serve un server sempre acceso e qualcuno che lo mantenga.
- CMS (WordPress o un CMS headless): il titolare modifica testi e articoli da un pannello, senza sviluppatore. Comodo, ma porta con sé aggiornamenti, plugin e una superficie d'attacco da curare.
Il mio caso: un sito Angular pubblicato come statico
Questo sito è un'applicazione Angular con SSR configurato, un backend NestJS separato con MongoDB e un blog in sette lingue i cui articoli vivono nel database. Sulla carta è il caso perfetto per l'SSR. In pratica, per costi e semplicità, il frontend viene compilato e pubblicato come file statici su un hosting Plesk, mentre il backend gira su un servizio separato.
Funziona, ma ho scoperto sulla mia pelle cosa comporta quella scelta.
1. Senza server, l'SSR non esiste
Con un deploy statico il rendering lato server non gira mai: se una pagina non viene generata durante la build, Google riceve solo la "shell" vuota dell'applicazione. Quando me ne sono accorto, su 32 URL in sitemap Google ne aveva indicizzati 4, e nessun articolo: ho raccontato tutta l'indagine in questo articolo. La soluzione è stata il prerendering: generare in fase di build l'HTML di ogni pagina, articolo per articolo e lingua per lingua.
2. Centinaia di pagine da generare a ogni build
Ogni articolo esiste in sette lingue, quindi le pagine da prerenderizzare sono centinaia. Le prime build interrogavano l'API di produzione per ciascuna: scattava il limite di richieste e alcune pagine venivano generate con il messaggio "articolo non trovato". Ho risolto scaricando tutti gli articoli una sola volta prima della build, in un file di cache da cui legge il prerendering:
// Before the build: download every published post once
const posts = await fetchAllPublishedPosts();
fs.writeFileSync('.prerender-cache/blog-posts.json', JSON.stringify({ posts }));
// The prerender reads this file instead of calling the API hundreds of times3. Ogni articolo nuovo richiede una nuova pubblicazione
È il compromesso più evidente: quando pubblico un articolo dal pannello, il contenuto è subito disponibile tramite API, ma la pagina HTML che legge Google esiste solo dopo la build successiva e il caricamento dei file. Per un blog aggiornato ogni tanto è accettabile; per un sito di notizie no.
4. I dettagli dell'hosting contano
Anche con le pagine generate, Apache rispondeva con un redirect 301 su ognuna: ogni pagina prerenderizzata è una cartella con dentro un index.html, e il server aggiungeva lo slash finale all'URL. Il fix è stato di poche righe nel .htaccess, ma senza un controllo con curl -I non me ne sarei mai accorto:
<IfModule mod_dir.c>
DirectorySlash Off
</IfModule>Proprio per questi compromessi sto preparando il passaggio a un container Node su Plesk, con SSR vero: la complessità era già nel progetto, tanto vale sfruttarla fino in fondo.
Cosa consiglio a una piccola attività
Il mio sito non è un caso tipico: è anche un laboratorio. Per un'attività reale, la scelta dipende quasi sempre da tre domande: quanto spesso cambiano i contenuti, chi li aggiorna e quante pagine servono.
| Situazione | Scelta consigliata | Perché |
|---|---|---|
| Ristorante, artigiano o studio con 5–10 pagine che cambiano poche volte l'anno | Sito statico | Veloce, economico, nessun server da mantenere |
| Professionista che pubblica articoli o novità in autonomia | CMS | Aggiorna i contenuti senza chiamare uno sviluppatore |
| Catalogo con centinaia di prodotti o contenuti che cambiano ogni giorno | SSR o piattaforma e-commerce | Pagine sempre aggiornate e indicizzabili senza ricostruire il sito |
| Area riservata, prenotazioni, dati per utente | Web app più pagine pubbliche statiche o SSR | Le pagine pubbliche servono alla SEO, l'area riservata no |
Per molte attività locali, poi, orari, recensioni e indicazioni stradali contano più del sito stesso: un profilo Google Business curato vale spesso più di una funzionalità in più.
Le domande da farsi prima di scegliere
- Chi aggiornerà i contenuti, e quanto spesso? Se la risposta è "il titolare, ogni settimana", serve un pannello.
- Quanto conta Google? Se il sito vive di ricerche organiche, ogni pagina deve arrivare al crawler come HTML completo: statico o SSR, mai una single page app senza prerendering.
- Chi manterrà il server? Un SSR o un CMS senza aggiornamenti invecchia male; un sito statico può restare fermo per anni.
- Quanto può crescere? Partire statici e passare all'SSR si può, a patto di scegliere un'architettura che lo permetta, come è successo a me con Angular.
Gli errori che vedo più spesso
- Un CMS pesante per cinque pagine che non cambiano mai: plugin da aggiornare e rischi di sicurezza senza alcun vantaggio.
- Una single page app senza prerendering per un sito che deve farsi trovare: piacevole da usare, invisibile ai motori di ricerca.
- Scegliere l'SSR senza budget per mantenerlo: un server va monitorato, aggiornato e pagato ogni mese.
In sintesi
Non esiste la tecnologia migliore in assoluto: esiste quella adatta a come vengono aggiornati i contenuti e a chi li gestisce. Per la maggior parte delle piccole attività un sito statico ben fatto è la scelta più solida; un CMS ha senso quando il titolare vuole autonomia; l'SSR serve quando i contenuti sono tanti e cambiano spesso. Il mio sito mi ha insegnato che ogni scelta ha un costo nascosto: l'importante è conoscerlo prima. Se stai valutando un progetto, scrivimi e partiamo da queste domande.