Cuando se habla de sitios web rápidos y seguros, antes o después aparece el término Jamstack. La idea es sencilla: generar páginas estáticas en el momento del build y servirlas desde una CDN, sin bases de datos expuestas ni servidores que procesen cada petición. El resultado es una web que carga rápido, que casi no tiene superficie de ataque y que escala sin esfuerzo.
Pero hay una pregunta práctica que surge enseguida: si la web es estática, ¿cómo edita el contenido el cliente sin tener que llamar a un desarrollador cada vez que quiere cambiar un texto? Ahí es donde entra el CMS headless.
La diferencia entre un CMS tradicional y uno headless
En un CMS tradicional como WordPress, el contenido y la presentación están pegados. La base de datos guarda los textos, las imágenes y los metadatos. El servidor los recupera, los pasa por una plantilla PHP y devuelve el HTML al navegador. Todo ocurre en el mismo sistema, en el mismo servidor, en el mismo momento en que el visitante hace la petición.
Un CMS headless separa esas dos capas. El backend —que es donde vive el contenido— existe de forma independiente. El editor escribe, modifica y organiza el contenido en una interfaz cómoda. Pero ese contenido no tiene un frontend asignado: se expone a través de una API que cualquier aplicación puede consultar.
La palabra "headless" hace referencia precisamente a eso: al CMS le falta la cabeza, es decir, el frontend. La cabeza se la pone quien construye el sitio, eligiendo la tecnología que mejor encaje: Eleventy, Next.js, Astro o cualquier otra. La separación es completa. El contenido fluye a través de la API hasta el generador de sitios estáticos, que produce el HTML final durante el proceso de build.
Cómo encaja en el flujo Jamstack
El flujo de trabajo típico es este: el editor entra al CMS headless, hace sus cambios y los guarda. Eso dispara un build del sitio —o el editor lo solicita manualmente cuando ha terminado todos sus cambios—. El generador de sitios estáticos, por ejemplo Eleventy, consulta la API del CMS, recoge los datos actualizados y regenera las páginas afectadas. El resultado se despliega en la CDN y en cuestión de minutos el sitio está actualizado.
El visitante nunca ve ese proceso. Solo recibe HTML estático servido desde el punto más cercano geográficamente. Sin tiempos de respuesta de base de datos, sin PHP ejecutándose en tiempo real, sin plugins que puedan abrirle una puerta a un atacante.
Las opciones principales del mercado
Hay varias categorías de CMS headless y cada una tiene sus ventajas dependiendo del proyecto.
Decap CMS (antes Netlify CMS) es una opción de código abierto que se integra directamente con el repositorio de Git. El contenido se guarda como archivos Markdown o JSON en el propio repositorio, lo que significa que no hay ningún servicio externo del que depender. El editor usa una interfaz web sencilla y cada cambio se convierte en un commit. Es una opción muy sólida para webs de tamaño medio con equipos editoriales pequeños.
Sanity y Contentful son plataformas en la nube con una propuesta más potente. Ofrecen modelos de contenido estructurado, flujos de publicación, gestión de activos multimedia y APIs muy flexibles. Son ideales para proyectos grandes con varios editores, tipos de contenido complejos o necesidad de publicar el mismo contenido en múltiples canales. El inconveniente es que implican una suscripción mensual que crece con el uso, y una dependencia de un servicio externo.
Desarrollo a medida es la tercera vía, y para ciertos clientes es la que mejor funciona. En Idenautas hemos desarrollado para algunos proyectos un backend propio en PHP que almacena los datos en archivos JSON. El cliente tiene una interfaz de edición hecha a su medida, pensada exactamente para su flujo de trabajo y sus tipos de contenido, sin funciones que no va a usar ni complejidad que no necesita. Cuando ha terminado de hacer todos sus cambios —no uno a uno, sino en bloque— solicita un único build. Eso es una ventaja real frente a los sistemas que generan un build por cada cambio guardado: el cliente revisa todo antes de publicar y el proceso es más controlado y eficiente. No hay cuota mensual de ningún SaaS, el sistema pertenece al proyecto y puede adaptarse a cualquier necesidad futura sin depender de la hoja de ruta de otra empresa.
Qué tener en cuenta para elegir
La decisión no es técnica en primer lugar. Es operativa. Hay tres preguntas que lo aclaran todo:
¿Con qué frecuencia se actualiza el contenido? Un blog que publica dos artículos al mes tiene necesidades muy distintas a una tienda que actualiza precios cada día. Para actualizaciones frecuentes, un sistema que genere builds automáticamente tiene más sentido. Para actualizaciones más espaciadas, un sistema de build bajo demanda es suficiente y más eficiente.
¿Quién va a editar el contenido? Un equipo técnico que ya trabaja con Git puede sentirse cómodo con Decap CMS. Un cliente sin perfil técnico necesita una interfaz más sencilla e intuitiva, sin términos como "commit" o "rama". Y si el cliente tiene un flujo de trabajo muy particular, una solución a medida puede adaptarse a él exactamente.
¿Cuánta flexibilidad editorial se necesita? Un proyecto con muchos tipos de contenido relacionados entre sí, con múltiples autores, con necesidad de previsualización antes de publicar o con contenido que debe llegar a varios canales a la vez, se beneficia de una plataforma especializada. Un proyecto con una estructura de contenido simple y estable puede funcionar perfectamente con algo mucho más ligero.
No hay una respuesta universal. Lo que sí es cierto es que la arquitectura headless, en cualquiera de sus formas, separa una responsabilidad que en sistemas como WordPress estaba mezclada: la de gestionar el contenido y la de mostrar ese contenido al mundo. Y esa separación, bien aplicada, hace que los sitios sean más rápidos, más seguros y más fáciles de mantener a largo plazo.
Si estás pensando en migrar tu web a una arquitectura estática o si ya tienes un sitio Jamstack y quieres darle a tu cliente una forma cómoda de editar el contenido, hay opciones para cada situación. En Idenautas trabajamos con distintos enfoques según lo que cada proyecto necesita, desde integraciones con Decap CMS hasta soluciones de edición completamente a medida.
