PathSentinel Article

Search Console dice «Problemas de seguridad»: cómo leerlo y pedir la revisión

Interpreta el informe de seguridad de Search Console, usa las URLs de ejemplo para encontrar el resto de páginas y redacta una revisión que no te denieguen.

Si en Search Console te ha aparecido el aviso «Problemas de seguridad», Google ha detectado en tu web algo que puede dañar a quien la visita: casi siempre son páginas de spam que tú no creaste, redirecciones a sitios de terceros o código que intenta colar algo en el ordenador del visitante. No es una penalización de posicionamiento: es una alerta de que tu web está comprometida, y mientras dure, Google enseña una pantalla roja a tus visitantes antes de dejarles entrar. Aquí tienes cómo leer el informe, cómo usar las URLs de ejemplo para encontrar todo lo demás y cómo redactar la solicitud de revisión para que no te la rechacen.

Empecemos por lo que más se malinterpreta: el aviso desaparece cuando la web está limpia y tú pides la revisión. No se va solo por esperar. Y si la solicitas con la web todavía infectada, Google la deniega y el siguiente intento tarda más. El orden importa: primero limpiar de verdad, después pedir revisión.

Las categorías del informe y qué significa cada una

El informe de seguridad agrupa lo que ha encontrado en unas pocas categorías. No hace falta que te las sepas de memoria, pero sí conviene entender qué te está diciendo cada una porque cambia dónde tienes que mirar:

  • Contenido pirateado (hacked content): alguien ha metido páginas o texto en tu web sin permiso. Es lo más habitual en un WordPress: aparecen URLs de casino, medicamentos o marcas falsas colgando de tu dominio.
  • Software malicioso (malware): hay archivos o scripts que intentan instalar algo en el equipo del visitante.
  • Ingeniería social / páginas engañosas: tu web (o una parte de ella) imita a otra o pide datos con engaño. A veces es una página de phishing que el atacante ha subido a una carpeta tuya.
  • Descargas peligrosas: hay ficheros descargables que Google considera dañinos.

Si ves más de una categoría a la vez, no te asustes: suele ser la misma intrusión provocando varios síntomas. Lo importante es que todas apuntan a lo mismo: alguien ha entrado. Antes de tocar Search Console, conviene entender el cuadro completo de una web hackeada para no ir arreglando síntomas sueltos.

Las URLs de ejemplo: cómo usarlas para encontrar todo lo demás

Debajo de cada categoría, Google te da una lista de URLs de ejemplo. La palabra clave es ejemplo: no es la lista completa, es una muestra. Si Google te enseña ocho URLs, casi seguro que hay muchas más que no salen ahí.

Esas URLs son tu punto de partida, no tu meta. Fíjate en el patrón:

  • ¿Cuelgan todas de la misma carpeta? Por ejemplo /wp-content/uploads/2024/ o una carpeta con nombre raro que no reconoces.
  • ¿Comparten una estructura? Como /tienda/?p= seguido de nombres de productos falsos, o rutas en un idioma que no es el tuyo.

Con ese patrón, ve a Google y busca site:tudominio.com añadiendo un término del spam (por ejemplo site:tudominio.com casino o el nombre del medicamento que aparezca). Ahí verás cuántas páginas de esas ha indexado Google en total. Compara ese número con las páginas que tú de verdad publicaste. La diferencia es el tamaño real del problema.

Revisa también tu propio sitemap y el listado de archivos por FTP o por el administrador de archivos del hosting, ordenado por fecha de modificación. Las páginas del atacante suelen tener todas la misma fecha, muy concentrada, y esa fecha te dice además cuándo entraron.

Comprobar cada URL con la inspección en vivo

Search Console tiene una herramienta llamada Inspección de URLs (arriba, la barra de búsqueda del panel). Pega ahí una de las URLs de ejemplo y pulsa Probar URL publicada (inspección en vivo). Esto le pide a Google que mire la página ahora mismo, no la versión que tenía guardada.

Esto sirve para dos cosas. Antes de limpiar, te confirma que la página maliciosa sigue viva. Después de limpiar, te confirma que ya no está: si la has borrado bien, la inspección en vivo debería devolver un 404 o un 410, y si la has dejado como página normal, debería mostrar tu contenido legítimo sin rastro del spam.

No pidas la revisión hasta que hayas comprobado varias de las URLs de ejemplo con la inspección en vivo y todas den el resultado limpio. Si una sola sigue mostrando el contenido malicioso, la revisión se cae.

Los errores que hacen que te denieguen la revisión

La mayoría de las revisiones denegadas se explican por unos pocos fallos, y casi todos son de haber ido con prisa:

  • Limpiar solo lo que salía en las URLs de ejemplo. Es el error clásico. Borras esas ocho páginas, pides revisión, y Google encuentra las otras doscientas que no te había enseñado.
  • Ocultar en vez de borrar. Poner un noindex o bloquear con robots.txt no limpia nada: la página maliciosa sigue ahí para quien tenga el enlace, y Google lo nota.
  • No haber cerrado la puerta de entrada. Si limpias el spam pero dejas la puerta trasera que usaron para entrar, la web se vuelve a llenar en días y la revisión que aprobaron hoy se reabre mañana.
  • Restaurar una copia y creer que ya está. A veces la copia también estaba infectada, o la puerta trasera es anterior a la fecha que restauraste.

Qué escribir en la solicitud de revisión

Cuando en el informe todo aparezca corregido, verás un botón de Solicitar revisión. Google te pide que expliques qué ha pasado. No hace falta literatura, pero un texto vacío o defensivo ayuda poco. Un mensaje que funciona dice tres cosas, breves:

  1. Qué encontraste: «Se habían inyectado páginas de spam en el directorio de uploads y un archivo PHP modificado en el tema.»
  2. Qué hiciste: «He eliminado todas las páginas inyectadas, sustituido los archivos del núcleo y del tema por versiones limpias, eliminado dos cuentas de administrador que no reconozco y cambiado todas las contraseñas.»
  3. Cómo evitas que se repita: «He actualizado WordPress y los plugins, activado la verificación en dos pasos y puesto vigilancia de archivos.»

Escríbelo en el idioma del panel, con frases cortas. Estás demostrando que entiendes lo que pasó y que no vas a volver a pedir revisión dentro de una semana.

Plazos: cuánto tarda de verdad y qué pasa mientras tanto

La revisión de un problema de seguridad no es inmediata. Cuenta con días, no con horas, y a veces más de una semana. No la pidas dos veces seguidas: mandar una segunda solicitud mientras la primera está en cola no acelera nada y puede retrasarlo.

Mientras tanto, la web sigue funcionando pero con la pantalla de advertencia delante. Es incómodo, pero no desactives ni borres la propiedad de Search Console para «reiniciar» el estado: perderías el canal por el que Google te va a avisar del resultado. Aprovecha la espera para revisar que de verdad no quede nada sucio; si tienes dudas de si la limpieza fue completa, un chequeo desde fuera te lo confirma antes de pedir la revisión.

Después del visto bueno: recuperar la indexación

Que Google retire el aviso es el final del problema de seguridad, pero no el final del trabajo. Durante los días que estuvo la alerta, tus visitas habrán bajado, y las páginas de spam que Google llegó a indexar todavía pueden aparecer en los resultados un tiempo.

Toca hacer limpieza en los resultados de búsqueda: pedir la retirada de las URLs falsas, dejar que devuelvan 404 o 410, y volver a solicitar la indexación de tus páginas buenas. Ese proceso, con sus plazos y sus atajos, lo tienes detallado en la guía para recuperar el posicionamiento en Google tras un ataque. Y si además del aviso de Search Console te salta la pantalla roja de Chrome, mira cómo quitar el aviso de sitio engañoso, porque va por un canal parecido pero se pide aparte.

Si no tienes claro que la web esté realmente limpia, no arriesgues una denegación: lanza el escáner gratuito de PathScan y comprueba desde fuera que no queda spam indexado ni páginas inyectadas antes de darle al botón de solicitar revisión.