Cómo elegir un CMS sin cabeza
Publicado: 2022-03-10Este artículo ha sido amablemente apoyado por nuestros queridos amigos de Storyblok, un CMS sin interfaz amigable con un editor visual, componentes anidados y bloques de contenido personalizables para sitios web y aplicaciones. ¡Gracias!
Las páginas web, como la que está leyendo ahora, tienen texto, imágenes, videos y otros activos para brindarle información. Estos datos serían recopilados y creados en un Sistema de gestión de contenido web (WCMS) por un editor de contenido. Los WCMS han pasado por una evolución al pasar de un CMS tradicional a un CMS desacoplado a un CMS sin cabeza.
Cambiar a un CMS sin cabeza no es una decisión fácil y el proceso de selección no debe tomarse a la ligera. En este artículo, destacaré algunas características principales que todo CMS autónomo debería proporcionar . Exploraremos esas características, los desafíos asociados y lo ayudaremos a elegir un CMS autónomo para satisfacer los requisitos únicos de su organización.
Como director técnico de Luminary, he estado ayudando a nuestros clientes a elegir el mejor CMS, DXP (Plataforma de experiencia digital) o CMS sin cabeza para satisfacer sus necesidades. Con los 21 años de experiencia de Luminary en el espacio digital, mi experiencia de 17 años en el espacio CMS, así como nuestro enfoque en Headless desde 2016, aquí están mis dos centavos sobre lo que debe tener en cuenta.
Cosas a considerar al elegir un CMS sin cabeza
- Conceptos
- Arquitectura de microservicios
- omnicanal
- Para autores de contenido
- Experiencia de edición
- Gestión de imágenes
- Roles de creación
- Flujos de trabajo
- Vista previa del contenido
- Localización de contenido
- Para desarrolladores
- API RESTful y GraphQL
- SDK nativos
- Entornos
- CDN
- Límites de uso
- Otros factores
- Ubicaciones de centros de datos
- Soporte técnico y de ventas.
- Funciones empresariales
- Integración de Infraestructura
- Proveedores de SaaS de renombre
- Integración de CMS sin cabeza como un microservicio
- Los mejores servicios de su clase
- Canales a los que desea dirigirse
- Buenas prácticas de modelado de contenido
- Experiencia de autor
- Estructura de elementos de contenido
- Facilidad de búsqueda de contenido
- Uso excesivo de editores WYSIWYG
- Reutilización de contenido
- Organización de imágenes
- Recortar y entregar imágenes a través de un CDN
- Los mejores servicios de video externos de su clase
- Roles distintos
- Número de usuarios de back-office
- Flujos de trabajo robustos
- Webhooks
- Vista previa de las API del proveedor
- Separe los entornos de preparación y producción por su parte
- Soporte de internacionalización y localización
- Creación de su propio modelo para el manejo de locales
- API REST maduras
- Compatibilidad con GraphQL
- Vista previa y API seguras
- API de administración de contenido para operaciones CRUD
- Pruebas gratuitas para probarlo
- Un SDK compatible con su elección de tecnología, idioma y plataforma.
- Entornos dentro de su CMS sin cabeza
- Capacidad para portar contenido entre entornos
- Almacenamiento en caché de imágenes y contenido a través de CDN
- Capacidades de dominio personalizado
- Límites en ciertas características
- Gasto operativo
- Requisitos legales y reglamentarios para el almacenamiento de datos
- Ventas locales y soporte técnico
- Funciones empresariales sin las que no puede vivir
- El compromiso de la comunidad con el proveedor y el producto.
- Soporte para su elección de Infraestructura
- Ir sin cabeza: casos de uso y para qué sirve
- No pierdas la cabeza: evaluación de personas sin cabeza
Monolítico vs Microservicios
Hemos explorado los conceptos detrás de los CMS sin cabeza en detalle aquí en Smashing Magazine, pero hagamos un resumen rápido. Cuando se trata de un CMS tradicional, el CMS y el sitio web front-end resultante se basan en una arquitectura monolítica. El CMS tradicional intenta y tiene éxito de muchas maneras para satisfacer las necesidades del desarrollador, autor de contenido y comercializador. Por ejemplo, si el CMS se basa en .NET Framework de Microsoft, el sitio web front-end también se crearía con la misma tecnología. Todas las funciones e integraciones también tendrían una estrecha dependencia que, a su vez, da como resultado una base de código monolítica grande y engorrosa.
Los CMS desacoplados han eliminado esta interdependencia hasta cierto punto. Esto se ha logrado al separar el sitio web de front-end del back-office y el repositorio de contenido de CMS.
La arquitectura monolítica pasa a un segundo plano con CMS sin cabeza. El CMS y cualquier otra integración es un microservicio. El CMS en sí se proporciona en un modelo de software como servicio (SaaS) que me gusta denominar contenido como servicio (CaaS). Con esta arquitectura de microservicios, todo lo que obtuvo de su CMS tradicional no sale de la lata. Es posible que tenga diferentes servicios y proveedores para brindarle lo mejor de su clase para cada uno de sus requisitos.
El paso a una mentalidad de microservicios requiere un poco de paciencia. Tuvimos especialistas en marketing con experiencia en CMS tradicionales que se resistieron a la idea de profundizar en múltiples sistemas y servicios al usar un CMS sin cabeza. Logramos acompañarlos en el viaje durante la selección e implementación de su plataforma CMS autónoma. Ahora, son defensores de esa plataforma de CMS sin cabeza, ya que les permite integrar nuevos sistemas y servicios en lugar de estar atados a uno proporcionado por un CMS tradicional.
Tener cuidado de:
Omnicanal en esencia
Por mucho que una mentalidad de microservicios lo ayudaría al integrar un CMS sin cabeza, el verdadero poder de sin cabeza se realiza en su naturaleza omnicanal. Una experiencia omnicanal gira en torno a su cliente y crea una única experiencia de cliente en toda su marca al unificar las ventas y el marketing. Con un CMS autónomo, el contenido se proporciona a diferentes canales, como web, dispositivos móviles, redes sociales, dispositivos inteligentes sin interfaz de usuario, dispositivos IoT e incluso puntos de contacto no digitales, como una tienda física.
Con un CMS sin encabezado, debe definir el esquema para cada modelo de contenido desde cero . El proceso de definición de esta estructura de taxonomía lógica y sólida para los elementos de contenido que crea y publica se conoce como modelado de contenido. Si su primer canal va a ser su sitio web, asegúrese de que su modelado de contenido tenga en cuenta la omnicanalidad para aliviar cualquier dolor futuro. Si solo está buscando un CMS de reemplazo para impulsar su sitio web, eche otro vistazo detenidamente al espacio de CMS tradicional o desacoplado para ver si hay algo que se adapte mejor a sus requisitos.
Al modelar esquemas de contenido, piense en el futuro. Trabajando para una aerolínea importante hace apenas una década, recuerdo haber intentado modelar contenido para dispositivos móviles (¡sí! Había un subdominio separado para un sitio web móvil). Esto fue terriblemente difícil ya que los esquemas de contenido estaban orientados solo a un sitio web de escritorio. Pero la historia sigue siendo cierta incluso hoy en día: debemos estar atentos al modelado de contenido.
Tener cuidado de:
Creando gran contenido
Ya sea un CMS tradicional o un CMS sin cabeza, el requisito principal es administrar el contenido. A los autores de contenido les encantaría trabajar en la oficina administrativa. Si ve que los autores recurren a otras herramientas de creación, como Google Docs, por sus capacidades de comentarios o sugerencias, puede ser una señal de alerta sobre las funciones que le faltan.
Los documentos de Microsoft Word, las hojas de cálculo y los documentos de Google siempre destacan cuando se trabaja con autores de contenido. En lugar de tratar de eliminarlos por adelantado, la forma más fácil de hacer que los autores de contenido trabajen en el CMS es brindarles las funciones que necesitan y las eliminarán automáticamente. Cuando lanzamos el sitio web de Luminary en vivo en un CMS sin cabeza, cada miembro del equipo (50 de ellos) tuvo suficiente acceso para agregar y editar su propio perfil para el sitio web. Funcionó de maravilla sin tener 50 Google Docs volando por todos lados.
Experiencia de edición
La decisión de utilizar un CMS sin encabezado puede ser una decisión de TI. Pero la aceptación de los especialistas en marketing y los autores de contenido dentro de la organización es fundamental para su adopción y éxito. Un CMS sin cabeza que permita a los autores de contenido ingresar contenido fácilmente, encontrar contenido existente y reutilizar contenido es algo que debería salir de la caja.
Para facilitar la creación de contenido, es imprescindible tener editores fáciles de usar , como editores WYSIWYG, editores de texto, menús desplegables y editores personalizados. Se apreciará una interfaz limpia y minimalista que permita al autor de contenido concentrarse en la tarea en cuestión. Una interfaz de edición que permita la edición, el comentario y la creación simultánea de elementos de contenido secundario en la misma interfaz aumentará la productividad de los autores de contenido.
Una palabra de precaución al usar editores WYSIWYG o confiar mucho en cualquier interfaz de edición que produzca HTML. Dado que un CMS sin encabezado está diseñado para atender múltiples canales, confiar en los editores WYSIWYG eliminaría la naturaleza atómica del contenido que se puede reutilizar. Asegúrese de que los editores personalizados permitan acceder a los campos de datos a un nivel granular . Hemos visto que esto dificulta la reutilización de contenido en diferentes canales, como dispositivos móviles y de escritorio, por ejemplo.
Con un CMS sin encabezado, organizar los elementos de contenido en una estructura de árbol no es la norma. Pero es un puente que permite a los autores de contenido pasar fácilmente de un CMS tradicional a uno sin cabeza. Si los elementos de contenido no se visualizan en una estructura de árbol, un motor de búsqueda fuerte con facetas y capacidades de etiquetado es primordial para sus editores de contenido. Esto permite a los autores encontrar y reutilizar contenido existente fácilmente.
Al reutilizar contenido, otro aspecto a considerar es si los elementos de contenido se pueden anidar fácilmente dentro de otros elementos de contenido. Esto permite la máxima reutilización del contenido existente. Pero tenga cuidado con las referencias circulares a contenido que podrían causar dolores de cabeza y problemas de rendimiento. Un ejemplo es un elemento de contenido para un abogado que está vinculado a un elemento de contenido para una experiencia. Entonces, si el elemento de contenido de experiencia está nuevamente vinculado a múltiples elementos de contenido de Abogado, esto podría formar una referencia circular. Busque un CMS sin cabeza con inteligencia incorporada para limitar la profundidad en la API y visualizaciones para mostrar elementos de contenido vinculados para evitar este escollo.
Tener cuidado de:
El valor de una imagen: cómo manejar los medios
Una imagen vale mas que mil palabras. Pero los activos de imagen son pesados para transportar, difíciles de organizar y difíciles de buscar. En un CMS típico, verá recursos de imagen duplicados y mal nombrados con el tiempo. Es importante que los editores de contenido dispongan de herramientas para organizar, categorizar, etiquetar, reutilizar y buscar imágenes dentro de un CMS sin cabeza. Para mí, esto significa organizar los activos en carpetas o contenedores. Pero sería bueno comprender lo que su equipo requiere en términos de gestión de activos estáticos.
La capacidad de cargar una sola imagen, establecer un punto focal y luego manipular sus dimensiones y calidad para diferentes dispositivos y tamaños de pantalla, brinda un gran ahorro de tiempo a un editor de contenido e incluso a aquellos diseñadores/artistas gráficos que trabajan entre bastidores. La entrega de activos estáticos en formatos como WebP a través de una red de entrega de contenido (CDN) también es crucial para ofrecer a sus usuarios un sitio web rápido.
La mayoría de los CMS sin encabezado vienen con estas características listas para usar. De lo contrario, debe decidir qué características puede prescindir de ellas. Hay una advertencia a esa regla. Para una edición extensa de las imágenes originales, debe ceñirse a las mejores herramientas para el trabajo, como Photoshop.
Junto con las imágenes, los siguientes activos más importantes son los videos. Una vez más, con la mentalidad de los microservicios, la transmisión de videos debe dejarse en manos de proveedores de servicios como YouTube, Vimeo y otros servicios de transmisión en línea. Si su CMS sin cabeza puede proporcionarle una buena interfaz de edición para buscar o seleccionar un video de uno de estos proveedores, es una ventaja.
Tener cuidado de:
Roles de creación
Quién puede ingresar contenido y quién puede aprobar o publicar contenido en un sitio en vivo y otros permisos granulares también deben administrarse a través del CMS autónomo. Un equipo de dos personas podría sobrevivir sin tener distintos roles de autor, pero a medida que crecen las organizaciones y los equipos de contenido, los roles de autor son imprescindibles.
He trabajado con equipos de contenido de más de 40 editores y este requisito debe evaluarse cuidadosamente en comparación con el CMS sin encabezado que elija. Si no, reinará el caos. Con el equipo de 40 personas con las que trabajé, teníamos redactores, traductores, personal de control de calidad y aprobadores legales que tenían diferentes permisos para acceder a cierto contenido , variantes de idioma, aprobaciones de flujo de trabajo y derechos de publicación.
La cantidad de roles distintos y usuarios administrativos suele ser la forma en que los CMS autónomos estructuran sus precios. Al comparar puntos de precio entre proveedores, piense en los números actuales y el crecimiento futuro de su equipo de contenido.
Tener cuidado de:
Flujos de trabajo
No todos los elementos de contenido deben administrarse a través de un flujo de trabajo. Pero cuando se necesitan flujos de trabajo, registros de auditoría y aprobaciones, el proceso debe administrarse dentro de su CMS autónomo. Tener un flujo de trabajo sólido creado desde cero en su CMS autónomo le brinda tranquilidad y la oportunidad de manejar cada elemento de contenido de acuerdo con su proceso comercial. La capacidad de integrar sistemas de terceros a través de webhooks o API es una ventaja que debe tener en cuenta.
Tener cuidado de:
Vistas previas de contenido
El editor de contenido ha creado el contenido, ha agregado imágenes y lo ha enviado a través de un flujo de trabajo para su aprobación. Pero, ¿dónde obtienen una vista previa del contenido antes de que esté disponible para el público en general? Aquí es donde entran en juego las API de vista previa para recuperar contenido no publicado y la capacidad de establecer entornos de vista previa.
Con un CMS sin cabeza, al alejarse de la mentalidad de un solo canal, sus editores de contenido no deben esperar ver vistas previas de página completa dentro de la oficina administrativa del CMS. Cada canal debe tener su propio entorno de prueba o de vista previa para ver el borrador del contenido que aún no se ha publicado. Este podría ser un sitio provisional para su sitio web o una versión instalada localmente de su aplicación móvil. Una función de vista previa debe estar disponible en el plan de precios que haya elegido para el CMS sin interfaz de su elección.
Tener cuidado de:
locales
Si su contenido debe servirse en diferentes lugares, ese requisito debe identificarse al principio de su proyecto. La modificación es posible, pero no es una actividad divertida. Se debe pensar y documentar cómo administra el contenido y los activos entre culturas e idiomas. Recomendaría crear un modelo para identificar qué idiomas y activos heredan o se establecen de forma predeterminada de otro. Luego, asegúrese de que su elección de CMS autónomo respalde ese modelo o explore vías para lograr el mismo resultado de manera diferente.
Tener cuidado de:
Crear un gran contenido siempre es importante. Por lo tanto, los autores de contenido deben tener la mejor experiencia posible en sus actividades diarias para que su transición a un CMS autónomo sea un éxito.
“
El tiempo de desarrollo es precioso
Con un CMS sin cabeza, la participación del desarrollador es imprescindible. Podría ser un desarrollador back-end o un desarrollador front-end que consume la API sin interfaz para mostrar contenido en el sitio web. Pero una vez que se realiza el desarrollo inicial, un autor de contenido debería poder trabajar con una intervención mínima. Ese es el punto de usar un CMS. También es válido para CMS sin cabeza.
Si bien se tienen en cuenta los autores de contenido al comparar funciones, también se deben explorar las funciones de desarrollador. En esta sección, veremos características que ahorrarán tiempo a los desarrolladores.
Compatibilidad con API/GraphQL
Una API madura, que permita la selección, la paginación y la proyección de elementos de contenido, es fundamental para que un desarrollador trabaje con un CMS autónomo. La compatibilidad con GraphQL lista para usar es otro factor definitorio, ya que permitirá al desarrollador definir el resultado que necesita en un nivel muy granular. La documentación completa y las muestras de código también son imprescindibles.
Asegúrese de que sus desarrolladores estén satisfechos con las API de recuperación de contenido antes de comprometerse con un CMS sin cabeza. No olvide las API de vista previa, las API seguras y la facilidad de usarlas a través del código. ¿Quieres automatizar la creación de contenido? Entonces se deben considerar las API de administración de contenido .
Las API de administración de contenido han sido una bendición, ya que automatizamos la importación de más de 2000 publicaciones de blog desde un sitio de WordPress a un CMS autónomo. Todas las publicaciones del blog y las imágenes relacionadas se importaron con un trabajo mínimo para los autores del contenido. Algunos CMS sin cabeza ofrecen complementos de Hojas de cálculo de Google y otras herramientas ingeniosas para hacer esto con solo hacer clic en un botón.
Con muchos CMS autónomos que ofrecen pruebas gratuitas, es una buena idea probarlos para ver su idoneidad y conformidad con su elección de creación y recuperación de contenido.
Tener cuidado de:
SDK nativos
Los kits de desarrollo de software (SDK) para diversas tecnologías, idiomas y plataformas están disponibles directamente del proveedor de Headless, una iniciativa de código abierto o un tercero. Asegúrese de que estos SDK sean compatibles con la tecnología, el idioma y la plataforma en los que creará su sitio web o aplicación para el consumidor. Por mucho que las API RESTful y GraphQL le permitan consultar contenido, tener un SDK nativo podría reducir significativamente las horas de desarrollo.
En Luminary, trabajar con SDK nativos para CMS autónomos nos ha permitido adoptar las últimas tecnologías como Microsoft .NET Core y .NET 5. Además, construir sobre un SDK existente nos ha permitido seguir las mejores prácticas recomendadas por el proveedor mientras ahorramos hora.
Tener cuidado de:
Entornos
Un sitio web o una aplicación para una tienda familiar podría seleccionar y obtener una vista previa del contenido con un único entorno de producción. Pero a medida que crecen las organizaciones, los equipos y las funciones, se hacen necesarios múltiples entornos para seleccionar y obtener una vista previa del contenido. Su CMS autónomo no solo necesita proporcionar entornos, sino que su aplicación de consumo también debe tener entornos configurados. Se deben considerar métodos para actualizar el contenido en todos los entornos.
Tener cuidado de:
Imágenes, archivos y CDN
Hablamos de la gestión de imágenes cuando hablamos de funciones para el autor del contenido. Desde la perspectiva del desarrollador, no solo los activos estáticos deben almacenarse en caché en una CDN. Muchos CMS sin cabeza almacenan en caché el contenido recuperado a través de las API RESTful o GraphQL. Esto acelera el proceso de recuperación y aporta mejoras de rendimiento a su aplicación.
Si bien el almacenamiento en caché de CDN es muy útil, hay momentos en que la corrupción de caché o los elementos almacenados en caché más antiguos pueden crear problemas . La capacidad de purgar la caché de CDN o la capacidad de extraer el contenido más reciente con encabezados HTTP específicos debe ser parte de la funcionalidad API de su CMS sin cabeza.
La capacidad de usar dominios personalizados en una CDN para entregar su contenido o activos estáticos puede ser un requisito que debe tener en cuenta.
Tener cuidado de:
Límites de uso entre planes
Otro factor a considerar son los límites de uso establecidos para cada plan al que se suscriba en su elección de CMS sin cabeza. Es necesario pensar en la cantidad de elementos de contenido, el consumo de ancho de banda, la cantidad de usuarios administrativos, la cantidad de llamadas a la API y los límites de velocidad. Al planificar los límites de uso, tenga en cuenta el uso actual y el uso futuro. Recuerde que muchos CMS sin cabeza funcionan por suscripción y le permiten actualizar casi instantáneamente a planes con límites más altos.
Sin embargo, vale la pena saber cuántos usuarios utilizarán la plataforma y si la solución necesitaría ampliarse masivamente. Fuimos testigos de que un cliente recibió una factura muy alta ya que, sin saberlo, agregó una gran cantidad de usuarios por encima de su cuota asignada. Es una buena idea que los administradores estén al tanto de lo que ofrece su plan Headless y estén al tanto del uso.
Considere mantenerse bajo los límites de uso en sus límites actuales con almacenamiento en caché del lado del cliente, generadores de páginas estáticas y API inteligente o llamadas GraphQL para reducir sus gastos operativos.
Tener cuidado de:
El tiempo de un desarrollador es caro. Mientras que un CMS sin encabezado se promociona como un CMS fácil de usar para desarrolladores, cada proveedor tiene diferentes funciones que admite de forma nativa. Es muy recomendable comprenderlos y compararlos con las necesidades de sus desarrolladores.
“
Otros factores
Hay algunos otros factores que pueden no afectar al autor del contenido o al desarrollador. Esto podría abarcar desde el marketing hasta las finanzas y los requisitos legales y reglamentarios para su industria y su negocio.
Ubicaciones de centros de datos
Una pregunta que nos hacen a menudo es, ¿dónde se almacenan los datos? Sí, en la nube. Pero qué centro de datos geográficos es una pregunta importante debido a los requisitos legales y reglamentarios de ciertas empresas. Un CMS sin cabeza que le permita almacenar datos en el centro de datos de su elección puede ser un factor crítico para decidir qué CMS elegir.
Soporte técnico y de ventas
La capacidad de recibir soporte técnico y de ventas en su zona horaria es otro factor decisivo al elegir su CMS autónomo. No tener un vendedor local ha inclinado muchos proyectos a favor de aquellos vendedores que tienen gente sobre el terreno en la región correspondiente.
Tuvimos una gran organización NFP (sin fines de lucro) que eligió un proveedor de CMS sin cabeza debido a la capacidad de almacenar datos en un centro de datos de Azure dentro de Australia. Tener soporte de ventas en el terreno y soporte técnico las 24 horas aseguró la venta para ese proveedor de CMS sin cabeza.
Tener cuidado de:
Características empresariales a tener en cuenta
Algunas organizaciones grandes pueden requerir un inicio de sesión único (SSO) vinculado al sistema de autenticación de la empresa o registros de auditoría que se pueden consultar fácilmente. Puede haber integraciones a los sistemas existentes y ciertas certificaciones ISO que deben estar vigentes antes de que un producto SaaS se considere adecuado. Hacer una lista de estas características empresariales y otras exclusivas de su organización de nivel empresarial es un buen punto de partida al elegir un CMS autónomo.
La comunidad en acción
Otra área que generalmente se pasa por alto es la comunidad en torno a un CMS sin cabeza determinado. ¿Hay gente por ahí que sienta pasión por el producto? No estoy hablando de los píos de marketing del proveedor. ¿Hay suficientes recursos de código abierto compartidos por las personas que usan la herramienta? Es posible que esto no sea un factor decisivo, pero lo ayudará cuando se encuentre en un aprieto durante la fase de implementación o soporte de un proyecto.
Integración de Infraestructura
Con los CMS sin cabeza, no está atado a la tecnología, el idioma o la plataforma. La tecnología o plataforma en la que se construye el CMS sin cabeza no influye en la aplicación del cliente. Puede usar una tecnología de su elección desde .NET hasta Node.js, su sistema operativo podría ser Windows, Linux o macOS, y su lenguaje podría ser cualquier cosa, desde Python hasta C#.
Del mismo modo, cuando se trata de adquirir infraestructura, puede optar por alojar su sitio en Netlify, Azure, GCP o AWS. La arquitectura de su sitio web y sus decisiones de infraestructura ahora se basan únicamente en sus requisitos. También hay integraciones nativas de primera clase con servicios como Gatsby Cloud que traen más combos que te hacen la vida más fácil. Para algunos, esta podría ser una decisión importante y debe tomarse hablando con algunos profesionales expertos en el espacio sin cabeza.
Tener cuidado de:
Nuestra experiencia en Luminary
En Luminary, hemos tenido la suerte de asociarnos con CMS autónomos como Acoustic, Contentful, Kentico Kontent y Umbraco Heartcore. Hemos estado trabajando con algunos de estos CMS desde las versiones beta de sus plataformas. Las hojas de ruta públicas, el excelente soporte técnico y la atención de nuestras solicitudes de funciones han sido algunos de nuestros aspectos más destacados con estas plataformas.
Hemos tenido experiencia abordando SEO para sitios web sin cabeza con implementaciones solo de front-end, almacenando en caché páginas de listas grandes, manejando grandes cachés del lado del servidor e integrando otros microservicios con CMS sin cabeza. Cada uno de estos tenía sus desafíos únicos que debe tener en cuenta. Además, las tareas simples en un CMS tradicional, como el envío de formularios y la búsqueda de sitios, deben estar bien pensadas junto con funciones más avanzadas, como la autenticación de usuarios y la autorización con servicios de terceros.
Si elige el CMS sin cabeza correcto con los indicadores anteriores y con el socio de implementación correcto, debería terminar con un CMS sin cabeza que hace felices a los vendedores, editores de contenido felices y desarrolladores felices.