Actualizar WordPress sin que la web se caiga en el intento

Actualizar WordPress es la tarea de mantenimiento que más se posterga y la que más factura cuando sale mal. El miedo no es infundado: un plugin que choca con el tema, una base de datos sin respaldo o una versión de PHP que WordPress ya no soporta pueden tumbar la web en segundos. Esto va dirigido a quien administra su propio WordPress o delega el mantenimiento y quiere saber qué pasa cada vez que aparece ese aviso de «hay una actualización disponible».

Actualizar WordPress sin riesgo exige cuatro pasos fijos: copia de seguridad completa, prueba en un entorno de staging, actualización de plugins uno a uno comprobando cada uno, y solo al final el núcleo. WordPress aplica en automático los parches menores de seguridad; las versiones mayores y los plugins siguen dependiendo de quien administra el sitio.

Actualizar WordPress sin perder el control

WordPress separa sus propias actualizaciones en dos categorías con un comportamiento distinto. Las menores —la segunda cifra de la versión, como pasar de 6.8.1 a 6.8.2— llevan casi siempre parches de seguridad y se instalan solas desde que lo activó por defecto en la versión 3.7, allá por 2013. Las mayores —de 6.8 a 6.9— añaden funciones nuevas y, desde la versión 5.6, también pueden activarse en automático, pero siguen exigiendo una decisión consciente en la mayoría de instalaciones, según detalla la documentación oficial de WordPress.org sobre cómo actualizar.

Los plugins y el tema no entran en ese automatismo salvo que se active panel por panel. Ahí está el margen de error real: una tienda con treinta plugins activos tiene treinta piezas que pueden chocar entre sí con cada actualización, y nadie las revisa a la vez que el núcleo salvo que exista un proceso para hacerlo. Ese proceso es justamente lo que mantiene el mantenimiento de WordPress dentro de unas horas razonables al mes y no de una tarde entera apagando fuego.

El riesgo real de un PHP sin soporte

WordPress funciona técnicamente con PHP 7.4, pero esa versión dejó de recibir parches de seguridad hace años y la propia página oficial de requisitos recomienda PHP 8.3 o superior para cualquier instalación en producción. La diferencia no es de velocidad: es que un fallo descubierto en una versión sin soporte ya no se corrige nunca, y los atacantes lo saben mejor que la mayoría de administradores de sitios pequeños. El caso más frecuente es el de un blog reactivado tras mucho tiempo parado: lleva meses o años sin que nadie entre al escritorio, y para cuando vuelve a tocarse acumula varias ramas de PHP de retraso a la vez.

El calendario de PHP que pocos miran

Cada rama de PHP recibe soporte de seguridad durante cuatro años desde su lanzamiento, según el propio calendario de versiones soportadas del proyecto PHP. Las ramas 7.4, 8.0 y 8.1 ya lo han agotado del todo. PHP 8.2 llega a su último parche el 31 de diciembre de 2026, así que una instalación que siga ahí tiene que moverse antes de que acabe el año. PHP 8.3 aguanta hasta finales de 2027 y PHP 8.4, la que recomienda hoy WordPress, hasta 2028. Comprobar la versión del hosting lleva un minuto y es el dato que más se ignora en una auditoría.

Copia de seguridad antes de cada actualización

Ninguna actualización debería empezar sin una copia de seguridad reciente, y esa copia solo sirve si se ha probado a restaurar alguna vez: una copia que nunca se ha comprobado es, en la práctica, una copia que no existe.

Qué debe incluir, y dónde guardarla

Una copia completa lleva dos piezas: los archivos —código, tema, plugins e imágenes subidas— y la base de datos completa, con todas sus tablas. Faltar cualquiera de las dos deja la restauración a medias. Debe guardarse fuera del propio servidor, en un almacenamiento externo o en la nube: si el problema que obliga a restaurar es que el servidor ha caído, una copia guardada ahí mismo no sirve de nada. La mayoría de paneles de hosting ofrecen copias automáticas diarias; comprobar que existen y tienen fecha reciente lleva menos tiempo que recrearlas a mano tras un disgusto.

Un entorno de staging es una copia exacta de la web, aislada de la que ven los visitantes, donde se instalan las actualizaciones de WordPress, plugins y tema antes de aplicarlas en el sitio real. Si algo se rompe, se rompe ahí, sin que lo note nadie.

Plugins y tema: el orden correcto al actualizar

El orden importa tanto como los pasos. Actualizar el núcleo antes que los plugins puede dejar activa una función que un plugin viejo todavía no soporta, y el resultado es la pantalla en blanco que todo administrador de WordPress ha visto alguna vez. El orden que menos sorpresas da es este:

• Copia de seguridad completa y comprobada.
• Prueba en un entorno de staging, si existe.
• Plugins, uno por uno, revisando la web entre cada actualización.
• Tema, comprobando páginas clave: inicio, ficha de producto, formulario de contacto.
• Núcleo de WordPress en último lugar.

Actualizar uno por uno, en vez de marcar todo y pulsar «actualizar» de golpe, es lo que permite saber cuál ha sido el culpable cuando algo deja de funcionar. Con quince actualizaciones aplicadas a la vez, encontrar la que rompió el formulario de contacto exige desinstalar y repetir hasta dar con ella.

Cuando el conflicto es con el tema, no con un plugin

Los temas comerciales y los constructores visuales guardan parte de su configuración en la base de datos con una estructura propia, y una actualización mayor del núcleo puede cambiar cómo WordPress la gestiona. El síntoma habitual no es una pantalla en blanco sino un diseño que se descoloca: columnas mal apiladas, tipografía que cambia sin motivo, un menú que desaparece en móvil. Antes de tocar nada a mano, conviene comprobar si el tema tiene una versión pensada para esa versión de WordPress: suele arreglarlo solo.

Cuatro fases para actualizar WordPress sin sustos

Backup, staging, plugins y núcleo son las cuatro fases, pero el calendario importa casi tanto como el orden. Las menores de seguridad conviene dejarlas en automático: son las que WordPress prueba contra miles de instalaciones antes de publicarlas, y retrasarlas solo alarga la ventana en la que un fallo ya conocido sigue abierto. Las mayores, en cambio, merecen esperar entre una y dos semanas desde su publicación: es el tiempo que tarda la comunidad en reportar los conflictos gordos con los plugins y temas más usados, y para entonces ya suele haber una actualización de ajuste.

Fijar un día fijo al mes para repasar plugins y tema, en vez de actualizar solo cuando WordPress avisa con un número en rojo, es lo que diferencia una web mantenida de una que acumula parches sueltos durante meses. Diez minutos a la semana revisando si hay actualizaciones pendientes cuestan mucho menos que una tarde entera restaurando una copia de seguridad.

Qué hacer cuando la actualización rompe algo

Si la web deja de cargar después de actualizar, lo primero es revisar el registro de errores del hosting: casi siempre señala el plugin o la línea exacta que ha fallado. Desactivar plugins uno a uno —por FTP o desde la base de datos si el escritorio tampoco carga— suele devolver el sitio en minutos, sin restaurar nada. Si no hay forma de aislar el problema, restaurar la copia de seguridad previa y empezar de nuevo, probando antes en staging, sale más rápido que seguir investigando a ciegas en producción.

Una vez resuelto, conviene revisar también que la velocidad de carga no se ha resentido: algunas actualizaciones de plugins añaden scripts nuevos que penalizan la carga de la página, y es justo lo que mide Google para situar el sitio en los resultados. El artículo sobre velocidad de carga en WordPress explica qué límites concretos fija Google y cómo medirlos.

Preguntas frecuentes sobre actualizar WordPress

¿Cada cuánto hay que actualizar WordPress?

Las actualizaciones menores de seguridad, en cuanto WordPress las publica, porque van en automático y no exigen revisión. Las mayores y los plugins, en una revisión fija al mes: ni hay que correr el mismo día que salen ni dejarlas acumularse durante meses sin mirar el panel.

¿Conviene activar las actualizaciones automáticas de los plugins?

Para plugins de seguridad y caché, sí: el riesgo de quedarse sin parche pesa más que el de un conflicto puntual. Para el tema o un plugin con lógica compleja —una pasarela de pago, un constructor visual—, mejor revisarlo a mano, porque un fallo silencioso ahí cuesta más que esperar unos días.

¿Qué pasa si no actualizo WordPress durante meses?

Se acumulan a la vez varias versiones de PHP, de plugins y del núcleo sin parches, así que cuando por fin se actualiza el salto es mayor y el riesgo de conflicto también. Además, cada vulnerabilidad conocida y sin corregir queda expuesta todo ese tiempo: los ataques automatizados las buscan por versión, no al azar.

¿Hace falta un entorno de staging si la web es pequeña?

No es obligatorio, pero sustituye por algo: probar primero en una copia local o en un subdominio de pruebas, aunque sea manual, antes de tocar la web que ven los clientes. La alternativa, actualizar directamente en producción, funciona hasta que falla una vez, y entonces falla con el público mirando.

Fuente: WordPress.org – Documentación oficial sobre actualizar WordPress