Mantenimiento del CMS del sitio web: cómo mantener el sitio en sus manos

La consulta traslada su horario del viernes a la mañana. En el sitio web sigue figurando la hora antigua y el personal de recepción se pregunta a quién habría que llamar. El diseñador web de entonces ha cambiado de profesión y el correo ya no llega. En la casa nadie sabe si existe siquiera un acceso ni dónde se guarda. Este escenario es inventado, pero el patrón que hay detrás no lo es.

En situaciones así, rara vez es la tecnología lo que estorba. Falta una respuesta a tres preguntas sencillas: quién puede cambiar qué, dónde están los accesos y qué ocurre si el proveedor deja de estar disponible. El sistema en sí, sea un constructor o un CMS, suele estar perfectamente bien. El problema es una empresa que encargó construir un sitio web sin encargar también su mantenimiento.

Por eso no solo consideramos la elección de un sistema de gestión de contenidos, sino todo el ciclo de vida de un sitio web: mantener los contenidos, tener el software actualizado, respaldar los datos, supervisar el hosting y, llegado el caso, poder cambiar de forma limpia. Quien entiende el “mantenimiento del CMS del sitio web” como una única tarea toma mejores decisiones que quien solo elige una herramienta.

Una imagen inicial típica en una pequeña empresa es esta: el sitio web lo construyó hace unos años una persona externa, un acceso está en un papelito o en un correo antiguo, y los cambios se comunican al proveedor por mensaje. Mientras esté localizable, funciona. Es un arreglo que se basa en la buena voluntad y carece de estructura, y la buena voluntad es una mala base para algo que recibe clientes todos los días.

El primer punto es el manejo. Un sistema de edición que el desarrollador usa con gusto suele ser, para la responsable de la consulta, un laberinto de menús, bloques y campos en el que un clic equivocado descompone el diseño. Quien teme al sistema no lo mantiene, y un sitio sin mantenimiento se queda anticuado en silencio. Horarios, precios o interlocutores desactualizados cuestan confianza mucho antes de que alguien lo note.

El segundo punto es el mantenimiento invisible. Las actualizaciones de seguridad del núcleo, las extensiones y el software del servidor no se hacen solas. En un CMS clásico con plugins se acumulan dependencias que van quedando obsoletas una tras otra. Un constructor le quita esa carga, pero le ata a un proveedor. Ambos caminos son legítimos, aunque ambos tienen costes que en las ofertas suelen perderse en la letra pequeña.

El tercer punto es la propiedad. Si la agencia registra el dominio a su propio nombre, el código está en su repositorio y el hosting funciona a través de su cuenta, a la empresa solo le pertenece, en el fondo, el contenido. No es mala fe, sino a menudo simple comodidad. Solo se convierte en un problema cuando se quiere o se debe cambiar.

A ello se suma un cuarto motivo, menos tangible: nadie se siente responsable. La dirección considera que el sitio web es un asunto de marketing, el marketing lo considera una cuestión técnica y el área técnica, cosa del proveedor. Una persona responsable con nombre y suplente resuelve más problemas que cualquier decisión de software. Si falta, las tareas quedan pendientes hasta que un incidente las hace visibles.

Los constructores, como los grandes servicios de sitios web, reúnen editor, hosting, seguridad y actualizaciones en una sola suscripción. Para una empresa con pocas páginas y pocos deseos especiales suele ser la solución más tranquila, porque no hay nada que usted mismo deba parchear. Los límites aparecen en la estructura a medida, en el ajuste fino del rendimiento y en la exportación: los contenidos suelen poder llevarse solo de forma limitada o en formatos poco manejables.

El CMS clásico, en la mediana empresa por lo general WordPress u otro sistema similar con un ecosistema de plugins, ofrece la mayor variedad de funciones y de proveedores. A cambio exige operación: actualizaciones, copias de seguridad, hosting, protección. Con mantenimiento es sencillo y barato de migrar; sin mantenimiento es la puerta de entrada más habitual para los ataques, porque las vulnerabilidades de las extensiones antiguas están documentadas públicamente.

Los sistemas headless separan el contenido de la presentación. El equipo editorial trabaja en el CMS y el sitio web lo renderiza una aplicación propia. Esto aporta velocidad, estructura limpia y libertad de diseño. Pero también trae dos sistemas que tienen que funcionar juntos y, por lo general, un desarrollador que hace falta en cada cambio importante de la presentación. Para un negocio artesanal con diez páginas rara vez es la escala adecuada.

Nuestra valoración es, en consecuencia, sobria. Los sitios pequeños y estables suelen encajar en un constructor o en un CMS clásico configurado de forma ligera. Headless merece la pena cuando varios canales usan el mismo contenido, hay altas exigencias de rendimiento o ya participa un equipo de desarrollo. Lo decisivo es la respuesta clara a la pregunta de cuánta operación está dispuesto a asumir.

Una tabla de características aquí lleva a error, porque casi cualquier sistema acaba obteniendo casi cualquier función de algún modo. Preguntamos, en cambio, qué va a ocurrir realmente en los próximos tres años: con qué frecuencia cambian los contenidos, quién los cambia, cuántos tipos de página hay y quién se ocupa de la técnica cuando todo está tranquilo. El resultado rara vez es el nombre de un sistema, sino un perfil con el que contrastar sistemas.

La cuestión de la responsabilidad pesa especialmente. Un sistema que requiere mantenimiento por parte de terceros tiene que contratar de verdad a esos terceros. Es decir: un contrato de mantenimiento con servicios claros, tiempos de respuesta y posibilidad de rescisión, o una persona responsable designada internamente. Olvidar ambas cosas a la vez es el error más frecuente.

A esto se suma el esfuerzo de cambio. Estimamos lo caro que sería una migración dentro de cinco años y lo tenemos en cuenta. Un constructor con mala exportación es barato hoy y caro después. Un sistema abierto con una estructura bien documentada es más caro hoy y más tranquilo después. Ambas decisiones son defendibles, siempre que se tomen de forma consciente.

Un paso de comprobación ha dado buen resultado: antes de decidir, recorremos un caso editorial realista. Crear una nueva página de servicios, cambiar una imagen, modificar una hora, volver a dejar una página fuera de línea. Quien lo prueba con la persona que lo hará más adelante aprende en una hora más que con cualquier folleto de producto. Si la prueba resulta difícil, la causa está en el sistema o en su configuración, y ambos aspectos aún pueden cambiarse de antemano.

Conviene desconfiar de promesas del tipo “todo es fácil”. Fácil es lo que una persona concreta resuelve en su puesto de trabajo concreto sin consultar a nadie, no lo que luce bien en una demo. Por eso valoramos el manejo con ejemplos de sus propios contenidos, no con las páginas de muestra del fabricante.

En un sitio web con tres personas suele bastar una división sencilla: una administración que responde de la estructura y la técnica, y editores que pueden modificar contenidos pero no instalar extensiones ni tocar ajustes. Quien puede hacerlo todo también puede destrozarlo todo, y normalmente sin mala intención. El principio de mínimo privilegio suena estricto, pero protege de los percances más habituales.

Un flujo editorial no tiene por qué ser complejo. Lo importante es que cada cambio esté asignado a una persona y que haya un punto que apruebe lo visible cuando se trata de asuntos legales, precios o afirmaciones médicas. En las pequeñas empresas eso significa dos pares de ojos sobre una página, nada más. Borrador, vista previa, publicación: cualquier sistema debería poder separar con claridad estos tres estados.

A ello se añade una guía breve y escrita. Describe qué campos existen, cómo se preparan las imágenes, qué formulaciones se evitan y qué hacer en caso de duda. Bastan dos páginas. La guía alivia a la persona que, de otro modo, respondería a cada pregunta por teléfono, y es la pieza más importante cuando cambia el personal.

El diseño también debería amortiguar los errores. En lugar de constructores de páginas libres en los que se puede elegir cada tamaño de letra y cada color, resultan eficaces los bloques fijos: bloque de texto, pie de imagen, tarjeta de servicio, caja de contacto. El equipo editorial rellena campos y el diseño se mantiene coherente. Esto limita y protege a la vez, porque una página que tras dos años sigue luciendo como el primer día rara vez es fruto de la disciplina, sino de límites razonables.

Las actualizaciones no son un proyecto, sino un ritmo. En un CMS clásico se revisan el núcleo, los temas y las extensiones a intervalos fijos, se instalan primero en una copia y después en producción. Las actualizaciones de seguridad deben instalarse con prontitud; para saltos de versión mayores basta una ventana planificada. Quien solo reacciona cuando algo se ha roto paga bastante más después.

Menos extensiones significan menos superficie de ataque. Cada plugin es código ajeno que hay que mantener. Por eso, antes de cada instalación comprobamos si una función puede resolverse también sin un módulo adicional, si el módulo se sigue desarrollando activamente y cuántos más lo usan. En los constructores, el proveedor asume parte de este trabajo, pero la responsabilidad de los accesos y las contraseñas sigue siendo suya.

Las copias de seguridad siguen una regla sencilla que se ha demostrado válida durante años: varias copias, en lugares separados, con regularidad y, sobre todo, probadas. Una copia que nunca se ha restaurado es una esperanza. Definimos con qué frecuencia se hacen copias, cuánto tiempo se conservan las versiones y quién puede iniciar una restauración. Forma parte de la prueba arrancar realmente la copia en un entorno separado.

A esto se suman pequeños vigilantes: supervisión de la disponibilidad, aviso de certificados a punto de caducar, notificación de inicios de sesión fallidos. No evitan ataques, pero garantizan que usted se entere de los problemas antes que sus clientes.

En el hosting importan menos los términos de marketing que las preguntas que pueden responderse de forma concreta: dónde están los servidores, cuánto tiempo se conservan las copias, con qué rapidez responde el soporte y si puede seguir funcionando durante un tiempo una versión anterior del programa. El hosting masivo barato suele bastar para sitios sencillos, pero se queda corto cuando funcionan varios sitios, muchos formularios o reservas. Cambiar de proveedor de hosting es factible si las copias de seguridad y la documentación están en orden.

Las contraseñas son la vía de entrada más frecuente al sistema, y es una vía trivial. Un gestor de contraseñas, cuentas individuales y autenticación en dos factores eliminan la mayoría de los riesgos realistas sin necesidad de un proyecto de seguridad. Además, no debería dejar la página de inicio de sesión del CMS desprotegida frente al bombardeo constante de intentos automáticos, y conviene eliminar con regularidad las cuentas sin uso.

El dominio, el contrato de hosting, el código, los archivos de diseño y las cuentas de analítica, mapas o boletines deben estar a nombre de la empresa, con una dirección de correo que no esté vinculada a una sola persona. Puede configurarse en una hora y ahorra semanas más adelante. Lo consideramos la medida más importante de todas, aunque sea la que parece menos espectacular.

En el código entra además la cuestión de los derechos de uso. Lo que usted ha pagado puede utilizarlo, pero en qué medida, si puede modificarse o si puede transmitirse lo regula el contrato. En los componentes de terceros, como temas o extensiones, rigen sus licencias. Aquí somos deliberadamente prudentes: es una orientación, no asesoramiento jurídico, y para afirmaciones vinculantes hace falta un contrato con reglas claras, revisado jurídicamente si procede.

En la práctica ayuda un sencillo documento de traspaso: una lista de todas las cuentas con titular, finalidad y responsable, sin contraseñas en texto plano, que se guardan en un gestor de contraseñas. A ello se añade una descripción de la estructura, de las rutinas de mantenimiento y de la restauración. Es el seguro contra la llamada que se queda tres semanas sin atender, y lo primero que necesita un nuevo proveedor cuando se cambia.

El proveedor deja de estar disponible, el hosting se cancela, un constructor modifica las tarifas o el sitio sufre un ataque. Cada uno de estos casos es imaginable, ninguno es exótico. Por eso un escenario de salida describe de antemano qué hay que hacer en esa situación, quién lo hace y cuánto tiempo lleva. No tiene que ser perfecto, pero tiene que existir.

En caso de compromiso rige un orden fijo: poner el sitio en modo de mantenimiento, cambiar los accesos, restaurar una versión limpia desde una copia de seguridad, buscar la causa, poner al día las actualizaciones y solo entonces volver a publicarlo. Con un constructor el camino es más corto porque el proveedor asume una parte; con un CMS clásico depende de su preparación. Quien haya reutilizado contraseñas debe empezar por poner orden ahí.

Para el cambio de proveedor cuenta que los contenidos estén disponibles en un formato legible. Las imágenes y los textos se copian rápido; más difíciles son las redirecciones, los ajustes de SEO y los destinos de formularios, que se pierden con facilidad en una migración. Recomendamos anotar la lista de las direcciones existentes antes de un cambio para que, tras la migración, ninguna página desaparezca sin querer.

Un caso especial son las empresas con varias personas y plantilla cambiante. Las cuentas de empleados que se han marchado deberían bloquearse el último día de trabajo, no semanas después. Esto vale también para las cuentas en servicios de terceros que un sitio web utiliza solo de forma indirecta, como herramientas de reserva o mapas.

El beneficio de un sitio web bien mantenido se nota primero en lo pequeño. Los cambios se publican el mismo día en lugar de semanas después, y nadie tiene que pedir ayuda para cambiar un número de teléfono. Se puede medir de forma sencilla: tiempo entre el motivo y la publicación, número de peticiones de cambio abiertas, antigüedad de la última página revisada. Son indicadores de su propia empresa, no valores de comparación ajenos.

En el lado técnico ayudan una revisión de los niveles de actualización, una restauración documentada y los avisos de la supervisión. Además, Search Console muestra si aparecen errores como páginas inaccesibles. El tiempo de carga y la estabilidad pueden seguirse con PageSpeed Insights y echando un vistazo a los tiempos de respuesta. Afirmar cómo afecta esto a las consultas o al posicionamiento sería especular.

Lo que no puede prometerse debe ponerse abiertamente sobre la mesa. Ningún sistema es invulnerable, ninguna copia de seguridad sustituye el cuidado con las contraseñas y ningún hosting garantiza una disponibilidad ininterrumpida. Tampoco pueden indicarse costes de forma general: dependen del sistema, del esfuerzo y del proveedor. Lo honesto es un marco tras una primera evaluación, no antes.

Un ejemplo de cómo interpretarlo: si, tras un motivo, suele tardar varios días en publicarse un cambio, el cuello de botella suele estar en la responsabilidad, no en el sistema. Si la restauración muestra lagunas en la prueba, por ejemplo archivos multimedia que faltan, es un buen hallazgo, porque llega antes de la emergencia. Estas observaciones son el verdadero fruto de un mantenimiento ordenado.

Un sitio web que la empresa puede mantener por sí misma es menos una cuestión de sistema que de organización. El mejor CMS sirve de poco si los roles no están claros, las actualizaciones quedan pendientes y nadie sabe dónde está el dominio. Por el contrario, un constructor sencillo llega lejos si las responsabilidades, las copias de seguridad y la propiedad están ordenadas. La tecnología es intercambiable; el orden, no.

Su primer paso no cuesta nada. Haga una lista: dominio, hosting, CMS o constructor, boletín, analítica, mapas, reservas, cada uno con titular, acceso y responsable. Compruebe si alguien de la casa podría iniciar sesión y cambiar un horario. Si falta una respuesta, ya ha encontrado su tarea más importante antes incluso de pedir un presupuesto.

Con gusto le ayudamos con la valoración: una mirada a su sistema actual, una opinión honesta sobre si conviene más quedarse o cambiar y un concepto de mantenimiento adecuado a su tamaño. Un contrato de mantenimiento es aquí una opción, no una obligación. Lo importante es que usted sepa en todo momento dónde está su sitio y quién puede tocarlo.

De este análisis quedan dos principios. Primero: elija el sistema según el esfuerzo de mantenimiento que realmente pueda asumir, no según las funciones que quizá algún día necesite. Segundo: ponga por escrito lo que hasta ahora estaba en la cabeza de una persona. Ambas cosas cuestan poco y evitan que un sitio web se convierta en una dependencia de la que solo uno se da cuenta en una emergencia.