CMS headless vs CMS tradicional: qué es un CMS headless, cuándo conviene y cuánto cuesta en Colombia

La respuesta corta

Un CMS headless es un gestor de contenido que guarda y edita el contenido pero no dibuja las páginas: lo entrega por una API, y un sitio aparte, construido por desarrolladores, lo convierte en páginas. Un CMS tradicional, como WordPress, hace las dos cosas: guarda el contenido y lo muestra con una plantilla.

Elige un CMS tradicional si un equipo pequeño edita un solo sitio, no hay un desarrollador disponible y quieres vista previa, formularios y campos de SEO desde el primer día. Elige headless si el mismo contenido alimenta varios sitios o una app, si ya tienes desarrolladores a cargo del front end o si necesitas controlar la velocidad y la seguridad más de lo que permiten una plantilla y sus plugins. Headless no es más rápido por sí solo: en Colombia, en septiembre de 2026, el 24,7% de los sitios con WordPress aprobó los Core Web Vitals en el celular, y solo el 16,0% de los sitios con Contentful.

¿Qué es un CMS headless y qué es uno tradicional?

El Web Almanac 2025 lo resume así: un CMS headless o componible separa la gestión del contenido del sitio o la app que lo muestra.

• CMS tradicional (acoplado). Una sola aplicación tiene la base de datos, el panel de edición, las plantillas y el código que arma cada página. WordPress, Drupal y Joomla funcionan así. Quien edita ve la página casi como la verá el visitante, y los plugins agregan funciones al panel y al sitio público.
• CMS headless. El CMS guarda contenido estructurado (títulos, campos, texto enriquecido, imágenes, relaciones) y lo entrega en JSON. El sitio es un proyecto aparte, hecho con frameworks como Astro o Next.js, que lee el contenido al compilar o en cada visita. El mismo contenido puede alimentar una app, un segundo sitio o un correo. Sanity, Contentful, Storyblok, Strapi y Payload son ejemplos.
• El punto medio. WordPress también puede funcionar como headless: su API REST entrega entradas, páginas y taxonomías en JSON. Y al revés, los CMS headless ya ofrecen edición visual sobre la página real.

dardo.studio es headless: un front end en Astro sobre Cloudflare Workers, con el contenido en EmDash, un CMS de código abierto que Cloudflare publicó en versión 1.0 el 28 de septiembre de 2026.

Cuántos sitios usan cada uno en Colombia y México, y qué tan rápidos son

Consultamos el informe de tecnologías del HTTP Archive para septiembre de 2026, el mes más reciente. Combina datos de visitas reales del Chrome UX Report con su rastreo mensual. Estos son los sitios de Colombia, medidos en celular:

Fuentes: API del HTTP Archive, adopción, Core Web Vitals y peso de página, consultadas el 21 de octubre de 2026.

Lo que muestran estos datos:

• Headless sigue siendo raro en Colombia. WordPress aparece en el 29,3% de los sitios medidos; los cuatro CMS headless de la tabla, más DatoCMS (52 sitios), suman 991, menos del 2,5% de los sitios con WordPress. La cifra subestima a los headless, porque se detectan por las direcciones de sus imágenes y archivos, y los que se instalan en servidor propio casi no aparecen.
• Los sitios headless cargan más JavaScript, no menos. Todos los CMS headless de la tabla superan la mediana de WordPress, porque muchos front ends headless son aplicaciones de React. Las muestras pequeñas (95 sitios con Storyblok) piden prudencia, pero la tendencia es la misma en México, donde aprueba el 31,6% de los sitios con WordPress y el 22,2% de los que usan Contentful.
• El front end decide. En Colombia, los sitios hechos con Astro aprueban el 46,0% de las veces, con cualquier CMS detrás. Nuestro informe de velocidad por plataforma tiene las cifras por país, y el artículo sobre Core Web Vitals en Latinoamérica explica por qué el celular sale peor.

¿Cuál le sirve a tu equipo?

Si casi todas tus respuestas quedan en la primera columna, te conviene un CMS tradicional o un constructor como Webflow o Framer; lee Webflow o WordPress. Si quedan en la segunda, la pregunta pasa a ser cuál CMS headless: lo comparamos en Sanity vs Contentful vs Payload.

Cuánto cuesta mantener cada uno durante tres años

Tomamos un sitio de marketing de 40 páginas con blog, cinco personas que editan y dos idiomas. Solo suscripciones y hosting, a precios de lista consultados el 21 de octubre de 2026, sin impuestos. Los precios en dólares se convierten con la TRM vigente el 21 de octubre de 2026, COP 3.163,76 por dólar:

Fuentes: Hostinger Colombia, WordPress.com, Sanity, Cloudflare Workers, Storyblok, Strapi Cloud y Contentful.

Lo que la tabla no muestra:

• Las promociones se acaban. El plan Premium de Hostinger cuesta COP 6.900 al mes solo si pagas 48 meses de una vez; al renovar pasa a COP 29.900. En México, el mismo plan cuesta MXN 1,679.52 por 48 meses y renueva a MXN 149.99 al mes, y un proveedor mexicano como Neubox publica su plan WordPress Master en MXN 89.90 más IVA al mes.
• Los planes gratis tienen letra pequeña. El plan Free de Sanity trae 20 puestos pero solo dos roles, así que todo el que edita es administrador. Strapi y Payload son gratis si los instalas en tu servidor, pero pagas el servidor, la base de datos y las horas de actualizarlos; Payload pausó los proyectos nuevos en su nube desde que se unió a Figma.
• El front end también se aloja. En Cloudflare Workers las páginas estáticas son gratis e ilimitadas; el plan Pro de Vercel empieza en USD 20 al mes.
• Dos idiomas en WordPress suelen costar. Sanity incluye idiomas ilimitados y Storyblok dos en Growth; WordPress normalmente necesita un plugin, y el plan Multilingual CMS de WPML cuesta EUR 99 por un año de actualizaciones.

Las suscripciones casi nunca deciden el presupuesto. Un sitio tradicional parte de una plantilla; uno headless necesita diseñar y programar su front end, que es la mayor parte del costo. Después del lanzamiento, WordPress pide actualizar plugins y núcleo con frecuencia: Patchstack, una empresa de seguridad para WordPress, contó 11.334 vulnerabilidades nuevas en el ecosistema WordPress en 2025, el 91% en plugins y solo 6 en el núcleo. Un sitio headless cambia eso por actualizaciones del framework y alguien responsable del código. Nuestro cotizador de páginas web muestra lo que sugieren los precios publicados en Colombia y México, y la guía de costos de mantenimiento reúne lo que cobran las agencias colombianas por mantener WordPress.

Qué gana y qué pierde quien edita

En un CMS tradicional, se trabaja sobre algo muy parecido a la página real. Se puede agregar una sección, mover una galería o armar una landing con un constructor de páginas, y verla antes de publicar. El Web Almanac estima que cerca del 60% de los sitios con WordPress usan un constructor, sobre todo Elementor. El precio es la consistencia: si cualquiera diseña cualquier cosa, el sitio se desordena, y cada constructor suma su propio código.

En un CMS headless, se llenan campos: un título, un resumen, una lista de beneficios, un caso relacionado. El diseño sale de componentes que hicieron los desarrolladores. El sitio se mantiene consistente y el mismo contenido sirve en varios lugares, pero sin una buena vista previa se siente como llenar un formulario. Hoy casi todos la ofrecen:

• La edición visual de Sanity muestra el borrador en el sitio real, con clic para editar y secciones que se arrastran.
• El Visual Editor de Storyblok carga el sitio dentro del editor, en todos sus planes.
• El Live Preview de Payload carga el front end en un iframe y lo actualiza mientras escribes.
• Del lado del front end, Astro puede renderizar una sola ruta de vista previa a pedido mientras el resto del sitio sigue estático. En dardo.studio, el botón Preview del CMS abre esa ruta con un token firmado de corta duración; es la única página que se genera en cada visita.

La vista previa es trabajo de desarrollo, y es donde los proyectos headless flojos le fallan a quien edita. Pide verla funcionando antes de aprobar la entrega.

Qué cambia para el SEO

Google no sabe ni le importa qué CMS usas: ve el HTML que entrega tu front end. En la práctica cambian cinco cosas:

1. Cómo se generan las páginas pasa a ser tu decisión. Un front end headless puede generar las páginas al compilar, en cada visita o en el navegador. La guía de JavaScript y SEO de Google recomienda el renderizado en servidor o previo porque no todos los bots ejecutan JavaScript. Evita los front ends que solo arman la página en el navegador.
2. Los campos de SEO hay que modelarlos. En WordPress, un plugin agrega título, descripción, canónica, noindex e imagen para redes a cada entrada. En un CMS headless esos campos existen solo si alguien los crea, y el front end tiene que escribirlos en la página. El sitemap y las redirecciones también pasan a ser código.
3. El contenido estructurado facilita los datos estructurados. Si el autor, la fecha, las preguntas frecuentes y los precios son campos separados, escribirlos en JSON-LD, el formato que recomienda Google, es cuestión de mapearlos.
4. La vista previa y el staging no deben indexarse. Necesitan noindex o contraseña.
5. Rehacer el front end es una migración. Cambian plantillas y a veces URL. Mapea cada dirección vieja y redirígela con un 301; la guía para migrar sin perder posicionamiento explica cómo.

Qué implica pasar de WordPress a un CMS headless

• El modelo de contenido. Haz la lista de tipos de contenido y campos (entradas, páginas, equipo, casos, campos personalizados) y decide qué se vuelve campo estructurado y qué sigue como texto enriquecido.
• El texto enriquecido. WordPress guarda el cuerpo de las entradas en HTML con comentarios de bloques; cada CMS headless usa su propio formato. Los shortcodes y el código de los constructores hay que limpiarlos o rehacerlos.
• Las imágenes. Copia los originales, no las versiones reducidas, y conserva el texto alternativo.
• Metadatos de SEO y URL. Exporta títulos y descripciones del plugin de SEO, conserva las URL que traen visitas y redirige el resto. La guía para migrar de WordPress a Astro cubre los dos pasos.
• Lo que hacían los plugins. Formularios, buscador, comentarios y boletín necesitan su propio servicio.
• El primer paso barato. Deja WordPress como CMS y construye solo un front end nuevo sobre su API REST. Quien edita conserva su panel y el contenido puede moverse después.

En cuánto cuesta migrar una página web están los precios publicados para este tipo de cambio.

Cuándo no vale la pena

• Un solo sitio, un equipo pequeño y nadie que programe. Pagarías por construir y mantener un front end que no necesitas. Un WordPress bien cuidado, o Webflow o Framer, es mejor negocio.
• Quien edita rehace diseños cada semana. Un CMS headless puede hacerlo con edición visual, pero un constructor de páginas lo resuelve con menos montaje.
• Solo editan desarrolladores. Archivos Markdown en el repositorio pueden ser todo el CMS que necesitas.
• El problema es una plantilla lenta. Arreglar la plantilla, las imágenes y los scripts cuesta menos que una arquitectura nueva; ¿WordPress o web a medida? te ayuda a decidir.

Qué hacer ahora

Anota quién edita, dónde se usará el contenido y quién se hará cargo del código, y estima la construcción con el cotizador. Si la respuesta es headless, compara opciones en Sanity vs Contentful vs Payload. En Dardo construimos sitios headless y su edición a través de nuestro servicio de desarrollo con CMS headless; para proyectos más amplios, mira desarrollo web.