Tu equipo quiere cambiar un texto de la home y tarda una semana. El sitio se pone lento cada vez que alguien instala un plugin nuevo. Y ahora te piden que el mismo contenido aparezca también en una app. Si alguna de estas escenas te suena, probablemente alguien ya te nombró el CMS headless.
El término suena técnico, pero la idea es simple. Separa el lugar donde cargás el contenido del lugar donde se muestra. Esa separación cambia cómo se construye, se mantiene y crece un sitio.
En esta nota vas a ver qué es un CMS headless y en qué se diferencia de un CMS tradicional. También qué ventajas y costos tiene, y cómo saber si le conviene a tu empresa. Al final repasamos las opciones más usadas y respondemos las dudas más comunes.
¿Qué es un CMS headless?
Un CMS (sistema de gestión de contenidos) es la herramienta donde tu equipo escribe, edita y publica: textos, imágenes, productos, notas de blog. En un CMS tradicional, esa misma herramienta también arma las páginas que ve el visitante.
Un CMS headless hace solo la primera parte. Guarda y organiza el contenido, y lo entrega a través de una API (una interfaz para que otros programas pidan datos). No decide cómo se ve. "Headless" significa justamente eso: sin cabeza, sin la capa de presentación.
La presentación la construye otra pieza, el frontend. Puede ser un sitio web, una app móvil, una pantalla en un local o todo eso a la vez. Cada canal le pide al CMS el contenido que necesita y lo muestra a su manera.
Un ejemplo concreto: Strapi se define en su documentación oficial como un CMS headless de código abierto, con un panel de administración extensible y control de acceso por roles. El panel es para el equipo que edita. La API es para los sitios y apps que muestran.
Hasta acá, la definición. Para entender cuándo vale la pena, conviene ponerlo al lado de lo que ya conocés.
CMS headless vs CMS tradicional: ¿cuál es la diferencia en simple?
Pensalo como un restaurante. En un CMS tradicional, la cocina y el salón son el mismo espacio. Funciona bien mientras el restaurante es chico. Pero si querés abrir un delivery o una segunda sucursal, todo depende de esa única cocina con su único salón.
Un CMS headless es una cocina central. Prepara los platos una sola vez y los manda a donde haga falta: al salón, al delivery o a otra sucursal. Cada lugar los presenta como quiere.
En términos técnicos, la diferencia se ve así:
- CMS tradicional: contenido, diseño y lógica viven en el mismo sistema. Cambiar la presentación muchas veces implica tocar el CMS, sus temas o sus plugins.
- CMS headless: el contenido vive en un sistema y la presentación en otro. Se comunican por API. El diseño se puede rehacer sin mover el contenido.
- Edición: en el tradicional solés editar viendo la página final. En el headless editás campos estructurados y, según la herramienta, ves una vista previa.
- Desarrollo: el tradicional te deja arrancar con un tema prearmado. El headless pide construir el frontend desde el inicio.
Un caso intermedio es WordPress. Es el CMS tradicional más conocido, pero también puede funcionar en modo headless. Su documentación de la API REST explica que permite enviar y recibir el contenido del sitio como objetos JSON. Con eso podés llevar tus contenidos a aplicaciones totalmente separadas.
La diferencia técnica es clara. Lo que importa para una empresa es otra pregunta: qué gana con ese cambio.
¿Qué ventajas tiene un CMS headless para una empresa: velocidad, seguridad y varios canales?
Las ventajas dependen de cómo se implemente. Un CMS headless mal armado puede ser tan lento o tan frágil como cualquier otro. Bien armado, abre tres beneficios concretos.
Velocidad
Como el frontend es independiente, se puede construir con tecnologías pensadas para cargar rápido. Por ejemplo, generar páginas estáticas que se sirven ya listas, sin consultar una base de datos en cada visita. En Astro o React: cuándo usar cada uno comparamos dos de esas tecnologías según el objetivo del proyecto.
También ganás velocidad de trabajo. El equipo de contenido sigue publicando mientras el equipo de desarrollo cambia el diseño. Uno no frena al otro.
Seguridad
En un CMS tradicional, el panel de administración y el sitio público suelen estar en el mismo servidor. Si alguien encuentra una falla en un plugin, puede llegar a todo.
En una arquitectura headless, el panel puede vivir en otro lugar, con acceso restringido. El sitio público, si es estático, no expone una base de datos ni un panel para atacar. La superficie de ataque se achica. No desaparece: la API y el CMS también hay que cuidarlos.
Varios canales
Es la ventaja que más se nota cuando la empresa crece. Cargás un producto, una sucursal o una nota una sola vez, y aparece en la web, la app y donde haga falta.
Sanity lo describe en su documentación del Content Lake: guarda el contenido como datos estructurados, listos para consultarse, referenciarse y entregarse a cualquier canal. Ese es el corazón del modelo headless.
Hasta acá, lo bueno. Pero ninguna arquitectura es gratis, y esta tiene costos que conviene conocer antes de decidir.
¿Qué desventajas y costos conviene conocer antes de elegir?
Un CMS headless resuelve problemas, pero también trae otros. Estos son los más frecuentes:
- Más desarrollo inicial: no hay un tema listo para instalar. El frontend se diseña y se programa desde cero.
- Dos sistemas para mantener: el CMS y el frontend se actualizan, se alojan y se monitorean por separado.
- Dependencia técnica: cambios que en un CMS tradicional hace el equipo de marketing, como sumar un bloque nuevo a una página, acá suelen pedir un desarrollador.
- Vista previa más compleja: ver cómo queda una página antes de publicar requiere configuración extra.
- Integraciones a medida: formularios, buscadores o comercio electrónico que en otros sistemas vienen como plugin, acá se integran por separado.
Sobre los costos, hay tres partidas que conviene separar al pedir presupuestos. La licencia o el alojamiento del CMS, que varía mucho según la herramienta y el plan. El desarrollo del frontend, que suele ser la parte más grande. Y el mantenimiento de las dos piezas en el tiempo.
Ninguna de estas desventajas descarta el modelo. Lo que hacen es marcar una frontera: hay proyectos donde compensa y otros donde no.
¿Cuándo conviene un CMS headless y cuándo no?
La decisión no depende de la moda, sino de lo que tu empresa necesita en los próximos años. Estas señales indican que un CMS headless probablemente te conviene:
- Necesitás mostrar el mismo contenido en más de un canal: web, app, pantallas o sitios de distintas marcas.
- El rendimiento del sitio es crítico para tu negocio y hoy no lo podés mejorar.
- Tu equipo de contenido y tu equipo técnico se frenan mutuamente.
- Planeás rediseñar el sitio cada pocos años y no querés migrar el contenido cada vez.
- Tenés un equipo de desarrollo, propio o externo, para sostener el frontend.
Y estas otras indican que probablemente no:
- Tu sitio es institucional, chico y cambia poco.
- Tu equipo necesita armar páginas nuevas sin ayuda técnica.
- No vas a tener soporte de desarrollo después del lanzamiento.
- El objetivo es salir rápido con un presupuesto ajustado.
En el medio hay muchos grises. Un sitio que hoy es chico puede necesitar una app el año que viene. Por eso conviene evaluar la arquitectura junto con el plan de crecimiento, no solo con el sitio de hoy.
En ARTDEPARTMENT hacemos esa evaluación al principio de cada proyecto web. Si estás entre las dos opciones, contanos qué necesita tu proyecto de diseño y desarrollo web y lo vemos juntos.
Si ya decidiste que el modelo headless te sirve, la pregunta siguiente es con qué herramienta.
¿Cuáles son las opciones de CMS headless más usadas?
Hay muchas, pero cinco aparecen en casi cualquier comparación. Cada una parte de una filosofía distinta.
WordPress headless
Es WordPress usado solo como gestor de contenido. El equipo edita en el panel de siempre y un frontend separado consume la API REST. Según su documentación oficial, esa API es además la base del editor de bloques. Conviene cuando tu equipo ya conoce WordPress y no querés cambiarle la forma de trabajar. Si ese es tu caso, te contamos cómo modernizar tu sitio con WordPress headless sin dejar WordPress.
Strapi
Es un CMS headless de código abierto. Su documentación indica que podés consultar el contenido por REST y GraphQL, y que el panel y la API se extienden con plugins. Te da control total, porque lo instalás y lo alojás donde quieras. Si querés ver cómo funciona en la práctica, lo analizamos en qué es Strapi y cuándo conviene.
Contentful
Es una plataforma en la nube. En el repositorio oficial de su librería de JavaScript, Contentful se presenta como infraestructura de contenido para potenciar sitios, apps y dispositivos. Ofrece APIs de gestión y de entrega, y una aplicación web para editar. No tenés que alojar ni mantener el CMS.
Sanity
Guarda el contenido como documentos JSON en su Content Lake y lo consulta con GROQ, su propio lenguaje de consultas. También ofrece una API de GraphQL. Su fuerte es el contenido estructurado y conectado, que se puede reutilizar en distintos contextos.
Payload
Se presenta como un framework fullstack para Next.js. Según su documentación oficial, con un archivo de configuración generás un panel de administración, una base de datos con migraciones, APIs REST y GraphQL, autenticación y control de acceso. Es de código abierto y TypeScript, y lo podés desplegar donde quieras.
Ninguna es mejor en abstracto. La elección depende de quién va a editar, quién va a mantener y dónde querés que vivan los datos. Vamos a analizar varias de estas opciones en detalle en las próximas notas de esta serie.
Antes, las preguntas que más aparecen cuando una empresa evalúa este cambio.
Preguntas frecuentes sobre CMS headless
¿Headless CMS y CMS headless son lo mismo?
Sí. "Headless CMS" es la forma en inglés y "CMS headless" la adaptación más usada en español. Los dos nombran un sistema que gestiona el contenido y lo entrega por API, sin ocuparse de la presentación.
¿Un CMS headless es mejor para el SEO?
No por sí solo. El posicionamiento depende del contenido, de la estructura del sitio y de la experiencia de página. Lo que sí permite un CMS headless es construir un frontend rápido y con control total sobre títulos, URLs y datos estructurados. Si ese frontend se arma mal, el SEO se resiente igual.
¿Puedo pasar mi WordPress actual a headless?
En muchos casos, sí. WordPress expone su contenido por la API REST, así que se puede construir un frontend nuevo sin migrar los contenidos a otro sistema. Hay que revisar qué plugins dependen del tema actual, porque esas funciones se tienen que resolver en el frontend nuevo.
¿Mi equipo de marketing va a poder editar solo?
Para el contenido del día a día, sí: notas, productos, textos y fotos. Para crear tipos de página nuevos o cambiar el diseño, normalmente hace falta un desarrollador. Por eso es clave diseñar bien los bloques y campos al inicio.
¿Cuánto tarda implementar un CMS headless?
Depende del alcance: cantidad de tipos de contenido, canales, integraciones y migración. Un sitio con un frontend nuevo siempre lleva más que instalar un tema. Lo importante es que el plan contemple las dos piezas, el CMS y el frontend, desde el principio.
Un CMS headless no es la respuesta para todos. Pero cuando tu contenido tiene que llegar lejos y rápido, es una de las mejores bases para crecer sin rehacer todo cada vez.
