CMS headless o tradizionale: quale è adatto al tuo sito?
Un CMS tradizionale conserva i contenuti e produce le pagine. Un CMS headless conserva i contenuti e li consegna tramite un'API, lasciando interamente a te il rendering. Quella singola differenza si ripercuote su tutto: anteprima, costo, struttura del team e con quanta rapidità una persona del marketing può cambiare una pagina.
Questa guida copre cosa guadagni, cosa perdi, e dove sta la via di mezzo.
La differenza vera#
Tutto il resto discende da dove avviene il rendering.
| Tradizionale | Headless | |
|---|---|---|
| Rendering | Il CMS produce l'HTML | Lo fa il tuo front-end |
| Template | Dentro il CMS | Nel tuo codice |
| Anteprima | Integrata e fedele | Devi costruirla |
| Canali | Un sito web | Sito, app, totem, qualsiasi cosa possa chiamare un'API |
| Libertà sul front-end | Limitata dal CMS | Totale |
| Tempo fino alla prima pagina | Rapido | Lento: nulla appare finché non lo costruisci |
| Chi serve per un cambio di impaginazione | Spesso la redazione | Chi sviluppa |
Cosa perdi passando all'headless#
Le funzionalità che un CMS tradizionale offre gratis sono quelle che mancano, e di solito si scoprono dopo aver deciso.
- L'anteprima. La redazione si aspetta di vedere la pagina prima di pubblicare. Nell'headless è una funzionalità che costruisci e mantieni.
- La composizione delle pagine. Disporre blocchi su una pagina è un problema risolto nei sistemi tradizionali e un cantiere in quelli headless.
- Menu e navigazione. Anche questi diventano qualcosa che modelli e costruisci tu.
- I moduli. Con l'API non arriva alcun costruttore di moduli.
- Reindirizzamenti e gestione degli URL. A tuo carico.
- L'ecosistema di plugin. Campi SEO, sitemap, reindirizzamenti: tutto diventa sviluppo su misura.
- La rapidità delle piccole modifiche. «Sposta su quella sezione» smette di essere un compito della redazione.
Lo schema ricorrente nei progetti headless deludenti è un team marketing che prima poteva cambiare una pagina da solo e ora apre ticket.
Quando l'headless è la scelta giusta#
Si adatta a una forma di problema precisa, e fuori da quella forma è flessibilità costosa.
| Situazione | Adeguatezza |
|---|---|
| Contenuti mostrati in un sito e in un'app mobile | Forte: è il caso centrale |
| Più siti che condividono una fonte di contenuti | Forte |
| Requisiti di front-end che il CMS non può soddisfare | Forte |
| Esiste già un team front-end dedicato | Buona |
| Sito di marketing con un team piccolo | Scarsa: perdi rapidità e guadagni ticket |
| Sito editoriale con frequenti cambi di impaginazione | Scarsa |
| «È l'approccio moderno» | Non è una ragione |
La via di mezzo#
Alla maggior parte dei siti serve meglio qualcosa tra i due estremi.
- CMS tradizionale con tema su misura. Controllo totale del front-end, e anteprima e composizione continuano a funzionare.
- CMS tradizionale usato in modo headless per una sola superficie. Il sito resta reso dal CMS; l'app consuma un'API.
- CMS headless con un generatore di siti statici. La redazione ha una buona interfaccia, il sito è statico e veloce; l'anteprima richiede lavoro.
- CMS ibrido. Sistemi che offrono sia pagine rese sia un'API — spesso la risposta pragmatica.
- Generatore statico con editor basato su git. Costo e rischio molto bassi per contenuti che sono soprattutto documenti.
Un tema su misura su un CMS tradizionale ti dà la maggior parte della libertà di front-end per cui si passa all'headless, senza rinunciare ad anteprima, composizione ed ecosistema.
Domande frequenti
L'headless è migliore per le prestazioni?
Può esserlo, perché controlli esattamente cosa viene inviato — ma il guadagno viene dalla generazione statica e da un front-end leggero, non dall'API. Un CMS tradizionale ben costruito con cache adeguata e tema su misura è veloce lo stesso. Le prestazioni sono conseguenza di come costruisci, non di dove sono conservati i contenuti.
L'headless è migliore per la SEO?
Neutro nel migliore dei casi, e peggiore se le pagine vengono rese solo nel browser. Tutto ciò che serve al SEO tecnico — HTML reso lato server, canonici, sitemap, dati strutturati, reindirizzamenti — nell'headless devi implementarlo tu, mentre i sistemi tradizionali hanno plugin maturi. L'headless va bene per la SEO con disciplina e delude senza.
La redazione può vedere un'anteprima con l'headless?
Sì, ma la costruisci tu: una modalità anteprima nel front-end che recuperi i contenuti in bozza e li mostri. Mettila a budget esplicitamente. I progetti che saltano l'anteprima finiscono con la redazione che pubblica in produzione per vedere come viene, che è esattamente ciò che un CMS dovrebbe evitare.
Quanto costa l'headless rispetto al tradizionale?
La costruzione iniziale è tipicamente più alta, perché stai costruendo il front-end più le funzionalità che un CMS tradizionale includeva. I costi di esercizio possono essere più bassi, soprattutto con la generazione statica. La differenza maggiore nel lungo periodo è che più modifiche di routine richiedono tempo di sviluppo, un costo continuo che non compare nel preventivo di realizzazione.
cms headlesscms tradizionaleheadless o tradizionalejamstackcms api firstarchitettura cms
