Actualizar los plugins de WordPress es la tarea de mantenimiento más frecuente que tiene cualquier web —y también la que más webs rompe y, paradójicamente, la que más webs salva. Los números no dejan lugar a dudas: la inmensa mayoría de los WordPress hackeados no caen por el núcleo, sino por un plugin con una vulnerabilidad conocida que nadie actualizó a tiempo. Al mismo tiempo, todos conocemos el caso contrario: una actualización que llega un martes cualquiera y deja la web con un error fatal. Esta guía resuelve esa tensión con un método concreto: cómo actualizar bien (copia previa, de uno en uno, con verificación), cuándo delegar en las actualizaciones automáticas y cómo protegerte de los dos riesgos que casi nadie vigila: los plugins abandonados y los ataques de cadena de suministro.
Una aclaración de alcance: aquí hablamos de plugins. La actualización del núcleo y del tema tiene su propio protocolo, que tratamos en la guía sobre cómo actualizar WordPress de forma segura; las dos guías se complementan.
Por qué un plugin desactualizado es la puerta de entrada número uno
Los informes anuales de seguridad del ecosistema WordPress repiten el mismo dato con pequeñas variaciones: en torno al 90% de las vulnerabilidades nuevas descubiertas cada año en el ecosistema corresponden a plugins, frente a una fracción mínima del núcleo. Tiene lógica: el núcleo lo mantiene un equipo grande con procesos de seguridad maduros; los casi 60.000 plugins del repositorio los mantienen desde empresas consolidadas hasta desarrolladores individuales que un día pierden el interés.
El mecanismo del ataque es menos sofisticado de lo que se imagina. Cuando un desarrollador publica una versión que corrige una vulnerabilidad, el parche mismo revela el fallo: los atacantes comparan el código nuevo con el viejo, deducen la vulnerabilidad y automatizan su explotación contra las webs que siguen en la versión anterior. Entre el parche y los primeros ataques masivos pueden pasar horas. Por eso «ya actualizaré el mes que viene» es una política de riesgo real: no es que tu web pueda ser atacada, es que será escaneada con certeza, porque los bots no eligen objetivos, barren Internet entero.
La conclusión práctica es doble. Primera: actualizar plugins no es cosmética, es la medida de seguridad más rentable que existe en WordPress. Segunda: como el riesgo de romper algo al actualizar existe, la respuesta no es retrasar las actualizaciones sino hacerlas con método, que es exactamente lo que viene ahora.
Cómo actualizar los plugins de WordPress con método
El protocolo seguro tiene tres reglas. Regla uno: copia de seguridad antes de tocar nada. Archivos y base de datos, guardada fuera del servidor y con restauración probada. Es la red que convierte cualquier fallo en un contratiempo menor; si no tienes el hábito, empieza por nuestra guía de cómo hacer una copia de seguridad de WordPress. Muchos plugins de backup permiten además lanzar una copia rápida justo antes de actualizar, que es exactamente el uso que nos interesa.
Regla dos: de uno en uno, no el botón de «actualizar todo». Si actualizas quince plugins a la vez y la web falla, no sabes cuál es el culpable y toca desactivarlos todos para ir descartando. Actualizando de uno en uno —empezando por los críticos: seguridad, caché, WooCommerce si lo usas— y recargando la web tras cada uno, el diagnóstico es inmediato. Antes de actualizar un plugin importante, echa un vistazo a su registro de cambios: no es lo mismo una corrección menor que una versión mayor que reescribe medio plugin; con las versiones mayores, espera unos días y revisa el foro de soporte antes de lanzarte.
Regla tres: verifica lo que importa. Tras la sesión de actualizaciones, recorre las páginas clave: portada, un artículo, el formulario de contacto y, si vendes, ficha de producto y checkout completo. Y si tu web es crítica —una tienda, la web de un cliente—, haz todo esto primero en un entorno de staging: la mayoría de hostings decentes ofrecen clonar la web en un clic, actualizar allí y publicar solo cuando está comprobado. Quince minutos de staging valen más que cualquier plan de emergencia.
Actualizaciones automáticas: sí, pero selectivas
Desde WordPress 5.5, cada plugin tiene su propio interruptor de actualizaciones automáticas en la pantalla de Plugins. La pregunta no es si activarlas, sino para cuáles: el todo o nada es un error en ambos sentidos.
Nuestro criterio: automáticas sí para plugins sencillos y de desarrolladores con buen historial —utilidades pequeñas, el plugin de SEO, los de seguridad, donde recibir el parche cuanto antes importa más que el pequeño riesgo de fallo—. Automáticas no para los plugins de los que depende la estructura de tu web: WooCommerce y sus extensiones, el constructor de páginas, los de pagos y membresías. En estos, una actualización defectuosa aplicada de madrugada puede costarte ventas durante horas sin que nadie se entere; mejor aplicarlas tú, con copia previa y verificación inmediata.
Este término medio te da lo importante de ambos mundos: los parches de seguridad de la larga cola de plugins pequeños llegan solos, y los componentes críticos se actualizan bajo supervisión. Dos complementos que redondean el sistema: un aviso de actividad (WordPress envía correos cuando una automática se aplica o falla; léelos) y un monitor de disponibilidad gratuito tipo UptimeRobot que te avise si la web cae, sea por una actualización o por cualquier otra cosa. Y aunque delegues en las automáticas, mantén una revisión manual periódica —semanal o quincenal— porque las automáticas no lo cubren todo: hay actualizaciones que requieren pasos manuales y plugins premium que se actualizan por otros canales.
Plugins abandonados: el riesgo silencioso
Actualizar solo protege si hay actualizaciones que instalar. El plugin abandonado —ese que funciona perfectamente pero cuyo desarrollador dejó de mantener hace dos años— es un riesgo creciente e invisible: cuando se descubra una vulnerabilidad, no habrá parche. Y se descubrirá, porque los investigadores y los atacantes revisan sistemáticamente el código de los plugins populares, sigan mantenidos o no. El repositorio oficial retira de la búsqueda los plugins con vulnerabilidades sin corregir, pero no los desinstala de tu web: esa parte es cosa tuya.
Cómo detectarlos: en la ficha del plugin en wordpress.org, mira la fecha de última actualización y la compatibilidad declarada («probado hasta»). Más de un año sin actualizar en un plugin con funcionalidad compleja es una señal amarilla; más de dos, roja. Añade una auditoría semestral de tu lista de plugins con tres preguntas por cada uno: ¿lo sigo usando?, ¿está mantenido?, ¿hay una alternativa viva que haga lo mismo? Todo plugin desactivado que no piensas reactivar, bórralo: el código desactivado sigue en el servidor y sigue siendo explotable en ciertos escenarios.
Para no depender de revisiones manuales, un plugin de seguridad con base de datos de vulnerabilidades cierra el círculo: Wordfence, por ejemplo, te avisa cuando alguno de tus plugins instalados tiene una vulnerabilidad conocida, tenga parche o no. Si no lo tienes montado, en nuestra guía para instalar y configurar Wordfence está el paso a paso. Con ese aviso automático, la decisión de sustituir un plugin abandonado llega antes de que sea urgente.
Ataques de cadena de suministro: cuando la amenaza viene en la actualización
Queda el riesgo más incómodo de contar: a veces la actualización misma es el ataque. Se llama ataque de cadena de suministro (supply chain) y en WordPress ha dejado de ser teórico. El patrón se repite con variantes: un atacante compra un plugin popular a su desarrollador original (o roba sus credenciales, o compromete su infraestructura) y publica una «actualización» que incluye una puerta trasera. Miles de webs la instalan confiadamente en horas. Ha ocurrido con plugins conocidos —casos documentados como Display Widgets años atrás o los compromisos de credenciales en el propio repositorio en 2024— y volverá a ocurrir.
Seamos claros sobre la respuesta correcta, porque la intuitiva es errónea: la lección no es «no actualices» —el riesgo de no parchear vulnerabilidades conocidas es órdenes de magnitud mayor que el de un supply chain—. La lección es añadir capas de detección. En la práctica: primera, un escáner de integridad (el propio Wordfence compara los archivos de tus plugins con las versiones oficiales del repositorio y avisa de modificaciones inesperadas). Segunda, principio de mínimo privilegio en tu instalación: cuantos menos plugins, menor superficie; cada plugin es un proveedor en el que confías. Tercera, atención a las señales de cambio de manos: si un plugin cambia de propietario, cambia de nombre de repente o su changelog se vuelve vago, espera unos días antes de actualizar y busca qué dice la comunidad. Y cuarta, las copias de seguridad con retención de varias versiones: si una actualización maliciosa se cuela, poder restaurar el estado de hace una semana es la diferencia entre incidente y catástrofe.
Si una actualización rompe la web: plan de rescate
Con método y todo, alguna vez tocará. El plan de rescate en orden: si la web muestra un error fatal, WordPress habrá enviado al correo del administrador un enlace de modo de recuperación que te deja entrar al escritorio con el plugin problemático desactivado; desactívalo y ya tienes la web de vuelta mientras investigas. Si no hay correo o no puedes entrar, conéctate por SFTP y renombra la carpeta del plugin en wp-content/plugins (por ejemplo, de nombre-plugin a nombre-plugin-off): WordPress lo desactivará automáticamente.
Recuperado el control, decide: si el fallo es una incompatibilidad conocida, puedes volver a la versión anterior del plugin (el plugin WP Rollback lo hace en dos clics desde el escritorio) y esperar a que salga la corrección; revisa el foro de soporte del plugin, porque si la actualización rompe webs, lo verás reportado en minutos y a menudo con solución provisional incluida. Si el desastre es mayor —base de datos afectada, varios componentes fallando—, restaura la copia de seguridad previa y repite la actualización otro día, en staging. Y anota lo aprendido: qué plugin, qué versión, qué falló. Esa pequeña bitácora de mantenimiento convierte cada susto en criterio para la próxima vez.
Preguntas frecuentes
¿Cada cuánto debo actualizar los plugins?
Revisión manual semanal como norma, e inmediata cuando la actualización corrige una vulnerabilidad de seguridad (los avisos de Wordfence o del propio changelog te lo indican). Los plugins pequeños con automáticas activadas se cuidan solos. Lo que marca el límite aceptable no es el calendario sino el riesgo: una vulnerabilidad conocida sin parchear en tu web es urgente siempre, aunque sea sábado.
¿Puedo volver a la versión anterior de un plugin si la nueva falla?
Sí. La vía cómoda es el plugin WP Rollback, que lista todas las versiones publicadas en el repositorio oficial y restaura la que elijas. La vía manual: descargar la versión anterior desde la pestaña «Advanced» de la ficha del plugin en wordpress.org y subirla por SFTP sustituyendo la carpeta. Ojo: si la actualización incluía cambios de base de datos (frecuente en WooCommerce), volver atrás puede no bastar; en ese caso, restaurar la copia de seguridad completa es más seguro.
¿Qué hago con un plugin premium comprado fuera del repositorio?
Los plugins premium se actualizan mediante su propia licencia: con la clave activada, las actualizaciones llegan al escritorio como las demás. Los riesgos específicos son dos: licencias caducadas que dejan el plugin sin actualizaciones (renovar no es opcional si el plugin es importante) y las versiones «nulled» descargadas de sitios piratas, que son directamente un vector de malware: nunca las instales. Aplica además el mismo criterio de abandono: un premium cuyo desarrollador no publica nada en un año merece las mismas alarmas que uno gratuito.
Conclusión
Actualizar los plugins de WordPress sin romper la web no depende de la suerte sino de un sistema: copia de seguridad siempre, actualizaciones de una en una con verificación, automáticas solo para lo no crítico, staging para lo que da de comer, auditoría periódica contra los plugins abandonados y capas de detección —escáner de integridad, avisos de vulnerabilidades, backups con retención— frente a los ataques de cadena de suministro. Nada de esto exige más de una hora al mes, y esa hora compra lo que ningún plugin puede vender: una web que se mantiene segura sin sustos. La alternativa —posponer actualizaciones y cruzar los dedos— solo aplaza el problema hasta el peor momento posible. El mantenimiento aburrido es, en seguridad, la estrategia más brillante que existe.
