Headless CMS vs WordPress Tradicional: Una Comparación Honesta

Casi todos los artículos que comparan un CMS headless con WordPress los escribió alguien que vende uno de los dos. Este viene de un estudio que entrega los dos, lo que básicamente significa que nos hemos quemado con ambos y que las opiniones vienen con cicatriz incluida.

Versión corta antes del detalle. Headless no es automáticamente mejor. Es mejor para un conjunto concreto de problemas y bastante peor para otro. Elige mal y te compras o un año de deuda de rendimiento o un año pagando a desarrolladores para hacer cosas que un editor podría haber resuelto solo en una tarde.

Qué significa «headless» en realidad

WordPress tradicional es un solo sistema haciendo dos trabajos: guardar tu contenido y renderizar tus páginas. Una plantilla convierte las entradas en HTML, los plugins añaden comportamiento por el lado, y PHP sirve todo el conjunto desde un servidor.

Headless separa esos dos trabajos. El CMS se convierte en una API de contenido y nada más. Un front end aparte, normalmente Next.js en nuestro caso, se trae ese contenido en tiempo de compilación o bajo petición y renderiza el sitio. El CMS no ve a un visitante en ningún momento.

Esa separación es toda la historia. Todo lo que viene después, la velocidad y la flexibilidad y el coste extra, cae de esa única decisión de arquitectura. Merece la pena retenerlo, porque casi todas las discusiones que tiene la gente sobre esto son en realidad discusiones sobre ese intercambio, disfrazadas.

Dónde sigue ganando WordPress tradicional

Esta es la parte que los defensores de headless suelen pasar rápido. WordPress mueve alrededor de un tercio de la web, y los motivos son genuinamente buenos.

• Los editores tienen edición visual de verdad. Con un buen tema de bloques o con Elementor, alguien de marketing monta una landing un martes por la tarde sin abrir un ticket. En headless, esa página normalmente espera a que un desarrollador defina antes el componente.
• El ecosistema es enorme. Formularios, membresías, WooCommerce, multiidioma, reservas. Existe, es barato y funciona hoy. Rehacer cualquiera de esas cosas en un stack headless es presupuesto de verdad y semanas de verdad.
• Es más barato de operar y mucho más fácil de contratar. Un hosting, un repositorio y una bolsa global de gente capaz de mantenerlo sin periodo de adaptación.
• Puede ser genuinamente rápido. Construimos Catalyst en WordPress con Elementor Pro y saca 99 en Lighthouse con 100 en accesibilidad. Un WordPress lento es un problema de disciplina, no una ley de la plataforma.

La mayoría de los sitios lentos en WordPress también serían lentos en headless. Los plugins solo se mudan de casa.

Dónde gana headless de verdad

Y ahora el otro lado, que es igual de real y que sobrevende bastante quien solo ha visto uno de los dos.

• Techo de rendimiento. Un sitio Next.js generado estáticamente sirve HTML prerenderizado directamente desde una CDN. No hay consulta a base de datos en ningún punto de la ruta crítica, así que el suelo se mantiene alto incluso en un mal día. Nuestras builds en Next.js se sitúan en 99 de Lighthouse sin que nadie haga heroicidades.
• Una fuente de contenido, muchas salidas. Web, app móvil, pantalla en tienda, feed para partners, todo leyendo la misma API. En cuanto tienes más de una superficie, headless deja de ser una preferencia y se convierte en la respuesta obvia.
• Superficie de seguridad. Sin login de administración público y sin un plugin arrastrando un CVE de 2021 en producción. La superficie de ataque se reduce muchísimo y se queda reducida.
• Interfaces que no son páginas. Paneles, configuradores, cualquier cosa con estado. Construimos el panel de seguridad de Murtasec en React exactamente por eso: un CMS basado en páginas tiene sencillamente la forma equivocada para una aplicación.
• Velocidad de desarrollo a escala. Orientado a componentes, tipado, testeable y desplegable en cada commit. En un sitio grande eso compone con fuerza, y en uno pequeño apenas lo vas a notar.

La comparación honesta

Léelo como un conjunto de compromisos y no como un marcador. Si la autonomía del editor es tu fila principal, WordPress gana tu proyecto diga lo que diga la columna de rendimiento, y por mucho que se discuta sobre milisegundos eso no cambia.

Los costes que nadie mete en el presupuesto

Headless arrastra tres costes recurrentes que rara vez llegan a una propuesta. Son la razón de que cierto número de estos proyectos se agrien sobre el mes doce, normalmente con todo el mundo un poco desconcertado sobre cómo ha pasado.

1. 01La vista previa es trabajo. Los editores esperan ver un borrador antes de publicar, con toda la razón. En headless eso es una funcionalidad que alguien tiene que construir y después mantener, no una casilla en un panel de ajustes.
2. 02Cada layout nuevo se convierte en un ticket. Salvo que inviertas pronto en un modelo de bloques flexible, marketing pierde la capacidad de publicar páginas por su cuenta, que muy a menudo es justo lo que le prometieron cuando se vendió el proyecto.
3. 03Dos sistemas, dos rutas de actualización. El CMS y el front end versionan por separado. No es difícil, pero tampoco es nada, y no aparece nunca en una planificación.

Hay un cuarto coste, más blando y más difícil de presupuestar: tu equipo tiene que estar cómodo con un pipeline de despliegue. Si nadie en la oficina tiene opiniones sobre Git, headless se va a sentir como fricción y no como libertad, por buena que sea la arquitectura.

El término medio que nadie menciona

El debate se plantea como binario y realmente no lo es. Hay al menos tres posiciones entre WordPress clásico y arráncalo de raíz, y una de ellas es la correcta para la mayoría de las empresas que llegan convencidas de necesitar el salto completo.

• WordPress headless. Mantén WordPress como API de contenido y pon un front end de Next.js delante. Nadie tiene que aprender un panel nuevo, no hay que exportar y reimportar nada, y sigues consiguiendo el techo de rendimiento. Es la opción que más recomendamos y la que menos se menciona.
• WordPress estático. Deja todo como está, pero pre-renderiza el sitio entero a ficheros planos y sirve esos. Pierdes las funcionalidades dinámicas y ganas mucha velocidad y seguridad con muy poco trabajo. Perfectamente válido para una web escaparate que cambia cada semana y no cada hora.
• Híbrido. Web de marketing headless y blog en WordPress, o al revés. Es algo más que mantener, pero cada mitad puede ser buena en su propio trabajo en vez de forzar a las dos a un compromiso.

Algo que conviene saber antes de comprometerse a nada: el front end y el CMS son decisiones separables. Elegir Next.js no te ata a un CMS concreto, y decidir dejar WordPress no te ata a un front end concreto. Los equipos suelen fundir las dos en una sola decisión y acaban comprando de más por los dos lados.

Un ejemplo trabajado

Algo concreto, porque las abstracciones se vuelven resbaladizas rápido. Imagina una empresa B2B de quince personas. Marketing publica dos o tres páginas al mes, casi siempre variaciones de una landing. Hay un portal de clientes en un subdominio hecho en React. El tráfico es decente, lo orgánico te importa, y la web actual de WordPress tarda cinco segundos en cargar por culpa de un maquetador visual y una década de plugins acumulados.

El instinto dice vete a headless, porque va lenta. Pero mira cuál es la restricción real. Marketing publica páginas por su cuenta, y esa es la capacidad que mantiene a la empresa en movimiento semana a semana. Quítasela y habrás cambiado dos segundos de carga por un cuello de botella permanente en la mesa de un desarrollador, que es un trato bastante peor de lo que parece en una diapositiva.

Aquí la respuesta correcta suele ser WordPress headless o, con bastante frecuencia, simplemente una limpieza seria primero. Quitar el maquetador, rehacer bien las plantillas, dejar los plugins en cinco y volver a medir. Son cuatro semanas en lugar de cuatro meses y, si después sigue yendo lenta, has aprendido algo real y el caso de headless se defiende solo, sin que nadie tenga que argumentarlo.

Cinco preguntas que lo deciden

Las hacemos en la primera llamada. Las respuestas apuntan en la misma dirección alrededor del ochenta por ciento de las veces, y el veinte restante son los proyectos interesantes.

1. 01¿Con qué frecuencia necesita marketing publicar una página que nadie diseñó de antemano? Mucha significa WordPress.
2. 02¿Hay más de un sitio donde tiene que aparecer el contenido? Sí significa headless.
3. 03¿La web incluye algo que se comporta como una aplicación y no como un documento? Sí significa headless.
4. 04¿Hay un desarrollador interno o lo mantendrá una agencia con una iguala? Sin desarrollador, el péndulo va hacia WordPress.
5. 05¿El rendimiento actual falla por razones estructurales o porque alguien instaló diecinueve plugins? Estructural significa headless. Diecinueve plugins significa limpieza, y probablemente una conversación.

Y una más, que no es tanto una pregunta como un aviso. No elijas headless porque es lo que recomendaba la última charla de una conferencia. El mejor stack es el que tu equipo seguirá pudiendo usar dentro de dos años sin llamar a nadie por teléfono.

Entonces, ¿cuál?

Si eres un negocio movido por contenido que publica a menudo, con un equipo pequeño y sin un segundo canal, quédate en WordPress y gasta el dinero en hacerlo rápido y bien estructurado. Serás más feliz y como un cuarenta por ciento más rico, y la web será mejor.

Si tienes un producto, varias superficies, un techo de rendimiento con el que chocas constantemente o una web de marketing que necesita sentirse como software y no como un folleto, ve a headless. Es el trabajo que más hacemos, y normalmente va acompañado de un front end en Next.js.

Vayas por donde vayas, construye pensando en poder dar marcha atrás. Mantén el modelo de contenido limpio y portable, evita enterrar la estructura dentro de un maquetador propietario y trata el CMS como algo que podrías cambiar en dieciocho meses sin reescribir el front end. Toda decisión de stack parece obvia durante unos dos años y luego, sin ruido, deja de serlo. Los equipos que lo llevan bien son los que no soldaron las piezas entre sí.

Y conviene decirlo claro: el coste de equivocarse aquí es real pero recuperable. Hemos movido sitios en las dos direcciones y no se ha muerto nadie. Lo que no se recupera es pasar ocho meses discutiéndolo mientras la web actual tarda cinco segundos en cargar y el formulario de contacto sigue teniendo once campos.

Y si ya estás en WordPress y te preocupa moverte sin destrozar tu visibilidad en búsqueda, ese es un camino muy transitado y todo el juego está en el mapa de redirecciones. Lo contamos entero por separado en migrar de WordPress a Next.js sin perder posiciones. En corto: rastrea cada URL antigua antes de tocar nada, redirige con 301 cada una a la página superviviente más cercana en vez de soltarlas todas en la home, y publica canonicals, sitemap y datos estructurados el día uno en vez de tratarlos como fase dos.