WordPress hackeado: qué hacer paso a paso

Una advertencia roja en Chrome, una redirección a un dominio ajeno y un panel de administración en el que todo parece de siempre. El protocolo de urgencia para una web WordPress: qué no se puede tocar en la primera hora, dónde se esconde de verdad la infección y cómo librarse de la advertencia de Google.

Un jueves por la mañana le llama un cliente y le dice que, en lugar de su tienda, Chrome le muestra una advertencia roja a pantalla completa; usted abre el sitio en el móvil y, al segundo y medio, el navegador le manda a un dominio que no ha visto nunca, mientras que en el ordenador de trabajo, con el panel de administración abierto desde el lunes, todo tiene el mismo aspecto de siempre. Así se ve casi siempre un WordPress hackeado: no como una portada destrozada con la firma del atacante, sino como un sitio que le enseña una cara al propietario y otra al visitante, y por eso las primeras horas suelen irse discutiendo si el problema existe.

Las preguntas que se responden aquí suelen formularse justo en este orden: qué se puede y qué no se puede tocar durante la primera hora, mientras todavía no se sabe hasta dónde ha llegado el atacante; en qué puntos concretos de una instalación de WordPress se esconde el código, porque sin eso limpiar es adivinar; y cómo conseguir que Google retire la advertencia sin echar a perder el segundo intento. En medio queda lo que más se salta el propietario: cambiar las credenciales de acceso en el momento y en el orden correctos.

Todo lo que hay que hacer en las próximas horas está aquí y no hará falta buscarlo en ningún otro sitio. Fuera del artículo queda únicamente lo que sirve después, cuando el sitio ya vuelve a funcionar: la estrategia de copias de seguridad, el bastionado del sistema y la protección frente a la siguiente vez, que es igual sea cual sea la plataforma; para eso remitimos más abajo a una guía aparte. Aquí hablamos de lo que hace distinto a WordPress: el ecosistema de plugins, la carpeta wp-content, las tablas de la base de datos en las que la infección sobrevive a la limpieza de archivos y los comandos que prometen más de lo que realmente comprueban. En nuestra experiencia, esas cuatro cosas deciden si el sitio queda limpio en un día o al tercer intento.

La primera hora: no borre nada

La primera reacción es casi siempre una de dos: abrir el gestor de archivos del alojamiento, encontrar allí algo ajeno y borrarlo, o pulsar el botón que restaura la copia de seguridad de ayer. Le pedimos que no haga ninguna de las dos cosas, y por un motivo práctico, no burocrático. Las prisas se entienden, porque cada hora con la advertencia roja cuesta visitantes, pero es precisamente con prisas cuando se toman las dos decisiones que alargan una recuperación de ocho horas hasta una semana, y las dos son irreversibles.

Cuando se borran los archivos infectados, desaparece el único material con el que después se determina el punto de entrada: las fechas de modificación, el contenido de los scripts que subió el atacante y las entradas del registro de accesos del servidor que coinciden con esas fechas. Sin punto de entrada, la limpieza es solo una retirada de síntomas, y ese precio está cuantificado: en un estudio de Google y la Universidad de California en Berkeley sobre 760 935 casos de intrusión ocurridos entre julio de 2014 y junio de 2015, el 12 % de los sitios volvió a ser hackeado en 30 días porque se habían corregido los síntomas y no la causa (Li et al., WWW 2016).

Por eso el primer trabajo es una copia completa: todos los archivos y toda la base de datos de una vez, antes de tocar un solo byte, porque la redirección visible o la portada destrozada rara vez son todo lo que pasa en el sitio. Según los datos de Sucuri, en 2023 se encontró al menos una puerta trasera (backdoor) en el 49,21 % de los sitios infectados, y a lo largo de ese año su equipo retiró 21 062 de esos programas (Sucuri, «2023 Hacked Website & Malware Threat Report», junio de 2024). Guarde la copia fuera de ese mismo servidor, porque es justo ahí donde el atacante sigue teniendo acceso.

La siguiente llamada es para el proveedor de alojamiento, y no por cortesía: ellos tienen los registros de acceso, que en su cuenta suelen verse solo unos días hacia atrás, y en un servidor compartido tienen la obligación de comprobar si en las cuentas vecinas ocurre lo mismo. Si en el sitio se aceptan pagos o se introducen datos personales, en este momento hay que apagarlo o activar el modo de mantenimiento: cada visitante que introduzca los datos de su tarjeta en la próxima hora es un problema aparte que todavía no tiene. El modo de mantenimiento cuesta un día de facturación; el momento perdido cuesta una carta a sus clientes.

Si wp-admin ya no se abre —en un sitio hackeado suele pasar—, no conseguirá activar el modo de mantenimiento desde el panel y quedan dos caminos: añadir en el archivo .htaccess de la raíz del sitio una regla que envíe a todo el mundo, salvo a su dirección IP, a una única página estática con un aviso de trabajos técnicos, o pedir en esa misma llamada al alojamiento que suspenda la cuenta temporalmente. La segunda opción parece brusca, pero funciona también cuando ya no llega a los archivos.

La copia de seguridad de ayer parece el camino más rápido de vuelta y a veces es de verdad el paso correcto, pero solo si se sabe qué día entró el atacante. En nuestra experiencia, la infección se detecta bastante más tarde de lo que empezó —primero el código se queda callado y solo después empieza a mostrar páginas de spam o redirecciones—, de modo que en la copia de ayer la puerta trasera ya está dentro con toda probabilidad. Restaurarla esconde los síntomas durante un par de horas y devuelve la web exactamente al estado en el que la hackearon, así que la recuperación de una web hackeada la empezamos normalmente en unas pocas horas y, incluso con prisas, lo primero es la copia y no el borrado, aun cuando el cliente llama y pide que se limpie todo rápido y ya está.

Señales para reconocer un WordPress hackeado

La redirección que se activa con el visitante llegado desde un resultado de Google, pero no cuando la dirección se escribe a mano en el navegador, no es un malentendido: es una decisión deliberada del atacante. En las políticas de spam de Google, las redirecciones figuran por separado como un tipo de contenido hackeado: los hackers «pueden inyectar código malicioso en tu sitio web para redirigir a algunos de tus usuarios a páginas dañinas o con contenido engañoso» (Google Search Central, consultado en agosto de 2026). La palabra que despista al propietario es «algunos». Comprobarlo cuesta un minuto: abra el sitio en una ventana de incógnito, búsquelo después en Google y ábralo desde ahí, y repita ambas cosas en el móvil.

El segundo grupo de señales está en el lado de la administración y es mucho más concreto: wp-admin devuelve de pronto un 404, el formulario de acceso se limita a recargarse tras la contraseña correcta, en la lista de usuarios hay una cuenta de administrador que nadie de su equipo ha creado, o en Ajustes → Generales la dirección del sitio ya no es la suya. En la base de datos, esta última señal son solo dos filas de la tabla wp_options —siteurl y home—, y por eso la dirección que usted ve en los ajustes y la que recibe el visitante pueden no coincidir.

El tercer grupo viene de fuera y es el más doloroso, porque quien le informa del estado de su sitio es otro: la empresa de alojamiento suspende sin avisar la cuenta desde la que ha salido spam, en Search Console aparece un registro de problema de seguridad, o junto al sitio en los resultados de búsqueda aparece el aviso «Este sitio puede haber sido pirateado», que Google muestra cuando cree que un atacante ha cambiado páginas existentes o ha añadido páginas de spam nuevas (Ayuda de Búsqueda de Google, consultada en agosto de 2026). Ese aviso lo pone Google por su cuenta, no a raíz de la denuncia de nadie, y aparece también cuando a usted el sitio le parece impecable.

Los nombres no son aquí una cuestión académica, porque con ellos buscará la solución y valorará si quien se ofrece a arreglarlo entiende su caso: Google nombra tres en su documentación —el gibberish hack, el Japanese keyword hack y el cloaked keywords and links hack, en el que las páginas creadas por el atacante muestran un contenido al buscador y otro al visitante—. El «pharma hack», popular en el sector, procede de la empresa de seguridad Sucuri (2020) y no figura en la documentación de Google. La comprobación práctica es la misma para los tres: escriba en el buscador una consulta site: con su dominio y verá enseguida las páginas que nadie de su empresa ha escrito. En la variante japonesa son páginas generadas automáticamente, con títulos en japonés, alojadas en carpetas de nombre aleatorio y con su dominio en la dirección.

Y ahora la parte desagradable: un resultado de escaneo limpio no demuestra que el sitio esté limpio, porque el escáner solo ve lo que el servidor le enseña, y el código del atacante reconoce a menudo tanto a los escáneres como a los buscadores; Google, en su guía sobre las páginas de palabras clave encubiertas, advierte de que la intrusión suele ocultarse justo para que al propietario le parezca que el problema ya ha pasado. Si el escaneo sale limpio pero el alojamiento se queja del correo saliente, créale al alojamiento. Ahí es donde procede una auditoría de seguridad web con revisión manual de archivos y registros, porque el escáner responde a la pregunta de si en el sitio hay algo de la lista de muestras conocidas, no a la de si dentro del sitio sigue habiendo alguien.

Dónde está en realidad el riesgo de WordPress

En nuestra experiencia, cuando por fin aparece la causa, casi nunca es el núcleo de WordPress. El informe de Patchstack «State of WordPress Security in 2026» contabiliza 11 334 vulnerabilidades nuevas descubiertas en el ecosistema de WordPress durante 2025, un 42 % más que el año anterior, y lo que ahora mismo le interesa a usted es cómo se reparte esa cifra: el 91 % correspondía a plugins y el 9 % a temas, mientras que en el propio núcleo de WordPress se notificaron seis en todo el año, y además todas de prioridad baja. Prácticamente ninguna vulnerabilidad nueva está, por tanto, en el WordPress que usted instaló en su día, sino en lo que se le ha ido añadiendo con los años.

Cada plugin es una base de código independiente, escrita por un autor independiente y con una disciplina de actualizaciones independiente y, bastante a menudo, ya interrumpida, de modo que una web con cuarenta plugins no es una web con un problema de seguridad, sino una web con cuarenta problemas de seguridad independientes entre sí. En nuestra experiencia, la web de una empresa normal se apaña de sobra con diez o quince plugins, y el resto suele ser el poso de encargos olvidados hace tiempo: una galería que ya no se muestra, un formulario sustituido por otro, un slider que el diseño actual ya no utiliza. Cuando asumimos el desarrollo y el mantenimiento de una web WordPress, reducir el número de plugins es el primer trabajo, no el último.

Y aquí está el error que se repite más que ningún otro: el plugin que sobra se desactiva en lugar de borrarse. Desactivar le dice a WordPress que deje de cargarlo, pero los archivos siguen en el servidor, una parte de ellos sigue siendo accesible directamente por HTTP y al script del atacante le basta con conocer la ruta. Wordfence documentó en junio de 2021 una vulnerabilidad de día cero explotada de forma activa en el plugin Fancy Product Designer que, según su aviso, «en algunas configuraciones es explotable incluso si el plugin está desactivado», y recomendó no desactivarlo, sino desinstalarlo por completo. Si un plugin ya no le hace falta, su lugar no es la lista de plugins en gris, sino fuera del servidor.

Por qué ocurre todo esto de forma automática y sin motivo personal lo explica la escala: según los datos de W3Techs del 5 de agosto de 2026, WordPress mueve el 41,2 % de todos los sitios web. En un ecosistema de ese tamaño, cada vulnerabilidad de plugin que se hace pública es explotable de inmediato contra un número enorme de sitios construidos igual, así que a los atacantes les sale más rentable automatizar que elegir objetivos: el script mira números de versión, no nombres de empresa. Nadie ha elegido su sitio en particular, y justo por eso un sitio web corporativo pequeño, sin datos de clientes y sin pagos, se hackea con la misma tranquilidad que una tienda online grande.

Dónde esconde el atacante el código en una instalación de WordPress

El primer lugar que abrimos es wp-content/uploads, una carpeta en la que por definición solo hay imágenes, archivos PDF y vídeos y en la que nunca debería ejecutarse ningún archivo PHP. Si entre las fotos de producto de 2019 hay un archivo con extensión .php, no ha llegado ahí por casualidad: casi siempre es o bien un script de subida con el que el atacante mete en el servidor los archivos siguientes, o bien una shell que permite ejecutar comandos en nombre de su servidor. Que el problema es real y no teórico se ve en que tanto Sucuri como Wordfence ofrecen un ajuste de bastionado específico que desactiva el motor de PHP en esa carpeta mediante una regla en .htaccess.

El segundo lugar es wp-content/mu-plugins. Los plugins que se colocan ahí se activan automáticamente, no se pueden desactivar desde el panel de administración y —lo más importante en este caso— no aparecen en la lista normal de plugins, de manera que el propietario puede pasarse meses mirando un panel aparentemente limpio; Sucuri describió en julio de 2025 un caso exactamente así: una puerta trasera alojada en esa carpeta. Junto a eso revisamos siempre el .htaccess, tanto en la raíz como en las subcarpetas, porque la redirección que solo se activa con visitantes llegados del buscador o solo en dispositivos móviles suele estar escrita ahí, y esa es la razón de que usted vea su sitio perfectamente normal.

El código también suele escribirse en las primeras líneas de archivos existentes y perfectamente legítimos, casi siempre al principio de wp-config.php y en el functions.php del tema, y casi nunca tiene aspecto de código malicioso: es una única línea larga con una llamada a base64_decode, gzinflate o eval, seguida de cientos de líneas vacías para que en el editor parezca que el archivo ha terminado. Por eso comparar los archivos con un original limpio vale más que leerlos a ojo: esa línea no la encuentra nadie a ojo, porque nadie se desplaza por un archivo hasta la línea novecientos.

Y después está la base de datos, donde el escáner de archivos no mira y hay tres puntos que revisar: las filas siteurl y home de wp_options, que el atacante reescribe para que los recursos de sus páginas se carguen desde un servidor ajeno; la tabla wp_users, donde suele aparecer una cuenta de administrador con un nombre verosímil; y el contenido de las entradas en wp_posts, donde los enlaces ocultos y los iframes se incrustan en mitad de artículos antiguos que ya no abre nadie. Si se limpian los archivos pero la inyección permanece en la base de datos, la infección vuelve ese mismo día. La fila en sí no se ejecuta: en cada carga la lee y la lanza un pequeño cargador alojado en el functions.php del tema o en mu-plugins, y esa pareja vuelve a poner los archivos borrados más deprisa de lo que usted tarda en comprobar el resultado. Por eso, en la recuperación de una web hackeada, limpiar los archivos y la base de datos es para nosotros un solo trabajo y no dos.

Comparar los archivos con originales verificados

La primera herramienta que cogemos, una vez asegurada la copia completa de archivos y base de datos, es wp core verify-checksums: compara el hash de cada archivo con las sumas de comprobación publicadas por WordPress.org y muestra al instante cuáles se han modificado y cuáles no estaban previstos en la instalación. El problema empieza donde termina su alcance: el comando revisa únicamente wp-admin/, wp-includes/ y los archivos wp-* de la raíz, mientras que su propio código fuente omite deliberadamente toda la carpeta wp-content, es decir, plugins, temas y subidas (código fuente de checksum-command de WP-CLI, consultado el 5 de agosto de 2026). Ese mismo código excluye además un archivo de la raíz por separado, wp-config.php, así que el archivo en cuyas primeras líneas se escribe el código con más frecuencia es invisible para esta comprobación. Un resultado limpio del comando no significa un sitio limpio.

Para los plugins existe un comando aparte, wp plugin verify-checksums, pero también compara los archivos solo con las sumas del repositorio de WordPress.org, así que un plugin comercial comprado al desarrollador se queda sencillamente fuera de la revisión; para los temas no hay ningún comando equivalente en la documentación de WP-CLI (documentación de WP-CLI, consultada el 5 de agosto de 2026). A la comprobación automática no se someten, por tanto, ni los temas ni los plugins comprados fuera del repositorio, y wp core verify-checksums deja fuera todo wp-content, que es la parte del código donde surgieron las 11 334 vulnerabilidades que Patchstack contó en 2025, salvo las seis del núcleo. En los sitios que asumimos, el tema suele ser precisamente lo único que no ha revisado nunca nadie.

En nuestra experiencia, las sumas de comprobación son por eso un punto de partida y no un método: el núcleo y los plugins no los curamos, los sustituimos; descargamos esas mismas versiones desde la fuente original y sobrescribimos las carpetas enteras, no archivo por archivo. De la instalación antigua conservamos wp-content/uploads, y solo después de comprobar que entre las imágenes no hay archivos PHP, por el mismo motivo por el que merece la pena desactivar ahí el motor de PHP. El tema lo restauramos desde el control de versiones, si lo hay; si no, cogemos la copia que entrega el desarrollador y volvemos a aplicar las personalizaciones una a una, porque solo así se puede decir después qué línea del sitio es nuestra y cuál no.

Encontrar y borrar la línea mala suena más barato, y justo por eso es el error que más se repite: el atacante rara vez deja una sola entrada, y una única puerta trasera que pase inadvertida convierte en inútil todo el resto del trabajo. El código suele estar repartido en varios archivos, escondido tras una llamada a base64 o a gzinflate, escrito en la tabla de opciones de la base de datos o metido en esa misma carpeta mu-plugins que el panel de administración no muestra. Buscar por patrones encuentra lo que usted ya conoce; sustituirlo todo le libra además de lo que no conoce.

Hay también trabajo que en esta fase no hacemos: no nos fiamos del plugin que ofrece «curar» los archivos infectados con un botón, porque trabaja con esa misma lista de muestras conocidas y dentro del mismo entorno al que el atacante sigue teniendo acceso. Tampoco comparamos archivos a mano cuando el sitio no pasa del tamaño de una web corporativa sencilla o de un blog: una instalación nueva con el contenido traspasado cuesta menos horas que comparar dos directorios línea a línea, y el resultado sí se puede verificar. La comparación manual minuciosa procede allí donde el tema o el plugin es único y no hay control de versiones; cómo tratar las copias de seguridad para que esa elección exista siquiera lo hemos descrito en la guía general de recuperación.

Claves, sesiones y contraseñas: qué hace realmente cada cosa

Las claves y sales de autenticación (security keys and salts) del archivo wp-config.php no cifran nada, por mucho que lo afirme casi cualquier guía: WordPress las usa como base de la clave con la que la función wp_generate_auth_cookie() firma la cookie de autenticación con HMAC-SHA256, pero la cookie en sí es texto plano con el nombre de usuario, la fecha de caducidad y el token de sesión (WordPress Developer Resources, consultado el 5 de agosto de 2026). Por eso, al cambiar esos valores, cualquier firma emitida antes deja de verificarse y el servidor rechaza todas las cookies entregadas hasta ese momento, aunque la sesión no haya expirado formalmente.

La consecuencia práctica es justo la que hace falta en una intrusión: la documentación oficial de WordPress describe el cambio de claves como la forma de echar fuera a cualquiera que siga con la sesión iniciada (WordPress.org, «FAQ My site was hacked», actualizado el 26 de julio de 2026), de modo que, si el atacante tiene una sesión válida, se le termina en ese mismo instante. Con las sesiones dejan de valer también todos los nonce emitidos, así que los formularios a medio rellenar y los pedidos a medio confirmar se interrumpen: el instante del cambio lo elegimos a conciencia, no al azar en mitad de la jornada.

Cambiar las claves y las sales no cambia ninguna contraseña. WordPress genera los hash de las contraseñas con bcrypt y con una sal aleatoria distinta para cada contraseña, sin relación alguna con las constantes de wp-config.php (función wp_hash_password(); bcrypt por defecto desde WordPress 6.8), así que el atacante que conoce la contraseña del administrador o ha tenido tiempo de crearse una cuenta propia vuelve a entrar sin más después del cambio de claves. Las contraseñas se cambian aparte y todas, también las que en teoría no conoce nadie, y a la vez hay que recorrer la lista de usuarios buscando cuentas que nadie de su equipo haya creado.

La lista de credenciales no termina en WordPress: en la misma tanda se cambian la contraseña del panel de control del alojamiento, los datos de acceso de FTP y SFTP, la contraseña del usuario de la base de datos junto con su línea en wp-config.php y las claves SSH, que no se cambian como una contraseña, sino que se generan de nuevo borrando la clave pública antigua del authorized_keys del servidor. Por último se renuevan todas las claves de API guardadas en el sitio —pasarela de pago, envío de correo, integraciones de logística y contabilidad—, porque son las que más tiempo suelen quedarse intactas: en el día a día no las ve nadie en ninguna pantalla.

Dé por hecho que el atacante tiene una copia completa de la base de datos, porque es el paso más barato de todo el ataque: todo lo que haya estado ahí —las direcciones de correo de sus clientes, el histórico de pedidos, los hash de las contraseñas y las claves guardadas en los ajustes de los plugins— hay que considerarlo en manos ajenas. Si alguna de esas contraseñas se usa en algún lugar más, ese lugar también está comprometido, y ahí es donde la conversación pasa de la web a las cuentas de correo, al programa de contabilidad y a la cuenta de pagos de la tienda.

El orden importa tanto como la lista: las claves y las contraseñas se cambian después de haber retirado las puertas traseras, porque en caso contrario el atacante lee los valores nuevos ahí mismo, en wp-config.php, o sencillamente intercepta el siguiente inicio de sesión. Justo esa secuencia —primero la copia completa, después la causa, después la limpieza y solo al final las credenciales— es donde más veces se detiene o se enreda una recuperación empezada por cuenta propia, así que esta fase la asumimos nosotros y al terminar entregamos un informe escrito de qué se cambió, cuándo y por qué.

Cómo conseguir que desaparezca la advertencia de Google y qué hacer después

La sección «Problemas de seguridad» de Google Search Console es el único lugar donde se ve qué ha encontrado Google exactamente en su sitio: ahí figuran el tipo de amenaza y una muestra de las páginas afectadas, y de eso depende también lo que ve ahora mismo el visitante. El tipo de amenaza no cambia lo que ve el visitante: Chrome ya no varía el encabezado según se haya detectado phishing, malware o software no deseado, sino que en todos los casos muestra la misma advertencia a pantalla completa —en español, «Sitio peligroso»—, que sencillamente no deja entrar a la persona, mientras que el aviso «Este sitio puede haber sido pirateado» ya mencionado es solo un texto junto al enlace en los resultados de búsqueda, y por él se puede pasar con un clic (página de ayuda de Google Chrome sobre sitios peligrosos, consultada en agosto de 2026). Chrome ya no usa los encabezados antiguos, distintos según el tipo de amenaza —«Deceptive site ahead», por ejemplo—, aunque estos siguen figurando en parte de la documentación de Google. El primero bloquea, el segundo advierte, y eso cambia cuánto tiempo tiene usted en realidad.

Antes de pulsar «Solicitar revisión» hay que asegurarse de que el sitio está limpio de verdad y no solo lo parece en su navegador. Google advierte expresamente, en su guía sobre el hackeo de palabras clave encubiertas, de que los atacantes intentan dar la impresión de que la página ya se ha borrado o ya se ha arreglado, así que cada antigua página de spam hay que comprobarla con la herramienta de inspección de URLs, que enseña la vista de Googlebot y no la suya. El segundo paso, el que más se salta, es la lista de propietarios: en el Japanese keyword hack el atacante se añade como propietario verificado en Search Console (documentación de Google en web.dev) y, mientras no se le retire de esa lista, sabe exactamente lo mismo que usted sobre el estado del sitio.

El botón que hay que buscar es «Solicitar revisión», dentro del informe de problemas de seguridad, no la «solicitud de reconsideración», que Google reserva para las acciones manuales; en el texto conviene escribir tres cosas: qué se encontró, por dónde entró el atacante y qué se ha hecho para cerrarlo. Nosotros no prometemos plazo, porque tampoco lo promete Google: su documentación sobre ingeniería social dice que «las revisiones pueden tardar varios días en completarse», mientras que la ayuda de Search Console sobre problemas de seguridad escribe que «pueden tardar en completarse entre unos pocos días y unas pocas semanas» (ambas consultadas en agosto de 2026). Si alguien le da una cifra exacta de 24 o 72 horas, está repitiendo un número que no aparece en ninguna fuente de Google.

Las prisas en este paso salen más caras que la espera. En ese mismo estudio de Google y la Universidad de California en Berkeley, el 80 % de los propietarios consiguió que su sitio se diera por limpio al primer intento, pero al 20 % restante le hicieron falta varios intentos, y el tiempo mediano que pasaron peinando el código dejado por el atacante fue de una semana entera. Los datos son de 2014-2015 y así hay que leerlos, pero la aritmética no ha cambiado: una solicitud rechazada significa que la advertencia se queda otro ciclo más, y la segunda vez usted ya no es un solicitante primerizo.

Cuando la advertencia desaparece el trabajo aún no ha terminado, porque en el índice se quedan las páginas del atacante, y esas no se pueden redirigir a la portada: tienen que devolver un 404 o un 410 para que Google las retire del todo, mientras que la herramienta de retirada de Search Console solo las esconde temporalmente. Las posiciones en buscadores tampoco vuelven girando un interruptor: las páginas hay que reindexarlas, y eso ocurre al ritmo de Google y no al suyo. Cómo aprovechar en esta fase los archivos de registro y las copias de seguridad para que la próxima vez el punto de partida sea mejor lo hemos descrito en una guía aparte sobre la recuperación de webs hackeadas.

Cuándo dejar de hacerlo usted mismo y cuánto cuesta

Una parte de lo que aquí se describe la hace por su cuenta un propietario con experiencia, y se lo decimos sin rodeos incluso a quien nos llama con Search Console abierto y el plugin culpable ya localizado. Si la infección es una portada estropeada, si en los archivos de registro se ve qué plugin la dejó entrar, si en la lista de usuarios no hay administradores desconocidos y si existe una copia de seguridad de ayer que alguna vez haya restaurado usted de verdad en un entorno de pruebas, entonces ocho horas pagadas le comprarán tranquilidad, no un resultado más rápido.

Hay cuatro situaciones en las que recomendamos parar, y la primera es la reinfección después de una limpieza: si la web se hackea por segunda vez, no es cuestión de mala suerte, sino la prueba de que el punto de entrada sigue abierto, y una tercera limpieza en ese mismo entorno costará exactamente lo mismo que las dos primeras. La segunda es cualquier sombra de sospecha sobre datos de clientes o de pagos, porque ahí, junto al trabajo técnico, aparecen obligaciones frente a la autoridad de control y plazos que la buena voluntad no alarga. La tercera es una web con la que la empresa gana dinero todos los días, y la cuarta, la simple falta de tiempo: limpiar no es intelectualmente difícil, pero es largo, monótono y no perdona ni un archivo que se quede sin mirar.

Nuestra recuperación de webs hackeadas cuesta 90 € por hora sin IVA, con un mínimo de ocho horas de trabajo que se abonan por adelantado. Normalmente empezamos a trabajar en unas pocas horas desde el aviso, y el proceso completo, desde el inicio hasta la entrega, suele llevar entre 8 y 72 horas; la diferencia está casi siempre en lo profundo que llegó a instalarse el atacante y en la antigüedad de la última copia limpia. El mínimo no es una cifra de marketing: la copia completa, la búsqueda de la causa en los archivos de registro, la limpieza y la comprobación rara vez caben en menos tiempo.

El procedimiento es el mismo que se describe más arriba, solo que sin su fin de semana de por medio. Antes de tocar nada hacemos una copia completa de los archivos y de la base de datos, para que el incidente pueda investigarse después, y solo entonces se aísla el sitio; a continuación se limpia de malware y de puertas traseras, se revisa la base de datos, se cambian las credenciales y las claves, se localiza y se cierra la causa de la intrusión, se envía la solicitud de revisión a Google y se configura la monitorización, y al final usted recibe un informe escrito de lo ocurrido y de lo que se ha cambiado. Si el sitio no funciona ahora mismo o no está seguro de lo que ve, puede solicitar una revisión urgente del sitio y le diremos si aquí hay algo por lo que merezca la pena pagar.

En muchos casos, sin embargo, la respuesta de verdad no es la recuperación, sino lo que viene después: si la web ha ido acumulando veinte plugins y nadie recuerda ya el motivo de la mitad, entonces el problema está en el mantenimiento, y eso se resuelve con el desarrollo y el mantenimiento de WordPress, no con otro ciclo de limpieza dentro de medio año. La hora más barata de toda esta historia es la que se gasta antes: borrar de wp-content/plugins el plugin que no se usa en lugar de desactivarlo, y una copia de seguridad que alguien haya restaurado de verdad alguna vez en un entorno de pruebas, cuestan juntas menos que una sola jornada de trabajo nuestra.