WordPress «headless» es una buena opción si tu sitio web corporativo debe ser muy rápido, estar conectado a varios canales o contar con una interfaz de usuario avanzada. Para un sitio web corporativo clásico, suele resultar demasiado costoso. El principio: WordPress sigue siendo la herramienta de gestión de contenidos, pero la visualización pública se confía a otra tecnología, como Next.js o Astro.
¿Qué es, concretamente, WordPress headless?
Un sitio web tradicional de WordPress reúne dos funciones en un mismo sistema: la administración, donde tus equipos redactan los contenidos, y el tema, que muestra las páginas a los visitantes. Con WordPress «headless», se separan estas dos partes. WordPress se convierte en el back-end (la parte invisible que almacena y organiza los contenidos), mientras que un front-end independiente muestra el sitio web.
Este front-end se puede desarrollar con Next.js, un marco de trabajo de JavaScript vinculado a React, o con Astro, un marco de trabajo muy apreciado por generar páginas rápidas y ligeras. Los contenidos se recuperan a través de una API, es decir, una interfaz de programación de aplicaciones estructurada que permite que dos programas se comuniquen entre sí. Desde WordPress 4.7, publicado en 2016, la API REST está integrada en el núcleo de WordPress y, entre otras cosas, expone los contenidos a través de la dirección /wp-json/wp/v2/.
También se puede utilizar GraphQL, un lenguaje de consulta que permite solicitar con precisión los datos necesarios. El plugin de código abierto WPGraphQL añade esta funcionalidad a WordPress. Otras herramientas, como Faust.js, facilitan los proyectos «headless» de WordPress con Next.js al gestionar aspectos muy prácticos: vista previa de las entradas, autenticación, componentes de bloques y jerarquía de plantillas.
En pocas palabras: tus redactores siguen trabajando en WordPress, pero tus visitantes ya no ven un tema clásico de WordPress. Lo que ven es una página web generada o mostrada por una aplicación front-end independiente.
¿Por qué algunas empresas eligen Headless WordPress?
El primer beneficio que se busca suele ser el rendimiento. Un front-end moderno puede generar páginas estáticas, que se sirven muy rápidamente a través de una CDN (red de servidores distribuidos geográficamente), con menor dependencia del servidor de WordPress en cada visita. Para un sitio editorial, una marca con mucho contenido o una página de destino con mucho tráfico, esta mejora puede ser importante.
La seguridad es otro argumento, pero hay que matizarlo. Dado que la página web pública ya no depende directamente del tema WordPress, se reducen algunas superficies de ataque. No obstante, WordPress sigue presente en el panel de administración, con sus usuarios, plugins y actualizaciones. Una contraseña débil o un plugin vulnerable siguen suponiendo un riesgo.
El enfoque «headless» también resulta interesante cuando un mismo contenido debe alimentar varios canales: sitio web, aplicación móvil, blog, extranet, área de socios. WordPress sirve como CMS central. Esta lógica coincide con la de las arquitecturas desacopladas que presentamos en nuestro Guía sobre los CMS «headless», pero con la ventaja de seguir utilizando una herramienta que muchos equipos de marketing ya conocen.
Otro caso frecuente: la experiencia de usuario requiere algo que un tema estándar de WordPress no gestiona bien. Un configurador de productos, una interfaz muy interactiva, una búsqueda instantánea o un proceso de compra en varias etapas. En estos casos, un front-end de JavaScript bien diseñado puede ofrecer más flexibilidad. Sinceramente, esta tecnología solo se justifica si esa flexibilidad aporta un valor real para el negocio.
¿Merece la pena el «headless» para una pyme?
La verdadera cuestión no es técnica, sino económica. Un proyecto «headless» de WordPress añade una capa adicional de diseño, desarrollo y mantenimiento. Ya no pagas solo por una web de WordPress: pagas por WordPress, un front-end independiente, la integración de la API, la caché, la vista previa, las implementaciones y la supervisión.
En el mercado francés, una página web clásica de WordPress para pymes suele oscilar entre los 5 000 y los 18 000 €, dependiendo del número de páginas, el diseño, el SEO y las integraciones. Un proyecto «headless» comparable suele partir de entre 15 000 y 30 000 €, y puede superar los 50 000 € si la experiencia de usuario, los contenidos multilingües, los flujos de trabajo o las conexiones con sistemas de negocio son ambiciosos. Se trata de órdenes de magnitud, no de una tabla universal.
| Arquitectura | Presupuesto orientativo del proyecto en Francia | Plazo habitual | Gastos recurrentes que hay que tener en cuenta |
|---|---|---|---|
| WordPress clásico | Entre 5 000 y 18 000 € | 4 a 10 semanas | Alojamiento WordPress, mantenimiento y posibles licencias |
| Headless WordPress para pymes | Entre 15 000 y 50 000 €+ | 8 a 16 semanas | Alojamiento WordPress, interfaz de usuario, CDN, monitorización, mantenimiento de la API |
| Empresa «headless» | Según presupuesto, a menudo muy por encima | De 3 a 6 meses o más | Entornos múltiples, support, seguridad, SLA, gobernanza |
Las plataformas front-end también suponen un coste adicional. En 2026, Vercel Pro tiene un precio de 20 dólares al mes con un crédito de uso, y se cobran de más por las licencias adicionales para determinados roles. Netlify Pro también parte de 20 dólares al mes, con créditos mensuales y tramos de precios. Cloudflare Pages factura las Functions como peticiones Workers, según el plan utilizado.
Estas cantidades mensuales parecen modestas. La trampa está en otra parte: excesos de uso, minutos de compilación, vistas previas, entornos de pruebas y el tiempo que dedica el desarrollador a corriger una cadena de implementación que no funciona. Con este presupuesto, es mejor destinar los fondos a una arquitectura clara y un buen plan de caché, en lugar de a una animación sofisticada que ralentice la puesta en línea.
Las trampas que los no técnicos descubren demasiado tarde
La primera dificultad tiene que ver con la vista previa. En WordPress clásico, un redactor hace clic en «Vista previa» y ve su página. En WordPress «headless», esta función debe reconstruirse entre WordPress y el front-end. Faust.js ayuda en este aspecto con Next.js, pero no es automático en todos los contextos.
Segundo tema: los plugins. Muchas extensiones de WordPress dan por hecho que el tema de WordPress se encarga de mostrar la página. Un plugin de SEO, un constructor de páginas, un formulario o una extensión multilingüe pueden funcionar en el panel de administración, pero no generar directamente el resultado esperado en la interfaz de usuario. Es necesario comprobar los datos realmente disponibles a través de la API REST o GraphQL.
En los proyectos que llevamos a cabo, a menudo observamos una discrepancia entre la promesa de que «WordPress sigue siendo sencillo» y la realidad cotidiana de los colaboradores. Si el equipo editorial pierde la vista previa fiel, los bloques habituales o la flexibilidad en el diseño, la ventaja técnica se convierte en una carga operativa. La confianza de los redactores forma parte del presupuesto.
El SEO también requiere una atención especial. Las etiquetas «title», la meta descripción, los datos estructurados, la paginación, el mapa del sitio XML, las redirecciones y el rendimiento de los Web Vitals deben gestionarse correctamente en el front-end. En el caso de un rediseño, el riesgo es mayor que con un cambio de tema convencional; nuestra lista de comprobación de rediseño WordPress sin pérdida de SEO ofrece una buena base para el control.
- Comprueba que los contenidos, los archivos multimedia, las taxonomías y los campos personalizados se muestren correctamente a través de la API.
- Probar la vista previa antes de validar la arquitectura, no al final del proyecto.
- Confirmar la compatibilidad de los plugins esenciales: SEO, formularios, multilingüismo y comercio electrónico.
- Prever un mecanismo de caché y revalidación cuando se modifique un contenido.
- Documentar quién se encarga del mantenimiento de WordPress, la interfaz de usuario y los alojamientos asociados.
Cuándo es mejor seguir utilizando la versión clásica de WordPress
Para una página web corporativa de entre 10 y 40 páginas, con blog, formularios, algunas páginas locales y un objetivo de SEO, WordPress clásico suele ser la opción más racional. Es más económico, su mantenimiento resulta más sencillo y permite que otro proveedor se haga cargo del proyecto sin tener que empezar desde cero. Sencillo. Eficaz.
Si tu prioridad es publicar rápidamente, comprobar tu posicionamiento o controlar el presupuesto, la arquitectura «headless» puede ralentizar la toma de decisiones. Una buena plantilla personalizada, un alojamiento sólido en OVHcloud, Infomaniak o un proveedor de alojamiento gestionado para WordPress, una caché bien configurada y Cloudflare delante del sitio suelen ser suficientes para conseguir muy buenos resultados.
La cuestión de la elección del CMS también merece ser planteada antes de decidir la arquitectura. WordPress no siempre es la respuesta: Webflow, Wix, un CMS headless nativo o una solución de comercio electrónico pueden ser más adecuados según el contexto. Para comparar las opciones sin jerga técnica, puedes leer nuestra guía para Elige entre Webflow, Wix y WordPress.
Un caso en el que la solución obvia a veces es la incorrecta: el comercio electrónico. Es posible utilizar WooCommerce en modo «headless», pero la complejidad aumenta rápidamente con el carrito de la compra, el pago, las cuentas de clientes, los correos electrónicos, las existencias y las promociones. Para una tienda de una pyme, es mejor comparar detenidamente WooCommerce, PrestaShop y Shopware antes de desacoplar la interfaz de usuario; esto Comparativa de comercio electrónico 2026 ayuda a orientar esta elección.
Cómo estructurar un proyecto «headless» de WordPress sin sobrepasar los plazos
Una planificación rigurosa comienza por los usos, no por el marco de trabajo. ¿Quién publica? ¿Cuántos contenidos al mes? ¿Qué plantillas de página? ¿Qué idiomas? ¿Qué canales? ¿Qué restricciones en materia de RGPD, accesibilidad o seguridad? Estas respuestas determinan la arquitectura.
Por parte de la agencia, lo habitual es establecer desde el principio una matriz sencilla: contenidos, roles, flujos de trabajo, datos expuestos mediante API, necesidades de SEO y restricciones de alojamiento. Solo después se decide entre Next.js, Astro, WPGraphQL o una API REST. Next.js se adapta bien a interfaces ricas y a sitios web con renderizado híbrido. Astro suele ser adecuado para sitios web de contenido rápido, con menos JavaScript en el navegador.
Los plazos dependen totalmente de la situación actual. Una migración gestionada por WordPress VIP suele durar entre 4 y 12 semanas para proyectos supervisados, dependiendo del tamaño y la complejidad. En el caso de una pyme, es mejor prever entre 8 y 16 semanas si se incluyen el diseño, el desarrollo, la importación de contenidos, el SEO y la aceptación del proyecto.
No descuides la accesibilidad. Un front-end moderno no garantiza nada de forma predeterminada: es necesario comprobar el contraste, la navegación con el teclado, las alternativas textuales, la estructura de los títulos y los componentes interactivos. Este tema se enmarca dentro de los requisitos de la RGAA, que se explican en nuestro artículo sobre la accesibilidad de una página web.
Último punto: el mantenimiento. WordPress evoluciona, y los frameworks también. En julio de 2026, WordPress.org mencionaba que las versiones 7.x se encontraban en fase de publicación y pruebas, con la advertencia habitual de no instalar una versión candidata en un sitio en producción. En una arquitectura desacoplada, cada actualización debe verificarse en dos capas en lugar de en una sola.
Planificar este tipo de proyecto desde el principio evita la mayoría de las sorpresas desagradables: un presupuesto subestimado, la falta de una vista previa, un SEO debilitado o un mantenimiento poco claro. Una perspectiva externa ayuda, sobre todo, a decidir si la separación de componentes aporta valor o si, por el contrario, añade una complejidad de la que tu empresa no necesita.
Preguntas frecuentes sobre WordPress sin interfaz gráfica
¿Es Headless WordPress bueno para el SEO?
Sí, siempre y cuando el front-end gestione correctamente las etiquetas SEO, los datos estructurados, las redirecciones, el mapa del sitio y la velocidad. Si está mal configurado, por el contrario, puede complicar la indexación y las migraciones.
¿Cuánto cuesta una página web «headless» de WordPress?
En el caso de una pyme en Francia, suele oscilar entre 15 000 y 50 000 €, o incluso más, dependiendo del alcance del proyecto. A esto hay que añadir el alojamiento de WordPress, el front-end, la CDN, las posibles licencias y el mantenimiento.
¿Next.js o Astro para WordPress headless?
Next.js es ideal para interfaces con gran cantidad de contenido, recorridos dinámicos y proyectos avanzados de React. Astro es muy adecuado para sitios web de contenido rápido que desean limitar la cantidad de JavaScript que se envía a los visitantes.
¿Se pueden conservar los plugins de WordPress en el modo «headless»?
Algunos plugins siguen siendo útiles en el panel de administración, pero su visualización pública no siempre es adecuada. Las extensiones de SEO, formularios, multilingües o de comercio electrónico deben someterse a pruebas antes de su validación.
¿Es recomendable elegir WordPress «headless» para una simple página web de presentación?
En la mayoría de los casos, no. Un WordPress clásico, bien diseñado, rápido y seguro ofrecerá una mejor relación coste-beneficio para una página web corporativa estándar.