Contenido como infraestructura: por qué el CMS es tan crítico como el backend

La diferencia entre un CMS que funciona y uno que no está en el modelo de datos subyacente, no en la interfaz de edición.

Un CMS que almacena contenido como texto libre — un campo grande donde va todo — es fácil de implementar y difícil de usar. El frontend no puede hacer nada inteligente con texto no estructurado. No puede mostrar solo el título. No puede filtrar por categoría. No puede traducir campo por campo.

Un CMS con modelo estructurado — campos específicos para cada pieza de información, tipos definidos, relaciones entre entidades — habilita funcionalidad real. El título es un campo separado del cuerpo. Las categorías son una relación, no texto. La imagen destacada es una referencia a un asset en el sistema de uploads, no una URL pegada a mano.

En Pegasuz usamos una tabla site_contents con pares clave-valor para el contenido del sitio institucional. La clave sigue una convención jerárquica: home.hero.title, services.page.lanes, contact.page.form.button.

El valor puede ser texto plano para campos simples, o JSON serializado para estructuras complejas como arrays de servicios o configuraciones de métricas.

El backend expone este contenido a través de /api/site-contents. El frontend lo normaliza en cmsService.js usando normalizeLegacySitePayload: transforma el array de {key, value} en el objeto de payload que las páginas esperan.

La normalización es la capa de traducción. Si el modelo de la base de datos cambia, el cambio se absorbe en la normalización. Las páginas no saben nada del modelo de almacenamiento.

El contenido más crítico para el negocio — las publicaciones del blog, los servicios ofrecidos, los proyectos ejecutados — vive en tablas relacionales propias, no en site_contents.

Esto importa porque esas entidades tienen estructura propia: un post tiene título, contenido, excerpt, imagen destacada, categorías, tags, estado de publicación, fecha. Un servicio tiene nombre, descripción, icono, precio base. Un proyecto tiene nombre, descripción, categoría, año, imágenes.

Cada entidad tiene su propio endpoint. El frontend consulta /api/posts, /api/services, /api/projects por separado. Puede paginar, filtrar, ordenar.

La alternativa — guardar servicios y proyectos como JSON en site_contents — es la opción que se toma cuando se quiere avanzar rápido y se paga caro en el futuro. Cuando el cliente quiere filtrar proyectos por año o buscar servicios por categoría, ese JSON estático no ayuda.

Además del contenido visible, el CMS gestiona configuración que afecta el comportamiento del sistema: idiomas disponibles, idioma por defecto, zona horaria, configuración de analytics, metadata de SEO global.

Las traducciones siguen el mismo modelo: pares clave-valor, pero versionados por locale. Un texto que existe en español puede tener su equivalente en inglés o alemán en el mismo sistema. El frontend solicita el locale correcto según la preferencia del usuario y el CMS responde con el contenido correspondiente.

Esto hace que agregar un idioma nuevo no sea un proyecto de desarrollo — es una operación de contenido. Alguien con acceso al CMS puede agregar las traducciones de todas las keys existentes en el nuevo idioma sin tocar código.

La metáfora más útil para entender el valor del CMS es pensarlo como un contrato operativo entre el equipo técnico y el equipo de negocio.

El equipo técnico define la estructura: qué campos existen, de qué tipo son, cómo se relacionan. El equipo de negocio opera dentro de esa estructura: actualiza valores, publica contenido, configura el sistema.

La frontera es clara. El equipo de negocio no necesita hablarle a un desarrollador para actualizar el texto del hero. El equipo técnico no necesita hacer un deploy para que salga un artículo nuevo.

Esa claridad de roles no es solo eficiencia operativa — es la condición que hace que el software sea sostenible a largo plazo.