WordPress redirige a spam: cómo encontrarlo y eliminarlo

Si tu WordPress redirige a sitios de spam, lo más probable es que tengas un redirect hack condicional: código malicioso inyectado que detecta si sos admin y te muestra el sitio limpio mientras manda a tus visitantes a páginas de farmacia o casinos. Según el análisis de Nova Pulse publicado en abril de 2026, el código suele esconderse en seis ubicaciones clave y, si no cerrás la puerta de entrada, el atacante vuelve en dos semanas.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado por WordPress Foundation, que permite crear y administrar sitios web, blogs y tiendas online sin requerir conocimientos avanzados de programación.

Qué es una redirección condicional en WordPress

Un redirect hack condicional es un ataque donde el código malicioso inyectado en tu WordPress evalúa quién está visitando el sitio antes de decidir si redirige o no. Si detecta que sos el admin logueado, muestra el sitio normal. Si detecta un visitante que viene de Google, o un usuario en mobile, o alguien sin cookie de sesión activa, lo manda a una página de spam.

El diseño del ataque es deliberado. El atacante necesita que vos no lo veas, porque si lo ves, lo arreglás. Por eso el WordPress que te redirige a spam raramente lo hace cuando estás trabajando en el panel.

Lo que hace que este tipo de compromiso sea especialmente dañino es el tiempo que pasa sin que lo notes. Tus visitantes se van a spam, Google empieza a registrar el comportamiento, y tu sitio puede terminar en la lista negra del buscador antes de que te enterés de que algo pasa.

Las 6 ubicaciones donde se esconde el código malicioso

Según el análisis de Nova Pulse de abril de 2026, el código de redirección aparece en seis lugares concretos. No en diez, no en «cualquier parte»: seis.

1. El archivo .htaccess

El más frecuente. Los atacantes agregan un bloque que redirige según el referrer (solo tráfico de Google) o el user-agent (solo mobile). Buscá cualquier RewriteCond %{HTTP_REFERER} o RewriteCond %{HTTP_USER_AGENT} que no hayas puesto vos. Ojo: puede haber .htaccess en subcarpetas también, no solo en la raíz.

2. wp-config.php

Menos común pero más grave. Si el atacante metió código acá, tiene acceso a las credenciales de la base de datos. Buscá funciones eval() o base64_decode() que no deberían estar ahí.

3. functions.php del tema activo

Clásico. El atacante modifica el functions.php para agregar un hook que ejecuta el redirect antes de que WordPress termine de renderizar. Si cambiaste de tema y «se solucionó», era acá. Relacionado: implementar protección contra ataques DDoS.

4. Tabla wp_options de la base de datos

Los atacantes guardan código en opciones como widget_text, sidebars_widgets o incluso crean opciones nuevas con nombres que parecen legítimos. Revisá con phpMyAdmin buscando base64_decode o eval en toda la tabla.

5. Tabla wp_posts

El código se inyecta directamente en el contenido de posts o páginas como un <script> tag oculto. Puede estar en el post_content o en post_meta. Buscá con una query SQL: SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%base64%'.

6. Archivos de plugins activos modificados

El atacante modifica un archivo PHP de un plugin que tenés activo. El código se ejecuta porque WordPress carga el plugin en cada request. Esta variante es difícil de detectar a ojo porque el archivo del plugin parece legítimo.

Cómo detectar un redirect hack en tu sitio

Ponele que entrás al sitio desde tu computadora y todo se ve bien. Antes de concluir que no hay problema, probá esto.

Abrí una terminal y ejecutá:

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

Si en la respuesta aparece un Location: apuntando a algo que no es tu dominio, encontraste el problema. Este comando simula ser Googlebot con referrer de Google, que es exactamente la condición que el código malicioso está esperando para activarse.

Otros síntomas que suelen aparecer antes de que alguien lo detecte directamente: caída de tráfico orgánico en Google Search Console, mensajes de usuarios que dicen que «el sitio los manda a otra página», alertas de tu proveedor de hosting, o la temida notificación de Google que dice que tu sitio puede estar comprometido. Si tenés Search Console configurado, chequeá la sección de Problemas de Seguridad. Más contexto en evitar plugins maliciosos en tu sitio.

Técnicas para encontrar el código inyectado

Una vez confirmado que hay un redirect, el trabajo es encontrar exactamente dónde está. Hay un orden lógico para hacer esto sin perder horas.

Primero, revisá los archivos modificados recientemente. Vía SSH: find /ruta/del/sitio -name "*.php" -mtime -7 te muestra los PHP modificados en los últimos 7 días. Si aparece algo raro (un archivo de plugin que «se modificó solo»), ahí está.

Segundo, buscá recursivamente por funciones peligrosas: grep -r "eval(base64_decode" /ruta/del/sitio --include="*.php". Combinaciones como eval(base64_decode(, eval(gzinflate( o preg_replace('/.*/e' son señales claras de código ofuscado.

Tercero, revisá la base de datos desde phpMyAdmin. Buscá en todas las tablas por el texto <script o base64. La mayoría de los paneles de hosting tienen phpMyAdmin disponible directamente.

Cuarto, revisá el historial de usuarios administradores. Entrá a Usuarios en el panel de WordPress y buscá cuentas admin que no reconocés. Es común que el atacante cree un usuario administrador como backdoor.

Pasos para remover el malware completamente

La remoción tiene tres frentes simultáneos. Si hacés solo uno, el malware vuelve o sigue activo desde otro vector.

Frente 1: Archivos. Limpiá el código de cada ubicación que encontraste. Para .htaccess, restaurá desde la versión por defecto de WordPress. Para functions.php, comparalo contra el original del tema. Para plugins, reinstalá desde el repositorio oficial de WordPress. Complementá con complementos seguros y verificados.

Frente 2: Base de datos. Limpiá wp_options y wp_posts. Hacé backup antes de tocar la base de datos. Si encontraste scripts inyectados en posts, usá el UPDATE de MySQL con cuidado o usá una herramienta como MalCare que automatiza esto.

Frente 3: Credenciales. Cambiá la contraseña de todos los usuarios admin. Cambiá las claves de autenticación en wp-config.php (WordPress tiene un generador oficial). Cambiá la contraseña de la base de datos y actualizala en wp-config.php. Eliminá los usuarios administradores que no reconocés. Limpiá la caché del servidor y de cualquier plugin de caché que uses.

¿Y qué pasa si hiciste todo eso pero a los días volvió? Exacto: no cerraste la puerta de entrada.

Por qué vuelven los atacantes y cómo prevenirlo

Acá viene lo que mucha gente se pierde. Remover el código malicioso sin parchear la vulnerabilidad que permitió la entrada es limpiar el humo sin apagar el fuego. Patchstack documenta que los reataques ocurren típicamente en un plazo de 14 días cuando el vector de entrada sigue abierto.

El vector más común en 2026 sigue siendo el mismo de siempre: plugins desactualizados con vulnerabilidades conocidas. Si el atacante entró por el plugin X versión 3.2.1 que tenés sin actualizar, puede volver a entrar exactamente igual después de que limpiaste todo.

Las medidas que realmente cierran la puerta:

• Actualizá todos los plugins inmediatamente después de la limpieza. Todos, no solo el que «parece» el culpable.
• Auditá los permisos de archivos: wp-config.php debe tener permisos 600 o 640, nunca 777.
• Activá un WAF (firewall de aplicación web) que bloquee intentos de inyección antes de que lleguen a tu sitio.
• Configurá backups automáticos diarios en una ubicación externa. Si tenés hosting en donweb.com, los planes incluyen backups que podés restaurar fácilmente desde el panel.
• Monitoreá cambios en archivos con herramientas como Wordfence File Integrity Scanner.

Herramientas para detectar y prevenir redirects maliciosos

Wordfence es el más instalado y tiene un buen escáner gratuito, pero la limpieza la tenés que hacer vos. MalCare tiene la ventaja de que hace la limpieza en un clic, sin que tengas que tocar código. Sucuri es la opción con más visibilidad externa del sitio (te detecta el problema aunque no esté instalado en el WordPress). Para la mayoría de los sitios medianos, Wordfence gratuito + backups automáticos + actualizaciones automáticas de plugins es una combinación que zafa bien.

Qué está confirmado y qué no

• Confirmado: El redirect hack condicional es el tipo de compromiso más común en WordPress según múltiples fuentes de seguridad de 2026.
• Confirmado: El código puede residir simultáneamente en múltiples ubicaciones (archivo + base de datos), lo que complica la limpieza parcial.
• Confirmado: Los atacantes crean backdoors adicionales (usuarios admin ocultos, archivos PHP en carpetas de subida) para mantener el acceso.
• No confirmado / varía por caso: El vector de entrada específico depende de qué plugins o versiones de WordPress tenés instaladas.
• Pendiente de verificar: Algunos reportes mencionan que ciertos temas premium de terceros también pueden ser el vector de entrada, pero los datos concretos de 2026 sobre esto todavía son escasos.

Errores comunes al limpiar un redirect hack

Error 1: Limpiar solo el .htaccess. El .htaccess es la primera ubicación que revisa todo el mundo y la primera que limpia. El problema es que el atacante casi siempre tiene el código en más de un lugar. Si limpiás solo el .htaccess y el problema «desaparece», esperá unos días: el código en la base de datos o en un plugin va a reactivar el redirect.

Error 2: No rotarlas credenciales. Sabemos que cambiar contraseñas es un fastidio. Pero si el atacante consiguió las credenciales de tu base de datos o de un usuario admin, la limpieza de código no sirve de nada: puede volver a inyectar todo. La rotación de claves es obligatoria, no opcional. Lo explicamos a fondo en automatizar WordPress de forma segura.

Error 3: Testear el sitio logueado como admin. Después de limpiar, mucha gente abre el sitio, lo ve bien, y da por resuelto el problema. El redirect condicional no se activa si estás logueado como admin (eso es justamente el punto del ataque). Siempre probá con el método curl de Googlebot o entrando desde un navegador en modo incógnito sin sesión.

Preguntas Frecuentes

¿Por qué mi WordPress redirige a visitantes pero no a mí como admin?

El código malicioso detecta si el visitante tiene una cookie de sesión de WordPress activa. Si la tiene (como vos cuando estás logueado), muestra el sitio normal. Si no la tiene (cualquier visitante externo), ejecuta el redirect. Algunos ataques son aún más específicos y solo redirigen al tráfico que viene de Google o a usuarios en dispositivos móviles.

¿Cómo sé si mi sitio tiene un malware redirect hack?

Ejecutá curl -A "Googlebot" -e "https://www.google.com" https://tusitio.com -L -I desde la terminal. Si la respuesta incluye un Location: apuntando a un dominio que no es el tuyo, el sitio está comprometido. También podés revisar Google Search Console en la sección Problemas de Seguridad, donde Google notifica activamente este tipo de comportamiento.

¿Dónde busco y cómo elimino un código de redirección inyectado?

Las seis ubicaciones a revisar son: .htaccess (buscá bloques RewriteCond que no pusiste vos), wp-config.php (buscá eval o base64_decode), functions.php del tema activo, la tabla wp_options de la base de datos, la tabla wp_posts, y los archivos de plugins activos. Para cada ubicación, comparalo contra la versión original o buscá funciones como eval(base64_decode( que no deberían estar ahí.

¿Qué es una redirección condicional y cómo afecta mi WordPress?

Una redirección condicional es código que evalúa el contexto del visitante (user-agent, referrer, presencia de cookies) antes de decidir si redirige o no. En el contexto de un hack de WordPress, significa que el sitio se comporta diferente para visitantes de Google que para el admin. El impacto directo es pérdida de tráfico orgánico, penalizaciones en buscadores y daño a la reputación del dominio.

¿Cómo evito futuros ataques de redirección a spam en WordPress?

La combinación que funciona: actualizaciones automáticas de plugins activadas, un WAF (Wordfence o Sucuri), backups diarios en ubicación externa, permisos de archivos correctos (wp-config.php en 640, no 777), y monitoreo de integridad de archivos. El vector de entrada en la gran mayoría de los casos es un plugin desactualizado con una vulnerabilidad conocida: mantener los plugins al día cierra ese vector.

Conclusión

El redirect hack condicional es un ataque diseñado para que no lo veas. Y funciona: en muchos casos el sitio lleva días o semanas redirigiendo a spam antes de que alguien se dé cuenta. La buena noticia es que la detección no requiere herramientas complejas, un curl con user-agent de Googlebot alcanza para confirmarlo en 30 segundos.

Lo que requiere más cuidado es la limpieza completa: archivos, base de datos, credenciales y, sobre todo, cerrar el vector de entrada. Sin ese último paso, el atacante vuelve. Patchstack lo documenta claramente: 14 días es el promedio de tiempo hasta el reataque cuando la vulnerabilidad original sigue activa.

Si tu sitio fue comprometido, el orden es: detectar con curl, limpiar en los seis frentes, rotar todas las credenciales, actualizar todos los plugins, y activar monitoreo continuo. En ese orden, sin saltarse pasos.

Fuentes

• Nova Pulse – Por qué tu WordPress redirige a spam y dónde encontrar el código (abril 2026)
• Patchstack – WordPress Redirect Hack: análisis técnico y remoción
• Astra Security – WordPress hackeado redireccionando: guía completa
• Jetpack – WordPress hackeado redirigiendo a spam
• MalCare – WordPress Redirect Hack: detección y limpieza