Has limpiado WordPress, cambiado contraseñas y eliminado el malware. La web vuelve a cargar con normalidad.
Pero buscas tu dominio en Google y siguen apareciendo páginas que nunca creaste: productos falsos, contenido en otros idiomas, casinos, medicamentos, directorios extraños o cientos —incluso miles— de URLs sin relación con tu negocio.
En Search Console quizá continúen apareciendo URLs fraudulentas. Algunas páginas importantes de tu web pueden haber perdido posiciones o haber desaparecido de Google. Y llega una duda razonable: si el malware ya no está, ¿por qué el problema SEO continúa?
Porque limpiar WordPress y limpiar el índice de Google son dos procesos diferentes.
La recuperación debería seguir este orden:
primero asegurarte de que la infección ha terminado; después conseguir que las URLs fraudulentas dejen de existir correctamente; y por último ayudar a Google a volver a entender la versión legítima de tu web.
Intentar acelerar el último paso cuando el primero todavía no está resuelto suele acabar en más confusión.
Que una URL fraudulenta siga apareciendo en Google no significa necesariamente que la infección continúe.
Google puede conservar durante un tiempo información obtenida en rastreos anteriores. Por eso hay que distinguir entre dos situaciones muy diferentes:
| Lo que ocurre al abrir una URL de spam | Qué significa |
|---|---|
| Devuelve la página fraudulenta | El contenido sigue accesible y el incidente no está resuelto |
| Redirige a otra página extraña | Puede quedar una redirección maliciosa o una configuración comprometida |
| Devuelve una página aparentemente normal con código HTTP 200 | Hay que investigar un posible soft 404 o contenido generado dinámicamente |
| Devuelve correctamente 404 o 410 | La URL ya no existe; Google puede necesitar tiempo para actualizar su índice |
| Google la muestra, pero la URL ya devuelve 404/410 | Probablemente estás viendo información residual del índice, no necesariamente una infección activa |
Esta comprobación es fundamental.
Si las URLs de spam todavía cargan, reaparecen después de eliminarlas o muestran contenido diferente dependiendo del dispositivo o del visitante, no estás todavía ante un problema exclusivamente SEO.
Antes habría que revisar la infección.
Para esa fase ya tienes contenidos específicos en arreglotuweb.com: cómo saber si un WordPress ha sido hackeado y cómo eliminar malware en WordPress sin romper la web.
También conviene investigar cómo se produjo el compromiso. Limpiar archivos maliciosos no demuestra que se haya cerrado la vía de entrada. En WordPress hackeado aunque estaba actualizado: qué comprobar explicamos por qué encontrar el malware y determinar cómo consiguió entrar son problemas distintos.
No empieces a hacer cambios masivos en Search Console mientras la web siga generando nuevas URLs fraudulentas.
Después del incidente conviene entrar en Google Search Console, pero no limitarse a mirar una sola pantalla.
Hay varios informes que responden a preguntas diferentes.
El informe Problemas de seguridad muestra indicios que Google ha detectado relacionados con una web comprometida, malware, phishing u otros comportamientos peligrosos.
Si aparece un problema, corrígelo completamente antes de solicitar una revisión. Google indica que la revisión de seguridad puede tardar desde varios días hasta algunas semanas.
Que este informe esté limpio es una buena señal, pero no debería interpretarse como un certificado forense de que no queda absolutamente nada en el servidor.
Search Console muestra lo que Google ha detectado.
La integridad de WordPress debe comprobarse también desde WordPress, el hosting, los archivos, la base de datos, los usuarios y los registros disponibles.
El informe Acciones manuales es distinto.
Una acción manual significa que un revisor de Google ha determinado que parte del sitio incumple sus políticas de spam. Una web afectada puede perder posiciones o dejar de aparecer total o parcialmente en los resultados.
Si existe una acción manual, primero hay que corregir todos los problemas afectados y después enviar la solicitud de reconsideración desde el propio informe.
Si el informe no muestra ninguna acción manual, no necesitas enviar una reconsideración “por si acaso”.
Aquí es donde probablemente encontrarás buena parte del ruido dejado por la infección.
Pueden aparecer URLs con estados como “No se ha encontrado (404)”, redirecciones, páginas rastreadas y no indexadas u otros motivos de exclusión.
Una cantidad enorme de 404 procedentes de URLs fraudulentas puede resultar alarmante, pero un 404 correcto para una página que no debería existir no es un error que tengas que reparar.
Google explica expresamente que los 404 no perjudican por sí mismos al rendimiento de búsqueda cuando corresponden a URLs que no deberían existir.
Lo importante no es conseguir que Search Console quede visualmente “sin errores”.
Lo importante es que cada URL responda como debería.
Esta es una de las decisiones que más dudas provoca y, en la práctica, no debería convertirse en una obsesión.
Si una URL fue creada fraudulentamente, ya no contiene nada legítimo y no existe una página equivalente a la que trasladarla, puede devolver:
404 — Not Found
o
410 — Gone
Google indica que trata el 410 de la misma manera que el 404 a estos efectos.
Por tanto, no necesitas convertir decenas de miles de URLs 404 en 410 esperando una ventaja SEO extraordinaria.
Lo fundamental es que hayan desaparecido realmente.
Una URL fraudulenta que ya no existe debería dejar de responder con un 200.
Y tampoco necesita una redirección simplemente para evitar un 404.
Después de descubrir miles de URLs falsas es tentador pensar:
“Ya que Google conoce estas páginas, voy a redirigirlas todas hacia la home para aprovechar algo de su autoridad”.
Normalmente no es la solución correcta.
Una redirección permanente tiene sentido cuando un contenido legítimo se ha trasladado a otra URL que realmente lo sustituye. Google recomienda las redirecciones permanentes cuando una página ha cambiado de ubicación o existe un destino adecuado.
Una página inventada por un atacante sobre casinos no se ha “mudado” a la página principal de una empresa de fontanería.
Nunca debería haber existido.
En ese caso, la respuesta lógica es 404 o 410.
Además, Google advierte de que enviar páginas inexistentes hacia otra URL irrelevante, como la página principal, puede terminar siendo interpretado como un soft 404.
La excepción sería que entre las URLs modificadas hubiese páginas legítimas antiguas que realmente hayan cambiado de dirección. Esas sí deberían estudiarse individualmente y, cuando exista un sustituto equivalente, redirigirse hacia él.
La regla práctica es sencilla:
contenido legítimo trasladado → redirección adecuada.
URL inventada por el atacante → desaparece con 404/410.
No.
Cuando el ataque ha creado cantidades masivas de URLs, el problema debe abordarse por patrones, no intentando editar manualmente cada dirección.
Puede que todas las URLs fraudulentas compartan un directorio, una estructura determinada, ciertos parámetros o alguna otra característica.
Si se puede identificar con seguridad ese patrón, la aplicación o el servidor deberían conseguir que todas esas direcciones dejen de generar contenido y respondan correctamente como inexistentes.
Precaución: una regla demasiado amplia puede hacer desaparecer páginas legítimas. Antes de modificar reglas de servidor, redirecciones, .htaccess, configuración de nginx, WordPress o plugins, realiza una copia adecuada y comprueba exactamente qué URLs se verán afectadas.
Si no tienes una política de recuperación probada, merece la pena resolver primero esa parte. Puedes consultar cómo saber si tus copias de seguridad de WordPress funcionan realmente.
Cuando hablamos de cientos de miles de URLs, el objetivo no es proporcionar a Google una lista manual de cientos de miles de eliminaciones.
El objetivo es conseguir que, cuando Google vuelva a cualquiera de ellas, el servidor le dé la respuesta correcta.
A veces.
Pero hay que entender para qué sirve.
La herramienta Retiradas permite ocultar temporalmente una URL de los resultados de Google. Google indica actualmente que una retirada temporal dura aproximadamente seis meses.
No elimina la página de Internet ni constituye por sí sola una eliminación permanente.
Puede ser útil cuando necesitas que determinadas URLs desaparezcan de los resultados con rapidez, por ejemplo porque todavía muestran fragmentos especialmente perjudiciales para la empresa.
Pero si esas URLs ya devuelven correctamente 404 o 410 y no existe una urgencia concreta, Google indica que normalmente no es necesario solicitar manualmente la retirada de páginas obsoletas: las volverá a rastrear y desaparecerán de forma natural.
La herramienta permite también trabajar con prefijos.
Eso puede resultar práctico si toda la infección se concentró, por ejemplo, en una ruta exclusivamente fraudulenta.
Pero comprueba muy bien el prefijo antes de utilizar esta opción. Un prefijo demasiado amplio podría ocultar también resultados legítimos.
Y recuerda siempre la diferencia:
Retiradas acelera la ocultación temporal.
404/410, eliminación del contenido, protección mediante autenticación o noindex cuando corresponda son los mecanismos que resuelven el estado permanente.
Porque Google no consulta cada página de Internet en tiempo real antes de mostrar un resultado.
El índice refleja información obtenida previamente.
Puedes haber eliminado hoy una URL que Google rastreó cuando todavía estaba comprometida. Hasta que el buscador procese de nuevo ese cambio, puede existir una diferencia entre lo que está publicado ahora mismo y lo que Google conserva de un rastreo anterior.
El propio informe de inspección de URLs distingue entre la versión indexada y una prueba en tiempo real precisamente por esta razón.
También es normal que Google continúe intentando rastrear durante un tiempo URLs que ahora devuelven 404, aunque vaya reduciendo progresivamente esa frecuencia.
No hay un plazo universal que permita decir: “todas las URLs desaparecerán en siete días”.
Dependerá, entre otras cosas, de cuándo las vuelva a rastrear Google y de la magnitud del incidente.
Por eso el mejor indicador no es comprobar compulsivamente cuántos resultados quedan cada mañana.
Es comprobar que las URLs ya devuelven consistentemente la respuesta correcta y no aparecen nuevas familias de spam.
Parece intuitivo:
“Si estas URLs son malas, las bloqueo en robots.txt”.
Pero puedes conseguir justo lo contrario de lo que buscas.
Para confirmar que una URL desaparecida devuelve 404 o 410, Google necesita poder rastrearla.
Y si utilizas una directiva noindex, Google también necesita acceder a la página para poder leerla. La documentación de Google explica expresamente que las reglas de indexación no pueden descubrirse si el rastreo está bloqueado mediante robots.txt.
Para URLs fraudulentas que ya no deberían existir, normalmente es más limpio permitir que Google las solicite y reciba su 404/410.
robots.txt controla el rastreo.
No es una herramienta para borrar de Google páginas ya conocidas.
noindex tiene su lugar, pero no es la solución habitual para una URL fabricada por malware que ya has eliminado.
Si una página legítima debe seguir existiendo para los usuarios pero no quieres que aparezca en Google, noindex puede ser apropiado.
Pero una página de spam inyectada no necesita seguir existiendo.
En ese caso suele tener más sentido retirarla y devolver 404/410.
Mantener miles de páginas fraudulentas con respuesta 200 únicamente para colocarles un noindex complica innecesariamente la recuperación.
No lo utilizaría como estrategia general de recuperación.
Google recomienda incluir en los sitemaps las URLs que quieres que aparezcan en los resultados, normalmente sus versiones canónicas.
Una vez limpia la infección, el sitemap principal debería volver a representar la web real:
las páginas, entradas, productos, categorías u otros contenidos legítimos que quieres que Google descubra e indexe.
Las URLs fraudulentas no pertenecen ahí.
Después de un hackeo sí merece la pena revisar el sitemap porque el propio ataque puede haberlo modificado, haber creado archivos sitemap adicionales o haber conseguido que el generador incluya contenidos que no deberían existir.
Comprueba también en Search Console qué sitemaps hay enviados.
Si encuentras uno que no reconoces, no te limites a borrarlo de Search Console: averigua primero quién o qué lo estaba generando.
Eso puede revelar que todavía queda algún mecanismo del ataque funcionando.
Una infección de SEO spam no siempre consiste en crear nuevas URLs visibles.
También puede modificar señales que los propietarios rara vez inspeccionan.
Google documenta, por ejemplo, ataques que introducen redirecciones o incluso etiquetas rel="canonical" hacia dominios maliciosos, lo que puede alterar qué URL interpreta Google como principal.
Después de limpiar el sitio conviene comprobar especialmente las páginas que antes posicionaban bien.
La URL Inspection de Search Console permite ver, entre otras cosas, si Google puede rastrear e indexar la página y qué canónica ha seleccionado.
Si una página importante ha desaparecido de los resultados, no presupongas inmediatamente que Google “ha penalizado el dominio”.
Puede existir un problema técnico concreto:
una directiva noindex que no debería estar, un bloqueo de rastreo, una canónica incorrecta, una redirección residual, un error del servidor o una modificación introducida durante la propia limpieza.
Aquí conviene abandonar el análisis masivo y estudiar páginas concretas.
Empieza por las URLs comercialmente importantes: la home, servicios principales, categorías, productos que generan negocio y contenidos que antes recibían tráfico.
Inspecciona cada una en Search Console.
La herramienta permite comparar la información que Google tiene indexada con una prueba de la URL publicada, comprobar rastreo, indexabilidad y canonicalización, y solicitar indexación cuando proceda.
Una página legítima debería cumplir, al menos, estas condiciones:
| Comprobación | Resultado esperado |
|---|---|
| Código HTTP | 200 |
| Robots.txt | No impide a Google rastrear la página |
| Meta robots / X-Robots-Tag | No contiene noindex por error |
| Canonical | Apunta a la versión correcta |
| Redirección | No existe una redirección inesperada |
| Sitemap | La URL canónica legítima está incluida |
| Contenido | Corresponde a la página real y no contiene restos del ataque |
| Search Console | Sin acción manual o problema de seguridad pendiente relacionado |
Si has corregido una página importante, puedes solicitar su indexación.
Pero la herramienta tiene límites diarios y Google deja claro que solicitar una indexación no garantiza que la página vuelva al índice. Para muchas URLs, el mecanismo apropiado es mantener un sitemap limpio y actualizado.
No intentes solicitar manualmente la indexación de todo el sitio.
Empieza por las páginas que realmente importan al negocio.
Puede recuperarlas, pero nadie debería garantizar que volverá exactamente al mismo punto ni fijar una fecha.
Hay varios escenarios posibles.
Si el daño se detectó pronto, las páginas legítimas no cambiaron de forma sustancial y Google vuelve a rastrear una web limpia y técnicamente correcta, muchas de las señales necesarias para recuperar visibilidad siguen existiendo.
Pero un incidente prolongado puede producir más consecuencias: páginas legítimas desindexadas, cambios de canonical, enlaces internos manipulados, servidor inestable, contenido sustituido, advertencias de seguridad o una acción manual.
Y mientras dura el incidente el resto de Internet tampoco permanece congelado. Los competidores pueden cambiar y los resultados de búsqueda evolucionan.
Por tanto, una recuperación SEO seria no consiste en esperar a que “Google perdone la web”.
Consiste en eliminar las causas técnicas que impiden que Google vuelva a rastrear, interpretar e indexar correctamente el contenido legítimo.
El informe de rendimiento de Search Console resulta mucho más útil para evaluar esta recuperación que comprobar unas pocas búsquedas manualmente.
Compara impresiones, clics y consultas de las páginas importantes antes, durante y después del incidente.
Busca una tendencia.
No una posición aislada un martes por la mañana.
En la mayoría de los incidentes de este tipo, cambiar de dominio no debería ser la primera respuesta.
Un dominio nuevo no elimina una puerta trasera, no corrige un plugin vulnerable, no repara unas credenciales comprometidas y no limpia una base de datos infectada.
Si trasladaras la misma instalación comprometida al dominio nuevo, trasladarías también el problema.
Además, un cambio de dominio es una migración SEO en toda regla. Google dispone de procedimientos específicos para los cambios de URL y advierte de problemas que pueden producirse durante estas migraciones, incluidos bloqueos por robots/noindex y redirecciones incorrectas.
Por tanto, no cambiaría un dominio empresarial consolidado solamente porque Google haya llegado a indexar spam generado durante un hackeo.
Primero intentaría recuperar correctamente el dominio existente.
Cambiarlo podría tener sentido si existen otras razones empresariales o técnicas independientes para hacerlo, pero debería tratarse como una decisión de migración, no como un botón de “reset SEO”.
Una web puede parecer limpia y seguir existiendo una causa de reinfección.
Puede quedar un usuario desconocido, una credencial comprometida, una tarea programada, un componente vulnerable o alguna otra persistencia.
Por eso la recuperación SEO debería comenzar solo después de una recuperación de seguridad razonablemente verificada.
En cómo recuperar y reforzar un WordPress después de un hackeo explicamos esa fase posterior de cierre de accesos y prevención de reinfecciones.
La relación entre ambos trabajos es directa:
si hoy consigues eliminar 50.000 URLs de Google pero mañana el atacante genera otras 50.000, no tienes un problema de Search Console.
Sigues teniendo un problema de seguridad.
Durante la recuperación merece la pena seguir un pequeño conjunto de indicadores de forma constante, en lugar de perseguir cada 404 individual.
Para una empresa, esta vigilancia no debería depender de acordarse de entrar de vez en cuando al panel. En Seguridad WordPress para empresas: 10 decisiones clave explicamos cómo convertir seguridad, accesos, actualizaciones, copias y respuesta ante incidentes en responsabilidades concretas.
Después de un ataque es fácil caer en una trampa psicológica: pensar que la recuperación terminará cuando Search Console deje de mostrar miles de URLs excluidas.
No funciona así.
Search Console conserva información histórica y Google puede seguir rastreando durante un tiempo URLs que ya no existen.
Un 404 correcto no es una mancha que haya que ocultar.
Es, muchas veces, exactamente la respuesta que debería recibir Google.
La recuperación está realmente encaminada cuando ocurren otras cosas:
las URLs fraudulentas ya no sirven contenido;
no se generan nuevas;
las páginas legítimas vuelven a ser rastreables e indexables;
el sitemap representa únicamente la web real;
canonical, robots y redirecciones son correctos;
no existen problemas de seguridad ni acciones manuales pendientes;
y el rendimiento de las páginas importantes empieza a estabilizarse.
Ese es el punto en el que una infección deja de ser una emergencia y pasa a convertirse en un proceso de recuperación controlado.
No empezaría borrando resultados uno a uno.
Primero confirmaría que WordPress está realmente limpio y que se ha cerrado la vía de entrada.
Después tomaría varias muestras de URLs fraudulentas y comprobaría su respuesta actual.
Si todavía devuelven contenido o un 200, corregiría el origen.
Si devuelven 404/410 de forma consistente, dejaría que Google pueda rastrearlas.
Revisaría Problemas de seguridad y Acciones manuales en Search Console.
Regeneraría y comprobaría el sitemap para asegurarme de que solo contiene URLs legítimas.
Inspeccionaría las páginas comerciales más importantes y corregiría cualquier noindex, canonical, redirección o problema de rastreo introducido durante el ataque o la limpieza.
Utilizaría Retiradas solamente cuando necesite ocultar con urgencia determinados resultados, entendiendo que es una medida temporal.
Y después monitorizaría.
Sin redirecciones masivas hacia la home.
Sin bloquear en robots.txt las URLs que Google necesita volver a comprobar.
Sin crear un sitemap lleno de páginas hackeadas.
Sin abandonar precipitadamente un dominio que todavía puede recuperarse.
La parte más frustrante de un hackeo de SEO spam es que la web puede estar limpia antes que Google.
Eso no significa necesariamente que la limpieza haya fallado.
Significa que ahora toca conseguir que el buscador vuelva a ver, poco a poco, la web que realmente existe.
