Economía de WordPress headless en 2026: cuándo compensa y cuándo no
La mayoría de afirmaciones del tipo “con headless recortamos un 70 por ciento el coste de alojamiento” son ficción contable. Cuentan la nueva factura, no el coste de migración que la produjo, e ignoran el tiempo de ingenieros sénior que mantiene en marcha la nueva arquitectura. WordPress headless sí compensa, pero no lo hace de forma automática.
Este artículo describe el marco que usamos con los clientes para decidir antes de que empiece la migración. Es el complemento, desde el lado de quien opera, del servicio de WordPress headless y de la matriz de decisión Next.js o Astro.
El planteamiento es sencillo, pero a menudo se pasa por alto: cambiar de capa de abstracción no es gratis. La pregunta económica es si el ahorro en la nueva capa supera el coste de la mudanza.
¿Vale WordPress headless lo que cuesta?
- Headless reduce el coste de alojamiento del tráfico público al quitar PHP de cada petición.
- Headless añade un coste puntual de migración, dominado por el trabajo de conservación del SEO.
- Headless añade un coste continuo de runtime en el edge que crece con el tráfico.
- En un sitio de contenido, el punto de equilibrio suele llegar en pocos meses. En un sitio muy pequeño, nunca.
- El mayor retorno está en la conversión, no en el coste: las Core Web Vitals generan ingresos.
¿Cuáles son las tres columnas de coste en WordPress headless?
Llamarlo “coste de alojamiento” es el primer error. Hay tres columnas.
Columna uno: infraestructura para el tráfico público. Lo que paga por atender a un visitante. En un monolito WordPress es la factura del alojamiento PHP más la CDN. En headless es el runtime en el edge (por ejemplo, Cloudflare Workers) más un origen WordPress más pequeño que solo atiende a los editores y a la REST API.
Columna dos: construcción y migración. Lo que paga una sola vez para pasar de una arquitectura a otra. Tiempo de ingenieros sénior, conservación del SEO, mapeo de redirecciones, migración de imágenes, formación del equipo de contenido, funcionamiento en paralelo de ambos stacks durante el cambio.
Columna tres: ingeniería continua. Lo que paga cada mes para mantener en marcha la nueva arquitectura. Minutos de CI, actualizaciones del framework, gestión de la cuenta de Cloudflare, monitorización, el coste de tener a un ingeniero de frontend sénior responsable del framework de frontend.
Una comparación seria suma las tres columnas en el mismo horizonte temporal. La mayoría de las afirmaciones de marketing solo suman la columna uno y presentan la diferencia como ahorro.
¿Cuánto cuesta el alojamiento de WordPress headless?
Un monolito WordPress en un alojamiento PHP típico paga capacidad. Tanto si el sitio recibe un visitante como mil, hay un servidor funcionando. La factura es fija. Los costes de CDN crecen con el tráfico. La base de datos, la caché de objetos y la caché de página completa reducen la CPU por petición, pero no la eliminan.
Headless en Cloudflare Workers paga por petición y por milisegundo de CPU. La respuesta con HTML prerenderizado en el edge consume una fracción de milisegundo de CPU. El origen WordPress solo trabaja cuando un editor guarda, cuando salta un webhook o cuando el frontend necesita datos nuevos. Con un tráfico público que consiste sobre todo en lecturas, esto es estructuralmente más barato.
En una tienda WooCommerce el panorama tiene más matices. Las páginas personalizadas y las rutas autenticadas siguen consumiendo CPU en el frontend. Las páginas estáticas del catálogo no. Cuando el catálogo se estabiliza, el reparto suele favorecer igualmente a headless.
¿Por qué la migración es el mayor coste de WordPress headless?
El mayor coste puntual en cualquier proyecto de WordPress headless es la propia migración, en concreto el trabajo de conservación del SEO. Cada uno de los siete patrones descritos en patrones SEO para WordPress headless requiere tiempo. Saltarse cualquiera de ellos cuesta más.
Componentes concretos:
- Mapear todas las URL canónicas existentes.
- Recoger el historial de redirecciones, incluidas las redirecciones silenciosas desde
/wp-contenty los selectores de país. - Llevar los metadatos de Yoast o Rank Math al renderizado del frontend.
- Reconstruir hreflang como HTML autorreferenciado, no solo como JSON.
- Comprobar la paridad de los datos estructurados en los informes de resultados enriquecidos de Search Console.
- Impedir que el antiguo origen WordPress sea visible en el índice de búsqueda.
- Reconstruir el texto alternativo y los datos estructurados de las imágenes para la búsqueda de imágenes.
Una migración que hace bien este trabajo lleva semanas de tiempo de ingenieros sénior. Una migración que no lo hace cuesta meses de recuperación más adelante. Dicho de forma polémica: cada caso de éxito de “ahorramos un 70 por ciento” en el que la empresa también tuvo que “rehacer el SEO a los tres meses” es un caso en el que el coste de migración se pagó dos veces.
¿Cuánto cuesta mantener WordPress headless?
Una implantación headless añade superficie operativa permanente. El CI ya no ejecuta solo actualizaciones de plugins de WordPress, sino también actualizaciones del framework, auditorías de dependencias y pipelines de build del frontend. Hay que revisar el uso de Cloudflare Workers. Hay que monitorizar el comportamiento de la caché en el edge. Hace falta un ingeniero de frontend sénior implicado, cuando un monolito a veces podía operarlo un generalista solo de backend.
En concreto, cuente con:
- Un workflow de CI para el origen WordPress (plugins, temas, core).
- Un workflow de CI para el build y el despliegue del frontend.
- Una capa de observabilidad que cubra el runtime en el edge, los errores de Workers y la salud de la REST API.
- Una persona de guardia para ambos stacks que entienda de verdad la frontera entre ellos.
Este último punto es el que más se infravalora. Hemos auditado migraciones en las que el equipo de ingeniería original se marchó tras el cambio y el siguiente equipo heredó una arquitectura que no sentía como propia. La economía de esa situación es sombría, al margen de los ahorros de la columna uno.
¿Cuándo compensa WordPress headless?
El marco que aplicamos con los clientes es conservador. Modelamos 24 meses y tres columnas, con el perfil de tráfico y el ritmo de publicación como datos de entrada.
Headless suele compensar en menos de 12 meses cuando:
- El tráfico público es lo bastante alto como para que la capacidad del alojamiento PHP sea el cuello de botella.
- Las Core Web Vitals en móvil están ligadas a los ingresos (comercio electrónico, captación de leads).
- El equipo editorial va a seguir usando WordPress y se beneficia del mismo flujo de trabajo.
- Ya hay un ingeniero de frontend sénior en el equipo o contratado durante todo el periodo.
No compensa en 24 meses cuando:
- El tráfico público es bajo y basta con un alojamiento PHP pequeño.
- El ritmo de publicación es bajo (una entrada al mes), así que la velocidad editorial no es un cuello de botella.
- En el sitio predomina una interfaz de producto interactiva que de todos modos necesita SSR e hidratación en el cliente.
- No hay un ingeniero de frontend sénior disponible; el coste de orquestación recae en un generalista.
¿Qué cambia las cuentas del coste de WordPress headless?
Tres factores adelantan el punto de equilibrio más de lo esperado:
Uno, funciones de IA en el edge. Cloudflare Workers AI, los servidores MCP y la personalización renderizada en el edge son baratos en un runtime de Workers y caros (a menudo imposibles) en un alojamiento PHP compartido. Un sitio que quiera ofrecer meta descripciones generadas por LLM, endpoints pensados para agentes o precios por región alcanzará antes el punto de equilibrio de headless.
Dos, la legislación de accesibilidad. La BFSG en Alemania desde junio de 2025, el Acta Europea de Accesibilidad y la ley polaca de accesibilidad penalizan los sitios con frontends lentos y no accesibles. Las auditorías de migración que de todos modos tienen que corregir la accesibilidad a menudo se pagan solas solo con la columna del riesgo legal.
Tres, comercio con IA y descubrimiento por agentes. Como el anillo Trial de nuestro Tech Radar incluye Universal Commerce Protocol, el comercio legible por agentes se convierte en una señal de compra. Las arquitecturas headless exponen los productos como datos de forma más limpia que los monolitos.
Guías relacionadas sobre WordPress headless
Este artículo respalda el servicio de WordPress headless, se complementa con el artículo de patrones SEO, enlaza con nuestra guía de TCO headless o monolito WordPress 2026 para el modelo financiero plurianual y hace referencia a la matriz de decisión Next.js o Astro. El orden de decisión: lea este artículo para saber “si el cambio compensa”; después la guía de TCO para el modelo financiero completo a cuatro años; después los patrones SEO para “cómo mantenemos el posicionamiento”; por último, la decisión de framework para “qué frontend necesita esta carga de trabajo”.
