Plan de mantenimiento WordPress: actualizaciones y copias

Hay cuatro partes. Actualizar significa llevar el software base, los complementos y el tema a versiones nuevas. Copiar significa guardar en un lugar seguro una copia tanto de los archivos como de la base de datos. La seguridad significa cerrar las brechas conocidas, revisar las cuentas de usuario y los permisos y buscar actividad sospechosa. La monitorización significa vigilar si el sitio está activo, si los formularios funcionan y cómo se mantienen indicadores como la velocidad.

Las cuatro dependen unas de otras. Si no se hace una copia antes de una actualización, una actualización defectuosa puede ser imposible de revertir. Sin monitorización, una avería causada por una actualización solo se advierte cuando un visitante se queja. El plan debe pensarse, por tanto, como un todo y no parte por parte.

El núcleo de WordPress, los complementos y los temas publican actualizaciones con regularidad, y algunas cierran brechas de seguridad. Dejar las actualizaciones esperando mucho tiempo significa dejar abierta una brecha conocida. En la práctica el intervalo depende de lo crítico que sea el sitio; los sitios con mucho movimiento que toman pedidos justifican intervalos más cortos.

Las actualizaciones no se aplican directamente al sitio en producción. Primero se hace una copia, la actualización se prueba si es posible en una copia de pruebas con la misma estructura y solo si no se rompe nada pasa a producción. Este orden importa sobre todo en sitios con muchos complementos interdependientes, donde la nueva versión de un complemento puede chocar con otro.

Una breve lista de comprobación tras cada actualización forma parte del trabajo: ¿se abre la página de inicio, envía un mensaje el formulario de contacto, funciona el proceso de pago? Estas tres preguntas muestran si una actualización ha roto algo en silencio.

Una buena copia tiene tres cualidades: se hace con regularidad, se guarda aparte del servidor propio del sitio y se ha probado su restauración. Una copia que queda en el mismo servidor se va con el sitio si el servidor falla o es atacado. Debe estar en otro lugar.

La frecuencia de las copias depende de lo a menudo que cambie el sitio. Para una web de presentación que se actualiza unas pocas veces al año pueden bastar copias espaciadas; para una tienda que recibe pedidos cada día, la base de datos debe copiarse con mucha más frecuencia. El criterio es cuánto tiempo puede permitirse perder.

Probar la restauración es el paso que más se omite. Si existe una copia pero no se abre, no hay copia. Restaurar a intervalos fijos en un entorno de pruebas y ver que el sitio arranca es la única prueba de que el plan funciona.

La seguridad no es un ajuste que se hace una vez y se cierra, sino una comprobación que se repite a intervalos. La mayoría de los ataques entran por brechas conocidas en complementos desactualizados o por cuentas de administrador con contraseñas débiles. Por eso la lista de tareas rutinarias es corta y concreta; los puntos siguientes forman la base para la mayoría de los sitios.

La monitorización empieza con una comprobación desde fuera de si el sitio está activo. Cuando el sitio cae o muestra una página de error, hay que avisar a alguien. A esto se suma la prueba periódica del formulario de contacto y, si existe, del proceso de pago, porque un formulario puede fallar en silencio incluso con el sitio abierto.

La velocidad y las fechas de caducidad del dominio y del certificado también forman parte de la monitorización. Un certificado caducado muestra a los visitantes una pantalla de aviso. Atar estas fechas a un calendario es uno de los pasos de monitorización más sencillos y útiles.

• Eliminar los complementos y temas sin usar
• Revisar las cuentas de administrador y los permisos
• Exigir contraseñas robustas y verificación en dos pasos
• Analizar en busca de código malicioso
• Limitar los intentos de inicio de sesión

El error más común es posponer el mantenimiento hasta que llega una crisis. Las actualizaciones se acumulan, los complementos se desfasan y una sola actualización grande acaba rompiendo el sitio. Los pasos pequeños y regulares son más seguros que los grandes y esporádicos.

El segundo error es dejar complementos sin usar. Un complemento desactivado pero todavía instalado también puede tener una brecha. El tercero es confiar en una copia que nunca se ha probado. El cuarto es dejar poco claro quién hace el mantenimiento: si todos suponen que lo hace otro, no lo hace nadie. El plan debe estar escrito y cada tarea debe tener un responsable.

Por último, considerar innecesaria la monitorización es un error frecuente. Si el sitio se rompe de noche y nadie lo advierte hasta la mañana, se pierden los visitantes y pedidos de esas horas. Incluso una sencilla monitorización de disponibilidad reduce ese riesgo de forma notable.

El mantenimiento tiene sentido sobre una base sólida. Si el sitio descansa sobre un tema viejo, complementos abandonados y un código a medida desordenado, el mantenimiento regular retrasa el problema pero no lo resuelve. En un sitio así cada actualización es un riesgo, y con el tiempo el coste del mantenimiento se acerca al de una nueva construcción.

También hay que revisar el vínculo entre el sitio y el negocio. Si WordPress ha dejado de cubrir las necesidades del sitio, por ejemplo porque se requiere una lógica de producto compleja o flujos de trabajo a medida, puede ser mejor revisar la estructura que seguir manteniéndola. Esa decisión también puede surgir del propio plan: cuando produce informes periódicos, se hace visible dónde se concentran los problemas.