Agente de usuário

TL;DR — Um user agent é uma pequena linha de texto que todo navegador e todo bot envia em cada requisição para dizer “aqui está quem eu sou”. O crawler do Google diz que é Googlebot; o do Bing diz bingbot. Em robots.txt você não escreve a linha inteira — você usa um nome curto (um “token”) como Googlebot. E aqui está o detalhe: essa linha é apenas texto, então qualquer um pode falsificá-la. A única maneira real de saber se um bot é quem ele afirma ser é verificar de onde a requisição realmente veio.

O que é um user agent

Toda vez que seu navegador carrega uma página, ele envia um pequeno rótulo de texto que diz o que ele é — algo como “Sou o Chrome em um Mac”. Esse rótulo é o user agent, e ele viaja em um cabeçalho HTTP em cada requisição. Os servidores podem lê-lo e reagir a ele.

Detalhe importante logo de início: o cliente preenche esse rótulo sozinho. Nada o verifica. É uma afirmação, não uma credencial — então um user agent que diz “Googlebot” não é a mesma coisa que uma requisição realmente verificada como Googlebot.

Os crawlers fazem a mesma coisa. Quando o Googlebot busca sua página, ele envia um user agent que inclui Googlebot. Quando o Bingbot a busca, o user agent inclui bingbot. É assim que um bot se anuncia nos logs do seu servidor.

A string vs. o nome curto

Na verdade, há duas coisas que as pessoas querem dizer com “user agent”, e misturá-las causa muita confusão:

• A string do user agent é a linha completa no cabeçalho da requisição. A do Googlebot é longa e se parece muito com um navegador.
• O token do user agent é o nome curto que você usa em robots.txt para direcionar um bot — como Googlebot ou bingbot. O token é apenas um pedaço da string completa, não a coisa toda.

Então, quando você escreve uma regra em robots.txt, você usa o token curto:

User-agent: Googlebot
Disallow: /private/

Você não cola a string gigante que parece navegador ali.

Você não pode confiar na string

Esta é a única coisa para lembrar. A linha do user agent é texto simples, então qualquer coisa pode falsificá-la. Qualquer script pode afirmar ser Googlebot em uma única linha de código — e muitos fazem isso, para passar despercebidos pelos bloqueios. O próprio Google diz que o cabeçalho do Googlebot é “frequentemente falsificado”.

Isso significa que você nunca deve decidir quem tem acesso ao seu site com base apenas no user agent. Se você realmente precisa confirmar que um visitante é o Googlebot real (por exemplo, se você está lendo seus logs), você verifica checando de onde a requisição veio — não o que ela diz ser. A aba Avançado explica exatamente como.

Alguns detalhes

• Os nomes de user agent em robots.txt não diferenciam maiúsculas de minúsculas — Googlebot e googlebot são os mesmos.
• Bloquear tudo com User-agent: * não bloqueia todos os bots do Google — seus crawlers de anúncios e o crawler de segurança ignoram o curinga.
• Mostrar uma versão de uma página para um crawler e uma diferente para pessoas reais é cloaking, e o Google trata isso como spam.

Quer o quadro completo — as tabelas de tokens, todos os crawlers do Google e do Bing, os comandos exatos de verificação e as regras de cloaking — mude para a aba Avançado.

TL;DR — Um user agent é o cabeçalho de solicitação HTTP que qualquer cliente envia para se identificar; é opcional, metadados preenchidos pelo cliente, não uma identidade autenticada. Seu valor é a string do user agent. Separado disso está o token do user agent (token de produto) usado em robots.txt — a RFC 9309 diz que ele DEVE ser uma substring da string, uma convenção forte com exceções documentadas (Google-Extended não tem string de solicitação alguma). A correspondência não diferencia maiúsculas de minúsculas, números de versão/curingas na linha do token são ignorados, o grupo mais específico vence e grupos com o mesmo token se mesclam, mas nunca se mesclam com *. A string é trivialmente falsificável — o Google chama a sua própria de “frequentemente falsificada” — então verifique por DNS reverso + direto (atrás de qualquer proxy/CDN, use o IP real do cliente) contra googlebot.com/google.com/googleusercontent.com para o Google ou search.msn.com para o Bing, ou corresponda a faixas de IP publicadas — e mesmo uma solicitação verificada apenas prova que uma solicitação chegou, não que a página foi indexada, recuperada ou usada para treinamento de IA. AdsBot e Google-Safety ignoram User-agent: *. O Chrome também está congelando detalhes das strings de UA do navegador (redução de User-Agent); Client Hints são a substituição estruturada, mas opt-in, e nenhuma substitui a verificação do crawler. A adaptação do user agent pode ser legítima, mas mostrar enganosamente aos crawlers conteúdo materialmente diferente pode ser cloaking.

O cabeçalho, a string e o token

Três coisas, e mantê-las distintas é a maior parte deste tópico.

• O cabeçalho. User-Agent é um cabeçalho de solicitação HTTP. Todo cliente o envia: seu navegador, curl, um crawler, um bot. De acordo com a RFC 9110 (o padrão central de semântica HTTP), é um campo opcional que o cliente preenche — metadados descritivos fornecidos pelo cliente, não uma identidade autenticada que o servidor verificou.
• A string. O valor do cabeçalho — uma linha de formato livre descrevendo o software, versão, mecanismo de renderização e, às vezes, o SO.
• O token. O identificador curto usado nas linhas User-agent: do robots.txt para direcionar um crawler — Googlebot, bingbot, Google-Extended.

A relação é a parte que confunde as pessoas. A RFC 9309 (o padrão formal do Protocolo de Exclusão de Robôs) diz que o token “DEVE ser uma substring da string de identificação que o crawler envia… no caso de HTTP, o token de produto DEVE ser uma substring no cabeçalho User-Agent.” Isso é um DEVE, não um OBRIGATÓRIO — uma convenção forte que o padrão recomenda, não um requisito rígido ao qual todo crawler está mecanicamente vinculado. Google-Extended (abaixo) é o exemplo mais claro de uma exceção documentada a isso. Não leia a regra da substring como universal só porque o Google a segue para a maioria de seus próprios tokens. O token é parte da string quando um provedor fornece um; você direciona o token no robots.txt e lê a string nos seus logs.

O próprio enquadramento do Google sobre como seus bots se identificam é útil aqui: “Os crawlers do Google se identificam por três coisas: o cabeçalho de solicitação HTTP user-agent, o endereço IP de origem da solicitação e o nome de host DNS reverso do IP de origem.” Observe que o user agent é apenas um dos três — os outros dois são como você realmente o verifica.

Google-Extended: um token sem string

A ilustração mais clara de token ≠ string é Google-Extended. Ele controla se o Google pode usar seu conteúdo para treinamento e fundamentação do Gemini — e ele não tem nenhuma string de user agent de solicitação HTTP dedicada. O rastreamento em si é feito com strings existentes do Googlebot; Google-Extended existe apenas como um token de controle do robots.txt. Você nunca verá “Google-Extended” em um cabeçalho de solicitação nos seus logs.

A consequência prática: bloquear Google-Extended afeta apenas o uso do seu conteúdo para treinamento de IA — isso não impede o Googlebot de rastrear e indexar você para a Pesquisa. São decisões separadas controladas por tokens separados. (Para uma visão mais ampla dos bots que leem seu site, veja rastreadores de IA e rastreador.)

Strings de user-agent do Googlebot

O Googlebot é “evergreen” — ele roda em uma versão recente do Chrome, e a versão do Chrome em sua string é atualizada periodicamente (desde dezembro de 2019). É por isso que a versão aparece como um espaço reservado W.X.Y.Z:

Googlebot Smartphone (celular):

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

Googlebot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/W.X.Y.Z Safari/537.36

Duas coisas para internalizar. Primeiro, não codifique a versão — W.X.Y.Z muda, e corresponder a ela quebrará. Em vez disso, corresponda ao token estável Googlebot. Segundo, você não pode separar celular de desktop no robots.txt. Ambas as variantes compartilham o único token Googlebot, então uma regra de robots.txt se aplica a ambas.

Tokens de rastreadores do Google

O Google executa uma família inteira de rastreadores e buscadores, cada um com seu próprio token. Os que você encontrará com mais frequência:

E os que quebram as regras usuais — os rastreadores de caso especial que ignoram User-agent: *:

• AdsBot (AdsBot-Google) e AdsBot Mobile (AdsBot-Google-Mobile) — eles não obedecem ao curinga. Para bloqueá-los, você deve nomeá-los explicitamente.
• AdSense (Mediapartners-Google) — o mesmo; ignora o * global.
• Google-Safety — usado para detecção de malware/abuso; ele ignora o robots.txt completamente.

A implicação é a que as pessoas perdem: User-agent: * não bloqueia o AdsBot ou o Google-Safety. Se você “bloquear todos os bots” com um curinga e assumir que o AdsBot está bloqueado, ele não está. (Este é exatamente o tipo de surpresa que coloca uma página no território de indexado embora bloqueado por robots.txt — veja robots.txt para a história completa de controle.)

Strings de user-agent do Bingbot

O Bing reconstruiu a string do Bingbot em 2022 para refletir que ele renderiza com o Microsoft Edge. As strings atuais:

Bingbot Desktop:

Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm) Chrome/W.X.Y.Z Safari/537.36

Bingbot Mobile:

Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)

O token do robots.txt é apenas bingbot. O que observar: pós-2022, a string do Bingbot parece quase exatamente com um navegador Chrome/Edge real — a única pista é o fragmento bingbot/2.0 dentro dela. Se você tem qualquer lógica que filtra ou detecta bots por UA, essa mudança importa.

Como o robots.txt realmente corresponde a um token

Algumas regras governam qual grupo de regras um rastreador obedece (de acordo com a especificação do robots.txt do Google e a RFC 9309):

• A correspondência mais específica vence. O Google “determina o grupo correto de regras encontrando… o grupo com o user agent mais específico que corresponde ao user agent do rastreador.” Um grupo Googlebot vence um grupo * para o Googlebot.
• Grupos com o mesmo token se fundem — mas nunca com *. Vários grupos nomeando o mesmo agente são combinados em um. Um grupo de agente específico e o grupo * não são fundidos; * é apenas o fallback quando nada específico corresponde.
• Insensível a maiúsculas e minúsculas. Tanto o nome do campo quanto o valor — Googlebot, googlebot, GOOGLEBOT são equivalentes.
• Números de versão e curingas na linha do token são ignorados. De acordo com o Google, “tanto googlebot/1.2 quanto googlebot* são equivalentes a googlebot.” Você não pode escrever User-agent: Googlebot* para corresponder a uma família — o * ali não faz nada.

Portanto, uma linha User-agent: recebe um token e o corresponde como uma substring simples (sem diferenciar maiúsculas de minúsculas) da identidade do rastreador — sem fixação de versão, sem curingas dentro dela.

Por que você não pode confiar na string — e como verificar

A string de user-agent é texto livre. Qualquer coisa pode defini-la. Uma linha de curl vai alegar ser Googlebot, e muitas ferramentas e bots maliciosos fazem exatamente isso para passar por bloqueios. O Google diz isso em sua própria documentação do Googlebot: “o cabeçalho de solicitação HTTP user-agent usado pelo Googlebot é frequentemente falsificado por outros rastreadores.” Como eu coloquei no meu guia do Googlebot, “Muitas ferramentas de SEO e alguns bots maliciosos fingem ser Googlebot. Isso pode permitir que eles acessem sites que tentam bloqueá-los.”

Portanto, nunca tome uma decisão de acesso ou conteúdo com base apenas na string. Verifique em vez disso.

Um pré-requisito antes de qualquer um dos métodos: obtenha o real IP de origem. Se o seu site estiver atrás de um proxy reverso, balanceador de carga ou CDN, o endereço no seu log de acesso padrão pode ser o IP do proxy, não o do rastreador — você precisa do IP original do cliente (geralmente encaminhado em um cabeçalho como X-Forwarded-For, configurado corretamente no seu proxy) ou nenhum dos métodos de verificação abaixo significa nada.

Método 1 — DNS reverso + direto (melhor para verificações pontuais). Os dois passos do Google:

1. “Execute uma consulta DNS reversa no endereço IP de acesso dos seus logs, usando o comando host. Verifique se o nome de domínio é googlebot.com, google.com ou googleusercontent.com.”
2. “Execute uma consulta DNS direta no nome de domínio obtido no passo 1… Verifique se é o mesmo que o endereço IP de acesso original dos seus logs.”

Para o Bingbot, a mesma dança de dois passos, mas o nome de host deve terminar em search.msn.com (não um domínio com a marca Bing — uma surpresa comum). Os comandos estão na aba Scripts.

Método 2 — faixas de IP publicadas (melhor em escala). O Google não publica uma lista de permissões estática para hardcoding (“essas faixas de endereços IP podem mudar”), mas publica arquivos JSON de CIDR legíveis por máquina que você pode comparar (common-crawlers.json e os arquivos de rastreadores mais amplos). O Bing agora também publica suas faixas. Eu construí uma ferramenta de verificação de IP do Googlebot exatamente para isso — cole IPs e ela os classifica. O Bing Webmaster Tools também tem uma ferramenta integrada “Verify Bingbot”.

DNS é melhor para uma verificação de log pontual; correspondência de faixa de IP é melhor para verificação em volume. Use o que se adequar — mas use um deles. E trate tanto os nomes de host esperados quanto os arquivos de faixa como atuais até hoje, não permanentes — Google e Bing já mudaram esses caminhos antes (os arquivos JSON de faixa de IP foram movidos e renomeados desde que este artigo foi escrito), então verifique novamente o documento de verificação ao vivo se uma consulta que costumava funcionar parar de corresponder.

Uma correspondência de UA não é prova de resultados posteriores

Mesmo uma solicitação totalmente verificada — IP real do Googlebot, DNS reverso confirmado direto, tudo confere — prova apenas uma coisa: essa solicitação chegou ao seu servidor. É tentador arredondar isso para uma afirmação muito maior, mas cada uma destas é um fato separado que exige evidências separadas:

• Solicitação recebida — uma solicitação com esse user agent atingiu seu servidor. (O que a verificação de log realmente prova.)
• Identidade confirmada — a solicitação realmente veio do crawler que afirma ser. (O que a correspondência de DNS reverso / faixas de IP adiciona por cima.)
• Conteúdo buscado e renderizado — o crawler renderizou a página com sucesso (sem erros, sem recursos bloqueados). Não é garantido apenas porque uma solicitação chegou.
• Indexado — a URL entrou no índice de busca. Uma busca bem-sucedida não garante a indexação.
• Usado para recuperação, citação ou treinamento — especialmente para crawlers de IA (Google-Extended, GPTBot e outros), um rastreamento não é prova de que seu conteúdo foi recuperado para uma resposta específica, citado ou usado no treinamento de modelos. Essas são etapas separadas, em grande parte não observáveis, posteriores ao rastreamento.

Um hit verificado do Googlebot em seus logs é um sinal real — apenas não o estenda além do que ele realmente mostra.

Autenticação de Bot da Web: para onde a verificação está indo

Em 2026, o Google começou a experimentar o Web Bot Auth — “um protocolo criptográfico experimental usado para autenticar solicitações enviadas por bots.” A ideia é “ir além de cabeçalhos facilmente falsificáveis para uma identidade verificada e desacoplar a identidade do agente dos endereços IP.” Os bots assinam criptograficamente suas solicitações; os sites verificam a assinatura contra as chaves públicas publicadas do Google, e as solicitações assinadas carregam um cabeçalho Signature-Agent. A ressalva do próprio Google é importante: “Não assinamos todas as solicitações de um agente específico. Certifique-se de recorrer aos métodos estabelecidos de verificação de bots.” Portanto, é aditivo, não um substituto — DNS reverso e faixas de IP continuam sendo sua base hoje.

Os navegadores também estão ficando mais difíceis de analisar a partir da string UA

Tudo acima é sobre crawlers, mas a mesma lição de “não confie demais na string” se aplica aos navegadores, e está ficando mais forte. O Chrome vem implementando a redução de User-Agent: congelando ou reduzindo a granularidade de partes de sua string UA (versão completa do navegador, versão do sistema operacional, modelo do dispositivo) em vez de relatá-las exatamente, para que a string não possa ser usada para identificar um usuário específico. O enquadramento do próprio Google: “A granularidade e a abundância de detalhes podem levar à identificação do usuário. A disponibilidade padrão dessas informações pode levar a rastreamento oculto.” Na prática, isso significa que a análise da string UA para versões exatas de navegador/SO/dispositivo — análises, detecção de dispositivo, triagem de bugs — é cada vez menos confiável e só vai piorar.

A substituição que o Chrome recomenda são as User-Agent Client Hints (UA-CH): dados estruturados que o navegador envia apenas quando um servidor solicita explicitamente. Hints de baixa entropia (marca do navegador, versão principal, sinalizador móvel) são enviados por padrão; hints de alta entropia (versão exata, versão da plataforma, modelo do dispositivo) exigem que o servidor opte por participar por meio de um cabeçalho de resposta Accept-CH primeiro — uma negociação explícita, não uma transmissão. Duas ressalvas antes de confiar nisso: é um mecanismo da família Chrome/Chromium, não algo que todos os navegadores enviam, e mesmo onde é suportado, “o valor pode estar em branco, não retornado ou preenchido com um valor variável.” As Client Hints resolvem o problema da string do navegador; elas não são um mecanismo de verificação de crawler — Google e Bing ainda verificam seus próprios crawlers via DNS e faixas de IP, não via Client Hints.

Segmentação por user-agent e cloaking

A jogada tentadora — “detectar o Googlebot pelo seu UA e servir algo especial para ele” — é ao mesmo tempo tecnicamente frágil e uma violação de política.

Frágil, porque o Google não rastreia com um único UA. Você teria que lidar corretamente com Googlebot (móvel e desktop), Google-InspectionTool, AdsBot, GoogleOther e outros, a partir de IPs rotativos — praticamente impossível de incluir na lista de permissões de forma limpa.

Uma violação de política, porque servir conteúdo diferente a um crawler e a usuários é cloaking: “apresentar conteúdo diferente a usuários e mecanismos de busca com a intenção de manipular o ranqueamento nos mecanismos de busca e enganar usuários.” A penalidade varia de desclassificação algorítmica a desindexação total. Observe a linha: adaptação legítima (layouts responsivos, negociação de conteúdo) é aceitável — é trocar o conteúdo em si entre bots e usuários que cruza a linha para cloaking.

Para saber onde o user agent se encaixa no pipeline maior, veja crawling (o hub) e crawler. Para controlar o que esses bots podem buscar, veja robots.txt.

Resumo de IA

Uma visão condensada da versão Avançada:

• Três coisas, mantidas separadas: o header de requisição User-Agent — opcional, metadados preenchidos pelo cliente conforme RFC 9110, não identidade autenticada; seu valor, a string de user-agent; e o token usado em robots.txt. Conforme RFC 9309, o token DEVE ser uma substring da string — uma convenção forte, não uma regra universal.
• Alguns tokens não têm string. Google-Extended é a exceção documentada: existe apenas como controle de robots.txt (treinamento do Gemini); o crawling usa strings normais do Googlebot. Bloqueá-lo não afeta a indexação na Pesquisa.
• As strings do Googlebot/Bingbot são perenes — a versão do Chrome aparece como W.X.Y.Z e muda; corresponda ao token estável (Googlebot, bingbot), nunca à versão. Googlebot mobile e desktop compartilham um token. O Bingbot pós-2022 parece um navegador real, exceto pelo fragmento bingbot/2.0.
• Correspondência em robots.txt: o grupo mais específico vence; grupos com o mesmo token se mesclam, mas nunca com *; a correspondência não diferencia maiúsculas de minúsculas; números de versão e curingas na linha User-agent: são ignorados (Googlebot* = Googlebot).
• AdsBot e Google-Safety ignoram User-agent: * — bloqueie-os pelo nome ou não bloqueie.
• A string é trivialmente falsificada (o Google chama a sua própria de “frequentemente falsificada”). Obtenha o IP real do cliente primeiro (proxies/CDNs podem mascarar isso nos seus logs), depois verifique por DNS reverso + direto (googlebot.com/google.com/googleusercontent.com; Bing → search.msn.com) ou faixas de IP publicadas — arquivos que o Google já renomeou/moveu antes, então verifique novamente o documento ao vivo se uma consulta parar de corresponder. Nunca confie na string para controle de acesso.
• Uma requisição verificada ainda não é prova de tudo a jusante. Requisição recebida, identidade confirmada, conteúdo renderizado, página indexada e conteúdo recuperado/citado/treinado são afirmações separadas que exigem evidências separadas — um hit de log prova a primeira, nada mais automaticamente.
• Web Bot Auth (2026, experimental) assina requisições criptograficamente — aditivo, com DNS/IP ainda como fallback.
• As strings de UA de navegadores também estão ficando mais difíceis de analisar: a redução do User-Agent do Chrome congela detalhes exatos de versão/SO/dispositivo fora da string; Client Hints são o substituto estruturado e opt-in — mas são específicos do Chrome e não substituem a verificação de crawler.
• Servir conteúdo diferente por UA é cloaking — uma violação de política de spam, e frágil porque o Google rastreia com muitos UAs.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca e do padrão.

Google

• Visão geral dos rastreadores e buscadores do Google (user agents) — os três sinais de identificação e a lista completa de rastreadores.
• Rastreadores comuns do Google — a tabela de token + string de user-agent.
• Rastreadores de casos especiais do Google — AdsBot, Mediapartners-Google, Google-Safety e as exceções *.
• Verificar solicitações de rastreadores e buscadores do Google — o método DNS em duas etapas e os arquivos de faixas de IP.
• O que é o Googlebot — as strings do Googlebot e a nota “frequentemente falsificado”.
• Como o Google interpreta a especificação robots.txt — correspondência de tokens, insensibilidade a maiúsculas/minúsculas, curingas ignorados.
• Autenticando solicitações com Web Bot Auth (Experimental) — o protocolo de assinatura criptográfica.
• Atualizando o user agent do Googlebot (2019) — por que a string mostra W.X.Y.Z.
• Políticas de spam — Cloaking — a definição e a penalidade.

Bing / Microsoft

• Anunciando mudança de user-agent para o Bingbot (abr 2022) — as strings atuais para desktop e mobile (Fabrice Canel).
• Como verificar se o Bingbot é o Bingbot (ago 2012) — o método de DNS reverso *.search.msn.com.
• Bing Webmaster Tools — Verificar Bingbot — a ferramenta de verificação integrada.

O padrão

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — a especificação HTTP central: User-Agent é um campo opcional fornecido pelo cliente, não uma identidade autenticada.
• RFC 9309: Robots Exclusion Protocol — a definição formal no nível SHOULD do token de produto como uma substring da string de user-agent.
• MDN — Cabeçalho User-Agent — a sintaxe HTTP do cabeçalho em si.

Strings de UA de navegadores

• Chrome Privacy Sandbox — Redução de User-Agent — o que é congelado/engrossado na string de UA do Chrome e por quê.
• Chrome for Developers — User-Agent Client Hints — dicas de baixa vs. alta entropia e o opt-in Accept-CH.

Citações da fonte

Declarações registradas do Google, Bing e da RFC. Cada link é um link profundo que salta para a passagem citada na página de origem.

Google — como os rastreadores se identificam

• “Google’s crawlers identify themselves through three things: the HTTP user-agent request header, the source IP address of the request, and the reverse DNS hostname of the source IP.” (tradução) «Os rastreadores do Google se identificam por três coisas: o cabeçalho de solicitação HTTP user-agent, o endereço IP de origem da solicitação e o nome de host DNS reverso do IP de origem.» — Documentação do Google Search Central. Ir para a citação

Google — a string é falsificada

• “The HTTP user-agent request header used by Googlebot is often spoofed by other crawlers.” — Google Search Central docs. Ir a la cita

Google — verificação por DNS

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command. Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” Ir a la cita
• “Google doesn’t post a public list of IP addresses for website owners to allowlist because these IP address ranges can change.” Ir a la cita

Google — correspondência de token no robots.txt

• “All non-matching text is ignored (for example, both googlebot/1.2 and googlebot* are equivalent to googlebot).” — especificação de robots.txt do Google. Ir a la cita

Google — Web Bot Auth

• “An experimental cryptographic protocol used to authenticate requests sent by bots.” Ir a la cita
• “We don’t sign every request of a particular agent. Be sure that you fall back to the established methods of bot verification.” Ir a la cita

Google — cloaking

• “Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.” — Google Search Essentials, Spam Policies. Ir a la cita

RFC 9309 — token é uma substring da string

• “The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP, the product token SHOULD be a substring in the User-Agent header.” Ir a la cita

Patrick Stox — sobre spoofing

• “Many SEO tools and some malicious bots will pretend to be Googlebot. This may allow them to access websites that try to block them.” — do meu guia sobre Googlebot na Ahrefs. Leia

Crawler → token → string → verificar

A tabela de referência. O token é o que você coloca em robots.txt; o hostname de verificação é para onde uma solicitação genuína resolve reversamente.

Regras de correspondência do robots.txt de relance

Fatos rápidos

• Token = substring da string UA (RFC 9309). Não a string inteira.
• Googlebot para mobile e desktop compartilham um token — você não pode separá-los no robots.txt.
• A versão do Chrome na string é W.X.Y.Z — ela muda; nunca a codifique.
• A string UA é trivialmente falsificável — verifique por DNS ou IP, nunca confie na string.

Verifique um bot por DNS reverso + direto

A string do user-agent pode ser falsificada em uma linha de curl. Confirme que um bot é genuíno verificando o IP de onde ele realmente veio. O padrão é o mesmo para Google e Bing — apenas o hostname esperado difere.

Obtenha o IP correto primeiro: se as requisições passarem por um proxy reverso, balanceador de carga ou CDN antes de chegar ao seu servidor, seus logs padrão podem mostrar o endereço do proxy, não o do crawler. Use o IP real do cliente (de um cabeçalho de encaminhamento configurado corretamente) antes de executar qualquer uma das verificações abaixo.

macOS / Linux

# --- Googlebot ---
# 1) Reverse DNS the IP from your logs — must end in googlebot.com, google.com, or googleusercontent.com
host 66.249.66.1
# → 1.66.249.66.in-addr.arpa domain name pointer crawl-66-249-66-1.googlebot.com

# 2) Forward DNS that hostname back — it must resolve to the same IP
host crawl-66-249-66-1.googlebot.com
# → crawl-66-249-66-1.googlebot.com has address 66.249.66.1

# --- Bingbot ---
# Reverse DNS must end in search.msn.com, then forward-confirm back to the IP
host 157.55.39.1
host <the-hostname-it-returned>

Windows

:: Googlebot
nslookup 66.249.66.1
nslookup crawl-66-249-66-1.googlebot.com

:: Bingbot
nslookup 157.55.39.1
nslookup <the-hostname-it-returned>

Se a consulta reversa não terminar no domínio esperado — googlebot.com / google.com / googleusercontent.com para Google, search.msn.com para Bing — ou a consulta direta não corresponder ao IP original, não é o bot real, não importa o que a string do user-agent diga.

Corresponda às faixas de IP publicadas (em escala)

Para verificar muitos acessos, pule o DNS por requisição e corresponda o IP às faixas CIDR publicadas pelo mecanismo. O Google publica JSON legível por máquina:

https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/crawling/ipranges/special-crawlers.json
https://developers.google.com/static/crawling/ipranges/user-triggered-fetchers.json

Baixe o arquivo, construa o conjunto CIDR e teste cada IP registrado para verificar se pertence. (Eu construí uma ferramenta de verificação de IP do Googlebot que faz isso para você.) O Bing também publica suas faixas, e o Bing Webmaster Tools tem uma verificação integrada “Verify Bingbot”.

Lista de verificação de sanidade do user-agent

Antes de escrever regras de UA ou agir sobre um bot em seus logs:

• Você está segmentando o token em robots.txt (por exemplo, Googlebot), não colando a string UA completa.
• Sem números de versão ou * dentro da linha User-agent: — eles são ignorados (Googlebot* não faz nada).
• Você não assumiu que User-agent: * bloqueia AdsBot ou Google-Safety — isso não acontece; nomeie-os explicitamente se precisar.
• Se você bloqueou Google-Extended, entende que isso afeta apenas o uso de treinamento de IA — o Googlebot ainda rastreia e indexa para a Pesquisa.
• Você não está baseando controle de acesso ou conteúdo na string UA bruta — ela é falsificável.
• Qualquer verificação de “isso é realmente Googlebot?” passa por DNS reverso + direto (googlebot.com / google.com / googleusercontent.com) ou as faixas de IP publicadas — Bing através de search.msn.com.
• Sem correspondência de UA com versão fixada em nenhum lugar — a parte Chrome W.X.Y.Z muda.
• Você não está servindo conteúdo diferente para um UA de bot do que para usuários (isso é cloaking).

Ferramentas para trabalhar com user agents

Três das minhas próprias ferramentas gratuitas cobrem as três tarefas que as pessoas realmente procuram neste tópico: confirmar que um bot reivindicado é real, ver quais user agents estão realmente atingindo seu site e verificar o que os rastreadores de IA podem fazer.

Googlebot Verifier — a ferramenta para o problema exato que este artigo aborda repetidamente: a string de user-agent é apenas texto, então você não pode confiar nela sozinha. Cole um endereço IP dos seus logs, escolha qual rastreador ela afirma ser (Googlebot, Bingbot e outros), e ela executa a verificação de DNS reverso + direto e a correspondência de faixa de IP publicada para você, retornando um veredito em níveis — confirmado por DNS reverso, em faixas publicadas, falsificado, não verificável ou não é um rastreador conhecido. Tem um dia inteiro de acessos para verificar em vez de um IP? Cole até 500 IPs ou linhas de log brutas na caixa de lote.

Log File Analyzer — para a pergunta “quais user agents estão realmente rastreando meu site?” Solte um log de acesso do servidor (nginx, Apache, IIS/W3C ou JSON) e ele o analisa inteiramente no seu navegador, dividindo a atividade de rastreamento por bot e por seção, sinalizando desperdício de código de status, separando rastreadores de IA de rastreadores de busca e — a parte que mais importa para este tópico — executando um relatório de falsificação que nomeia solicitações que afirmam ser o token de user-agent de um rastreador conhecido sem o IP para respaldá-las.

AI-Crawler Access Checker — para a família mais nova de tokens que não se comportam como Googlebot ou bingbot. Insira uma URL e ele verifica seu robots.txt contra cada token de user-agent de rastreador de IA importante (GPTBot, ClaudeBot, PerplexityBot, Google-Extended e mais), mostra a regra exata que vence para cada um e sinaliza se um llms.txt existe. Útil para confirmar que um token como Google-Extended está fazendo o que você pensa que está fazendo — já que, como abordado acima, ele não tem uma string de solicitação própria para detectar em seus logs.

Prompts para tarefas de user-agent

Dois prompts construídos em torno das armadilhas específicas que este tópico apresenta — falsificação e sintaxe de token robots.txt — não um preenchimento genérico de “audite meu SEO”. Cole seus próprios dados nos espaços reservados.

Prompt 1 — triagem de um lote de strings de user-agent dos seus logs para sinais de falsificação

Cole uma coluna de strings de user-agent brutas extraídas do seu log de acesso (não IPs — este prompt não pode verificar identidade, apenas detectar inconsistências na string em si):

Here is a list of raw User-Agent strings from my server access log, one per
line. For each one:
1. Say which crawler token it claims to be (e.g. Googlebot, bingbot,
   GPTBot), or "no recognizable token" if none.
2. Flag anything internally inconsistent for that claimed crawler — e.g. a
   claimed Googlebot string missing "compatible; Googlebot" or the
   "+http://www.google.com/bot.html" URL, a claimed bingbot string missing
   "bingbot/2.0", or a Chrome version that looks hand-typed rather than a
   real evergreen build.
3. Remind me that this is a text-pattern check only — it cannot confirm
   identity. Real verification requires reverse+forward DNS or matching
   against the crawler's published IP ranges.

[paste user-agent strings here]

Prompt 2 — verificar um robots.txt para erros de correspondência de token

Cole seu arquivo robots.txt completo:

Review this robots.txt file for user-agent token mistakes:
1. Flag any User-agent line that includes a version number or a wildcard
   inside the token (e.g. "Googlebot/1.2" or "Googlebot*") — these are
   ignored, not matched as a family.
2. Check whether User-agent: * is being relied on to block AdsBot-Google,
   AdsBot-Google-Mobile, Mediapartners-Google, or Google-Safety — these
   ignore the wildcard and need their own named group if I want them
   blocked.
3. Note any duplicate groups for the same token that could be merged, and
   confirm token matching here is case-insensitive so I don't need
   near-duplicate groups for casing variants.
4. List which named groups exist and which of Google's/Bing's common
   crawler tokens (Googlebot, Googlebot-Image, Google-Extended, bingbot)
   have no explicit group at all, so I know they're falling through to *.

[paste robots.txt here]

Teste-se: user agent

Cinco perguntas rápidas sobre o cabeçalho, a string, o token e como verificar se um bot é real. Escolha uma resposta para cada uma e depois verifique.

Recursos que valem seu tempo

Meus escritos relacionados

• O que é o Googlebot e como ele funciona? — as strings completas de user-agent do Googlebot, métodos de verificação e minha ferramenta de verificação de IP.
• Indexado, embora bloqueado por robots.txt — onde o bloqueio baseado em UA e o bloqueio por robots.txt colidem.
• Robots.txt e SEO: tudo o que você precisa saber — como os grupos de user-agent e as regras realmente funcionam.
• Conheça os novos rastreadores da web: bots de IA estão se aproximando dos bots de mecanismos de busca — o elenco em mudança de user agents nos seus logs.

Oficial / padrões

• RFC 9110 — HTTP Semantics, §10.1.5 User-Agent — a definição base: metadados opcionais fornecidos pelo cliente.
• RFC 9309: Robots Exclusion Protocol — a definição formal de nível SHOULD de token de produto como substring.
• Visão geral do Google sobre rastreadores e buscadores e Verificar rastreadores do Google.
• Chrome Privacy Sandbox — Redução de User-Agent e User-Agent Client Hints — por que as strings de user-agent dos navegadores estão ficando mais difíceis de analisar e o que as substitui.

De outros

• John Mueller — Bots que se passam por Googlebot — sobre spoofing e por que o DNS reverso é a resposta.
• MDN — Cabeçalho User-Agent — a visão da especificação HTTP sobre o cabeçalho.
• r/TechSEO — a comunidade para depuração de crawl/logs.
• Web Bot Auth: o novo método experimental do Google para validar bots autênticos (Search Engine Land, Barry Schwartz, maio de 2026) — o melhor resumo jornalístico de como a assinatura criptográfica de bots funciona e o que significa na prática.
• User agent Google-Agent identifica tráfego de agentes de IA em logs de servidor (Search Engine Land) — cobre o novo buscador acionado pelo usuário que ignora robots.txt e usa Web Bot Auth.
• Google está testando novo padrão de autorização de bots (Search Engine Journal) — contexto mais amplo do setor sobre o padrão IETF e quais empresas (Amazon, Cloudflare, Akamai, OpenAI) estão apoiando.
• Anunciando futuros user-agents para o Bingbot (Bing Webmaster Blog, Fabrice Canel, dez. 2019) — o anúncio original da mudança do Bingbot para renderização baseada em Edge antes do lançamento em 2022.
• Lista da Microsoft de endereços IP do Bingbot divulgada (Search Engine Land) — cobertura da decisão do Bing de publicar faixas de IP para verificação de bots em escala.

Registro de alterações