Cómo probar una actualización de WordPress y preparar una reversión real

Los botones de actualización de WordPress son fáciles de encontrar. Revertir una actualización fallida sin perder comentarios, pedidos o borradores nuevos es mucho más difícil. Por eso, el flujo de trabajo más seguro no consiste simplemente en «hacer una copia de seguridad y pulsar actualizar». Consiste en definir qué puede cambiar, probarlo en una copia y ensayar cómo volver al estado anterior que funcionaba.

La documentación oficial de WordPress sobre actualizaciones aconseja hacer una copia de seguridad antes de actualizar y explica tanto el método automático como el manual. También advierte de que los cambios realizados directamente en los archivos del núcleo pueden sobrescribirse. Para los editores independientes, la cuestión operativa adicional es si la base de datos, los archivos multimedia, la configuración y el código pueden recuperarse de forma conjunta.

Anota lo que se va a cambiar

Registra la versión del núcleo de WordPress, el tema activo, los plugins, la versión de PHP y el entorno de alojamiento. Identifica las correcciones de seguridad que no pueden esperar razonablemente y las actualizaciones de funciones corrientes que pueden programarse. Una lista de cambios permite explicar lo ocurrido si una página falla después del despliegue.

Comprueba si los plugins o el código personalizado indican restricciones de versión o de PHP. Las notas de la versión son útiles, pero no pueden prever interacciones exclusivas de tu sitio. Utiliza un entorno de pruebas con una copia reciente del contenido y la configuración reales. Protege el entorno de pruebas frente a la indexación pública y el acceso no autorizado.

Haz copias de los archivos y de la base de datos por separado

Una exportación correcta de la base de datos sin los archivos multimedia está incompleta. Del mismo modo, una copia de las carpetas sin la base de datos no permite restaurar las entradas ni los ajustes. Conserva las copias de seguridad fuera del servidor que vas a modificar, con los controles de acceso y los límites de conservación adecuados. Incluye cualquier configuración crítica del entorno necesaria para volver a conectar un sitio restaurado, sin guardar secretos en un archivo expuesto.

Ensaya una restauración siempre que puedas. Pregúntate cuánto tarda la restauración, qué datos se perderían desde la copia de seguridad y quién puede autorizarla. WordPress ofrece indicaciones sobre copias de seguridad; la implementación concreta del alojamiento y del plugin sigue necesitando una prueba práctica.

Prueba los recorridos de los usuarios, no solo la página de inicio

Aplica las actualizaciones en el entorno de pruebas en el mismo orden previsto para producción. Visita páginas de artículos, archivos de categorías, la búsqueda, las redirecciones, las rutas de idioma, los archivos multimedia, los datos estructurados y el editor. Si el sitio vende productos, comprueba el carrito, el pago y las notificaciones de pedidos con métodos de prueba seguros. Si utiliza acceso para miembros, comprueba el inicio y el cierre de sesión y los límites de permisos.

Vigila los errores de PHP, los mensajes de la consola de JavaScript y los registros del servidor. Una página que visualmente parece normal puede estar generando un error en un feed o en una tarea programada. Compara el resultado con una breve lista de comprobación de referencia para que las diferencias sean observables.

Decide cómo funcionaría realmente la reversión

Algunos alojamientos ofrecen instantáneas; otros requieren restaurar archivos y base de datos. Restaurar una base de datos más antigua puede borrar la actividad producida después de la instantánea. En un sitio con mucho movimiento, un despliegue que revierte el código de forma independiente de los datos de contenido puede ser más seguro, pero depende de la compatibilidad de las migraciones. Documenta la decisión antes de la ventana de actualización en producción.

En las versiones que modifican la base de datos, aclare si la aplicación admite migraciones inversas. Nunca des por hecho que copiar archivos antiguos de un plugin sobre una base de datos actualizada es seguro. Si la reversión fuera destructiva, planifica una ventana de mantenimiento y un procedimiento de conciliación de datos. Conserva acceso a una copia limpia de la versión anterior a la actualización.

Una copia de pruebas tiene otro riesgo: puede enviar por accidente correos electrónicos reales, cobrar a métodos de pago guardados o publicar entradas en servicios conectados. Desactiva las notificaciones salientes, las integraciones de pago y los webhooks de producción, salvo que la prueba esté diseñada expresamente para ello y aislada. Sustituye las credenciales reales por credenciales de prueba seguras. Un sitio de pruebas bloqueado para la indexación no es automáticamente seguro; utilice autenticación y evita copiar datos sensibles de usuarios sin necesidad.

Prepara una lista breve de criterios de aceptación antes de la ventana de actualización: cinco URL de artículos representativas, un artículo con mucho contenido multimedia, el inicio de sesión editorial, el guardado de un borrador, una ruta multilingüe y cualquier flujo de trabajo crítico para los ingresos. Asigna a cada elemento un resultado de correcto, fallido o no aplicable. Un cambio que solo rompe el feed RSS o el mapa del sitio puede no aparecer en la revisión visual de la página de inicio, pero aun así merece una investigación antes del despliegue en producción.

El procedimiento de reversión debe distinguir entre una compilación fallida y unos datos de contenido dañados. Si solo una hoja de estilos o el código de un plugin son defectuosos, restaurar toda una base de datos puede provocar pérdidas evitables. Por el contrario, un cambio en los formatos de datos podría requerir una migración que tenga en cuenta la aplicación. Asigna responsables para las copias de seguridad, la aprobación del despliegue, la supervisión y la restauración. Cuando no exista una reversión segura para un cambio concreto, comunica ese riesgo internamente y elige una ventana de mantenimiento más prudente.

Despliega, verifica y cierra el ciclo

Actualiza producción, ejecuta las mismas pruebas básicas y compara los registros. Comprueba si la caché sirve un script antiguo frente al nuevo código del servidor, purga solo lo necesario y confirma que las páginas públicas devuelven los códigos de estado esperados. Guarda una breve nota de incidencias incluso cuando la actualización salga bien. Ese registro te ahorrará tiempo en la próxima versión.

Esta guía trata de la secuencia de publicación de versiones, no de todas las obligaciones de mantenimiento. La lista de comprobación de mantenimiento del sitio web, más amplia, cubre las tareas periódicas, y la guía de migración de alojamiento trata los traslados entre infraestructuras. Un plan de reversión sólido no es miedo a actualizar; es la condición que hace más predecibles las actualizaciones necesarias.