WordPress o headless son las dos rutas que valora cualquier empresa B2B cuando su web actual se queda corta. La primera pregunta no es cuál es mejor en abstracto, sino qué necesita tu equipo: publicar rápido, escalar a varios canales o simplemente que el blog cargue bien. Esta pieza compara ambas arquitecturas con cifras de mercado, coste real y tiempos de desarrollo, pensada para quien tiene que defender la decisión ante dirección, no solo ante el departamento técnico.
Para una web B2B con blog, landings y formularios de contacto, WordPress tradicional sigue siendo la opción más rápida y barata de mantener. La arquitectura headless solo compensa cuando el tráfico supera medio millón de visitas mensuales, hay varios frontales consumiendo el mismo contenido —web, app, intranet— o el equipo ya trabaja con React o Next.js.
WordPress o headless, dos maneras de montar tu web
WordPress mueve, según datos de W3Techs, algo más del 40% de todas las webs del mundo: es un gestor de contenidos monolítico, donde el mismo sistema guarda el contenido, lo maqueta y lo sirve al visitante con plantillas PHP. La arquitectura headless rompe esa unión.
Una arquitectura headless separa el gestor de contenidos —donde escribe marketing— de la web que ve el visitante, normalmente construida con React, Next.js o Astro, y las conecta mediante una API REST o GraphQL en lugar de servir páginas ya montadas.
Con WordPress headless, el propio WordPress hace de backend y un frontend aparte consume esos datos por API. Es un término medio entre las dos rutas puras que se trata más adelante. Si quieres el detalle completo de esa variante, ya lo cubrimos en cuándo compensa dar el salto a WordPress headless.
Qué gana en rendimiento la arquitectura headless
El argumento técnico más repetido a favor de headless es la velocidad. Sin plugins acumulados ni un motor de plantillas PHP renderizando en cada petición, un frontend headless bien construido carga menos JavaScript de terceros y sirve HTML ya generado. La diferencia se nota sobre todo en el móvil, donde cada plugin de WordPress mal optimizado añade peticiones y scripts que compiten por el mismo hilo principal.
Core Web Vitals en un sitio desacoplado
Google mide la experiencia de carga con tres Core Web Vitals: el LCP (contenido principal visible) debe ocurrir antes de 2,5 segundos, el INP (respuesta a la interacción) por debajo de 200 milisegundos y el CLS (estabilidad visual) por debajo de 0,1, los tres medidos en el percentil 75 de las visitas. Un WordPress cargado de plugins de formularios, chat y pop-ups suele fallar el INP porque todos ellos añaden su propio JavaScript al arrancar la página. Un frontend headless con Next.js o Astro, generado como HTML estático o servido desde un CDN, parte con menos peso y menos scripts de terceros, así que llega más fácil a esos umbrales sin que el equipo tenga que pelear plugin por plugin.
Cuándo el rendimiento no compensa la complejidad
La ganancia de rendimiento no es automática ni gratis. Montar el frontend a mano obliga a reconstruir a mano lo que WordPress trae de serie: formularios con validación, buscador, paginación, sitemap, feed RSS y la vista previa que el equipo de marketing usa para revisar un artículo antes de publicarlo. Si el sitio actual ya carga en menos de tres segundos y el equipo no tiene a nadie que mantenga ese frontend, cambiar de arquitectura solo para ganar unas décimas de LCP no compensa: el coste de mantenimiento sube más que lo que se gana en velocidad. La pregunta no es qué arquitectura rinde más en un test de laboratorio, sino cuál rinde más con el equipo que de verdad hay disponible.
Cinco años de coste, WordPress o headless
El coste inicial engaña: un WordPress con un theme premium puede salir por 2.000-4.000 euros y un proyecto headless con frontend a medida rara vez baja de 15.000. La diferencia real aparece después, en lo que cuesta cada cambio pequeño —una landing nueva, un campo más en el formulario, una integración con el CRM— durante los años siguientes. Un CMS headless de gama media como Storyblok cuesta desde 99 euros al mes en su plan Growth, con 5 usuarios y un millón de peticiones a la API, y eso antes de pagar al desarrollador que construya y mantenga el frontend que lo consume.
| Concepto | WordPress tradicional | Headless (CMS + frontend a medida) |
|---|---|---|
| Coste inicial de desarrollo | 2.000 – 6.000 € | 15.000 – 40.000 € |
| Publicar una landing nueva | Horas, sin desarrollador | Días, requiere despliegue |
| CMS headless (ej. Storyblok Growth) | No aplica | Desde 99 €/mes, 5 usuarios, 1M peticiones API |
| Hosting y mantenimiento mensual | 30 – 150 € | 150 – 500 € (backend + frontend + CDN) |
| Perfil necesario para un cambio de contenido | Marketing, sin código | Desarrollador o CMS bien configurado |
| Coste a 5 años en un sitio de tráfico medio | Menor | Mayor, salvo multicanal real |
Ese mantenimiento mensual no es solo servidor: hay que vigilar rendimiento, seguridad y actualizaciones en los dos extremos de la arquitectura. En WordPress, el mantenimiento continuo del gestor de contenidos cubre buena parte de esa factura con un proveedor conocido; en headless, ese mismo trabajo se reparte entre el backend, el frontend y la infraestructura que los une, con más piezas que pueden fallar a la vez.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
WordPress o CMS headless: quién edita el contenido
En WordPress, cualquier responsable de marketing con dos horas de formación edita un texto, cambia una imagen o publica una landing sin abrir un ticket al equipo técnico. Es la razón por la que sigue siendo la opción por defecto en empresas donde marketing publica varias veces por semana y no quiere depender de un sprint de desarrollo para corregir un párrafo.
En headless, esa autonomía depende de cómo se haya modelado el contenido. Un CMS headless bien configurado —con campos claros para título, bloques de texto e imagen— deja editar sin tocar código. Pero cualquier cambio de estructura, como un campo nuevo o un tipo de bloque distinto, exige volver a tocar el frontend, porque el HTML final no vive en el CMS: vive en el código que lo consume. Es el motivo por el que muchas empresas B2B que migran a headless acaban contratando un desarrollo de software a medida solo para mantener ese frontend al día.
Integraciones con el CRM en una web B2B
La arquitectura también decide cómo se conecta la web con el resto del stack comercial. Un SaaS B2B necesita que cada formulario de demo llegue al CRM en segundos y dispare una secuencia de email automatizada; una empresa industrial necesita un catálogo con fichas técnicas y un buscador por referencia; una consultora o despacho profesional necesita, sobre todo, que el formulario de contacto no se pierda y que la agenda de reuniones se sincronice sola.
Con WordPress, esas integraciones suelen resolverse con plugins: Gravity Forms, WP Fusion o el conector nativo del CRM. Funcionan, pero cada plugin añade una dependencia más que hay que mantener actualizada. Con headless, la integración se programa a medida contra la API del CRM, lo que da más control sobre qué dato se manda y cuándo, a cambio de que cada cambio en el formulario pase por el equipo de desarrollo en vez de por un ajuste en el panel. Repasamos ese reparto de piezas con más detalle en por qué el equipo B2B no aprovecha su propio stack tecnológico.
Cómo decide un equipo técnico entre las dos
La decisión se simplifica bajando a criterios concretos en vez de preferencias de arquitectura. Antes de elegir, conviene revisar estos puntos con quien va a mantener el sitio los próximos tres años:
- Tráfico mensual actual y previsto: por debajo de medio millón de visitas, WordPress rinde de sobra.
- Número de frontales que van a consumir el mismo contenido: web, app, intranet, punto de venta.
- Quién publica cada semana: si es marketing sin apoyo técnico, la autonomía de edición pesa más que el rendimiento.
- Presupuesto de mantenimiento anual, no solo el de desarrollo inicial.
- Si ya existe equipo o proveedor que trabaje con React o Next.js, o habría que contratarlo desde cero.
Si dos o más de esos puntos apuntan a headless, el término medio razonable es WordPress headless: se conserva la edición que ya conoce marketing y se gana el frontend a medida donde de verdad aporta. Para el resto, una agencia especializada en WordPress sigue siendo el camino más corto entre decidir y publicar.
Preguntas frecuentes sobre WordPress o headless
¿Es lo mismo WordPress headless que headless puro?
No. WordPress headless usa WordPress como backend y un frontend externo, como Next.js, que consume su API. El headless puro no lleva WordPress en ningún punto: el contenido vive en un CMS especializado, como Storyblok o Contentful, pensado desde el inicio para servir datos, no páginas HTML.
¿Cuánto cuesta migrar de WordPress a headless?
Depende del alcance, pero un frontend a medida con un CMS headless de gama media rara vez baja de 15.000-20.000 euros, sin contar el mantenimiento posterior del backend y del frontend por separado. Migrar solo compensa si el volumen de tráfico o los canales adicionales justifican esa inversión.
¿WordPress sigue siendo válido para una web B2B en 2026?
Sí. Mueve más del 40% de las webs del mundo y cubre de sobra un blog, landings y formularios con un equipo de marketing autónomo. Headless aporta cuando hay varios frontales o tráfico muy alto, no por ser la opción más nueva.
