CMS headless para una web B2B: cuál elegir

Elegir un CMS headless para una web B2B se reduce a tres preguntas: quién edita, con qué frecuencia y en cuántos idiomas. Decide por el trabajo diario de tus editores, no por listas de funciones. A un equipo pequeño que edita una vez al mes le pueden bastar archivos en git. Si marketing publica cada semana en varios idiomas, un CMS headless en la nube suele compensar.

Un CMS headless guarda el contenido y lo sirve mediante una API. La web, a menudo hecha en Next.js, decide cómo se ve. Esa separación da libertad en el front end y una experiencia de edición más limpia. También añade un proveedor, un modelo de contenido que diseñar y una factura que prever. Esta guía te ayuda a decidir si el intercambio merece la pena y qué tipo de CMS encaja contigo.

Qué cambia un CMS headless para un equipo B2B

En un CMS tradicional como WordPress, contenido, plantillas y plugins viven en el mismo sistema. Un editor puede cambiar la maquetación, y una actualización de plugin también. En un enfoque headless, los editores gestionan contenido estructurado y las plantillas son cosa de desarrollo.

Para una web de marketing B2B, esa separación tiene ventajas reales:

• Páginas coherentes. Los editores rellenan campos, así que un caso de éxito siempre parece un caso de éxito.
• Menos piezas en producción. La web pública puede ser estática o renderizada en servidor, sin panel de administración expuesto en tu dominio.
• Reutilización. La misma descripción de producto alimenta la web, la página de precios y una presentación comercial.
• Velocidad. Las páginas se generan de antemano y se sirven desde una CDN.

El precio es menos libertad de maquetación para los editores, salvo que diseñes bloques flexibles a propósito. Ese equilibrio está detrás de todas las decisiones que vienen a continuación.

¿De verdad necesitas un CMS headless B2B?

No siempre. Aquí tienes una prueba sencilla basada en cómo trabaja tu equipo.

• Quizá no lo necesites si editan menos de tres personas, los cambios son mensuales y publicas en un solo idioma. Archivos Markdown en el repositorio, con un editor sencillo basado en git, pueden funcionar bien.
• Probablemente lo necesites si marketing publica páginas cada semana sin desarrolladores, trabajas en varios idiomas o necesitas borradores, publicaciones programadas y aprobaciones.
• Lo necesitas seguro si la revisión legal o de cumplimiento forma parte de publicar, o si varios equipos comparten una misma biblioteca de contenido.

Si la respuesta sincera es «editamos dos veces al año», invierte el presupuesto en diseño y contenido. Un CMS que tu equipo nunca abre es una cuota mensual a cambio de nada.

Criterios que importan a un equipo de marketing B2B

Las tablas comparativas suelen listarlo todo. Estos son los puntos que deciden cómo se siente el CMS tras seis meses de uso real.

Edición y vista previa

Los editores necesitan ver la página antes de publicarla. Pide una vista previa en vivo con tu front end real, no un formulario genérico. Comprueba cuánto tarda una persona sin perfil técnico en publicar un cambio sencillo.

Modelo de contenido

Un buen modelo de contenido refleja tu negocio: productos, sectores, casos, equipo, preguntas frecuentes. Debe permitir referencias entre tipos, para que la página de un sector muestre sus casos sin copiar y pegar.

// Un modelo de contenido B2B pequeño, simplificado
caseStudy {
  title: string
  industry: reference -> industry
  services: reference[] -> service
  summary: text (max 300)
  body: richText
  publishedAt: date
}

Si el modelo está mal, cada página cuesta más de construir y de editar. Normalmente lo diseñamos antes de cerrar el diseño visual.

Localización

Las webs B2B suelen pasar de un idioma a tres. Comprueba si el CMS localiza por campo o por documento y cómo sigue las traducciones. Pregunta cómo afectan los idiomas al precio, porque algunos planes los cobran aparte.

Roles, aprobaciones y auditoría

¿Quién puede redactar, quién publica y quién cambia el modelo de contenido? En sectores regulados también necesitas un historial de quién cambió qué y cuándo. El inicio de sesión único (SSO) importa en cuanto acceden más de unas pocas personas.

Modelo de alojamiento y dependencia del proveedor

Las plataformas en la nube se ocupan de la disponibilidad y el escalado, y pagas por usuario o por uso. Las herramientas open source autoalojadas te dan el control, y tú asumes el hosting y las actualizaciones. En ambos casos, confirma que puedes exportar todo el contenido en un formato documentado.

Precio a tu tamaño real

Calcula el plan que necesitarás dentro de dos años, no el gratuito. Cuenta editores, idiomas, entornos y uso de la API. Un CMS barato para tres editores puede ser caro para quince.

En la nube, open source o en git: cómo se comparan

Casi todas las opciones caben en tres familias. Cada una encaja con un tipo de equipo.

CMS headless en la nube

Algunos ejemplos son Contentful, Sanity, Storyblok e Hygraph. El proveedor gestiona la API de contenido y la aplicación de edición, aunque algunos, como Sanity, permiten personalizar el editor con código. Son los más fáciles de llevar en el día a día. Pagas una suscripción que crece con el equipo y el uso.

Para quién: equipos de marketing que publican a menudo, en varios idiomas, y no quieren mantener ningún servidor.

Open source autoalojado

Algunos ejemplos son Strapi, Payload y Directus. El CMS corre en tu propia infraestructura, o en la nube del proveedor si la ofrece. Tienes control total sobre datos y código, y las actualizaciones y la seguridad son tuyas.

Para quién: equipos con desarrolladores propios, requisitos estrictos sobre dónde se guardan los datos o flujos muy personalizados.

Contenido en git

El contenido vive como archivos Markdown o JSON en el repositorio. Herramientas como Keystatic, Decap CMS o TinaCMS añaden encima una interfaz de edición. No hay base de datos aparte que mantener y cada cambio queda versionado.

Para quién: equipos pequeños, editores técnicos y webs que cambian cada mes, no cada día. Este blog funciona con archivos Markdown justo por eso.

Cómo elegimos el CMS con nuestros clientes

No tenemos un proveedor favorito ni revendemos licencias. La recomendación sale de un descubrimiento breve:

1. Listamos quién edita, qué edita y con qué frecuencia.
2. Mapeamos los tipos de contenido y sus relaciones.
3. Contamos los idiomas de hoy y los de dentro de dos años.
4. Anotamos los requisitos de cumplimiento: aprobaciones, auditoría, ubicación de datos, SSO.
5. Calculamos el precio de las dos o tres mejores opciones al tamaño previsto.

Después construimos primero el modelo de contenido y lo probamos con tus editores sobre contenido real. Cambiar el modelo en la segunda semana es barato. Cambiarlo después del lanzamiento obliga a migrar cada página.

En empresas SaaS suele acabar en un CMS en la nube con un constructor por bloques para las landings y tipos estrictos para el contenido de producto y precios. En nuestra página de diseño web para SaaS repasamos los tipos de página que suelen necesitar estos equipos.

El front end es el mismo elijas el CMS que elijas. Describimos ese stack en nuestra guía sobre la web corporativa con Next.js.

Elige el CMS antes de diseñar las páginas

La elección del CMS da forma al modelo de contenido, y el modelo de contenido da forma al diseño. Decídelo pronto. Configuramos y modelamos el CMS en cada página web corporativa, que empieza en 8500 $ y suele llevar 4-5 semanas. Ahí la configuración del CMS va incluida. En la mayoría de los demás productos es un extra de 2000 $, publicado junto al resto. Si todavía dudas entre un enfoque tradicional y uno headless, nuestra comparativa WordPress vs Next.js explica las diferencias.