Cómo elegir un CMS: un panel que de verdad se vaya a usar

Lo eligen los desarrolladores y lo usas tú

Un sistema de gestión de contenidos casi siempre lo elige quien va a instalarlo y no quien va a trabajar en él cada día. De ahí sale la mayoría de las quejas posteriores.

El desarrollador elige por familiaridad y por velocidad de montaje, y desde su lado es razonable. Pero no va a ser él quien dé de alta cien productos, publique un artículo un viernes por la tarde o cambie un precio en todas las páginas a la vez.

El resultado es una web técnicamente sólida que su dueño tiene miedo de tocar. Seis meses después deja de tocarla del todo, y la web envejece.

Abajo: cómo elegir para que ambas partes queden satisfechas y qué comprobar antes de tomar la decisión.

Qué es un gestor de contenidos y qué no es

Un gestor de contenidos es aquello que permite cambiar el contenido de una web sin un desarrollador. Textos, imágenes, productos, precios, páginas.

No es el diseño: el mismo sistema puede tener cualquier aspecto, y una web bonita no significa un panel usable. Eso es justo lo que se confunde durante una demostración.

Tampoco es el conjunto de funciones de la web. Un catálogo con filtros, los pagos, el área de cliente se construyen encima, y pueden construirse encima de cualquier cosa.

En la práctica la pregunta es esta: ¿qué tienes que poder cambiar tú, sin escribir a la agencia? La respuesta determina la elección.

Y una cosa más: un gestor de contenidos no tiene por qué ser uno solo para toda la web. A menudo tiene sentido que el catálogo venga del sistema de gestión mientras los textos se editan en un panel aparte.

Tres enfoques

No se diferencian por capacidad sino por quién responde de las actualizaciones y cuánto puedes alejarte del comportamiento estándar.

Un sistema ya hecho de código abierto. Se instala, se amplía con extensiones y lo conoce mucha gente. Barato al principio y con especialistas disponibles, pero las actualizaciones y la seguridad quedan de tu lado.

Un servicio en la nube. Todo el mantenimiento es del proveedor, se actualiza solo y se rompe poco. A cambio vives dentro de sus reglas y pagas cada mes.

Un panel propio sobre tu propio código. Exactamente los campos que necesitas, nada de sobra, control completo. Más caro de construir y necesita que alguien lo mantenga.

Nuestra web está hecha de la tercera forma, y el motivo principal no es la flexibilidad sino las reglas editoriales: un texto no entra en la búsqueda hasta cumplir unas veinticinco condiciones de extensión, fuentes y estructura. Ese filtro no se atornilla a un sistema ya hecho.

El criterio principal: quién hará los cambios

Respóndelo con honestidad, porque de ahí sale todo lo demás.

Si quien edita el contenido no tiene formación técnica, el panel tiene que ser simple hasta resultar aburrido, y merece la pena sacrificar flexibilidad por eso.

Si tienes un desarrollador o una agencia de mantenimiento, puedes coger una herramienta más potente, porque la complejidad no les estorba.

Si casi nada va a cambiar y las actualizaciones son anuales, la pregunta apenas importa y no merece discusión.

Y aparte: si varias personas con papeles distintos van a introducir contenido, eso es un requisito propio y hay que decirlo desde el principio. Los permisos añadidos a posteriori encajan mal.

Cinco tareas para poner a prueba un panel

No mires una demostración: pide acceso y haz cinco cosas a mano.

Crea una página o un producto desde cero, con fotografía y descripción. Cronométralo.

Cambia el texto de una página existente y mira cuánto tarda en aparecer en la web y si la maquetación sobrevive.

Sube una fotografía con el tamaño equivocado y mira qué pasa. Un buen sistema la recorta y la comprime; uno malo la muestra tal cual y estira el diseño.

Busca una manera de cambiar algo en veinte páginas a la vez. Si no existe, lo harás a mano durante toda la vida de la web.

Y prueba a deshacer tu propia edición. Poder volver a una versión anterior de un texto se recuerda exactamente una vez, y esa vez hace mucha falta.

Lo que una demostración no enseña

Las demostraciones se hacen sobre una web vacía con tres productos. Los problemas empiezan a los trescientos.

La velocidad del panel con volumen. Una lista de mil elementos que tarda veinte segundos en abrir es lo habitual, y una demostración nunca lo revela.

La búsqueda dentro del panel. Cuando hay muchos elementos, buscar es la única forma de encontrar uno, y puede ser sorprendentemente mala.

Las operaciones masivas. Cambiar la categoría de cuarenta productos, subir precios un cinco por ciento, despublicar todo lo que no se vende. Sin eso el trabajo se convierte en un rastreo.

Y el comportamiento cuando trabajan dos personas a la vez. ¿Quién gana si ambas abrieron la misma página y guardaron? La respuesta correcta es un aviso; la habitual es que a quien guardó primero se le sobrescribe en silencio.

Extensiones: la fuerza y el peligro principal

Los sistemas ya hechos tienen una extensión para cada tarea, y esa es su ventaja principal. También es su riesgo principal.

Cada extensión es código ajeno dentro de tu web. Puede ralentizar páginas, entrar en conflicto con otras extensiones y llevar vulnerabilidades que nunca verás.

Una extensión abandonada es la más peligrosa de todas: sigue funcionando pero deja de actualizarse, y en un año se convierte en el agujero por el que entran.

Las reglas prácticas son simples. Antes de instalar, mira la fecha de la última actualización y el número de instalaciones. No uses dos extensiones que hagan lo mismo. Cada seis meses borra lo que no usas: una extensión desactivada sigue siendo código en el servidor.

Y lleva una lista: qué está instalado, para qué y quién lo decidió. Dentro de dos años nadie se acordará.

Actualizaciones: Las demostraciones van con tres productos; los problemas…

La parte más aburrida y la causa más común de una intrusión.

Las actualizaciones no salen por botones nuevos sino, la mayoría de las veces, para cerrar vulnerabilidades. Una vulnerabilidad se hace pública, y desde ese día empieza un barrido automático de sitios que no aplicaron la actualización.

La gente se las salta por un motivo comprensible: a veces una actualización rompe la web. De ahí la lógica de si funciona no lo toques, que se sostiene justo hasta la primera intrusión.

Hay un único orden correcto: un entorno de pruebas, la actualización ahí, una comprobación de los recorridos clave y después producción. Lleva media hora y elimina casi todo el riesgo.

Y acuerda de antemano quién lo hace. Actualizar es trabajo recurrente; necesita un responsable y un sitio en el presupuesto. Tu proveedor de alojamiento no lo hará por ti.

Permisos

Un punto que aparece en un momento inoportuno.

Si varias personas gestionan el contenido, cada una necesita su cuenta con un papel asignado. No una cuenta compartida cuya contraseña conoce también un exempleado.

El conjunto mínimo de papeles: alguien que escribe pero no puede publicar, alguien que publica, alguien que cambia ajustes. Con eso se cubre la mayoría de los casos.

Piensa aparte qué pasa cuando alguien se va. La cuenta se desactiva, no se borra; si no, el registro de quién cambió qué desaparece con ella.

Y comprueba si ese registro se ve siquiera. Un historial de cambios responde a quién quitó este bloque en un segundo; sin él la misma pregunta es una discusión sin salida.

Qué preguntar a la agencia

Seis preguntas que se hacen antes de firmar y no después.

Quién actualizará el sistema y sus extensiones tras el lanzamiento y si eso va en el precio.

Si hay un entorno de pruebas donde se comprueban las actualizaciones antes de producción.

Si se puede exportar todo el contenido en un formato portable en caso de cambiar de agencia.

Cuánta gente en el mercado sabe trabajar con este sistema. La respuesta solo nosotros no es una ventaja.

Y enséñame cómo hacer un cambio masivo en cuarenta páginas en este panel. No lo describas: enséñalo.

Cómo comprobarlo antes de decidir

Un procedimiento corto para una tarde.

Coge la lista de lo que vas a cambiar en la web durante un año: textos, precios, productos, artículos, promociones.

Junto a cada punto anota quién lo hará y con qué frecuencia.

Pide acceso a una versión de demostración y ejecuta a mano los tres puntos más frecuentes, cronometrándote.

Multiplica ese tiempo por la frecuencia anual. El número de horas resultante es el coste real del panel, y suele superar la diferencia en el precio de construcción.

Si no hay tiempo para cuentas, hay una regla corta: elige lo más simple que cubra tus tareas. La falta de capacidad se nota enseguida y se arregla desarrollando. El exceso de complejidad se nota al año, y para entonces ya no lo arregla nada.