El sitio muestra a un usuario de habla inglesa de EE. UU. una página, mientras que Googlebot, que físicamente se encuentra en el centro de datos de Mountain View, ve una completamente diferente. Formalmente, esto ya es cloaking, incluso si solo querías adaptar el contenido a la región. Analizamos 6 errores típicos de geo-redirecciones que hacen que los sitios pierdan posiciones, reciban sanciones manuales y se bloqueen dominios enteros en redes de afiliados.
Qué es la geo-redirección y por qué es necesaria para los negocios
La geo-redirección es un mecanismo que redirige automáticamente al usuario a la versión del sitio adaptada a su país: otro idioma, moneda, precios, ofertas. Las tiendas en línea la utilizan para que un comprador de Alemania acceda directamente a la versión en alemán con precios en euros, en lugar de navegar por un catálogo en dólares. Los arbitrajistas aplican geo-redirecciones en combinaciones para mostrar diferentes ofertas según el tráfico geográfico: por ejemplo, a los usuarios de países de Tier-1 una landing page, y a los demás, una página de reemplazo o un producto diferente.
El problema es que la misma lógica que determina el país del usuario por IP también se aplica a Googlebot. Y las direcciones IP de los bots de Google se encuentran físicamente en EE. UU., independientemente de si están indexando una página para la búsqueda en Rusia, Kazajistán o Alemania. Si el sistema de geo-redirección no distingue entre un crawler y una persona real, el resultado es el mismo: Google ve una página diferente a la que ven los visitantes reales. Esta es la definición formal de cloaking según las recomendaciones de Google Search Central, y la sanción por ello varía desde una disminución en el ranking hasta la exclusión total del dominio del índice.
Por qué Googlebot y un humano ven diferentes páginas
La discrepancia ocurre por tres razones al mismo tiempo, y generalmente se superponen. En primer lugar, Googlebot rastrea el sitio desde direcciones IP que pertenecen a Google, y estas direcciones son identificadas por servicios geográficos (MaxMind, IP2Location y similares) como estadounidenses en casi el 100% de los casos. En segundo lugar, Googlebot envía su propio User-Agent, que a menudo es procesado por una rama de código separada: a veces intencionalmente, para no romper la indexación, y a veces simplemente por error del desarrollador. En tercer lugar, el comportamiento de Googlebot durante el renderizado de JS es diferente al del navegador del usuario: el crawler puede no ejecutar la redirección que depende de JavaScript del lado del cliente, y entonces indexa una versión completamente diferente de la página que ve una persona con JS habilitado.
Agregue a esto el almacenamiento en caché de CDN, que puede "atascarse" en la versión de un país y entregarla a todos, y obtendrá una situación en la que, incluso sin mala intención por parte del propietario del sitio, el motor de búsqueda indexa contenido que no coincide con lo que ve la audiencia. A continuación, se presentan seis escenarios concretos en los que esto ocurre con mayor frecuencia.
Error 1: redirección por IP sin verificar el User-Agent del bot
El error más común es que la lógica de redirección se basa exclusivamente en la determinación del país por IP, sin ninguna verificación de quién está haciendo la solicitud: una persona o un crawler. Como resultado, Googlebot, que accede desde un rango de IP estadounidense, automáticamente termina en la versión US del sitio, incluso si la página originalmente se promovía para consultas desde Rusia o Kazajistán. Después de unas semanas de rastreo, el índice de Google se llena de la "versión incorrecta" del contenido, y las posiciones en las regiones objetivo comienzan a caer sin una razón aparente.
La solución es siempre excluir User-Agents e IPs de rangos conocidos de bots de búsqueda (Googlebot, Bingbot, YandexBot) de la geo-redirección, entregándoles la versión canónica de la página independientemente del país determinado. La verificación del User-Agent es una barrera necesaria, pero no suficiente, porque es fácil de falsificar, por lo que proyectos serios verifican adicionalmente la IP a través de una consulta DNS inversa, como recomienda la propia documentación de Google para verificar Googlebot.
Error 2: pruebas con IP de centros de datos en lugar de reales de usuarios
El segundo error ocurre ya en la etapa de verificación. Un desarrollador o un especialista en marketing prueba la geo-redirección a través de un proxy de centro de datos o VPN común, y la lógica se activa como si fuera un usuario real del país deseado. Pero las IP de centros de datos son fácilmente distinguibles del tráfico doméstico: muchos CDN y sistemas antifraude las marcan con una bandera separada, y parte de la lógica de geo-targeting puede comportarse de manera diferente para tales direcciones que para una IP doméstica normal del proveedor.
Como resultado, la prueba "pasa", la redirección en el servidor de desarrollo funciona perfectamente, y en producción, los usuarios reales del país objetivo reciben una versión incorrecta, porque la base de geolocalización del proveedor o la regla de CDN interpreta su IP de manera diferente a la dirección de prueba del centro de datos. Para una verificación correcta, es recomendable utilizar proxies residenciales — tienen IP de proveedores domésticos reales en el país deseado, y los servicios geográficos los identifican de la misma manera que identificarían a un usuario real. Esto proporciona una imagen honesta de lo que verá un visitante real del sitio, y no una versión simplificada para una IP "típica" de centro de datos.
Error 3: caché y falta de encabezados Vary
Si el sitio está detrás de un CDN (Cloudflare, Fastly, Akamai) y la geo-redirección se implementa a nivel del servidor de origen, y no del propio CDN, es fácil caer en una situación en la que el CDN almacena en caché la primera versión entregada de la página y la distribuye a todos, independientemente del país del siguiente visitante. Esto ocurre cuando la respuesta del servidor no incluye el encabezado correcto Vary: Accept-Language o una clave de caché similar por criterio geográfico.
En este caso, Googlebot puede encontrar la versión "correcta" en su primera visita, almacenarla en sus propios sistemas de indexación, y luego recibir la misma versión durante semanas en visitas posteriores, incluso si el contenido para otros países ha cambiado hace tiempo. Mientras tanto, los usuarios ven una versión actual, pero diferente — la desincronización aumenta gradualmente y es difícil de diagnosticar sin una comparación directa de las respuestas del servidor para diferentes geografías a través de herramientas como curl con sustitución de encabezados o a través de proxies con la geolocalización necesaria.
Error 4: redirección JS que el bot interpreta de manera diferente
Googlebot puede ejecutar JavaScript, pero lo hace con un retraso significativo (la segunda ola de renderizado puede tardar días) y no siempre de manera idéntica al navegador del usuario. Si la redirección geográfica se implementa a través de JS del lado del cliente — por ejemplo, a través de window.location después de una solicitud fetch a la geo-API — existe el riesgo de que en la primera pasada el crawler indexe la página antes de que se active la redirección, es decir, una versión "incorrecta" para la región específica del contenido.
Esto es especialmente crítico para las landing pages de una sola página (SPA), donde toda la lógica de personalización se mantiene del lado del cliente. El enfoque correcto es realizar la identificación geográfica y la redirección del lado del servidor (función edge del CDN, middleware en Node.js, regla en Nginx), para que Googlebot y el usuario reciban una redirección HTTP 302 antes de que la página comience a renderizarse en el navegador. Esto elimina la dependencia de cómo exactamente el crawler procesará el JS en un momento específico.
Error 5: una URL sin hreflang para diferentes versiones de idioma
El quinto error es intentar servir varias versiones de idioma en la misma URL sin marcado hreflang. Google recomienda directamente: si el contenido en una URL difiere según la localidad del usuario, se debe proporcionar diferentes URL para cada versión (subdominios, subcarpetas o dominios separados) con marcado hreflang cruzado, o mostrar honestamente la misma versión a todos, incluidos los bots, añadiendo la posibilidad de cambiar manualmente el idioma.
Sin hreflang, Google no puede entender físicamente que /product en ruso y /product en inglés son intencionadamente contenido diferente para diferentes audiencias, y no un intento de ocultar una versión del índice en favor de otra. El resultado es que se indexa una versión aleatoria (generalmente la que estaba disponible para el bot en el último rastreo), y esa es la que comienza a clasificarse en todas las regiones simultáneamente, lo que afecta negativamente a la relevancia de los resultados y a la conversión.
Error 6: sin fallback para usuarios con VPN y proxies móviles
El sexto error se refiere no tanto a Googlebot, sino a los usuarios reales — pero está directamente relacionado con el tema de las geo-redirecciones, porque a menudo es el intento de "arreglar" el comportamiento para los bots lo que lo rompe para las personas reales con VPN o internet móvil. Los usuarios de operadores móviles a menudo acceden a la red a través de CGNAT (Carrier-Grade NAT), cuando decenas de miles de abonados utilizan la misma IP externa, y la base geográfica puede identificar tal IP como perteneciente a un país vecino o incluso erróneamente.
Si el sitio no tiene un interruptor manual de país/idioma como fallback, un usuario con una IP "incorrectamente" identificada se queda atrapado en una versión irrelevante sin posibilidad de cambiarla — y simplemente se va. Para probar exactamente este escenario, es recomendable verificar el comportamiento del sitio a través de proxies móviles, que emulan IP de operadores de telefonía móvil reales con el comportamiento característico de CGNAT en geolocalización — esto ayuda a ver el problema antes de que lo descubran los usuarios reales y escriban al soporte.
Cómo verificar la geo-redirección desde la perspectiva de Google en diferentes países
La herramienta principal para el diagnóstico inicial es la función "Ver como Googlebot" en Google Search Console (herramienta de verificación de URL), que muestra qué HTML recibe realmente el crawler de Google. Si allí se muestra una versión diferente a la que ves en tu navegador desde tu país, — el problema está confirmado. Pero Search Console siempre rastrea desde IP estadounidenses, por lo que para comparar el comportamiento del sitio por regiones se necesita una capa de prueba separada.
En la práctica, los especialistas en marketing y SEO crean varios perfiles en un navegador anti-detección — Dolphin Anty, AdsPower, Multilogin o GoLogin — y asocian a cada perfil un proxy del país necesario, para seguir manualmente el camino del usuario: abrir el sitio, ver qué versión se carga, qué encabezado Accept-Language se envió, si se activó la redirección y a qué URL. Para tales verificaciones, son convenientes proxies residenciales con selección específica de ciudad u operador — proporcionan la simulación más honesta de un visitante real, a diferencia de las direcciones de centros de datos, que algunos servicios pueden marcar como sospechosas incluso antes de evaluar la geolocalización.
| Tipo de proxy | Para qué tipo de verificación es adecuado | Riesgo de resultado falso |
|---|---|---|
| Proxies residenciales | Simulación de un usuario doméstico normal en el país/ciudad deseada | Bajo |
| Proxies móviles | Verificación del comportamiento bajo CGNAT y geolocalización móvil | Bajo |
| Proxies de centros de datos | Verificación rápida del hecho de la activación de la redirección por país | Más alto: parte de las bases geográficas marcan IP de manera diferente que las domésticas |
Para verificar exactamente el comportamiento de la lógica del servidor (y no el renderizado visual) es útil también observar la respuesta cruda del servidor a través de curl con sustitución del User-Agent por Googlebot y el encabezado X-Forwarded-For por la IP del país deseado — esto mostrará qué estado HTTP y Location devuelve el servidor antes de cualquier renderizado de JS, y permitirá detectar el error 4 y el error 1 de la lista anterior con un solo comando.
Lista de verificación para una configuración segura de geo-redirecciones
- Googlebot, Bingbot y YandexBot están excluidos de la lógica de geo-redirección por User-Agent y confirmados a través de DNS inverso
- La redirección se implementa del lado del servidor (302/307), y no solo a través de JavaScript del lado del cliente
- Se ha configurado el encabezado
Varypara el almacenamiento en caché correcto de CDN por geografía/idioma - Para cada versión de idioma hay una URL separada con marcado hreflang cruzado
- Hay un interruptor manual visible de país/idioma como fallback para IPs erróneamente identificadas
- Las pruebas se realizan a través de proxies residenciales y móviles de los países deseados, y no solo a través de direcciones de centros de datos
- Una vez al trimestre se verifica qué muestra Google Search Console — la versión coincide con lo que ven los usuarios reales
Conclusión
La discrepancia entre lo que ve Googlebot y lo que ve un usuario rara vez es un engaño intencionado al motor de búsqueda — más a menudo es una deuda técnica acumulada: redirección por IP sin verificar el bot, caché sin encabezado Vary, redirección JS que el crawler no logra ejecutar, y falta de hreflang para versiones de idioma. Cada uno de estos errores por separado parece trivial, pero juntos crean una imagen clásica de cloaking a los ojos de Google — con las sanciones correspondientes.
La única manera confiable de asegurarse de que el sitio se comporta de manera honesta tanto para bots como para personas es verificarlo regularmente desde IP reales de los países necesarios. Para tal diagnóstico, recomendamos utilizar proxies residenciales para simular un usuario doméstico típico y proxies móviles para verificar escenarios con CGNAT — esto proporciona la imagen más honesta de lo que realmente ve tu audiencia en cada región, y ayuda a detectar problemas antes de que los encuentre el algoritmo de Google.