En resumen: cuando el sitio web redirige a páginas ajenas, la causa está en una de seis capas: DNS, CDN o proxy, configuración del servidor web, código PHP, base de datos o scripts incluidos. Como muchas redirecciones solo actúan bajo ciertas condiciones, pruebe de forma específica con distintos identificadores y páginas de origen. Proteja primero a los visitantes, preserve las pruebas y, tras la eliminación, cierre la vía de entrada.
Cuando los clientes acaban en páginas de sorteos
El aviso suele llegar de fuera. Un cliente escribe que, al abrir su página, ha terminado en un sorteo o en una tienda dudosa. Usted lo comprueba en su propio ordenador y todo parece normal. No es una contradicción, sino intencionado: las redirecciones posteriores a un hackeo están diseñadas para que los responsables las noten lo más tarde posible.
Para su empresa es delicado. Los visitantes pierden la confianza, los buscadores y navegadores pueden mostrar avisos y en las páginas de destino a veces esperan fraudes o software malicioso. Además, una redirección casi nunca es lo único que deja un atacante.
Tras PHP2Shell, las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 con ejecución de código sin autenticación, las redirecciones figuran entre las consecuencias visibles que los responsables deberían tomar en serio. No son un indicio específico de PHP2Shell, ya que no existen indicadores de compromiso (IoC) confirmados. Pero muestran que alguien pudo modificar contenidos de su sitio web.
Con frecuencia las redirecciones no vienen solas. Quien redirige a los visitantes suele crear además páginas de spam para los buscadores, con el fin de captar aún más tráfico. Si Google ya muestra un aviso de sitio web hackeado, la guía Quitar el aviso de Google describe cómo solicitar la revisión. Las páginas ajenas en el índice de búsqueda se tratan en el artículo Spam SEO y páginas ajenas en el índice de Google.
Por qué el sitio web solo redirige a veces
Las redirecciones condicionales evalúan características de la petición. Las más frecuentes son estas:
- Origen: solo se redirige a quien llega desde un resultado de búsqueda. Los accesos directos muestran la página normal.
- Dispositivo: solo afecta a dispositivos móviles o a determinados navegadores.
- Repetición: la redirección actúa una vez por visitante; después establece una cookie y se calla.
- Inicio de sesión: quien ha iniciado sesión en el CMS nunca ve nada.
- Tiempo o azar: la redirección actúa solo en una parte de los accesos.
Por eso no pruebe solo desde su puesto de trabajo. Con una consulta de solo lectura ve cómo responde el servidor a distintos accesos:
# Acceso normal: código de estado y destino de una posible redirección
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' https://www.ihre-domain.de/
# Acceso como desde un dispositivo móvil que llega desde una búsqueda
curl -s -o /dev/null -w '%{http_code} %{redirect_url}\n' \
-A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15 Mobile/15E148" \
-e "https://www.google.com/" https://www.ihre-domain.de/
Si solo en la segunda consulta aparece un destino ajeno, la redirección está en el servidor. Si ambas parecen normales, puede producirse en el navegador mediante JavaScript. Entonces ayuda mirar el código fuente de la página servida o la vista de red de las herramientas para desarrolladores del navegador, preferiblemente en una ventana privada.
El sitio redirige: revisar las seis capas
Avance de fuera hacia dentro. Así evita pasar horas buscando en el código cuando la causa está en una entrada DNS:
| Capa | Causa típica | Comprobación |
|---|---|---|
| Dominio y DNS | registro A o servidores de nombres modificados | comparar las entradas DNS con el valor esperado conocido, revisar el acceso al registrador |
| CDN o proxy | regla ajena de redirección o de página | revisar las reglas en el área de cliente del proveedor |
| Servidor web | reglas en .htaccess o en la configuración del servidor |
buscar reglas Rewrite y Redirect con condiciones |
| Código PHP | código adicional en archivos de entrada, plantillas o extensiones | comparar los archivos del núcleo con el original |
| Base de datos | ajustes de dirección modificados, scripts en contenidos u opciones | buscar de forma específica direcciones y scripts ajenos |
| Scripts externos | inclusión comprometida de un tercero | listar y valorar las fuentes de scripts incluidas |
Las capas exteriores suelen saltarse porque no están en el propio servidor. Precisamente por eso son peligrosas: quien se ha hecho con la cuenta del registrador o del proveedor de CDN no necesita acceso al servidor. Compruebe allí, además de las reglas, quién tiene acceso y si la autenticación en dos factores está activa.
Para la capa del servidor web resultan útiles las búsquedas de solo lectura de reglas que reaccionan al origen o al dispositivo:
# Reglas de redirección con condiciones en todos los archivos .htaccess
grep -rn --include='.htaccess' -iE 'Rewrite(Cond|Rule)|Redirect' /var/www/ihre-website
# Redirecciones en la configuración del servidor (Apache y Nginx)
grep -rn -iE 'Rewrite|Redirect|return 30[12]' /etc/apache2/ /etc/nginx/ 2>/dev/null
Para la capa PHP, Comparar los archivos del núcleo del CMS con el original describe el procedimiento. Para la base de datos merece la pena el artículo Revisar la base de datos en busca de código inyectado.
Cuando la causa está fuera del servidor
No toda redirección implica un servidor comprometido. Los scripts de terceros incluidos, por ejemplo para chats, estadísticas o publicidad, se ejecutan directamente en el navegador de los visitantes. Si un proveedor así es comprometido, o si caduca un dominio desde el que su página sigue cargando un script, puede producirse una redirección sin que se haya modificado ningún archivo en su servidor.
Una Content Security Policy limita las fuentes desde las que el navegador puede cargar scripts y hace visibles estos casos. Encontrará indicaciones en Cabeceras de seguridad para sitios web. Muy raramente la causa está en el propio visitante: el software publicitario o malicioso de su ordenador redirige entonces también en otros sitios web.
El orden correcto tras el hallazgo
- Proteger a los visitantes: poner el sitio web en modo de mantenimiento o bloquear las áreas afectadas.
- Preservar las pruebas: copiar con marca de tiempo las reglas, archivos y contenidos de la base de datos sospechosos antes de eliminarlos.
- Eliminar: suprimir la redirección y sustituir los archivos del núcleo por una fuente limpia.
- Cerrar la vía de entrada: llevar PHP a una versión corregida, actualizar el CMS y las extensiones, reiniciar todos los workers y renovar los accesos.
- Volver a probar: comprobar de nuevo con todas las variantes de la segunda sección y vigilar Search Console.
Una regla de redirección eliminada no prueba que el sitio web esté limpio. Si la regla reaparece al cabo de unos días, queda en algún lugar una puerta trasera que la reescribe.
¿Cómo ayuda PHP SOS en concreto?
- Reproducimos la redirección con distintos identificadores y páginas de origen y acotamos la capa.
- Preservamos las pruebas y eliminamos redirecciones, código malicioso y puertas traseras en archivos, configuración y base de datos.
- En caso de infección aguda, nuestra ayuda de emergencia para sitios web hackeados se encarga de la contención hasta que el incidente quede cerrado y documentado.
- Revisamos los scripts de terceros incluidos y recomendamos una Content Security Policy adecuada.
Preguntas frecuentes
¿Por qué yo mismo no veo la redirección?
Muchas redirecciones solo actúan bajo ciertas condiciones: para visitantes que llegan desde la búsqueda de Google, solo en dispositivos móviles, solo en la primera visita o no para administradores con sesión iniciada. Por eso conviene probar con distintos dispositivos, sin iniciar sesión y desde un enlace de resultados de búsqueda.
¿Puede producirse una redirección sin que haya un hackeo?
Sí. Un plugin caducado, un script externo comprometido, entradas DNS incorrectas o software malicioso en el ordenador del visitante pueden causar efectos parecidos. Si la causa está en el propio ordenador, la redirección suele producirse también en otros sitios web.
¿Dónde ocultan los atacantes las redirecciones con más frecuencia?
Lo habitual son reglas en .htaccess o en la configuración del servidor, código adicional en los archivos de entrada de la aplicación, ajustes de dirección modificados en la base de datos y fragmentos de JavaScript inyectados en contenidos o plantillas.
¿Qué debo hacer de inmediato si mi sitio web redirige?
Proteger a los visitantes, por ejemplo con un modo de mantenimiento, y preservar las pruebas antes de borrar nada. Después, buscar la causa capa por capa y cerrar la vía de entrada. Una regla eliminada sin haber cerrado la brecha suele reaparecer.