Cloaking en WordPress: tu web enseña spam solo a Google (y tú no lo ves)

Respuesta corta: si Google muestra tu web con spam (farmacia, casinos, japonés) pero tú la ves limpia, probablemente tienes cloaking: un código malicioso que enseña una versión a Google y otra a las personas. Se confirma comparando lo que recibe Googlebot con lo que recibe un visitante, sobre todo con la inspección de URL de Search Console. Se limpia quitando ese código (en .htaccess, PHP o la base de datos), cerrando la puerta de entrada y pidiendo la revisión a Google.

El cloaking en WordPress (en Search Console lo verás también como «encubrimiento») es de los hackeos más desconcertantes: el cliente te llama porque en Google sale su web con viagra, entras y no ves nada raro. No te estás volviendo loco. Esta guía forma parte de nuestra guía general sobre qué hacer con un WordPress hackeado.

Por qué tu web enseña spam solo a Google

Al atacante le interesa que Google indexe su spam con la autoridad de tu dominio, pero no que tú lo descubras y lo limpies. Así que el código que deja en tu web decide qué enseñar según quién pregunta. Las condiciones más habituales:

• Quién dice ser el visitante (su User-Agent): si dice ser Googlebot, recibe spam.
• Desde dónde llega (el Referer): quien llega desde un resultado de Google es redirigido a la web del atacante; quien escribe tu dirección ve la web normal.
• Desde qué IP: las variantes más cuidadas comprueban que la IP es de verdad de Google.
• Si has iniciado sesión: a los administradores conectados se les enseña la web limpia.
• El dispositivo: solo redirige en móviles.

Google considera el cloaking una infracción de sus políticas de spam, aunque no lo hayas puesto tú. El resultado puede ser el aviso de web hackeada en los resultados, una acción manual o una caída fuerte de posiciones.

No todo HTML distinto es cloaking. Una caché, una CDN, un banner de cookies o una prueba A/B pueden servir versiones ligeramente diferentes. Lo que delata un hackeo es que la diferencia sea contenido o enlaces de spam.

Cómo saber si te pasa

1. Mira lo que tiene Google

Busca site:tudominio.com y añade términos como viagra, casino o replica. Fíjate en los títulos y descripciones: si salen con spam y tú no lo ves al entrar, ya tienes la pista.

2. Usa la inspección de URL de Search Console

Es la prueba buena, porque Google pide la página desde sus propios servidores. Pega la URL de la portada (o de la página sospechosa), pulsa «Probar URL publicada» y luego «Ver página probada» → «HTML». Busca dentro términos de spam y enlaces a dominios que no conoces. Revisa también «Problemas de seguridad» y «Acciones manuales».

3. Compara desde terminal

URL="https://tudominio.com/"
GB="Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
curl -s "$URL" | grep -oiE "viagra|cialis|casino|apuestas|replica|slot" | sort | uniq -c
curl -s -A "$GB" "$URL" | grep -oiE "viagra|cialis|casino|apuestas|replica|slot" | sort | uniq -c
curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -e "https://www.google.com/" "$URL"
curl -s -A "$GB" "$URL" | wc -c ; curl -s "$URL" | wc -c

Si como Googlebot salen términos que no salen como visitante, o el tamaño de la página cambia mucho, o la visita con Referer de Google acaba en otro dominio, es cloaking. Prueba también con una URL interna que hayas visto con spam en Google.

Si curl no muestra diferencias pero la inspección de URL sí, el código comprueba la IP de Google. No hace falta que lo reproduzcas: la inspección de URL ya es la prueba.

4. Prueba como una visita normal

Cierra sesión en WordPress, abre una ventana privada en el móvil, busca tu marca en Google y entra desde el resultado. Muchas redirecciones solo saltan así.

Cómo limpiar el cloaking en WordPress paso a paso

1. Lo básico de cualquier hackeo

Copia de cómo está la web, cambio de todas las contraseñas (WordPress, hosting, FTP/SFTP, base de datos) y cierre de sesiones con wp config shuffle-salts. Detallado en la guía general.

2. Busca el código que decide

Está en uno de estos sitios, de más a menos habitual en lo que vemos:

• Reglas en .htaccess que miran el User-Agent o el Referer y reescriben la petición.
• PHP que lee el User-Agent o el Referer, en el functions.php del tema, en mu-plugins, en un plugin falso o al principio de index.php o wp-config.php.
• Un .user.ini o php.ini con auto_prepend_file, que carga un PHP malicioso antes que WordPress en cada petición.
• Código guardado en la base de datos (en wp_options) que un fichero pequeño lee y ejecuta.

find . -name ".htaccess" -exec grep -HniE "HTTP_USER_AGENT|HTTP_REFERER|googlebot" {} \;
find . -name ".user.ini" -o -name "php.ini" | xargs grep -Hn "auto_prepend_file"
grep -rlniE "googlebot|HTTP_REFERER" --include=*.php wp-content/themes wp-content/mu-plugins
grep -rlE "eval\(|base64_decode\(|gzinflate\(" --include=*.php . | grep -v "/vendor/"
wp core verify-checksums
wp plugin verify-checksums --all

Cuidado con los falsos positivos: plugins de caché, de SEO o de seguridad leen legítimamente el User-Agent. Lo sospechoso es un fichero que no pertenece a ningún plugin conocido, con código ofuscado o con una lista de buscadores junto a texto o URLs de spam.

En la base de datos, busca opciones con contenido codificado o enlaces raros:

wp db query "SELECT option_name, LENGTH(option_value) AS tam FROM wp_options WHERE option_value LIKE '%base64%' OR option_value LIKE '%googlebot%' ORDER BY tam DESC LIMIT 20"

Cambia wp_ por tu prefijo (wp db prefix). Antes de borrar una opción, mira de qué plugin es.

3. Reinstala lo que no puedas revisar

Núcleo y plugins del repositorio con --force; plugins y temas de pago, desde la web del fabricante. Restaura .htaccess a las reglas estándar de WordPress (más las de tu caché o tu plugin de seguridad, si las necesitas):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

4. Cierra la puerta de entrada

Revisa plugins con vulnerabilidades conocidas, administradores que no reconoces y contraseñas de aplicación. Si no sabes por dónde entraron, el cloaking volverá.

5. Comprueba y pide la revisión

Repite la inspección de URL y los curl: Googlebot y visitante tienen que recibir lo mismo. Después, en «Problemas de seguridad» o en «Acciones manuales», pide la revisión explicando qué has limpiado.

Errores habituales

• Comprobar solo desde tu navegador con sesión iniciada. Es justo lo que el código está preparado para engañar.
• Creer que es un problema de caché de Google. Si la inspección de URL en vivo ve spam, no es caché: es cloaking en WordPress y hay que limpiarlo.
• Borrar el .htaccess y olvidarse del .user.ini. El código sigue cargándose antes que WordPress.
• Limpiar sin pedir la revisión. El aviso puede seguir semanas en los resultados.

Para agencias: detectar el spam que solo ve Google

El cloaking está hecho para que no lo veas tú, ni tu cliente, ni nadie que entre en la web. Por eso Jeffrey descarga cada día la portada de cada web dos veces: como un visitante y como Googlebot. Si encuentra spam de farmacia, casinos o apuestas, o un bloque de texto japonés o chino, abre un aviso crítico y te avisa al momento. Cuando el spam solo aparece en la versión de Googlebot, el aviso lo dice así: la web enseña spam solo a Google, que es señal de hackeo.

Con los enlaces pasa igual: Jeffrey revisa como visitante y como Googlebot los enlaces de la portada y de hasta 4 páginas internas, y avisa de enlaces a casinos, farmacia o apuestas y de enlaces ocultos a otras webs.

Un límite que conviene saber: Jeffrey se presenta como Googlebot desde sus propios servidores, así que una variante que compruebe la IP real de Google solo se ve con la inspección de URL de Search Console. Y Jeffrey no analiza los ficheros del servidor en busca de malware: vigila lo que se ve desde fuera.

Si es urgente y no sabes por dónde empezar, escríbenos y lo miramos.

Preguntas frecuentes