Headless CMS: cuándo tiene sentido y cuándo complica más de lo necesario

En los últimos años, la arquitectura headless se ha popularizado mucho entre equipos de desarrollo. La idea es seductora: separas el backend de contenido (el CMS) del frontend (la web), y cada parte puede evolucionar independientemente. Puedes servir el mismo contenido a la web, la app móvil, un quiosco digital o cualquier canal. Pero la realidad es que para muchos proyectos —especialmente pymes y startups en fase temprana— un headless CMS añade complejidad operativa y coste de mantenimiento que no se justifica con los beneficios.

Cuándo un headless CMS realmente aporta valor

Un headless CMS tiene sentido cuando el proyecto tiene necesidades que un CMS tradicional (WordPress, Drupal) no puede satisfacer eficientemente. El caso más claro es el multicanal: si tu contenido debe aparecer en la web, en una app móvil iOS/Android, en un smartTV y en una API pública, gestionarlo todo desde un WordPress es una pesadilla. Con un headless CMS (Contentful, Sanity, Strapi) el contenido se define una vez y se distribuye via API a todos los canales.

El segundo caso es la escala editorial: si tu equipo de contenido publica 50+ artículos al día, necesita flujos de trabajo complejos (aprobación multinivel, programación, localización), o trabaja en múltiples idiomas, las herramientas editoriales de un headless CMS profesional superan claramente las de un WordPress estándar.

El tercer caso es el rendimiento extremo: combinado con un framework de frontend moderno (Nuxt.js, Next.js, Astro) y una estrategia de generación estática, un headless CMS permite conseguir webs con puntuaciones de 99/100 en Lighthouse que serían imposibles con un WordPress con plugins.

• Headless TIENE SENTIDO cuando: el contenido se debe servir a múltiples canales (web + app + API pública).
• Headless TIENE SENTIDO cuando: el equipo editorial es grande y necesita flujos de trabajo complejos.
• Headless TIENE SENTIDO cuando: el rendimiento es una ventaja competitiva directa (e-commerce de alto volumen, media).
• Headless TIENE SENTIDO cuando: el frontend necesita tecnología muy específica incompatible con WordPress.
• Headless NO TIENE SENTIDO cuando: el proyecto es una web corporativa estándar con menos de 10 actualizaciones de contenido al mes.
• Headless NO TIENE SENTIDO cuando: el equipo de contenido no es técnico y necesita una experiencia de edición simple.
• Headless NO TIENE SENTIDO cuando: el presupuesto es limitado —la infraestructura de un headless setup es más cara y compleja de mantener.
• Headless NO TIENE SENTIDO cuando: no hay un equipo de frontend dedicado. Sin este equipo, los cambios de diseño se convierten en proyectos largos y costosos.

Opciones headless y su coste real de propiedad

El coste de un headless CMS no es solo la licencia. Debes sumar el coste del CMS (Contentful Basic: gratuito hasta un límite, Pro: 300€/mes; Sanity: gratuito con límites, Business: desde 100€/mes; Strapi: open source pero necesita servidor), el coste del hosting del frontend (Vercel, Netlify, o tu propio servidor), y el coste de mantenimiento y actualización.

Para comparar: un WordPress bien optimizado en hosting de calidad (15-30€/mes) con Elementor Pro o un tema personalizado cubre el 90% de los casos de webs corporativas. La diferencia de velocidad y flexibilidad raramente justifica el coste adicional para proyectos de menos de 50.000€ de presupuesto total.

Si el proyecto requiere escala editorial o multicanal real, headless suma mucho. Si no, suele ser una capa técnica innecesaria que consume presupuesto que podría ir a SEO o contenido.