Quien llega desde búsqueda es redirigido mientras la visita directa funciona. Un .htaccess infectado puede comprobar referrer, agente, ruta o cookie antes de enviar tráfico seleccionado.
También contiene permalinks, HTTPS, seguridad y caché legítimos. Consérvalo y anótalo antes de sustituirlo.
Captura el archivo y el desencadenante
Copia .htaccess con metadatos y hash. Registra URL, referrer, agente, hora y destino.
Busca otros .htaccess en directorios padre y carpetas anidadas de uploads o caché. Apache aplica reglas a lo largo de la ruta.
No abras el destino malicioso; consérvalo como texto.
Lee las condiciones como un grupo
Las reglas dependen de sus condiciones anteriores. Busca HTTP_REFERER, HTTP_USER_AGENT, parámetros, cookies y dominios desconocidos.
No pegues o publiques reglas maliciosas para probarlas. Analiza sin conexión y contrasta con los requisitos de la web.
Cadenas codificadas, líneas extensas y reglas anteriores a los marcadores de WordPress merecen revisión, no borrado automático.
Documenta para cada RewriteCond si se combina con AND u OR y qué regla gobierna. Leer una condición aislada puede llevar a borrar una excepción legítima o pasar por alto que el destino solo se activa con varias señales simultáneas.
Compara con la referencia legítima
Obtén una versión fiable desde despliegues o copias. El bloque estándar es corto, pero hosting, caché y seguridad añaden secciones válidas.
Asigna propietario a cada bloque no estándar. Los marcadores generados suelen identificar el plugin.
No dejes solo el bloque genérico si existen idiomas, rutas protegidas o caché del servidor.
Prueba la configuración antes
Usa el comprobador del hosting o staging. Un error de sintaxis puede devolver 500 en toda la web.
Aplica el archivo limpio de forma controlada con reversión inmediata. Corrige propietario y permisos sin hacerlo escribible por todos.
En Nginx puro puede ignorarse; revisa servidor, CDN y PHP.
Prueba en staging URLs existentes, inexistentes, assets, administración y variantes con barra final. Verifica bucles, códigos y cabecera Location. Una regla limpia que corrige el malware pero rompe REST, webhooks o archivos estáticos todavía no es aceptable.
Encuentra el proceso que lo reescribe
Si vuelve, relaciona la hora con peticiones, cron, ajustes de plugins, SFTP y panel. Busca el dominio y escrituras a .htaccess en la copia.
Inspecciona PHP raíz, puertas traseras, mu-plugins, uploads y webs vecinas. Un plugin de caché puede reescribir secciones legítimas al guardar, así que diferencia su salida.
Una auditoría estrecha puede capturar al escritor en un VPS autorizado.
Revisa CDN y hosting
Redirect Rules, Workers de Cloudflare, panel y DNS pueden reproducir el síntoma con .htaccess limpio.
Exporta configuraciones y revisa usuarios y sesiones. No borres reglas antes de conservar evidencia.
Prueba origen y ruta pública por separado con métodos autorizados.
Inspecciona también configuración heredada sobre la raíz. Un .htaccess padre o include del virtual host puede afectar varios directorios y ser invisible para WordPress.
Pide al proveedor que preserve esas capas si no tienes acceso. No intentes compensar una regla padre desconocida con directivas cada vez más complejas.
Compara el resultado mediante una petición autorizada con y sin referrer de búsqueda, sin seguir el destino. Registra el primer código y Location; seguir toda la cadena podría llevar la prueba hasta infraestructura dañina y ocultar qué capa originó el salto.
Verifica recorridos directos y de búsqueda
Tras limpiar y cerrar la entrada, prueba visita directa y desde búsqueda aislada, móvil y escritorio. Confirma que canonical y HTTPS legítimos siguen funcionando.
Monitoriza el hash durante guardados de plugins y tareas. Busca en logs peticiones que sigan el patrón anterior.
Repite después de guardar permalinks y de una purga normal de caché, porque WordPress o un plugin pueden regenerar el archivo. La referencia final debe incluir las secciones legítimas que el sistema vuelve a escribir.
Cuándo pedir ayuda especializada
Solicita ayuda si las reglas vuelven, intervienen varios niveles o el hosting y CDN también redirigen. Envía dominio y condiciones censuradas como texto, no accesos.
La reparación debe preservar rutas válidas, eliminar la redirección selectiva e identificar quién puede modificar la configuración.