Cómo detectar y eliminar SEO Spam y malware de una web

Si tu web aparece en Google con títulos en japonés o indonesio, páginas de casinos, medicamentos o productos que nunca publicaste, probablemente no estés ante un simple error de SEO. Es posible que el sitio haya sido comprometido y esté siendo utilizado para una campaña de SEO Spam.

Lo más engañoso es que la página puede seguir viéndose normal cuando entrás de forma directa. El atacante no siempre quiere destruirla: muchas veces necesita conservar su autoridad, antigüedad y tráfico para posicionar contenido ajeno, crear páginas falsas o redirigir visitas hacia otro dominio.

Qué es el SEO Spam

El SEO Spam, también llamado spamdexing malicioso o malware SEO, ocurre cuando un tercero coloca sin autorización contenido, enlaces, páginas o redirecciones dentro de un sitio legítimo para manipular los resultados de búsqueda.

Google considera “contenido hackeado” a cualquier contenido agregado sin permiso como consecuencia de una vulnerabilidad de seguridad. Sus políticas mencionan tres manifestaciones habituales: inyección de código, inyección de páginas e inyección de contenido. El objetivo puede ser posicionar otro negocio, aprovechar programas de afiliados, vender tráfico o conducir a los visitantes hacia estafas, phishing o descargas maliciosas.

SEO Spam, cloaking y redirect malware no son lo mismo

Estas técnicas suelen convivir. Una infección puede crear miles de páginas, mostrarlas solamente a un crawler y redirigir únicamente a quienes llegan desde un buscador.

Por qué una web infectada puede parecer normal

El atacante intenta pasar inadvertido. Para eso puede evaluar datos de cada solicitud, como:

• el User-Agent del navegador o crawler;
• el encabezado Referer, que indica desde dónde llegó la visita;
• la dirección IP o el país;
• el tipo de dispositivo;
• si el usuario inició sesión como administrador;
• cookies creadas para no repetir una redirección.

Así, un usuario o el dueño del negocio entra escribiendo la dirección y encuentra el sitio de siempre, mientras una persona que llega desde Google es enviada a un casino. También puede ocurrir que Googlebot reciba títulos, enlaces y textos completamente distintos.

Cómo suele infectarse un sitio

No existe un único punto de entrada. Culpar automáticamente a WordPress, al hosting o a un plugin sin reunir evidencia puede hacer que la limpieza falle.

En WordPress

Los vectores más comunes son plugins o temas vulnerables, componentes abandonados, credenciales reutilizadas, cuentas administrativas comprometidas, formularios de subida inseguros y software “nulled” descargado desde fuentes no confiables.

WordPress no es inseguro por definición. Su enorme ecosistema y la cantidad de instalaciones lo convierten en un objetivo rentable. El riesgo aumenta cuando se acumulan extensiones que ya no se usan, no existe mantenimiento o todos los sitios del hosting comparten accesos y permisos demasiado amplios.

En PHP tradicional o sistemas a medida

Una aplicación sin CMS también puede ser comprometida. Entre los riesgos se encuentran:

• subidas de archivos sin una lista permitida real;
• inclusión local o remota de archivos;
• inyección SQL;
• ejecución remota de código;
• deserialización insegura;
• dependencias antiguas de Composer;
• paneles administrativos sin protección suficiente;
• versiones de PHP fuera de soporte.

OWASP advierte que validar sólo el Content-Type de un archivo no alcanza: puede falsificarse. Una subida segura requiere controlar extensión, firma o contenido, nombre, tamaño, permisos, ubicación y autorización del usuario.

Fuera de la aplicación

El acceso inicial también puede venir de un cPanel, SFTP, SSH o correo comprometido; de malware en la computadora del administrador; de un subdominio olvidado; de un staging público; o de otra instalación vulnerable dentro del mismo hosting.

Por eso una auditoría seria abarca la aplicación, el servidor, las cuentas y los dispositivos desde los que se administra.

Tipos de SEO Spam que aparecen con mayor frecuencia

• Japanese Keyword Hack: crea páginas con títulos y descripciones en japonés, a menudo relacionadas con tiendas o productos falsos.
• Casino spam: usa términos como togel, toto, slot o gacor y puede generar contenido en indonesio.
• Pharma hack: posiciona medicamentos y farmacias no autorizadas.
• Réplicas y falso e-commerce: promociona marcas, zapatillas, bolsos o electrónica que el sitio nunca vendió.
• Spam adulto, préstamos o criptomonedas: aprovecha consultas competitivas y de alto riesgo.
• Sitemaps falsos: facilita el descubrimiento de miles de URLs creadas por el atacante.
• Redirecciones condicionales: se activan sólo para determinadas visitas, dispositivos o países.
• Enlaces ocultos: quedan fuera de pantalla o se disimulan con CSS para transferir señales hacia otros dominios.

El idioma extraño es una pista, no una condición. También puede existir SEO Spam en español o inglés y confundirse con contenido legítimo.

Cómo saber si una web fue hackeada

Señales visibles en Google

Revisá periódicamente:

1. Resultados de marca con títulos o descripciones que no reconocés.
2. Un aumento anormal de páginas indexadas.
3. Consultas de apuestas, medicamentos o productos ajenos en Search Console.
4. Advertencias como “Este sitio puede estar comprometido”.
5. Caídas de tráfico o posiciones sin un cambio editorial que las explique.

Una búsqueda rápida puede ser:

site:tudominio.com
site:tudominio.com casino
site:tudominio.com viagra
site:tudominio.com togel

El operador site: sirve como comprobación inicial, pero no muestra necesariamente todas las URLs indexadas. El informe de indexación y el rendimiento de Search Console ofrecen una visión más útil.

Señales dentro del servidor

• archivos PHP recientes que nadie reconoce;
• modificaciones en .htaccess, index.php, wp-config.php o functions.php;
• archivos .php dentro de carpetas de imágenes o uploads;
• administradores, claves API o propietarios de Search Console desconocidos;
• tareas cron inesperadas;
• reglas de redirección por User-Agent o Referer;
• opciones o entradas ocultas en la base de datos;
• procesos de reinfección después de “limpiar”;
• picos de solicitudes a rutas inexistentes o conexiones externas no esperadas.

Diagnóstico técnico sin destruir evidencia

Antes de modificar el sitio, guardá una copia del estado comprometido, los logs disponibles y una exportación de la base de datos. Esa evidencia puede revelar cuándo entró el atacante, qué cuenta utilizó y qué mecanismo mantiene la persistencia.

Comprobaciones iniciales por consola

Estos comandos son de lectura. Deben ejecutarse desde la ruta correcta y por una persona que comprenda la estructura del hosting.

# Archivos modificados durante los últimos 14 días
find public_html -type f -mtime -14 -print

# PHP dentro de uploads: revisar, no eliminar automáticamente
find public_html/wp-content/uploads -type f -iname '*.php' -print

# Patrones que merecen inspección manual
grep -RInE 'base64_decode|gzinflate|shell_exec|passthru|eval[[:space:]]*\(' public_html

# Reglas basadas en crawler o procedencia de la visita
grep -RInE 'HTTP_USER_AGENT|HTTP_REFERER|Googlebot|RewriteCond|RewriteRule' public_html/.htaccess public_html 2>/dev/null

En WordPress, WP-CLI también ayuda a comparar archivos con checksums oficiales:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator
wp cron event list

Una diferencia de checksum puede ser una modificación legítima, una versión premium no disponible en el repositorio o una señal de compromiso. Siempre se valida con la versión y la fuente correctas.

Cómo probar una posible respuesta diferente

curl -sL https://tudominio.com/ -o respuesta-normal.html
curl -sL -A 'Googlebot' https://tudominio.com/ -o respuesta-googlebot.html
curl -sL -e 'https://www.google.com/' https://tudominio.com/ -o respuesta-desde-google.html
diff -u respuesta-normal.html respuesta-googlebot.html

Esto puede descubrir una respuesta condicional, pero simular el nombre Googlebot no demuestra cómo ve Google realmente la página. Cualquier bot puede falsificar ese encabezado y un malware avanzado puede verificar IPs. Para contrastar, usá la inspección de URL de Search Console y revisá los logs del servidor.

Cómo limpiar SEO Spam correctamente

La recuperación tiene cuatro objetivos simultáneos: contener el incidente, eliminar la persistencia, cerrar la vía de acceso y restaurar la confianza de usuarios y buscadores.

1. Preservar una copia forense

Guardá el entorno infectado fuera del directorio público. No reemplaces el único backup existente: puede ser posterior a la intrusión. Conservá fechas, logs y hashes cuando el caso lo justifique.

2. Contener el incidente

Si existe riesgo para visitantes, formularios, pagos o datos, priorizá la seguridad por encima de la disponibilidad. Según el alcance, puede ser necesario activar mantenimiento, restringir el acceso, aislar la cuenta o coordinar con el hosting.

3. Encontrar el acceso inicial y la persistencia

Reconstruí una línea de tiempo con archivos modificados, logs, accesos y cambios de usuarios. Revisá cron del sistema y de la aplicación, .htaccess secundarios, mu-plugins, uploads, cachés, directorios temporales, base de datos y otras webs de la misma cuenta.

Si no se corrige la raíz, el sitio puede reinfectarse aunque el escáner diga que está limpio.

4. Reconstruir desde fuentes confiables

En WordPress suele ser más seguro reemplazar el core, plugins y temas por copias legítimas de la versión adecuada que “reparar” archivos sospechosos uno por uno. El contenido personalizado debe compararse con Git, un backup limpio o una fuente conocida.

En PHP a medida, revisá dependencias, controladores de uploads, consultas, includes, credenciales expuestas y cualquier archivo que pueda ejecutar código. No sobrescribas producción hasta validar el resultado en un entorno aislado.

5. Limpiar la base de datos

Buscá scripts, iframes, enlaces, usuarios, opciones, tareas y entradas que no pertenezcan al proyecto. En WordPress, prestá especial atención a wp_options, wp_users, wp_usermeta, wp_posts y tablas creadas por plugins, recordando que el prefijo puede no ser wp_.

6. Rotar accesos y secretos

Cambiá desde un dispositivo confiable:

• hosting y panel de control;
• WordPress u otro CMS;
• SFTP/SSH y claves privadas comprometidas;
• base de datos;
• correo administrativo;
• CDN, DNS y registrador del dominio;
• claves API, tokens y salts;
• propietarios y usuarios de Search Console, Analytics y Tag Manager.

Cerrar sesiones activas es tan importante como cambiar la contraseña. No reutilices credenciales y activá 2FA donde esté disponible.

7. Corregir la vulnerabilidad

Actualizá o eliminá el componente vulnerable, corregí el código, reducí permisos y protegé el endpoint afectado. Si el origen fue una computadora infectada, limpiarla forma parte del incidente.

8. Validar antes de reabrir

Probá distintas rutas, dispositivos, procedencias y cuentas; verificá que no existan conexiones externas sospechosas; compará checksums; revisá logs; escaneá desde fuera del servidor y confirmá que las URLs falsas ya no entreguen contenido malicioso.

Qué no hacer durante la recuperación

• No borrar todas las coincidencias de base64 o eval de manera automática.
• No confiar en un único plugin o escáner remoto.
• No restaurar un backup y mantener las mismas contraseñas.
• No limpiar sólo la instalación visible si hay más sitios en la cuenta.
• No bloquear las URLs spam únicamente con robots.txt: eso controla rastreo, no garantiza su eliminación del índice.
• No redirigir miles de URLs falsas a la portada; deben devolver el estado correcto, normalmente 404 o 410, salvo que exista un reemplazo real.
• No solicitar una revisión de Google antes de haber corregido todas las variantes del problema.
• No prometer una fecha exacta de recuperación del tráfico o las posiciones.

Recuperación SEO después de la limpieza

Limpiar el servidor y recuperar Google son etapas relacionadas, pero diferentes.

Paso 1: comprobar el estado en Search Console

Revisá:

• Problemas de seguridad;
• Acciones manuales;
• Indexación de páginas;
• Rendimiento, especialmente consultas y URLs anómalas;
• Sitemaps;
• propietarios y usuarios con acceso.

Un problema de seguridad no es lo mismo que una acción manual. Tampoco todas las caídas algorítmicas generan una notificación.

Paso 2: devolver respuestas correctas

Las páginas legítimas deben responder con contenido limpio y código 200. Las rutas spam eliminadas deberían responder 404 o 410, no un “soft 404” con código 200. Eliminá esas URLs del sitemap y de cualquier enlace interno.

Paso 3: enviar un sitemap limpio

Incluí solamente URLs canónicas, indexables y legítimas. Para las páginas principales, la inspección de URL puede ayudar a confirmar cómo las procesa Google y permite solicitar una nueva indexación.

Paso 4: usar las eliminaciones con criterio

La herramienta de eliminaciones de Search Console oculta temporalmente resultados; no reemplaza la eliminación real de la página ni la respuesta HTTP correcta. Puede ayudar en casos urgentes, pero el arreglo permanente está en el servidor.

Paso 5: solicitar revisión cuando corresponde

Si Search Console muestra un problema de seguridad, corregí todas las categorías y ejemplos, probá la solución y luego elegí Solicitar una revisión. Google recomienda explicar:

1. cuál era el problema;
2. qué acciones concretas se realizaron;
3. cuál fue el resultado.

Si no existe un problema de seguridad ni una acción manual, normalmente no hay un botón de reconsideración que acelere el proceso: Google deberá volver a rastrear y procesar las URLs.

WordPress: endurecimiento después de un hackeo

La guía oficial de WordPress define la seguridad como reducción de riesgo, no como una garantía absoluta. Después de la recuperación, aplicá una estrategia por capas:

• mantener core, temas y plugins actualizados;
• borrar componentes inactivos o abandonados;
• instalar software sólo desde fuentes confiables;
• activar 2FA para administradores y hosting;
• usar SFTP o SSH en lugar de FTP sin cifrar;
• aplicar mínimos privilegios y permisos adecuados;
• desactivar la edición de PHP desde el panel si no se necesita;
• usar WAF y limitación de intentos como capas adicionales;
• conservar backups externos, versionados y probados;
• monitorear cambios de archivos, logs y disponibilidad;
• revisar periódicamente administradores y accesos a herramientas de Google.

Para desactivar el editor de archivos desde wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

Esta medida puede limitar el daño si roban una cuenta administrativa, pero no impide por sí sola que un atacante suba archivos o explote otra vulnerabilidad.

Checklist rápido para propietarios de sitios

Preguntas frecuentes

Conclusión: limpiar el síntoma no alcanza

El SEO Spam es una intrusión de seguridad con consecuencias sobre reputación, tráfico y ventas. La parte visible —resultados extraños, páginas de casinos o redirecciones— puede desaparecer y aun así quedar una puerta trasera preparada para reactivar la campaña.

Una recuperación completa debe responder cuatro preguntas: cómo entraron, qué modificaron, cómo mantuvieron el acceso y qué controles evitarán que vuelva a ocurrir. Sólo después tiene sentido pedirle a Google que reprocese el sitio.

Auditoría y recuperación

¿Tu web muestra resultados extraños o redirige a otro sitio?

Puedo revisar WordPress, PHP, hosting y Search Console para determinar el alcance real, limpiar la infección y planificar la recuperación SEO sin promesas irreales.

Solicitar una revisión Ver mantenimiento web

Fuentes y documentación técnica

• Políticas de spam: contenido hackeado, cloaking, doorways y redirecciones — Google Search Central.
• Informe de problemas de seguridad y solicitud de revisión — Ayuda de Search Console.
• Por qué Google puede marcar un sitio como peligroso — Ayuda de Search Console.
• Prevención de infecciones de malware — Google Search Central.
• Eliminación de información de Google Search — Google Search Central.
• Hardening de WordPress — documentación oficial de WordPress.
• Guía de seguridad para la subida de archivos — OWASP Cheat Sheet Series.
• Gestión segura de secretos — OWASP Cheat Sheet Series.