Si has llegado aquí con la web caída o marcada en rojo por Google, ve directamente a la primera sección y sigue el orden. El resto lo lees luego.
Lo primero, en las primeras dos horas
1. No borres nada todavía. Es lo más contraintuitivo y lo más importante. Si empiezas a eliminar ficheros, destruyes las pruebas de cómo entraron y te quedas sin saber por dónde cerrar.
2. Haz una copia completa tal como está. Ficheros y base de datos, infectados y todo. Guárdala fuera del servidor. Es tu copia forense.
3. Pon el sitio en mantenimiento. Mejor una página de mantenimiento que un sitio distribuyendo malware a tus visitantes. Cada hora que sirve contenido malicioso empeora tu reputación en Google.
4. Cambia todas las credenciales. Panel de hosting, FTP y SFTP, base de datos, usuarios administradores de WordPress, y el correo asociado. Si reutilizabas contraseñas, cámbialas también donde las reutilizabas.
5. Revisa los usuarios administradores. Es habitual que el atacante se cree uno propio con nombre inocente. Cualquiera que no reconozcas, fuera.
Lo que no hay que hacer nunca
No restaures una copia antigua y te olvides. Si la vulnerabilidad sigue ahí, en una semana vuelves a estar igual. Y es bastante probable que la copia ya estuviera comprometida: los atacantes suelen esperar semanas antes de activar nada.
No te limites a borrar los ficheros raros. Las puertas traseras se esconden en sitios que parecen legítimos: dentro de un plugin real, en el functions.php del tema, en la tabla de opciones de la base de datos.
No ignores el aviso de Google. Si Search Console te ha marcado, hay que solicitar la revisión explícitamente después de limpiar. No se quita solo.
Cómo saber por dónde entraron
Esta es la parte que casi nadie hace y la que decide si el problema vuelve.
Los registros de acceso del servidor. Busca peticiones POST a ficheros que no deberían recibirlas, accesos a wp-login.php en ráfaga desde una misma IP, o peticiones a rutas de administración que no existen en tu sitio.
Las fechas de modificación de los ficheros. Ordena por fecha. Todo lo modificado en un rango que no corresponde a una actualización tuya es sospechoso.
Las versiones de plugins y tema. Compara lo que tienes instalado contra las vulnerabilidades conocidas de esa versión. La inmensa mayoría de las intrusiones en WordPress entran por un plugin desactualizado, no por una contraseña débil.
Los directorios de caché y subidas. Un patrón muy revelador: cientos de carpetas con nombres que no son páginas de tu web sino rutas de escaneo de vulnerabilidades. Si ves nombres como ALFA_DATA, alfacgiapi, administrator o fckeditor en sitios donde no pintan nada, eso son rastros de herramientas de ataque automatizadas.
Las obligaciones legales que casi nadie cumple
Si el atacante pudo acceder a datos personales —clientes registrados, pedidos, formularios de contacto, suscriptores—, estás ante una violación de seguridad de los datos.
El RGPD obliga a notificar a la Agencia Española de Protección de Datos en un plazo de 72 horas desde que tienes conocimiento del incidente. Y si el riesgo para los afectados es alto, también hay que comunicárselo a ellos.
Ojo al matiz: la obligación se activa cuando pudo acceder, no cuando está demostrado que accedió. Si no puedes descartarlo, se notifica.
Esta es otra razón para hacer la copia forense antes de limpiar: sin ella no puedes documentar el alcance, y sin alcance documentado la notificación es un ejercicio de adivinación.
La limpieza, por orden
- Sustituye el núcleo de WordPress por una descarga limpia de la versión correspondiente.
- Reinstala los plugins y el tema desde su origen oficial, en su versión actualizada. No los limpies: sustitúyelos.
- Revisa lo que no se puede sustituir:
wp-config.php,.htaccess, el directorio de subidas y tu tema hijo si lo tienes. - Busca en la base de datos: la tabla de opciones y las entradas suelen llevar scripts inyectados.
- Comprueba las tareas programadas. Un
cronque reinstala la puerta trasera cada noche es un clásico. - Cierra la vulnerabilidad. Si entraron por un plugin, actualízalo o quítalo. Si entraron por credenciales, activa doble factor.
- Solicita la revisión en Google Search Console y en tu antivirus de reputación.
Y después, la pregunta incómoda
Si has llegado hasta aquí, la pregunta es: ¿vas a volver a pasar por esto dentro de un año?
WordPress no es inseguro por naturaleza, pero su superficie de ataque es enorme: un panel de administración accesible desde internet, una base de datos, PHP ejecutándose y treinta plugins de treinta autores distintos, cada uno con su propio ritmo de actualización.
La alternativa que recomendamos, cuando el sitio no necesita de verdad un CMS dinámico, es un sitio estático: HTML generado en el momento de publicar, sin base de datos, sin panel expuesto y sin PHP ejecutándose. No es que sea más difícil de hackear; es que no hay nada que hackear.
Y editar el contenido sigue siendo igual de fácil, con un editor visual que publica contra el repositorio.
Un caso propio. Este mismo dominio arrastraba un WordPress heredado con 716 directorios que eran rastros de escaneo y firmas de webshell conocidas, además de una copia de seguridad de 495 MB con la base de datos completa accesible públicamente. Lo borramos entero y reconstruimos el sitio como estático. Por eso escribimos esto con cierta autoridad.
Si estás en mitad del problema ahora mismo, el servicio de rescate empieza el mismo día. Escríbenos con la dirección de tu web y lo que estás viendo.