No siempre necesitas un CMS: un framework de decision para sitios modernos
Como agencia web remota en Nepal, construimos una mezcla de sitios de servicios, sitios de marketing y web apps de producto. Hay una pregunta que aparece en casi todos los kickoffs: "Necesitamos un CMS?" La respuesta honesta es: no siempre. Muchos sitios son estructuralmente simples, y agregar un CMS crea nuevas superficies operativas: auth, bases de datos, permisos, riesgo de plugins, trabajo de upgrades y entrenamiento editorial. Este post es un framework practico de decision, basado en lo que esta cambiando ahora: stacks static-first, madurez de headless CMS y flujos de edicion asistidos por IA.Empieza por el trabajo que el "CMS" se supone que debe hacer
Cuando la gente dice "CMS", normalmente se refiere a uno (o mas) de estos trabajos:- un lugar para que no-ingenieros actualicen paginas sin abrir un PR
- un modelo estructurado para tipos de contenido (posts, case studies, servicios, FAQs)
- flujos editoriales: borradores, aprobaciones, programacion, roles, historial de revisiones
- operaciones de contenido: redirects, enlazado interno, campos SEO, gestion de media
El perfil de "no necesitas un CMS" (la mayoria de sitios de servicios)
Probablemente no necesitas un CMS completo si la mayoria de esto es cierto:- los cambios de contenido son ocasionales (no diarios)
- el sitio es principalmente: home, servicios, about, contacto y un blog
- tu modelo de contenido es poco profundo (pocas relaciones)
- tu equipo puede vivir con "los cambios de contenido se publican via un proceso de release"
- te importa mas un output HTML predecible que plugins de un admin panel
- Next.js 16 SEO Checklist for Production
- AI Search Optimization in 2025: Build Websites Like It’s 2005
"Pero y la edicion?" La restriccion real es el workflow, no la tecnologia
El argumento historico mas fuerte para un CMS ha sido la experiencia de edicion: "nuestro equipo no puede editar Markdown y desplegar". Sigue siendo una restriccion valida para muchos equipos. Pero la forma de esa restriccion esta cambiando:- muchos equipos ya usan workflows basados en Git para docs y marketing de producto
- existen herramientas de preview visual para setups static y headless
- la edicion asistida por IA reduce la barrera de "tienes que aprender la herramienta"
Cuando realmente necesitas un CMS (y deberias elegir uno con intencion)
Un CMS se gana su complejidad cuando el sitio es parte de un sistema operacional con volumen editorial constante o requisitos de contenido complejos. Probablemente si necesitas un CMS si tienes:- multiples editores publicando con frecuencia
- control de acceso por roles y aprobaciones
- programacion, revisiones y auditoria como requisitos
- un modelo de contenido muy estructurado / relacional:
- productos
- ubicaciones
- autores
- categorias
- knowledge bases
- personalizacion o contenido que cambia por usuario/sesion
- un sitio que es, en la practica, una aplicacion (membership, LMS, contenido con gate)
La trampa: "construimos un CMS pequeno"
Aqui es donde los equipos se queman. La primera version suena pequena:- una pantalla de login
- un editor
- subidas de media
- publicar/despublicar
- roles y permisos
- borradores, previews, aprobaciones
- historial de revisiones y diffing
- migraciones de schema
- transformaciones/optimizacion de imagenes
- integridad de enlaces y gobernanza de redirects
- prevencion de abuso, rate limits y seguridad de contenido
- usar un CMS que ya resuelva las partes duras, o
- no usar CMS y en su lugar invertir en un workflow que haga los cambios de contenido seguros
Una matriz de decision que usamos en proyectos reales
Aqui tienes un set simple de preguntas que normalmente hace obvia la decision correcta.1) Con que frecuencia cambia el contenido?
- mensual o menos: static-first suele estar bien
- semanal con multiples autores: considera un CMS
- cadencia editorial diaria: elige un CMS temprano
2) Quien necesita publicar?
- solo ingenieros: MDX/Markdown es limpio y fiable
- un equipo pequeno que puede usar preview + formularios estructurados: tooling de contenido ligero funciona
- muchos editores no tecnicos: CMS
3) Necesitas features de workflow?
Si necesitas borradores, aprobaciones, programacion y roles, estas describiendo un CMS.4) Tu contenido es relacional?
Si tu contenido depende de relaciones y consultas (no solo paginas), quieres un modelo respaldado por CMS.5) Es critica la salida "pixel-perfect"?
Los enfoques static y MDX-first suelen ganar aqui porque controlas el output HTML de punta a punta.Alternativas a "CMS" que funcionan bien para agencias
En vez de elegir un CMS por defecto, elige la herramienta mas pequena que cumpla el requisito real:- MDX/Markdown en el repo:
- ideal para sitios de servicios, blogs tecnicos y docs
- combina bien con QA gates y disciplina de enlazado interno
- Un headless CMS:
- ideal cuando necesitas contenido estructurado + workflows editoriales
- Un CMS agent-native (categoria emergente):
- busca que la automatizacion y las operaciones con IA sean first-class
- ejemplo: EmDash: Cloudflare’s Agent-Native CMS
Nuestro ejemplo: Lunover paso de WordPress a Markdown (2024)
En 2024 movimos el sitio de Lunover de WordPress a un setup Markdown/MDX-first. Hoy nuestro "CMS" es basicamente:- archivos Markdown/MDX bien estructurados en el repo
- un conjunto pequeno de componentes reutilizables para secciones consistentes (CTAs, callouts, layouts)
- un workflow de release (preview, review, deploy)
- la mayoria de paginas no cambian con frecuencia
- los edits suelen ser pequenos e intencionales (no publicacion editorial constante)
- todo el equipo puede leer y trabajar con Markdown
- la estructura se refuerza con plantillas y convenciones, no con un dashboard
Donde cae esto para una agencia web
Para la mayoria de sitios de servicios, la "decision de CMS" es en realidad una decision de delivery:- Quieres que los cambios de contenido se gobiernen como releases?
- O necesitas un sistema editorial self-serve con controles de workflow?