Actualizar WordPress no consiste solo en pulsar un botón. El núcleo, los plugins, el tema y la versión de PHP forman un conjunto de dependencias; cambiar varias piezas sin comprobarlas puede dejar una pantalla en blanco o romper una función concreta.
Un procedimiento ordenado reduce ese riesgo y facilita volver a un estado conocido si aparece un problema.
Qué debe entrar en la revisión
Incluye el núcleo de WordPress, los plugins activos, el tema y sus temas hijo, la versión de PHP y las tareas programadas. Revisa también integraciones externas, pasarelas de pago y código añadido a medida. Un plugin desactivado puede seguir siendo relevante si sus archivos permanecen instalados y se reactiva más adelante.
Lee el registro de cambios de las versiones importantes y comprueba que el proveedor siga manteniendo las extensiones críticas. No todas las actualizaciones tienen el mismo alcance: un parche menor y un cambio mayor merecen niveles de prueba distintos.
La copia previa debe poder restaurarse
Antes de cambiar nada, conserva una copia de la base de datos y de los archivos, incluidos los contenidos de wp-content/uploads y la configuración necesaria para que el sitio arranque. Una copia que nunca se ha restaurado es una hipótesis, no un plan de reversión.
Define dónde se guarda, qué credenciales necesita y quién puede acceder a ella. Si el servidor falla durante la actualización, el objetivo no es solo recuperar archivos: hay que recuperar una combinación compatible de código, datos y configuración.
Probar compatibilidad sin interrumpir producción
Un entorno de staging permite actualizar una réplica y recorrer las rutas importantes antes de tocar el sitio público. Comprueba inicio de sesión, formularios, búsquedas, subida de medios y, si existe comercio, carrito, checkout, impuestos y notificaciones. La prueba debe usar versiones representativas, no una instalación vacía.
Por ejemplo, un plugin puede funcionar con la versión anterior de PHP y producir un error fatal con una versión nueva. Detectarlo en staging permite corregirlo o posponer la actualización con una decisión documentada.
Un orden de actualización que facilite el diagnóstico
Actualiza primero en el entorno de prueba y cambia una variable cada vez cuando el riesgo sea alto. Después revisa el núcleo, los plugins y el tema siguiendo las indicaciones de los mantenedores. Evita actualizar diez componentes simultáneamente si no podrás identificar cuál causó el fallo.
Tras cada paso, revisa los registros de PHP y del servidor, no solo la página de inicio. También conviene comprobar tareas cron y procesos en segundo plano, porque un error puede aparecer horas después de la actualización.
Comprobaciones posteriores
En producción, valida las páginas principales con un usuario anónimo y con una cuenta con permisos. Comprueba enlaces, formularios, sesiones, búsquedas, medios y avisos del navegador. Observa el consumo de memoria y los errores durante un periodo razonable, especialmente si el sitio recibe pedidos o procesa importaciones.
Si el cambio afecta al dominio o al HTTPS, prueba además las redirecciones y las URLs canónicas. Una actualización no debería modificar esos valores por sí sola, pero un plugin de optimización o una migración mal preparada puede hacerlo.
Cómo preparar una reversión
Si aparece un fallo, identifica el componente antes de restaurar todo. En ocasiones basta con desactivar un plugin desde el panel o renombrar temporalmente su directorio; en otros casos será necesario recuperar archivos y base de datos de forma coordinada. No sobrescribas la única copia buena durante la investigación.
El procedimiento debe indicar el responsable, la ventana de mantenimiento, el punto de restauración y las comprobaciones que permiten declarar el sitio operativo. Actualizar WordPress de forma segura es un proceso de cambio controlado, no una tarea aislada.
Dependencias que suelen quedar fuera
La actualización también puede afectar a integraciones con correo, servicios de analítica, almacenamiento externo y sistemas que consumen la API de WordPress. Comprueba que los webhooks sigan llegando y que las tareas cron no se hayan quedado detenidas. Un sitio puede parecer correcto para un visitante y fallar solo al publicar una entrada o procesar un formulario.
Revisa los límites de PHP, la memoria disponible y los registros de errores. Si el cambio aumenta el consumo, el problema puede aparecer solo cuando coinciden varias peticiones o una importación.
Documentar el resultado
Anota las versiones anterior y nueva, los componentes actualizados, las pruebas realizadas y cualquier incidencia. Esa información permite repetir el procedimiento con menos incertidumbre y decidir si un fallo procede del código, de la configuración o de una dependencia externa.
También deja claro qué no se probó. La transparencia sobre ese límite es más útil que afirmar que todo el sitio quedó cubierto cuando solo se comprobó la portada.
Una actualización con criterio de riesgo
No todos los cambios requieren la misma ventana. Un sitio informativo puede probar y publicar con una interrupción breve; una tienda debe proteger pedidos, pagos y correos en curso. Clasifica el cambio, el impacto y la posibilidad de volver atrás antes de ejecutarlo.
Si una actualización afecta a una extensión esencial y no existe una alternativa compatible, documenta la decisión temporal y fija una fecha de revisión. Posponer no debe convertirse en abandonar el mantenimiento.
Qué hacer si la prueba falla
No fuerces la actualización cuando una prueba descubre un error en una función esencial. Conserva el registro, identifica el componente responsable y decide si puedes actualizarlo por separado. Desactivar temporalmente una extensión puede servir para confirmar la causa, pero no debe ocultar el problema antes de volver a producción.
Una ventana de mantenimiento bien planteada incluye una comprobación inicial, el cambio, la validación y un criterio explícito para revertir. Esto protege el contenido y evita improvisar cuando la página deja de responder.