Respuesta breve: tu web sirve código inyectado que envía a parte de las visitas a otro sitio. La redirección suele ser condicional —solo móvil, solo desde buscadores o una vez por visitante—, por eso a menudo no la reproduces desde tu propio ordenador.
Reproduce y registra el disparador primero
Antes de tocar nada, anota qué dispositivo, navegador, país y origen la reproducen, y a dónde te lleva. Pruébalo como visita de Google y en móvil. Esas condiciones localizan la carga y son la única forma de demostrar después que ha desaparecido. No abras repetidamente el destino desde un equipo con sesiones importantes iniciadas.
Busca en cada capa — los sitios exactos
- Base de datos: revisa
wp_optionsporsiteurlyhomemanipulados, y busca en todas las tablas<script>inyectado o el dominio del atacante. - Archivos: por SSH,
grep -RIlE 'eval\s*\(|base64_decode\s*\(|gzinflate\s*\(|str_rot13\s*\(|assert\s*\(|create_function\s*\(' wp-content/saca a la luz código ofuscado. Revisaheader.php,footer.php,functions.phpy cualquier.phpdentro de/wp-content/uploads. - Reglas del servidor:
.htaccesssuele llevar redirecciones condicionales según user-agent u origen. - Código autocargado: un archivo soltado en
/wp-content/mu-pluginsse carga en cada petición y se oculta de la lista de plugins. - Tareas programadas: inspecciona el array de cron (
wp cron event list) por una tarea que reinyecta el código.
Por qué borrar una línea no es una limpieza
La redirección visible suele ser la última fase. Si queda una puerta trasera, o la credencial que usó el atacante sigue siendo válida, vuelve en horas. Una limpieza real compara archivos con copias limpias (reinstalar núcleo y plugins desde su origen), elimina la persistencia, cierra la vía de entrada y rota todas las credenciales: WordPress, base de datos, SFTP y hosting.
Verifica bajo el disparador original
Vuelve a probar con el dispositivo, el origen y la red exactos que la reproducían, con todas las cachés y el CDN vaciados: una redirección puede sobrevivir en una respuesta cacheada tras limpiar el origen. Después vigila varios días, porque la reinfección desde una puerta trasera que se pasó por alto suele volver de forma discreta.
CRITERIO DE INCIDENTE WP REPAIR
Reconstruye el incidente antes de corregirlo
Las redirecciones condicionales de spam son un incidente, no una sola línea mala. Reproducir el disparador, conservar evidencia y encontrar persistencia es necesario antes de verificar la limpieza.
- 1
Anota dispositivo, origen, país, cookies y destino que reproducen la redirección.
- 2
Busca en archivos, base de datos, reglas, mu-plugins y tareas programadas.
- 3
Compara núcleo, plugins y tema con paquetes limpios de origen.
- 4
Identifica el componente vulnerable o credencial que permitió el cambio.
Qué debe quedar verificado
- El disparador condicional original ya no redirige.
- Comparación de archivos y revisión de usuarios, cron y base no muestran persistencia.
- Las credenciales se rotan y la vía de entrada se parchea o elimina.
Fuentes técnicas oficiales
Esta guía explica el diagnóstico. Si la web está afectada ahora, la intervención debe preservar una vía de vuelta y verificar el recorrido real del negocio.
Ver el servicio de reparación urgente →