WordPress redirige spam: guía de limpieza 2026

Si entraste a tu sitio desde el celu y terminaste en una página de casinos online o de “actualizá tu Flash Player” que no pediste, no estás solo: el redirect hack condicional en WordPress es una de las infecciones más comunes en 2026, y lo peor es que el atacante lo diseñó para que vos (logueado como admin) veas todo normal. En este artículo te explico paso a paso cómo detectarlo, dónde se esconde el código malicioso y cómo limpiarlo sin dejar la puerta abierta para que vuelvan.

Un redirect hack condicional en WordPress es un ataque que inserta código malicioso en archivos o base de datos del sitio para redirigir a los visitantes que llegan desde buscadores (especialmente Google) o desde dispositivos móviles a sitios de spam, phishing o malware, mientras que los usuarios administradores logueados ven el sitio sin alteraciones. El objetivo es pasar desapercibido y monetizar el tráfico orgánico robado.

¿Qué es un redirect hack condicional en WordPress?

El término ya lo adelanté, pero vale la pena desmenuzarlo. Un redirect hack condicional no es un redirect cualquiera que le pega a todo el mundo por igual. El bicho está programado para activarse solo cuando detecta ciertas condiciones: que el visitante venga de un buscador (Google, Bing, DuckDuckGo), que use un dispositivo móvil o que no tenga una cookie de sesión activa de WordPress. Si vos entrás como administrador desde tu navegador de escritorio, el sitio carga perfecto. Esa es la trampa.

Según el análisis que publicó seguridadenwordpress.com, los atacantes usan esta técnica para robar tráfico orgánico legítimo y redirigirlo a páginas que generan comisiones por publicidad o instalan malware. El administrador promedio puede tardar semanas en darse cuenta porque, bueno, cada vez que revisa el sitio lo ve bien. Y mientras tanto, Google ya empezó a marcar el dominio como comprometido en Search Console.

¿Cómo detectar si mi WordPress redirige a sitios de spam?

El método más confiable no es entrar a tu panel de administración. Es simular lo que haría un visitante real desde Google. Abrí una terminal y ejecutá este comando curl —te toma dos segundos y te da una respuesta inequívoca—:

• curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -e "https://www.google.com" -I https://tusitio.com

Si en la respuesta ves una línea que dice Location: https://sitiospam.com o cualquier dominio que no es el tuyo, tenés un redirect hack activo. El -I pide solo los headers, así que el comando es liviano. Probá también con user-agent de iPhone o Android para cubrir el vector móvil. Más contexto en nuestra comparativa entre Sucuri y Patchstack.

Otras señales que no mienten:

• Google Search Console muestra una alerta de seguridad. En la sección “Problemas de seguridad” aparece el aviso de contenido malicioso o redirección. Google tarda menos de 48 horas en detectar estos patrones cuando el tráfico es constante.
• Caída abrupta del tráfico orgánico. Si el redirect se activa para el 90% de las visitas que vienen de Google, el gráfico de Analytics se desploma. Los usuarios rebotan en segundos.
• Probás desde un celular en red móvil sin sesión. Navegá en modo incógnito, sin WiFi, desde un teléfono que nunca haya entrado al panel de WordPress. Si te manda a otro lado, listo.

No caigas en la tentación de testear solo con tu navegador de siempre, logueado. El redirect condicional está pensado justamente para que vos no lo veas.

¿Dónde se esconde el código malicioso del redirect?

Acá viene la parte que más dolores de cabeza da. Los atacantes no dejan un solo archivo infectado; suelen sembrar código en varios lados para que la limpieza superficial no funcione. Según el relevamiento de Nova Pulse de abril de 2026, citado por seguridadenwordpress.com, estas son las seis ubicaciones que tenés que revisar sí o sí:

• .htaccess en la raíz de WordPress. Es el archivo más común para reglas de redirección. Buscá líneas con RewriteCond %{HTTP_USER_AGENT} seguidas de RewriteRule a dominios externos. A veces el código está ofuscado con comentarios falsos.
• wp-config.php. Puede tener inclusiones ocultas al inicio o al final del archivo, tipo include(‘/tmp/malware.php’); o variables con cadenas codificadas en base64.
• functions.php del tema activo. Los atacantes agregan funciones que enganchan en wp_head o init para inyectar JavaScript que redirige en el navegador. Comparalo con el original del repositorio de WordPress.org.
• Tabla wp_options. Las opciones serializadas pueden contener payloads completos. Buscá registros con nombres sospechosos o valores que incluyan base64_decode, eval o gzinflate.
• Tabla wp_posts. Los atacantes inyectan scripts directamente en entradas o páginas, sobre todo en las que tienen alto tráfico. Una búsqueda con LIKE sobre post_content buscando <script> o document.location ayuda.
• Archivos de plugins activos modificados. Un plugin legítimo que fue alterado para incluir un archivo extra. La pista: archivos con fechas de modificación posteriores a la última actualización oficial del plugin.

La pregunta es: ¿chequeaste todo esto o solo miraste el .htaccess? Porque ese es el error más común.

¿Cómo limpiar el redirect hack paso a paso?

No existe un botón mágico que resuelva todo, pero si encarás la limpieza en tres frentes simultáneos, salís del problema en menos de una hora. El orden importa menos que la exhaustividad: hacé los tres, no elijas uno.

Frente 1 — Archivos. Restaurá el .htaccess al que genera WordPress por defecto (podés regenerarlo desde Ajustes > Enlaces permanentes). Reemplazá el wp-config.php con una copia limpia de una instalación fresca de la misma versión, y volcá manualmente las constantes de conexión a base de datos. Compará el functions.php del tema activo con el original del repositorio; si no tenés backup, descargá el tema de nuevo desde wordpress.org y sobrescribí. Reinstalá todos los plugins desde el repositorio oficial, uno por uno, eliminando antes las carpetas viejas.

Frente 2 — Base de datos. Con phpMyAdmin o wp-cli, ejecutá consultas de búsqueda sobre wp_options y wp_posts. Para wp_options, un SELECT * FROM wp_options WHERE option_value LIKE ‘%base64%’ OR option_value LIKE ‘%eval%’; suele encontrar los registros infectados. Borralos o reemplazalos con valores limpios. Para wp_posts, lo mismo: buscá scripts inyectados en post_content y editá las entradas afectadas. Si tenés backup diario de la base de datos, restaurar a un punto anterior al ataque es más rápido y seguro —siempre y cuando después cambies todas las credenciales. Esto se conecta con lo que analizamos en el análisis de Sucuri contra iThemes Security.

Frente 3 — Credenciales. Rotá todas las contraseñas de usuarios administradores desde el panel de WordPress. Generá nuevas claves de autenticación (las constantes AUTH_KEY, SECURE_AUTH_KEY, etc.) usando el generador oficial de WordPress y reemplazalas en wp-config.php. Cambiá la contraseña de la base de datos y actualizala en wp-config.php. Revisá la tabla wp_users y eliminá cualquier cuenta con permisos de administrador que no reconozcas —a veces los atacantes se crean un usuario falso para mantener acceso.

Si hacés solo el frente 1, el atacante vuelve a entrar por las credenciales que dejaste sin tocar. Si solo tocás la base de datos, los archivos siguen sirviendo el redirect. Es un combo sí o sí.

¿Qué herramientas pueden ayudar a detectar y limpiar redirects maliciosos?

No hace falta que hagas todo a mano. Hay plugins y servicios que automatizan buena parte del trabajo, aunque cada uno tiene su enfoque. La tabla que sigue resume lo que ofrecen en junio de 2026, basada en los relevamientos de wpbeginner y limpiatuweb.com:

Ojo con esto: Wordfence gratuito es un golazo para escanear, pero la limpieza la tenés que hacer vos siguiendo sus indicaciones. MalCare, en cambio, te limpia el sitio con un clic desde su panel, y eso para un redirect condicional que está regado en seis lugares distintos puede ahorrarte horas. Ahora bien, ningún plugin te exime de rotar las credenciales y cerrar la vulnerabilidad de entrada —eso va por tu cuenta.

¿Por qué vuelven los atacantes y cómo prevenirlo?

El patrón es predecible. Según datos de Patchstack que recoge el artículo de referencia, si limpiás el código malicioso pero no cerrás la vulnerabilidad que permitió la entrada —típicamente un plugin desactualizado con una falla conocida—, el atacante vuelve a infectar el sitio en un promedio de 14 días. A veces usa el mismo vector, a veces prueba otro, pero la persistencia es alta porque muchos sitios WordPress quedan meses sin actualizar.

Las medidas que cierran el ciclo de una vez:

• Actualizá todos los plugins, temas y el core a la última versión. No dejes nada con actualizaciones pendientes. El 80% de las reinfecciones vienen de plugins que quedaron congelados en una versión vulnerable.
• Auditá los permisos de archivos. wp-config.php debe estar en 600 o 640, nunca en 777. Lo mismo para .htaccess. Si el servidor usa suPHP o similares, 644 para archivos y 755 para directorios es suficiente.
• Activá un firewall de aplicación (WAF). El que viene con Wordfence, o uno a nivel de hosting, bloquea peticiones maliciosas antes de que lleguen a WordPress. Shield Security también hace este trabajo sin costo.
• Configurá backups automáticos diarios externos. Un backup que no dependa de un plugin de WordPress —idealmente a nivel de hosting— te permite restaurar a un punto limpio en minutos. Si tu sitio está en donweb.com, los backups diarios automatizados vienen incluidos en el panel y se restauran sin tocar phpMyAdmin.
• Activá el monitoreo de integridad de archivos. Wordfence y Shield Security te avisan por mail si un archivo del core o de un plugin cambia sin que vos lo hayas actualizado. Esa alerta temprana te da margen para actuar antes de que Google te marque.

La diferencia entre un sitio que se infecta una vez y uno que entra en loop es esa: tener un backup limpio y un sistema que te grite cuando algo se modifica.

Errores comunes al limpiar un redirect hack en WordPress

Después de ver decenas de casos, hay tres errores que se repiten con una consistencia casi cómica. Evitalos y te ahorrás el segundo round. Para más detalles técnicos, mirá la comparación de MalCare y Sucuri para limpiar malware.

Error 1: Limpiar solo el .htaccess. El redirect condicional rara vez está solo ahí. El atacante suele tener un backdoor en wp-config.php o en un plugin modificado, y si solo tocás el .htaccess, a las horas vuelve a aparecer la redirección. Solución: revisá las seis ubicaciones que mencioné más arriba, sin excepción.

Error 2: No rotar las credenciales después de limpiar. Si el atacante obtuvo las claves de autenticación del wp-config.php o la contraseña de un administrador, puede volver a escribir el código malicioso sin necesidad de explotar una vulnerabilidad nueva. Solución: cambiá absolutamente todas las contraseñas y claves de autenticación, incluida la de la base de datos, el mismo día que terminás la limpieza.

Error 3: Testear el sitio logueado como administrador. Es el error más tentador porque es lo que hacés automáticamente: abrís el navegador, entrás al panel, ves que carga bien y respirás aliviado. Pero el redirect condicional justamente no se activa para administradores logueados. Solución: testeá siempre con curl o con un celular en modo incógnito sin sesión de WordPress.

Qué está confirmado y qué es especulación

Con los redirects condicionales hay mucha data firme y algunas cosas que se dan por sentadas sin suficiente evidencia. Separemos:

• Confirmado: el comportamiento condicional basado en user-agent y referer existe y está documentado por Sucuri, Wordfence y los reportes de wpbeginner. Las seis ubicaciones de código malicioso relevadas por Nova Pulse en abril de 2026 coinciden con los hallazgos en sitios reales. El plazo de reinfección de ~14 días si no se cierra el vector de entrada viene de datos de Patchstack y se condice con la experiencia en producción.
• No confirmado del todo: que el ataque siempre entre por un plugin desactualizado. En muchos casos el vector es una contraseña débil de FTP o un archivo wp-config.php con permisos demasiado abiertos. También se especula con que algunos redirects usan JavaScript inyectado en la base de datos y no reglas de servidor, pero no hay un estudio que desglose la proporción exacta.

Lo que no está en discusión es que si dejás credenciales viejas después de limpiar, el atacante vuelve a entrar. Eso es un hecho comprobable en cualquier entorno de staging. Relacionado: la guía actualizada de Sucuri vs Patchstack 2026.

Preguntas Frecuentes

¿Por qué mi WordPress redirige a sitios de spam?

Porque un atacante insertó código malicioso en archivos del servidor o en la base de datos que evalúa condiciones como el user-agent del navegador o la fuente de tráfico. Cuando un visitante llega desde Google o desde un dispositivo móvil sin sesión de administrador, el código activa una redirección a un dominio externo que suele ser una página de phishing, publicidad forzada o descarga de malware.

¿Cómo detectar si mi WordPress tiene un redirect hack?

El método más directo es usar curl desde una terminal con el user-agent de Googlebot y el referer de Google. Si el header de respuesta incluye un Location a un dominio que no es el tuyo, hay infección activa. También podés revisar Google Search Console en la sección “Problemas de seguridad” y hacer la prueba desde un celular en modo incógnito sin conexión WiFi previa al panel de administración.

¿Dónde se esconde el código malicioso en WordPress?

En seis ubicaciones típicas según el análisis de Nova Pulse (abril 2026): el archivo .htaccess con reglas de redirección, wp-config.php con inclusiones ocultas, functions.php del tema activo con funciones inyectadas, la tabla wp_options con valores serializados infectados, la tabla wp_posts con scripts en el contenido de entradas, y archivos de plugins activos que fueron modificados después de su instalación oficial.

¿Qué herramientas puedo usar para limpiar un redirect hack?

Las más usadas en 2026 son Wordfence (escáner gratuito, limpieza manual guiada), MalCare (limpieza automatizada en un clic desde USD 99/año), Sucuri (monitoreo externo y limpieza con soporte humano desde USD 199/año) y Jetpack Security (backups diarios y escaneo desde USD 120/año). Shield Security es una opción gratuita para prevención, pero no limpia infecciones ya instaladas.

¿Cómo evitar que los atacantes vuelvan a infectar mi WordPress?

Actualizando todos los plugins, temas y el core a la última versión disponible, auditando los permisos de archivos (wp-config.php en 600 o 640), rotando todas las credenciales administrativas y de base de datos, activando un WAF como el de Wordfence o Shield Security, y manteniendo backups automáticos diarios externos que permitan restaurar a un punto limpio sin depender del panel de WordPress infectado.

Conclusión

Limpiar un redirect hack en WordPress no es solo borrar una línea del .htaccess y rezar. Es una auditoría completa de archivos, base de datos y credenciales, hecha en el mismo día, sin saltearse ningún paso. La infección está diseñada para pasar desapercibida ante el administrador, así que la detección tiene que ser externa: curl, Search Console, un celular en modo incógnito.

Lo que cambió en 2026 respecto a años anteriores es que los atacantes diversificaron los puntos de persistencia —ya no es solo un archivo, son seis ubicaciones comunes— y que los servicios de limpieza automatizada como MalCare bajaron la barrera de entrada para quien no quiere meterse en código. Pero el principio sigue siendo el mismo: si no cerrás la vulnerabilidad que dejó entrar al atacante, en dos semanas estás de vuelta en el mismo loop.

Mi recomendación para un sitio argentino típico de WordPress es combinar Wordfence gratuito para escaneo semanal, Shield Security para hardening en tiempo real, y backups diarios externos —si tu hosting los incluye, mejor; si no, configuralos por tu cuenta con un cron y un volcado de base de datos a un almacenamiento fuera del servidor. La paz mental sale más barata que explicarle a un cliente por qué su sitio manda a los visitantes a una página de casinos.

Fuentes

• WordPress redirige a spam: análisis del redirect hack condicional — seguridadenwordpress.com
• Cómo detener la redirección de WordPress a sitios de spam — wpbeginner (español)
• Guía de limpieza del redirect hack en WordPress — limpiatuweb.com