Qué hacer si WordPress no actualiza los plugins

Contexto: por qué WordPress deja de actualizar plugins

Cuando WordPress no actualiza los plugins, el fallo suele estar en uno de estos bloques: permisos de escritura en el servidor, límites de recursos, conflictos de código, bloqueos por caché o seguridad, o una actualización previa que dejó el sistema en un estado incompleto. El síntoma visible es simple, pero la causa puede ser técnica y acumulativa, especialmente si el sitio lleva tiempo sin mantenimiento.

En WordPress, actualizar un plugin implica descargar un paquete, descomprimirlo, reemplazar archivos, ejecutar rutinas internas y, a veces, aplicar cambios en base de datos. Si algo interrumpe ese flujo, puede quedar un plugin a medias, activarse el modo mantenimiento o aparecer errores en el frontal y en el panel. Por eso conviene tratarlo como una incidencia de mantenimiento y estabilidad, no como un clic fallido.

• Riesgo de seguridad por plugins desactualizados y vulnerabilidades conocidas.
• Riesgo de caída por actualizaciones incompletas o conflictos con el tema y otros plugins.
• Impacto en ventas y captación si fallan formularios, checkout o áreas privadas.
• Mayor dificultad de diagnóstico si se repiten intentos sin guardar evidencias.
• Coste de recuperación más alto si se rompe el sitio sin copia previa.

Diagnóstico inicial: señales verificables y comprobaciones prudentes

Antes de repetir actualizaciones, identifique señales concretas. Anote el mensaje exacto del panel, la hora del intento y qué plugin falló. Si el sitio está en producción, priorice no empeorar la situación: evite actualizar en bloque, no instale plugins “para arreglarlo” sin confirmar la causa y no borre carpetas sin copia.

Busque evidencias en el propio WordPress y en el servidor. En muchos casos, el panel muestra un error genérico, pero el registro del servidor o el modo depuración de WordPress aclaran si fue un problema de permisos, memoria, tiempo de ejecución o conflicto de PHP. Si su hosting en España ofrece panel de logs, úselo, pero tenga en cuenta que la disponibilidad y el detalle varían por proveedor y plan.

• Mensajes típicos: “La actualización ha fallado”, “No se pudo crear el directorio”, “Descarga fallida”, “Mantenimiento programado. Vuelva a comprobarlo en un minuto”.
• Errores de sitio: 500, 502, 503, pantalla blanca, o acceso al wp-admin muy lento tras intentar actualizar.
• Señales de recursos: picos de CPU o memoria en el panel del hosting, procesos PHP agotados, límites de I/O o inodos.
• Cambios recientes: actualización de PHP, activación de caché, cambios en CDN, reglas WAF, o migración de hosting.
• Avisos externos: alertas en Search Console por páginas caídas, o avisos del hosting sobre malware, permisos o consumo.

Causas habituales y cómo confirmarlas sin suposiciones

La mayoría de fallos al actualizar plugins se explican por causas repetibles. La clave es confirmarlas con pruebas simples y reversibles. Si puede, trabaje primero en un entorno de staging o una copia del sitio, especialmente si hay WooCommerce o funcionalidades críticas.

En WordPress, el actualizador necesita descargar paquetes desde WordPress.org, escribir en disco y ejecutar PHP. Por eso, una incidencia de red, permisos, espacio, límites de ejecución o un plugin que interfiere con las peticiones puede bloquear el proceso. Confirme cada hipótesis con un indicador claro, no con intuición.

• Permisos o propietario incorrectos en archivos: confirme si WordPress pide FTP o si falla al crear directorios en wp-content.
• Espacio en disco o cuota: revise espacio disponible y límites del plan; una descompresión puede requerir margen temporal.
• Conectividad saliente bloqueada: si el servidor no puede acceder a WordPress.org, la descarga falla.
• Límites de PHP: memoria insuficiente o tiempo de ejecución corto; se ve en logs como “Allowed memory size” o “Maximum execution time”.
• Bloqueo por caché o seguridad: reglas del WAF, plugins de seguridad o cachés agresivas pueden interferir en el proceso.

Seguridad: cuando el fallo al actualizar es una señal de compromiso

No poder actualizar plugins también puede ser un síntoma de seguridad, aunque no siempre. Un sitio comprometido puede bloquear actualizaciones para mantener persistencia, o puede haber modificaciones en permisos y archivos que impidan escribir. Además, si la web lleva tiempo sin actualizar, el riesgo real aumenta porque las vulnerabilidades conocidas se explotan con frecuencia.

Los vectores habituales incluyen plugins vulnerables, credenciales filtradas, usuarios administradores no reconocidos, permisos demasiado abiertos, inyecciones en archivos del plugin o del tema, y puertas traseras en wp-content. Actúe con calma: antes de “limpiar”, asegure copia y evidencias, y rote accesos. Para estar al día de avisos, puede consultar guías públicas como las de INCIBE, aunque la aplicabilidad concreta depende del caso.

• Síntomas: redirecciones extrañas, anuncios no deseados, spam en formularios, usuarios nuevos, cambios en archivos sin explicación.
• Vectores: plugin desactualizado, contraseña reutilizada, acceso FTP filtrado, permisos 777, inyección en archivos PHP.
• Medidas prudentes: copia completa antes de tocar, rotación de contraseñas (WP, hosting, FTP, base de datos), revisión de usuarios y roles.
• Hardening básico: desactivar edición de archivos desde el panel, limitar intentos de acceso, revisar permisos y propietarios.
• Contención: si hay indicios fuertes, ponga el sitio en mantenimiento controlado y priorice preservar logs y fechas de modificación.

Rendimiento y estabilidad: recursos insuficientes y bloqueos durante la actualización

Actualizar plugins consume recursos puntuales: CPU para descomprimir, memoria para ejecutar PHP y operaciones de disco para reemplazar archivos. En hostings compartidos o con límites estrictos, es frecuente que el proceso se corte a mitad, dejando el plugin en un estado inconsistente. Esto puede provocar lentitud, errores 500 o bucles de mantenimiento.

La estabilidad también depende de la carga del sitio. Si actualiza en horas de tráfico alto, aumenta la probabilidad de timeouts y bloqueos de archivos. En sitios con caché agresiva o con muchas tareas programadas, la actualización puede coincidir con cron jobs y agravar el consumo. La recomendación general es actualizar en ventana de baja demanda y con monitorización mínima.

• Revise límites de PHP: memoria, tiempo máximo de ejecución y tamaño de subida si el método alternativo es manual.
• Compruebe si hay muchas tareas de WP-Cron ejecutándose o fallando, especialmente tras cambios recientes.
• Evite actualizar muchos plugins a la vez; priorice uno crítico y verifique antes de continuar.
• Si hay caché de página o de objeto, purgue después de actualizar, no antes, para no perder referencias útiles.
• Si el sitio es grande, valore actualizar con WP-CLI para reducir fallos del navegador y del panel.

Plugins, temas y actualizaciones: buenas prácticas y gestión de conflictos

La actualización de plugins no ocurre en aislamiento. Un plugin puede depender de una versión mínima de WordPress, de PHP o de otro plugin. También puede chocar con el tema, especialmente si hay personalizaciones en functions.php o constructores visuales. Por eso, una buena práctica es tratar las actualizaciones como cambios controlados, con staging y registro.

Si la actualización falla, no asuma que el plugin “está mal”. A veces el problema es un conflicto con otro plugin que intercepta peticiones HTTP, un sistema de caché que sirve archivos antiguos, o una instalación corrupta por una actualización previa interrumpida. La gestión correcta consiste en aislar variables, actualizar de forma incremental y poder volver atrás con una copia.

• Use staging cuando sea posible: reproduce el fallo sin afectar a producción y permite probar compatibilidades.
• Controle cambios: anote qué se actualiza, versión anterior y nueva, fecha, y resultado de la verificación.
• Actualice por fases: primero WordPress núcleo si procede, luego plugins críticos, después el resto, y por último el tema.
• Si hay conflicto: desactive temporalmente plugins no esenciales para aislar, y pruebe la actualización del plugin afectado.
• Alternativas seguras: actualización con WP-CLI o sustitución manual del plugin (con copia previa) si el panel falla.

Hosting, dominio y correo en España: DNS, SSL, PHP y límites que afectan a actualizaciones

En España es frecuente trabajar con hostings compartidos, VPS gestionados o servicios con panel propio. Cada proveedor aplica límites y capas de seguridad distintas, y eso influye directamente en la capacidad de WordPress para descargar y escribir actualizaciones. Por ejemplo, un WAF puede bloquear peticiones salientes, un antivirus del servidor puede poner en cuarentena archivos, o un sistema de caché a nivel servidor puede servir versiones antiguas del panel.

Aunque el dominio y el correo no son la causa directa de que un plugin no se actualice, sí pueden complicar el diagnóstico si hay problemas de SSL, DNS o correo transaccional. Un SSL mal configurado puede provocar errores al conectar con recursos externos, y un DNS en transición puede hacer que usted pruebe en un servidor distinto al que cree. En correo, si un plugin de formularios se actualiza a medias, puede parecer un fallo de deliverability cuando en realidad es un fallo de código.

• PHP: confirme versión y compatibilidad; cambios recientes de PHP pueden romper plugins antiguos o exigir actualizaciones previas.
• Límites del plan: CPU, RAM, procesos PHP, I/O y espacio; una actualización puede fallar por restricciones temporales.
• Permisos y propietario: en entornos con despliegues o migraciones, los archivos pueden quedar con propietario incorrecto.
• SSL y DNS: verifique que el sitio resuelve al servidor correcto y que no hay errores de certificado que afecten a conexiones.
• Cachés de servidor: purga y exclusiones del panel; algunos hostings cachean rutas que no deberían cachearse.

Pruebas, accesos y documentación técnica para resolverlo con trazabilidad

Para resolver un bloqueo de actualizaciones con rapidez, lo que más ayuda es la trazabilidad. Si puede documentar qué cambió, cuándo y qué error exacto aparece, reducirá el tiempo de diagnóstico y evitará soluciones destructivas. Esto es especialmente importante si intervienen varias personas o si su proveedor de hosting le pide evidencias.

Reúna accesos mínimos y pruebas antes de actuar. No se trata de acumular datos, sino de conservar lo esencial para reproducir el fallo y validar la corrección. Si trabaja con un soporte externo, esta información acelera la intervención y reduce el riesgo de tocar lo que no corresponde.

• Trazabilidad de cambios recientes: registro de actualizaciones (qué plugins, versiones, fecha), lista completa de plugins activos e inactivos, y enlaces a changelog si el autor lo publica.
• Evidencias técnicas: logs del servidor (error log), logs de PHP, y si procede el modo depuración de WordPress con el error exacto.
• Capturas y URLs: pantallazo del mensaje de error en el panel, URL exacta donde falla, y hora aproximada del intento.
• Copias de seguridad: confirmación de copia completa (archivos y base de datos) y dónde está almacenada; si hay staging, estado de sincronización.
• Accesos: wp-admin con rol administrador, acceso al panel del hosting, y si es posible acceso SFTP/SSH para usar WP-CLI o revisar permisos.

Plan de acción ordenado para recuperar actualizaciones sin aumentar el riesgo

Un plan ordenado minimiza tiempos de caída y evita que una incidencia de mantenimiento se convierta en una restauración completa. La idea es contener, asegurar copia, diagnosticar con evidencias, corregir con cambios pequeños y verificar con pruebas repetibles. Si el sitio es crítico, priorice staging o ventana de mantenimiento.

A nivel práctico, el objetivo es conseguir una actualización fiable y repetible. Si el panel falla, WP-CLI puede ser una alternativa más estable porque evita límites del navegador y reduce interferencias. En cualquier caso, cada cambio debe ir seguido de una verificación básica: acceso al panel, carga del frontal, y funcionamiento de la parte crítica del negocio.

• Contención: si hay errores visibles, active un mantenimiento controlado y evite más cambios simultáneos.
• Copia: realice backup completo de archivos y base de datos antes de tocar plugins, especialmente si ya hubo intentos fallidos.
• Diagnóstico: revise logs y active depuración de forma temporal si es necesario, siguiendo la documentación oficial.
• Corrección: ajuste permisos, recursos o desactive el plugin conflictivo; actualice de uno en uno y verifique.
• Verificación y monitorización: compruebe funcionalidades clave y deje monitorización básica tras la corrección (errores, rendimiento, alertas).

Si ya se ha tocado algo o hay urgencia: cómo no perder evidencia ni agravar la caída

En urgencias es habitual actuar rápido: instalar un plugin de seguridad, restaurar una copia parcial o borrar un plugin “culpable”. El problema es que esas acciones pueden borrar evidencia técnica, dejar el sitio incoherente o introducir nuevos conflictos. Si ya ha intervenido, el primer paso es estabilizar y reconstruir la secuencia de cambios.

Si el sitio está caído, priorice recuperar acceso al panel o al servidor sin hacer más cambios destructivos. Si se restauró una copia parcial, puede haber desajustes entre archivos y base de datos. Si se cambió de hosting, puede haber diferencias de PHP, permisos o cachés. Y si se tocó functions.php, un error de sintaxis puede bloquear todo el sitio y confundir el diagnóstico de actualizaciones.

• Se instaló un plugin de seguridad: revise si bloquea peticiones o escrituras; documente reglas activas antes de desactivarlo.
• Se restauró una copia parcial: confirme coherencia entre base de datos y archivos; evite “mezclar” versiones sin control.
• Se cambió de hosting: verifique PHP, permisos, propietario y cachés del servidor; en España varía mucho por proveedor.
• Se tocó functions.php: si hay error, revierta el cambio desde SFTP/SSH y guarde el archivo para análisis.
• Se borró un plugin crítico o se intentó limpiar malware sin copia: detenga cambios, haga imagen/copia del estado actual y recupere evidencias.

Preguntas frecuentes

Estas dudas son habituales cuando el panel no completa una actualización. Las respuestas son generales y deben adaptarse a su hosting y configuración.

P: ¿Es seguro reintentar la actualización varias veces desde el panel?

R: No es lo más recomendable si ya falló una vez sin causa clara, porque puede dejar archivos a medias. Es preferible revisar logs, permisos y recursos, y luego reintentar de uno en uno con copia previa.

P: ¿Qué hago si el sitio se queda en “modo mantenimiento” tras actualizar?

R: Suele indicar una actualización interrumpida. Primero confirme si el sitio vuelve solo tras unos minutos; si no, revise el estado del plugin afectado y los logs antes de eliminar archivos, y asegure una copia del estado actual.

P: ¿Actualizar por WP-CLI es mejor que hacerlo desde wp-admin?

R: En muchos casos es más estable porque evita límites del navegador y reduce interferencias, pero requiere acceso técnico (SSH) y cuidado con el entorno. Aun así, debe mantener copia y verificación posterior.

P: ¿Puede ser un problema de permisos aunque el sitio “funcione”?

R: Sí. WordPress puede servir páginas sin poder escribir en disco. Las actualizaciones necesitan escritura en wp-content, y un propietario incorrecto o permisos restrictivos bloquean el proceso.

P: ¿Cuándo debería pedir soporte profesional?

R: Si hay caída, errores 500 recurrentes, indicios de malware, o si el sitio es crítico (ventas, leads), conviene una revisión técnica para evitar pérdida de datos y reducir el tiempo de indisponibilidad.