Gary Illyes explicou que a localização declarada do Googlebot é só um rótulo de texto: os pontos de saída reais variam conforme o data center. Isso muda como validar crawl logs.
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:
- Faça um DNS reverso no IP que aparece no log. Para o Googlebot legítimo, o resultado termina em
googlebot.comougoogle.com. - 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.1O 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
Este artigo foi escrito por Sabrina Santos, colunista de SEO. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de SEO técnico e descoberta. Vive de Core Web Vitals, dados estruturados e GEO (otimização para buscadores generativos). Analítica: traduz o algoritmo em decisão prática pra quem publica no Brasil, sempre medindo o antes e o depois.
