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. Los proyectos Shopify puros se presupuestan con un desarrollador Shopify, no como un añadido al presupuesto WordPress.
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.
Precios de Cloudflare Workers para un frontend de WordPress headless
Cloudflare publica sus tarifas en la página de precios de Workers. El nivel gratuito permite 100 000 peticiones al día y 10 milisegundos de CPU por invocación. Workers Paid tiene un cargo mínimo de 5 USD al mes por cuenta. En el modelo de facturación estándar incluye 10 millones de peticiones y 30 millones de milisegundos de CPU al mes. Cada millón adicional de peticiones cuesta 0,30 USD y cada millón adicional de milisegundos de CPU, 0,02 USD.
Para las cuentas de headless, dos frases de esa documentación importan más que las tarifas. La primera: las peticiones a recursos estáticos son gratuitas e ilimitadas. El HTML prerenderizado desplegado como recurso estático no genera, por tanto, cargo por petición, y solo se facturan las rutas que ejecutan código del Worker: búsqueda, formularios, carrito, vista previa de borradores. La segunda está en la página de límites: la espera de red, es decir, las llamadas fetch(), las lecturas de KV y las consultas a la base de datos, no cuenta como tiempo de CPU. Un Worker que pide datos a la REST API de WordPress y espera la respuesta del origen paga su propio cómputo, no un origen lento.
Los límites de CPU deciden el nivel. En el gratuito, una invocación HTTP tiene 10 ms de CPU. En Workers Paid, el valor predeterminado es de 30 segundos por petición y se puede ampliar hasta 5 minutos. La diferencia pesa en el SSR, porque cada renderizado bajo demanda tiene que caber en ese presupuesto. Un frontend totalmente estático sirve recursos estáticos gratuitos y nunca toca el límite de CPU.
Rebuild completo o ISR en WordPress headless
El coste de actualizar contenido cae en uno de dos sitios: en el momento del build o en el momento de la petición.
Con un build estático completo, cada publicación en WordPress dispara un webhook y un build nuevo. Los límites de Cloudflare Pages muestran dónde están los techos: 500 builds al mes en Free, 5000 en Pro y 20 000 en Business, con un build a la vez en Free, cinco en Pro y veinte en Business. Un build se corta a los 20 minutos. Free admite hasta 20 000 archivos por sitio y los niveles de pago hasta 100 000. Una redacción que guarda cambios 20 veces al día, con un build tras cada guardado, necesita unos 600 builds al mes, es decir, más de los que ofrece Free. Un sitio multilingüe con miles de entradas e imágenes puede llegar, en cambio, al límite de archivos. Los dos techos se pueden sortear, por ejemplo agrupando builds o dejando las imágenes fuera del despliegue, pero es trabajo que hay que planificar en la columna dos, no descubrir después del lanzamiento.
Incremental Static Regeneration en Next.js traslada ese coste al momento de la petición. La documentación de ISR describe dos modos: actualización por tiempo con revalidate y actualización bajo demanda con revalidatePath o revalidateTag, que un webhook de WordPress puede llamar al guardar una entrada. La misma página enumera limitaciones que cambian la factura. ISR solo funciona con el runtime de Node.js y no con la exportación estática. Con varias instancias, la caché predeterminada en el sistema de archivos es independiente para cada una, y la actualización bajo demanda solo invalida la instancia que recibe la llamada, así que hace falta un cache handler compartido. La regeneración en segundo plano se ejecuta en la instancia que atendió la petición y, en plataformas con facturación por petición, cuenta como cómputo adicional. ISR ahorra builds, pero añade infraestructura y una partida de cómputo. El build completo sigue siendo más sencillo mientras quepa en los límites.
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.
Qué necesita todavía el origen WordPress después de pasar a headless
El origen se reduce, pero no desaparece. Los requisitos de WordPress son los mismos que en un monolito: se recomienda PHP 8.3 o superior, MySQL 8.0 o MariaDB 10.11 o superior y soporte de HTTPS. Cambia el perfil de carga, no la lista de tareas. El servidor sigue necesitando actualizaciones, copias de seguridad y monitorización, solo que atiende a los editores y al build en lugar de a los visitantes.
El build obtiene el contenido a través de la REST API, y eso tiene su propia aritmética. La documentación de paginación limita per_page a 100 registros, y las cabeceras X-WP-Total y X-WP-TotalPages devuelven el número de registros y de páginas. Un build completo de un sitio con 10 000 entradas supone, por tanto, al menos 100 peticiones solo para el listado de entradas, antes de páginas, categorías, medios y cada versión de idioma adicional. Un origen que responde despacio con esa carga alarga cada build, y un build en Cloudflare Pages tiene 20 minutos para todo.
La vista previa de borradores exige autenticación. El manual de la REST API limita la autenticación por cookie a las peticiones hechas desde el propio WordPress, así que un frontend externo usa contraseñas de aplicación (Application Passwords). Están en el núcleo desde la versión 5.6 y llegan a la REST API por HTTPS como Basic Auth. Una contraseña de aplicación es un secreto más que guardar en la configuración del Worker y que rotar periódicamente, es decir, una partida más en la columna tres.
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.
La condición sobre las Core Web Vitals solo se puede comprobar midiendo antes y después de la migración. web.dev fija los umbrales de un buen resultado: LCP en 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos, medidos en el percentil 75 de las cargas de página, por separado en móvil y escritorio. Si el sitio ya cumple esos umbrales como monolito, el argumento de la conversión pierde fuerza y las cuentas tienen que sostenerse en las demás columnas.
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. En España, el Acta Europea de Accesibilidad se transpuso con la Ley 11/2023, de 8 de mayo, cuyo título I regula en su capítulo XI (artículos 27 a 31) las autoridades de vigilancia y el régimen sancionador; si vendes a Alemania, se suma la BFSG, vigente desde junio de 2025. Ambas prevén sanciones para los sitios con frontends no accesibles, en el ámbito que se describe más abajo. 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.
A quién se aplica el Acta Europea de Accesibilidad
El argumento legal de la sección anterior solo vale donde la norma se aplica. La Directiva (UE) 2019/882 cubre los servicios prestados a consumidores después del 28 de junio de 2025, entre ellos los servicios de comercio electrónico. La directiva los define como servicios prestados a distancia, a través de sitios web y servicios para dispositivos móviles, por vía electrónica y a petición individual de un consumidor, con vistas a celebrar un contrato con el consumidor. El artículo 4, apartado 5, exime de los requisitos de accesibilidad a las microempresas que prestan servicios. Una microempresa, según la directiva, ocupa a menos de 10 personas y tiene un volumen de negocios anual o un balance general anual que no supera los 2 millones de euros.
De ahí sale un reparto sencillo. Una tienda online por encima del umbral de microempresa tiene la columna del riesgo legal sea cual sea su arquitectura, y la migración es el momento en que las correcciones de accesibilidad entran de todos modos en el frontend. Una microempresa, o un sitio que no vende a consumidores y no presta ninguno de los otros servicios que enumera la directiva, no tiene esa columna, y en su caso el argumento legal no acelera el retorno. Es la misma conclusión que en la sección sobre cuándo headless no compensa: a los sitios pequeños les faltan, en el lado del ahorro, las partidas que cubrirían el coste de la migración.
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”.
