Qué es y cómo funciona
Un CMS tradicional, como WordPress con un tema clásico, hace dos trabajos a la vez: guarda el contenido y genera las páginas con las que se muestra. Un CMS headless, literalmente «sin cabeza», se queda solo con el primer trabajo. Gestiona los datos, los usuarios y el panel de edición, y entrega el contenido por una API para que cualquier otra aplicación lo presente.
Esa otra aplicación, el front, puede ser una web hecha con Next.js o Astro, una app móvil o varias a la vez, todas leyendo del mismo contenido. El equipo editorial sigue trabajando en un panel conocido, mientras que el equipo técnico decide libremente cómo se construye y se sirve la web.
WordPress puede funcionar como headless si se usa solo como backend, por ejemplo con la API REST que incluye o con WPGraphQL. También existen gestores pensados desde el principio para esto, como Strapi o Sanity. La elección depende del equipo, de cómo se modela el contenido y de quién va a mantenerlo.
Por qué importa
La separación da libertad en rendimiento, diseño y canales. Puedes servir páginas estáticas rápidas, reutilizar el contenido en una app o cambiar el front sin migrar los datos. También permite aislar el panel de edición, que deja de estar expuesto como parte de la web pública.
A cambio, hay más piezas que mantener: un servidor para el CMS, otro para el front, una conexión entre ambos y un proceso de despliegue. Perderás cosas que en un WordPress clásico venían gratis: la vista previa, los plugins que modifican el front, los formularios o el SEO que dependía del tema. Para una web de pocas páginas y un equipo pequeño, un WordPress tradicional bien cuidado puede ser la opción más sensata.
Un ejemplo
Una empresa de formación gestiona cientos de cursos y quiere mostrarlos en su web y en una app móvil. Guarda cursos, fechas y profesores en un CMS headless y publica una API. La web, hecha con Next.js, lee esa API y genera páginas rápidas; la app consume la misma API. Cuando el equipo comercial cambia el precio de un curso en el panel, ambos canales se actualizan sin tocar código.
Errores y confusiones frecuentes
- Pensar que headless es sinónimo de mejor. Si tienes una sola web sencilla, añade complejidad y coste de mantenimiento sin un beneficio claro.
- Subestimar la vista previa. Los editores están acostumbrados a ver cómo queda antes de publicar, y en headless hay que construirla.
- No modelar bien el contenido. Una estructura de campos mal pensada se paga luego en cada canal que consume los datos.