Para elegir una plataforma web, prueba qué tendrá que editar alguien después de publicarla. Corregir dos textos al año, mantener un catálogo con campos y coordinar varias personas editoras son necesidades diferentes.
Un CMS —gestor de contenidos— puede facilitar ese trabajo. No garantiza por sí solo facilidad de uso, buen rendimiento, accesibilidad o independencia. Esas cualidades dependen de cómo se configure, se construya la web y se mantenga.
Empieza por el trabajo editorial
Anota tres tareas representativas. Evita “quiero poder cambiar todo”, porque no distingue autonomía de riesgo.
En el ejemplo ficticio Estudio Ladera, las tareas son corregir un servicio, sustituir la composición visual de una propuesta y añadir una propuesta nueva manteniendo la estructura. También importa quién revisará el contenido antes de hacerlo público.
Para cada tarea, escribe:
| Pregunta | Por qué cambia la decisión |
|---|---|
| ¿Con qué frecuencia ocurre? | Una tarea diaria merece una operativa distinta de una modificación excepcional |
| ¿Quién la hace? | Experiencia, permisos y apoyo disponible afectan la interfaz necesaria |
| ¿Se repite una estructura? | Campos consistentes pueden evitar fichas incompletas o datos contradictorios |
| ¿Necesita aprobación? | Borrador, revisión y publicación pueden ser roles distintos |
| ¿Qué pasa si hay un error? | Hace falta recuperar contenido y entender qué se publicó |
| ¿Dónde debe aparecer? | Un contenido puede alimentar varias páginas o canales |
| ¿Cómo se conserva fuera de la plataforma? | Exportación y copias condicionan continuidad |
La respuesta puede recomendar una solución pequeña. No hay que introducir una arquitectura distribuida para actualizar una página ocasional, ni renunciar a una buena interfaz editorial cuando la publicación forma parte del trabajo cotidiano.
Cuatro formas de organizar la edición
Las opciones siguientes describen formas de trabajo. Pueden combinarse y no equivalen a cuatro niveles de calidad.
Archivos y publicación mediante desarrollo
El contenido vive en archivos que una persona con acceso al proyecto puede editar y publicar. Puede ser suficiente cuando hay pocos cambios y existe soporte de desarrollo.
Su ventaja práctica es mantener contenido y código bajo un proceso común de versiones. Su límite es que quien edita necesita conocer ese proceso o depender de otra persona. “No tiene CMS” no significa que el contenido no pueda cambiar; significa que la operativa es diferente.
Antes de elegir, comprueba el tiempo y responsabilidad del cambio, cómo se revisa y qué ocurre si el profesional no está disponible.
CMS con edición y presentación integradas
El gestor ofrece una interfaz para páginas o contenidos y se conecta con la presentación de la web. La libertad concreta depende del modelo, permisos, tema y configuración.
Por ejemplo, WordPress documenta la gestión de páginas desde Site Editor, consultado el 10/09/2026. Es una capacidad de ese producto y contexto; no implica que cualquier instalación permita la misma edición ni que editar todo sea conveniente.
Puede encajar cuando el trabajo se realiza principalmente dentro de una web y la persona responsable necesita una interfaz editorial. Revisa qué partes quedan protegidas para no desordenar navegación, estilos o estructura por accidente.
CMS con contenido estructurado
El modelo define tipos y campos: una propuesta puede tener título, contexto, imágenes, servicios relacionados y fecha. La interfaz ayuda a mantener consistencia entre elementos.
La guía oficial de Drupal, consultada el 10/09/2026, explica conceptos como estructura del contenido, campos y taxonomías. Se utiliza aquí como referencia de capacidad, no como recomendación universal ni comparación de coste.
La estructura aporta valor cuando se repiten registros o relaciones. Si cada elemento tiene reglas distintas, un modelo excesivamente rígido puede resultar incómodo. Prueba una ficha habitual y una excepcional antes de cerrar el esquema.
CMS separado de la presentación
En un enfoque desacoplado, una herramienta gestiona contenido y otra aplicación lo muestra. Puede facilitar reutilización y libertad de interfaz, pero obliga a definir publicación, previsualización, integración y operación de ambas partes.
No basta con que el contenido “salga por una API”. Hay que comprobar qué ve la persona editora antes de publicar, cuánto tarda en aparecer el cambio y qué ocurre si una parte falla.
Puede tener sentido cuando varios canales comparten contenido o la presentación necesita un comportamiento específico. No es automáticamente una mejora para una web sencilla.
Una prueba con el mismo contenido
Pide que las alternativas se evalúen con las tareas de tu web, no con una demostración preparada exclusivamente para lucir la herramienta.
Este guion sirve para Ladera y se puede adaptar:
- Cambia el alcance de un servicio sin tocar su URL.
- Sustituye una imagen y escribe un texto alternativo que describa lo necesario.
- Añade una propuesta con los campos acordados.
- Relaciónala con el servicio correspondiente.
- Guarda como borrador y revisa su aspecto en móvil.
- Publica en un entorno de prueba autorizado.
- Corrige un error y recupera una versión anterior o una copia.
- Exporta el contenido o localiza el procedimiento documentado para hacerlo.
Registra qué pasos son posibles, cuáles requieren ayuda y cuáles todavía no constan. Una prueba observada de edición no equivale a un estudio de usabilidad con participantes; si no lo ejecutas, consérvalo como guion de evaluación.
Compara con criterios visibles
| Criterio | Evidencia que conviene pedir | Señal de una decisión pendiente |
|---|---|---|
| Autonomía editorial | La persona realiza una tarea representativa | Solo se enseña la portada pública |
| Protección de estructura | Permisos y campos evitan cambios accidentales | Cualquier editor puede cambiar todo sin revisión |
| Continuidad | Copia, exportación y restauración explicadas | “Tus datos son tuyos” sin formato ni procedimiento |
| Mantenimiento | Responsables de actualizaciones, incidencias y dependencias | Nadie sabe qué cubre la cuota |
| Integración | Flujo probado entre contenido y web | Se asume compatibilidad por tener una API |
| Coste | Inicial, recurrente y cambios fuera de alcance | Licencias o soporte omitidos |
| Accesibilidad y rendimiento | Pruebas sobre la web construida | Se atribuye calidad a la marca del CMS |
| Salida | Accesos, activos y obligaciones al terminar | La continuidad depende de una persona sin documentación |
No hace falta sumar estos criterios en una puntuación. Un requisito imprescindible incumplido puede decidir más que varias ventajas menores. Deja visible qué condición te haría cambiar de opción.
Dos escenarios de decisión
En una web con tres servicios, dos propuestas y cambios ocasionales, una edición mediante archivos con apoyo puede ser suficiente. También puede encajar un CMS sencillo si la persona quiere publicar por su cuenta. La elección depende de la autonomía que necesita y del coste de mantener esa operativa.
En una biblioteca con varios tipos de contenido, relaciones, varias personas editoras y revisión, conviene probar un modelo estructurado y permisos adecuados. Una interfaz de bloques totalmente libre quizá dificulte mantener consistencia; una solución demasiado rígida quizá dificulte explicar contenidos excepcionales.
Son razonamientos de diseño, no resultados de una comparación de productos realizada aquí. El mismo proyecto puede tener varias soluciones válidas si sus límites se entienden.
Si ya tienes una web
No cambies CMS solo porque existe otro más reciente. Primero identifica el problema concreto: edición difícil, dependencia, contenido inconsistente, rendimiento de una implementación, limitación funcional o mantenimiento.
Distingue si el fallo está en la plataforma, configuración, tema, extensiones, contenidos o proceso de trabajo. Cambiar de herramienta sin resolver esa causa puede trasladar el mismo problema a otro sistema.
Si el cambio afecta URLs o estructura, prepara un rediseño con mapa de contenido y rutas. Conserva originales, relaciones y formatos de exportación antes de migrar.
Qué dejar escrito al decidir
Registra la opción elegida, las tareas probadas, las limitaciones aceptadas y quién se hará cargo de operación y cambios. Añade lo que queda pendiente: licencia, permisos, previsualización, restauración o una integración concreta.
Esa decisión cabe dentro del briefing web. Si aún dudas entre una web informativa, un catálogo o una aplicación, revisa primero los tipos de web y lo que cambia en su alcance. No necesitas defender una marca; necesitas explicar por qué la forma de editar y mantener la web encaja con tu trabajo.