WordPress o headless: una guía para quienes toman las decisiones

Si vas a encargar una web nueva, es probable que alguien te haya dicho que headless es el futuro y que las plataformas tradicionales se han quedado anticuadas. Y que otra persona te haya dicho lo contrario. La decisión entre WordPress o headless tiene menos que ver con la tecnología que con tu equipo, tus contenidos y el número de sitios en los que esos contenidos tienen que aparecer. Esta guía explica qué supone cada enfoque en la práctica, cuánto cuesta mantener cada uno y qué preguntas te llevarán a la opción adecuada para tu organización.

¿Qué significa exactamente headless?

Un sistema de gestión de contenidos tradicional hace dos trabajos. Guarda y gestiona tus contenidos, y genera las páginas que ven los visitantes. WordPress, en su forma estándar, funciona así: los editores escriben en el panel de administración y un tema convierte esos contenidos en páginas web.

Una arquitectura headless separa esos dos trabajos. El sistema de gestión de contenidos (CMS) solo guarda los contenidos y los ofrece a través de una API. Una aplicación aparte, el frontend, solicita esos contenidos y construye las páginas, normalmente con un framework de JavaScript. La “cabeza” que se ha quitado es la capa de presentación.

Hay dos puntos que suelen entenderse mal. Primero, headless describe una arquitectura, no un producto: el propio WordPress puede usarse como sistema headless, igual que las plataformas creadas expresamente para ello. Segundo, headless no significa automáticamente más rápido, más seguro ni mejor. Significa más flexible, a cambio de más piezas que construir y mantener.

¿Qué hace bien el WordPress tradicional?

Para la mayoría de las webs de marketing, WordPress en su forma estándar sigue siendo una opción sólida, por razones prácticas.

• Los editores son autónomos. Tu equipo puede crear páginas, cambiar la maquetación y previsualizar el resultado sin un desarrollador.
• El ecosistema es maduro. Formularios, SEO, contenidos multilingües, e-commerce, reservas y membresías existen como plugins consolidados, sin necesidad de desarrollos a medida.
• Hay muchos profesionales disponibles. No dependes de un único proveedor, porque muchos desarrolladores y agencias trabajan con él.
• El coste y el plazo de desarrollo son menores. Un solo sistema hace todo el trabajo.
• Puede ser rápido. Con un buen alojamiento, caché, un tema ligero y un uso disciplinado de los plugins, una web WordPress puede cumplir estándares de rendimiento exigentes.

¿Cuándo tiene sentido una arquitectura headless?

Headless justifica su complejidad adicional en circunstancias concretas:

• Los contenidos alimentan varios canales. El mismo contenido tiene que aparecer en una web, una app móvil, pantallas en tienda o plataformas de partners. Gestionarlo una vez y distribuirlo en todas partes es justo para lo que sirve esta arquitectura.
• El frontend se parece más a una aplicación que a una web. Las herramientas interactivas complejas, los paneles para usuarios registrados o las experiencias de producto muy personalizadas ganan con un framework de frontend específico.
• Tienes una escala excepcional o picos de tráfico. Las páginas generadas de antemano y servidas desde una red de distribución de contenidos (CDN) responden muy bien a una demanda repentina.
• Hay que combinar varios sistemas. Los contenidos de un CMS, los productos de una plataforma de comercio y los datos de sistemas internos pueden reunirse en un único frontend.
• Tienes desarrolladores en tu equipo interno que se harán cargo del frontend y lo ampliarán con el tiempo.

Si no se da ninguno de estos casos, lo más probable es que headless añada coste sin añadir un valor que tus visitantes o tus editores vayan a notar.

¿Cuáles son los costes ocultos de una web headless?

Las contrapartidas de headless suelen aparecer después del lanzamiento y recaen sobre todo en quienes gestionan la web.

• Dos sistemas que construir, alojar y mantener. El CMS y el frontend necesitan cada uno su alojamiento, su monitorización, sus actualizaciones y su atención a la seguridad.
• La edición es menos directa. La vista previa en directo y la construcción visual de páginas hay que desarrollarlas expresamente, y rara vez resultan tan fluidas como en una instalación tradicional. A menudo los editores rellenan campos estructurados sin ver la página terminada.
• Los plugins dejan de funcionar como se espera. Todo lo que genera salida en el frontend, como los formularios, las etiquetas SEO, el consentimiento de cookies o las integraciones de analítica, hay que reconstruirlo o volver a conectarlo.
• Los cambios dependen de los desarrolladores. Una nueva maquetación de página o un nuevo tipo de sección es una tarea de desarrollo, no de edición.
• El SEO exige un trabajo deliberado. Metadatos, sitemaps, redirecciones y datos estructurados son todos posibles, pero cada uno hay que implementarlo a mano, y el renderizado debe configurarse para que los buscadores reciban el HTML completo.

WordPress o headless: ¿qué preguntas deben decidirlo?

Plantea estas preguntas a tu equipo y a los proveedores que estés valorando.

• ¿Dónde tienen que aparecer nuestros contenidos, ahora y en los próximos años? ¿Solo en una web o también en otros canales?
• ¿Quién actualizará la web a diario y cuánta libertad necesita para crear y reorganizar páginas sin ayuda?
• ¿Tenemos desarrolladores en el equipo interno o en una colaboración mensual, y los seguiremos teniendo?
• ¿Qué funciones necesitamos y existen ya como plugins contrastados?
• ¿Qué problema de rendimiento tenemos hoy, si es que tenemos alguno, y se ha diagnosticado su causa?
• ¿Cuál es el coste total de propiedad durante la vida de la web, incluidos el alojamiento, el mantenimiento y los cambios?

Como regla general: a una empresa cuya web es ante todo una herramienta de marketing y de captación de leads, gestionada por un equipo de marketing, le conviene un WordPress tradicional bien hecho. Una organización con un equipo de producto, varios canales y requisitos propios de una aplicación debería valorar headless en serio.

¿Hay un término medio entre los dos?

Sí, y a menudo es la respuesta más sensata. Puedes mantener WordPress como sistema de contenidos y usarlo en modo headless, de forma que los editores conservan un panel de administración conocido y los desarrolladores ganan libertad en el frontend. O puedes optar por un modelo híbrido, en el que la mayor parte de la web usa el WordPress estándar y solo una sección exigente, como un configurador o un portal de clientes, se desarrolla como aplicación aparte.

También puedes prepararte para el futuro sin pagarlo ahora. Una web WordPress tradicional desarrollada con contenidos estructurados, campos personalizados limpios y poca dependencia de estilos específicos de cada página puede pasar más adelante a un frontend headless, porque los contenidos ya están organizados de forma reutilizable. Un buen modelado de contenidos mantiene abiertas las dos opciones.

Preguntas frecuentes

Si quieres una recomendación imparcial basada en tus contenidos, tu equipo y tus objetivos, descubre nuestro servicio de diseño y desarrollo web.