CMS headless frente a CMS tradicional: ¿cuál encaja en su sitio?
Un CMS tradicional guarda el contenido y genera las páginas. Un CMS headless guarda el contenido y lo entrega por una API, dejándole a usted todo el renderizado. Esa única diferencia se propaga a todo: vista previa, coste, estructura de equipo y con qué rapidez puede alguien de marketing cambiar una página.
Esta guía cubre qué gana, qué pierde y dónde está el término medio.
La diferencia real#
Todo lo demás se deriva de dónde ocurre el renderizado.
| Tradicional | Headless | |
|---|---|---|
| Renderizado | El CMS produce el HTML | Su frontend lo hace |
| Plantillas | Dentro del CMS | En su código |
| Vista previa | Incorporada y fiel | Tiene que construirla |
| Canales | Un sitio web | Web, app, quiosco, lo que pueda llamar a una API |
| Libertad de frontend | Limitada por el CMS | Total |
| Tiempo hasta la primera página | Rápido | Lento: nada se muestra hasta que lo construya |
| Quién hace falta para un cambio de maquetación | A menudo quien edita | Quien desarrolla |
Qué pierde al pasar a headless#
Las funciones que un CMS tradicional da gratis son las que se echan de menos, y normalmente se descubren después de tomar la decisión.
- Vista previa. Quien edita espera ver la página antes de publicar. En headless es una función que usted construye y mantiene.
- Composición de páginas. Organizar bloques en una página es un problema resuelto en los sistemas tradicionales y un desarrollo en los headless.
- Menús y navegación. También algo que ahora modela y construye usted.
- Formularios. Con la API no viene ningún creador de formularios.
- Redirecciones y gestión de URLs. A su cargo.
- Ecosistema de plugins. Campos de SEO, sitemaps, redirecciones: todo pasa a ser desarrollo propio.
- Velocidad de los cambios pequeños. «Sube esa sección» deja de ser una tarea de edición.
El patrón recurrente en los proyectos headless decepcionantes es un equipo de marketing que antes podía cambiar una página solo y ahora abre tickets.
Cuándo headless es la decisión correcta#
Encaja con una forma concreta de problema, y fuera de esa forma es flexibilidad cara.
| Situación | Encaje |
|---|---|
| Contenido mostrado en un sitio y en una app móvil | Fuerte: este es el caso central |
| Varios sitios compartiendo una fuente de contenido | Fuerte |
| Requisitos de frontend que el CMS no puede cumplir | Fuerte |
| Ya existe un equipo de frontend dedicado | Bueno |
| Sitio de marketing con un equipo pequeño | Malo: pierde velocidad y gana tickets |
| Sitio de contenido con cambios frecuentes de maquetación | Malo |
| «Es el enfoque moderno» | No es un motivo |
El término medio#
A casi todos los sitios les sirve mejor algo entre los dos extremos.
- CMS tradicional con tema propio. Control total del frontend, y la vista previa y la composición siguen funcionando.
- CMS tradicional usado como headless para una superficie. El sitio lo sigue renderizando el CMS; la app consume una API.
- CMS headless con un generador de sitios estáticos. Quien edita tiene buena interfaz y el sitio es estático y rápido; la vista previa requiere trabajo.
- CMS híbrido. Sistemas que ofrecen páginas renderizadas y una API, a menudo la respuesta pragmática.
- Generador estático con editor basado en git. Coste y riesgo muy bajos para contenido que son sobre todo documentos.
Un tema propio sobre un CMS tradicional le da casi toda la libertad de frontend por la que la gente se va a headless, sin renunciar a la vista previa, la composición y el ecosistema.
Preguntas frecuentes
¿Headless es mejor para el rendimiento?
Puede serlo, porque usted controla exactamente qué se envía, pero la ganancia viene de la generación estática y de un frontend ligero, no de la API. Un CMS tradicional bien construido con caché adecuada y tema propio también es rápido. El rendimiento es consecuencia de cómo construye, no de dónde está guardado el contenido.
¿Headless es mejor para el SEO?
Neutral en el mejor caso, y peor si las páginas solo se renderizan en el navegador. Todo lo que necesita el SEO técnico —HTML renderizado en servidor, canónicas, sitemaps, datos estructurados, redirecciones— hay que implementarlo uno mismo en headless, mientras que los sistemas tradicionales tienen plugins maduros. Headless va bien para SEO con disciplina y decepciona sin ella.
¿Puede quien edita previsualizar contenido en headless?
Sí, pero lo construye usted: un modo de vista previa en el frontend que obtenga el contenido en borrador y lo muestre. Presupuéstelo de forma explícita. Los proyectos que se saltan la vista previa acaban con equipos de edición publicando en producción para ver cómo queda algo, que es justo lo que un CMS debería evitar.
¿Cuánto cuesta headless frente a tradicional?
La construcción inicial suele ser mayor, porque está construyendo el frontend más las funciones que un CMS tradicional incluía. Los costes de funcionamiento pueden ser menores, sobre todo con generación estática. La diferencia mayor a largo plazo es que más cambios rutinarios requieren tiempo de desarrollo, un coste continuo que no aparece en el presupuesto de construcción.
cms headlesscms tradicionalheadless vs tradicionaljamstackcms api firstarquitectura cms
