WordPress caído cómo recuperarlo sin perder datos
Guía para recuperar un WordPress caído sin perder datos: diagnóstico rápido, copias de seguridad, restauración, limpieza de malware y prevención.
Índice
- Diagnóstico inicial: qué está fallando de verdad
- Poner el sitio en modo seguro sin empeorar el problema
- Copia de seguridad antes de tocar nada
- Revisar hosting, recursos y servicios
- Errores de plugins y temas
- Base de datos y conexión
- Recuperación tras hackeo o malware
- Restaurar un backup de forma correcta
- Comprobaciones finales y recuperación de SEO
- Prevención para que no vuelva a caerse
- Preguntas frecuentes
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.
Qué ocurre en la práctica: lo más frecuente es que la caída aparezca justo después de actualizar un plugin pesado o el tema. El error típico es desactivar cosas a ciegas desde el panel y dejar el sitio en peor estado. Recomendación concreta: antes de tocar nada, haga una captura del error, anote la hora y revise logs. Esa información reduce muchísimo el tiempo de recuperación.
- 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.
Qué ocurre en la práctica: un error crítico se repite aunque “ya lo arreglé” porque el caché del servidor sigue sirviendo una versión rota. Error frecuente: vaciar todas las cachés antes de hacer copia de seguridad y perder la posibilidad de comparar estados. Recomendación concreta: primero asegure acceso y copie, luego ajuste cachés de forma ordenada.
- 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.
Qué ocurre en la práctica: se “arregla” desactivando plugins y, cuando se intenta restaurar el estado anterior, se descubre que no hay copia reciente. Error frecuente: confiar en un backup automático sin comprobar que incluye la base de datos. Recomendación concreta: exporte la base de datos manualmente y descargue wp-content antes de cualquier cambio.
- 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.
Qué ocurre en la práctica: un sitio cae y se culpa a un plugin, pero el motivo real es que el hosting ha limitado procesos por picos de consumo o porque el disco está al límite. Error frecuente: restaurar backups repetidamente sin resolver el cuello de botella del servidor. Recomendación concreta: revise recursos, espacio y versión de PHP antes de tocar WordPress.
- 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.
Qué ocurre en la práctica: tras una actualización automática nocturna, el sitio amanece con error crítico. Error frecuente: reinstalar WordPress completo y perder personalizaciones del tema o plugins. Recomendación concreta: desactive por carpetas, identifique el plugin o tema y actúe de forma quirúrgica, siempre con copia previa.
- 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.
Qué ocurre en la práctica: después de una migración, el sitio muestra error de base de datos y el problema real es que DB_HOST ya no es “localhost”. Error frecuente: restaurar un backup antiguo y perder publicaciones recientes. Recomendación concreta: valide credenciales y acceso en phpMyAdmin antes de restaurar, y exporte la base actual aunque esté dañada.
- 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.
Qué ocurre en la práctica: la web vuelve a cargar tras restaurar un backup, pero a los pocos días reaparecen redirecciones. Error frecuente: restaurar el backup sin rotar contraseñas y sin cerrar la vulnerabilidad inicial. Recomendación concreta: cambie credenciales, elimine puertas traseras y actualice todo antes de volver a abrir el sitio al tráfico.
- 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.
Qué ocurre en la práctica: se restaura un backup y el sitio vuelve, pero faltan artículos del último día porque el backup era nocturno. Error frecuente: no validar qué fecha cubre el backup y asumir que es “de hoy”. Recomendación concreta: revise la fecha real del backup, compare con el momento de la caída y, si hace falta, recupere contenido reciente desde exportaciones o caché antes de dar por cerrada la restauración.
- 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.
Qué ocurre en la práctica: la web parece bien, pero los leads dejan de entrar porque el formulario no envía y nadie lo detecta hasta días después. Error frecuente: dar por finalizada la recuperación sin probar el flujo de conversión. Recomendación concreta: haga una lista de comprobación con formularios, correos, compra, panel, y páginas clave antes de reabrir al público.
- 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.
Qué ocurre en la práctica: el sitio cae cada vez que se actualiza “algo”, porque no hay staging y se mezclan cambios de PHP, tema y plugins. Error frecuente: posponer actualizaciones por miedo y acumular una bomba de tiempo. Recomendación concreta: adopte un calendario mensual de mantenimiento con pruebas, y retire plugins que no se actualicen.
- 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
¿Puedo recuperar un WordPress caído sin entrar al panel?
Sí. Muchas recuperaciones se hacen por FTP o gestor de archivos del hosting: desactivar plugins renombrando carpetas, forzar un tema alternativo, revisar wp-config.php y restaurar backups. No poder entrar al panel no significa que haya perdido datos, pero sí exige actuar con más método y, siempre, con copia de archivos y base de datos.
¿Qué es lo primero que debo hacer para no perder datos?
Hacer una copia completa del estado actual: descargar archivos, especialmente wp-content, y exportar la base de datos en SQL. Aunque exista un backup automático, este paso le da control y le permite volver atrás si una prueba sale mal.
Si restauro un backup, ¿pierdo publicaciones o pedidos recientes?
Depende de la fecha del backup. Si su copia es de anoche y la caída ocurrió hoy, puede perder lo creado hoy. Por eso conviene revisar la fecha real del backup, exportar la base actual aunque esté dañada y, si hace falta, recuperar contenido reciente desde otras fuentes antes de dar por finalizada la restauración.
¿Cómo sé si es un plugin, el tema o el servidor?
La pista más fiable son los logs. Como prueba rápida, desactivar plugins por carpeta y forzar un tema alternativo ayuda a aislar el problema. Si todo sigue igual, revise recursos del hosting y conexión a base de datos. Este orden reduce pruebas inútiles y evita cambios irreversibles.
¿Qué hago si hay redirecciones raras o spam en idiomas que no uso?
Trátelo como un posible hackeo: cambie credenciales, revise usuarios, inspeccione .htaccess y wp-config.php, busque puertas traseras en la raíz y en wp-content, y limpie antes de reabrir el sitio. Si no se elimina el origen, el problema reaparecerá aunque el sitio “vuelva” temporalmente.
¿Necesitas asesoramiento legal?
Nuestro equipo de expertos está listo para ayudarte