Você nunca verá o GPTBot no Google Analytics. O GA4 e a maioria das ferramentas de analytics de terceiros dependem da execução de JavaScript no navegador para registrar uma visita. Como o GPTBot não executa JS nem aciona o código de rastreamento, ele passa despercebido. Para comprovar que o crawler da OpenAI acessou uma página, saber qual conteúdo coletou e qual resposta recebeu, a única evidência confiável é o access log original do servidor.
Por que os logs do servidor são a única fonte confiável
Crawlers de IA e usuários reais percorrem caminhos diferentes. Uma pessoa abre o navegador, carrega a página, executa o JavaScript e aciona um evento do GA4; por isso, a visita aparece no painel. Já crawlers como o GPTBot fazem apenas uma requisição HTTP, coletam o HTML retornado e vão embora. Como não executam o código de rastreamento, ficam completamente fora das ferramentas de analytics. Nos logs do servidor, a história é outra: a cada requisição recebida, seja de uma pessoa, do Googlebot ou do GPTBot, o Nginx ou o Apache registra linha por linha o IP de origem, o horário, o caminho solicitado, o código de status da resposta e o User-Agent. O front-end não consegue bloquear esse registro, e ele não desaparece só porque o visitante não executa JS.
Conheça os três crawlers da OpenAI — não monitore apenas o GPTBot
Muita gente acredita que a OpenAI opera um único crawler e procura apenas por GPTBot nos logs. Isso leva a uma subestimação relevante da visibilidade do site. A OpenAI mantém pelo menos três crawlers com finalidades e User-Agents diferentes. Eles devem ser identificados e contabilizados separadamente.
- GPTBot: coleta conteúdo para treinamento e aprimoramento de modelos. O User-Agent contém "GPTBot". Ele respeita o robots.txt, e os IPs de origem são publicados em openai.com/gptbot.json.
- OAI-SearchBot: cria o índice usado pela busca do ChatGPT. O User-Agent contém "OAI-SearchBot". É o crawler mais diretamente relacionado à possibilidade de seu conteúdo ser citado nas respostas do ChatGPT.
- ChatGPT-User: é acionado quando um usuário pede ao ChatGPT para acessar um link. O User-Agent contém "ChatGPT-User". Quando ele aparece, significa que uma pessoa real está chegando à sua página por meio do ChatGPT.
- Indo além: o mesmo log costuma registrar outros crawlers de IA, como PerplexityBot, ClaudeBot e Google-Extended. O método de análise é exatamente o mesmo.
Etapa 1: encontre os rastros do GPTBot no access log
No formato combined do Nginx, um dos mais usados, cada linha do log traz o IP de origem, o horário, a requisição "GET /blog/geo-audit HTTP/1.1", o código de status 200, o número de bytes retornados e, por fim, a string do User-Agent. Nas requisições do GPTBot, o final do User-Agent inclui compatible; GPTBot/1.2; +https://openai.com/gptbot. Com esse identificador, poucas linhas de comando bastam para mapear seu comportamento.
- Liste todas as requisições do GPTBot: grep -i "GPTBot" /var/log/nginx/access.log
- Conte quantas vezes ele acessou o site hoje: grep -ic "GPTBot" access.log
- Veja a distribuição dos códigos de status retornados (no formato combined, a coluna 9 contém o status HTTP): grep -i "GPTBot" access.log | awk '{print $9}' | sort | uniq -c | sort -rn
- Descubra quais páginas ele rastreia com mais frequência (a coluna 7 contém o caminho solicitado): grep -i "GPTBot" access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
- Compare de uma só vez o volume de rastreamento dos três crawlers: grep -c "GPTBot" access.log; grep -c "OAI-SearchBot" access.log; grep -c "ChatGPT-User" access.log
A saída já revela três pontos: frequência — quantos acessos ocorrem por dia e em quais horários; cobertura — se o crawler chega às páginas de produto e aos artigos mais importantes ou fica restrito à home; e integridade das respostas — se os códigos de status são quase sempre 200. Se o grep não retornar nada, o GPTBot não visitou o site no período analisado. Nesse caso, verifique se o robots.txt ou o firewall está bloqueando o acesso.
Etapa 2: confirme se o GPTBot é legítimo
Qualquer agente pode falsificar a string do User-Agent. Um crawler desconhecido ou até mesmo um tráfego malicioso pode inserir "GPTBot" no cabeçalho para se passar pelo bot da OpenAI, contornar determinadas regras ou consumir recursos do servidor. Portanto, depois de localizar as requisições, é preciso validar sua autenticidade. Há dois métodos altamente confiáveis.
- Compare com as listas oficiais de IPs: a OpenAI publica as faixas de IP de origem de cada crawler em openai.com/gptbot.json, openai.com/searchbot.json e openai.com/chatgpt-user.json. Compare o IP registrado no log com a lista correspondente e considere a requisição legítima apenas se ele estiver dentro de uma dessas faixas.
- Faça a verificação por DNS reverso: execute uma consulta PTR (com host ou dig -x) para o IP de origem. Um GPTBot legítimo deve resolver para um domínio da OpenAI. Depois, faça uma consulta direta nesse domínio para confirmar que ele aponta para o mesmo IP, processo conhecido como forward-confirmed rDNS. A requisição só é confiável quando as duas verificações coincidem.
Etapa 3: descubra o que ele coleta e quais códigos de status recebe
A presença do crawler não garante que seu conteúdo tenha sido coletado. O que realmente influencia a possibilidade de uma referência no ChatGPT é o conteúdo recebido em cada requisição. Há quatro sinais que merecem atenção.
- Código de status: o cenário ideal é receber sempre 200. Um volume alto de 403 costuma indicar que o Cloudflare ou o WAF está tratando o GPTBot como tráfego suspeito e bloqueando seu acesso. Respostas 404 apontam para URLs inválidas no sitemap ou nos links internos. Erros 5xx recorrentes indicam falhas no servidor durante as visitas do crawler.
- Páginas cobertas: examine a lista de caminhos rastreados e confira se ela inclui páginas de preços, páginas de planos e artigos aprofundados com maior potencial de citação. Se o crawler acessa apenas a home e alguns conteúdos antigos, suas páginas principais continuam invisíveis para a IA.
- Acessos ao llms.txt e ao robots.txt: os logs mostram se o crawler solicita /llms.txt e /robots.txt. Se você publicou um llms.txt, mas ele nunca é lido, esse crawler não está usando o arquivo no momento. Não superestime seu impacto.
- Frequência e atualização do rastreamento: compare os horários das visitas com as datas de publicação ou revisão dos artigos para entender com que frequência o GPTBot retorna. Um intervalo muito longo significa que seu conteúdo novo demorará mais para entrar no entendimento do modelo.
Leia os logs antes de falar em otimização
Antes de investir tempo em escrever o llms.txt, ajustar os dados estruturados Schema e reformular o conteúdo, dedique dez minutos a uma busca com grep no access log. Em um projeto assumido pela Tenten, o cliente já tinha um llms.txt bem preparado e uma implementação correta de Schema. Ao analisar os logs, porém, a equipe descobriu que o WAF respondia com 403 a todas as requisições do GPTBot havia seis meses. Todo o trabalho anterior de otimização não produzia efeito. Os logs mostram com clareza se o GPTBot apareceu, o que tentou coletar e onde foi bloqueado. Essa é a etapa mais barata e mais importante de qualquer otimização técnica de GEO. Para descobrir quais lacunas de visibilidade estão escondidas nos seus logs e o que deve ser corrigido primeiro, agende um diagnóstico de GEO de 30 minutos. Analisaremos diretamente a situação do rastreamento e indicaremos os pontos de ação prioritários.
