Reparar actualización fallida de WordPress

Qué es una actualización fallida en WordPress

Una actualización fallida de WordPress ocurre cuando el proceso de actualizar el núcleo, un plugin o un tema se interrumpe o termina con errores y la web queda en un estado inconsistente. En la práctica esto se traduce en una pantalla en blanco, un mensaje de “ha ocurrido un error crítico”, un bucle de redirecciones al acceso, un “briefly unavailable for scheduled maintenance”, errores 500, avisos de incompatibilidad o un panel de administración inaccesible. El problema no es solo “la actualización” como tal, sino el punto exacto donde se quedó a medias: archivos a medio copiar, dependencias que no cuadran, cachés que conservan una versión antigua, o una base de datos que se migró parcialmente.

Lo importante es que, aunque el síntoma sea aparatoso, normalmente es reversible si se sigue un orden. El orden evita dos riesgos habituales: perder datos recientes (por restaurar a lo bruto) y agravar la rotura (por borrar sin identificar si el fallo está en el core, en un plugin, en el tema o en el servidor). Por eso el servicio de reparación se centra en diagnosticar primero, estabilizar después y solo entonces completar o rehacer la actualización de forma segura.

• Objetivo 1: recuperar acceso al frontal y al panel sin perder contenido.
• Objetivo 2: identificar la causa exacta, no solo el síntoma visible.
• Objetivo 3: dejar una ruta de actualización futura fiable y repetible.

Causas más frecuentes y síntomas

Las actualizaciones de WordPress dependen de varios factores a la vez: conectividad del servidor, permisos de escritura, espacio en disco, versión de PHP, límites de memoria, reglas de seguridad del hosting, integridad de archivos y compatibilidad entre componentes. Por eso una actualización puede fallar aunque “ayer funcionara”. También influye la forma de actualizar: desde el panel, por autoactualización o por herramientas del proveedor.

Entre las causas más habituales está la falta de memoria PHP durante la descompresión de paquetes, un tiempo de ejecución insuficiente, un WAF que bloquea una petición durante la actualización, o permisos incorrectos en carpetas como wp-content. Otra causa común es que el plugin o tema nuevo exige una versión mínima de PHP superior a la que usa el servidor. En esos casos, WordPress puede “romper” justo al activar el código actualizado.

Una buena reparación no se limita a “volver a como estaba”, sino a entender por qué se rompió para que no se repita en la siguiente actualización. Si se corrige solo el síntoma, lo habitual es que el siguiente intento falle en el mismo punto.

Checklist antes de tocar nada

Antes de intervenir, conviene hacer una comprobación rápida que evita pérdidas y acelera el arreglo. Incluso si la web está caída, casi siempre se puede acceder por FTP o panel del hosting. La idea es capturar el estado actual, identificar si hay copia reciente y asegurar que cualquier acción sea reversible.

Si el sitio está en producción y genera leads o ventas, también conviene activar una página temporal controlada o modo mantenimiento “bonito”, pero solo una vez que tengamos una vía de acceso segura al panel y al servidor. La prioridad es recuperar funcionalidad básica, no decorar el fallo.

Este checklist marca la diferencia entre una reparación limpia y una reparación con daños colaterales. En muchos casos basta con ajustar recursos y rehacer la actualización bien, sin restaurar nada.

Reparación rápida con modo recuperación

WordPress incluye un modo de recuperación pensado para fallos de plugins o temas que generan errores fatales. Si recibiste un correo automático con un enlace de recuperación, esa suele ser la vía más rápida para volver a entrar al panel. Al acceder, WordPress intenta aislar el componente que falló y te permite desactivarlo para recuperar el control.

A partir de ahí, el enfoque recomendado es conservador: desactivar el plugin o tema que provocó el error, limpiar cachés, y verificar el estado de la web. Solo cuando el sitio vuelve a cargar sin errores se decide si conviene actualizar el servidor (por ejemplo PHP), sustituir el plugin por alternativa o aplicar una versión compatible.

Si no existe correo de recuperación o no funciona, no significa que la web no tenga arreglo. Solo indica que necesitamos intervenir desde el servidor para recuperar el control.

Solución si la web se queda en modo mantenimiento

Uno de los fallos más conocidos tras una actualización interrumpida es quedarse bloqueado en el mensaje de mantenimiento. Esto suele pasar cuando WordPress crea un archivo temporal de mantenimiento y, por un corte de proceso, no lo elimina. La consecuencia es que todas las visitas ven la página de “no disponible” aunque el sitio, por dentro, pudiera funcionar.

La reparación suele ser rápida si se hace con cuidado: localizar y eliminar el archivo de mantenimiento en la raíz de WordPress y luego verificar que no quedaron actualizaciones a medias. Aun así, hay que revisar el estado porque, en ocasiones, el mantenimiento se queda como síntoma de una actualización incompleta del núcleo o de un plugin grande.

Una vez desbloqueado el modo mantenimiento, conviene terminar la actualización correctamente, o revertir el componente conflictivo, para evitar que el sitio vuelva a caer al primer pico de tráfico.

Reparar por FTP: sustituir core, temas y plugins

Cuando el panel no carga o el modo recuperación no está disponible, la intervención por FTP o gestor de archivos suele ser la vía más efectiva. El objetivo es aislar el origen del fallo con cambios controlados: primero descartar que el problema sea del núcleo de WordPress, después comprobar plugins, y por último el tema. Este orden evita deshacer configuraciones que sí son válidas.

Una técnica fiable para comprobar plugins es renombrar la carpeta de plugins (o la carpeta del plugin sospechoso) para que WordPress no lo cargue. Si la web vuelve, ya sabemos dónde está el conflicto. Para el tema, se puede renombrar la carpeta del tema activo y dejar que WordPress intente activar uno por defecto. Si el problema persiste incluso sin plugins y sin tema personalizado, lo más probable es un núcleo incompleto o un problema de servidor.

Esta reparación por FTP es especialmente útil si el proveedor limita WP CLI o si el error ocurre antes de que WordPress pueda cargar su propia interfaz. Una vez recuperado el acceso, se puede completar la actualización de manera segura.

Reparar con WP CLI en servidor

WP CLI es una herramienta de línea de comandos que permite gestionar WordPress desde el servidor, sin depender del panel. Cuando hay una actualización fallida, WP CLI es muy valiosa para completar actualizaciones, desactivar plugins conflictivos o limpiar cachés sin pasar por la interfaz web. También ayuda a detectar errores que, en el navegador, se quedan en un simple “algo salió mal”.

Una reparación típica con WP CLI consiste en confirmar la versión de WordPress, listar plugins, desactivar el último actualizado y rehacer el proceso de actualización. Además, es habitual ejecutar la actualización de la base de datos si el núcleo se actualizó y quedó pendiente el ajuste de esquema. Si el problema es de permisos o de descargas, WP CLI puede mostrar el error exacto, lo cual acelera muchísimo el diagnóstico.

Si no tienes acceso SSH, también se puede hacer una reparación equivalente por FTP, aunque suele ser más lenta. En planes gestionados, a veces el proveedor ofrece una consola propia o herramientas de mantenimiento que cumplen un rol similar.

Reparar base de datos y tareas pendientes

Algunas actualizaciones no solo cambian archivos; también ajustan la base de datos. Cuando ese ajuste se queda a medias, el sitio puede comportarse de forma extraña: el panel carga pero ciertas pantallas fallan, el editor se rompe, aparecen avisos de “se requiere actualización de base de datos”, o el sitio entra en bucles de tareas programadas. En proyectos con muchos plugins, también puede haber migraciones internas de cada plugin, y ahí es donde se atascan colas y cron.

La reparación, en estos casos, pasa por completar la actualización de base de datos, limpiar transients caducados, revisar tareas programadas y validar que no haya tablas corruptas. Si el hosting tiene herramientas de reparación de tablas, se pueden usar con cautela, pero lo más importante es disponer de copia de la base de datos antes de tocarla. También conviene revisar el tamaño de tablas de caché y de logs, porque algunas crecen mucho y pueden provocar fallos por falta de espacio.

Si el sitio depende de formularios, pedidos o captación de leads, esta fase es clave. Una web que “abre” pero no registra conversiones suele estar peor que una web caída con causa clara, porque el fallo pasa desapercibido.

Restaurar copia y hacer rollback con seguridad

Restaurar una copia es una herramienta potente, pero conviene usarla con cabeza. A veces es la mejor salida, por ejemplo si el núcleo quedó incompleto y no hay forma rápida de sustituirlo, o si un plugin crítico actualizó su estructura interna y la web quedó inutilizable. El riesgo está en restaurar una copia demasiado antigua y perder contenido reciente, formularios recibidos o pedidos. Por eso, antes de restaurar, se recomienda capturar una copia del estado actual, aunque esté roto, para poder rescatar datos posteriores.

El rollback no siempre implica restaurar todo el sitio. En muchos casos basta con revertir el plugin o tema a una versión anterior compatible. Si el proveedor lo permite, se puede desplegar una copia en un entorno de pruebas para confirmar que la restauración devuelve la funcionalidad y, solo entonces, aplicarla en producción. Este enfoque reduce sustos y evita que el sitio entre en bucles de restauración.

Una restauración bien hecha debe terminar con una revisión funcional: formularios, login, navegación, rendimiento, y cualquier integración clave. Si algo queda a medias, es el momento de corregirlo, no cuando el tráfico ya está entrando.

Cómo evitar que vuelva a pasar en la próxima actualización

Reparar una actualización fallida es la parte urgente, pero el verdadero valor está en que no vuelva a repetirse. La prevención en WordPress se basa en proceso y control: actualizar con criterio, medir compatibilidad, y tener un plan claro de copia y reversión. La mayoría de incidentes graves se producen cuando se actualiza todo de golpe, sin comprobar requisitos mínimos y sin un entorno de pruebas.

Un enfoque eficaz es establecer un flujo: primero actualizar en un clon o staging, después en producción en una ventana de baja actividad, y siempre con copia reciente. También ayuda limitar el número de plugins, evitar duplicidades (varios plugins que hacen lo mismo) y vigilar la salud del servidor: versión de PHP soportada, memoria suficiente, y espacio en disco holgado. Si usas caché agresiva o CDN, el proceso de limpieza debe estar definido para que no sirva archivos viejos tras actualizar.

Con un método consistente, las actualizaciones dejan de ser un salto al vacío y pasan a ser una rutina controlada. Eso se traduce en menos incidencias, mejor rendimiento y menos tiempo perdido cada mes.

Preguntas frecuentes