Cuándo hacer headless (y cuándo no),
y por qué la mitad son un error.

1. Qué es headless (y qué no)

Un CMS "headless" separa el back (donde se edita contenido) del front (lo que ve el usuario). El back sirve contenido via API (REST o GraphQL) y cualquier front puede consumirlo: web, app nativa, totem, Alexa, etc.

Ejemplos:

• WordPress headless: WP como editor, Next.js/Astro al front.
• Sanity / Storyblok / Contentful: CMS SaaS puros headless.
• Strapi / Directus: CMS self-hosted headless.
• Shopify Hydrogen / Commerce Layer: e-commerce headless.

Lo importante: headless no es una cualidad mágica que te hace ir más rápido. Es una decisión arquitectural con trade-offs concretos.

2. Los trade-offs reales

Lo que ganas

• Performance: si se hace bien, una web headless con SSG (static site generation) es la más rápida que hay. LCP < 1s es normal.
• Multi-canal: el mismo contenido sirve web + app + marketing emails + kiosko.
• Tecnología moderna del front: React/Vue/Svelte/Solid, animaciones avanzadas, interactividad sin friccionar con el CMS.
• Escalabilidad independiente: puedes escalar front y back por separado.
• Seguridad: el CMS no está expuesto al público — reduce superficie de ataque.

Lo que pierdes (y nadie cuenta)

• Complejidad operativa: dos sistemas en vez de uno. Deploy más caro. Debugging más caro. Onboarding de nuevo desarrollador más lento.
• Preview y edición: "editar en vivo" como en WordPress desaparece. Sanity/Storyblok tienen preview modes, pero hay que configurarlos bien o el editor odia la experiencia.
• SEO técnico: Next.js mal configurado genera páginas que no indexan. WordPress con un tema decente indexa solo. Riesgo real, documentado en 2023–2024.
• Formularios y lógica backend: tu landing de contacto necesita un endpoint. ¿Dónde lo montas? ¿Route de Next.js? ¿Serverless function? Complejidad que WordPress con un plugin resuelve en 10 minutos.
• Coste: doble stack = doble coste de hosting + mantenimiento. Normalmente 30–60% más caro operativo que un WordPress equivalente.

3. Cuándo SÍ tiene sentido (criterios reales)

Elige headless si tu proyecto cumple al menos 3 de estos 5 criterios:

1. Multi-canal real: vas a consumir el mismo contenido desde al menos 2 plataformas (web + app móvil, web + tótem, web + emails automatizados masivos).
2. Performance es diferencial de negocio: e-commerce premium, media con monetización por impresiones, SaaS con landing que compite en mercados saturados. Aquí 0.5s de LCP = 10% más conversión.
3. Equipo técnico consolidado: tienes al menos 2 desarrolladores front y 1 backend capaces de mantener el stack. Headless exige skills que un WordPresssmo no cubre.
4. Ciclo editorial espaciado: tu equipo de contenido no edita diariamente. Si edita 20 posts al día, headless con preview pesado les frustra.
5. Identidad visual muy diferenciada: necesitas animaciones scroll-driven, transiciones entre páginas tipo app, experiencias que un tema WordPress no alcanza.

4. Cuándo NO (la mitad de los proyectos headless)

NO elijas headless si tu caso es:

• Blog editorial con equipo no técnico y cadencia diaria. WordPress/Ghost es superior.
• Web corporativa que se edita 2 veces al año. No compensa la complejidad. Mejor estático o WP simple.
• MVP con presupuesto ajustado. El doble stack consume el runway. Haz WordPress/Shopify bien configurado y valida idea antes.
• Equipo técnico de 1 persona. Cuando se va de vacaciones, la web se queda a medias.
• Porque "es más moderno". No es un criterio. Es un meme de LinkedIn.

5. Qué errores hemos visto en auditorías de proyectos headless

Auditamos proyectos ya construidos en headless. Lo más común:

• SSG cuando debería ser SSR o viceversa. Content que cambia cada hora renderizado como estático → caché stale. Content que NUNCA cambia servido por servidor → coste de CPU absurdo.
• N+1 queries a la API del CMS: cada card en una grid hace un fetch individual. Una página tarda 4 segundos en renderizar.
• Hydration mismatches: el HTML servido y el del React no coinciden, React re-renderiza, CLS por las nubes.
• Preview no montado: el equipo editorial no puede ver cambios sin desplegar. Acaban editando con miedo y el headless se convierte en carga.
• Seguridad del CMS olvidada: Strapi o WordPress headless expuesto a internet sin WAF, con admin en /admin. Lo escaneas y sale en 2 minutos.

Conclusión: la pregunta que debes hacerte

Antes de ir headless, responde honestamente:

"Si hubiera que explicárselo a mi próximo desarrollador en 3 meses, ¿el coste de mantener dos stacks se justifica con beneficios concretos que un WordPress/Shopify bien hecho no da?"

Si la respuesta tiene 3+ beneficios concretos, adelante con headless. Si son argumentos del tipo "es más moderno" o "así podremos escalar", mejor replantéatelo: probablemente te estás metiendo en un pozo por moda.