Googlebot diz vir da Califórnia, mas o IP pode enganar você

Por anos, a suposição mais comum entre quem analisa logs de servidor foi que o Googlebot vem de Mountain View, Califórnia. Uma conversa recente no Bluesky, relatada pelo Search Engine Roundtable, deixou claro que essa localização é apenas um rótulo declarado, não um fato geográfico. Para quem opera sites no Brasil e depende de logs de rastreamento para diagnosticar indexação, essa distinção tem consequências práticas.

O que Gary Illyes realmente disse

A discussão começou quando John Mueller, do Google, comentou que "tenho quase certeza de que a localização física [do Googlebot] varia". Barry Schwartz, do Search Engine Roundtable, perguntou se não seria majoritariamente Califórnia, com alguns bots de teste vindo de outros lugares.

Gary Illyes respondeu com a explicação técnica que importa: "A localização do IP é declarada (isso é só um pedaço de texto que você define para os IPs que gerencia) como sendo US, Mountain View, na maioria dos casos, mas os pontos de saída reais variam." O exemplo dele foi direto: se o IP está atribuído a um cluster em Atlanta (ATL), o ponto de saída (egress point) será Atlanta, mesmo que o registro diga Califórnia.

Illyes foi além e desmontou a própria ideia de que endereços IP têm localização geográfica confiável: "Endereços IP não têm uma 'localização geográfica'. Eles normalmente assumem por padrão a localização do registrante, ou são atribuídos a algum lugar com base em rotas BGP anycast. Pense em endereços como 1.1.1.1 ou 8.8.8.8. Onde você os coloca no mapa? Eles estão tecnicamente em todo lugar."

Por que a geolocalização de IP mente

O ponto central é entender a diferença entre o que um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → de geolocalização diz e por onde o tráfego efetivamente sai. Os serviços de GeoIP (MaxMind, IP2Location e afins) trabalham com o registro WHOIS e o local declarado pelo dono do bloco de IPs. O Google, como registrante de imensos blocos, declara Mountain View por padrão. Isso não impede que a máquina que abre a conexão TCP esteja fisicamente em um data center de Atlanta, da Bélgica ou de São Paulo.

O BGP anycast agrava isso: um mesmo endereço IP pode ser anunciado a partir de múltiplos pontos de presença ao redor do mundo, e a rota que o pacote toma depende de qual nó está mais próximo da rede que faz a consulta. É por isso que 8.8.8.8 responde de dezenas de lugares diferentes. Nesse modelo, atribuir uma coordenada única ao IP é uma ficção conveniente para relatórios, não uma verdade operacional.

O impacto direto em quem valida crawl logs

Aqui está o erro que a nota do Search Engine Roundtable ajuda a evitar: nunca valide o Googlebot pela geolocalização do IP. Se um dev brasileiro olha o access log, vê um user-agent de Googlebot vindo de um IP que o GeoIP marca como Atlanta ou até fora dos EUA, e conclui que é um bot falso, ele pode acabar bloqueando o rastreador legítimo.

A validação correta sempre foi outra, e essa história só reforça isso. O método oficial do Google é o reverse DNS lookup em duas etapas:

1. Faça um DNS reverso no IP que aparece no log. Para o Googlebot legítimo, o resultado termina em googlebot.com ou google.com.
2. Faça um forward lookup no nome retornado e confirme que ele resolve de volta para o mesmo IP.

Em prática, com dig:

dig -x 66.249.66.1 +short
# retorna algo como crawl-66-249-66-1.googlebot.com
dig crawl-66-249-66-1.googlebot.com +short
# precisa retornar 66.249.66.1

O Google também publica as faixas de IP dos seus crawlers em arquivos JSON (googlebot.json e afins), o que permite validação sem depender de DNS. O ponto é: geolocalização não entra nessa conta em momento nenhum.

O caso do bloqueio por região

A nota lembra dois fatos relevantes para quem pensa em geo-blocking. Primeiro, bloquear tráfego dos EUA quebraria o rastreamento do Google de forma severa, já que a maior parte declara origem norte-americana. Segundo, o Google mantém os chamados locally-aware crawlers, capazes de rastrear a partir de regiões específicas quando o conteúdo do site muda conforme o país do visitante. Em 2011 houve inclusive rastreamento a partir da China, provavelmente por exigência legal regional.

Para um site brasileiro que serve conteúdo diferente por país (preços em real, idioma, disponibilidade), isso importa: o Googlebot pode aparecer com um ponto de saída que não bate com a Califórnia justamente porque está tentando ver o que um usuário de determinada região veria. Bloquear ou tratar diferente com base em GeoIP pode fazer o Google indexar a versão errada da página, ou nenhuma.

Quando isso não muda nada para você

Seja honesto sobre o escopo: se sua validação de bots já usa reverse DNS ou as faixas oficiais de IP, nada muda. Você já estava fazendo certo. A revelação de Illyes não introduz um comportamento novo do Googlebot, apenas explica o que sempre foi verdade sobre a natureza dos IPs.

O alerta vale para três situações concretas: quem escreveu regras de firewall ou WAF baseadas em país; quem usa ferramentas de análise de log que rotulam a origem do crawler por GeoIP e tira conclusões daí; e quem serve conteúdo geo-segmentado sem testar como o Googlebot enxerga cada versão. Nesses casos, a lição é revisar a lógica antes que ela derrube a indexação.

O que fica em aberto

O Google não detalha quais pontos de saída usa nem com que frequência, e não há razão para que detalhe: é infraestrutura interna. O que dá para medir é o efeito no seu próprio servidor. Compare os IPs de Googlebot nos seus logs contra as faixas oficiais publicadas pelo Google e veja quantos falhariam num teste ingênuo de GeoIP. Esse número costuma surpreender, e é o argumento mais forte para nunca confiar em localização de IP como sinal de autenticidade do rastreador.

Fonte: Search Engine Roundtable