Abres la web con la sesión iniciada y todo parece normal. Un cliente que llega desde Google acaba en un anuncio, una actualización falsa o una tienda ajena. Las redirecciones selectivas permiten que la infección permanezca oculta para quien administra el sitio.
Considera creíble el aviso hasta que la evidencia indique lo contrario. No visites repetidamente el destino desde tu ordenador habitual ni borres archivos antes de conservar las condiciones que lo activan.
Si la redirección está activa, consulta el servicio de limpieza de redirecciones WordPress para definir evaluación, intervención y pruebas de cierre. Esta guía describe un síntoma; el título por sí solo no identifica la causa.
Registra el recorrido exacto
Solicita URL original, hora aproximada, dispositivo, navegador y si la visita llegó desde buscador, red social o enlace directo. Una captura es útil; la URL maliciosa debe tratarse como evidencia insegura.
No pidas al cliente que repita el problema. Un informe claro basta para empezar pruebas controladas. Anota si ocurrió en la primera visita y desapareció al refrescar: el malware puede dejar una cookie o marca de almacenamiento para no mostrarse dos veces.
Reproduce en un entorno aislado
Utiliza un perfil desechable sin sesión de WordPress. No abras correo, banca ni el panel desde ese perfil.
Prueba una matriz pequeña:
- acceso directo y con referrer de búsqueda;
- agente móvil y escritorio;
- primera visita sin cookies;
- página afectada y portada;
- CDN y origen, únicamente cuando estés autorizado.
Detente si intenta descargar algo. Conserva la petición sin abrir el archivo.
Inspecciona la cadena de redirección
Conserva una respuesta GET acotada, con cabeceras y cuerpo, antes de seguir una redirección. Una consulta HEAD no recoge ese cuerpo:
curl -q --silent --show-error --max-time 15 --max-filesize 1048576 --dump-header headers.txt --output response.txt https://example.com/Úsalo desde un entorno de análisis limpio y solo con una URL autorizada. La primera opción ignora la configuración local de curl; no se activa el seguimiento de redirecciones. Revisa cabeceras y texto guardado sin abrirlo como página web. Recoge una respuesta HTTP, no navegación posterior por JavaScript. El manual de curl documenta HEAD y las opciones de salida.
En la red del navegador identifica la respuesta o script que cambia la ubicación. Un 301 o 302 apunta a servidor, PHP o CDN; si la página carga primero, puede intervenir JavaScript, un iframe o una notificación.
Comparación local original: método y condición de visita
En un ensayo HTTP inocuo del 25 de octubre de 2026 registramos seis peticiones a un servidor accesible solo desde el ordenador local. Cuatro ilustran por qué una respuesta aparentemente normal no basta como control:
Misma URL de prueba: HEAD → 200; GET → 302
Ejemplo de visitante: GET de control directo → 200
Ejemplo de visitante: GET con condición ficticia → 302
Destinos de redirección visitados: 0La condición era una cabecera de formación inventada, no una sesión real de administrador, móvil, entrada desde Google ni petición de su rastreador. El ejemplo produjo respuestas distintas a propósito. Demuestra cómo comparar; no reproduce una infección ni identifica por qué redirige una web real. No ejecutamos JavaScript ni archivos descargados.
En una incidencia, conserva una observación de control y otra afectada para la misma URL pública. Anota método, hora, estado de sesión, origen de entrada, clase de dispositivo, primer estado de respuesta, capa que la sirvió y si hubo navegación posterior. Cambia una condición cada vez y mantén emparejadas las observaciones. Un hash distinto puede deberse a contenido dinámico legítimo; compara la evidencia relevante de redirección o script.
Captura la primera respuesta antes de seguir la cadena. Guarda un destino sospechoso como evidencia en lugar de abrirlo. Una respuesta HTTP limpia deja sin probar el comportamiento activado por JavaScript. Pide que el analista señale la capa observada y lo que sigue pendiente.
Cambiar la etiqueta de agente de usuario no autentica a un rastreador de Google. Su documentación de verificación de peticiones explica cómo comprobar la IP solicitante. Distingue una prueba sintética de un registro de acceso verificado. Para URL inesperadas en búsqueda, la guía de páginas de spam sin entrada en WordPress separa respuesta actual e historial indexado.
Observación HTTP pública: cuatro peticiones controladas
El 24 de octubre de 2026 a las 22:40 UTC recogimos cuatro respuestas GET de la versión inglesa de esta guía: cabeceras de escritorio con entrada directa, las mismas con referrer de búsqueda sintético, cabeceras de móvil y repetición de móvil sin cookies. Las cuatro devolvieron HTTP 200, sin cabecera Location y con cuerpos idénticos al recogerlos.
Es una observación fechada de nuestra URL editorial, no de un cliente infectado. Las etiquetas describen cabeceras, no dispositivos físicos ni una visita real desde Google. No probamos sesión de administrador, ejecutamos JavaScript ni verificamos un rastreador de Google. El resultado cubre solo la respuesta HTTP inicial; no demuestra ausencia de redirección en el navegador o infección en otras partes.
Compara el HTML público y administrativo
Guarda la respuesta HTML inicial de un visitante limpio y compárala con la vista conectada. Busca dominios de scripts desconocidos, bloques codificados, iframes y código antes del cierre de body.
No pegues el código en un decodificador online: puede contener rutas, secretos o un payload activo. Trabaja con una copia desconectada.
Si el HTML está limpio pero existe redirección, revisa respuestas JavaScript externas, service workers y contenido almacenado por la CDN.
Revisa WordPress y el hosting
Inspecciona archivos modificados recientemente, plugins activos y mu-plugins, tema, wp-config.php, index.php raíz y .htaccess. Busca scripts inyectados en entradas, widgets y opciones de la base.
Comprueba también:
- administradores y contraseñas de aplicación inesperados;
- cron de WordPress y servidor;
- redirecciones del panel de hosting;
- DNS y reglas de Cloudflare;
- webs vecinas en la misma cuenta.
El primer archivo sospechoso rara vez demuestra todo el alcance.
Contén sin destruir evidencias
Si los visitantes afrontan una estafa o descarga, publica mantenimiento controlado o restringe acceso conservando archivos y logs. Crea una copia de sistema y base con sus fechas.
Una sustitución masiva cambia timestamps y dificulta la investigación. Restaurar antes de conocer la entrada puede recuperar código vulnerable o borrar pruebas. Coordina con el hosting si hay varias webs o riesgo de suspensión.
Verifica con el desencadenante original
Después de eliminar código confirmado y cerrar la entrada, repite las mismas pruebas de referrer, dispositivo y cookies limpias. Revisa HTML público, peticiones externas, usuarios, tareas y cambios de archivos.
Purga la CDN solo después de limpiar el origen. Monitoriza redirecciones e integridad para detectar recurrencias.
Cuándo pedir una limpieza urgente
Solicita ayuda cuando la redirección sea selectiva, descargue archivos, afecte varias webs o regrese tras borrarla. Envía URLs públicas, horas y capturas, nunca contraseñas ni adjuntos maliciosos.
Una limpieza responsable conserva evidencia, localiza persistencia, retira el payload, cierra la vía y demuestra que la condición original ya no se activa.
Prepara la evaluación y la prueba de cierre
Envía URL pública, dispositivo/navegador, hora aproximada, origen de entrada y primera visita o repetición. Incluye destino como texto y captura sin datos privados si la tienes. Solicita una evaluación de redirecciones sin contraseñas ni archivos sospechosos.
Pide que la propuesta identifique capas afectadas, copia de recuperación, intervención prevista, pruebas repetibles y responsable de seguimiento. Compara visitas afectadas con controles directos y del administrador. El proceso de evaluación separa diagnóstico de cambios aprobados.