WordPress headless separa el contenido, que sigue gestionándose en el WordPress de siempre, del diseño que ve el visitante, construido aparte con tecnologías como React o Next.js. Para un responsable de marketing o un equipo técnico que vigila cada segundo de carga y cada punto de conversión, la pregunta no es si la arquitectura funciona —ya lo hace en portales de gran tráfico— sino si el salto compensa para su web concreta, su presupuesto y su calendario de publicación. La respuesta cambia según el sector y el volumen de contenido.
WordPress headless es una instalación de WordPress que actúa solo como gestor de contenido: expone los artículos y páginas mediante una API —normalmente WPGraphQL o la REST API— y un frontend separado, sin relación con los temas clásicos de WordPress, se encarga de mostrarlos.
Qué significa desacoplar WordPress del frontend
En una instalación clásica, WordPress hace dos trabajos a la vez: guarda el contenido en su base de datos y lo pinta en pantalla con un tema PHP. En una arquitectura headless esos dos trabajos se separan. WordPress conserva el editor, los roles de usuario y el flujo de publicación que ya conoce el equipo de contenido, pero deja de encargarse del diseño: expone cada artículo y cada página a través de una API, normalmente WPGraphQL, y un frontend construido aparte —con React, Next.js o Astro— se encarga de mostrarlo al visitante.
Este cambio dejó de ser un experimento de equipos muy grandes. WordPress.org anunció en octubre de 2024 que WPGraphQL pasaba a ser plugin canónico del proyecto, con el respaldo de Automattic para su mantenimiento a largo plazo. Para un equipo técnico, esa garantía cambia el cálculo: ya no se apuesta por una pieza de software de un solo desarrollador, sino por una vía de acceso a los datos que WordPress sostiene de forma oficial.
Cuándo WordPress headless compensa de verdad
El salto no compensa por moda ni porque lo use la competencia: compensa cuando el volumen de tráfico o la complejidad del catálogo hacen que cada décima de segundo de carga se note en el negocio. Dos perfiles de sector lo ilustran bien.
Portales editoriales con mucho tráfico
Los medios y los portales de contenido con miles de artículos son el caso más documentado. En proyectos de migración a WordPress headless con Next.js publicados por sus propios equipos de ingeniería, las páginas cargan entre 4 y 10 veces más rápido que en la versión monolítica anterior. Un editor con 50.000 artículos y 2 millones de visitas mensuales redujo el tiempo de carga de 3,5 segundos a menos de 1 segundo, y amortizó la migración en cuatro meses solo por la mejora de rendimiento. Para un responsable de contenido de un medio digital o de un portal sectorial, esa cifra pesa más que cualquier argumento de arquitectura.
Tiendas online y catálogos grandes
En comercio electrónico el argumento es la conversión, no solo la velocidad. El estudio Milliseconds Make Millions, elaborado por Google y Deloitte, encontró que mejorar el tiempo de carga móvil en apenas 0,1 segundos elevó la conversión un 8,4% en retail y un 10,1% en el sector viajes. Una tienda con miles de referencias y filtros de catálogo es exactamente el escenario donde WordPress clásico empieza a notar la carga: cada plugin de filtrado o de recomendación suma peticiones. Servir el catálogo desde una capa headless con caché en el borde de la red evita ese arrastre sin renunciar a WordPress como gestor de producto.
Casos donde el WordPress clásico sigue ganando
La mayoría de las webs no necesitan este cambio, y conviene decirlo con la misma claridad. Según W3Techs, WordPress mueve más del 41% de todas las webs del mundo y más del 60% de las que usan un gestor de contenido identificable: esa dominancia se explica precisamente porque, para la mayoría de sitios, el WordPress clásico —bien cacheado, con pocos plugins y un tema ligero— sigue siendo la opción más rápida de poner en marcha y la más barata de mantener.
Un despacho de servicios profesionales con una web de veinte páginas, un fabricante industrial con un catálogo estático o una consultora que publica dos artículos al mes no van a notar el salto en conversión que sí nota un medio o un ecommerce grande, y sí van a notar el coste de mantener dos capas de software en lugar de una. Ahí, invertir ese presupuesto en optimizar el tema, la caché y las imágenes suele dar más retorno que desacoplar el frontend.
Qué cambia en el día a día de marketing y contenido
Para el equipo que redacta y publica, el editor de WordPress no cambia: los roles, el flujo de revisión y el calendario editorial siguen siendo los mismos. Lo que cambia es todo lo que ocurre después de pulsar «publicar».
- La vista previa deja de ser automática: hay que configurar un enlace de previsualización contra el frontend separado, o el equipo publica a ciegas.
- Los plugins que pintan algo en pantalla —constructores visuales, calculadoras, formularios con lógica propia— dejan de funcionar tal cual: hay que reconstruir esa pieza en el frontend nuevo.
- El SEO on-page (metadatos, etiquetas canónicas, datos estructurados) pasa a depender del frontend, no de un plugin de WordPress: si no se replica con el mismo cuidado, se pierde terreno que costó años ganar.
Ese último punto es el que más disgustos da. Un frontend headless mal configurado puede servir páginas rapidísimas y, aun así, perder posiciones porque nadie replicó las etiquetas hreflang, el mapa del sitio o los datos estructurados que el plugin SEO generaba solo. La velocidad no sustituye al SEO técnico: lo complementa.
Coste, plazos y equipo para una migración headless
Una migración a WordPress headless no es un ajuste de tema de una tarde. Exige un equipo con perfil de desarrollo frontend (React o Next.js), no solo administración de WordPress, y un plazo que en proyectos de tamaño medio se mueve entre dos y cuatro meses según cuántas plantillas y funcionalidades haya que reconstruir. Contar con un servicio de desarrollo de software en Barcelona que ya haya llevado este tipo de migración acorta la curva de aprendizaje, porque los errores de la primera vez —sobre todo en SEO y en caché— salen caros.
Qué perfil técnico necesitas contratar
El perfil que falta en la mayoría de equipos de marketing no es el que sabe WordPress, sino el que sabe consumir su API y construir con ella. Se necesita un desarrollador frontend cómodo con JavaScript moderno y con al menos un framework de renderizado (Next.js, Astro o similar), y conviene que haya trabajado antes con WPGraphQL o con la REST API de WordPress, porque ahí es donde aparecen los problemas de rendimiento por consultas mal optimizadas. Si el equipo interno no cubre ese perfil, una agencia especializada en WordPress en Barcelona con experiencia en proyectos headless resuelve la migración sin que el equipo de contenido note el cambio de arquitectura.
Riesgos técnicos que conviene prever antes del salto
Separar WordPress del frontend no reduce los riesgos técnicos: los traslada. El backend sigue siendo WordPress, con el mismo historial de vulnerabilidades en plugins de WordPress que exige mantenerlo parcheado igual que en cualquier instalación clásica, y un backend con versiones de PHP sin soporte es tan explotable detrás de una API como delante de un tema. La diferencia es que ahora hay una segunda pieza —el frontend— que también necesita mantenimiento, dependencias actualizadas y un despliegue propio.
El otro riesgo es organizativo: si el frontend lo construye una agencia externa y nadie interno entiende cómo se conecta con la API, cualquier cambio pequeño en el WordPress —una nueva categoría, un campo personalizado— puede requerir tocar código que el equipo no controla. Antes de dar el salto conviene dejar por escrito quién mantiene cada capa y con qué frecuencia se revisa el mantenimiento continuo del WordPress, para que no quede huérfano en cuanto el proyecto de migración se dé por cerrado.
Preguntas frecuentes sobre WordPress headless
¿Qué es WordPress headless?
Es una instalación de WordPress que gestiona el contenido pero no lo muestra: un frontend separado, construido con otra tecnología, consume su API y se encarga del diseño. El equipo de contenido sigue usando el editor de WordPress igual que siempre.
¿Cuánto cuesta migrar a una arquitectura headless?
Depende de cuántas plantillas y funcionalidades haya que reconstruir en el frontend nuevo. Un proyecto de tamaño medio, con un catálogo o un blog de varios cientos de piezas, suele moverse entre dos y cuatro meses de trabajo de un equipo con perfil frontend, más el mantenimiento continuo de las dos capas.
¿Se pierde posicionamiento al migrar?
Solo si el frontend nuevo no replica lo que hacía el plugin SEO de WordPress: etiquetas canónicas, datos estructurados, mapa del sitio y redirecciones. Bien planificada, una migración headless no pierde posiciones porque las URL y el contenido no cambian, solo cambia qué motor las renderiza.
¿Qué pasa con los plugins que ya uso?
Los plugins que solo trabajan en el backend —SEO, formularios de captura, seguridad— siguen funcionando porque WordPress sigue ahí. Los que pintan algo en pantalla —constructores visuales, calculadoras, sliders— dejan de servir tal cual y hay que reconstruir esa funcionalidad en el frontend nuevo, pieza a pieza.
Fuente: WordPress News (WordPress.org)