¿Qué es un headless CMS?

«Headless» significa en inglés «sin cabeza»; Merriam-Webster documenta el adjetivo desde antes del siglo XII, con los sentidos de «que no tiene cabeza» y «que no tiene jefe». En un CMS, la cabeza es la capa de presentación. Sanity lo explica con la imagen del cuerpo y la cabeza: el cuerpo es el lugar donde se guarda el contenido, la cabeza el lugar donde se presenta. Un headless CMS conserva el cuerpo y deja la cabeza a otros sistemas, que piden el contenido por API.

Estas fechas marcan el camino de la arquitectura, no el nacimiento de la palabra:

• 2013: según Contentful, Sascha Konietzke y Paolo Negri fundan la empresa.
• 30 de septiembre de 2015: se crea en GitHub el repositorio de Strapi, que el proyecto describe como un headless CMS de código abierto.
• 6 de diciembre de 2016: WordPress 4.7 incorpora al núcleo puntos de acceso de la API REST para entradas, comentarios, términos, usuarios, metadatos y ajustes.
• 24 de enero de 2019: Dries Buytaert, fundador de Drupal, distingue en su blog tres arquitecturas: tradicional (acoplada), desacoplada de forma progresiva y totalmente desacoplada.
• 1 de mayo de 2019: Drupal 8.7 incluye el módulo JSON:API como función estable del núcleo, según el anuncio para construir aplicaciones desacopladas.

El trabajo empieza por el modelo de contenido. Según Contentful, el equipo define primero los tipos de contenido y los campos de cada tipo, por ejemplo un tipo «artículo» con título, texto principal, fecha de publicación y autor, y después crea las entradas. Contentful permite además referencias entre entradas, de modo que el autor puede ser una entrada propia que varios artículos reutilizan.

El contenido sale por una API, normalmente en JSON. Contentful separa dos API principales. La Content Delivery API es de solo lectura, entrega el contenido publicado y los archivos (imágenes, vídeos) y funciona a través de una CDN. La Content Management API lee y escribe: sirve para crear y modificar contenido y devuelve también lo no publicado y todas las traducciones, pero Contentful advierte de que no debe usarse para entregar grandes cantidades de contenido. Strapi ofrece su Content API por REST y GraphQL.

Cuando algo cambia, el CMS puede avisar a otros sistemas con un webhook. Contentful define los webhooks como llamadas HTTP que notifican cambios para que otros sistemas reaccionen, por ejemplo reconstruyendo la web. En Strapi se eligen los eventos por tipo de contenido, como entry.publish.

Como el CMS no genera HTML, el frontend decide dónde y cuándo se renderiza cada página. Astro pre-renderiza por defecto las páginas como archivos estáticos al compilar; según Astro, una página renderizada bajo demanda muestra datos recién cambiados sin reconstruir todo el sitio. Next.js trata por defecto páginas y layouts como Server Components, renderizados en el servidor. Con páginas estáticas, el webhook de publicación pone en marcha la nueva compilación; con renderizado en servidor, el contenido nuevo llega en la siguiente petición. Si todo se monta en el navegador, se trata de renderizado en cliente.

Para la redacción cambia sobre todo la vista previa, porque el CMS no tiene la página final. Contentful ofrece una Preview API con contenido publicado y sin publicar y un token propio; los tokens de producción no funcionan allí, para que no se filtre contenido no publicado. En Next.js, el modo borrador (Draft Mode) deja ver a quien edita cómo quedará el contenido, mientras el resto de visitantes sigue viendo la versión en caché. Storyblok ofrece un editor visual con vista previa en contexto y flujos de borrador, revisión y publicación.

Fuente: documentación y páginas de Contentful, Storyblok, Directus, Payload, Strapi, Decap CMS, WordPress, Drupal y Ghost (consultadas el 15.11.2026).

Las categorías se mezclan. Hygraph pone como ejemplo Strapi Cloud, un servicio en la nube construido sobre código abierto. Cómo funciona WordPress como headless lo explica su entrada.

Contentful describe así la visita a la página de un producto:

• El navegador pide la página al frontend.
• El frontend pide a la API del CMS la entrada de ese producto.
• La API comprueba que la petición está permitida y devuelve la versión publicada como JSON.
• El frontend pasa los datos a su plantilla y envía la página terminada al navegador.

La misma API puede alimentar a la vez una web, una app móvil o una pantalla, cada una con su diseño. Un ejemplo de publicación en un sitio estático: una redactora publica un artículo en Strapi, Strapi envía el evento entry.publish, el servicio de compilación genera de nuevo las páginas con Astro y la CDN sirve la versión nueva.

Que un headless CMS compense depende del caso:

Fuente: Contentful, «Headless CMS explained in one minute»; Sanity, «Headless CMS 101»; Dries Buytaert, «How to decouple Drupal in 2019» (consultados el 15.11.2026).

Dries Buytaert lo resume así: para una organización sobre todo editorial, el desacoplamiento puede ser un problema porque reduce el control de la redacción sobre la presentación.

Fuente: Contentful, apartado «The difference between headless CMS and decoupled CMS»; Sanity, «Headless CMS 101»; Dries Buytaert, «How to decouple Drupal in 2019»; documentación de Ghost (consultados el 15.11.2026).

Los términos no se usan de forma uniforme: Contentful escribe que algunos los usan como sinónimos, aunque no son idénticos, y Sanity que a menudo se intercambian. En Drupal, lo que ambos llaman headless se llama «totalmente desacoplado».

La comparación básica entre un CMS tradicional y uno headless está en la entrada de CMS. El mismo principio aplicado a la tienda es el headless commerce: el CMS headless gestiona contenidos, el motor de comercio, la lógica de venta.

Fuente: páginas, documentación y licencias de cada fabricante (consultadas el 15.11.2026). Orden alfabético, sin valoración.

El frontend no viene incluido: Contentful escribe que siempre es responsabilidad del cliente. Sanity, que vende un headless CMS, reconoce que eso puede subir el coste inicial y la complejidad y que depender del equipo de desarrollo puede frenar los cambios. Funciones que un CMS clásico trae de fábrica, como la edición sobre la página o los diseños por bloques, hay que volver a construirlas; Dries Buytaert advierte de que puede ser lento y caro.

En los servicios en la nube, el uso de la API tiene límites según el plan. Contentful fija llamadas por segundo y por espacio: en sus planes de pago, 78 a la Delivery API y 10 a la Management API. Hygraph afirma que hay menos dependencia del proveedor porque el contenido vive en un formato entregado por API; es una afirmación del fabricante.

Por sí mismo, un headless CMS no resuelve el SEO. Title, meta description, canonical, hreflang y sitemap tienen que existir como campos del modelo y el frontend tiene que escribirlos en el HTML. Google recuerda que el renderizado en servidor o el pre-renderizado siguen siendo buena idea, porque aceleran la web y no todos los bots ejecutan JavaScript. Cómo lo resolvimos nosotros con un CMS headless y Astro está en nuestro artículo sobre headless CMS y SEO.

• Cuenta los canales que van a usar el contenido antes de decidir la arquitectura.
• Define el modelo de contenido antes que el diseño: tipos, campos y referencias.
• Incluye en el modelo campos para title, meta description, canonical e idioma.
• Decide para cada tipo de página si se genera al compilar, en el servidor o en el navegador.
• Monta la vista previa al principio, con la API de vista previa o el modo borrador del frontend.
• Conecta el webhook de publicación con la compilación o con la caché.
• Comprueba cómo se exportan contenidos y modelo antes de elegir proveedor.

• Separa los tokens: uno de entrega para producción y otro distinto para la vista previa.
• Sirve el contenido público con la API de entrega y deja la de gestión para escribir.
• Filtra los webhooks por entorno, para que un cambio de pruebas no reconstruya producción.

• Servir la web pública con la Management API.
• Poner el token de vista previa en el código que llega al navegador.
• Renderizar todo en el navegador y dar por hecho que todos los bots lo verán.
• Elegir headless para una web pequeña con mucha redacción y casi nadie de desarrollo.

Esta entrada se redactó en noviembre de 2026 con ayuda de IA. Los datos proceden de la documentación y las páginas de los fabricantes, de las notas de versión de WordPress y Drupal, del blog de Dries Buytaert, de la documentación de Astro, Next.js y Google y del diccionario Merriam-Webster. Se revisó antes de publicarse y no contiene datos de clientes.