Cómo actualizar plugins de WordPress sin romper la web

Tienes catorce actualizaciones pendientes en el escritorio de WordPress, sabes que deberías instalarlas y no lo haces porque la última vez que le diste al botón se descolocó la página de inicio. Es un miedo legítimo y muy extendido. La solución no es actualizar a ciegas y cruzar los dedos: es tener una copia con la que puedas volver atrás en diez minutos, un sitio donde probar sin público delante y un orden fijo. Con eso, actualizar deja de ser una apuesta y pasa a ser una tarea aburrida de cuarenta y cinco minutos al mes.

Aquí tienes ese procedimiento completo, con las comprobaciones concretas después de cada paso y qué hacer exactamente cuando algo se rompe.

Por qué mucha gente no actualiza: el miedo tiene fundamento

Conviene reconocerlo antes de dar consejos: sí, las actualizaciones rompen webs. Un plugin que cambia cómo genera el HTML descoloca el diseño; un constructor visual que cambia sus plantillas te deja una portada rara; una extensión de tienda que exige una versión de PHP más nueva deja la web en blanco. Y si eso pasa un viernes por la tarde sin copia, es un fin de semana perdido.

El problema es que la alternativa es peor. Los ataques a webs de empresa casi nunca son personales: son barridos automáticos que buscan versiones concretas de plugins conocidos, y empiezan a llamar a las puertas pocos días después de publicarse el fallo. Entre «se me puede descolocar una página» y «me pueden meter páginas de casino en el dominio de mi empresa» no hay empate.

La salida no es elegir entre las dos cosas, es quitarle el riesgo al proceso. Y eso se hace con método, no con valor. Si quieres el contexto de por qué la puerta de entrada casi siempre es un plugin y no WordPress en sí, lo explicamos en la guía sobre vulnerabilidades en plugins de WordPress.

Una copia de seguridad que de verdad te sirve para volver atrás

Una copia sirve si cumple tres condiciones: es completa, está fuera del servidor y sabes restaurarla. Si le falta una, no cuentes con ella.

Completa significa archivos y base de datos, no uno de los dos. Los archivos son la carpeta entera del sitio (incluido wp-config.php y .htaccess, que suelen quedarse fuera por estar ocultos). La base de datos la exportas desde el panel del hosting con phpMyAdmin (Exportar > Rápido > SQL) o, si tienes acceso por consola, con una línea:

wp db export copia-antes-de-actualizar.sql

Fuera del servidor significa descargada a tu ordenador o a un disco o nube que no sea el propio hosting. Una copia que solo vive dentro de la cuenta que quieres restaurar es una copia a medias.

Que sepas restaurarla es la parte que casi nadie prueba. Dedica una vez, una sola, a montar esa copia en un subdominio de pruebas y comprobar que arranca. El día que la necesites de verdad no vas a estar de humor para descubrir que el volcado estaba incompleto.

Y un detalle práctico: antes de tocar nada, apunta en un archivo de texto la lista de plugins con su versión actual. Se saca en dos segundos si tienes consola:

wp plugin list --fields=name,version,status

Si no la tienes, haz una captura de pantalla de la lista de plugins. Cuando algo falle, querrás saber de qué versión venías.

Cómo montar un entorno de pruebas en el hosting que ya tienes

No hace falta contratar nada nuevo. La mayoría de hostings decentes ya lo incluyen y mucha gente no lo sabe:

Con cPanel: busca WordPress Toolkit y la opción de crear una copia de staging. Te clona la web en un subdominio en un par de minutos.
Con Plesk: misma idea, dentro de WordPress > Copiar.
Hostings gestionados españoles: casi todos tienen un botón equivalente en su panel propio, a veces llamado «entorno de pruebas» o «clonar web».

Si tu hosting no lo ofrece, créate un subdominio (por ejemplo pruebas.tudominio.com), instala ahí una copia con un plugin de migración y protégelo para que no lo indexe Google: Ajustes > Lectura, casilla «Disuade a los motores de búsqueda de indexar este sitio», y a poder ser también una contraseña a nivel de servidor.

Dos avisos para que la copia de pruebas no te dé un disgusto: desactiva en ella todo lo que envíe correos o cobre (pasarelas en modo real, avisos automáticos a clientes, sincronizaciones con tu facturación) y bórrala cuando acabes, porque una copia con la base de datos real es igual de sensible que la web buena.

El orden correcto: núcleo, plugins y tema

Hay un orden que reduce los conflictos, y es este:

Primero el núcleo de WordPress. Es lo que menos rompe y es la base sobre la que el resto declara compatibilidad. Se hace desde Escritorio > Actualizaciones.
Después los plugins, de uno en uno (ahora vamos a eso).
El tema al final, porque suele ser lo que más se nota visualmente y quieres tenerlo aislado para saber a quién culpar.

Dentro de los plugins, empieza por los que llevan más tiempo sin actualizarse y por los que tienen aviso de seguridad; deja para el final los constructores visuales y las tiendas, que son los que más ruido hacen. Para decidir qué va hoy y qué puede esperar a la revisión mensual, te sirve el criterio que explicamos en cómo priorizar los parches de plugins en una pyme: no todo urge igual, y tratarlo todo como urgente acaba en no hacer nada.

Un caso aparte: si tienes tienda, WooCommerce y sus extensiones merecen su propio momento y sus propias comprobaciones. Antes de meterte, repasa qué revisar en una tienda WooCommerce y cómo actualizarla sin dejarla fuera de servicio.

Actualizar de uno en uno y qué comprobar después de cada uno

Marcar todas las casillas y darle a «Actualizar» es cómodo hasta que algo se rompe: entonces tienes catorce sospechosos y ninguna pista. De uno en uno tardas quince minutos más y ahorras horas.

Antes de empezar, activa el registro de errores. En wp-config.php, justo encima de la línea que dice /* Eso es todo, deja de editar */, añade:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con eso los errores se escriben en /wp-content/debug.log y no se muestran a los visitantes. Acuérdate de volver a poner WP_DEBUG en false cuando termines.

Después de cada actualización, esta ronda de comprobación de dos minutos:

La portada, con el navegador en modo incógnito (para no ver la versión en caché de tu sesión de administrador).
Una página interior y una entrada del blog.
El formulario de contacto: envíalo de verdad y comprueba que llega el correo. Los formularios se rompen en silencio y no te enteras hasta que un cliente se queja.
Si vendes: ficha de producto, carrito y llegar hasta la pantalla de pago. Si puedes, un pedido de prueba completo.
La consola del navegador (tecla F12, pestaña «Consola») buscando errores en rojo.
Y una mirada al debug.log.

Si actualizas un plugin de caché, purga la caché antes de juzgar el resultado: la mitad de los «se ha roto la web» tras una actualización son páginas antiguas guardadas. Este es uno de los motivos por los que los plugins de caché merecen atención propia, como contamos en qué revisar en LiteSpeed Cache y cómo purgar sin dejar la web a medias.

Cómo revertir una actualización que ha roto algo

Que se rompa entra dentro de lo previsto. Lo importante es que la vuelta atrás sea rápida y quirúrgica, no un pánico general.

Si sabes qué plugin ha sido

Desactívalo primero: si con eso la web vuelve, ya tienes al culpable identificado y tiempo para pensar. Para volver a la versión anterior tienes dos caminos. El sencillo es un plugin de reversión de versiones, que te deja elegir la versión anterior desde el propio escritorio (solo funciona con plugins alojados en el repositorio oficial de WordPress). El manual es descargar el zip de la versión antigua desde la ficha del plugin en wordpress.org, apartado de versiones anteriores, borrar la carpeta actual en /wp-content/plugins/nombre-del-plugin/ y subir la antigua por FTP. Los datos del plugin viven en la base de datos, así que no los pierdes al cambiar los archivos.

Si la web se ha quedado en blanco y no puedes ni entrar

Entra por FTP o por el gestor de archivos del hosting y renombra la carpeta /wp-content/plugins/ a plugins-off. Eso desactiva todos los plugins de golpe y te devuelve el acceso al escritorio. Luego renómbrala de vuelta y ve activándolos de uno en uno hasta que reaparezca el fallo.

Si te has quedado en «Brevemente no disponible por mantenimiento programado»

Es un archivo llamado .maintenance que WordPress crea al empezar a actualizar y no llegó a borrar. Bórralo tú desde la raíz del sitio por FTP y la web vuelve al momento.

Si nada de lo anterior funciona

Restauras la copia. Para eso la tenías. Y si la web restaurada vuelve a fallar exactamente igual, entonces el problema no era la actualización: revisa si hubo un cambio en el servidor (versión de PHP, por ejemplo) el mismo día.

Actualizaciones automáticas: cuándo activarlas y cuándo no

WordPress permite activar la actualización automática plugin por plugin, desde Plugins > Plugins instalados, columna de la derecha, «Habilitar las actualizaciones automáticas». Bien usado ahorra trabajo; mal usado te rompe la tienda un domingo por la noche.

Actívalas en plugins pequeños, muy usados y que no tocan el diseño ni el proceso de compra: los de seguridad, los de SEO, los que hacen una sola cosa. También conviene dejar activas las actualizaciones automáticas de seguridad del núcleo, que WordPress trae puestas de fábrica.

No las actives en constructores visuales, en el tema, en WooCommerce ni en sus pasarelas de pago, ni en plugins de los que dependa la facturación. Ahí quieres estar delante cuando ocurra.

Y si activas alguna automática, monta al menos un aviso: que el correo de administración de WordPress sea uno que leas, y no el buzón que nadie mira desde 2019.

Rutina mensual realista para una web de empresa

Lo que funciona en una empresa pequeña no es un procedimiento perfecto, es uno que se cumple. Este cabe en menos de una hora:

Día fijo al mes, en horario de poco tráfico, y nunca un viernes ni la víspera de vacaciones. Si algo se tuerce, quieres tener el día siguiente por delante.
Copia completa y descargada. Cinco minutos.
Revisión rápida de avisos de seguridad de los plugins que tengas. Si hay alguno crítico, ese va primero y no espera al mes que viene.
Núcleo, plugins de uno en uno, tema. Con la ronda de comprobación después de cada uno.
Limpieza: desinstala (no solo desactives) lo que no uses. Un plugin desactivado sigue siendo código en el servidor.
Anota en una hoja la fecha, qué actualizaste y si algo dio guerra. Ese registro vale oro cuando dentro de seis meses intentes recordar cuándo empezó un problema.

Si tienes entorno de pruebas, haz todo esto ahí primero y repítelo en la web buena sabiendo ya lo que va a pasar. Si no lo tienes y la web es sencilla, actualizar directamente en producción con copia reciente es un riesgo asumible; en una tienda con pedidos entrando, no lo es.

Una última cosa, dicha sin adornos: si tu web no factura y la puedes rehacer en una tarde, hazlo tú y ahorra el dinero. Si tu web es el canal por el que entran los clientes, esta hora al mes es la más barata que vas a pagar nunca. Si prefieres no hacerlo tú cada mes, con Pulse nos encargamos del mantenimiento y de la vigilancia continua, con las copias comprobadas y el aviso en cuanto algo cambia en la web sin tu permiso.

Seguir leyendo en esta sección

Ver todo en Seguridad de plugins WordPress → · Mapa completo del sitio