Escrito por
Nacho Seoane
Publicado el
Compartir
Para elegir el CMS de tu empresa, comprueba que las personas que van a usarlo pueden completar sus tareas habituales con los permisos que tendrán al recibir la web. Publicar un artículo, cambiar una imagen, revisar una traducción y corregir un error son pruebas más útiles que una demostración realizada enteramente por el proveedor.
Un gestor de contenidos permite preparar y actualizar información de la web. La autonomía que obtengas depende también de cómo estén organizados los campos, las plantillas y la publicación. Esta guía propone ocho pruebas y una ficha para comparar propuestas antes de contratar.
TL;DR — Elegir el CMS por el trabajo del equipo
- Empieza por las tareas que repetís. Lleva a la demostración contenido representativo de vuestra empresa.
- Prueba con la cuenta de un editor. Los permisos de administrador pueden ocultar limitaciones del trabajo diario.
- Distingue contenido y estructura. Cambiar un texto y crear una plantilla nueva requieren capacidades diferentes.
- Comprueba la vista previa y la publicación. Guardar un cambio no demuestra que haya llegado a la web.
- Prueba los idiomas por separado. Define quién traduce, revisa y publica cada versión.
- Incluye la recuperación de errores. El equipo debe conocer qué puede deshacer y cuándo necesita soporte.
- Compara ocho tareas con evidencias. La ficha permite registrar ayuda necesaria, límites y coste pendiente.
Qué debería poder editar tu equipo
El alcance del CMS debe describir acciones concretas sobre contenido concreto. Una frase como «web autogestionable» deja abierta una pregunta: qué podrá gestionar exactamente la persona que la recibe.
Empieza por un inventario sencillo: artículos, servicios, proyectos, equipo, preguntas frecuentes y datos de contacto. Para cada tipo, anota quién lo cambia, qué campos necesita y qué relaciones tiene con otras páginas. Por ejemplo, actualizar el cargo de una persona debería tener un recorrido claro si ese dato aparece en su ficha y en varios proyectos.
Separa tres niveles de cambio: editar campos existentes, crear páginas con bloques preparados y modificar el diseño o las funciones. Decide cuáles necesitas en el trabajo habitual y cuáles puedes encargar al equipo técnico. No hace falta dar libertad para cambiar toda la estructura para permitir que marketing publique un caso de estudio.
Ese alcance debe aparecer en el presupuesto de la web a medida, junto con la configuración, la formación y el soporte previsto.
Qué tipo de CMS conviene valorar
Valora cada enfoque por el contenido, la autonomía y el mantenimiento que necesitas. Las siguientes opciones describen formas de organizar el trabajo; no son un ranking de marcas y pueden combinarse en una misma solución.
| Enfoque | Cuándo merece una prueba | Qué comprobar antes de elegir |
|---|---|---|
| CMS integrado con plantillas y editor de páginas | La prioridad es mantener una web y publicar contenido dentro de una estructura conocida | Qué puede cambiar el editor, qué queda protegido y quién mantiene temas o extensiones |
| CMS separado de la web, habitualmente llamado headless | Necesitas contenido estructurado, relaciones entre fichas o reutilización en varios canales | Vista previa conectada, publicación completa y soporte para la parte visible de la web |
| Edición con bloques preparados | El equipo crea páginas nuevas a partir de componentes acordados | Si los bloques cubren sus campañas y qué ocurre cuando necesita uno nuevo |
La tabla es una propuesta de evaluación de Apogeo. La facilidad de uso debe comprobarse en la implementación ofrecida, no deducirse de la categoría.
Un CMS separado de la web también puede tener edición visual. La documentación de Sanity sobre edición visual describe vistas previas conectadas al contenido y acceso al campo correspondiente desde la página. Esa capacidad necesita integrarse con la web: conviene pedir verla funcionando en la propuesta concreta.
Ocho pruebas para la demostración del CMS
Pide que una persona de tu equipo haga las pruebas con su futura cuenta de editor. Utiliza una web de prueba y contenido sin datos sensibles. El proveedor puede explicar el funcionamiento al empezar; después registra dónde hace falta su intervención.
| Prueba | Tarea del equipo | Evidencia que conviene guardar |
|---|---|---|
| 1. Editar contenido | Cambiar un titular, una imagen y su texto alternativo | Vista previa correcta en escritorio y móvil |
| 2. Crear una pieza | Preparar un artículo o un caso con los campos y bloques acordados | Borrador completo sin modificar una plantilla |
| 3. Revisar antes de publicar | Compartir un cambio con quien lo aprueba | Recorrido de revisión y estado público anterior conservado, si ese es el requisito |
| 4. Publicar | Hacer visible la pieza de prueba | URL pública correcta y tiempo observado hasta verla actualizada |
| 5. Usar permisos distintos | Preparar contenido con una cuenta sin autorización de publicación | Acciones permitidas y restringidas comprobadas |
| 6. Gestionar idiomas | Actualizar una versión y revisar qué ocurre en las demás | Idiomas pendientes identificados y publicación según el flujo acordado |
| 7. Corregir un error | Recuperar una versión anterior del contenido de prueba | Resultado restaurado y límites de recuperación anotados |
| 8. Recuperar el contenido fuera del panel | Solicitar y revisar una exportación representativa | Archivos, imágenes y relaciones identificados, con responsable de exportación |
Esta prueba no tiene un tiempo universal de aprobado. Registra cuánto tarda vuestro equipo y qué ayuda necesita. Si una función requiere un plan adicional, una extensión o desarrollo, inclúyelo en la comparación. Una función prometida para más adelante queda pendiente de demostrar.
Para la prueba de permisos, WordPress ofrece un ejemplo concreto: sus roles y capacidades distinguen al autor, que puede publicar sus entradas, del colaborador, que puede redactarlas pero no publicarlas. Comprueba siempre los permisos de la configuración entregada; el nombre del rol por sí solo no sustituye la prueba.
Idiomas, revisiones y cambios que requieren soporte
Define qué se publica junto, qué puede publicarse por separado y qué puede recuperarse. Tener campos en dos idiomas no responde por sí solo a esas preguntas.
Sanity documenta dos formas de organizar contenido multilingüe: varios idiomas dentro de un documento o documentos relacionados por idioma. La segunda permite publicar versiones de forma independiente. La decisión debe corresponder al trabajo de traducción y aprobación del equipo, y requiere comprobar también el resultado en las URLs públicas.
Para corregir errores, la documentación de revisiones de WordPress explica cómo comparar cambios y restaurar una revisión de contenido. No des por hecho que ese historial recupera también toda la configuración, los archivos o las conexiones de la web. Pide que se distingan las revisiones editoriales de las copias de seguridad.
También habrá cambios fuera del alcance del editor: una nueva conexión con el CRM, un tipo de contenido no previsto o un componente con otro comportamiento. Deja por escrito quién los realiza y cómo se presupuestan. Si el proyecto sustituye una web existente, trata el traslado de contenido y URLs como parte del plan de migración de la web.
Ficha para comparar propuestas de CMS
Copia esta ficha y complétala con cada proveedor durante la misma prueba. El recurso es una propuesta propia para registrar evidencias; no certifica productos ni puntúa automáticamente la calidad del CMS.
Propuesta y fecha:
Persona del equipo que realiza la prueba:
Cuenta, rol y entorno utilizados:
Contenido de prueba:
Para cada una de las ocho tareas:
- Necesaria para nuestra empresa: sí / no
- Resultado: completada / con ayuda / pendiente / no incluida
- Evidencia o URL de prueba:
- Tiempo observado y ayuda recibida:
- Límite detectado:
- Configuración, plan o coste adicional:
- Responsable y fecha para resolverlo:
Antes de decidir:
- Tareas imprescindibles todavía pendientes:
- Quién mantiene CMS, web y conexiones:
- Formación y documentación incluidas:
- Cómo recibe la empresa los accesos y el contenido:
- Próxima comprobación acordada:Como ejemplo ficticio, un equipo que publica casos en español e inglés puede necesitar que la versión española salga antes de que termine la traducción. Si la demostración solo permite publicar ambas juntas, queda una diferencia concreta que resolver. No implica descartar toda la herramienta: permite pedir una configuración adecuada y su coste antes de contratar.
Preguntas frecuentes
Estas preguntas ayudan a concretar la autonomía editorial que vas a contratar. Las respuestas deben contrastarse con la configuración y el alcance de cada propuesta.
¿Podré cambiar cualquier parte de la web sin un desarrollador?
Podrás cambiar lo que se haya preparado como editable y permita tu cuenta. Pide una lista de campos, bloques y tipos de página. Si quieres crear nuevas páginas, comprueba ese recorrido durante la prueba; editar el texto de una página existente no demuestra que puedas crear otra con una estructura diferente.
¿Un CMS headless es demasiado complicado para marketing?
La complejidad para el editor depende del panel y de su conexión con la web. Un sistema con campos claros y una vista previa útil puede resultar manejable. También puede necesitar más trabajo de configuración. Pide a marketing que complete las mismas tareas en las alternativas que estés valorando.
¿Tener un CMS elimina el mantenimiento técnico?
La edición de contenido y el mantenimiento son trabajos distintos. Aunque tu equipo publique sin ayuda, alguien debe atender los cambios de la plataforma, las incidencias y las conexiones acordadas. Pide que la propuesta identifique ese responsable y el alcance de su servicio, además del coste de la herramienta.
¿Cómo sé si la web permite trabajar en varios idiomas?
Prueba una actualización completa en cada idioma necesario. Comprueba textos, imágenes cuando cambien por mercado, enlaces, vista previa y publicación. Anota quién detecta una traducción pendiente y si las versiones pueden publicarse por separado. El idioma de los menús del panel es una cuestión distinta del idioma del contenido.
¿Podré cambiar de proveedor más adelante?
La continuidad exige revisar contenido, accesos y documentación de la web. Comprueba qué se exporta y quién puede hacerlo. Una exportación de textos no incluye necesariamente plantillas, relaciones o integraciones. La ficha de entrega de un proyecto de software ayuda a ampliar esta comprobación con el equipo técnico.
¿Qué hago si ya tengo un CMS y mi equipo no lo utiliza?
Observa primero dónde se detiene una tarea habitual. Puede faltar un permiso, un campo, una explicación o una vista previa fiable. Documenta el bloqueo antes de decidir una migración. Si la solución actual puede resolverlo con una configuración razonable, compárala con el coste y el trabajo de cambiar de sistema.
Recomendación final
Elige la propuesta que demuestre las tareas imprescindibles de tu equipo y deje claras sus dependencias. Utiliza las ocho pruebas como guion, adapta las que no correspondan y conserva los pendientes. Si la demostración depende de que el proveedor haga todos los pasos, todavía falta comprobar la autonomía que estás comprando.
En resumen
- Empieza por el trabajo editorial. Define qué necesita publicar y mantener tu empresa.
- Detalla el alcance editable. Campos, bloques y nuevas plantillas son capacidades diferentes.
- Compara implementaciones concretas. La categoría o marca del CMS no demuestra facilidad de uso.
- Haz la prueba con tu equipo. Utiliza su cuenta y registra la ayuda necesaria.
- Comprueba el recorrido completo. Borrador, revisión, publicación y URL pública deben encajar.
- Incluye idiomas y recuperación. Deja claros sus límites antes de contratar.
- Conserva la ficha de ocho tareas. Permite decidir con evidencias y retomar lo que queda pendiente.
Fuentes consultadas
Las funciones citadas se contrastaron con documentación oficial el 8 de noviembre de 2026. La ficha, las pruebas y los criterios de decisión son una propuesta editorial de Apogeo; no proceden de un estudio de resultados.
- WordPress: roles y capacidades.
- WordPress: revisiones de contenido.
- Sanity: edición visual.
- Sanity: organización de contenido por idiomas.
Siguiente paso
Lleva las tareas de tu equipo a la conversación sobre la nueva web. En Apogeo trabajamos el diseño y desarrollo web con contenido editable. Si quieres valorar qué necesita tu proyecto, cuéntanos qué publicáis y qué cambios os bloquean.
