Guía para decidir mejor
Qué hacer cuando WordPress queda bloqueado en modo mantenimiento
No retires el bloqueo mientras una actualización sigue escribiendo archivos. Confirma su estado y verifica después la web.
El aviso «no disponible por mantenimiento programado» aparece durante una actualización de WordPress y normalmente desaparece solo. Si permanece, no elimines archivos inmediatamente: primero comprueba si una actualización sigue trabajando o quedó interrumpida. Borrar la señal mientras se reemplazan archivos puede dejar versiones mezcladas.
Confirma que no hay una operación activa
- Anota cuándo empezó el aviso y qué se estaba actualizando. Pregunta a quien administra la web si hay una ventana de mantenimiento o un despliegue manual.
- Comprueba en el panel de hosting y en los registros si siguen procesos de actualización, extracción o escritura. En una tienda, confirma si hay compradores activos antes de repetir pasos.
- Distingue el aviso nativo de WordPress de una página «Próximamente» puesta por un plugin, una regla de proxy o un 503. El archivo nativo se llama .maintenance y está en la raíz de la instalación, según la referencia de WordPress.
Retira el bloqueo solo cuando sea seguro
Si la actualización terminó o falló y ya no hay procesos activos, conserva una copia del estado actual. Entonces, con acceso al gestor de archivos o SFTP, mueve temporalmente el .maintenance de la instalación correcta fuera de la raíz y prueba el sitio. La guía oficial de actualización indica retirarlo tras una actualización fallida. No toques carpetas de plugins, base de datos ni permisos como primer paso. Si el mensaje sigue, busca una caché, plugin de mantenimiento o proxy que sirva la página antigua.
Ejemplo: una actualización de idioma finaliza, pero el navegador sigue mostrando el aviso. El proceso ya no existe y el archivo quedó presente; al apartarlo, la portada abre. Eso solo recupera acceso: verifica que WordPress, tema y plugins quedaron en versiones coherentes y repite la actualización fallida desde un estado seguro. Si el log muestra un error PHP, sigue el diagnóstico del 500 en vez de insistir en actualizar.
Revisión posterior
Prueba portada, administración, formularios y, si corresponde, carrito, checkout y nuevas órdenes de prueba. Consulta Salud del sitio y logs; no borres avisos sin documentar la causa. Si una tienda recibió pedidos durante la incidencia, comprueba su estado antes de restaurar nada. La guía de restauración explica por qué una copia anterior no debe sobreescribir datos nuevos.