Actualizar plugins WordPress sin romper las webs de tus clientes

Respuesta corta: Para actualizar plugins WordPress sin romper la web de un cliente: haz una copia completa que sepas restaurar, prueba en staging lo arriesgado, actualiza de uno en uno (no con «Actualizar todo»), comprueba la web después de cada plugin y ten la vuelta atrás preparada antes de empezar. Lo que rompe webs no es actualizar: es actualizarlo todo a la vez y a ciegas.

Actualizar es obligatorio: muchos hackeos de WordPress entran por plugins sin actualizar. Pero cada actualización es un cambio de código en producción, y en una agencia se multiplica por decenas de webs. Aquí va el proceso que usamos nosotros.

Por qué actualizar plugins WordPress rompe webs

Un plugin no vive solo. Comparte la web con el tema, con otros 20 o 30 plugins, con una versión concreta de PHP y con la caché del hosting. El autor prueba su plugin, no tu combinación. Lo que suele fallar:

• Saltos de versión grande (de 3.x a 4.0): cambian funciones, ajustes o plantillas.
• Plugins críticos: WooCommerce y sus pasarelas de pago, formularios, caché y constructores visuales. Si fallan, se nota en el negocio.
• Versiones recién publicadas: los primeros días es cuando aparecen los errores que el autor no vio.
• Plantillas sobrescritas en el tema que se quedan viejas respecto al plugin.
• Versión de PHP que el plugin nuevo ya no soporta, o al revés.
• Caché que sigue sirviendo CSS o JavaScript antiguo.

Cómo saber si una actualización es arriesgada

Antes de pulsar nada, mira cada actualización pendiente:

1. ¿Es un cambio de versión mayor, menor o un parche?
2. ¿Cuántos días lleva publicada?
3. ¿Qué dice el registro de cambios? Busca «breaking», «requires», «deprecated» o cambios en plantillas.
4. ¿Es un plugin del que depende el dinero del cliente (pago, reservas, formularios)?
5. ¿Se ha roto antes al actualizarlo en esta u otra web?
6. ¿Corrige una vulnerabilidad? Entonces hay prisa, pero no por eso se hace sin copia.

Con dos o más respuestas preocupantes, esa actualización pasa por staging o se hace sola y con calma.

Cómo actualizar plugins WordPress paso a paso

Este es el proceso manual seguro. Con WP-CLI es más rápido y deja rastro de lo que has hecho.

1. Copia completa: archivos y base de datos, guardada fuera del servidor. Una copia que nunca has probado a restaurar no es una copia.
2. Lista lo pendiente y decide el orden: primero lo de seguridad, después lo que menos riesgo tiene, al final lo crítico.
3. Prueba en staging lo que hayas marcado como arriesgado. Muchos hostings crean la copia de staging con un clic.
4. Simula antes de actualizar con la opción de prueba de WP-CLI para ver qué va a cambiar.
5. Actualiza de uno en uno. Si algo falla, sabrás cuál ha sido.
6. Comprueba después de cada plugin: portada, una página interior, el formulario de contacto, el carrito y el pago de prueba si es tienda, y la consola del navegador por si hay errores de JavaScript nuevos.
7. Vacía la caché del plugin, del hosting y del CDN si lo hay.
8. Anota qué has actualizado, de qué versión a cuál y a qué hora.

Los comandos que usamos:

# 1. Copia de la base de datos (además de la copia de archivos)
wp db export antes-de-actualizar.sql

# 2. Qué plugins tienen actualización
wp plugin list --update=available

# 4. Qué pasaría, sin tocar nada
wp plugin update --all --dry-run

# 5. Uno a uno
wp plugin update contact-form-7

# Solo parches (x.y.Z) en plugins de poco riesgo
wp plugin update --all --patch

Qué comprobar después de cada plugin

Si usas el registro de errores, sigue la guía oficial de depuración en WordPress y apágalo al terminar: un debug.log accesible desde fuera da pistas a cualquiera.

Si algo se rompe

No intentes arreglarlo en caliente. Vuelve a la versión anterior y lo investigas después con calma:

# Reinstalar la versión anterior del plugin
wp plugin install contact-form-7 --version=X.Y.Z --force

# Si no puedes ni entrar al escritorio, desactívalo
wp plugin deactivate contact-form-7

Si la web da error crítico y no tienes WP-CLI, renombra la carpeta del plugin en wp-content/plugins por SFTP: WordPress lo desactivará. Si con eso no basta, restaura la copia.

Actualizaciones automáticas: cuándo sí y cuándo no

WordPress permite activar las actualizaciones automáticas de cada plugin. Tienen una ventaja clara: los parches de seguridad se aplican sin esperar a que alguien se acuerde. Y tienen riesgos:

• Se aplican cuando WordPress quiere, no cuando tú puedes mirar.
• Pueden caer varias a la vez, y si algo falla no sabrás cuál fue.
• Nadie comprueba que el carrito o el formulario siguen funcionando.
• Si el fallo no es un error fatal, sino un botón que desaparece, nadie lo ve hasta que el cliente pregunta.

Nuestra regla: automáticas para plugins sencillos y de poco riesgo, y control manual (o controlado) para pago, formularios, caché, constructores y todo lo que toque el negocio.

Cómo organizarlo cuando son 50 webs

Con una web, el proceso anterior lleva media hora. Con 50, hay que organizarlo o no se hace:

1. Agrupa las webs por riesgo. Tiendas y webs con reservas en un grupo; webs corporativas sencillas en otro. Las primeras se miran con más calma.
2. Fija una ventana de mantenimiento semanal, de martes a jueves por la mañana, cuando hay alguien para reaccionar.
3. Empieza por una web de prueba que tenga los plugins más comunes de tu cartera. Si la actualización pasa ahí, el riesgo en el resto baja.
4. No actualices plugins WordPress críticos en todas las webs el mismo día. Haz primero dos o tres y espera un día.
5. Cuéntalo en el informe mensual. El cliente no ve las actualizaciones; si no se las cuentas, no sabe que existen.

Una herramienta que te diga qué está pendiente en toda la cartera ahorra mucho tiempo. Tienes una comparativa en herramientas para gestionar webs de clientes.

Errores habituales

• «Actualizar todo» el viernes a las 18:00. Si algo se rompe, se rompe el fin de semana.
• Copia sin probar o guardada en el mismo servidor que se puede romper.
• Plugins de pago con la licencia caducada que llevan meses sin actualizarse, sin que nadie lo vea.
• Plugins abandonados: sin actualizaciones desde hace muchos meses o retirados de WordPress.org. No hay actualización que esperar: hay que sustituirlos.
• No avisar al cliente con tienda antes de tocar plugins de pago.
• Dejar WP_DEBUG activo y el registro de errores público después de investigar un fallo.

Para agencias: cómo actualiza Jeffrey

Con el plugin de Jeffrey instalado (30 segundos por web), el proceso anterior se hace solo y con las mismas precauciones:

• De una en una: Jeffrey actualiza cada plugin por separado, nunca todos a la vez.
• Copia previa antes de cada actualización.
• Prueba con navegador real después de cada una: abre la web en móvil y escritorio y busca errores críticos de WordPress, páginas en blanco, errores de PHP en pantalla o que haya desaparecido el formulario o el botón de comprar.
• Vuelta atrás automática si algo se rompe, y te avisa de qué actualización se ha deshecho.
• Riesgo antes de actualizar: te indica qué actualizaciones son más delicadas (salto de versión, recién publicada, plugin crítico o con roturas anteriores).
• Vulnerabilidades cruzadas cada día con el inventario de cada web, con aviso urgente si afecta a un plugin activo con gravedad alta, y aviso de plugins retirados o abandonados.
• Si actualizas tú (o el cliente), Jeffrey lanza una prueba con navegador unos minutos después del cambio.

Tú decides qué webs se actualizan solas: el permiso se activa en los ajustes del plugin. Y cuando algo pide manos, la bolsa de horas de NexaTech está para eso. Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Prueba Jeffrey 15 días sin tarjeta

Si te interesa cómo encaja esto en un servicio que cobras cada mes, lee la guía de mantenimiento WordPress en marca blanca y la de cómo vender el mantenimiento web.

Preguntas frecuentes