De repente las búsquedas de mi web dan resultados raros en Google, en japonés y cosas de vender relojes o viagra ¿me han hackeado?

Si buscas tu dominio en Google y aparecen páginas con caracteres japoneses o títulos que venden Viagra, tienes un problema. Y si no aparece nada raro, ojo, porque los ataques más sofisticados son exactamente esos: los que no ves desde el escritorio de WordPress, pero que Google lleva meses rastreando mientras tú no ves nada fuera de lo normal.

A eso se le llama spam SEO inyectado, y no persigue tumbar tu web ni robarte datos, lo que busca es aprovechar la autoridad que llevas años construyendo para posicionar webs basura de farmacias ilegales, tiendas de imitaciones de lujo o casinos online. Usan tu dominio como trampolín, y mientras ellos cobrando las comisiones de afiliados.

El informe State of WordPress Security de Patchstack recoge datos de Sucuri que cifran en más de 422.000 los incidentes de spam SEO detectados en 2024, con el spam japonés como la variante más extendida, responsable del 27,77% de todos los casos. No es un problema marginal ni de lejos.

Vamos a ver qué formas tiene este ataque de inyección de spam, cómo detectarlo y cómo cerrarlo, desde lo más básico hasta lo más potente.

Tres tipos de spam SEO, tres niveles de problema

No todos los ataques de spam SEO son iguales ni entran por el mismo sitio ni se detectan igual. Conviene distinguirlos antes de ponerse a tapar agujeros a ciegas.

El más visible: spam en los comentarios

El atacante (o casi siempre un bot automatizado) publica comentarios que incluyen enlaces a las webs que quieren posicionar. Google rastrea esos enlaces cuando visita tu web y les transfiere autoridad, el resultado es que tu web contribuye al SEO de una farmacia sin receta, una tienda de relojes falsificados o cualquier otra web de mierda.

Es el nivel básico, es feo, molesto y contraproducente para tu propio perfil de enlazado, pero por otro lado es fácil de detectar porque lo ves tú mismo en la sección de comentarios.

El nivel medio: inyección de enlaces en la base de datos

Aquí ya el atacante ha conseguido entrar en tu instalación, pues en lugar de dejar un comentario, inyecta enlaces directamente en el contenido de tus entradas o páginas, en campos de la base de datos como wp_options o wp_postmeta, o en el código del tema. Los enlaces pueden ir con CSS que los oculta visualmente a los visitantes humanos, pero que los rastreadores de los buscadores leen perfectamente.

No lo ves navegando tu web, pero lo puedes ver revisando el código fuente de la página o auditando la base de datos.

El más peligroso: el pharma hack y el spam japonés con cloaking

Este es el nivel que da más guerra, nunca mejor dicho, pues el atacante instala en tus archivos o en la base de datos un código que comprueba quién está visitando la página antes de decidir qué contenido servir.

Si detecta que es un rastreador de Google, Bing o Yandex, sirve páginas llenas de palabras clave farmacéuticas o texto en japonés, si detecta a un visitante humano normal, muestra tu contenido de siempre. Podríamos decir que es hackeo inteligente.

El resultado es que tú entras a tu web y ves todo perfecto, pero ve un catálogo de medicamentos sin receta con miles de páginas generadas automáticamente.

Esta técnica se llama cloaking (camuflaje), y es deliberada porque los atacantes no quieren que lo descubras. Cuanto más tiempo lleve activo, más autoridad de tu dominio han aprovechado, y cuanto más tarde en detectarse, más difícil es la recuperación del SEO después.

El truco que hace invisible la infección

Para entender por qué no lo ves desde el escritorio de WordPress hay que entender cómo funciona el cloaking.

El código malicioso, que puede vivir en tu .htaccess, en tu wp-config.php, en el functions.php del tema o en archivos de plugins, lee la cabecera User-Agent de cada petición que llega al servidor. Esa cabecera identifica quién hace la petición: si es Chrome, Firefox, Safari o un bot de Google.

Si el User-Agent es Googlebot, Bingbot, baiduspider o cualquier rastreador conocido, el código conecta con el servidor del atacante, descarga el contenido de spam del momento y lo sirve. Si eres tú entrando desde el navegador, con tu sesión de WordPress activa o simplemente con un User-Agent de navegador normal, ves tu web tal cual.

Este mecanismo explica por qué muchos propietarios de WordPress llevan meses o incluso años con la infección activa sin saber nada. Y explica también por qué la primera señal de alarma suele venir de fuera, como de un aviso de Google Search Console, un cliente que lo vio en Google, o una caída inexplicable del tráfico orgánico.

El código malicioso se esconde habitualmente en estos sitios:

• Las primeras o últimas líneas del wp-config.php, camuflado como comentario o como código de configuración aparentemente legítimo.
• El archivo .htaccess, con reglas de redirección condicionales.
• El functions.php del tema activo, aprovechando que se ejecuta en cada carga.
• La carpeta mu-plugins/ (de must-use plugins), que se ejecuta automáticamente en cada carga de página y no aparece en la lista de plugins del escritorio, lo que la convierte en el escondite preferido para la persistencia después del hackeo.
• La carpeta uploads/, donde a veces aparecen archivos .php disfrazados de imágenes.
• Opciones de la base de datos en wp_options, codificadas en base64 para dificultar la detección.

Y sobre la cadena de suministro como vector de entrada, si no leíste el artículo de los ataques a la cadena de suministro en WordPress que publiqué hace unas semanas, te lo resumo en que el caso Essential Plugin fue exactamente esto, una puerta trasera que servía spam SEO camuflado solo a los rastreadores, invisible para los propietarios. El ataque más sofisticado posible a través del canal oficial de actualización de plugins.

Cómo saber si te han inyectado spam SEO antes de enterarte por Google

No esperes al aviso de Search Console. Para cuando Google te manda la alerta, la infección lleva semanas o meses activa y el daño al SEO ya está hecho, es mucho mejor buscarlo activamente ¿a que sí?.

La búsqueda más directa

Ve a Google y escribe site:tudominio.com, revisa los resultados que aparecen, y si ves páginas con caracteres japoneses, títulos sobre medicamentos, casinos o productos que no tienen nada que ver con tu contenido real, date por inyectado.

También puedes añadir términos sospechosos: site:tudominio.com viagra, site:tudominio.com casino. Si aparece algo ya tienes la confirmación.

Google Search Console

En la sección de seguridad y acciones manuales aparecerán los avisos si Google ya ha detectado el problema. Pero no esperes solo a eso, en el inspector de URLs puedes comparar cómo procesa Google una URL concreta de tu web frente a cómo la ves tú. Si el contenido que ve Google no coincide con el que ves tú, ¡te han cloakeado!

Ojo también con los usuarios que tienen acceso a tu Search Console. Una técnica habitual es añadir un usuario del atacante como propietario o delegado para poder manipular el sitemap e indexar las páginas de spam. Revísalo en Ajustes → Usuarios y permisos.

Herramientas de escáner externo

El escáner gratuito Sucuri SiteCheck analiza tu web desde fuera, como lo haría un motor de búsqueda, y detecta código malicioso, listas negras y redirecciones sospechosas. No necesitas instalar nada.

También la base de datos de WPScan te permite comprobar si alguno de tus plugins tiene vulnerabilidades conocidas activas.

Lo que puedes ver desde el escritorio de WordPress

Ve a Usuarios → Todos los usuarios y filtra por el perfil de administrador. ¿Los reconoces todos? Una práctica habitual tras un hackeo es crear usuarios administradores falsos para mantener el acceso aunque limpies los archivos. Borra sin piedad cualquier usuario que no reconozcas.

WP-CLI si tienes acceso por SSH

Si tienes acceso al servidor, estos tres comandos te dan una imagen rápida del estado:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --format=table

El primero compara los archivos del núcleo de WordPress con los oficiales y te dice si alguno ha sido modificado, el segundo hace lo mismo con los plugins que tienen checksums en WordPress.org (esto mismo puedes hacerlo con Vigilante), y el último lista todos los administradores para que compruebes quién está ahí.

Para buscar código sospechoso en PHP lanza esto en la raíz de tu instalación:

grep -ri "base64_decode\|eval(" wp-content/ --include="*.php" -l
find wp-content/uploads -name "*.php" -ls

El primer comando busca los patrones de ofuscación más comunes, el segundo lista todos los archivos PHP que hay en uploads/, donde no debería haber ninguno.

De lo más básico a lo más serio: así cierras la puerta

Ninguna medida por sí sola es suficiente. La defensa funciona por capas, y cada capa tapa los agujeros que la anterior deja sin cubrir.

Capa básica: comentarios y acceso público

La primera y más sencilla. No protege contra el pharma hack ni el spam japonés, pero sí contra el spam de comentarios y contra que atacantes anónimos inyecten contenido.

• Cierra los comentarios en entradas antiguas: En Ajustes → Comentarios, activa «Cerrar automáticamente los comentarios de entradas con más de X días de antigüedad». Los bots de spam atacan preferentemente entradas viejas porque suelen tener menos supervisión.
• Modera todos los comentarios antes de publicarlos: En el mismo panel, activa «El comentario debe aprobarse manualmente». Ningún enlace de spam se publica sin que tú lo veas primero.
• Instala un filtro de spam: Akismet sigue siendo la referencia, aunque requiere clave de API. Alternatives gratuitas como Antispam Bee o CleanTalk funcionan bien en la mayoría de casos.
• Desactiva los pingbacks: En Ajustes → Comentarios, desmarca «Permitir avisos de enlace de otros blogs». Los pingbacks tienen un uso muy limitado en 2026 y son un vector de abuso.
• Desactiva el registro de usuarios si no es imprescindible: En Ajustes → Generales, desmarca «Cualquiera puede registrarse». Si tu web no necesita que los visitantes tengan cuenta, no hay razón para exponerlo.

Capa media: archivos, permisos y credenciales

Aquí va el grueso de la protección contra los ataques más sofisticados. Patchstack registró en 2025 la cifra de 11.334 vulnerabilidades en el ecosistema WordPress, con un tiempo medio de apenas 5 horas desde que se publica la vulnerabilidad hasta que los bots la explotan. Mantener todo actualizado no es opcional, es la primera línea de defensa real.

• • Actualiza siempre y cuanto antes: WordPress, plugins y temas. El 91% de las vulnerabilidades de 2025 estaban en plugins, no en el núcleo. Cada plugin sin actualizar es una puerta potencialmente abierta.
  • Permisos de archivos correctos: Los archivos deben estar a 644 y los directorios a 755. El wp-config.php puede ir a 440 o 400 si tu servidor lo permite.
  • Protege los archivos sensibles desde el servidor: Añade esto por encima del bloque # BEGIN WordPress:

# Proteger wp-config.php
<Files wp-config.php>
  Order Allow,Deny
  Deny from all
</Files>

# Proteger .htaccess
<Files .htaccess>
  Order Allow,Deny
  Deny from all
</Files>

# Bloquear ejecución de PHP en uploads
<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteRule ^wp-content/uploads/.*\.php$ - [F,L]
</IfModule>

# Deshabilitar listado de directorios
Options -Indexes

• Bloquea la ejecución de PHP en la carpeta uploads/: Esta carpeta tiene que poder recibir archivos subidos, pero nunca ejecutar PHP. Es uno de los vectores de acceso más habituales una vez que un atacante ha conseguido subir un archivo malicioso.
• Contraseñas fuertes y únicas para todos los administradores: Si tienes varios usuarios con rol de Administrador, cada uno con su propia contraseña segura. Un gestor de contraseñas como Bitwarden lo hace fácil y gratuito.
• Elimina el usuario admin si todavía lo tienes: Es el primer nombre de usuario que prueban todos los ataques automatizados.
• Elimina temas y plugins nulled o piratas: Esto no lo negocies: los temas y plugins de fuentes no oficiales son el vector de infección más rápido y más evitable. Si los tienes, quítalos.
• Desactiva XML-RPC si no lo usas: La mayoría de webs WordPress no lo necesitan actualmente y es un vector de ataque muy usado para inyectar contenido de forma remota.

Capa avanzada: monitorización activa

Llegamos al punto donde la defensa deja de ser reactiva y se vuelve proactiva. No solo cerramos puertas sino que detectamos cuando alguien intenta abrirlas.

El archivo .htaccess y wp-config.php son los primeros objetivos de cualquier atacante que consiga acceso a tu servidor. Si esos archivos cambian sin que tú hayas tocado nada, tienes una infección activa. El problema es que nadie mira esos archivos todos los días.

Puedes usar Vigilante para monitorizar ambos archivos contra su línea base original, muestra un diff línea a línea de cualquier cambio y manda un aviso por correo en el momento en que detecta la modificación. En vez de enterarte semanas después porque Google te manda un aviso de acción manual, te enteras cuando el atacante toca el archivo. Eso es la diferencia entre limpiar una infección de horas y limpiar meses de daño en el SEO.

Más allá de eso, un escáner periódico de integridad de archivos compara los archivos de tu instalación con los oficiales de WordPress.org y detecta modificaciones, archivos añadidos o código sospechoso en temas y plugins. Lo ideal es que esto corra de forma automática y te mande el informe.

Otras medidas avanzadas:

• Activa la identificación en dos pasos (2FA) para todos los administradores: Si las credenciales quedan expuestas en una filtración, el 2FA es lo que evita que sirvan de algo.
• Registra toda la actividad con un log de auditoría: Logins, cambios de contraseña, activaciones de plugins, modificaciones de entradas, así todo queda registrado y con alerta si algo parece raro. Si un atacante crea un usuario administrador o activa un plugin que no reconoces, necesitas saberlo en el momento.
• Revisa la carpeta mu-plugins/ periódicamente: Los archivos que hay ahí se ejecutan en cada carga de página sin aparecer en la lista de plugins. Si encuentras algo que no pusiste tú, bórralo.
• Usa un cortafuegos a nivel de aplicación: Cloudflare como primera capa (gratis en su plan básico) más un plugin de seguridad con WAF dentro de WordPress bloquea la mayor parte del tráfico malicioso antes de que llegue a intentar explotar nada.
• Activa la detección de plugins cerrados: WordPress.org cierra plugins cuando se descubren problemas de seguridad. Si tienes uno instalado y lo cierran, necesitas saberlo ese mismo día, no cuando busques en Google por qué tu web se comporta raro. Esto lo tiene Vigilante, nadie más.

Para completar la defensa contra fuerza bruta, tienes una guía específica en el plan de batalla contra ataques de fuerza bruta con el detalle de cómo montar la protección por capas desde Cloudflare hasta el plugin.

Ya lo tengo ¿qué hago?

Si llegas a este punto con la confirmación de que tu web está infectada, para. No borres nada todavía. El orden importa porque si limpias sin cerrar el vector de entrada, la infección vuelve en horas.

1. Haz una copia de seguridad completa ahora mismo, incluyendo archivos y base de datos. Incluso de la versión infectada. La necesitarás como referencia para saber exactamente qué cambió y para no perder el contenido legítimo si algo sale mal durante la limpieza.
2. Pon el sitio en modo mantenimiento para que los visitantes no lleguen a las páginas infectadas mientras limpias.
3. Ejecuta un escáner completo (Wordfence, Sucuri o Vigilante) y guarda el informe completo antes de tocar nada. Necesitas la lista de todo lo afectado antes de empezar a limpiar.
4. Limpia el núcleo de WordPress. Descarga la versión exacta que tienes de wordpress.org y sustituye las carpetas wp-admin/ y wp-includes/ por las originales. No toques wp-content/ ni wp-config.php en este paso.
5. Elimina todos los plugins y temas y reinstálalos desde cero. Descarga versiones limpias desde WordPress.org o de sus fuentes oficiales. No reactivar los plugins nulled.
6. Revisa wp-config.php buscando código inyectado al principio o al final del archivo, y revisa .htaccess buscando redirecciones condicionales que no pusiste tú. Si usas Vigilante y tenías el monitoreo activado, el diff te muestra exactamente qué líneas cambiaron.
7. Audita la carpeta mu-plugins/ y la carpeta uploads/ buscando archivos PHP que no deberían estar ahí.
8. Limpia la base de datos. Revisa wp_posts buscando contenido con enlaces ocultos o contenido que no reconoces. Revisa wp_options buscando valores codificados en base64. Busca en wp_users usuarios administradores que no reconoces.
9. Elimina todos los usuarios administrador que no reconozcas y cambia las contraseñas de todos los que sí reconozcas.
10. Cambia las credenciales de todo: WordPress, base de datos, FTP y cuenta de hosting. Si la contraseña que usaban para entrar sigue activa, vuelven.
11. Actualiza WordPress, todos los plugins y todos los temas a la última versión disponible.
12. Ejecuta un segundo escáner completo para verificar que la limpieza ha sido efectiva antes de quitar el modo mantenimiento.

Si después de limpiar la infección vuelve en horas o días, hay algún punto de re-entrada que no has cerrado: un plugin vulnerable que no actualizaste, un usuario comprometido que no eliminaste, o una puerta trasera en mu-plugins/ o en uploads/ que te has dejado. Vuelve al escáner y revisa esos puntos específicamente.

Si el proceso te supera o si el sitio tiene un volumen de páginas infectadas que hace que la limpieza manual sea inviable, el servicio de recuperación de web hackeada existe exactamente para esto.

Recuperar el SEO después del golpe

Limpiar la infección es la mitad del trabajo, la otra es convencer a Google de que ya no hay problema.

Si Google emitió una acción manual contra tu sitio, aparecerá en Search Console → Seguridad y acciones manuales → Acciones manuales. Una vez limpias la web, puedes solicitar revisión desde esa misma pantalla. El equipo de calidad de Google suele responder en unos días en los casos más claros.

Si no hay acción manual sino penalización algorítmica (tu tráfico cayó pero no hay aviso explícito), el proceso es más lento porque Google necesita volver a rastrear las páginas afectadas y procesar que el contenido ya no está. Puedes acelerar esto enviando tu mapa del sitio actualizado desde Search Console y usando la herramienta de inspección de URLs para solicitar la indexación de tus páginas principales.

Las páginas de spam que Google tenía indexadas (los miles de URLs con contenido japonés o farmacéutico) irán desapareciendo del índice a medida que Google las reindexe y confirme que el contenido ya no está. Este proceso puede tardar semanas, no es inmediato, pero sí progresivo.

Monitoriza desde Search Console el número de páginas indexadas de tu dominio durante las semanas siguientes a la limpieza. Si vas bien, verás cómo esas URLs spam van desapareciendo del recuento.

Una última cosa

El spam SEO inyectado no es un ataque de película que requiere un hacker sofisticado persiguiendo tu web específicamente. Son ataques automatizados que explotan vulnerabilidades conocidas a escala industrial. El destino del ataque no eres tú, es el plugin sin actualizar que tienes instalado, y hay bots que escanean millones de webs buscando exactamente eso.

La buena noticia es que la defensa tampoco es complicada, se basa en mantener todo actualizado, cerrar los comentarios donde no hacen falta, monitorizar los archivos que más se tocan en un hackeo (wp-config.php y .htaccess) y tener un escáner que avise cuando algo cambia cubre la inmensa mayoría de los casos. Para eso desarrollé Vigilante, para que no tengas que pagar por todas esas funcionalidades des seguridad imprescindibles.

El trabajo hay que hacerlo antes de que llegue el problema, no después. Cuando Google te manda el aviso el daño ya lleva semanas hecho.

Si tienes dudas o has pasado por esto y quieres compartir cómo fue el proceso, me tienes ahí abajo en los comentarios.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!