Un cliente te avisa de que tu web lo manda a una página extraña. Entras tú y parece estar todo bien. O el hosting suspende el sitio, Google muestra una advertencia y aparecen páginas que nadie de tu empresa ha escrito. La primera reacción suele ser probar cosas hasta que vuelva a funcionar. Es comprensible. También es una buena manera de perder pistas y complicar la recuperación.
Si tu WordPress está hackeado, hay que contener el problema, conservar una copia del estado actual y decidir cómo recuperar una versión fiable. Después toca cerrar el acceso que permitió la intrusión y comprobar que el negocio puede volver a operar. Que la portada cargue otra vez es una buena noticia; todavía queda trabajo.
Vamos a recorrer ese orden. Si no tienes acceso al hosting o no sabes distinguir los archivos de WordPress de los de tu proyecto, pide ayuda desde el principio. Puedes avanzar mucho reuniendo la información correcta, sin tener que improvisar una operación a corazón abierto sobre tu web.
Cómo saber si tu WordPress está hackeado
Una página lenta o un error al actualizar un plugin no bastan para diagnosticar una intrusión. Tampoco recibir spam en un formulario: puede estar funcionando exactamente como lo configuraste, para desgracia de tu bandeja de entrada.
Las señales que sí justifican investigar son más concretas:
- Redirecciones a dominios ajenos, a veces solo desde Google, desde el móvil o cuando no has iniciado sesión.
- Páginas, enlaces o productos que no has creado, incluidos resultados en Google con textos extraños bajo tu dominio.
- Cuentas de administrador o cambios de permisos sin explicación, modificaciones de archivos o tareas programadas que no corresponden al trabajo del equipo.
- Avisos del hosting, del navegador o de Search Console sobre código malicioso, contenido engañoso o actividad anómala.
Que tú no veas la redirección no invalida el aviso del cliente. Algunas alteraciones cambian de comportamiento según quién visita la web. Anota la URL, la hora, cómo llegó la persona y qué ocurrió. Pide una captura del aviso si ya la tiene; no le pidas que vuelva a entrar en una página peligrosa para hacerte el favor.
El hosting puede revisar registros y archivos, y Search Console puede aportar ejemplos de páginas afectadas. Esos ejemplos son pistas, no un inventario completo de la infección. Tampoco la ausencia de alertas certifica por sí sola que todo esté bien.
Qué hacer primero si han hackeado tu web
Antes de actualizar, borrar o restaurar, contacta con el hosting y explica qué has observado. Pide que conserve los registros disponibles y te ayude a limitar la exposición del sitio. Si se están mostrando páginas fraudulentas o se puede perjudicar a visitantes, la prioridad es impedir que sigan llegando a ellas.
La contención conviene hacerla desde una capa que controles, como el alojamiento o el servidor, con ayuda de quien lo administra. Un plugin de mantenimiento dentro de la instalación comprometida puede no bloquear todos los accesos. Si tienes campañas enviando tráfico, páusalas mientras resuelves el incidente. No hace falta pagar por presentar el problema a más gente.
Conserva una copia de los archivos, la base de datos y los registros disponibles antes de empezar a modificar. Guarda ese material de forma privada y fuera de la carpeta pública. Esta copia sirve para investigar y recuperar información si algo sale mal; puede contener la infección y no debe confundirse con una copia limpia para restaurar.
Al mismo tiempo, protege los accesos desde un dispositivo fiable. Empieza por el correo que permite recuperar contraseñas y por la cuenta del hosting. Revisa después administradores de WordPress, accesos de archivos, claves de aplicaciones e integraciones y sesiones abiertas. Cambiar solo tu contraseña del panel deja fuera bastantes puertas.
Si ya no puedes entrar en WordPress, utiliza la recuperación por correo solo si sigues controlando esa cuenta. Si también la han cambiado, recupera el control con el proveedor del alojamiento. No crees un segundo administrador a ciegas mientras desconoces quién conserva acceso al servidor.
Restaurar una copia o limpiar WordPress: qué conviene
Restaurar suele ser una buena opción cuando existe una copia completa, comprobada y anterior al compromiso. La fecha del aviso no es necesariamente la fecha del ataque. Una copia de ayer puede conservar perfectamente el problema que has descubierto hoy.
Antes de elegir, necesitas responder dos preguntas: ¿podemos confiar en esa copia y qué información legítima perderíamos al volver a ella?
| Situación | Qué conviene valorar |
|---|---|
| Copia fiable anterior al incidente, con pocos cambios posteriores | Recuperar esa versión en un entorno aislado, corregir la causa y comprobarla antes de reabrir. |
| Copia antigua y pedidos, reservas o trabajo reciente | Diseñar la recuperación de esos datos antes de restaurar. Una vuelta completa al pasado también los elimina. |
| Copias que podrían estar comprometidas | Revisarlas; su fecha o el mensaje «backup correcto» no prueban que estén limpias. |
| Sin copia utilizable o con mucho desarrollo propio | Evaluar una limpieza con revisión de archivos, base de datos, accesos y configuración. Puede requerir ayuda especializada. |
Para esta guía lo probamos en un WordPress aislado. Hicimos una copia, añadimos después un contenido legítimo y restauramos aquella versión en una carpeta separada. El contenido nuevo desapareció. Es un resultado esperable, pero fácil de olvidar cuando lo urgente es quitar una advertencia roja.
En una tienda, ese contenido podría equivaler a pedidos o cambios de clientes posteriores a la copia. Recuperar datos recientes exige seleccionarlos y revisarlos, no volver a importar toda la base de datos comprometida y cruzar los dedos.
No tener una copia limpia tampoco obliga automáticamente a empezar de cero. El núcleo y muchos componentes se pueden obtener de sus fuentes originales. El contenido, la configuración y las partes propias necesitan una revisión distinta. Ahí se decide si merece la pena limpiar, reconstruir una parte o preparar una instalación nueva a la que llevar solo material verificado.
Cómo limpiar un WordPress hackeado
La limpieza consiste en localizar y retirar los cambios no autorizados sin destruir lo que sí pertenece a la web. Un escáner ayuda a encontrar indicios; la interpretación de lo que marca sigue importando. Un archivo personalizado puede ser legítimo aunque no coincida con ninguna versión pública.
El núcleo de WordPress se contrasta con sus archivos oficiales. Los plugins y temas se revisan contra versiones fiables de sus proveedores. En los componentes que se puedan sustituir, hay que retirar también los archivos ajenos que hayan quedado dentro de sus directorios. Copiar archivos limpios encima de los anteriores puede dejar intactos otros añadidos.
La revisión no termina ahí. Los cambios pueden estar en la base de datos, en la configuración, en archivos de subidas, en componentes que se cargan automáticamente o en tareas programadas. También hay que comprobar usuarios, permisos y accesos. La guía oficial para un sitio WordPress hackeado explica por qué una recuperación debe mirar más allá de lo que aparece en pantalla.
Si el alojamiento contiene otras webs o instalaciones antiguas con acceso compartido, hay que incluirlas en el diagnóstico. Limpiar la web principal mientras una copia olvidada conserva el mismo problema puede dejar abierta la vía de regreso.
No recomendamos borrar todo lo que contenga una función determinada ni ejecutar consultas de eliminación copiadas de un tutorial. La misma función puede aparecer en código legítimo. Con la base de datos, un error de criterio puede llevarse páginas, ajustes o pedidos bastante más rápido que el propio ataque.
Cuando hay desarrollo propio, conviene recuperar su versión conocida desde el repositorio o desde una copia fiable y comparar los cambios. Si no puedes distinguir qué es parte del proyecto y qué se ha añadido, ese es un buen punto para parar y pedir ayuda, conservando lo que ya has recopilado.
Cómo comprobar que WordPress vuelve a estar limpio
La comprobación debe reunir varias señales. Integridad de archivos, análisis del sitio, revisión de usuarios y configuración, ausencia de los comportamientos detectados y funcionamiento del negocio. Ninguna de ellas, aislada, explica el conjunto.
Hicimos una segunda prueba para mostrar ese límite. En el laboratorio añadimos un usuario de prueba y un archivo de texto inocuo dentro de la carpeta de subidas. También cambiamos un archivo del núcleo mediante un comentario inofensivo. La comprobación de integridad detectó ese cambio. Al devolver el archivo a su estado original, pasó correctamente, aunque el usuario y el archivo de subidas seguían presentes.
No fue una infección real ni una prueba de eliminación de malware. Demuestra el alcance de una comprobación: WP-CLI verifica los archivos del núcleo, no certifica todos los usuarios, datos y componentes del sitio.
Un escaneo externo observa lo que la web sirve a quien la visita. Una revisión del alojamiento puede inspeccionar archivos que no se muestran públicamente. Se complementan; ninguno debe convertirse en una excusa para ignorar accesos extraños o cambios que reaparecen.
Antes de reabrir, comprueba además las tareas que hacen útil la web: enviar un formulario, acceder con los roles correctos, recibir los correos esperados y, si corresponde, realizar una compra de prueba mediante un método adecuado. Una recuperación puede eliminar el código malicioso y dejar roto el proceso de reserva. El cliente seguirá teniendo un problema, solo que de otro tipo.
Renueva los accesos que hayan podido quedar expuestos durante el incidente y revoca sesiones o credenciales ajenas. Si una contraseña nueva se introdujo mientras la instalación seguía comprometida, puede ser necesario volver a cambiarla tras la limpieza. Conserva el registro de lo que se modificó y prepara una nueva copia de la versión comprobada.
Cómo quitar el aviso de Google tras un hackeo
Si Search Console muestra un problema de seguridad, revisa qué describe y las URLs que ofrece. Corrige el conjunto del problema, no solo las páginas de muestra. Cuando hayas comprobado la reparación, solicita la revisión desde ese informe y explica lo encontrado, lo corregido y cómo lo has verificado. Google indica que el proceso puede tardar de varios días a varias semanas; no depende de que recargues la pantalla con más convicción. Documentación de Google.
Si se han creado URLs de spam, retira el contenido y la causa que lo genera. Las URLs que no deban existir deben responder con un estado adecuado, normalmente 404 o 410. No redirijas todas esas páginas a la portada: un catálogo de spam no se convierte en contenido útil por aterrizar allí.
Revisa también que el sitemap contenga las URLs legítimas y que las páginas recuperadas puedan rastrearse. Quitar una URL temporalmente de los resultados no limpia el servidor. Del mismo modo, la desaparición del aviso no garantiza que el tráfico vuelva inmediatamente a su nivel anterior. La recuperación técnica y la evolución en Google llevan ritmos distintos.
Cómo evitar que vuelvan a hackear tu WordPress
Cuando nos encontramos con una web que vuelve a infectarse, una de las primeras preguntas es qué acceso o componente se corrigió después de limpiarla. Si la respuesta es «restauramos una copia y ya», falta una parte decisiva del trabajo.
Hay que investigar el punto de entrada: un componente vulnerable, credenciales expuestas, permisos inadecuados u otro acceso al alojamiento. A veces no se puede reconstruir con certeza porque faltan registros. En ese caso conviene dejarlo dicho y revisar las vías plausibles, en lugar de presentar una causa inventada como diagnóstico.
Mantén WordPress, plugins y temas actualizados, retira componentes que ya no utilices y sustituye los que no tengan mantenimiento fiable. Un plugin desactivado puede seguir dejando archivos accesibles; acumularlos «por si acaso» no es un plan de conservación especialmente brillante.
Protege con doble factor los accesos que lo permitan, asigna a cada persona solo los permisos que necesita y retira cuentas al terminar una colaboración. Revisa también la seguridad del correo y del alojamiento: desde ellos puede recuperarse el control de la web.
Un cortafuegos puede filtrar parte del tráfico malicioso y reducir exposición. Su utilidad depende de lo que cubra y de su configuración. No elimina por sí solo una infección existente ni sustituye las actualizaciones, la revisión de accesos y las copias guardadas fuera de la instalación.
Durante los días siguientes, observa cambios de archivos, nuevas cuentas y avisos del alojamiento. Comprueba que las copias se ejecutan y que se pueden restaurar. Tener un archivo llamado «backup» tranquiliza bastante más de lo que demuestra.
Cuándo pedir ayuda para recuperar una web hackeada
Pide ayuda si no controlas el alojamiento, no puedes determinar qué se ha modificado, la infección reaparece o hay varias instalaciones afectadas. Si existen indicios de acceso a información de clientes o de alteración del proceso de pago, amplía la revisión con las personas responsables de esos datos y sistemas.
Al contratar una recuperación, pregunta qué incluye: diagnóstico, conservación de una copia, limpieza o restauración, corrección de la vía de entrada, revisión de accesos, pruebas funcionales y seguimiento. Pregunta también qué queda fuera y qué se hará si no se puede confirmar la causa. «Pasamos un escáner» describe una herramienta, no todo ese trabajo.
Si necesitas que revisemos el caso, en el mantenimiento web de Nereida podemos valorar el estado de la instalación y el alcance de la recuperación. Empieza por enviarnos las URLs afectadas, el aviso recibido y cuándo lo detectaste, sin contraseñas. Con eso podemos decidir el siguiente paso sin convertir la web en un campo de pruebas.
Escrito en Nereida Studio, estudio de diseño web y posicionamiento en Valencia. Así trabajamos.
