Cuando llega el momento de renovar un sitio web, tarde o temprano aparece la palabra “headless”. Suena moderno, aparece en las presentaciones de agencias y en los foros de desarrolladores, y es fácil terminar con la sensación de que un WordPress “normal” ya quedó atrás.
La realidad es menos dramática. Headless es una arquitectura con ventajas concretas y costos igual de concretos. La pregunta útil no es cuál es más moderna, sino cuál calza con la forma en que tu equipo trabaja y con lo que tu sitio tiene que hacer en los próximos años.
Qué significa realmente “headless”
Todo sitio administrable tiene dos partes: un lugar donde se guarda y edita el contenido (el CMS) y una capa que lo convierte en las páginas que ve tu cliente.
En un WordPress tradicional, ambas partes viven juntas. El mismo sistema guarda tus textos y, a través de un tema, arma el HTML de cada página. Editas, guardas y el cambio está publicado.
En una arquitectura headless se separan. El CMS (puede ser WordPress u otro) solo administra contenido y lo entrega a través de una API. Un proyecto aparte, el frontend, consulta esa API y construye las páginas, normalmente con un framework de JavaScript. La “cabeza” (la presentación) se desacopla del “cuerpo” (el contenido).
Esa separación es la fuente de todas sus ventajas y también de todos sus costos.
Lo que ganas con headless
- Libertad total en el frontend. El equipo de desarrollo no está limitado por cómo funciona un tema de WordPress. Puede construir interfaces muy interactivas, con transiciones, filtros en tiempo real o experiencias que se parecen más a una aplicación que a una página.
- Un mismo contenido, varios canales. Si tus productos, noticias o fichas técnicas tienen que aparecer en el sitio, en una app móvil y en pantallas de tus sucursales, una API central evita duplicar el trabajo.
- Menos superficie expuesta. El panel de administración puede quedar en un servidor que el público no ve. El sitio que recibe las visitas puede ser estático o casi estático, servido desde una CDN.
- Equipos en paralelo. En proyectos grandes, quienes trabajan en contenido y quienes trabajan en la interfaz avanzan sin pisarse.
Lo que pagas por esa flexibilidad
Esta es la parte que suele quedar fuera de la presentación comercial.
- Dos proyectos en vez de uno. Dos bases de código, dos despliegues, dos cosas que mantener actualizadas y, muchas veces, dos servicios de hosting.
- Los plugins dejan de funcionar “solos”. Formularios, SEO, sliders, constructores visuales: todo lo que en WordPress se instala con un clic y se ve en el sitio, en headless hay que reconstruirlo o conectarlo a mano en el frontend.
- La vista previa se complica. Ver cómo va a quedar un borrador antes de publicarlo requiere trabajo adicional de integración. Si tu equipo de marketing publica a diario, lo va a notar.
- Cada cambio de diseño pasa por un desarrollador. Agregar una sección nueva a una página ya no es arrastrar un bloque: es modificar código y desplegar.
Nada de esto es un problema si tienes un equipo técnico permanente. Para una empresa que actualiza su sitio con una persona de marketing y sin desarrolladores internos, puede convertirse en una dependencia cara.
Cuándo WordPress tradicional es la mejor respuesta
Para la gran mayoría de los sitios corporativos, de servicios, blogs y catálogos, un WordPress bien construido sigue siendo la opción más sensata. Tu equipo edita con el editor de bloques, ve el resultado de inmediato y no necesita a nadie para publicar una noticia o cambiar un precio.
Un mito frecuente es que headless es necesario para tener un sitio rápido. En la práctica, la velocidad depende mucho más de cómo está construido el sitio que de su arquitectura: imágenes optimizadas, pocos scripts de terceros, caché bien configurada y un tema escrito a medida en vez de un tema genérico cargado de funciones que no usas. Un WordPress liviano puede ser muy rápido; un frontend headless mal hecho puede ser lento.
Si lo que necesitas es un sitio que represente bien tu negocio y que tú mismo puedas mantener, eso es exactamente lo que resolvemos en Sitios Web.
Cuándo headless sí se justifica
Hay escenarios donde la separación paga su costo con creces:
- Tu contenido alimenta más de un canal. Por ejemplo, un catálogo que se muestra en el sitio y también en una app móvil conectada al mismo backend.
- La experiencia es más aplicación que página. Configuradores de productos, buscadores complejos, paneles de cliente con datos en tiempo real.
- El sitio integra varias fuentes. Contenido editorial desde un CMS, precios desde un ERP, stock desde otro sistema. En ese caso el frontend actúa como una capa que une todo, y suele ser parte de un proyecto de sistemas a medida.
- Tienes equipo técnico para sostenerlo. Propio o externo, pero con continuidad.
El punto intermedio que pocos mencionan
No es una decisión binaria. WordPress ofrece una API REST de serie, así que puedes tener un sitio tradicional para todo el contenido editorial y, a la vez, exponer parte de ese contenido a una app o a una sección interactiva construida aparte. Muchas veces este modelo híbrido entrega lo mejor de ambos mundos: autonomía editorial donde importa y flexibilidad técnica solo donde se necesita.
Cinco preguntas para decidir
Antes de elegir arquitectura, responde esto con tu equipo:
- ¿Quién va a actualizar el contenido y con qué frecuencia? Si es una persona sin perfil técnico que publica varias veces por semana, la autonomía pesa más que la flexibilidad.
- ¿El contenido se usa en más de un canal hoy, o tienes un plan concreto (no hipotético) para que se use?
- ¿Tienes acceso permanente a desarrolladores, internos o externos, para mantener dos proyectos?
- ¿Qué parte de la experiencia tiene que comportarse como una aplicación? ¿Todo el sitio o solo una sección?
- ¿Cuánto cuesta el sitio en tres años, no solo en su lanzamiento? Suma hosting, mantenimiento y el costo de cada cambio que tu equipo no podrá hacer solo.
La arquitectura correcta es la que tu equipo puede sostener
Headless no es mejor ni peor que WordPress tradicional: resuelve otro problema. Si tu desafío es tener un sitio rápido, bien posicionado y fácil de actualizar, una arquitectura tradicional bien construida suele ser la respuesta más eficiente. Si tu desafío es distribuir contenido en varios canales o construir experiencias complejas, headless o un modelo híbrido empiezan a tener sentido.
En Medialogic partimos por esas preguntas antes de escribir una línea de código. La tecnología se elige después de entender cómo opera tu negocio, no al revés.
