Su sitio WordPress tiene spam SEO. Limpiarlo no lo va a solucionar.

El spam SEO en WordPress vuelve una y otra vez porque la limpieza borra el síntoma y deja intacta la vía de entrada. Sucuri encontró una puerta trasera en el 49,21 % de los sitios comprometidos en el momento de la infección, y al menos una cuenta de administrador maliciosa en el 55 % de los sitios con malware en la base de datos.

Usted escanea las páginas, borra los enlaces inyectados, actualiza cada plugin, y en menos de un mes los enlaces de farmacia han vuelto. La cuenta que los reinstala se creó durante la primera brecha y sobrevivió a la limpieza.

Quien haya limpiado alguna vez una instalación de WordPress hackeada ya lo sabe: la segunda infección llega más rápido que la primera. A continuación, el daño que esto causa a su posicionamiento, una auditoría de 20 minutos sin comprar ningún escáner, los motivos por los que la eliminación fracasa y la forma de cerrar el agujero de manera definitiva.

• El spam SEO figura entre las infecciones más frecuentes que Sucuri repara. Apareció en el 20,30 % de los sitios infectados durante la limpieza y en el 42,22 % mediante análisis remotos.
• La limpieza retira la carga útil y deja el acceso. El 49,21 % de los sitios comprometidos tenía una puerta trasera, y el 55 % de los sitios con malware en base de datos, una cuenta de administrador maliciosa.
• Parchear resulta imposible con frecuencia. Patchstack contabilizó 11.334 nuevas vulnerabilidades de WordPress en 2025, el 91 % de ellas en plugins, y el 46 % no tenía solución disponible el día de su publicación.
• La mayor parte del spam vive en la base de datos. El 38,3 % de las bases de datos comprometidas contenía spam SEO, y por eso un escáner de archivos informa de un sitio limpio mientras Google muestra títulos de farmacia.
• Una reconstrucción estática cierra el ciclo. Sin base de datos en tiempo de ejecución y sin capa de plugins, no queda nada en el servidor donde inyectar.

Qué le hace una inyección de spam SEO a un sitio WordPress

El atacante quiere la reputación de su dominio. Un sitio en el que Google ya confía traslada esa confianza a páginas que venden medicamentos falsificados, altas en casinos o zapatillas falsas. Los enlaces permanecen ocultos para usted y se sirven a Googlebot. En el navegador el sitio parece impecable, en el índice se lee como una farmacia.

• Bloques de enlaces ocultos. Cientos de etiquetas de anclaje desplazadas fuera de la pantalla con CSS, inyectadas en el pie de página, en un área de widgets o en una entrada antigua que nadie abre.
• Páginas encubiertas (cloaking). El servidor comprueba el user-agent y el referente antes de decidir qué enviar. Los visitantes humanos reciben su página de inicio, Googlebot recibe spam, y el propietario es el último en enterarse.
• El Japanese keyword hack. Google Search Central lo documenta con ese nombre: miles de páginas generadas automáticamente con texto japonés y enlaces de afiliación, más un propietario ajeno añadido a Search Console para que el atacante conserve el acceso después de que usted limpie los archivos.
• Redirecciones condicionales. Los visitantes que llegan desde un resultado de búsqueda acaban en el destino de spam. Quien teclea el dominio directamente ve un sitio normal, de ahí que los propietarios rara vez crean el primer aviso.

El 38,3 % de las bases de datos comprometidas en el conjunto de datos de Sucuri contenía spam SEO, sobre todo enlaces ocultos a medicamentos falsificados y juegos de azar. Esa cifra explica la parte más frustrante. Un escáner de malware recorre el sistema de archivos, informa de que todo está limpio, y el contenido inyectado está en una tabla de la base de datos que nunca abrió.

Si en sus resultados de búsqueda ya aparecen páginas de spam, la vía de la reconstrucción importa más que el siguiente análisis. El servicio de migración de WordPress de webvise cubre el paso a un frontend estático en Next.js, junto con el mapa de redirecciones que traslada su posicionamiento actual.

Confirmar la infección en 20 minutos

Haga estas cuatro comprobaciones antes de pagar a nadie por una limpieza. Cada una lleva unos minutos, no necesita ningún plugin y detecta algo que al escáner de su panel se le escapa.

1. Pregunte a Google qué tiene indexado

Busque su propio dominio con el operador site y lea el número de resultados antes de leer los resultados.

• site:sudominio.es viagra y site:sudominio.es casino devuelven páginas que usted nunca escribió. Basta con un resultado.
• site:sudominio.es por sí solo devuelve muchas más páginas de las que tiene su sitio. Un sitio corporativo de 40 páginas que declara 6.000 URL indexadas es ya el diagnóstico completo.
• Los títulos de los resultados aparecen en caracteres japoneses, cirílicos o chinos en un sitio que publica en español o inglés.

2. Solicite su propio sitio haciéndose pasar por Googlebot

El spam encubierto solo aparece cuando el servidor cree que quien pregunta es Googlebot. Compare desde un terminal lo que reciben ambos visitantes.

Cifras iguales no dejan limpio al sitio. Muchas inyecciones se dirigen a URL concretas en lugar de a la página de inicio. Repita la comparación en dos o tres páginas profundas antes de fiarse del resultado.

3. Lea Search Console y luego compruebe quién más puede leerla

Abra primero las secciones Acciones manuales y Problemas de seguridad. Una acción manual por spam derivado de un hackeo, un repunte súbito de impresiones para consultas ajenas a su negocio, o un propietario verificado desconocido en Configuración apuntan todos en la misma dirección. Ese último punto se pasa por alto casi siempre, y es precisamente el que permite a un atacante volver a verificar la propiedad mucho después de reconstruido el sitio.

4. Busque en la base de datos, no en los archivos

Aquí es donde el escáner de archivos dejó de mirar. Tres consultas sacan a la luz casi todo lo que pasó por alto.

• SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%display:none%' OR post_content LIKE '%position:absolute;left:-%'; localiza bloques de enlaces ocultos almacenados en sus contenidos.
• SELECT user_login, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 10; lista las cuentas más recientes. Cuestione cada una a la que no pueda ponerle cara.
• SELECT option_name FROM wp_options WHERE autoload='yes' AND LENGTH(option_value) > 100000; atrapa cargas útiles inyectadas de tamaño desmedido, configuradas para cargarse en cada una de las peticiones.

Por qué la limpieza fracasa una y otra vez

Una limpieza apunta a la carga útil visible. La vía de acceso es otra cosa por completo, y sobrevive al análisis, a la actualización de plugins y a la restauración de la copia de seguridad que la mayoría de las agencias aplica como primer paso.

Los datos de remediación de Sucuri sitúan una puerta trasera en el 49,21 % de los sitios comprometidos en el momento de la infección. En los sitios con malware en la base de datos, el 55 % sumaba además al menos una cuenta de administrador maliciosa, de modo que el atacante entra por la puerta principal y se ahorra el exploit la segunda vez. Borrar enlaces de spam de un sitio que conserva ambas cosas es tarea de limpieza doméstica. La reinfección está programada más que resulta sorprendente.

WP Automatic hace tangible el patrón. Patchstack publicó CVE-2024-27956 el 13 de marzo de 2024, una inyección SQL no autenticada puntuada con 9,8, y los ataques posteriores la usaron para crear nuevas cuentas de administrador. Los investigadores registraron más de 5,5 millones de intentos de explotarla. Cada sitio afectado y limpiado después sin que nadie auditara la tabla de usuarios le entregó al atacante un acceso operativo.

La última fila decide toda la estrategia. Patchstack contabilizó 11.334 nuevas vulnerabilidades de WordPress en 2025, un 42 % más que el año anterior, con el 91 % en plugins y el 46 % sin solución el día de su publicación. Para casi la mitad de todo lo divulgado el año pasado, aplicar el parche no era una opción a su alcance.

Eso es justo lo que convierte una cuestión de mantenimiento en una cuestión de plataforma. El mismo razonamiento recorre los riesgos de seguridad de dejar una instalación obsoleta, y la cuenta empeora cada año que sube el número de vulnerabilidades.

Lo que el spam le cuesta de verdad en Google

El daño al posicionamiento va muy por delante del descubrimiento. Cuando una página de spam asoma en una búsqueda site, Google lleva semanas rastreándola e indexándola, y el patrón que ha aprendido sobre su dominio ya está asentado.

La recuperación sigue una secuencia fija y nada en ella es rápido. Limpiar el sitio, eliminar las cuentas y propietarios ajenos, presentar una solicitud de reconsideración y esperar a que se retire la acción manual. Google no publica ningún compromiso de plazo para esa revisión. Las páginas desindexadas como spam no regresan con sus posiciones anteriores.

Un sitio que sirvió páginas de farmacia encubiertas durante dos meses arrastra ese historial a todo lo que se construya después, lo que eleva lo que está en juego en la propia reconstrucción. Los mecanismos para conservar el posicionamiento en un relanzamiento merecen una lectura antes de que nadie toque el DNS.

Eliminar la superficie de ataque en lugar de parchearla

WordPress ejecuta PHP en su servidor, lee y escribe en una base de datos en cada petición, y hace funcionar código de plugins de terceros con acceso casi total a ambas cosas. Esas tres propiedades son precisamente lo que necesita una inyección de spam SEO. Un sitio Next.js generado de forma estática no ofrece ninguna de ellas en tiempo de ejecución.

• Sin base de datos en tiempo de ejecución. Las páginas se construyen en el despliegue y se sirven como archivos desde un CDN. No existe ninguna tabla wp_posts donde escribir divs ocultos.
• Sin capa de plugins. El 91 % de las vulnerabilidades de WordPress de 2025 residía en plugins. Un sitio sin capa de plugins no hereda ninguna de ellas.
• Nada escribible en el servidor. Solo un despliegue cambia lo que ven los visitantes, y parte del control de versiones. Un archivo inyectado aparece como una diferencia antes siquiera de publicarse.
• Sin panel de administración expuesto a internet. El problema de la cuenta de administrador maliciosa deja de existir cuando no hay ningún formulario de acceso al que llegar.

La migración en sí es una magnitud conocida: auditoría completa del sitio existente, reconstrucción en Next.js con generación estática, un 301 para cada URL que exista hoy y seguimiento del posicionamiento tras el cambio. webvise trabaja exactamente en ese orden, con un prototipo funcional lo bastante pronto como para que vea sus contenidos colocados antes de comprometerse con el cambio. Si el paso encaja con su sitio depende de cuánto de él necesita realmente un servidor.

Haga primero las cuatro comprobaciones. Si una búsqueda site devuelve páginas que usted nunca escribió, hay que cerrar la vía de acceso antes que cualquier otra cosa, y el presupuesto de limpieza que espera en su bandeja de entrada compra unas semanas de calma en lugar de una solución. webvise audita la instalación existente, informa de lo que encuentra y reconstruye sobre una base donde no hay nada que inyectar: reserve la auditoría aquí.