Los navegadores pueden seguir mostrando una pantalla roja después de eliminar archivos maliciosos. Google necesita volver a rastrear o revisar la web, y una página infectada en caché o una respuesta selectiva todavía puede estar activa.
No envíes solicitudes repetidas antes de demostrar que la web pública está limpia bajo las condiciones originales.
Registra el alcance exacto del aviso
Usa Search Console y la información oficial para propietarios de Safe Browsing para identificar URL y categoría: malware, ingeniería social, software no deseado o descargas dañinas.
Guarda capturas, rutas y fechas. No atravieses el aviso con un navegador normal ni descargues muestras.
Comprueba si afecta a un subdominio concreto o a toda la propiedad.
Prueba cada patrón reportado
Desde un entorno aislado, inspecciona estado, cuerpo, redirecciones y conexiones externas de cada patrón. Compara visita ordinaria, móvil, referencia de buscador y primera visita.
Una portada limpia no corrige una ruta de descarga maliciosa. Prueba muestras de cada directorio y parámetro.
Las URL de payload retiradas deben devolver estados de error precisos, no una portada 200.
Compara origen, caché y navegador
Confirma el origen limpio y después inspecciona variantes de caché del CDN, hosting y página. Purga objetos infectados tras conservar evidencias y eliminar su fuente.
Comprueba service workers y caché del navegador en un perfil nuevo. Un visitante anterior puede conservar un worker, pero esto no sustituye limpiar el origen.
Verifica todos los nodos cuando exista balanceo.
Completa la limpieza subyacente
Reconstruye paquetes de confianza, revisa código propio y limpia scripts, spam, usuarios y cron de la base, además de hosting, DNS y gestor de etiquetas. Corrige la entrada y rota credenciales.
Comprueba cada web y subdominio de la cuenta. Google puede advertir sobre una ruta hermana que el WordPress principal no gestiona.
Monitoriza más allá de los ciclos programados.
Prepara una solicitud concisa
En Search Console describe qué se encontró, cómo entró, componentes limpiados o sustituidos, accesos rotados y cómo se probó el desencadenante original.
Declara honestamente las limitaciones. No afirmes un impacto o punto de entrada exactos cuando los logs no lo demuestran.
Envía la solicitud solo cuando la web y sus variantes en caché estén limpias.
Entiende los tiempos sin adivinar
El rastreo y la revisión pueden variar. Registra hora de envío, propiedad y respuesta en vez de solicitar de nuevo o cambiar la web cada pocas horas.
Mantén DNS, TLS, mantenimiento y respuestas suficientemente estables. Si parte de la web sigue desconectada, permite que Google acceda a una respuesta limpia o de error en las rutas reportadas.
Comprueba certificado y propiedad del dominio por separado; un fallo TLS o subdominio comprometido puede confundirse con la advertencia original.
Mantén la web estable durante la revisión
Evita cambiar repetidamente redirecciones, mantenimiento y estados. Google debe poder rastrear las rutas y ver su respuesta limpia.
No bloquees toda la web en robots.txt, porque puede impedir verificar la retirada.
Mantén un aviso limpio monitorizado si todavía no puede volver la funcionalidad completa.
Verifica después de retirar el aviso
Repite las rutas reportadas, el HTML público y las conexiones externas. Confirma el estado de Search Console y monitoriza nuevos avisos o indicadores.
La retirada recupera reputación, pero no demuestra que toda puerta trasera desapareció. Continúa vigilando archivos, usuarios, cron y cuentas.
Prueba formularios y checkout tras cambios de scripts o credenciales y conserva la referencia y fecha de resolución.
Cuándo conviene ayuda especializada
Solicita ayuda si el aviso vuelve, no se reproducen las URL o Google y el hosting discrepan. Envía URL públicas y capturas, nunca credenciales de Search Console.
Una recuperación responsable produce una web limpia, una solicitud defendible y evidencias de que el payload original no puede regresar.