Reparar WordPress tras restaurar backup incompleto

Cuando toca reparar WordPress después de una restauración parcial, el problema no suele ser solo “que falten cosas”, sino que puede existir un desajuste entre archivos, base de datos y configuración del entorno. Esto ocurre con frecuencia cuando la copia no incluía todo wp-content, cuando la base de datos se restauró desde otro momento distinto o cuando el hosting aplicó cambios de PHP, rutas o caché durante la recuperación.

Lo más útil al principio es aislar qué parte ha quedado incompleta: primero conviene comprobar si faltan archivos críticos, si la base de datos contiene todas las tablas esperadas y si las credenciales y URLs siguen siendo coherentes. No es recomendable tocar todo a la vez, porque mezclar pruebas sobre archivos, plugins, base de datos y caché puede dificultar el diagnóstico.

En esta guía encontrarás un procedimiento práctico para revisar una copia restaurada a medias, recuperar archivos y tablas faltantes, validar wp-config.php y dejar el sitio estable antes de dar por cerrada la incidencia. Si el problema empezó porque el backup de WordPress falla al restaurar, este contexto te ayudará a entender mejor el origen.

Qué significa restaurar una copia de seguridad incompleta en WordPress

Una restauración incompleta no implica necesariamente que el backup esté corrupto. En muchos casos significa que solo se ha recuperado una parte del sitio: por ejemplo, la base de datos sí se importó, pero faltan directorios de uploads; o se restauró wp-content, pero no coincide con el estado de las tablas que registran plugins activos, opciones o metadatos de medios.

También puede deberse a una restauración interrumpida por límites del hosting, falta de espacio en disco, errores en la importación SQL, permisos de archivos incorrectos o copias remotas descargadas de forma parcial. Según el entorno, el sitio puede mostrar síntomas muy distintos:

• pantalla blanca o error fatal por plugin o tema ausente,
• medios que no cargan porque faltan ficheros en wp-content/uploads,
• enlaces rotos o redirecciones extrañas por valores incorrectos de siteurl y home,
• mensaje de Error establishing a database connection por credenciales o nombre de base de datos no válidos,
• plugins desaparecidos o desactivados al no encontrarse sus carpetas,
• bucles de login por URL, cookies, caché o diferencias entre HTTP y HTTPS.

La clave es entender si el fallo está en la completitud del backup, en la coherencia entre sus partes o en la adaptación al servidor donde se ha restaurado.

Cómo diagnosticar qué se ha perdido tras la restauración

Antes de modificar nada, conviene documentar el estado real del sitio. El objetivo no es “probar por probar”, sino comparar qué existe en disco, qué aparece en la base de datos y qué error devuelve WordPress o el servidor.

Checklist de diagnóstico rápido

Si tienes acceso al panel del hosting, a un gestor de archivos o a SFTP, compara el contenido real del sitio con la estructura esperada. Si además dispones de la copia original comprimida, es recomendable verificar si el problema está en la restauración o ya venía del backup.

En paralelo, conviene revisar los registros de errores de PHP o del servidor web. En muchos hostings españoles se pueden consultar desde el panel de control. Si prefieres usar WordPress para depurar, puede ser útil activar el modo de depuración en un entorno controlado, siempre evitando mostrar errores al público en producción.

Síntomas frecuentes y lectura técnica

• Pantalla blanca: puede deberse a un plugin activo en base de datos cuya carpeta no existe, a un tema faltante o a incompatibilidad con la versión de PHP.
• Medios que no cargan: suele apuntar a archivos faltantes en uploads, permisos incorrectos o URLs heredadas de otro dominio.
• Plugins desaparecidos: la base de datos puede conservar su configuración, pero si no están sus directorios, WordPress no podrá cargarlos.
• Error de conexión: conviene validar credenciales, host de base de datos, prefijo y que la base importada sea la correcta.
• Bucles de acceso: pueden relacionarse con siteurl, home, caché persistente o diferencias entre HTTP y HTTPS.

Revisar archivos críticos de WordPress antes de tocar la base de datos

Antes de importar tablas, ejecutar reparaciones o cambiar opciones en la base de datos, conviene asegurarse de que la parte de archivos está razonablemente completa. Si el sitio arranca con código incompleto, cualquier corrección posterior puede quedar enmascarada por errores fatales o rutas inexistentes.

1. Verifica la estructura básica

Como mínimo deberían existir las carpetas principales de WordPress y el archivo wp-config.php. Además, dentro de wp-content conviene revisar:

• themes, especialmente el tema activo y, si existe, el tema hijo,
• plugins, comprobando si están las carpetas de extensiones esenciales,
• uploads, validando que existan los directorios y ficheros de medios esperados,
• archivos especiales como .htaccess si el servidor usa Apache o configuraciones equivalentes según el entorno.

2. Comprueba si falta el tema o algún plugin imprescindible

Si la base de datos indica un tema activo cuya carpeta no está presente, WordPress puede caer a un tema por defecto o devolver errores según la versión y el contexto. Lo mismo ocurre con plugins marcados como activos. No es raro ver un sitio que parece “medio vivo” porque carga la parte pública, pero rompe al acceder al administrador por una dependencia ausente.

Si dispones de una copia fiable de esos directorios, restaurarlos primero suele ser más seguro que empezar a desactivar elementos directamente en la base de datos. Si no la tienes, documenta qué falta antes de seguir.

3. Revisa la integridad de uploads

Una incidencia muy habitual tras restaurar una copia de seguridad WordPress es que la biblioteca de medios exista en la base de datos, pero los archivos físicos no estén en disco. En ese escenario, las entradas y páginas pueden seguir ahí, pero las imágenes devolverán errores 404 o quedarán rotas en el front-end.

Conviene comprobar varios meses o años concretos dentro de uploads y no solo la presencia de la carpeta principal. Una carpeta vacía o con menos contenido del esperado puede apuntar a una sincronización incompleta.

4. Contrasta versión de PHP y compatibilidades

Después de una restauración, el código puede volver a un estado antiguo mientras el servidor mantiene una versión de PHP más reciente. Eso puede romper funciones del tema, plugins o personalizaciones. También puede ocurrir al revés: una copia moderna sobre un entorno con PHP desactualizado.

No hace falta asumir que la restauración “está mal” si aparece un error fatal. A veces el backup es correcto, pero el entorno actual ya no coincide con el que tenía el sitio cuando se generó la copia.

Cómo reparar la base de datos y volver a sincronizar el sitio

Una vez revisados los archivos, toca confirmar que la base de datos está completa y corresponde al mismo estado lógico del sitio. Aquí el objetivo no es solo “que conecte”, sino que la información almacenada sea coherente con los plugins, el tema y los medios disponibles.

1. Confirma que están todas las tablas necesarias

Desde phpMyAdmin o una herramienta equivalente, comprueba que existan las tablas estándar de WordPress y, en su caso, las adicionales creadas por plugins relevantes. Si la importación SQL se cortó, puede que falten tablas completas o que algunas aparezcan con tamaño anómalamente bajo.

Revisa también el prefijo. Si en wp-config.php se define uno distinto al usado por las tablas importadas, WordPress intentará leer tablas que no existen o parecerá una instalación nueva.

2. Valida la conexión antes de reparar

Si aparece un error de conexión, conviene verificar nombre de base de datos, usuario, contraseña y host configurados. En algunos hostings el host no es localhost, y usar un valor incorrecto impide acceder aunque las tablas estén bien.

Si tienes acceso a WP-CLI y el entorno lo permite, puede ser útil utilizarlo para confirmar el estado de la instalación o ejecutar comprobaciones puntuales. No obstante, no es un requisito universal, ya que muchos usuarios operan únicamente desde panel de hosting y phpMyAdmin.

3. Repara tablas si hay indicios reales de corrupción

No toda incidencia tras una restauración implica tablas corruptas. Aun así, si la herramienta de base de datos muestra errores de estructura o tablas marcadas como dañadas, puede tener sentido ejecutar una reparación con los mecanismos disponibles del hosting o mediante procedimientos propios de WordPress, siempre con copia previa del estado actual.

Es importante distinguir entre corrupción y desincronización. Si la tabla existe y funciona, pero referencia plugins, adjuntos o rutas que ya no están presentes, el problema no se arregla “reparando” la tabla: hay que restaurar la parte faltante o ajustar los datos con criterio.

4. Sincroniza contenido, plugins y medios con el estado de la base

Después de restaurar una base de datos, conviene revisar estas correspondencias:

• si un plugin figura como activo, su carpeta debe existir y ser compatible con la versión de PHP,
• si el tema activo está definido en opciones, sus archivos deben estar presentes,
• si hay adjuntos en la biblioteca, los ficheros deberían existir en uploads,
• si el sitio procede de una migración o clonación, las URLs y rutas antiguas pueden requerir ajuste.

Si recuperas elementos desde otra copia, intenta que archivos y base de datos pertenezcan a ventanas temporales cercanas. Mezclar una base de datos muy reciente con un wp-content mucho más antiguo puede dejar el sitio operativo, pero con incoherencias funcionales difíciles de detectar al principio, incluido algún error de actualización de base de datos.

Revisar wp-config.php, URLs y ajustes clave tras la recuperación

Una restauración que aparentemente “ha terminado bien” puede seguir fallando por configuración. El archivo wp-config.php y varios ajustes almacenados en la base de datos son determinantes para que WordPress arranque con normalidad.

Elementos clave en wp-config.php

• Credenciales de base de datos: revisa DB_NAME, DB_USER, DB_PASSWORD y DB_HOST.
• Prefijo de tablas: debe coincidir con las tablas realmente importadas.
• Modo debug: puede ayudarte a localizar errores, pero conviene gestionarlo con cautela en producción.
• Constantes personalizadas: si el sitio dependía de ajustes específicos de caché, rutas o entorno, una copia antigua de este archivo puede no encajar con el servidor actual.

Revisión de siteurl y home

Los valores siteurl y home merecen una comprobación explícita. Si apuntan a otro dominio, a una URL temporal o a una versión HTTP cuando el sitio trabaja ya en HTTPS, pueden aparecer redirecciones erráticas, acceso roto al administrador o recursos que cargan desde una ubicación incorrecta.

Si la restauración se ha hecho tras una migración WordPress o en un dominio provisional, este punto es especialmente sensible. Conviene revisar también si el hosting aplica redirecciones desde panel, reglas del servidor o certificados que estén influyendo en el comportamiento final.

Caché, cookies y sesiones

Tras una recuperación parcial, la caché puede confundir bastante el diagnóstico. Puede mostrar páginas antiguas, provocar que parezca que un cambio no ha surtido efecto o mantener redirecciones que ya no corresponden. Por eso es recomendable vaciar:

• caché de plugins, si el acceso al panel lo permite,
• caché del hosting o del servidor, si existe,
• caché del navegador para validar el comportamiento real.

Si persisten bucles de login o comportamientos extraños en sesiones, revisa además que dominio, protocolo y cookies estén alineados con la URL final del sitio.

Validaciones finales para dejar WordPress estable y seguro

Cuando el sitio vuelve a cargar, todavía no conviene dar la recuperación por cerrada. La revisión post-restauración debe confirmar que WordPress funciona de forma estable y que no quedan incoherencias ocultas.

Comprobaciones mínimas antes de darlo por válido

1. Accede al frontal y al administrador sin errores fatales ni redirecciones anómalas.
2. Abre varias entradas, páginas y categorías para detectar enlaces rotos o contenidos incompletos.
3. Comprueba que las imágenes y documentos cargan desde uploads.
4. Verifica que el tema activo es el correcto y que su maquetación no ha perdido recursos.
5. Revisa los plugins esenciales uno por uno, especialmente seguridad, caché, formularios, SEO, comercio electrónico o membresía si aplica.
6. Confirma que la versión de PHP del hosting es compatible con el conjunto actual de WordPress, tema y plugins.
7. Consulta de nuevo los logs para detectar avisos persistentes o errores silenciosos.

Seguridad y consistencia después de la reparación

Si la restauración implicó mover copias entre servidores, dejar archivos temporales o probar credenciales, conviene cerrar esa parte operativa. Elimina copias descomprimidas que no deban quedar accesibles, revisa permisos según las políticas del hosting y confirma que las copias de seguridad futuras vuelven a ejecutarse correctamente.

También es buena práctica generar una nueva copia completa una vez validado el sitio. Así dispondrás de un punto de restauración ya coherente, en lugar de seguir dependiendo del backup que originó la incidencia, especialmente si antes has trabajado en staging para pruebas seguras.

Si necesitas una referencia técnica oficial sobre tareas de mantenimiento y gestión de WordPress, puedes consultar la documentación de WordPress.org en https://wordpress.org/documentation/.

Prioridades tras una restauración parcial y siguiente paso razonable

Si necesitas priorizar, el orden más sensato suele ser este: identificar qué falta, revisar archivos críticos, comprobar tablas y prefijo, validar wp-config.php, corregir URLs y limpiar caché. Solo después conviene dar el sitio por recuperado.

El error más frecuente tras una copia restaurada a medias es asumir que el problema está solo en la base de datos o solo en los plugins, cuando en realidad existe un desajuste entre archivos y base de datos. Ese desfase puede dejar WordPress funcionando “a medias” y generar incidencias posteriores más difíciles de rastrear.

Si tras estas comprobaciones el sitio sigue inestable, el siguiente paso razonable es comparar la copia restaurada con otra versión del backup o trabajar sobre un entorno de staging para rehacer la recuperación con control. Cuando la incidencia afecta a negocio, formularios, acceso al administrador o integridad de datos, suele compensar escalar la revisión técnica antes de seguir aplicando cambios sobre producción.