← Todas las entradas

Comparativa

¿Cuál es el mejor CMS headless para una IA? Contentful, Sanity y Strapi, a prueba

Dos compañeros mirando una pantalla grande con un cerebro dibujado con luz.

Un CMS headless es un almacén donde vive el contenido, sin la parte que lo enseña: tu web es otra cosa, construida encima. De los tres que conectamos, Contentful es el que más permite —10 de nuestros 14 trabajos, frente a 9 de Sanity y 7 de Strapi— y el motivo no es el rendimiento ni la comodidad para programar, sino una lista corta de cosas poco vistosas: programar, etiquetas y una forma de informar de lo que hay en el espacio. Los tres leen, escriben, editan y publican sin quejarse. La tabla de abajo la imprimen los tres adaptadores que hacen el trabajo.

·

Una cosa antes de nada, porque decide si esta entrada va contigo: un CMS headless es donde vive el contenido, y este producto es una forma de hablar con uno. Nosotros no somos un CMS headless, no guardamos nada y no servimos nada a ningún visitante.

Por qué estos tres no son como los demás

En WordPress o en Joomla, el gestor de contenidos y la web son la misma cosa en la misma dirección. En estos tres no: tu web es lo que alguien construyó encima del almacén de contenido, y el almacén está en otro sitio. Así que lo que conectas es un espacio, un conjunto de datos o un proyecto, no una dirección que un visitante vaya a escribir nunca.

Eso tiene dos consecuencias prácticas. La primera: aquí no hay una "página" que publicar en el sentido de las demás plataformas. Publicar marca una entrada como disponible para lo que lea el almacén, y que un visitante la vea después depende de una web que no controla nadie de aquí; Contentful en concreto informará de algo como publicado sin que ningún visitante pueda llegar a verlo, porque la parte pública no se ha vuelto a generar. La segunda: no hay un modelo de contenido fijo. En las otras plataformas una entrada es una entrada; aquí los tipos te los inventaste tú, y no se puede escribir nada hasta que alguien diga cuál de tus tipos guarda los artículos y cuál de sus campos es el cuerpo. Eso lo preguntamos durante la configuración en lugar de adivinarlo, y es la parte más lenta de todo esto y la que nadie debería automatizar.

Los tres, uno al lado del otro

Lo que cada plataforma nos deja intentar, leído del adaptador de esa misma plataforma.
Lo que puedes pedir Contentful Strapi Sanity
Leer el contenido Sí Sí Sí
Crear contenido Sí Sí Sí
Editar contenido Sí Sí Sí
Publicar contenido Sí Sí Sí
Programar publicaciones Sí No No
Gestionar imágenes y archivos Sí Sí Sí
Gestionar categorías y etiquetas Sí No No
Editar la información SEO No No Sí
Gestionar los menús No No No
Tipos de contenido propios Sí Sí Sí
Cambios en lote No No No
Información del sitio Sí Sí Sí
Gestionar redirecciones No No No
Información de administración Sí No Sí

Esta tabla se genera a partir de los adaptadores al cargar la página, no está escrita a mano. Una casilla verde significa que el software intentará ese trabajo en esa plataforma; una gris significa que se niega antes de intentarlo, porque la plataforma no ofrece ninguna forma admitida de hacerlo. El trabajo por lotes es la única fila vacía en todas las plataformas: ningún adaptador lo reclama todavía, y la página de automatización lo dice también.

Léelo antes de la tabla. Una casilla verde significa que nuestro software intentará ese trabajo, no que alguien lo haya visto funcionar en una instalación real de esa plataforma. Esa afirmación más fuerte se anota capacidad por capacidad con su fecha, y hasta hoy se la han ganado WordPress, Joomla, Drupal, Craft CMS, Concrete CMS, Webflow, Wix, Contentful y Sanity. Cuando uno de estos tres no está en esa lista, su adaptador se escribió desde la documentación y el código de la plataforma, cada fila de capacidades lo dice, y no vamos a difuminar la diferencia quitándolo de aquí.

Contentful: 10 de 14, y el único que sabe programar

Las acciones programadas de Contentful son una función real de su API de gestión: Contentful guarda la cita y publica la entrada él mismo, en vez de que algo nuestro se despierte a hacerlo. Tiene además etiquetas, que es lo más cerca que está ninguno de los tres de tener categorías, y bastante información sobre un espacio como para informar de él. Dos cosas que conviene saber. Sus etiquetas nuevas son privadas por defecto, y una etiqueta privada es invisible para la API que sirve tu web, así que una etiqueta creada para archivar un artículo daría algo que tu propia web no puede leer; las nuestras se crean públicas y lo decimos. Y una conexión con Contentful queda fijada a un entorno de un espacio: dos entornos son dos webs conectadas aquí, y es a propósito, porque la alternativa es que una petición acabe en el entorno equivocado. Contentful no tiene datos de SEO propios, así que esa fila sale gris: cualquier campo que uses para una meta descripción es un campo que te inventaste tú, y escribir en el campo inventado de alguien bajo el nombre de una capacidad de SEO es una promesa que no vamos a hacer.

Sanity: 9 de 14, y el único donde un borrador es otro documento

Sanity guarda los borradores como documentos aparte en lugar de como un estado de uno solo, lo cual es limpio y pilla a todo el mundo una vez: editar un artículo publicado guarda en el borrador y deja intacto lo que leen los visitantes. La descripción de nuestra propia herramienta prometía lo contrario, y era cierta en todas partes menos aquí. El otro hecho con forma de Sanity es su esquema. Tradicionalmente el esquema de Sanity vivía en el código de tu Studio, donde nada de fuera puede leerlo, pero una orden reciente del Studio lo guarda dentro del propio conjunto de datos, donde sí se puede leer en condiciones. Si la has ejecutado, leemos tu modelo de contenido de verdad, incluidos los tipos que has definido y todavía no usas; si no, lo único honesto es observar qué tipos tienen de hecho tus documentos, y etiquetamos cada tipo con cuál de las dos cosas es, en vez de llamar a una observación tu modelo de contenido. Sanity sí escribe campos de SEO, cosa que Contentful y Strapi no, y no sabe programar: lo que programa es una entrega de contenido, que es algo genuinamente distinto.

Strapi: 7 de 14, y aquel donde los fallos son silenciosos

Strapi es el más autogestionado de los tres y el que pide más cuidado. Sus tokens se pueden limitar por colección, lo cual está bien; el fallo habitual es que algo sencillamente no esté concedido, y a un token al que le falta un permiso le contestan algo que parece una web vacía en lugar de una negativa. Por eso el adaptador distingue entre "esa colección está ahí y tu token no puede verla" y "no hay nada que se llame así", y dice cuál de las dos es. La trampa mayor está entre Strapi 4 y Strapi 5: los dos publican al crear por defecto y se les impide de dos maneras distintas, así que mandar la instrucción de la versión nueva a una antigua publica un borrador sin terminar en una web en vivo. La versión se averigua por la forma de un registro antes de cualquier escritura, y cuando no se puede averiguar no se escribe nada. Strapi no tiene etiquetas ni categorías propias ni campos de SEO, y ahí está casi toda la distancia entre 7 y 10.

Cómo elegir entre ellos, si estás eligiendo

Nadie elige un almacén de contenido por lo bien que lo alcance un asistente, y hace bien. Pero si la elección está igualada por lo demás, hay tres cosas de la tabla que valen dinero de verdad.

Límite honesto: 9 de 11 plataformas han tenido capacidades ejecutadas contra una instalación real hasta hoy —WordPress, Joomla, Drupal, Craft CMS, Concrete CMS, Webflow, Wix, Contentful y Sanity— y cada uno de estos tres dice con claridad en su propia página en qué estado está cada una de sus filas. Lo que le falta a una comprobación de Contentful de verdad es concreto y no lo tenemos: un espacio con más de un entorno, un alias de entorno y un idioma por defecto que no sea el inglés, que es lo más fácil de equivocar sin darse cuenta en ese adaptador.

Lo que nos preguntan sobre esto

¿CMS AI Agent es un CMS headless?
No. No guarda contenido y no sirve nada a ningún visitante. Es una forma de que un asistente hable con el gestor de contenidos que ya tienes, sea headless o no.
¿Por qué publicar no hace que algo aparezca en mi web?
Porque en un montaje headless publicar deja una entrada disponible para lo que lea el almacén, y tu web es otra cosa que quizá tenga que volver a generarse para que un visitante la vea. Eso es asunto de tu parte pública, no del almacén ni nuestro.
¿Tengo que decirle cuál de mis tipos guarda los artículos?
Sí, una vez, durante la configuración: en los tres, y en Craft y Webflow por el mismo motivo. El modelo de contenido te lo inventaste tú, así que nada puede escribir en él con seguridad hasta que alguien que lo conozca diga qué tipo y qué campos son. Es el único paso que no vamos a adivinar.

Por dónde seguir