Qué es un CMS headless
Un CMS headless es un sistema de gestión de contenido cuya única responsabilidad es almacenar y servir contenido vía API. No genera HTML, no impone un theme, no obliga a un stack determinado. El equipo editorial trabaja en un panel cómodo y el contenido viaja a uno o varios frontends que lo renderizan a su manera.
El término “headless” se refiere a que el CMS no tiene “cabeza” (la capa de presentación). Esa parte la pone el frontend, sea Astro, Next.js, Nuxt, SvelteKit, una app móvil o una pantalla de retail.
Diferencia con CMS tradicionales
| Aspecto | CMS tradicional (WordPress, Drupal, Joomla) | CMS headless (Sanity, Contentful, Storyblok) |
|---|---|---|
| Frontend | Ligado al CMS (themes, templates) | Libre, cualquier framework |
| Renderizado | El CMS sirve HTML directamente | API JSON/GraphQL; renderiza el frontend |
| Stack | PHP + MySQL + servidor propio | API gestionada en cloud + frontend a tu elección |
| Velocidad | Limitada por el servidor y el theme | Excelente con frontend estático y CDN |
| Mantenimiento | Actualizar core + plugins + hosting | El CMS lo mantiene el proveedor |
| Plugins | Ecosistema enorme pero arriesgado | Integraciones cleaner por API |
| Curva de entrada | Baja para empezar, alta para escalar | Media inicial, baja a largo plazo |
WordPress puede usarse como headless (vía REST API o WPGraphQL), pero arrastra peso, vulnerabilidades del ecosistema y limitaciones de modelo de datos. Si la opción es headless, conviene partir de un CMS pensado para serlo.
Por qué tiene sentido con Astro
Astro es un framework pensado para sitios donde el contenido es lo principal. Encaja con un CMS headless de forma natural:
- Build estático: el contenido se consulta en build y se sirve como HTML pre-generado.
- Velocidad real: sin servidor PHP, sin caché plugins, sin DB en cada request.
- Type safety: muchos CMS headless ofrecen tipos generados (Sanity, Storyblok) que Astro consume con TypeScript.
- Hosting barato: Cloudflare Pages o Vercel sirven el HTML desde edge global.
- Reutilización: el mismo CMS puede alimentar también app móvil, kiosco o widgets.
Para sitios con contenido frecuente (blog, magazine, catálogo) el patrón es: editor publica en el CMS → webhook dispara un build de Astro → CDN sirve HTML estático. Cuando se necesita más inmediatez, se combina con SSR puntual o ISR.
CMS headless populares
- Sanity: estructura flexible, GROQ como query language, estudio embebible.
- Contentful: el clásico empresarial, API REST y GraphQL, fuerte en gobierno de contenido.
- Storyblok: orientado a marketing, editor visual con preview en vivo.
- Strapi: open source, autoalojable, Node.js.
- Decap CMS (antes Netlify CMS): open source, edita ficheros markdown en Git.
- Hygraph (antes GraphCMS): GraphQL nativo.
- Payload: open source, autoalojable, TypeScript-first.
- Directus: open source sobre cualquier base de datos SQL.
- Prismic: editor “slices” para marketing.
- Cosmic, DatoCMS, Builder.io, Webiny: alternativas según caso de uso.
Casos de uso típicos
- Web corporativa con blog: editores no técnicos publican posts; el sitio se mantiene en Astro o Next.
- E-commerce headless: el catálogo va en Shopify (vía Storefront API) y las landings de campaña en un CMS headless.
- Marketing con landings rápidas: el equipo de marketing crea landings desde un editor visual sin esperar a desarrollo.
- Documentación técnica versionada.
- Multi-país o multi-idioma: contenido centralizado, varios frontends por mercado.
- Apps móviles + web compartiendo el mismo backend de contenido.
Ventajas
- Velocidad y SEO técnico mejores que un CMS tradicional servido por PHP.
- Independencia del proveedor de hosting: el CMS está aparte del frontend.
- Escalabilidad: el frontend es estático en CDN; el CMS solo se llama en builds.
- Equipo editorial cómodo: paneles modernos pensados para no tocar código.
- Sin actualizaciones de core ni plugins críticos: el proveedor del CMS se ocupa.
Desventajas y trade-offs
- Coste mensual del CMS (los planes gratuitos suelen quedarse cortos rápido).
- Curva de aprendizaje para el equipo técnico al modelar contenido en estructuras tipadas.
- Sin “instalar un plugin”: cada integración (newsletter, comentarios, búsqueda) hay que pensarla.
- Dependencia del proveedor SaaS si no eliges una opción open source autoalojable.
- Preview en vivo puede requerir setup extra (preview URLs, draft mode).
Errores típicos
- Modelo de contenido mal pensado al inicio: rehacerlo después es doloroso.
- Usar el CMS como base de datos relacional: no lo es.
- No planificar workflow editorial (borradores, revisión, publicación).
- Forzar headless donde un sitio estático puro con Markdown bastaría.
En IMPERO
Cuando un cliente viene de WordPress y necesita seguir editando contenido sin pisar código, combinamos Astro con un CMS headless adecuado al volumen (Decap, Sanity, Storyblok según caso). El servicio dedicado para esa migración es WordPress a Astro, con redirects, schema y panel editorial listo para el equipo.