El SEO cloaking consiste en mostrar a los buscadores una versión de una página y a las personas otra. El rastreador recibe una página limpia y rica en palabras clave que posiciona; el visitante que hace clic recibe otra cosa, a menudo una redirección, una oferta distinta o spam sin más. Google incluye el cloaking en sus políticas sobre spam, y un sitio al que se descubre haciéndolo puede perder posiciones en páginas concretas o en todo el dominio.
La mayoría de los equipos se encuentran con el cloaking desde el lado defensivo: un sitio hackeado que posiciona para términos de farmacia o casino que su propietario nunca ha visto, o un competidor cuya página posicionada no coincide con lo que prometía el snippet. En ambos casos, encontrarlo es un problema de monitorización SEO: hay que ver la página tal como la ve cada tipo de visitante y comparar.
Qué se considera cloaking
La definición de Google se centra en la intención: presentar contenido distinto a usuarios y buscadores para manipular el posicionamiento y engañar a los usuarios. Entre sus propios ejemplos figuran servir al rastreador una página sobre destinos de viaje mientras los visitantes reciben una página sobre medicamentos con descuento, e insertar texto o palabras clave solo cuando quien hace la petición es un buscador.
El mecanismo es siempre el mismo. El servidor, o un script de la página, decide qué enviar en función de quién parece estar preguntando. Las señales que utiliza son:
- User agent. La versión burda: todo lo que diga “Googlebot” recibe la página limpia.
- Dirección IP. La versión cuidadosa: las peticiones procedentes de los rangos de rastreadores publicados por Google, verificadas mediante DNS inverso, reciben la página limpia, de modo que falsificar el user agent no basta para desbloquearla.
- Referrer. Los visitantes que llegan desde una página de resultados de Google reciben la redirección; quienes escriben la URL, incluido el propietario del sitio, ven un sitio normal.
- Ubicación y red. Los visitantes del país objetivo con conexiones domésticas reciben la carga maliciosa; los rangos de oficinas, nube y centros de datos reciben la versión limpia, porque de ahí proceden los revisores y los escáneres de seguridad.
- Dispositivo. Algunos esquemas redirigen solo a los visitantes móviles, porque es ahí donde monetizan.
La mayoría de los casos reales combinan dos o tres de estas señales, y por eso una sola comprobación desde la propia mesa no suele mostrar nada.
Qué no es cloaking
Muchas configuraciones legítimas sirven respuestas distintas a visitantes distintos. Google indica que son correctas siempre que el rastreador vea lo que vería un usuario comparable:
- Personalización geográfica y de idioma. Mostrar precios en euros a los visitantes de Alemania no es cloaking. Tratar a Googlebot de forma distinta a un usuario situado en el mismo lugar sí lo sería. Nuestra guía sobre resultados de Google localizados explica cómo la ubicación cambia lo que ve la gente.
- Muros de pago y contenido restringido. Google documenta datos estructurados para contenido de pago precisamente para que los editores puedan dejar que el rastreador vea el artículo completo sin que cuente como cloaking.
- Diseños específicos por dispositivo. Un marcado distinto para móvil y escritorio es correcto cuando el contenido principal es equivalente.
- Renderizado para bots. Servir HTML prerrenderizado a los rastreadores se recomendó en su día como solución provisional para JavaScript pesado. Google ahora lo considera una solución provisional y no una solución a largo plazo, pero no es cloaking cuando el contenido coincide.
La prueba en cada caso es la misma pregunta: ¿recibiría un usuario real en la posición del rastreador el mismo contenido?
Por qué no se puede comprobar desde un solo lugar
Una página con cloaking está diseñada para parecer limpia precisamente ante quienes tienen más probabilidades de revisarla. Eso genera tres puntos ciegos:
- El propio equipo es la audiencia excluida. Si se revisa el propio sitio con la sesión iniciada, desde la oficina o escribiendo la URL, un hackeo basado en el referrer nunca se mostrará. Los propietarios de sitios suelen enterarse por Search Console o por sus clientes.
- Nadie puede ser Googlebot. Enviar un user agent de Googlebot solo detecta el cloaking burdo. Cualquier esquema que verifique la IP del rastreador tratará la petición como la de un usuario.
- Se está en el mercado o la red equivocados. Un esquema que solo se activa para visitantes móviles de un país con conexiones domésticas es invisible desde un servidor en la nube de otro.
Por tanto, la detección es una comparación, ejecutada desde suficientes puntos de observación para cubrir las condiciones que filtra el cloaker.
Un flujo de detección
Paso 1: obtener primero la vista de Google. En Search Console, la prueba en directo de la herramienta URL Inspection obtiene la página como Googlebot desde la propia infraestructura de Google y muestra el HTML renderizado y una captura de pantalla. El Rich Results Test hace lo mismo con páginas que no son propias. Es la única forma fiable de ver la versión del rastreador, porque procede de una IP real de Googlebot.
Paso 2: recopilar las vistas de usuario. Obtener la misma URL como visitantes corrientes, variando una condición cada vez:
| Variante | User agent | Referrer | Red |
|---|---|---|---|
| Base | Navegador de escritorio | ninguno | la oficina |
| Desde búsqueda | Navegador de escritorio | página de resultados de google.com | la oficina |
| Móvil desde búsqueda | Navegador móvil | página de resultados de google.com | IP doméstica en el país objetivo |
| Escritorio desde búsqueda, mercado | Navegador de escritorio | página de resultados de google.com | IP doméstica en el país objetivo |
| Comprobación burda de bot | Cadena de Googlebot | ninguno | la oficina |
Las filas con IP doméstica son donde entra un proxy residencial: una conexión doméstica en el país que se está probando, de modo que la petición parece la de los visitantes que el esquema espera. Hay que mantener la configuración regional, la zona horaria y el idioma coherentes con el país de salida, como se explica en nuestra guía sobre cómo alinear geolocalización, zona horaria y configuración regional del proxy; de lo contrario, un esquema bien construido tratará la petición como una anomalía.
Paso 3: comparar lo que importa. El HTML en bruto difiere entre dos peticiones cualesquiera por los tokens y las marcas de tiempo. Conviene comparar las partes que cambian el posicionamiento o la experiencia del visitante:
- la URL final tras las redirecciones, y cada salto de la cadena;
- el título, la meta description, el canonical y las directivas robots;
- el texto principal, normalizado y con hash;
- los enlaces salientes, sobre todo hacia dominios desconocidos.
Paso 4: repetir. Los hackeos y los esquemas de la competencia a menudo solo se activan para una parte de las visitas, o solo a ciertas horas. Un único resultado limpio es una prueba débil. Conviene ejecutar la matriz varias veces con distintas salidas y a distintas horas del día antes de concluir que una página está limpia.
Este es un script mínimo de comparación. Basta con asignar a PROXY_URL un gateway residencial con un país objetivo y añadir más variantes para cada mercado de interés:
import hashlib, os, re
import requests
URL = "https://example.com/some-page"
DESKTOP = "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0 Safari/537.36"
MOBILE = "Mozilla/5.0 (iPhone; CPU iPhone OS 18_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.0 Mobile/15E148 Safari/604.1"
GOOGLEBOT = "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
SERP = "https://www.google.com/"
RESI = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}
VARIANTS = {
"baseline": dict(ua=DESKTOP, ref=None, proxies=None),
"from_search": dict(ua=DESKTOP, ref=SERP, proxies=None),
"mobile_market": dict(ua=MOBILE, ref=SERP, proxies=RESI),
"desktop_market": dict(ua=DESKTOP, ref=SERP, proxies=RESI),
"googlebot_ua": dict(ua=GOOGLEBOT, ref=None, proxies=None),
}
def tag(html, pattern):
m = re.search(pattern, html, re.I | re.S)
return m.group(1).strip() if m else ""
def fingerprint(ua, ref, proxies):
headers = {"User-Agent": ua, "Accept-Language": "en-US,en;q=0.9"}
if ref:
headers["Referer"] = ref
r = requests.get(URL, headers=headers, proxies=proxies, timeout=30)
html = r.text
text = re.sub(r"<script.*?</script>|<style.*?</style>|<[^>]+>", " ", html, flags=re.S)
text = re.sub(r"\s+", " ", text).strip().lower()
return {
"final_url": r.url,
"hops": [h.headers.get("Location", "") for h in r.history],
"title": tag(html, r"<title[^>]*>(.*?)</title>"),
"canonical": tag(html, r'<link[^>]+rel=["\']canonical["\'][^>]+href=["\']([^"\']+)'),
"robots": tag(html, r'<meta[^>]+name=["\']robots["\'][^>]+content=["\']([^"\']+)'),
"text_hash": hashlib.sha256(text.encode()).hexdigest()[:12],
}
results = {name: fingerprint(**v) for name, v in VARIANTS.items()}
base = results["baseline"]
for name, res in results.items():
diffs = [k for k in res if res[k] != base[k]]
print(f"{name:15} {'SAME' if not diffs else 'DIFFERS: ' + ', '.join(diffs)}")Una diferencia solo en text_hash puede ser una personalización inofensiva. Una final_url distinta, un nuevo salto de redirección o un título que solo aparece para los visitantes que llegan desde la búsqueda es el patrón que hay que investigar. Después, conviene comparar las vistas de usuario con el HTML de la prueba en directo de URL Inspection.
Qué hacer al encontrarlo
En el propio sitio, hay que tratarlo antes que nada como un incidente de seguridad. El cloaking basado en referrer e IP en un sitio que no se ha construido así casi siempre implica una intrusión: reglas de servidor inyectadas, un plugin o tema modificado, o un script añadido a la plantilla. Hay que eliminar el código, cerrar el agujero por el que entró y, si Google ha aplicado una acción manual, solicitar una revisión en Search Console. Después, conviene volver a ejecutar la matriz de comparación desde los mismos mercados para confirmar que ha desaparecido.
En el sitio de un competidor, hay que documentar antes de denunciar. Conviene capturar la versión del rastreador desde el Rich Results Test, las versiones de usuario con marca de tiempo, país de salida y dispositivo, y la cadena de redirecciones completa. Google acepta denuncias de spam a través de su formulario de calidad de búsqueda. Para la versión de búsqueda de pago del mismo comportamiento, nuestra guía sobre cómo detectar anuncios con cloaking y segmentación geográfica cubre el lado publicitario.
Seguir monitorizando. Los hackeos vuelven cuando no se corrige el punto de entrada, y tienden a reaparecer en las páginas que mejor posicionan. Una ejecución semanal de la matriz sobre las principales landing pages, desde los países que generan tráfico orgánico, es una alerta temprana barata.
Preguntas frecuentes
¿Es ilegal el SEO cloaking?
Normalmente no es una cuestión legal; es una infracción de las políticas de un buscador. Google lo incluye en sus políticas sobre spam y puede degradar o eliminar las páginas que lo utilizan. Cuando el cloaking oculta estafas o malware, pueden aplicarse otras leyes al propio contenido.
¿Mostrar contenido distinto según el país es cloaking?
No por sí mismo. Localizar precios, idioma u ofertas por país es normal. Se convierte en cloaking cuando el rastreador recibe un trato distinto al de un usuario en la misma situación.
¿Se puede comprobar el cloaking cambiando el user agent a Googlebot?
Solo en el caso del cloaking burdo. Los esquemas cuidadosos verifican la IP del rastreador, así que un user agent falsificado se trata como un visitante corriente. Para ver la vista real de Google hay que usar la prueba en directo de URL Inspection de Search Console o el Rich Results Test.
¿Por qué hacen falta IP residenciales para detectar el cloaking?
Muchos esquemas solo muestran su carga maliciosa a visitantes corrientes de un mercado objetivo y muestran una página limpia a las direcciones de oficinas, nube y centros de datos. Comprobar desde conexiones domésticas en ese mercado es la forma de ver lo que reciben esos visitantes.
En resumen
El cloaking se oculta de quien tiene más probabilidades de revisarlo, así que un solo vistazo desde la propia mesa demuestra poco. Hay que obtener la vista de Google con sus propias herramientas, recopilar vistas de usuario con distintos referrers, dispositivos y conexiones domésticas en los mercados relevantes, comparar URL finales, títulos y contenido principal, y repetir antes de dar una página por limpia. Si se trata del propio sitio, cualquier hallazgo debe tratarse como una intrusión y hay que corregir el punto de entrada. Para seguir cómo aparecen las páginas en muchas ubicaciones a lo largo del tiempo, puede consultarse nuestra guía de seguimiento de posiciones en geo-grid.