¿Archivos principales modificados? Cómo restaurar los archivos principales de WordPress de forma segura

Estás viendo una pantalla en blanco donde solía estar tu página de inicio. Quizás sea un error 500 en su lugar, o una alerta de un plugin de seguridad que te dice que los archivos principales de WordPress han sido modificados.

He reemplazado archivos principales en sitios que rompí yo mismo y en sitios que aparecieron ya rotos. Sea lo que sea que te haya traído aquí, la solución es la misma y es menos destructiva de lo que parece.

Restaurar los archivos principales de WordPress significa intercambiar los propios archivos del programa de WordPress (los de wp-admin, wp-includes y tu directorio raíz) por copias limpias de WordPress.org. Tus posts, páginas, medios, temas, plugins y configuraciones no se mueven. Viven en otro lugar por completo.

Dos cosas salen mal cuando la gente intenta esto por su cuenta.

La primera es eliminar wp-content junto con las carpetas principales, lo que convierte una reparación de 20 minutos en una reconstrucción completa. La segunda es coger la versión más reciente de WordPress cuando el sitio está ejecutando algo más antiguo, lo que fuerza un salto de versión importante en un sitio que ya es inestable.

En esta publicación, te mostraré cómo confirmar que los archivos principales son el problema antes de eliminar nada, tres formas de reemplazarlos y qué hacer cuando reemplazarlos no es la solución real.

Puntos clave rápidos:

• Verifica antes de eliminar nada: wp core verify-checksums responde en un comando si los archivos principales son el problema, y un pase limpio significa que estarías reemplazando archivos que nunca estuvieron rotos.
• Iguala tu versión en lugar de coger la última: instalar la versión más reciente de WordPress en un sitio antiguo fuerza una actualización importante no planificada y un cambio de esquema de base de datos en un sitio que ya es inestable.
• Tienes tres rutas: el botón Reinstalar versión X.X.X si puedes iniciar sesión, un comando WP-CLI si tienes SSH y un intercambio manual por FTP si no tienes ninguno.
• Elimina las carpetas principales en lugar de sobrescribirlas: sobrescribir deja archivos añadidos por el atacante dentro de wp-admin y wp-includes porque nada en la compilación oficial reemplaza un archivo que no forma parte de ella.
• Los archivos principales limpios no limpian un sitio hackeado: las puertas traseras en wp-content/uploads, los mu-plugins maliciosos y las filas de base de datos inyectadas sobreviven, que es el punto en el que una restauración completa supera una reparación archivo por archivo.

Tabla de Contenidos

¿Cuáles son los archivos principales de WordPress?

Antes de eliminar nada, necesitas saber qué carpetas cuentan como archivos principales de WordPress y cuáles son tuyos. Equivocarse en esto es el error más costoso de todo el proceso.

Esto es lo que cuenta como un archivo principal:

• Todo en wp-admin. Este es el panel de administración en sí, cada pantalla a la que inicias sesión.
• Todo en wp-includes. Estas son las bibliotecas sobre las que se ejecuta WordPress. Es la carpeta más grande en número de archivos y la que tiene más probabilidades de ser marcada como modificada.
• Los archivos PHP sueltos en tu directorio raíz. Archivos como index.php, wp-login.php, wp-settings.php y wp-cron.php se encuentran junto a tus carpetas, y también se reemplazan.

¿Qué archivos de WordPress no deberías reemplazar?

Esto es lo que deberías dejar en paz:

• wp-content. Contiene subidas específicas del sitio, plugins instalados, temas, mu-plugins y, a veces, artefactos del host o de implementación. WordPress proporciona una copia de esta carpeta, pero la tuya es única.
• wp-config.php. Contiene tus credenciales de base de datos. Si lo sobrescribes, tu sitio no podrá encontrar su propio contenido.
• .htaccess. No es un archivo principal, pero WordPress escribe en él. Guarda una copia y deja el original en su lugar.
• Cualquier cosa que tu host o tu desarrollador haya añadido. Archivos de verificación de dominio, scripts personalizados, un robots.txt editado a mano. Si no vino en la descarga de WordPress, se queda.

Elimina wp-content y ya no restaurarás archivos principales. Estás reconstruyendo tu sitio desde cero.

¿Cuándo necesitas restaurar los archivos principales de WordPress?

Los archivos principales permanecen intactos durante meses. Cuando fallan, casi siempre se debe a una de unas pocas causas. Saber cuál estás experimentando cambia la forma en que manejas la limpieza posterior.

Aquí es cuándo reemplazar los archivos principales es la decisión correcta:

• Falló una actualización principal a mitad de camino. Se interrumpió la conexión, el servidor se agotó o PHP alcanzó su límite de memoria. Te quedas con algunos archivos de la versión anterior y otros de la nueva, y WordPress no tiene forma de reconciliarlas.
• Un escaneo informó que los archivos principales de WordPress fueron modificados. Wordfence, Sucuri y muchos hosts administrados comparan tus archivos con las versiones oficiales de WordPress.org. Un archivo principal modificado significa que se cambió código que nadie debería editar.
• Tu sitio fue hackeado. Los atacantes inyectan código en los archivos principales porque esos archivos se cargan en cada solicitud. Reemplazarlos elimina el código inyectado (no eliminará el resto de la infección, a lo que volveré más tarde).
• Los archivos se corrompieron durante una transferencia. Una sesión FTP interrumpida o una migración a medias dejan archivos truncados. Parecen normales en un listado de archivos y fallan la segunda vez que PHP intenta ejecutarlos.
• Una pantalla blanca o un error 500 sobrevivieron a la solución de problemas básica. Si has deshabilitado todos los plugins, cambiado a un tema predeterminado y el error no se ha movido, los archivos principales son el siguiente lugar donde buscar.
• Alguien editó un archivo principal a propósito. Esto sucede más a menudo de lo que crees. La edición se mantiene hasta que una actualización la sobrescribe o el archivo deja de coincidir con lo que espera WordPress.

Hay una situación en la que restaurar los archivos principales no te ayudará en absoluto: un plugin o tema roto. Este proceso no toca wp-content, por lo que si ese es el verdadero problema, harás todo el trabajo y te encontrarás con el mismo error. El paso 1 es cómo lo descubres antes de pasar una hora en ello.

Lo que necesitas antes de empezar

Aquí tienes lo que debes tener listo antes de restaurar los archivos principales de WordPress:

• Una copia de seguridad completa realizada ahora mismo. Guárdala en un lugar separado del servidor que estás a punto de modificar (recomiendo Duplicator Cloud). Si estás ejecutando Duplicator Pro, esto es lo que convierte una mala tarde en una restauración de un clic.
• Acceso a través de al menos una de estas opciones: El panel de administración de WordPress, SFTP o FTP (FileZilla es gratuito y cumple su función), el Administrador de Archivos de tu host o SSH. Solo necesitas una, y cuál tengas decide tu método en el Paso 4.
• Tu número de versión exacto de WordPress, anotado. Si el panel de administración no funciona, abre wp-includes/version.php a través de FTP y lee la línea $wp_version cerca de la parte superior.
• Copias locales de wp-config.php y .htaccess. Descarga ambos antes de tocar nada.
• De 15 a 30 minutos, dependiendo del método que termines usando.

Si tu sitio recibe tráfico real, haz esto durante una hora de poca actividad. Estará parcialmente roto mientras se ejecuta la carga.

Cómo restaurar los archivos principales de WordPress

El proceso consta de seis pasos. Tres de ellos son iguales sin importar qué, y el Paso 4 es donde eliges un camino basado en el acceso que aún tengas.

Así es como restaurarás tus archivos principales de WordPress:

• Paso 1: Confirma que los archivos principales son el problema. Un escaneo de checksum te dice si estás arreglando lo correcto antes de eliminar algo que no puedas deshacer.
• Paso 2: Haz una copia de seguridad del sitio antes de reemplazar nada. Una transferencia que se interrumpe a mitad del intercambio puede tumbar todo el sitio, y este es el paso que lo hace recuperable.
• Paso 3: Coincide con la versión de WordPress que estás restaurando. Descargar la versión incorrecta convierte una reparación en una actualización no planificada sobre un sitio roto.
• Paso 4: Reemplaza los archivos principales. Elige el panel de control, WP-CLI o FTP según el acceso que tengas, y ejecuta solo uno de los tres.
• Paso 5: Ejecuta la actualización de la base de datos y limpia los restos. Código nuevo contra un esquema antiguo, un archivo .maintenance atascado y cachés obsoletas se leen como "todavía está roto" cuando los archivos ya están bien.
• Paso 6: Verifica que la restauración funcionó. Un sitio que carga no es prueba de nada, y una segunda pasada limpia de checksum sí lo es.

Paso 1: Confirma que los archivos principales son el problema

Omite este paso y puedes pasar una hora reemplazando archivos que nunca estuvieron rotos. Lo he hecho. Un archivo principal corrupto y un error fatal de plugin se ven idénticos desde el exterior.

WP-CLI resuelve la cuestión en un comando.

WP-CLI es la herramienta de línea de comandos de WordPress, y la ejecutas a través de SSH (una conexión de terminal a tu servidor). La mayoría de los hosts gestionados la tienen instalada, así que compruébalo antes de asumir que está descartada.

Conéctate por SSH, muévete a tu directorio de WordPress y ejecuta:

wp core verify-checksums

WordPress.org publica un checksum para cada archivo en cada versión, que es una huella digital corta del contenido de ese archivo. El comando extrae la lista para tu versión y la compara con lo que hay en tu servidor.

Una instalación limpia devuelve una única línea de éxito. Una dañada nombra cada archivo que no puede verificar:

Warning: File doesn't verify against checksum: wp-includes/version.php

Error: WordPress installation doesn't verify against checksums.

Un resultado es una falsa alarma que vale la pena reconocer. readme.html falla constantemente porque los hosts lo modifican o eliminan. El comando detecta el idioma de tu instalación por sí solo, por lo que solo necesitas el indicador --locale (wp core verify-checksums --locale=de_DE, por ejemplo) si lo adivina mal.

Luego ejecútalo de nuevo con --include-root:

wp core verify-checksums --include-root

Ese indicador te advierte sobre archivos que se encuentran en tu directorio raíz que no forman parte de WordPress en absoluto. En un sitio hackeado, ahí es donde frecuentemente encuentras lo que causó esto en primer lugar.

Si no tienes acceso SSH, tienes tres formas más de comprobarlo:

• Ejecuta un escaneo de Wordfence. Su comparación de archivos principales hace el mismo trabajo desde dentro del panel de control y te muestra exactamente qué cambió en cada archivo.
• Usa la herramienta de integridad de archivos de tu host. La mayoría de los hosts gestionados tienen una, generalmente en una pestaña de seguridad o herramientas.
• Compara manualmente. Descarga una copia nueva de tu versión de WordPress, abre el archivo sospechoso de ambas copias y léelos uno al lado del otro.

Ahora lee tus resultados honestamente antes de seguir adelante. Si las sumas de verificación (checksums) son correctas, tus archivos principales están bien y tu problema es un plugin, un tema o tu base de datos.

Reemplazar los archivos principales no solucionará ninguno de esos problemas.

Estarás listo para el Paso 2 cuando tengas en tu poder una lista de archivos específicos que fallaron la verificación o un resultado limpio que te indica que busques en otro lado.

Paso 2: Haz una copia de seguridad del sitio antes de reemplazar nada

Estás a punto de eliminar dos carpetas que WordPress necesita para funcionar. Si la carga que las reemplaza se interrumpe a mitad de camino, tu sitio pasará de estar roto a desaparecer.

Ese es un problema peor que el que tienes ahora.

Realiza una copia de seguridad completa que cubra tanto tus archivos como la base de datos. Asegúrate de enviar una copia a un lugar distinto del servidor que estás a punto de editar. Una copia externa es el único tipo que sobrevive a un fallo a nivel de servidor.

Duplicator es mi herramienta favorita para esto. Ve a Duplicator Pro » Backups y haz clic en Add New.

Elige el preset de copia de seguridad Full Site y selecciona al menos dos ubicaciones de almacenamiento (a mí me gusta usar Local y Duplicator Cloud).

Terminarás con dos archivos: el archivo (archive), que contiene tu sitio y base de datos comprimidos, y el instalador (installer), que es el script PHP que lo restaura todo.

Si algo sale mal durante el proceso de restauración de archivos, vuelve a subir estos archivos a tu servidor y ejecuta el instalador de Duplicator.

Si no estás usando Duplicator, haz una copia de seguridad manual. Aquí tienes lo mínimo indispensable para este paso:

• Descarga wp-content, wp-config.php y .htaccess a tu ordenador por FTP.
• Exporta tu base de datos desde phpMyAdmin como un archivo .sql.

Estarás listo para continuar cuando sepas dónde está tu copia de seguridad y cómo la restaurarías.

Paso 3: Coincide con la Versión de WordPress que Estás Restaurando

Todos los tutoriales sobre este tema te dicen que descargues la última versión de WordPress. Ese es un buen consejo si tu sitio ya está ejecutando la última versión. Es una trampa si no lo está.

Supongamos que estás dos versiones principales por detrás. Introduces los archivos principales más recientes y aún no has reparado nada. Lo que has hecho es forzar una actualización de versión mayor y un cambio en el esquema de la base de datos sobre un sitio inestable, en medio de una emergencia, sin pruebas.

Restaura la versión que tienes. Actualiza más tarde, a propósito, una vez que el sitio esté saludable.

Aquí te explicamos cómo encontrar tu número de versión:

• Desde el panel: ve a Panel » Actualizaciones. La versión que estás ejecutando se indica en la parte superior de la pantalla.
• Por FTP: abre wp-includes/version.php y lee la línea $wp_version cerca de la parte superior del archivo. Esto funciona cuando nada más lo hace.
• Por SSH: ejecuta wp core version y te imprimirá el número.

Ahora, descarga esa compilación exacta del archivo de versiones de WordPress en lugar de la página de descarga principal. La página principal solo sirve la versión actual.

La descarga de los archivos principales de WordPress es un único archivo zip que contiene wp-admin, wp-includes, wp-content y los archivos raíz sueltos. Coincide con la cadena de versión completa, no solo con el número principal. Una versión de diferencia sigue siendo un conjunto de archivos distinto.

Si optas por la ruta de WP-CLI, puedes omitir la descarga por completo. El comando en el Método 2 a continuación lee tu versión y descarga los archivos coincidentes en un solo paso.

Estás listo para el Paso 4 cuando tengas un archivo zip de WordPress en tu ordenador que coincida con tu sitio o una terminal abierta y esperando.

Paso 4: Reemplaza los archivos principales

Este es el paso en el que los archivos dañados salen y entran los limpios. Hay tres maneras de hacerlo, y todas reemplazan los archivos del programa de WordPress con copias verificadas de WordPress.org, dejando tu contenido y configuraciones intactos.

Cuál uses depende del acceso que tengas:

• Método 1: El botón del panel. Úsalo si todavía puedes iniciar sesión en WordPress. Es el más rápido por un amplio margen.
• Método 2: WP-CLI. Úsalo si tienes SSH. Es el más preciso y es el único que fija tu versión dentro del mismo comando.
• Método 3: FTP manual. Úsalo cuando no tengas ninguno de los dos. Funciona en cualquier host y tiene más formas de salir mal.

Método 1: Usa el botón Reinstalar del panel

Si wp-admin todavía carga, empieza aquí. Es la forma más rápida de reinstalar el núcleo de WordPress, y no tendrás que tocar una sola carpeta.

Ve a Panel » Actualizaciones. Cuando ya estés en la versión actual, WordPress te lo dice y te ofrece reinstalar esa versión, con un botón de Reinstalar versión X.X.X.

Haz clic en él. WordPress descargará la actualización, desempaquetará la actualización del núcleo, verificará los archivos desempaquetados, instalará la última versión y actualizará la base de datos. Termina con un mensaje de éxito en la misma pantalla.

Conoce una limitación antes de empezar. Esto reinstala la versión en la que WordPress cree que deberías estar, por lo que no puede llevarte hacia atrás. Si una actualización errónea es lo que rompió tu sitio, este botón no lo revertirá.

También sobrescribe archivos en lugar de eliminar carpetas, al igual que el Método 2. Cualquier cosa que un atacante haya añadido dentro de wp-admin o wp-includes permanece. Si estás limpiando un hackeo, usa el Método 3, o confirma después con una comprobación de checksum que no quede nada extra.

Algunos hosts interrumpen el proceso con un diálogo de Información de conexión pidiendo credenciales FTP. Ese es un problema de propiedad de archivos, y la sección de solución de problemas a continuación cubre la solución.

Método 2: Usa WP-CLI

WP-CLI es lo que uso siempre que tengo acceso a la terminal. Conéctate por SSH, muévete a tu directorio de WordPress y ejecuta:

wp core download --version=$(wp core version) --force --skip-content

Aquí tienes lo que hace cada parte:

• --version=$(wp core version) lee la versión que tu sitio está ejecutando y descarga esa versión exacta.
• --force sobrescribe los archivos existentes. Sin él, WP-CLI se niega a tocar un directorio que ya contiene WordPress.
• --skip-content deja wp-content fuera de la descarga por completo, por lo que tus temas, plugins y subidas nunca se acercan a la sobrescritura.

No uses wp core install aquí, aunque el nombre suene correcto. Ese comando ejecuta la rutina de instalación de WordPress en un sitio nuevo, y es la herramienta incorrecta para un sitio que ya existe.

Antes de pulsar intro, ten en cuenta que --force no pide confirmación. Si alguien editó deliberadamente un archivo principal en este sitio, esa edición desaparece en el momento en que se ejecuta el comando. Normalmente ese es el objetivo, pero consulta con quien haya creado el sitio si no estás seguro.

Luego confirma el resultado:

wp core verify-checksums

Una pasada limpia significa que la mitad del problema, la de los archivos, está resuelta.

Método 3: Reemplaza los archivos manualmente por FTP

Cuando no puedes acceder al panel de administración y no tienes SSH, haces el mismo trabajo a mano: quitas las dos carpetas principales del servidor y pones unas nuevas en su lugar.

Ninguno de los movimientos individuales es difícil. La secuencia es lo que protege los archivos que necesitas conservar, así que vale la pena seguirla en orden.

1. Desactiva tus plugins si todavía puedes acceder al panel de administración. Sáltatelo si no puedes. Esto es una precaución, no un requisito.
2. Descomprime la descarga de WordPress en tu ordenador. Verás wp-admin, wp-includes, wp-content y un puñado de archivos sueltos.
3. Elimina wp-admin y wp-includes del servidor. Ambas carpetas, completamente. Deja todo lo demás exactamente donde está.
4. Sube los nuevos wp-admin y wp-includes de tu copia descomprimida a la misma ubicación.
5. Sube los archivos raíz sueltos de la nueva compilación y sobrescribe los antiguos. No elimines tu carpeta raíz primero. Te llevarías wp-config.php y .htaccess con ella.
6. Copia los archivos de dentro de wp-content a tu wp-content existente. Copia dentro de él. Nunca lo reemplaces.
7. Confirma que wp-config.php y .htaccess siguen en tu raíz. Si falta alguno, sube la copia que guardaste antes.

El paso 3 de esa lista es donde la gente duda, porque eliminar parece más arriesgado que sobrescribir. Es lo contrario.

Sobrescribir solo reemplaza los archivos que existen en ambas copias. Cualquier cosa que un atacante haya introducido en wp-admin o wp-includes no forma parte de la compilación oficial, por lo que nada la sobrescribe y pasa desapercibida en toda tu limpieza. Eliminar las carpetas primero es lo que hace que esto sea una solución real en lugar de una cosmética.

Establece también tus expectativas sobre el tiempo. Solo wp-includes tiene más de mil archivos, y FTP los mueve uno a uno. Veinte minutos es normal en una conexión lenta, y pueden ocurrir transferencias interrumpidas.

Si la subida sigue fallando, envía el zip a tu servidor como un solo archivo y extráelo allí con el Gestor de Archivos de tu hosting. Una transferencia grande es mucho más fiable que mil pequeñas.

Has superado este paso cuando tu estructura de carpetas coincide con la copia nueva, wp-config.php está intacto y el sitio carga, aunque te salude con una solicitud de actualización de la base de datos.

Paso 5: Ejecuta la actualización de la base de datos y borra los restos

Tus archivos están limpios ahora, pero WordPress puede seguir en el estado en que lo dejó la actualización fallida. Tres pequeñas limpiezas terminan el trabajo.

Empieza visitando /wp-admin. Es posible que se te pida iniciar sesión de nuevo, lo cual es normal.

Si WordPress detecta que tu base de datos necesita ponerse al día con el código, muestra una pantalla de Actualización de base de datos requerida con un botón de Actualizar base de datos de WordPress. Haz clic en él y deja que se ejecute.

Haz esto de inmediato, porque hasta que no lo hagas, tu sitio estará ejecutando código nuevo contra un esquema antiguo.

A continuación, busca en tu directorio raíz un archivo llamado .maintenance y elimínalo si está ahí. WordPress crea ese archivo al inicio de una actualización y lo elimina cuando la actualización se completa. Cuando una actualización falla a mitad de camino, el archivo se queda atrás y los visitantes ven el mensaje de mantenimiento.

Es un archivo oculto, por lo que no aparecerá en tu lista de archivos hasta que actives los archivos ocultos. En FileZilla, es Servidor » Forzar visualización de archivos ocultos, y en la mayoría de los administradores de archivos de hosting, es una casilla de verificación Mostrar archivos ocultos en la configuración.

Luego, limpia todas las cachés que tengas: tu plugin de caché, la caché del servidor de tu hosting, tu CDN y tu propio navegador. Si omites esto, puedes pasar 20 minutos depurando una página que ya estaba arreglada.

Reactiva tus plugins si los desactivaste durante el Método 3.

Habrás terminado aquí cuando el panel de control se cargue, la indicación de actualización haya desaparecido y tu frontend se renderice.

Paso 6: Verifica que la restauración funcionó

Un sitio que carga no es lo mismo que un sitio que está arreglado. Antes de cerrar la pestaña, repasa esta lista.

Esto es lo que debes comprobar:

• Vuelve a ejecutar wp core verify-checksums. Una ejecución limpia es la única prueba definitiva de que tus archivos principales coinciden con la versión oficial.
• Carga tu frontend sin iniciar sesión en una ventana de navegación privada. Las vistas de sesión iniciada ocultan problemas de caché y errores de permisos.
• Haz clic en las páginas importantes. Tu página de inicio, una entrada individual, un archivo de categoría, la pantalla de inicio de sesión y cualquier formulario o proceso de pago del que dependas.
• Vuelve a guardar tus permalinks. Ve a Ajustes » Permalinks y haz clic en Guardar cambios sin cambiar nada. Eso regenera tus reglas de reescritura, que es la razón habitual por la que las entradas empiezan a devolver 404s después de un intercambio de archivos.
• Confirma tus URLs. En Ajustes » Generales, comprueba que Dirección de WordPress (URL) y Dirección del sitio (URL) digan exactamente lo que decían antes.
• Lee tu registro de errores. Cualquier cosa nueva ahí merece la pena ser tratada ahora, mientras todavía recuerdas lo que cambiaste.

Luego haz una copia de seguridad más. Tu sitio se encuentra en un estado conocido y correcto en este preciso momento, que es el estado que vale la pena capturar, y es una copia mucho más útil de conservar que la de emergencia que hiciste en el Paso 2.

¿Qué pasa si reemplazar los archivos principales no soluciona el problema?

A veces, sigues todos los pasos, las sumas de verificación son correctas y el sitio sigue fallando. Cuando eso sucede, los archivos principales dañados eran un síntoma en lugar de la causa.

Tres escenarios explican la mayoría de estos casos:

• El sitio fue hackeado. Reemplazar los archivos principales elimina el código inyectado de los archivos principales y nada más. Una puerta trasera en wp-content/uploads, un archivo functions modificado en el tema o algo oculto en mu-plugins sobreviven a esto. El indicio más claro son los archivos PHP en tu carpeta de uploads, donde solo deberían estar los medios.
• La base de datos también sufrió daños. Tus archivos están bien y tu contenido también. Los enlaces de spam inyectados en la tabla posts, un sitiourl reescrito en la tabla options y cuentas de administrador desconocidas sobreviven a una restauración de los archivos principales.
• Las sumas de verificación (checksums) son correctas y el sitio todavía da errores. Eso apunta a un plugin, un tema o una incompatibilidad de versión de PHP. El paso 1 te envió por el camino correcto; los archivos principales nunca fueron el problema.

En los tres casos, restaurar todo el sitio desde una copia de seguridad en la que confíes es mejor que revisarlo archivo por archivo. Dejas de adivinar qué está limpio.

En Duplicator Pro, busca una copia de seguridad anterior al inicio de los problemas y restáurala.

Si esa copia de seguridad se encuentra en Google Drive, Dropbox u otra ubicación de almacenamiento conectada, puedes restaurarla directamente desde WordPress sin necesidad de descargar y volver a subir el archivo primero.

Si WordPress no se carga en absoluto, vuelve a subir la copia de seguridad con la que empezaste a tu directorio raíz. Inicia el instalador de Duplicator con una URL como: https://tudominio.com/installer.php

Una restauración devuelve tu sitio al momento en que se tomó esa copia de seguridad, por lo que todo lo publicado u ordenado desde entonces se va con ella. En un sitio comprometido, esa suele ser la decisión correcta, porque una limpieza parcial que omita una puerta trasera te devuelve aquí en una semana.

Duplicator no escanea ni elimina malware. Te proporciona una copia limpia de un sitio que funcionaba. Combínalo con un escáner de seguridad si estás lidiando con una infección activa.

Para la ruta manual, Cómo restaurar manualmente tu sitio de WordPress cubre la restauración de archivos y bases de datos a mano, y Cómo restaurar un sitio web con solo una copia de seguridad de la base de datos cubre qué hacer cuando la base de datos es todo lo que te queda.

Solución de problemas: Errores comunes después de restaurar los archivos principales

Estos son los fallos que aparecen con más frecuencia después de un intercambio de archivos principales. Trabaja a partir del síntoma que estés observando.

¿Por qué mi sitio dice "Brevemente no disponible por mantenimiento programado"?

Aparece una página blanca simple con una sola línea de texto y no desaparece.

WordPress escribe un archivo llamado .maintenance en tu directorio raíz cuando comienza una actualización y lo elimina cuando finaliza. Si la actualización falló en el medio, ese archivo todavía está allí y WordPress no tiene forma de saber que el trabajo nunca se completó. WordPress deja de tener en cuenta el archivo después de 10 minutos, pero una actualización fallida puede dejar tu sitio medio actualizado mientras tanto.

Elimina .maintenance de tu directorio raíz por FTP con los archivos ocultos activados. Por SSH, wp maintenance-mode deactivate hace lo mismo. Tu sitio vuelve a la normalidad en el momento en que el archivo desaparece.

¿Por qué se me pide información de conexión FTP?

Haces clic en Reinstalar versión X.X.X y WordPress abre un diálogo de Información de conexión pidiendo un nombre de host, nombre de usuario y contraseña. Este es un problema de propiedad de archivos.

WordPress escribe archivos directamente solo cuando son propiedad del mismo usuario con el que se ejecuta el servidor web. Cuando no lo son, solicita credenciales FTP para poder escribirlos de otra manera.

Introduce las credenciales de la cuenta FTP que posee tus archivos de WordPress y continuará. Si no las tienes, pide a tu proveedor que corrija la propiedad, que es la solución real.

También encontrarás consejos en línea sobre cómo añadir define('FS_METHOD', 'direct'); a wp-config.php. A veces funciona, pero evita el síntoma y puede fallar más adelante de formas más difíciles de diagnosticar que el diálogo.

¿Por qué obtengo una pantalla en blanco después de reemplazar los archivos principales?

No carga nada, ni el frontend ni el admin, y no hay texto de error para trabajar. Tres causas cubren casi todos estos casos: una transferencia FTP que terminó de forma incompleta, permisos de archivo incorrectos durante la carga o un error fatal de PHP que se está suprimiendo.

Vuelve a cargar primero wp-includes, ya que es la carpeta más grande y la que tiene más probabilidades de haber perdido archivos. Luego comprueba tus permisos, que deberían ser 644 para archivos y 755 para carpetas.

Si la pantalla sigue en blanco, añade define('WP_DEBUG', true); y define('WP_DEBUG_LOG', true); a wp-config.php y lee wp-content/debug.log. Eso convierte una pantalla blanca en un nombre de archivo y un número de línea.

¿Por qué las sumas de verificación siguen fallando después de una reinstalación limpia?

Has reemplazado todo y wp core verify-checksums sigue mostrando advertencias. Normalmente son tres cosas: readme.html está marcado porque tu proveedor lo modifica o elimina, el comando eligió el idioma incorrecto para tu instalación o algo en esas carpetas realmente no pertenece allí.

Si cada archivo está marcado, vuelve a ejecutarlo con tu configuración regional (wp core verify-checksums --locale=fr_FR, por ejemplo) y mira qué queda. Una advertencia de "El archivo no debería existir" significa que algo extra está en una carpeta principal y la sobrescritura no lo eliminará. Elimina wp-admin y wp-includes por completo y sube copias nuevas, que es la diferencia que hace el Método 3.

¿Por qué WordPress dice que una actualización ya está en curso?

Intentas reinstalar y te dice "Otra actualización está actualmente en progreso". WordPress establece un bloqueo en tu tabla de opciones cuando comienza una actualización principal, por lo que dos actualizaciones no pueden ejecutarse al mismo tiempo. Una actualización fallida deja ese bloqueo sin nada que lo elimine.

El bloqueo expira por sí solo después de 15 minutos, por lo que esperar no te cuesta nada más que tiempo. Para eliminarlo ahora, ejecuta wp option delete core_updater.lock, o abre tu tabla de opciones en phpMyAdmin, busca la fila core_updater.lock y elimínala.

Nada funciona: ¿Y ahora qué?

Has seguido la lista y el sitio sigue caído. En este punto, deja de reparar y empieza a restaurar.

Vuelve a la copia de seguridad que hiciste en el Paso 2. Si todavía puedes acceder al panel, realiza una restauración con un clic desde Duplicator Pro » Copias de seguridad. Si no puedes, vuelve a subir el archivo y el instalador a tu directorio raíz y ejecuta el instalador en tu navegador, lo que funciona sin una instalación de WordPress funcional detrás.

Si no tienes una copia de seguridad, ponte en contacto con tu proveedor de alojamiento y pregunta por una instantánea del lado del servidor. La mayoría de los proveedores de alojamiento guardan copias de seguridad diarias en una ventana rotatoria, incluso en planes compartidos, y el soporte técnico puede restaurar una por ti.

Preguntas Frecuentes (FAQs)

Los archivos principales limpios son la base: esto es lo que debes hacer a continuación

Has reemplazado los archivos del programa de WordPress con copias verificadas y lo has confirmado con una comprobación de suma de verificación. Esa comprobación importa más que simplemente la carga del sitio. Un sitio puede cargarse perfectamente bien con un archivo principal modificado ejecutando silenciosamente el código de otra persona en cada solicitud, por lo que el paso de diagnóstico vino antes que nada.

Tres hábitos te sacan de esto a partir de ahora.

• Programa tus copias de seguridad en lugar de hacerlas cuando te acuerdes.
• Realiza una copia de seguridad reciente después de cada actualización exitosa, de modo que tu estado más reciente conocido como bueno nunca esté a más de una restauración de distancia.
• Ejecuta wp core verify-checksums como una comprobación mensual rutinaria en lugar de una medida de emergencia, porque un archivo principal modificado que detectas durante una comprobación de estado es un problema mucho menor que uno que descubres cuando el sitio deja de funcionar.

Una cosa más que vale la pena hacer mientras ya estás en wp-config.php. Agrega define('DISALLOW_FILE_EDIT', true); para desactivar los editores de temas y complementos integrados, lo que cierra la ruta más fácil para que cualquier persona con acceso de administrador cambie un archivo desde el panel. Luego, agrega un pequeño archivo .htaccess en wp-content/uploads que impida la ejecución de PHP allí:

<Files *.php>

Require all denied

</Files>

Esa segunda opción es sintaxis de Apache 2.4, por lo que en nginx querrás el bloque de ubicación equivalente en la configuración de tu servidor. Juntos cierran las dos puertas que pusieron a la mayoría de las personas en esta situación para empezar, y ninguna lleva más de un minuto.

Deja de reparar sitios de WordPress a mano

Reemplazar los archivos principales manualmente funciona. También te cuesta una tarde y solo ayuda si detectas el problema antes de que se propague. Una copia de seguridad reciente y una restauración con un clic convierten esa larga sesión de depuración en dos minutos.

Duplicator Pro es lo que más de 1.5 millones de usuarios activos confían para copias de seguridad programadas, restauraciones con un clic directamente desde el almacenamiento en la nube y una URL de recuperación ante desastres que aún funciona cuando WordPress no se carga. Cada plan de pago viene con un reembolso de 14 días sin preguntas.

Si este tutorial te ha sido útil, estas guías también merecen ser marcadas.

• Cómo restaurar WordPress desde una copia de seguridad (en menos de 5 minutos)
• Cómo restaurar manualmente tu sitio de WordPress
• Cómo restaurar un sitio web con solo una copia de seguridad de la base de datos
• Cómo degradar tu versión de WordPress y revertir actualizaciones fallidas
• Cómo restaurar su sitio de WordPress a partir de una copia de seguridad de Google Cloud
• Cómo restaurar un sitio de WordPress a una fecha anterior sin copia de seguridad