CMS headless vs CMS visual vs la vía intermedia

Así analizamos las opciones de CMS para agencias pequeñas y medianas.

TL;DR. Los CMS headless dan libertad al diseñador pero dejan a los editores pyme en paneles desconocidos. Los editores visuales gustan al editor, pero entregan el renderizado a la plataforma e invitan al cliente a romper el diseño. La vía intermedia mantiene la estructura en el código y limita la edición a los campos definidos: encaja mejor en carteras de webs pyme similares.

TL;DR (versión rápida)

• Los CMS headless ofrecen libertad de diseño, pero a menudo son demasiado complejos para los editores de pymes.
• Los editores visuales son fáciles de usar, pero conllevan riesgos de diseño y bloqueos de rendimiento.
• El enfoque intermedio mantiene la estructura en el código y restringe la edición a campos definidos, lo que según nuestra experiencia es ideal para administrar muchos sitios similares.

Cualquier agencia web con algunos años de experiencia ha tenido esta conversación. El cliente quiere editar el contenido él mismo. El diseñador quiere que el diseño se mantenga intacto. El desarrollador quiere algo que pueda desplegar y olvidar. Elegir un CMS es elegir cuál de los tres está dispuesto a sacrificar.

A menudo se describe el mercado como dividido entre dos respuestas - CMS headless y editores visuales por bloques - y existe una tercera vía entre ellas que recibe menos atención pero que probablemente se adapta mejor a la mayoría de las carteras de agencias.

CMS headless

Un CMS headless es un repositorio de contenido puramente backend que proporciona datos estructurados a través de una API y deja el renderizado del frontend completamente en manos del desarrollador.

Un CMS headless es un almacén de contenido sin capa de presentación. El contenido está estructurado (campos tipados, relaciones, idiomas). El frontend es su problema. Lo construye con el framework que prefiera; se comunica con el CMS a través de una API.

Ejemplos: Sanity, Contentful, Strapi, Storyblok, Hygraph, Caisy.

Lo que hace bien: libertad de diseño total. El contenido está estructurado, por lo que el frontend puede renderizarlo como exija el diseño. Versiones, borradores, localización, registros de auditoría - todos los recursos orientados al desarrollador están presentes.

Lo que hace mal para el editor de una pyme: la experiencia del editor varía enormemente. Algunos CMS headless tienen un editor cuidado (Sanity Studio, Storyblok). Otros son esquemas sin refinar con scaffolding de administración (Strapi, el extremo más orientado a desarrolladores del mercado). Para un editor de pyme que lleva diez años usando WordPress, el panel desconocido puede suponer una fricción real.

Para quién es adecuado: agencias con un equipo frontend sólido, que trabajan con clientes con personal técnico y necesitan la máxima libertad de diseño. Según nuestra experiencia, es la respuesta correcta para la mayoría de los proyectos de agencia de nivel alto y para la mayoría de los sitios de marketing de producto.

Editor visual por bloques

Un editor visual por bloques es una herramienta low-code donde los editores construyen páginas arrastrando y soltando, pero que depende completamente del motor de renderizado propietario de la plataforma.

Un editor visual por bloques permite al editor componer páginas arrastrando bloques sobre un lienzo. El resultado lo renderiza la propia plataforma - la agencia no controla la capa de renderizado.

Ejemplos: Wix, Squarespace, Webflow, Elementor (un plugin de WordPress), Duda.

Lo que hace bien: los editores lo adoran. Arrastrar, soltar, cambiar un color, ver el resultado. No se requiere ningún modelo mental de “contenido estructurado”.

Lo que hace mal para la agencia: usted no es dueño del sistema de diseño. Los clientes pueden mover secciones, cambiar colores, alterar tipografías y romper el diseño de maneras que son inmediatamente visibles. La agencia acaba haciendo trabajo recurrente de “recuperación del diseño”, o bien restringe tanto al editor que se pierde el sentido de usar un editor visual en primer lugar.

Lo que hace mal técnicamente: el renderizado es de la plataforma. El rendimiento (como se indica en el informe de rendimiento de Web Almanac), la accesibilidad y el SEO dependen de decisiones que tomó la plataforma. La migración fuera de la plataforma es costosa.

Para quién es adecuado: proyectos muy pequeños donde el cliente es también el diseñador, o donde la agencia está dispuesta a externalizar la capa de renderizado a cambio de que el editor sea autosuficiente. Con frecuencia es la respuesta correcta para un negocio unipersonal que quiere gestionar su propia web sin contratar a una agencia.

La vía intermedia

La vía intermedia es un enfoque híbrido en el que la agencia define la estructura del contenido estrictamente en el código, mientras que el CMS proporciona una interfaz cuidada para que los clientes editen solo los campos permitidos.

La vía intermedia mantiene la estructura en el código (el punto fuerte de la agencia) y el contenido en el CMS (el dominio del cliente). El editor está limitado: los clientes editan únicamente los campos que la agencia ha expuesto. No pueden reordenar secciones, cambiar tipografías ni romper el diseño - pero sí pueden cambiar la foto, editar el texto, añadir una entrada en una lista de preguntas frecuentes o publicar.

Ejemplos: según nuestra experiencia, esto es exactamente Kernset. Consulte las funcionalidades de Kernset para ver el catálogo completo de bloques. Otros ejemplos en este espacio incluyen Statamic (PHP), Tina (de código abierto) y partes de Sanity Studio cuando se usa con esquemas estrictos.

Lo que hace bien: la experiencia del editor es cuidada (porque la agencia construyó solo los campos que importan), el diseño queda fijado en el código (porque la estructura no es editable) y la capa de renderizado es la que eligió la agencia. Es lo más parecido a un “WordPress que no se rompe” que puede obtenerse sin ser WordPress.

Lo que hace mal: menos libertad de diseño para el editor. Si un cliente dice “quiero que esta sección tenga un aspecto completamente diferente en esta página”, la respuesta es “podemos construir un nuevo tipo de bloque para eso, pero será un proyecto pequeño”. Los editores visuales absorben esa petición sin necesidad de un presupuesto de trabajo.

Para quién es adecuado: agencias que mantienen muchos webs de cliente similares - hoteles, clínicas, servicios locales, restaurantes - donde el sistema de diseño es bastante coherente, los clientes no son diseñadores y el objetivo es fijar el diseño y dejar que los clientes editen el contenido. El segmento intermedio de la cartera de la agencia.

Tabla comparativa

Aspecto	CMS headless	Editor visual	Vía intermedia
Libertad de diseño para la agencia	Alta	Baja	Media
Libertad de diseño para el cliente	Ninguna	Alta	Limitada a las regiones definidas
Familiaridad del editor para clientes pyme	Variable	Alta	Media-alta
Capa de renderizado en manos de	La agencia	La plataforma	La agencia
Riesgo de que el cliente rompa el diseño	Bajo	Alto	Muy bajo
Coste recurrente por cliente	Medio	Bajo-medio	Bajo
Ergonomía multitenant	Variable (a menudo configuración por proyecto)	Una cuenta de plataforma por cliente	Integrada
Mejor para	Sitios de producto o de alto nivel	Negocios unipersonales	Carteras de agencia de webs pyme similares

Cómo tomar la decisión

Si se encuentra haciendo estas preguntas, la respuesta correcta suele ser una de las siguientes:

1. “Mis clientes siguen rompiendo el diseño.” Está en el lado equivocado del headless o del visual. Pase a la vía intermedia.

2. “Mis clientes necesitan diferentes maquetaciones por página.” El editor visual se acerca más a lo que necesita - o necesita una biblioteca de bloques más rica en un CMS de vía intermedia.

3. “Mi diseñador quiere libertad total y el cliente solo edita texto.” CMS headless con editor cuidado (Sanity Studio es la elección habitual).

4. “Tengo muchos clientes similares y quiero un solo panel para todos.” Vía intermedia con multitenancia. Kernset.

Dónde encaja Kernset

Kernset es la vía intermedia con administración multitenant. Los esquemas de bloques viven en TypeScript (el repositorio de la agencia), el editor se renderiza contra esos esquemas (los clientes ven solo los campos que la agencia ha expuesto) y la web del cliente puede alojarse en cualquier lugar: un hosting compartido económico, Vercel o un servidor Node propio. Un solo panel gestiona todos los webs de clientes.

No es para todo el mundo. Si su cartera son dos webs de producto con diseño exigente, headless con Sanity Studio probablemente sea un mejor encaje. Si su cartera son cincuenta webs de pyme muy similares y quiere gestionarlas todas bajo un solo panel, la vía intermedia es exactamente la herramienta adecuada.

Preguntas frecuentes

¿Qué CMS es mejor para una agencia web pequeña?

El “mejor” CMS depende del cliente típico de la agencia. Para sitios de productos de alto nivel y personalizados, un CMS headless suele ganar. Para proyectos puntuales de bajo presupuesto donde el cliente es el diseñador, los creadores visuales destacan. Para una agencia que gestiona docenas de sitios similares de pymes donde la coherencia del diseño es clave, un CMS basado en bloques en el espacio intermedio suele ser la opción más sostenible.

¿Se puede usar Kernset como CMS headless para un proyecto Next.js propio?

Sí. Los modos de hosting de sitio estático con caché y el de servidor Node autogestionado son exactamente eso. El contenido vive en Kernset y la web del cliente en Next.js lo consume a través de la API. La restricción es que los esquemas de bloques viven en su código (no en una interfaz de “esquemas” al estilo de Sanity Studio en el panel), que es precisamente la decisión de diseño que hace funcionar la experiencia de la vía intermedia.

¿La vía intermedia no es simplemente un CMS headless con esquemas más estrictos?

En cierto sentido, sí. La diferencia es que Kernset asume que usted VA a definir los esquemas de bloques en el código, y diseña la experiencia del editor alrededor de esa premisa. Un CMS puramente headless con esquemas estrictos puede llegar a un lugar similar, pero usted tiene que construir el acabado del editor por su cuenta.

¿Por qué no ofrecer a los clientes un editor visual para las partes que necesitan flexibilidad?

Puede hacerlo. Las zonas de contenido flexible de Kernset permiten a los clientes añadir y reordenar bloques dentro de una región designada, extraídos de una lista de permitidos que define la agencia. No es un editor visual completo - la lista de permitidos limita lo que pueden añadir - pero ofrece al editor un control estructural significativo sin exponer la cuadrícula de maquetación.

Compárelo con su cartera

Si sigue dudando entre headless, visual y vía intermedia, la forma más rápida de resolver la pregunta es ver Kernset junto a dos de sus webs de cliente más complicadas. Solicitar acceso anticipado - cada mensaje lo lee una persona.