WordPress redirige a páginas raras: causas reales y cómo detectar si es hack o configuración

Que tu WordPress te mande a páginas raras (casino, “tu iPhone tiene virus”, premios falsos, descargas extrañas) no es “un bug cualquiera”. Casi siempre es una de estas 3 cosas: inyección en tu sitio (tema/plugin/JS), reglas en el servidor (.htaccess) o problema fuera de WordPress (DNS/Cloudflare).

En este bloque vas a lograr algo concreto: identificar el patrón exacto de la redirección y con eso saber en qué capa está el problema. Eso te ahorra horas y evita el típico error de “borré algo y volvió”.

Lo que vas a aprender a hacer en 10 minutos:

Confirmar cuándo ocurre la redirección (móvil, Google, incógnito, visitantes nuevos).
Distinguir si es un redirect de servidor (301/302) o un “salto” por JavaScript.
Definir la ruta correcta de solución sin romper tu web.

Alerta rápida: si un “soporte” te dice que instales un script, pegues código raro o pagues para “desbloquear” tu web, desconfía. Las redirecciones maliciosas viven de la urgencia.

Índice

Primero: confirma el patrón (esto define la causa)
Matriz rápida: síntoma → causa probable → dónde mirar después
Diagnóstico rápido: 3 pruebas simples para confirmar el origen
Qué NO hacer (porque empeora o tapa el problema)
Lecturas relacionadas (para completar el cluster)
Soluciones por escenario: cómo detener las redirecciones sin romper tu WordPress
Escenario A: toda la web redirige (o redirige instantáneo)
Escenario B: redirige después de 1–2 segundos (parece “salto”)
Escenario C: redirige solo en algunas páginas (no en todo el sitio)
Escenario D: tu WordPress “se ve limpio” pero igual redirige (DNS/Cloudflare)
Checklist final de limpieza (para que no vuelva)
Lecturas relacionadas (para reforzar el cluster)
Cuando el problema no está “dentro” de WordPress: DNS, Cloudflare y verificación final
Señales fuertes de DNS hijacking o Cloudflare comprometido
Checklist de rescate en DNS (sin pasos con capturas)
Verificación final: cómo confirmar que realmente quedó resuelto
Prevención para que no vuelva (lo mínimo que sí marca diferencia)
Lecturas relacionadas (para completar el cluster)

Primero: confirma el patrón (esto define la causa)

Responde estas preguntas con total honestidad. No necesitas herramientas avanzadas; solo observar bien el comportamiento:

1) ¿Pasa solo en móvil o también en PC?

Solo móvil: suele ser inyección JavaScript que detecta el navegador móvil, o scripts de anuncios maliciosos.
En móvil y PC: puede ser .htaccess, plugin/tema comprometido o DNS si es global.

2) ¿Pasa solo en incógnito o a “visitas nuevas”?

Solo incógnito / visitas nuevas: típico de inyecciones que se activan 1 vez por sesión (para que tú no lo notes fácil).
Siempre, sin excepción: suele ser redirección de servidor (.htaccess/DNS) o un plugin muy agresivo.

3) ¿Pasa solo cuando entras desde Google (no desde acceso directo)?

Solo desde Google: suena a cloaking o SEO spam (el sitio se comporta “normal” si entras directo, pero “malo” si vienes de buscador).
También entrando directo: más probable .htaccess/JS/plugin.

4) ¿Pasa en todo el sitio o solo en algunas URLs?

Todo el sitio redirige: piensa primero en .htaccess, configuración del servidor o DNS.
Solo algunas páginas: suele ser tema/plantilla, un plugin específico, o contenido inyectado en una página/post.

5) ¿La redirección ocurre “instantáneo” o después de 1–2 segundos?

Instantáneo (apenas cargas): más probable redirect de servidor (301/302) o DNS.
Después de 1–2 segundos: muchas veces es JavaScript inyectado (carga tu web y luego “salta”).

Matriz rápida: síntoma → causa probable → dónde mirar después

Solo móvil → JavaScript/ads injection → revisar tema (header/footer) y plugins recientes.
Solo desde Google → cloaking/SEO spam → revisar plugins, tema y señales de URLs spam.
Toda URL redirige → .htaccess o DNS → mirar .htaccess y configuración de DNS/Cloudflare.
Solo algunas URLs → plantilla/post/plugin → revisar plugins y contenido inyectado en esas páginas.
Solo incógnito / visitas nuevas → malware “selectivo” → revisar JS, plugins y archivos sospechosos.

Con esto ya deberías tener una sospecha fuerte de la capa responsable. Ahora vamos a confirmarlo con 3 pruebas simples.

Diagnóstico rápido: 3 pruebas simples para confirmar el origen

Prueba 1: incógnito + cambia de red (Wi-Fi vs datos móviles)

Abre tu web en incógnito y prueba:

En tu Wi-Fi
Con datos móviles (o desde el celular compartiendo internet)

Cómo interpretar:

Si cambia según la red, puede haber cache/CDN o incluso algo a nivel DNS/ISP (menos común, pero pasa).
Si es igual en todas, el problema está en tu sitio (tema/plugin/.htaccess) o DNS global.

Prueba 2: ¿es un redirect “real” (servidor) o un “salto” por JavaScript?

Observa el comportamiento:

Redirect de servidor: la página rara abre casi al instante, sin que veas tu web “cargar”.
Redirect por JavaScript: ves tu web cargar 1–2 segundos y luego te manda a otro sitio.

Por qué importa: si es servidor, casi seguro miras .htaccess / reglas / DNS. Si es JS, miras tema, plugins y scripts.

Prueba 3: desactiva “lo que más suele mentir”: caché y optimización (temporal)

Muchos hacks se esconden “detrás” de cachés o minificadores. Si tienes plugins de caché/optimización, el diagnóstico suele mejorar si los desactivas temporalmente (solo para probar).

Si al desactivar caché/optimización el problema desaparece o cambia, puede haber inyección en scripts minificados o cacheados.
Si no cambia nada, apunta más a .htaccess, plugin/tema comprometido o DNS.

Nota: no es la solución final; es una prueba para acotar la causa.

Qué NO hacer (porque empeora o tapa el problema)

No restaures cualquier backup “a ciegas”. Si no cierras la puerta (plugin vulnerable/credenciales), vuelve.
No borres archivos al azar. Puedes romper el sitio y el backdoor seguir vivo.
No instales 5 plugins de seguridad desesperado. A veces solo agregas complejidad y conflictos.
No asumas que “si a mí no me redirige, ya está bien”. Mucho malware es selectivo (móvil, visitas nuevas, desde Google).

Idea clave: tu misión no es “parchar un síntoma”. Tu misión es descubrir qué capa está empujando la redirección. En el siguiente bloque pasamos a soluciones por escenario (servidor/.htaccess, JS/tema, plugins, cloaking y el caso DNS).

Lecturas relacionadas (para completar el cluster)

Soluciones por escenario: cómo detener las redirecciones sin romper tu WordPress

Ya con el patrón identificado, ahora sí puedes ir directo a la capa correcta. Este bloque está armado para que avances como “árbol de decisión”: si tu síntoma coincide, haces ese bloque y validas. Si no coincide, pasas al siguiente.

Meta realista: dejar tu sitio sin redirecciones y sin “puertas abiertas”. Si solo quitas el síntoma pero no el origen, suele volver.

Escenario A: toda la web redirige (o redirige instantáneo)

Cuando todas las URLs redirigen o el salto es inmediato, normalmente es:

.htaccess alterado (Apache/LiteSpeed), o
reglas del servidor (Nginx), o
un cambio en DNS/Cloudflare (lo cubrimos como escenario D).

A1) Revisa y “desinfecta” .htaccess (si existe)

En muchos hostings, el archivo .htaccess está en la raíz del sitio (donde está wp-config.php). Lo que buscas son señales como:

Bloques enormes con texto raro que no reconoces
Reglas de redirección a dominios extraños
Código ofuscado o líneas muy largas sin explicación

Acción segura: no borres todo a lo loco. Haz esto:

Renombra el archivo a .htaccess.bak (así puedes volver atrás).
Genera uno limpio guardando los enlaces permanentes desde WordPress (si puedes entrar) o restaurando el bloque estándar.

Validación: prueba en incógnito y desde móvil. Si el redirect desaparece, el problema estaba en reglas a nivel servidor.

Si tu web se rompe sin .htaccess: significa que sí dependías de reglas válidas (permalinks). En ese caso, restaura lo básico y elimina solo lo sospechoso.

Escenario B: redirige después de 1–2 segundos (parece “salto”)

Este es el patrón más típico de JavaScript inyectado. La web carga normal, y luego te manda a otro lado (muchas veces solo a móviles o visitas nuevas).

B1) Entra por el lado más probable: tema (header/footer/functions)

La inyección suele vivir en:

header.php y footer.php
functions.php
un archivo script agregado recientemente

Qué buscar:

Scripts que cargan desde dominios que no conoces
Cadenas largas raras, texto ofuscado, llamadas a eval o base64_decode
Scripts insertados “al final” del footer

Acción segura: si sospechas del tema:

Temporalmente cambia a un tema estándar (si tienes acceso) para probar.
Si el redirect desaparece al cambiar de tema, el problema está en el tema (o en un child theme).

Consejo: si usas un tema nulled/pirata, asume que es culpable hasta demostrar lo contrario. Es una de las causas más repetidas.

B2) Revisa plugins que inyectan scripts

Muchos redirects vienen de plugins de:

popups / publicidad / monetización
optimización/minificación
scripts de header/footer
“security scanners” dudosos

Prueba rápida: desactiva temporalmente los plugins más relacionados con scripts/caché. Si desaparece, reactiva uno por uno hasta encontrar el culpable.

Validación: siempre prueba en móvil + incógnito. Muchos hacks están diseñados para no afectarte a ti “todo el tiempo”.

Escenario C: redirige solo en algunas páginas (no en todo el sitio)

Cuando el redirect ocurre solo en ciertas URLs, normalmente es:

contenido inyectado en esa página/post
una plantilla específica del tema
un plugin que afecta solo cierto tipo de contenido

C1) Revisa si hay scripts “pegados” en el contenido

Esto pasa más de lo que parece, sobre todo si el sitio fue comprometido vía credenciales y el atacante editó páginas.

Revisa el editor de la página afectada (incluyendo widgets/HTML personalizado si usas constructor).
Busca bloques HTML extraños, iframes ocultos o scripts insertados.

Tip: si el ataque es “SEO spam”, a veces crean páginas nuevas y tú ni te enteras. Por eso conviene revisar la lista de páginas recientemente modificadas.

C2) Revisa la plantilla que usa esa página

Si solo falla un tipo de página (por ejemplo, productos o posts), puede ser una plantilla específica (single.php, page.php, templates del builder, etc.).

Acción práctica: cambia temporalmente a un tema estándar para confirmar si el problema es del tema. Si desaparece, ya acotaste el origen.

Escenario D: tu WordPress “se ve limpio” pero igual redirige (DNS/Cloudflare)

Este caso confunde a cualquiera: revisas WordPress, desactivas plugins, cambias tema… y aun así redirige. Aquí debes pensar en DNS hijacking o cambios en el proxy/CDN.

D1) Señales de DNS/Cloudflare comprometido

La redirección pasa incluso con un HTML simple
El hosting dice “todo ok”, pero los visitantes siguen redirigiendo
La redirección cambia según la región/red

Qué hacer en simple: verifica que tus DNS apunten al hosting correcto y que nadie haya cambiado tu zona. Este tema lo cubrimos a fondo en:

Regla: si tienes Cloudflare, revisa acceso a la cuenta y cambia contraseñas/2FA. Muchos ataques no tocan WordPress: tocan la capa DNS/CDN.

Checklist final de limpieza (para que no vuelva)

Una vez que el redirect se detuvo, haz este cierre:

Actualiza WordPress core, plugins y tema (todo lo que se quedó atrás es riesgo).
Elimina plugins/temas que no uses (incluso inactivos).
Cambia contraseñas otra vez si encontraste admin desconocidos o backdoors (porque pudieron copiar credenciales).
Revisa uploads: archivos .php dentro de wp-content/uploads son sospechosos en la mayoría de sitios.
Activa medidas de hardening básicas (2FA admin, deshabilitar editor, limitar intentos).

Si tu caso fue más amplio (SEO spam, backdoors, reinfección), conviene complementar con:

Lecturas relacionadas (para reforzar el cluster)

Cuando el problema no está “dentro” de WordPress: DNS, Cloudflare y verificación final

Si ya desactivaste plugins, cambiaste de tema, revisaste .htaccess y aun así hay redirecciones… muchas veces el atacante no tocó WordPress: tocó la capa de dominio/DNS o la cuenta de Cloudflare. Este escenario es más común de lo que parece porque, cuando controlan DNS, pueden redirigir tráfico sin dejar “huellas” claras en tus archivos.

En esta sección vas a lograr:

Detectar si el redirect viene por DNS/Cloudflare.
Asegurar tu dominio para que no lo vuelvan a tomar.
Hacer una verificación final que realmente confirme que quedó limpio.

Señales fuertes de DNS hijacking o Cloudflare comprometido

La redirección ocurre incluso si subes una página HTML simple (sin WordPress) al hosting.
A ti te funciona “a veces”, pero a visitantes nuevos o desde otra red los manda a otro sitio.
El hosting te dice que no ve malware, pero el problema persiste.
Usas Cloudflare y ves reglas/redirects que no recuerdas haber creado.

Idea clave: cuando DNS/Cloudflare está comprometido, puedes limpiar WordPress 10 veces… y seguirá pasando.

Checklist de rescate en DNS (sin pasos con capturas)

1) Asegura el correo dueño del dominio (primero)

Muchos “robos” de dominio empiezan por el correo del dueño. Si el atacante controla el email, puede resetear accesos del registrador y Cloudflare.

Cambia la contraseña del correo.
Activa 2FA (siempre).
Revisa sesiones/dispositivos desconocidos.

2) Entra al registrador del dominio y revisa cambios recientes

Verifica que el dominio siga en tu cuenta (y que el email sea el tuyo).
Revisa si cambiaron DNS (nameservers) o registros (A, CNAME, etc.).
Activa 2FA del registrador y cambia contraseña.

Si ves nameservers que no reconoces, eso explica casi cualquier redirección “fantasma”. Devuélvelos a los correctos y refuerza seguridad.

3) Si usas Cloudflare: revisa 3 zonas “típicas de ataque”

En Cloudflare, los atacantes suelen tocar:

Rules / Redirect Rules: reglas que envían visitantes a otro dominio.
DNS: A/CNAME apuntando a otro servidor.
Workers: scripts que interceptan tráfico (si tu plan lo permite).

Acción práctica: si encuentras una regla o Worker que no configuraste, desactívalo y cambia credenciales + activa 2FA.

Referencia oficial (Cloudflare WAF/seguridad en general):

Verificación final: cómo confirmar que realmente quedó resuelto

No te quedes con “parece que ya no redirige”. Los ataques modernos son selectivos (solo móvil, solo visitas nuevas, solo desde Google). Haz estas comprobaciones:

1) Prueba cruzada en 4 condiciones

Móvil con datos (sin Wi-Fi)
PC en incógnito
Otra red (por ejemplo, desde el teléfono de un familiar)
Entrando desde Google (si tu sitio está indexado)

Si falla en una sola condición, todavía hay una capa comprometida (JS selectivo, caché/CDN, DNS o cloaking).

2) Si tu sitio aparece “peligroso” en navegadores o Google

Cuando ya limpiaste, revisa el reporte de seguridad en Search Console. Si había advertencias, ahí verás el estado.

Security issues report (Google Search Console)

Tip importante: si el hack fue SEO spam, además de limpiar, debes asegurarte de que las URLs falsas devuelvan 404/410 y no se sigan generando.

3) Limpia cachés después de corregir (para no “perseguir fantasmas”)

Caché de tu plugin (si usas)
Caché del servidor/hosting (si aplica)
Caché/CDN (Cloudflare)

Esto evita que tú veas “una versión vieja” mientras los visitantes ven otra.

Prevención para que no vuelva (lo mínimo que sí marca diferencia)

1) Hardening básico en WordPress

Guía oficial recomendada:

Hardening WordPress (oficial)

2FA para administradores
Eliminar plugins/temas que no uses
Actualizar todo (core/plugins/tema) con disciplina
Evitar temas/plugins nulled

2) Seguridad del dominio (la capa que más duele si cae)

2FA en el registrador
Contraseña única y fuerte
Correo del dominio con 2FA
Revisar accesos y cambios periódicamente

Una frase que te ahorra problemas: si el atacante controla tu dominio, controla tu tráfico. Por eso esta capa vale oro.

Lecturas relacionadas (para completar el cluster)

Deja una respuesta Cancelar la respuesta