Has limpiado WordPress, eliminado archivos o usuarios sospechosos, actualizado los componentes vulnerables y aparentemente la web vuelve a estar bajo control. Sin embargo, buscas tu dominio en Google o entras en Search Console y siguen apareciendo cientos o miles de URLs que nunca creaste: páginas de productos falsos, contenido en otros idiomas, apuestas, medicamentos, directorios extraños o combinaciones interminables de palabras.
La primera duda es inevitable: ¿significa que la web sigue hackeada?
No necesariamente.
Después de un ataque que ha generado páginas spam hay que separar tres cosas distintas:
Que una URL spam siga apareciendo en Google no demuestra por sí solo que el malware continúe activo. Pero tampoco deberías dar la recuperación por terminada únicamente porque la portada y el panel de WordPress parezcan normales.
El objetivo ahora es comprobar que el ataque realmente ha terminado y que Google encuentra el estado correcto cuando vuelve a visitar esas URLs.
Antes de pensar en desindexar nada, verifica que WordPress ya no esté generando páginas nuevas.
Si las URLs fraudulentas siguen apareciendo, cambian de patrón o aumentan con el tiempo, el problema principal no es Google. Hay que volver al diagnóstico de seguridad.
Una limpieza correcta no consiste únicamente en borrar el contenido visible. También hay que investigar cómo se produjo el acceso, revisar credenciales y usuarios, eliminar componentes comprometidos y cerrar la vía que permitió la intrusión.
Si todavía estás en esa fase, empieza por cómo eliminar malware de WordPress sin romper la web.
Y si ya habías limpiado la instalación pero el contenido malicioso vuelve a aparecer, consulta por qué un WordPress puede volver a infectarse aunque esté actualizado. Borrar los síntomas sin corregir el acceso utilizado por el atacante puede dejar el incidente abierto.
En Google Search Console revisa al menos:
Google utiliza el informe de Problemas de seguridad para avisar de situaciones como contenido inyectado, malware o páginas comprometidas. Los ejemplos de URLs que aparecen en ese informe pueden ser solo una muestra; que no aparezca cada página afectada no significa que el resto no exista.
Si Google muestra un problema de seguridad y ya has corregido completamente la causa, puedes solicitar una revisión desde ese mismo informe. Google recomienda hacerlo cuando hayas solucionado el problema en todo el sitio, no solo en las URLs que utiliza como ejemplo.
No confundas ese informe con Acciones manuales. Una acción manual está relacionada con incumplimientos de las políticas de spam de Google; el informe de seguridad señala problemas como hackeos, phishing o software malicioso. Son situaciones diferentes y pueden requerir procesos diferentes.
Este punto explica buena parte de la confusión después de una infección.
Durante el ataque, Google pudo rastrear una URL como:
https://tudominio.com/producto-falso-12345
y añadirla a su índice.
Después limpias WordPress y esa página desaparece del servidor.
Aun así, durante un tiempo Google puede conservar información obtenida anteriormente. Para descubrir que la página ya no existe necesita volver a procesar esa URL.
Por eso puedes encontrarte con una situación aparentemente contradictoria:
Eso puede formar parte del proceso normal de actualización del índice. Lo importante es comprobar qué recibe Google ahora, no solo lo que todavía muestra de una visita anterior.
Toma varias URLs representativas del ataque y compruébalas individualmente.
Puedes utilizar la herramienta Inspección de URLs de Search Console para consultar información sobre una URL y probar su versión publicada. Search Console permite analizar problemas de indexación a nivel de página y comprobar qué obtiene Google al acceder a ella.
No necesitas revisar manualmente 50.000 direcciones. Lo útil es identificar los patrones generados durante el ataque y comprobar muestras suficientes para entender qué está ocurriendo.
Aquí pueden aparecer varios escenarios.
Si la página fraudulenta ya no existe y no tiene una sustituta legítima, esta es una respuesta correcta.
Google recomienda devolver 404 (Not Found) o 410 (Gone) cuando una página se ha eliminado y no existe otra equivalente que deba reemplazarla. Ambos códigos indican que el contenido ya no está disponible y permiten que los buscadores procesen su desaparición.
No necesitas convertir cada página hackeada en una página real.
Tampoco deberías alarmarte porque Search Console empiece a mostrar muchas URLs como «No encontrada (404)» después de una limpieza. Si corresponden precisamente a las páginas fraudulentas que has eliminado, ese 404 puede ser el resultado esperado.
Lo importante es distinguir esos errores de URLs legítimas que sí deberían existir.
Esto requiere más atención.
Un código 200 OK significa que el servidor está entregando una página como válida.
Puede ocurrir, por ejemplo, que hayas eliminado el contenido spam pero WordPress, el tema o algún sistema de rutas genere una página vacía con respuesta 200. Google puede interpretar algunas de estas situaciones como soft 404, pero no conviene depender de ello.
Si una URL ya no existe, el servidor debería comunicarlo correctamente mediante un 404 o 410. Google advierte expresamente contra devolver una respuesta 200 para contenido que en realidad representa un error.
No conviertas automáticamente miles de URLs creadas por el atacante en redirecciones hacia la home.
Una redirección permanente 301 tiene sentido cuando una página se ha trasladado y existe una sustituta clara. Google recomienda precisamente el 301 en ese escenario.
Una URL fraudulenta sobre un producto que nunca vendiste no se ha trasladado a tu página principal. Simplemente ha desaparecido.
Crear redirecciones indiscriminadas puede ocultar el estado real de las URLs y generar una estructura que no tiene ninguna utilidad para visitantes ni buscadores.
Reserva las redirecciones para situaciones en las que exista una correspondencia real entre la dirección antigua y el contenido legítimo que la reemplaza.
Para este problema, la decisión suele ser menos trascendental de lo que parece.
Google acepta tanto 404 como 410 cuando una página ya no existe y no tiene sustituta.
Por tanto, no merece la pena complicar una recuperación de seguridad intentando convertir decenas de miles de direcciones en respuestas 410 únicamente porque alguien afirme que Google las eliminará de inmediato.
Lo verdaderamente importante es:
Si tu configuración ya devuelve correctamente un 404 para las páginas que no existen, normalmente tienes una base válida sobre la que trabajar.
La herramienta Retiradas puede ser útil, pero no sustituye la solución técnica.
Google explica que una retirada temporal oculta una URL de los resultados aproximadamente durante seis meses. No impide que Google siga rastreando la dirección y no elimina por sí misma la causa que permite que la página exista.
Por eso el orden importa.
Primero:
Después puedes valorar una retirada temporal si necesitas que determinadas direcciones dejen de aparecer cuanto antes mientras Google procesa el cambio permanente.
Google describe precisamente la herramienta como una vía rápida de retirada, mientras que la solución permanente debe existir también en el sitio.
No conviertas la recuperación en una tarea manual consistente en enviar una solicitud individual por cada dirección.
Primero identifica cómo fueron generadas.
Por ejemplo, puede haber grupos completos bajo:
/shop/...
/product/...
/tag/...
o patrones con parámetros o cadenas introducidas por el atacante.
La herramienta de retiradas permite actuar sobre URLs y, en determinados casos, sobre direcciones que comparten un prefijo. Pero hacerlo sin analizar antes el patrón puede ocultar también URLs legítimas.
Especialmente en una web empresarial o un ecommerce, una retirada masiva basada únicamente en una coincidencia de texto merece una revisión previa.
Es una reacción comprensible: si existen miles de páginas spam, parece lógico impedir que Google entre en ellas.
Pero para que Google procese que una página eliminada devuelve un 404 o un 410, necesita poder acceder a la URL.
robots.txt controla principalmente el rastreo. No es el mecanismo adecuado para comunicar que una página ha dejado de existir.
Por eso, antes de añadir reglas masivas a robots.txt, comprueba qué quieres conseguir. Bloquear el rastreo puede impedir que Google vea precisamente la respuesta que necesitas que procese.
Después de un ataque conviene comprobar que los sitemaps XML contienen únicamente URLs legítimas.
Una página spam eliminada no debería seguir apareciendo en el sitemap como si formara parte de la web actual.
Revisa:
Si descubres URLs fraudulentas dentro del sitemap, no te limites a borrarlas del XML. Investiga por qué el sistema que genera el sitemap todavía las considera contenido válido.
Puede ser una pista de que quedan entradas, taxonomías, productos, registros o contenido introducido durante el ataque.
Puede ocurrir.
El informe de Problemas de seguridad sirve para mostrar amenazas que Google ha detectado. No es una lista histórica de todas las URLs que alguna vez fueron indexadas.
Del mismo modo, que el informe ya no muestre una incidencia no obliga a que todas las URLs antiguas desaparezcan simultáneamente de los resultados.
Son procesos distintos:
Seguridad resuelta
→ ya no existe el contenido o comportamiento malicioso.
URLs eliminadas correctamente
→ las direcciones antiguas devuelven 404/410 u otra respuesta adecuada.
Índice actualizado
→ Google vuelve a rastrearlas y procesa su nuevo estado.
La segunda y la tercera fases pueden continuar después de haber solucionado la primera.
No confíes en una sola señal.
Combina varias comprobaciones:
Revisa Problemas de seguridad, Acciones manuales, Indexación e Inspección de URLs.
Google recomienda también utilizar Search Console y búsquedas del propio dominio para localizar contenido inesperado que pueda indicar una intrusión.
Una búsqueda como:
site:tudominio.com
puede ayudarte a localizar resultados que no reconoces.
También puedes combinar el dominio con términos característicos del contenido que apareció durante el ataque.
No utilices el número de resultados que muestra una búsqueda site: como un contador exacto de páginas infectadas. Úsalo como herramienta de exploración.
Verifica:
Este es uno de los indicadores más importantes.
Que disminuya lentamente un conjunto de URLs antiguas es muy diferente de descubrir nuevas páginas fraudulentas creadas después de la supuesta limpieza.
Si aparecen direcciones nuevas, vuelve al diagnóstico de seguridad.
Encontrar cuentas con permisos que no reconoces es otra señal que merece investigación. En qué hacer si aparece un administrador desconocido en WordPress explicamos cómo revisarlo sin eliminar pruebas precipitadamente.
No hay un plazo universal que permita decir: «en X días desaparecerán todas».
Google necesita volver a rastrear y procesar las URLs. La velocidad depende, entre otros factores, del sitio y del propio patrón de rastreo.
Por eso resulta más útil comprobar la dirección de la recuperación que esperar una fecha exacta.
Busca señales como:
No conviertas una cifra antigua de Search Console en una prueba de que la limpieza ha fallado.
Eliminar las páginas spam y recuperar el tráfico son dos problemas relacionados, pero no idénticos.
Un descenso de tráfico después de un hackeo puede estar asociado al propio incidente de seguridad, pero también pueden intervenir problemas técnicos, cambios de indexación, acciones manuales, actualizaciones de los sistemas de Google, cambios de demanda u otros factores.
Google recomienda estudiar estas caídas utilizando el informe de Rendimiento y contrastarlo con los informes de indexación, seguridad y acciones manuales.
Por tanto, evita dos conclusiones precipitadas:
«Las URLs spam todavía aparecen, así que por eso no vuelve el tráfico».
Puede existir relación, pero hay que comprobarla.
Y también:
«Ya no hay avisos de seguridad, así que el posicionamiento debería recuperarse automáticamente».
Google no garantiza que una determinada modificación produzca una mejora concreta en resultados de búsqueda.
Una vez estabilizada la seguridad conviene comparar:
Así podrás separar la recuperación de seguridad de un eventual problema SEO que necesite su propio diagnóstico.
Después de una infección con páginas spam, evita estas soluciones rápidas:
Una redirección tiene sentido cuando existe una sustituta real. Para contenido inventado por un atacante, normalmente no existe.
Puede impedir que Google compruebe que las URLs eliminadas ahora devuelven el estado correcto.
Una página que no existe debería comunicarlo también a nivel HTTP.
Ocultar un resultado durante unos meses no elimina malware ni impide que una página vuelva a aparecer.
Antes de actuar individualmente, estudia patrones y corrige el comportamiento del servidor.
La desaparición de una advertencia de seguridad es una señal positiva, pero conviene verificar también URLs, usuarios, archivos, actualizaciones y la causa original del compromiso.
Si acabas de salir de un ataque y quieres revisar esa parte de forma más amplia, consulta cómo recuperar y reforzar un WordPress después de un hackeo.
Si necesitas convertir todo lo anterior en una secuencia de trabajo, utiliza este orden:
1. Confirma que el ataque está cerrado.
No deben seguir apareciendo archivos, usuarios, redirecciones o páginas fraudulentas nuevas.
2. Conserva información suficiente sobre el incidente.
Antes de borrar indiscriminadamente, documenta qué ocurrió y qué componentes estaban afectados.
3. Comprueba varias URLs fraudulentas conocidas.
Las que ya no existen deberían devolver una respuesta coherente, normalmente 404 o 410 si no tienen sustituta.
4. Revisa sitemaps, enlaces internos y canonicals.
No deberían presentar las páginas spam como parte vigente del sitio.
5. Revisa Problemas de seguridad y Acciones manuales.
Si existe una incidencia de seguridad solucionada, sigue el procedimiento de revisión indicado por Google.
6. Utiliza Retiradas solo cuando tenga sentido acelerar la ocultación.
Recuerda que es una medida temporal, no el mecanismo que hace permanente la desaparición.
7. Vigila si Google encuentra URLs nuevas.
Si ocurre, vuelve a investigar la seguridad.
8. Analiza aparte la recuperación del tráfico.
Comprueba las páginas y consultas que han perdido visibilidad en lugar de atribuir cualquier caída exclusivamente al hackeo.
El tiempo que Google tarde en actualizar su índice no debería confundirse con una reinfección.
Sin embargo, hay señales que justifican volver al diagnóstico técnico:
En esas situaciones, intentar «borrar más URLs de Google» no resuelve el problema de fondo.
La prioridad vuelve a ser averiguar qué sigue permitiendo modificar la web.
Si necesitas intervenir una instalación comprometida, la recuperación debe cubrir tanto la limpieza como la causa del acceso y las medidas posteriores. Solo después tiene sentido tratar la indexación residual como un problema independiente.
Una web puede estar técnicamente limpia mientras Google todavía conserva URLs creadas durante la infección.
Y también puede ocurrir lo contrario: que algunas URLs hayan desaparecido de los resultados mientras la instalación continúa comprometida.
Por eso no conviene utilizar una única señal para decidir si el problema está resuelto.
Comprueba por separado:
Seguridad: el atacante ya no controla ni modifica la web.
Servidor: las páginas falsas han desaparecido y las URLs responden correctamente.
Google: el buscador está procesando progresivamente ese nuevo estado.
Cuando las tres piezas están alineadas, las páginas spam dejan de ser un misterio y la recuperación se puede seguir con datos en lugar de probar redirecciones, bloqueos o retiradas al azar.
