O site mostra a um usuário de língua inglesa dos EUA uma página, enquanto o Googlebot, que fisicamente está no data center de Mountain View, vê uma completamente diferente. Formalmente, isso já é cloaking, mesmo que você apenas quisesse adaptar o conteúdo para a região. Analisamos 6 erros típicos de geo-redirects que fazem os sites perderem posições, receber sanções manuais e banir domínios inteiros em redes de parceiros.
O que é geo-redirect e por que é necessário para os negócios
O geo-redirect é um mecanismo que redireciona automaticamente o usuário para a versão do site adaptada ao seu país: outro idioma, moeda, preços, ofertas. Lojas online o utilizam para que um comprador da Alemanha acesse imediatamente a versão em alemão com preços em euros, em vez de navegar por um catálogo em dólares. Os afiliados usam geo-redirects em suas campanhas para mostrar ofertas diferentes dependendo do tráfego geográfico — por exemplo, usuários de países Tier-1 recebem uma landing page, enquanto os demais recebem uma página de espera ou um produto diferente.
O problema é que a mesma lógica que determina o país do usuário pelo IP também se aplica ao Googlebot. E os endereços IP dos bots do Google estão fisicamente localizados nos EUA, independentemente de estarem indexando uma página para resultados russos, cazaques ou alemães. Se o sistema de geo-redirect não distingue o crawler de um ser humano, o resultado é um — o Google vê uma página diferente da que os visitantes reais veem. Esta é a definição formal de cloaking de acordo com as diretrizes do Google Search Central, e a punição por isso varia de uma queda no ranking até a exclusão total do domínio do índice.
Por que o Googlebot e os humanos veem páginas diferentes
A discrepância ocorre por três razões simultaneamente, e geralmente elas se sobrepõem. Primeiro, o Googlebot rastreia o site a partir de endereços IP pertencentes ao Google, e esses endereços são identificados por serviços geográficos (MaxMind, IP2Location e similares) como americanos em quase 100% dos casos. Em segundo lugar, o Googlebot envia seu próprio User-Agent, que muitas vezes é tratado em um ramo de código separado — às vezes intencionalmente, para não quebrar a indexação, e outras vezes apenas por erro do desenvolvedor. Em terceiro lugar, o comportamento do Googlebot ao renderizar JS é diferente do comportamento do navegador do usuário: o crawler pode não executar o redirect que depende do JavaScript do cliente, e então ele indexa uma versão da página completamente diferente da que o usuário vê com o JS ativado.
Adicione a isso o cache de CDN, que pode "grudar" na versão de um país e entregá-la a todos, e você terá uma situação em que, mesmo sem a má intenção do proprietário do site, o mecanismo de busca indexa conteúdo que não corresponde ao que a audiência vê. Abaixo estão seis cenários específicos em que isso acontece com mais frequência.
Erro 1: redirect por IP sem verificação do User-Agent do bot
O erro mais comum é que a lógica de redirecionamento é construída exclusivamente na determinação do país pelo IP, sem qualquer verificação de quem está fazendo a solicitação: um humano ou um crawler. Como resultado, o Googlebot, que acessa a partir de um intervalo de IP americano, automaticamente vai para a versão dos EUA do site, mesmo que a página tenha sido originalmente promovida para consultas da Rússia ou do Cazaquistão. Após algumas semanas de rastreamento, o índice do Google fica saturado com a "versão errada" do conteúdo, e as posições nos regiões-alvo começam a cair sem uma razão aparente.
A solução é sempre excluir User-Agents e intervalos de IP conhecidos dos bots de busca (Googlebot, Bingbot, YandexBot) do geo-redirect, entregando a eles a versão canônica da página independentemente do país determinado. A verificação do User-Agent é uma barreira necessária, mas não suficiente, porque é fácil de falsificar, portanto, projetos sérios verificam adicionalmente o IP através de uma consulta DNS reversa, como recomenda a própria documentação do Google para verificar o Googlebot.
Erro 2: teste com IPs de data center em vez de usuários reais
O segundo erro ocorre já na fase de teste. O desenvolvedor ou o profissional de marketing testa o geo-redirect através de um proxy de data center comum ou VPN, e a lógica aciona como se fosse um usuário real do país desejado. Mas os IPs de data center são facilmente distinguíveis do tráfego doméstico — muitos CDNs e sistemas antifraude os marcam com uma bandeira separada, e parte da lógica de geo-targeting pode se comportar de maneira diferente para esses endereços do que para um IP doméstico comum.
Como resultado, o teste "passa", o redirecionamento no servidor de desenvolvimento funciona perfeitamente, mas na produção os usuários reais do país-alvo recebem a versão errada, porque a base de geolocalização do provedor ou a regra do CDN interpreta seu IP de maneira diferente do endereço de data center de teste. Para uma verificação correta, é recomendável usar proxies residenciais — eles têm IPs de provedores domésticos reais no país desejado, e os serviços geográficos os identificam da mesma forma que identificariam um usuário real. Isso fornece uma imagem honesta do que um visitante real do site verá, e não uma versão simplificada para um IP "típico" de data center.
Erro 3: cache e ausência de cabeçalhos Vary
Se o site está atrás de um CDN (Cloudflare, Fastly, Akamai) e o geo-redirect é implementado no nível do servidor de origem, e não no próprio CDN, é fácil cair na situação em que o CDN cacheia a primeira versão da página entregue e a distribui para todos — independentemente do país do próximo visitante. Isso acontece quando a resposta do servidor não contém o cabeçalho correto Vary: Accept-Language ou uma chave de cache geográfica semelhante.
O Googlebot, nesse caso, pode encontrar a "versão correta" na primeira visita, cacheá-la em seus próprios sistemas de indexação, e então receber a mesma versão em visitas subsequentes, mesmo que o conteúdo para outros países tenha mudado há muito tempo. Enquanto isso, os usuários veem uma versão atual, mas diferente — a desincronização aumenta gradualmente e é difícil de diagnosticar sem uma comparação direta das respostas do servidor para diferentes geos através de ferramentas como curl com substituição de cabeçalhos ou através de proxies com a geolocalização necessária.
Erro 4: JS-redirect que o bot interpreta de forma diferente
O Googlebot pode executar JavaScript, mas faz isso com uma considerável latência (a segunda onda de renderização pode levar dias) e nem sempre de forma idêntica ao navegador do usuário. Se o redirect por geo é implementado através de JS do cliente — por exemplo, através de window.location após uma solicitação fetch para o geo-API — há o risco de que, na primeira passagem, o crawler indexe a página antes que o redirect ocorra, ou seja, a versão "errada" para a região específica do conteúdo.
Isso é especialmente crítico para landing pages de uma única página (SPA), onde toda a lógica de personalização é mantida no lado do cliente. A abordagem correta é realizar a determinação geográfica e o redirect no lado do servidor (função edge do CDN, middleware em Node.js, regra no Nginx), para que o Googlebot e o usuário recebam um redirect HTTP 302 antes que a página comece a ser renderizada no navegador. Isso elimina a dependência de como exatamente o crawler processará o JS em um momento específico.
Erro 5: um URL sem hreflang para diferentes versões de idioma
O quinto erro é a tentativa de servir várias versões de idioma no mesmo URL sem a marcação hreflang. O Google recomenda claramente: se o conteúdo em um URL difere dependendo da localidade do usuário, é necessário fornecer URLs diferentes para cada versão (subdomínios, subpastas ou domínios separados) com marcação hreflang cruzada, ou mostrar honestamente a mesma versão para todos, incluindo bots, adicionando a possibilidade de alternar manualmente o idioma.
Sem hreflang, o Google fisicamente não pode entender que /product em russo e /product em inglês são conteúdos intencionalmente diferentes para diferentes audiências, e não uma tentativa de esconder uma versão do índice em favor de outra. O resultado é que uma versão aleatória (geralmente a que estava disponível para o bot na última vez que foi rastreada) entra no índice, e é essa versão que começa a ser ranqueada em todas as regiões simultaneamente, o que afeta negativamente a relevância dos resultados e a conversão.
Erro 6: sem fallback para usuários com VPN e proxies móveis
O sexto erro diz respeito não tanto ao Googlebot, mas aos usuários reais — mas está diretamente relacionado ao tema dos geo-redirects, porque muitas vezes a tentativa de "consertar" o comportamento para bots quebra para pessoas reais com VPN ou internet móvel. Usuários de operadoras móveis frequentemente acessam a internet através de CGNAT (Carrier-Grade NAT), quando dezenas de milhares de assinantes usam o mesmo IP externo, e a base de geo pode identificar esse IP como pertencente a um país vizinho ou até mesmo erradamente.
Se o site não tem um interruptor manual de país/idioma como fallback, o usuário com um IP "incorretamente" identificado fica preso em uma versão irrelevante sem a possibilidade de mudá-la — e simplesmente sai. Para testar exatamente esse cenário, é importante verificar o comportamento do site através de proxies móveis, que emulam IPs de operadores de telefonia real com o comportamento característico de geolocalização de CGNAT — isso ajuda a ver o problema antes que os usuários reais o descubram e entrem em contato com o suporte.
Como verificar o geo-redirect aos olhos do Google de diferentes países
A principal ferramenta para diagnóstico inicial é a função "Visualizar como Googlebot" no Google Search Console (ferramenta de verificação de URL), que mostra qual HTML o crawler do Google realmente recebe. Se a versão exibida não é a mesma que você vê no navegador do seu país, o problema está confirmado. Mas o Search Console sempre rastreia a partir de IPs americanos, portanto, para comparar o comportamento do site por regiões, é necessário um nível separado de teste.
Na prática, profissionais de marketing e especialistas em SEO criam vários perfis em um navegador anti-detectável — Dolphin Anty, AdsPower, Multilogin ou GoLogin — e vinculam a cada perfil um proxy do país desejado, para passar manualmente pelo caminho do usuário: abrir o site, ver qual versão foi carregada, qual cabeçalho Accept-Language foi enviado, se o redirect funcionou e para qual URL. Para essas verificações, são convenientes proxies residenciais com seleção pontual de cidade ou operador — eles proporcionam a simulação mais honesta de um visitante real, ao contrário dos endereços de data center, que alguns serviços podem marcar como suspeitos antes mesmo da avaliação geográfica.
| Tipo de proxy | Para qual verificação é adequado | Risco de resultado falso |
|---|---|---|
| Proxies residenciais | Simulação de um usuário doméstico comum no país/cidade desejada | Baixo |
| Proxies móveis | Verificação do comportamento em CGNAT e geolocalização móvel | Baixo |
| Proxies de data center | Verificação rápida do fato de o redirecionamento por país ter funcionado | Maior: parte das bases geográficas marca IPs de forma diferente do que os domésticos |
Para verificar exatamente o comportamento da lógica do servidor (e não a renderização visual), é útil também observar a resposta bruta do servidor através de curl com substituição do User-Agent para Googlebot e do cabeçalho X-Forwarded-For para o IP do país desejado — isso mostrará qual status HTTP e Location o servidor retorna antes de qualquer renderização JS, e permitirá capturar o erro 4 e o erro 1 da lista acima com apenas um comando.
Checklist para configuração segura de geo-redirects
- Googlebot, Bingbot e YandexBot excluídos da lógica de geo-redirect por User-Agent e confirmados através de DNS reverso
- Redirect implementado no lado do servidor (302/307), e não apenas através de JavaScript do cliente
- Cabeçalho
Varyconfigurado para cacheamento correto do CDN por geo/idioma - Para cada versão de idioma, há um URL separado com marcação hreflang cruzada
- Há um interruptor manual visível de país/idioma como fallback para IPs erroneamente identificados
- Testes realizados através de proxies residenciais e móveis dos países desejados, e não apenas através de endereços de data center
- Uma vez por trimestre, verifica-se o que o Google Search Console mostra — a versão coincide com o que os usuários reais veem
Conclusão
A discrepância entre o que o Googlebot vê e o que o usuário vê raramente é uma tentativa intencional de enganar o mecanismo de busca — geralmente é uma dívida técnica acumulada: redirect por IP sem verificação do bot, cache sem cabeçalho Vary, redirect JS que o crawler não consegue executar, e ausência de hreflang para versões de idioma. Cada um desses erros, isoladamente, pode parecer trivial, mas juntos eles criam um quadro clássico de cloaking aos olhos do Google — com as sanções correspondentes.
A única maneira confiável de garantir que o site se comporte de forma justa tanto para bots quanto para humanos é verificar regularmente com IPs reais dos países desejados. Para esse diagnóstico, recomendamos o uso de proxies residenciais para simular um usuário doméstico típico e proxies móveis para verificar cenários com CGNAT — isso fornece a imagem mais honesta do que sua audiência realmente vê em cada região e ajuda a identificar problemas antes que o algoritmo do Google os encontre.