Non sempre ti serve un CMS: un framework decisionale per siti moderni

Come web agency remota in Nepal, costruiamo un mix di siti di servizi, siti marketing e web app prodotto. Una domanda arriva in quasi ogni kickoff di progetto: “Ci serve un CMS?” La risposta onesta e: non sempre. Molti siti sono strutturalmente semplici e aggiungere un CMS crea nuove superfici operative: auth, database, permessi, rischio plugin, lavoro di upgrade e formazione editoriale. Questo post e un framework decisionale pratico, basato su cio che sta cambiando adesso: stack static-first, maturita dei headless CMS e workflow di editing assistiti dall’AI.

Parti dal lavoro che il “CMS” dovrebbe fare

Quando le persone dicono “CMS”, di solito intendono uno (o piu) di questi lavori:

Un posto dove i non-ingegneri possono aggiornare pagine senza aprire una PR.
Un modello strutturato per i content type (post, case study, servizi, FAQ).
Workflow editoriali: draft, approvazioni, scheduling, ruoli, revision history.
Content ops: redirect, internal linking, campi SEO, gestione media.

Spesso ti serve solo uno di questi, non l’intero “pacchetto CMS tradizionale”.

Il profilo “non ti serve un CMS” (la maggior parte dei siti di servizi)

Probabilmente non ti serve un CMS completo se la maggior parte di queste cose e vera:

I contenuti cambiano ogni tanto (non ogni giorno).
Il sito e principalmente: homepage, servizi, about, contatto e un blog.
Il modello contenuti e poco profondo (poche relazioni).
Il team puo accettare che “gli aggiornamenti contenuto viaggiano con un processo di release”.
Ti interessa piu un output HTML prevedibile che plugin da pannello admin.

In quel caso, un approccio static-first (MDX/Markdown + componenti tipizzati + pipeline di build) puo essere una scelta pulita. Se sei su Next.js, di solito lo abbini a una base solida di SEO tecnica:

“Ma l’editing?” Il vero vincolo e il workflow, non la tecnologia

L’argomento storico piu forte per un CMS e l’esperienza di editing: “il nostro team non riesce a modificare Markdown e deployare”. E ancora un vincolo valido per molti team. Ma la forma del vincolo sta cambiando:

Molti team usano gia workflow Git-based per docs e product marketing.
Esistono strumenti di preview visuale per setup statici e headless.
L’editing assistito dall’AI sta riducendo la barriera del “devi imparare gli strumenti”.

Il takeaway pratico: se puoi rendere l’editing sicuro e previewabile, spesso puoi evitare un pannello admin tradizionale.

Quando ti serve davvero un CMS (e dovresti sceglierlo con intenzione)

Un CMS si “guadagna” la sua complessita quando il sito fa parte di un sistema operativo con volume editoriale continuo o requisiti contenuto complessi. Probabilmente ti serve un CMS se hai:

Piu editor che pubblicano spesso.
Controllo accessi basato su ruoli e approvazioni.
Scheduling, revisioni e audit trail come requisiti non negoziabili.
Un modello contenuti molto strutturato / relazionale:
- prodotti
- location
- autori
- categorie
- knowledge base
Personalizzazione o contenuti che cambiano per utente/sessione.
Un sito che e, di fatto, un’applicazione (membership, LMS, contenuti gated).

In questi casi, un headless CMS o un approccio “CMS + framework app” e spesso lo strumento giusto.

La trappola: “costruiamo un CMS piccolo”

E qui che i team si bruciano. La prima versione sembra piccola:

una schermata login
un editor
upload media
publish/unpublish

Ma i requisiti reali di un CMS arrivano dopo:

ruoli e permessi
draft, preview, approvazioni
revision history e diff
migrazioni di schema
trasformazioni immagini e ottimizzazione
integrita dei link e governance dei redirect
prevenzione abusi, rate limit e sicurezza contenuti

Se costruisci un CMS, ti stai impegnando a mantenere un ecosistema di problemi che esistono perche i contenuti sono infrastruttura di produzione. Se il tuo obiettivo e “spedire pagine velocemente e in sicurezza”, il pattern migliore e:

usare un CMS che gestisce gia le parti difficili, oppure
evitare il CMS e investire in un workflow che rende gli aggiornamenti contenuto sicuri

Una matrice decisionale che usiamo nei progetti reali

Ecco un set di domande che di solito rende la scelta ovvia.

1) Quanto spesso cambiano i contenuti?

Mensile o meno: static-first di solito va bene.
Settimanale con piu autori: valuta un CMS.
Cadenza editoriale giornaliera: scegli un CMS presto.

2) Chi deve pubblicare?

Solo ingegneri: MDX/Markdown e pulito e affidabile.
Un piccolo team che puo usare preview + form strutturate: tooling leggero funziona bene.
Molti editor non tecnici: CMS.

3) Ti servono feature di workflow?

Se ti servono draft, approvazioni, scheduling e ruoli, stai descrivendo un CMS.

4) Il contenuto e relazionale?

Se il tuo contenuto dipende da relazioni e query (non solo pagine), vuoi un modello supportato da CMS.

5) L’output “pixel-perfect” e critico?

Approcci static e MDX-first spesso vincono qui perche controlli l’output HTML end-to-end.

Alternative “CMS” che funzionano bene per le agency

Invece di partire dal CMS, scegli lo strumento piu piccolo che soddisfa il requisito reale:

MDX/Markdown in-repo:
- ottimo per siti di servizi, blog tecnici e docs
- si abbina bene a QA gate solidi e disciplina di internal linking
Un headless CMS:
- ottimo quando servono contenuti strutturati + workflow editoriali
Un CMS agent-native (categoria emergente):
- punta a rendere automazione e operazioni guidate da AI di prima classe
- esempio: EmDash: Cloudflare’s Agent-Native CMS

Il nostro esempio: Lunover e passata da WordPress a Markdown (2024)

Nel 2024 abbiamo spostato il sito Lunover da WordPress a un setup Markdown/MDX-first. Oggi il nostro “CMS” e essenzialmente:

file Markdown/MDX ben strutturati in-repo
un set piccolo di componenti riutilizzabili per sezioni consistenti (CTA, callout, layout)
un workflow di release (preview, review, deploy)

Per noi funziona perche il comportamento dei contenuti combacia con il profilo “no CMS”:

la maggior parte delle pagine non cambia spesso
le modifiche sono piccole e intenzionali (non publishing editoriale costante)
tutti nel team sanno leggere e lavorare con Markdown
la struttura e imposta da template e convenzioni, non da una dashboard

Il punto chiave non e che WordPress sia “cattivo”. E che quando i contenuti sono stabili e il team sa gestire Markdown, un CMS puo diventare superficie extra senza aggiungere valore proporzionato.

Cosa significa per una web agency

Per la maggior parte dei siti di servizi, la “decisione CMS” e in realta una decisione di delivery:

Vuoi che i cambi contenuto siano governati come release?
Oppure ti serve un sistema editoriale self-serve con controlli di workflow?

Costruiamo entrambe le tipologie di sistemi, ma scegliamo con intenzione perche la superficie di manutenzione nel lungo periodo e diversa. Se stai pianificando una nuova build o una migrazione e vuoi una raccomandazione tarata sul tuo team e sulla tua cadenza di aggiornamento: