¿Qué es un CMS headless? Diferencia con el CMS clásico

01¿Qué es un sistema de gestión de contenidos?

Un sistema de gestión de contenidos (CMS) es un software que permite a alguien sin conocimientos técnicos añadir y editar páginas, noticias, productos o artículos de blog. En el panel introduce el título, el texto y la imagen; el sistema los publica en el sitio.

En los CMS clásicos, el panel de contenidos, la base de datos y el aspecto del sitio son partes de un único paquete. El panel guarda el contenido y el mismo software lo combina con las plantillas y lo sirve al visitante como una página HTML. A esta estructura se la denomina arquitectura monolítica o integrada.

El enfoque headless divide este paquete en dos. El término «headless» (sin cabeza) expresa que el sistema no tiene una «cabeza», es decir, una capa de presentación fija. La capa de presentación es un proyecto aparte que pide el contenido por API.

02¿Cómo funciona la arquitectura headless?

Una arquitectura headless suele constar de tres partes: el panel de administración donde se introduce el contenido, la API que lo entrega al exterior y una o más interfaces que lo muestran.

1. El editor introduce el contenido: rellena en el panel el título, el texto, la imagen y los campos.
2. El contenido se guarda como datos estructurados: no se guarda la maquetación de la página, sino los campos (título, resumen, cuerpo, autor, fecha).
3. La interfaz envía una solicitud a la API: el sitio web, la aplicación móvil u otro canal recibe el contenido en JSON.
4. La interfaz muestra el contenido con su propio diseño: el mismo contenido se presenta en cada canal de la forma adecuada a ese canal.
5. Se publica el cambio: las páginas se regeneran o, en la siguiente solicitud, se obtienen los datos actualizados.

const yanit = await fetch('https://cms.ornek.com/api/yazilar?limit=3');
const { veriler } = await yanit.json();
veriler.forEach(y => console.log(y.baslik, y.yayinTarihi));

03Diferencias entre headless y CMS clásico

Como se ve en la tabla, el headless aporta flexibilidad y escala, pero exige más trabajo de desarrollo al principio. Por eso no es la elección adecuada para todos los proyectos; debe valorarse según la necesidad.

04Ventajas del headless CMS

Velocidad y rendimiento

En la estructura headless, la interfaz puede generar las páginas de antemano y servirlas desde una CDN. El visitante no espera una consulta a la base de datos en cada solicitud; la página ya está lista. Esto facilita alcanzar los objetivos de Core Web Vitals (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1). Tratamos la velocidad en detalle en nuestra página de velocidad y rendimiento.

Seguridad

El panel de administración puede estar en una dirección distinta del sitio al que accede el visitante. Si el sitio se compone de archivos estáticos, se reduce el código del lado del servidor al que puede apuntar un atacante. Esto reduce la superficie de ataque; pero no olvide que el panel y la API también deben protegerse.

Publicación multicanal

La misma descripción de producto puede usarse en el sitio web, en la aplicación móvil, en una pantalla del punto de venta y en el feed de un marketplace. El contenido se actualiza una vez y cambia en todas partes. A esto se le llama publicación multicanal (omnichannel).

Libertad tecnológica

El equipo de la interfaz puede elegir la tecnología que quiera sin depender del lenguaje de plantillas del CMS. Si quiere renovar la interfaz, el contenido se queda donde está; solo se reescribe la capa de presentación.

05Desventajas y aspectos a tener en cuenta

La flexibilidad de la estructura headless no sale gratis. Muchas funciones que en un sistema clásico vienen de serie, aquí las instala y mantiene el equipo. Antes de decidir, valore uno por uno los puntos siguientes para su propio proyecto; lo que suele ser decisivo no es la tecnología, sino si el equipo y el presupuesto pueden asumir esa responsabilidad adicional.

• Aumenta la dependencia de desarrolladores: añadir una nueva plantilla de página o un componente requiere código.
• La vista previa se instala aparte: para que el editor vea la página antes de publicarla hace falta trabajo adicional.
• Aumenta el número de piezas: el CMS, la API, la interfaz y el alojamiento se gestionan por separado.
• El SEO queda en manos de la interfaz: las etiquetas de título, los datos estructurados y el mapa del sitio deben configurarse bien en el proyecto de la interfaz.
• El modelo de costes es distinto: algunos servicios de CMS en la nube cobran según el contenido, los usuarios o el número de solicitudes a la API.

06¿Qué es Jamstack?

Jamstack es un enfoque de arquitectura web que se menciona a menudo junto con el headless CMS. Las páginas se generan de antemano durante la compilación y se sirven como archivos estáticos desde una CDN; las tareas dinámicas se hacen con API y JavaScript.

En este enfoque el contenido procede del headless CMS, y las páginas las genera un generador de sitios estáticos o un framework como Next.js. Cómo combina Next.js la generación estática y la del lado del servidor lo explicamos en nuestro artículo sobre qué es Next.js.

Jamstack no encaja con todos los proyectos. En contenidos que cambian con mucha frecuencia o se personalizan según el usuario, la generación del lado del servidor o los métodos híbridos pueden ser más adecuados. Lo importante es elegir la forma de generación correcta según la frecuencia con que cambia cada página.

07¿En qué proyectos conviene elegirlo?

Al decidir, mire su contenido antes que la tecnología: ¿cuántos canales hay, con qué frecuencia se actualiza, cuántas personas lo editan y hasta qué punto es crítica la velocidad? Si responde con un sí rotundo a al menos dos de estas preguntas, la estructura headless es una candidata seria; de lo contrario, una arquitectura más sencilla suele dar un resultado más rápido y más económico.

• Marcas multicanal: empresas que usan el mismo contenido en la web, en la aplicación móvil y en pantallas físicas.
• Sitios multilingües y multirregión: que el contenido esté estructurado facilita la gestión de las traducciones.
• Sitios de contenido con mucho tráfico: las páginas generadas de antemano resisten mejor bajo carga.
• Aplicación y sitio a la vez: una tienda online o una plataforma de reservas con aplicación móvil.
• Marcas que renuevan su diseño con frecuencia: quienes quieren reescribir la interfaz desde cero sin trasladar el contenido.

08¿En qué fijarse al migrar?

En la migración de un sitio existente a una estructura headless, el paso más importante es construir bien el modelo de contenido. En lugar de trasladar las páginas tal cual, hay que dividir el contenido en campos con sentido: nombre del producto, descripción corta, descripción larga, imagen, categoría, etc.

El segundo paso es conservar la estructura de URL. Si las direcciones van a cambiar, hay que planificar una redirección 301 para cada dirección antigua; de lo contrario, la visibilidad en los buscadores puede resentirse. En este punto sirven de guía los principios del diseño web SEO.

También conviene hablar desde el principio de con qué tecnología se servirá el contenido en la interfaz. El reparto de tareas entre la interfaz y el servidor lo tratamos en nuestro artículo sobre la diferencia entre frontend y backend, y uno de los lenguajes que siguen siendo habituales en el servidor, en el artículo qué es PHP. En los proyectos de diseño web de Aurora Yazılım, la estructura del contenido, los objetivos de velocidad y la facilidad de gestión se planifican conjuntamente.