WordPress caído cómo recuperarlo sin perder datos

Diagnóstico inicial: qué está fallando de verdad

Cuando un WordPress “se cae” no siempre significa lo mismo. A veces el navegador muestra una pantalla blanca, otras un error crítico, un 500 interno, un 403, un 404 generalizado o un aviso de “Error establishing a database connection”. Recuperarlo sin perder datos depende de identificar el tipo de fallo antes de hacer cambios impulsivos. La regla de oro es sencilla: primero observar, después actuar.

Empiece por anotar exactamente qué ve: mensaje de error, código HTTP, si afecta a todo el sitio o solo al panel, si se reproduce en incógnito, y si coincide con un cambio reciente como una actualización, la instalación de un plugin o una migración. Si el panel sigue accesible, revise “Herramientas”, “Salud del sitio” y el correo de administrador, porque WordPress suele enviar un aviso cuando detecta un fallo fatal y, en ocasiones, permite entrar en modo de recuperación.

El segundo paso es revisar los logs del servidor, incluso sin tocar WordPress. En muchos hostings hay un apartado de “Registros” o “Logs” y, si tiene acceso por FTP o SSH, puede revisar los logs de PHP y del servidor web. Los errores típicos que orientan rápido son: límite de memoria, tiempo de ejecución agotado, archivo faltante, incompatibilidad de versión de PHP, o rutas sospechosas que apuntan a infección. También conviene comprobar si el dominio resuelve bien y si el certificado HTTPS está correcto, porque un problema de DNS o SSL puede “parecer” una caída.

• Si ve “Error crítico”: suele ser PHP, plugin o tema incompatible.
• Si ve “Base de datos”: suele ser credenciales, servidor MySQL caído o corrupción.
• Si ve 403 o redirecciones raras: puede haber reglas, seguridad o malware.
• Si solo falla el panel: a menudo es plugin, memoria o permisos.

Con este mapa inicial, ya puede escoger un camino que priorice la integridad de los datos. El objetivo no es “que cargue como sea”, sino recuperar control y conservar contenido, base de datos y archivos con el menor riesgo posible.

Poner el sitio en modo seguro sin empeorar el problema

Antes de arreglar, conviene estabilizar. Un WordPress caído puede estar recibiendo tráfico y, si usted prueba cambios continuamente, puede generar más errores, cachés corruptas o bloqueos del hosting. Poner el sitio en un modo “seguro” significa reducir variables y ganar acceso sin que la web empeore mientras diagnostica.

Si todavía puede entrar al panel, active un modo mantenimiento temporal desde un plugin fiable o, mejor, desde el propio hosting si ofrece una página de mantenimiento. Si no puede entrar, cree una página sencilla estática desde el hosting, o utilice una regla temporal para mostrar mantenimiento mientras sigue trabajando. El objetivo es evitar que visitantes y bots disparen procesos que agraven el problema.

Después, asegure el acceso. Cambie contraseñas del panel si sospecha un hackeo y, sobre todo, cambie contraseñas de FTP, panel del hosting y base de datos si están expuestas. Si el sitio está infectado, la prioridad es cortar el acceso del atacante antes de “limpiar” a medias. También conviene desactivar temporalmente la caché a nivel de servidor si está provocando errores persistentes, y vaciar cachés solo cuando tenga claro qué se está rompiendo.

• Active mantenimiento para reducir carga y riesgos.
• Asegure credenciales de hosting, FTP, panel y WordPress.
• Evite cambios masivos sin un punto de restauración.
• Documente cada acción y su resultado.

Este enfoque le ahorra una trampa clásica: arreglar un síntoma, romper otro y no saber qué lo causó. Con el sitio estabilizado, ya es momento de proteger los datos.

Copia de seguridad antes de tocar nada

Recuperar WordPress sin perder datos empieza por asegurar una copia completa. Incluso si ya tiene backups automáticos, haga uno adicional del estado actual, aunque esté roto. ¿Por qué? Porque ese estado contiene pistas del fallo y, en casos de hackeo, puede ayudar a identificar el punto de entrada. La copia que le interesa tiene dos partes: archivos y base de datos.

En archivos, priorice wp-content porque ahí viven el tema, plugins, subidas y muchas configuraciones. Aun así, si es posible, copie todo el directorio de WordPress, incluyendo wp-config.php. En base de datos, exporte un volcado completo desde phpMyAdmin o mediante el panel del hosting. Si no sabe cuál es la base de datos correcta, se identifica en wp-config.php en los campos DB_NAME y DB_USER.

Guarde la copia fuera del servidor, por ejemplo en su equipo y en un almacenamiento adicional. Si su hosting ofrece snapshots o puntos de restauración, úselo, pero no lo sustituya por una copia local. También es útil guardar un listado de plugins y la versión de PHP. Si está en modo de emergencia, esta información puede marcar la diferencia al volver atrás.

• Descargue archivos completos o, como mínimo, wp-content y wp-config.php.
• Exporte la base de datos completa en SQL.
• Guarde copias fuera del servidor.
• Anote versión de PHP, tema activo y plugins principales.

Con una copia segura, ya puede probar soluciones sin miedo. Si algo sale mal, siempre podrá volver al punto anterior sin perder contenido, usuarios ni configuraciones.

Revisar hosting, recursos y servicios

Una caída no siempre es culpa de WordPress. Muchas veces el origen es el entorno: un límite de memoria demasiado bajo, una versión de PHP incompatible, un servicio de base de datos caído o un consumo excesivo de CPU que hace que el hosting bloquee procesos. Por eso conviene revisar el panel del proveedor antes de meterse en cambios dentro del CMS.

Compruebe primero si el hosting tiene incidencias o mantenimiento. Después revise recursos: uso de CPU, memoria, entradas simultáneas y espacio en disco. Un disco lleno puede provocar fallos en actualizaciones, errores al escribir caché y corrupción. En paralelo, verifique la versión de PHP y cambie temporalmente a una versión estable compatible con su WordPress y sus plugins. Si el fallo empezó tras subir versión de PHP, volver a la anterior puede recuperar el sitio mientras prepara una actualización ordenada.

Revise también permisos de archivos y carpetas. Un cambio de propietario o permisos tras una migración puede impedir que WordPress lea o escriba archivos esenciales. Si el hosting ofrece “reparar permisos” o “restablecer propietario”, puede ayudar. Si usa un firewall o un WAF, confirme que no esté bloqueando rutas como wp-admin o admin-ajax, algo muy típico tras endurecer seguridad.

• Compruebe incidencias del proveedor y estado de MySQL.
• Revise espacio en disco, CPU, RAM y límites de procesos.
• Ajuste versión de PHP si hay incompatibilidad.
• Confirme permisos y propietario tras migraciones.

Si el entorno está estable y el problema persiste, lo más probable es que el fallo esté en plugins, tema, base de datos o infección. Pasamos al nivel WordPress.

Errores de plugins y temas

Los plugins y el tema son la causa más común de un WordPress caído tras actualizaciones. La forma más segura de comprobarlo, sin entrar al panel, es desactivar plugins por FTP o desde el gestor de archivos del hosting. Para ello, renombre la carpeta wp-content/plugins por ejemplo a plugins_old. WordPress, al no encontrarla, desactivará todos los plugins automáticamente. Si el sitio vuelve a cargar, ya sabe que el origen está ahí.

Luego, restaure la carpeta con su nombre original y desactive plugins uno a uno renombrando subcarpetas específicas dentro de plugins. Así identifica el culpable con precisión. Cuando lo encuentre, revise si ese plugin tiene actualización compatible, si requiere una versión concreta de PHP o si su configuración necesita reparación. En el caso del tema, puede forzar temporalmente un tema estándar renombrando la carpeta del tema activo dentro de wp-content/themes. WordPress intentará activar un tema por defecto si está disponible.

Si el error es “pantalla blanca”, muchas veces es un fatal error silencioso por memoria o incompatibilidad. Aumentar memoria puede ayudar, pero no debe ser su primera jugada si no sabe qué plugin lo provoca. En su lugar, busque el archivo y la línea exacta en los logs. Esto evita desactivar medio sitio sin necesidad y reduce el riesgo de perder funcionalidades críticas.

• Desactive plugins renombrando la carpeta plugins.
• Reactívelos uno a uno para detectar el causante.
• Fuerce un tema alternativo si sospecha del theme.
• Use logs para confirmar archivo y línea del error.

Una vez recuperado el acceso, actualice con orden: primero WordPress núcleo, luego tema, luego plugins, y al final optimizaciones y caché. Hacerlo al revés suele reintroducir el fallo.

Base de datos y conexión

Cuando aparece el mensaje de conexión a base de datos, la clave es separar credenciales de disponibilidad. Primero revise wp-config.php y confirme que DB_NAME, DB_USER, DB_PASSWORD y DB_HOST son correctos. Un cambio de hosting o una restauración parcial puede haber dejado estos valores desalineados. Si el hosting cambió el host de MySQL, el sitio puede fallar aunque la base de datos exista.

Después, verifique si la base de datos está operativa desde phpMyAdmin. Si puede entrar y ver tablas, la disponibilidad existe. En ese caso, la caída suele venir por usuario sin permisos, contraseña incorrecta o un problema de resolución del host. Si no puede entrar o el servicio está caído, contacte con el proveedor o revise el estado del servidor de bases de datos. También conviene comprobar corrupción: tablas marcadas como “crashed” o errores al consultar. Algunas tablas de plugins pueden corromperse y bloquear consultas.

WordPress tiene un modo de reparación de base de datos, pero debe usarse con cautela y solo cuando entienda el alcance. Si lo activa, desactívelo en cuanto termine para no dejar una puerta abierta. Otra opción segura es restaurar solo la base de datos desde un backup reciente, siempre que los archivos del sitio correspondan con esa fecha, para evitar desajustes de contenido y referencias.

• Confirme credenciales en wp-config.php.
• Pruebe acceso a la base desde phpMyAdmin.
• Revise permisos del usuario de base de datos.
• Si hay corrupción, priorice exportar y reparar con método.

Cuando la base de datos vuelve a responder y el sitio sigue caído, suele quedar un problema de archivos, plugins o seguridad. El siguiente capítulo es clave si sospecha un ataque.

Recuperación tras hackeo o malware

Si su WordPress se cae con redirecciones extrañas, páginas en idiomas que usted no creó, enlaces spam, popups o bloqueos por parte de Google, es posible que haya infección. En estos casos, el objetivo no es solo levantar el sitio, sino hacerlo limpio, porque si lo “recupera” sin eliminar el origen, se volverá a caer o quedará comprometido.

El primer paso es cambiar credenciales de todo: hosting, FTP, base de datos, panel de WordPress y cuentas de administrador. Luego, revise usuarios administradores no reconocidos y elimine los sospechosos. Tras eso, inspeccione wp-config.php y archivos en la raíz, especialmente los que no deberían estar ahí. Los atacantes suelen añadir puertas traseras en archivos con nombres que parecen legítimos. También revise .htaccess por reglas de redirección, inyecciones y condiciones extrañas.

Para limpiar con seguridad, compare su instalación con una copia limpia de la misma versión de WordPress. Reemplazar núcleo de WordPress por archivos originales es una práctica efectiva, siempre que no toque wp-content y wp-config.php sin revisar. Dentro de wp-content, revise uploads por archivos PHP, porque normalmente solo debería haber imágenes, PDFs y medios. Si encuentra ejecutables, es una señal clara de compromiso. Use un escáner de seguridad reputado, pero no confíe solo en él: el malware moderno se ofusca y se esconde en plugins abandonados.

• Rote credenciales de hosting, FTP, base de datos y WordPress.
• Revise usuarios admin y archivos sospechosos en raíz.
• Inspeccione .htaccess y wp-config.php por inyecciones.
• Busque PHP dentro de uploads y elimine lo indebido.

Una limpieza correcta suele combinar sustitución de núcleo, revisión de wp-content, actualización, y un control posterior con monitorización. Con esto, ya puede abordar la restauración de backups con criterio.

Restaurar un backup de forma correcta

Restaurar un backup no es pulsar un botón y ya. Para recuperar WordPress caído sin perder datos, debe restaurar de forma coherente archivos y base de datos, preferiblemente del mismo punto temporal. Si restaura solo archivos y deja la base de datos actual, puede encontrar errores de rutas, shortcodes rotos o plugins que “no cuadran”. Si restaura solo la base, puede perder contenido reciente o generar fallos de dependencias.

Si su proveedor ofrece restauración por fecha, elija la última fecha anterior a la caída. Antes de aplicar la restauración, guarde una copia del estado actual, incluso si está roto. Luego, aplique la restauración en un entorno de staging si lo tiene. Probar primero en staging reduce riesgos y le permite validar si el sitio arranca, si el panel funciona y si las páginas principales responden.

Tras restaurar, actualice enlaces permanentes desde el panel si puede, y limpie cachés. Si cambió dominio o ruta, revise la URL del sitio en la base de datos, pero solo si sabe lo que hace, porque cambios masivos pueden romper serializaciones. Un plugin especializado o una herramienta del hosting para “search and replace” suele ser más segura que un reemplazo manual con errores.

• Restaure archivos y base de datos del mismo momento siempre que sea posible.
• Pruebe primero en staging si dispone de ello.
• Compruebe la fecha real y el alcance del backup.
• Tras restaurar, regenere enlaces permanentes y limpie cachés con orden.

El backup es una herramienta, no una varita mágica. El cierre correcto exige comprobaciones finales y, si su web es negocio, una revisión SEO y analítica para confirmar que no ha quedado nada roto.

Comprobaciones finales y recuperación de SEO

Cuando el sitio ya carga, todavía no ha terminado. La fase final es comprobar que no ha perdido datos, que los formularios funcionan, que no hay errores ocultos y que no se han generado problemas de indexación. Empiece por lo básico: navegue por las páginas más importantes, haga un pedido de prueba si hay tienda, envíe un formulario, revise que el correo se entrega y que el panel no muestra avisos críticos.

Después, compruebe que su contenido está íntegro. Revise entradas recientes, páginas legales, menús, widgets y el aspecto del tema. En la base de datos, confirme que los usuarios siguen ahí y que no hay administradores sospechosos. En SEO, revise el archivo robots.txt, el sitemap y las etiquetas canónicas. Si hubo hackeo, también conviene buscar páginas extrañas indexadas. En Google Search Console, mire “Seguridad y acciones manuales” y “Cobertura” para detectar errores tras la caída.

No olvide el rendimiento. Una caída a veces se resuelve pero deja el sitio lento, por ejemplo por desactivar caché o por regenerar miniaturas sin control. Mida tiempos, revise imágenes, y reactive optimizaciones de forma gradual. También es buen momento para revisar redirecciones y errores 404 en logs o herramientas de analítica, porque tras un restablecimiento puede haber rutas que cambiaron.

• Pruebe formularios, envío de correo y funciones críticas.
• Revise usuarios admin y contenido reciente.
• Compruebe Search Console por seguridad e indexación.
• Active rendimiento y cachés de forma progresiva.

Si todo está correcto, el último paso es blindar el sitio. La prevención reduce drásticamente la probabilidad de una nueva caída y evita pérdidas de datos futuras.

Prevención para que no vuelva a caerse

La mejor recuperación es la que no tiene que repetirse. Prevenir que WordPress se caiga implica combinar mantenimiento, seguridad, copias y un entorno de pruebas. Empiece por un plan de backups real: frecuencia acorde al negocio, retención suficiente y copias fuera del servidor. Si publica a diario, un backup semanal no es aceptable. Si tiene tienda, quizás necesite copias más frecuentes o una estrategia que proteja pedidos y usuarios.

Después, establezca una rutina de actualizaciones controladas. Actualizar todo en producción sin probar es una receta para el error crítico. Lo ideal es usar staging: actualizar primero ahí, revisar, y luego pasar a producción. Si no tiene staging, al menos actualice en horas de baja demanda y con un punto de restauración listo. Mantenga PHP y WordPress en versiones compatibles y evite plugins abandonados. Un plugin sin mantenimiento es una puerta abierta a fallos y vulnerabilidades.

En seguridad, aplique mínimos: autenticación fuerte, limitación de intentos, protección de archivos sensibles, revisión periódica de usuarios admin, y un firewall o WAF si su proyecto lo justifica. También es recomendable monitorizar uptime y alertas por correo o mensajería: saber que el sitio cae al minuto 1 es muy distinto que descubrirlo a los dos días. En rendimiento, reduzca carga: caché bien configurada, imágenes optimizadas y limpieza de base de datos sin excesos.

• Backups automáticos y comprobados, también fuera del servidor.
• Actualizaciones probadas en staging o con protocolo estricto.
• Seguridad básica y monitorización de uptime.
• Higiene de plugins: menos, mejores y con mantenimiento activo.

Con prevención, una caída deja de ser un desastre y pasa a ser un incidente manejable. Y si vuelve a ocurrir, tendrá trazabilidad, copias limpias y un método para actuar con calma.

Preguntas frecuentes