Tu agencia te ha propuesto WordPress headless. O lo has leído en un hilo de Twitter y ahora te preguntas si tu web debería hacer lo mismo. El argumento suena bien: separar el frontend del backend, velocidad extrema, libertad total de tecnología.
Lo que nadie te cuenta es que esa libertad tiene un precio. Y no es solo económico: es de complejidad operativa, de tiempo de desarrollo y de coste de mantenimiento a largo plazo. Headless no es mejor que WordPress tradicional. Es diferente. Y para la mayoría de proyectos, la diferencia no justifica el coste.
Este post no es una defensa de WordPress clásico ni una crítica a headless. Es un mapa para que tomes la decisión correcta para tu proyecto concreto, sin dejarte llevar por el hype ni por la inercia de lo que ya conoces.
Qué es WordPress headless y qué cambia realmente
En una instalación de WordPress tradicional, el mismo sistema gestiona el contenido y lo muestra al visitante. El frontend y el backend están acoplados: WordPress genera el HTML que ve el usuario.
En una arquitectura headless, WordPress actúa solo como gestor de contenido (CMS). El frontend — lo que ve el usuario — está construido con una tecnología separada: React, Next.js, Astro, Nuxt… lo que sea. WordPress expone el contenido a través de su API REST o de GraphQL (con el plugin WPGraphQL), y el frontend lo consume para construir las páginas.
Las ventajas reales de este enfoque son tres: mayor control del frontend, posibilidad de usar el mismo CMS para múltiples frontends (web, app, quiosco), y rendimiento potencialmente superior si el frontend está bien construido.
Las desventajas también son reales: mayor complejidad de desarrollo, pérdida de compatibilidad con plugins que asumen el frontend acoplado, y un coste de mantenimiento más alto. Si tu proyecto necesita desarrollo web a medida con un nivel alto de especificidad técnica, headless puede ser la respuesta. Si no, probablemente no.
Cuándo WordPress headless es la respuesta correcta
Hay escenarios en los que headless no es una decisión de moda sino la solución técnicamente correcta. Reconocerlos evita tanto elegirlo por exceso como descartarlo por inercia.
Cuándo WordPress headless es un error caro
El problema con headless no es la arquitectura en sí. El problema es aplicarla a proyectos donde añade complejidad sin resolver un problema real.
Si tu web es informativa, tiene menos de 50 páginas y el equipo de contenido es la prioridad de uso, headless es sobredimensionar. Los plugins de WordPress que facilitan la vida del editor (constructores de página, gestión de medios, flujos de publicación) dejan de funcionar o requieren alternativas costosas de implementar.
Antes de entrar en el detalle de este gestor conviene tener claro cuándo una arquitectura headless tiene sentido de verdad, sea cual sea la tecnología. Si el proyecto está en fase de validación — todavía estás probando si el modelo de negocio funciona — añadir la capa de complejidad de headless es un riesgo innecesario. Primero valida, luego escala la arquitectura.
Si el equipo que va a mantener la web no tiene perfil frontend avanzado, headless implica dependencia de un perfil técnico externo para cada cambio mínimo. Eso es un coste operativo que rara vez se calcula en el presupuesto inicial.
| Criterio | WordPress tradicional | WordPress headless |
|---|---|---|
| Coste de desarrollo inicial | Menor | 30–60% más alto |
| Velocidad de lanzamiento | Semanas | Semanas o meses extra |
| Rendimiento (bien implementado) | Bueno | Excelente |
| Compatibilidad con plugins | Total | Limitada — muchos no funcionan |
| Experiencia del editor de contenido | Familiar y completa | Reducida o requiere configuración extra |
| Coste de mantenimiento | Predecible | Mayor — requiere perfil técnico más especializado |
| ¿Cuándo elegirlo? | Webs informativas, blogs, tiendas estándar, equipos sin perfil técnico avanzado | Plataformas multicanal, tráfico alto, lógica de frontend compleja, equipo con perfil React/Next |
La pregunta que decide el 80% de los casos
¿El problema que intentas resolver es un problema de frontend o un problema de CMS? Si es de frontend, headless puede ser la respuesta. Si es de CMS, probablemente hay una solución más sencilla.
La mayoría de proyectos que llegan a nosotros con «queremos headless» en realidad tienen un problema de rendimiento que se puede resolver optimizando el WordPress actual, o un problema de diseño que se puede resolver con un tema a medida bien construido sin necesidad de separar los sistemas.
Headless es la respuesta correcta cuando el frontend tiene requisitos que WordPress acoplado no puede cumplir de forma razonable. No cuando parece más moderno o cuando la agencia propone más horas de desarrollo.
Tip técnico: Medir el rendimiento antes de decidir la arquitectura
Antes de migrar a headless por razones de rendimiento, ejecuta un análisis de Core Web Vitals con datos reales de campo (no solo laboratorio). El informe de experiencia de usuario de Chrome (CrUX) y PageSpeed Insights con datos de campo te dicen si el problema de rendimiento es real y en qué consiste exactamente. En muchos casos, el LCP alto se resuelve con lazy loading y optimización de imágenes, y el INP elevado con reducción de JavaScript bloqueante — sin tocar la arquitectura. Si tras la optimización el rendimiento sigue siendo inaceptable para el tráfico que recibes, entonces la conversación sobre headless está justificada.
Checklist para decidir si headless tiene sentido en tu proyecto
- ¿Tu plataforma necesita servir el mismo contenido a más de un canal (web, app, otros)?
- ¿El rendimiento actual afecta de forma medible a la conversión o al posicionamiento?
- ¿El equipo técnico que va a mantener el proyecto tiene experiencia real con React o Next.js?
- ¿Tienes presupuesto para cubrir el 30–60% de sobrecoste en desarrollo y el mayor coste de mantenimiento?
- ¿Las funcionalidades de WordPress que usáis actualmente son compatibles con headless o tenéis alternativas concretas?
- ¿El proyecto está validado y tiene un roadmap claro, o todavía estáis probando el modelo?
Si has respondido que sí a la mayoría, headless puede ser la decisión correcta. Si hay dudas en más de tres preguntas, merece la pena explorar primero si un WordPress optimizado a medida resuelve el problema sin añadir complejidad innecesaria.
Preguntas frecuentes sobre WordPress headless
¿WordPress headless es más rápido que WordPress tradicional?
Puede serlo, pero no automáticamente. El rendimiento en headless depende de cómo está construido el frontend. Un Next.js mal optimizado puede ser más lento que un WordPress bien configurado con caché. La arquitectura no garantiza el rendimiento — la implementación sí.
¿Puedo usar todos los plugins de WordPress en una arquitectura headless?
No. Muchos plugins asumen que WordPress controla el frontend y no funcionan correctamente en headless. Plugins de constructores de página (Elementor, Divi), de popup, de checkout visual y algunos de SEO tienen limitaciones importantes. Antes de migrar, audita los plugins que usas y verifica la compatibilidad uno a uno.
¿Cuánto más cuesta desarrollar una web con WordPress headless?
Aproximadamente entre un 30% y un 60% más que un WordPress tradicional de complejidad equivalente, dependiendo del equipo y la tecnología de frontend elegida. El sobrecoste no está solo en el desarrollo inicial: el mantenimiento continuo también es más caro porque requiere perfiles con conocimiento de dos stacks en lugar de uno.
¿Qué tecnología de frontend se usa habitualmente con WordPress headless?
Next.js es actualmente el estándar más extendido por su equilibrio entre rendimiento (Static Site Generation, Incremental Static Regeneration) y flexibilidad. Astro es una alternativa interesante para proyectos con contenido más estático. La elección depende del perfil del equipo y de los requisitos de interactividad del frontend.
