Análise de logs de crawlers de IA

TL;DR — A análise de logs de crawlers de IA consiste em examinar os logs brutos de acesso do servidor para ver quais bots de IA — como GPTBot da OpenAI ou ClaudeBot da Anthropic — realmente visitaram seu site, com que frequência e o que obtiveram. Seus logs são o único lugar que registra isso. O Google Search Console não mostra bots de IA, e o Google Analytics só vê pessoas que clicam para chegar ao site, não os próprios bots. O problema é que muito tráfego afirma ser um bot famoso sem ser, então não dá para confiar apenas no nome.

O que é um arquivo de log

Os logs de acesso do servidor registram as solicitações que chegaram ao servidor, incluindo user agent, horário, caminho e detalhes da resposta quando configurados. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files A documentação dos fornecedores identifica user agents de crawlers, mas uma string sozinha não prova que o solicitante é genuíno. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

Sempre que qualquer coisa — o navegador de uma pessoa, o Googlebot ou o GPTBot — pede uma página ao seu servidor, ele grava uma linha em um arquivo de log. Cada linha registra o horário, o endereço IP do visitante, o que foi solicitado, o user agent (um rótulo usado pelo visitante para se identificar, como GPTBot) e o código de resposta enviado pelo servidor (200 para sucesso, 404 para não encontrado e assim por diante).

A análise de logs de crawlers de IA consiste em ler essas linhas e filtrá-las para encontrar os bots de IA. Ela responde a perguntas que você literalmente não consegue responder de outra maneira:

• Um bot de IA chegou a visitar meu site?
• Quais páginas ele buscou e quais páginas importantes ignorou?
• Era o bot verdadeiro ou algo fingindo ser ele?
• O que ele recebeu — meu conteúdo real ou uma página de erro?

Se você quer conhecer o elenco completo de bots de IA e a finalidade de cada um (bots de treinamento, de busca ou de “buscar esta página agora”), esse é um assunto separado — veja AI crawlers. Esta página trata do como: extrair os logs e lê-los.

Por que seus painéis não cobrem isso

• Google Search Console tem um relatório de estatísticas de rastreamento, mas ele trata apenas do Googlebot. Não mostra nada sobre GPTBot, ClaudeBot ou PerplexityBot.
• Google Analytics (GA4) registra apenas visitantes que clicam em um link para chegar ao seu site com um “referrer”. Um crawler que busca sua página em segundo plano nunca aparece ali.

Portanto, os logs são a fonte de verdade. Nada mais enxerga o bot.

A única coisa que iniciantes deixam passar

Um rótulo GPTBot nos seus logs não prova que era realmente a OpenAI. Qualquer pessoa pode colocar o user agent que quiser em uma solicitação — é como escrever um endereço de remetente em um envelope. Muitos scrapers colocam o nome de um bot famoso no tráfego para parecer legítimo. A única forma de ter certeza é verificar o endereço IP do visitante na lista de endereços reais publicada pela empresa de IA. Essa etapa de verificação é o centro de uma análise correta, e a aba Avançado explica o processo.

TL;DR — Extraia os logs de acesso do Apache/Nginx ou da CDN e faça quatro coisas: verifique (compare o user agent e confirme o IP na lista publicada de cada operador — as taxas de spoofing vão de 5,7% da HUMAN Security aos 81,8% do teste próprio de Duane Forrester); escolha uma ferramenta pela escala (grep → Screaming Frog Log File Analyser → ELK/Splunk → BigQuery/Cloudflare); meça a frequência de rastreamento por bot, quais páginas são acessadas, rastreamento versus renderização e códigos de status; e interprete com honestidade — a recuperação é necessária, mas não suficiente, portanto “mais rastreamento = mais citações” não foi comprovado. Este é o método irmão de AI crawlers (que trata de quais são os bots), AI traffic attribution (o lado dos cliques) e LLM visibility (o modelo recuperado → mencionado → citado, do qual esta página observa a primeira etapa).

O que este artigo cobre — e o que não cobre

Os logs demonstram solicitações, não se o conteúdo foi usado para treinamento, recuperação ou uma resposta. Evidence for this claim Server access logs record requests and can include fields such as request path, status, referrer, and user agent. Scope: Apache HTTP Server logging; available fields depend on server configuration. Confidence: high · Verified: 2026-07-14 Apache: Log files Verifique os bots usando mecanismos publicados pelos provedores quando disponíveis e trate a atribuição como uma evidência delimitada. Evidence for this claim OpenAI publishes user-agent tokens and controls for several of its crawlers. Scope: OpenAI's documented crawlers; a user-agent string is not proof of downstream training, retrieval, citation, or use. Confidence: high · Verified: 2026-07-14 OpenAI: Crawlers

O artigo irmão AI crawlers já cobre a tabela bot a bot, a taxonomia de três categorias (treinamento / busca de IA / busca acionada pelo usuário), a distinção entre Google-Extended ser um token e ser um bot e as receitas de robots.txt. Não vou refazer nada disso aqui. AI traffic attribution cobre o lado de GA4/referrer — o que o bot devolveu. Este artigo é o lado oposto do funil: o que o bot pegou. E LLM visibility cobre o modelo recuperado → mencionado → citado; a análise de logs mostra especificamente a etapa recuperada, e nada além dela.

Esta é a sequência da análise clássica de logs de SEO na era da IA. Quando revisei How to Do an SEO Log File Analysis do Ahrefs, as dimensões eram frequência de rastreamento, URLs rastreadas, códigos de status e verificação dos bots com os IPs publicados pelo Google. A mesma estrutura vale aqui — mas voltada a uma população de bots que em grande parte não renderiza JavaScript, é constantemente imitada e rastreia em rajadas irregulares em vez de manter um fluxo constante.

Etapa 1 — Obtenha seus logs

Seus logs ficam em um de dois lugares, ou nos dois:

• Logs do servidor de origem. Apache (access.log), Nginx (access.log) ou o servidor da aplicação. Cada linha contém, no mínimo: timestamp, IP do cliente, método + caminho da solicitação, código de status, bytes, referrer e user agent.
• Logs da CDN/borda. Se você está atrás de Cloudflare, Fastly, Akamai etc., muito tráfego de bots é respondido na borda e pode nunca chegar à origem — por isso o log da borda é o registro mais completo. A Cloudflare oferece isso por meio do Logpush (e de uma API GraphQL); a Fastly oferece streaming de logs em tempo real.

Os campos de que você realmente precisa para analisar bots de IA são: timestamp, IP do cliente, user agent, caminho da solicitação e código de status, além de bytes e referrer, se possível.

O problema prático é a retenção. Muitos hosts guardam apenas alguns dias de logs. O texto de Lauren Busby na Search Engine Land dá a solução diretamente — uma extração agendada transforma uma janela curta em algo que pode ser analisado ao longo do tempo: um job SFTP agendado, criado em uma ferramenta de workflow como n8n ou roteirizado, basta para transformar uma janela curta de retenção em algo que você consegue analisar ao longo do tempo (Busby, SEL). Configure isso antes de precisar dos dados.

Uma limitação honesta para ter em mente desde o início: como Busby explica, os arquivos de log mostram o que chegou ao seu site, mas nem sempre mostram o que tentou chegar (SEL) — solicitações bloqueadas ou respondidas upstream podem não aparecer.

Etapa 2 — Verifique antes de confiar no user agent

Esta é a etapa que separa a análise de logs de bots de IA da versão clássica e que a maioria dos tutoriais concorrentes ignora. Strings de user agent são fáceis de falsificar. Há dois dados independentes sobre a gravidade do problema:

• HUMAN Security analisou duas semanas de tráfego que alegava ser de um dos 16 crawlers de IA conhecidos e descobriu que 5,7% eram falsificados — aproximadamente 1 em cada 18 solicitações (reportado pela SEJ).
• Duane Forrester fez a mesma verificação nos próprios logs e encontrou algo muito pior. De 33 solicitações com nome de busca ao vivo, seis vieram de um IP publicado pelo fornecedor e 27 não — uma taxa de spoofing de 81,8% entre as solicitações que ele conseguiu verificar (SEJ). O número do Googlebot foi ainda pior: de 799 solicitações com o nome Googlebot, apenas 107 vieram de um endereço Google verificado — as outras aproximadamente 87% não eram do Google (SEJ).

Trate esses números como direcionais, vindos de amostras e métodos diferentes, não como um número universal. Mais importante: não generalize o método de verificação de um provedor para todos os bots. Alguns operadores publicam intervalos de endereços; outros documentam tokens de user agent sem um intervalo público atual ou um contrato de verificação por DNS (SEJ).

O método de verificação:

1. Compare a string do user agent. O GPTBot se identifica como Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.3; +https://openai.com/gptbot; OAI-SearchBot e ChatGPT-User têm seus próprios tokens (documentação de bots da OpenAI).
2. Use o método oficial atual de verificação do provedor quando existir. A OpenAI publica openai.com/gptbot.json, searchbot.json e chatgpt-user.json. A documentação atual de crawlers da Anthropic diz que um endereço na lista publicada indica que o crawler vem da Anthropic. Use esse método específico do provedor; não o transforme em uma regra universal de verificação de bots.
3. Não invente um fallback. DNS reverso mais direto é válido para um provedor somente quando ele publica o padrão de hostname e o procedimento de verificação. Uma correspondência PTR genérica prova controle do DNS, não a identidade do bot alegado. O Log File Analyser da Screaming Frog pode aplicar listas confirmadas publicamente quando disponíveis; seu recurso de verificação na importação consulta listas de IP confirmadas publicamente para confirmar que os bots são genuínos (Screaming Frog).

A verificação deve orientar políticas precisas e a resposta a incidentes. Prefira o token de robots documentado pelo provedor para uma política de rastreamento; reserve controles de rede para casos de abuso ou segurança e identifique-os separadamente da conformidade com robots.

Etapa 3 — Escolha sua ferramenta

Dimensione a ferramenta para o tamanho do trabalho, aproximadamente de gratuita → paga e de fonte de verdade → gerenciada:

• grep / PowerShell — uma contagem rápida pontual e um filtro consciente de verificação. O artigo AI crawlers traz o snippet básico de contagem; a aba Scripts amplia isso para verificação de IP, divisão por código de status e detecção de rastreamento versus renderização.
• Screaming Frog Log File Analyser — importador de desktop com predefinições para bots de IA (GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot) e a opção “Verify Bots When Importing”. A aba Response Codes divide 2XX/3XX/4XX/5XX por URL, User Agents mostra solicitações e taxas de erro por bot, URLs ordena por Num Events (páginas mais buscadas) e IPs permite investigar fontes suspeitas (tutorial).
• ELK Stack (Elasticsearch / Logstash / Kibana) ou Splunk — para ingestão contínua em escala maior, com painéis e alertas, quando uma ferramenta de desktop de importação única fica lenta ou quando você quer monitoramento contínuo em vez de exportações periódicas.
• BigQuery — para retenção de longo prazo e consultas SQL em escala, alimentado normalmente pelo Cloudflare Logpush ou por uma extração GraphQL agendada do conjunto httpRequestsAdaptiveGroups da Cloudflare, permitindo consultar a atividade dos bots por página, data e código de status sem reimportar arquivos simples.
• Cloudflare AI Crawl Control (para sites atrás da Cloudflare) — um painel gerenciado para atividade e padrões de solicitações de crawlers, verificação de bots e acompanhamento de conformidade com diretivas, sem construir seu próprio pipeline (documentação).

Etapa 4 — O que medir e como interpretar

Frequência de rastreamento por bot. Acessos por dia/semana para cada nome de bot. Bots de IA rastreiam em rajadas, não em fluxos constantes. No estudo de caso de logs de CDN de 48 dias da WISLR, o GPTBot ficou ausente por semanas e depois fez 187 solicitações em uma única semana — 152 delas em uma rajada de três minutos, com pico de 114 solicitações/minuto (WISLR). Leia a frequência como um padrão, não apenas como um total.

Quais páginas recebem acessos — e quais importantes não recebem. Ordene pela quantidade de solicitações. Busby observa que crawlers de IA normalmente são superficiais — é comum vê-los limitados às páginas de nível superior: a homepage, a navegação principal e um pequeno número de URLs de alto nível (SEL) — com queda acentuada nas páginas profundas, mesmo quando elas são as mais importantes para citações. Uma página profunda que nunca aparece nos logs não pode ser recuperada.

Dependência de HTML bruto — meça, não universalize. A documentação dos provedores não dá um contrato único de renderização JavaScript para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, PerplexityBot e outros agentes. Um padrão observado ainda é útil: na amostra da WISLR, o ChatGPT-User buscou apenas HTML — zero solicitações de imagens, CSS ou arquivos JS — enquanto Googlebot e OAI-SearchBot também buscaram imagens (WISLR). Se seus logs mostram bots de IA acessando páginas cujo HTML bruto é um shell JS quase vazio, isso é um risco de dependência verificável, não uma prova de que todos os provedores sempre se comportam assim. Compare o HTML entregue com os resultados ou com testes de busca específicos do provedor. (Para os fundamentos de renderização, veja JavaScript SEO.)

Divisão por código de status/bloqueio. Observe: 200 (sucesso), 304 (não modificado — recrawl eficiente), 404 (links quebrados seguidos pelo bot) e 403/429 (bloqueado / limitado por taxa). Busby destaca que os arquivos de log mostram onde os crawlers encontram problemas, incluindo respostas 403 (solicitações bloqueadas) e 429 (limitação de taxa) (SEL). Verifique se o bloqueio é intencional ou acidental.

Solicitações a robots.txt e llms.txt como sinal próprio. Cruze quais bots solicitam /robots.txt antes de rastrear — na amostra da WISLR, GPTBot e Meta-WebIndexer nunca o verificaram em 48 dias — e se caminhos não permitidos são acessados mesmo assim. A WISLR também registrou zero solicitações a /llms.txt de qualquer bot de IA durante esses 48 dias (WISLR), em linha com o achado de aproximadamente 97% de não leitura coberto no artigo AI crawlers. Não espere solicitações a llms.txt nos logs como prova de que ele “funciona”.

Mais rastreamento significa mais citações? Seja honesto.

Não há dados estabelecidos que sustentem “rastreie mais e seja mais citado”. A recuperação é uma condição necessária para a citação, mas está longe de ser suficiente — páginas são rastreadas constantemente e nunca citadas, seja por renderização no cliente, paywalls, conteúdo superficial ou duplicado, seja simplesmente por perderem para uma fonte melhor na etapa de recuperação/ranking do modelo. A estrutura essencial está no artigo LLM visibility: recuperado → mencionado → citado, e a análise de logs observa apenas a primeira etapa.

A forma honesta de fechar o ciclo é combinar o lado da entrada do rastreamento (seus logs) com o lado da saída das citações. O relatório AI Performance do Bing (prévia pública, fevereiro de 2026) é a primeira ferramenta oficial a expor dados de citações junto das grounding queries — as frases-chave que a IA usou ao recuperar conteúdo referenciado em respostas geradas por IA (Bing Webmaster Blog). Os logs informam o que foi obtido; grounding queries e contagens de citações informam o que resultou disso. Nenhum dos dois é o quadro completo — veja o hub de medição e relatórios para saber como essas camadas se encaixam.

A complicação do rastreamento furtivo

A verificação não é uma auditoria única. Segundo Clint Spaulding, da Seer Interactive, depois de bloqueados, crawlers furtivos podem reaparecer com cabeçalhos genéricos de navegador e IPs não relacionados — essas sessões parecem humanas nos logs, o que infla a contagem de sessões, subestima o tráfego de bots e torna a segmentação por GEO menos confiável (Seer). Seu resumo direto: se você não consegue enxergar esses crawlers furtivos, não consegue medir seu impacto. É exatamente por isso que a análise de logs precisa de reverificação e redefinição periódicas de baseline, não de uma única passada.

Resumo de IA

Uma versão condensada da versão Advanced:

• Análise de logs de crawlers de IA = leitura dos logs brutos do servidor/CDN para solicitações de bots de IA, verificando, com dados de primeira parte, quais bots acessaram você, se são reais e o que obtiveram. GSC (somente Googlebot) e GA4 (somente referrer) não veem isso.
• Escopo: este é o método. O que os bots são está em AI crawlers; o lado dos cliques em AI traffic attribution; o modelo recuperado → mencionado → citado em LLM visibility (os logs observam apenas o que foi recuperado).
• Separe identidade verificada de user agent alegado. User agents são falsificados — a HUMAN Security mediu 5,7% entre 16 bots; Duane Forrester testou 81,8% de falsos entre suas solicitações de busca ao vivo (87% para Googlebot). Compare o UA e confira o IP de origem na lista oficial atual do operador quando existir (por exemplo, openai.com/gptbot.json ou claude.com/crawling/bots.json da Anthropic). Não invente um fallback genérico de DNS reverso.
• Ferramentas por escala: grep → Screaming Frog LFA (predefinições de IA + verificação na importação) → ELK/Splunk → BigQuery / Cloudflare AI Crawl Control.
• Meça: frequência de rastreamento por bot (em rajadas, como as 152 solicitações do GPTBot em 3 minutos na WISLR), páginas acessadas, dependência de HTML bruto (a amostra do ChatGPT-User na WISLR buscou zero imagens/CSS/JS), códigos de status (403/429) e solicitações a robots.txt/llms.txt (a WISLR registrou zero acessos a llms.txt em 48 dias).
• Rastreamento ≠ citação. A recuperação é necessária, não suficiente — “mais rastreamento = mais citações” não foi comprovado. Combine os logs com as grounding queries do Bing para fechar o ciclo.
• Verifique de novo periodicamente — crawlers furtivos bloqueados reaparecem parecendo humanos.

Documentação oficial

Fontes primárias — os próprios arquivos de verificação dos operadores de bots e a documentação das plataformas.

OpenAI

• Documentação de bots/crawlers da OpenAI — strings de user agent e comportamento de GPTBot, OAI-SearchBot, ChatGPT-User e OAI-AdsBot.
• Listas de IP publicadas para verificação: gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json.

Anthropic

• A Anthropic rastreia dados da web? — nomes e finalidades atuais dos bots, controles de robots e a afirmação de que um endereço na lista publicada indica um crawler da Anthropic.
• Lista de IPs dos crawlers da Anthropic — fonte atual compartilhada de verificação para ClaudeBot, Claude-SearchBot e Claude-User.

Google

• Relatório Crawl Stats — a visão do próprio Google sobre atividade de rastreamento (somente Googlebot; não cobre bots de IA de terceiros, razão pela qual são necessários logs brutos).

Cloudflare

• AI Crawl Control — painel gerenciado para atividade de crawlers de IA, verificação de bots e conformidade com diretivas.

Bing / Microsoft

• Introducing AI Performance in Bing Webmaster Tools (Public Preview) — o contraponto de resultado de citações à análise de logs: Total Citations, Average Cited Pages, Grounding Queries e atividade de citações por página.

Citações da fonte

Declarações registradas de operadores e profissionais nomeados.

Anthropic — escopo atual

• A página de suporte atual da Anthropic distingue ClaudeBot, Claude-SearchBot e Claude-User, documenta como seus controles de robots se aplicam e diz que um endereço na lista publicada indica um crawler da Anthropic. Fonte

Lauren Busby, cofundadora da Trebletree — Search Engine Land

• “Log files are the closest thing to that missing layer. They don’t summarize or interpret activity. They record it — every request, every URL, every crawler.” (tradução) «Os arquivos de log são o que mais se aproxima dessa camada ausente. Eles não resumem nem interpretam a atividade; registram cada solicitação, cada URL e cada crawler.»
• “Tools like Screaming Frog Log File Analyzer make it possible to process that data quickly.” (tradução) «Ferramentas como o Screaming Frog Log File Analyzer permitem processar esses dados rapidamente.»
• Sobre a profundidade dos crawlers de IA: “It’s common to see them limited to top-level pages – the homepage, primary navigation, and a small number of high-level URLs.” (tradução) «É comum vê-los limitados às páginas de nível superior: a página inicial, a navegação principal e um pequeno número de URLs de alto nível.»
• Sobre o que os logs revelam: “Log files also surface where crawlers encounter issues. This includes: 403 responses (blocked requests). 429 responses (rate limiting).” (tradução) «Os arquivos de log também mostram onde os crawlers encontram problemas, inclusive respostas 403 (solicitações bloqueadas) e 429 (limitação de taxa).»
• Sobre retenção: “A scheduled SFTP job – whether built in a workflow tool like n8n, or scripted – is enough to turn a short retention window into something you can actually analyze over time.” (tradução) «Uma tarefa SFTP agendada, criada em uma ferramenta de workflow como o n8n ou por script, basta para transformar uma janela curta de retenção em algo que você possa analisar ao longo do tempo.»
• O limite honesto: “Log files show you what reached your site. They don’t always show you what tried to.” (tradução) «Os arquivos de log mostram o que chegou ao seu site, mas nem sempre mostram tudo que tentou chegar.» Fonte (tradução) «Lauren Busby explica que os arquivos de log são a camada que falta porque registram cada solicitação, URL e crawler; ela também descreve as ferramentas, o rastreamento superficial, as respostas 403/429, a extração SFTP agendada e o limite honesto de que os logs mostram o que chegou, não tudo o que tentou chegar.»

Duane Forrester — Search Engine Journal

• “Of 33 requests carrying one of those live-fetch names. Six came from an IP the vendor publishes. Twenty-seven did not. That is an 81.8% spoof rate among the requests I could check.” (tradução) «Das 33 solicitações com um desses nomes de busca ao vivo, seis vieram de um IP publicado pelo fornecedor e 27 não; isso representa uma taxa de falsificação de 81,8% entre as solicitações que pude verificar.»
• “The real check is not complicated. The major operators publish the actual IP addresses their bots use, as plain files you can open right now, and a request is legitimate only if the name matches and the address sits inside the published list.” (tradução) «A verificação real não é complicada: os principais operadores publicam os endereços IP usados por seus bots em arquivos simples, e uma solicitação só é legítima quando o nome corresponde e o endereço está na lista publicada.»
• Sobre o Googlebot, para dar escala: “Of 799 requests carrying the Googlebot name, only 107 came from a verified Google address. The other 692, roughly 87%, were not Google.” (tradução) «Das 799 solicitações com o nome Googlebot, apenas 107 vieram de um endereço verificado do Google; as outras 692, cerca de 87%, não eram do Google.»
• Seu chamado à ação: “Do not take my numbers; take the method… Pull a date range, match the names, verify the IPs against the published lists, and find your real fraction.” (tradução) «Não use meus números; use o método. Extraia um intervalo de datas, compare os nomes, verifique os IPs nas listas publicadas e descubra sua proporção real.» Fonte (tradução) «Duane Forrester descreve a verificação de IPs publicados como o teste real: entre 33 solicitações de busca ao vivo, 27 não correspondiam aos IPs do fornecedor; no Googlebot, apenas 107 de 799 solicitações foram verificadas. Ele recomenda aplicar o método aos próprios logs, não tomar seus números como universais.»

Clint Spaulding, gerente sênior de SEO técnico na Seer Interactive

• “Once blocked, stealth crawlers can reappear under generic browser headers and unrelated IPs.” (tradução) «Depois de bloqueados, crawlers furtivos podem reaparecer sob cabeçalhos genéricos de navegador e IPs sem relação entre si.»
• “These sessions look human in logs. That means session counts get inflated, bot traffic gets undercounted, and GEO segmentation becomes less trustworthy.” (tradução) «Essas sessões parecem humanas nos logs; com isso, as contagens de sessão ficam infladas, o tráfego de bots é subestimado e a segmentação de GEO perde confiabilidade.»
• “If you can’t see these stealth crawlers, you can’t measure their impact.” (tradução) «Se você não consegue enxergar esses crawlers furtivos, não consegue medir o impacto deles.» Fonte (tradução) «Clint Spaulding explica que crawlers furtivos podem reaparecer com cabeçalhos genéricos e IPs diferentes, parecendo humanos nos logs e tornando as contagens de sessão, o tráfego de bots e a segmentação GEO menos confiáveis.»

Screaming Frog — tutorial do Log File Analyser (documentação do produto)

• Sobre a verificação na importação: “Search engine bots are often spoofed, and this performs a lookup against publicly confirmed IP lists to confirm they are genuine.” (tradução) «Bots de mecanismos de busca são frequentemente falsificados, e esse recurso consulta listas públicas de IPs confirmados para verificar se são genuínos.»
• “If you see high request volumes from IPs that don’t verify, you’re likely dealing with fake bot traffic that should be blocked at server level.” (tradução) «Se você observar um volume alto de solicitações vindas de IPs que não passam na verificação, provavelmente está lidando com tráfego falso de bots que deve ser bloqueado no servidor.» Fonte (tradução) «A documentação do Log File Analyser explica que bots de mecanismos de busca são frequentemente falsificados e que a verificação na importação consulta listas públicas de IPs confirmados; volumes altos de IPs não verificados podem indicar tráfego falso que deve ser bloqueado no servidor.»

Bing Webmaster Tools — relatório AI Performance (prévia pública de fevereiro de 2026)

• Consultas de fundamentação (Grounding Queries): “Shows the key phrases the AI used when retrieving content that was referenced in AI-generated answers.” (tradução) «Mostra as frases-chave que a IA usou ao recuperar conteúdo referenciado em respostas geradas por IA.»
• Total de citações (Total Citations): “Shows the total number of citations that are displayed as sources in AI-generated answers during the selected time frame.” (tradução) «Mostra o número total de citações exibidas como fontes em respostas geradas por IA durante o período selecionado.» Fonte (tradução) «O relatório AI Performance do Bing define Grounding Queries como as frases-chave usadas pela IA ao recuperar conteúdo citado e Total Citations como o total de citações exibidas como fontes em respostas geradas por IA no período selecionado.»

“Esta solicitação de bot de IA é real e o que faço com ela?”

Percorra uma linha de log suspeita — ou todo o tráfego de um bot — usando isto. É a lógica de verificação da Etapa 2 transformada em um fluxo.

Checklist de análise de logs de crawlers de IA

Uma passada repetível, desde a extração dos logs até a leitura deles:

• Os logs são capturados com os campos necessários: timestamp, IP do cliente, user agent, caminho da solicitação e código de status (bytes + referrer ajudam).
• Você está extraindo da camada certa — logs da CDN/borda se estiver atrás de Cloudflare/Fastly (muito tráfego de bots nunca chega à origem).
• Uma extração agendada (SFTP/n8n/script) supera a janela de retenção para que você tenha histórico, não apenas os últimos dias.
• Toda solicitação de bot de IA é verificada: user agent comparado e IP de origem conferido na lista publicada pelo operador (DNS reverso como backup).
• Solicitações falsificadas/não verificadas são excluídas das métricas de rastreamento de IA, não contadas como o bot nomeado.
• A frequência de rastreamento tem baseline por bot (observe padrões em rajada e constantes).
• As páginas mais buscadas foram identificadas — e as páginas profundas importantes foram confirmadas como rastreadas.
• Rastreamento versus renderização foi verificado: os bots de IA estão buscando apenas HTML em páginas cujo conteúdo é renderizado por JS? (Registre isso como um teste de dependência de HTML bruto; o comportamento é específico do agente e pode não ser documentado.)
• Os códigos de status foram revisados: 200/304 saudáveis; 404 links quebrados; 403/429 confirmados como intencionais ou corrigidos.
• A presença de solicitações a robots.txt foi verificada (os bots o buscam antes de rastrear?); não há acessos surpresa a caminhos não permitidos.
• Os dados foram combinados com dados do lado das citações (grounding queries do Bing / recursos de IA do GSC) antes de concluir se “está funcionando”.
• A reverificação foi agendada — esta não é uma auditoria única (crawlers furtivos reaparecem parecendo humanos).

Folha de consulta da análise de logs de crawlers de IA

Arquivos de verificação (adicione aos favoritos)

Códigos de status para observar

Verifique, não confie

• User agent sozinho = não verificado. Compare o UA e os dados de verificação publicados pelo provedor quando disponíveis; caso contrário, preserve a incerteza.
• Taxas de spoofing observadas na prática: 5,7% (HUMAN, 16 bots) → 81,8% (logs de buscas ao vivo de Forrester); 87% de Googlebot falso na mesma auditoria.

Indício de dependência do HTML bruto

• Um bot que busca apenas HTML, com zero solicitações de .js/.css/imagens, apresenta um padrão observado de busca. Em uma página dependente de JS, é um sinal de risco, não uma prova universal de capacidade.

Fatos rápidos

• Frequência de rastreamento ≠ probabilidade de citação. A recuperação é necessária, não suficiente.
• Use tokens de robots documentados para a política de rastreamento; mantenha o bloqueio de rede como um controle separado de abuso/segurança.

Scripts para análise de logs de crawlers de IA

O artigo AI crawlers traz o snippet básico de “contar os acessos do bot”. Estes scripts vão além: extração, verificação, divisão por código de status e detecção de rastreamento versus renderização.

1. Extraia todas as linhas de bots de IA (grep + regex)

macOS / Linux — uma alternância sobre os user agents comuns de IA:

# Pull all AI-bot requests from a combined-format access log
grep -Ei 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|Claude-SearchBot|PerplexityBot|Perplexity-User|Applebot|Amazonbot|Bytespider|CCBot|Meta-ExternalAgent' \
  access.log > ai-bots.log

# Count requests per bot (which token, how many hits)
grep -Eoi 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|Claude-User|PerplexityBot|Perplexity-User|CCBot|Bytespider' \
  access.log | sort | uniq -c | sort -rn

PowerShell no Windows:

Select-String -Path .\access.log -Pattern 'GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider' |
  ForEach-Object { ($_ -match '(GPTBot|OAI-SearchBot|ChatGPT-User|ClaudeBot|PerplexityBot|CCBot|Bytespider)') | Out-Null; $Matches[1] } |
  Group-Object | Sort-Object Count -Descending | Select-Object Count, Name

2. Verifique um IP que alega ser GPTBot na lista publicada pela OpenAI

O user agent sozinho não prova nada — confira o IP. Isto baixa a lista da OpenAI e testa se um IP dos seus logs está dentro de algum CIDR publicado:

# Requires jq and (for CIDR math) grepcidr — brew/apt install both
IP="203.0.113.45"   # the IP from your log line
curl -s https://openai.com/gptbot.json \
  | jq -r '.prefixes[].ipv4Prefix // .prefixes[].ipv6Prefix' \
  | while read -r cidr; do
      echo "$IP" | grepcidr "$cidr" >/dev/null 2>&1 && echo "VERIFIED in $cidr"
    done
# No output = the IP is NOT in OpenAI's published range → treat as spoofed.

Para a Anthropic, baixe a lista atual https://claude.com/crawling/bots.json e ajuste o caminho do jq ao formato documentado. Se outro operador não publicar um feed de verificação atual, mantenha o resultado como um user agent alegado.

3. Fallback de DNS reverso + direto (IPs fora da lista)

Use isto apenas quando o provedor nomeado publicar um sufixo de hostname esperado e o procedimento de verificação reversa + direta. Não é uma prova genérica da identidade do bot:

IP="203.0.113.45"
HOST=$(host "$IP" | awk '/pointer/ {print $NF}' | sed 's/\.$//')
echo "PTR: $HOST"
host "$HOST" | grep -q "$IP" && echo "FORWARD-CONFIRMED" || echo "MISMATCH → suspect"

4. Divisão por código de status para cada bot

Encontre bloqueios 403/429 e 404s que os bots estão acessando:

# For GPTBot: tally status codes (combined log format; $9 is the status)
grep -i 'GPTBot' access.log | awk '{print $9}' | sort | uniq -c | sort -rn
# → e.g. "812 200 / 47 404 / 15 403" — the 403s are worth investigating

5. Sinal de dependência de HTML bruto — que tipos de arquivo o bot busca?

Se um bot alegado só busca .html// e nunca .js/.css/imagens, e seu conteúdo é renderizado por JS, isso é um sinal de dependência para investigar:

# What extensions is ChatGPT-User actually requesting?
grep -i 'ChatGPT-User' access.log \
  | awk '{print $7}' \
  | grep -oE '\.(html?|js|css|png|jpe?g|webp|svg|woff2?)(\?|$)' \
  | sort | uniq -c | sort -rn
# All HTML, zero subresources = compare the raw body with provider-specific outcomes.

6. Console do Chrome DevTools — encontre buscadores de IA em uma página ativa

Não é uma consulta de log, mas uma verificação rápida do que a página entrega no HTML bruto e depois do JS (o que um bot de IA veria e não veria). Cole no Console:

// Compare rendered text length to what's in the initial HTML source.
// A big gap means most content depends on JS; provider behavior must be verified separately.
(async () => {
  const raw = await (await fetch(location.href, { cache: "no-store" })).text();
  const rawText = new DOMParser().parseFromString(raw, "text/html").body.innerText.trim().length;
  const renderedText = document.body.innerText.trim().length;
  console.log({ rawText, renderedText, jsDependentRatio: +(1 - rawText / renderedText).toFixed(2) });
})();
// jsDependentRatio near 1 = almost all content is JS-injected; flag dependency, not invisibility.

7. Bookmarklet — abra a lista de IP de cada bot de uma vez

Arraste isto como favorito para abrir os arquivos de verificação em abas e fazer uma consulta rápida:

javascript:(function(){["https://openai.com/gptbot.json","https://openai.com/searchbot.json","https://openai.com/chatgpt-user.json","https://claude.com/crawling/bots.json"].forEach(u=>window.open(u,"_blank"));})();

SOP: revisão mensal dos logs de crawlers de IA

Um procedimento recorrente para executar periodicamente (mensalmente na maioria dos sites; semanalmente se o tráfego de IA for relevante). Ele produz um baseline comparável a cada execução.

Preparação

1. Extraia a janela de logs desde a última revisão da camada correta (logs da CDN/borda se estiver atrás de uma CDN; logs da origem caso contrário). Confirme que a extração SFTP/n8n agendada realmente foi executada — falhas aqui quebram silenciosamente as linhas de tendência.
2. Carregue no seu sistema de registro (Screaming Frog LFA para importações periódicas; BigQuery/ELK se estiver usando um pipeline).

Verifique (nunca pule) 3. Atualize cada fonte de verificação publicada atualmente pelos provedores (gptbot.json, searchbot.json, chatgpt-user.json, adsbot.json e claude.com/crawling/bots.json da Anthropic) — elas mudam. 4. Ative a verificação na importação (Screaming Frog) ou execute a checagem de IP-em-CIDR (aba Scripts) contra cada solicitação de bot de IA. 5. Divida o tráfego em verificado e não verificado. Informe a fração não verificada — essa é sua taxa de spoofing do período. Um aumento já é um achado.

Meça (somente tráfego verificado) 6. Frequência de rastreamento por bot versus o período anterior — registre bots novos, desaparecidos e rajadas. 7. Páginas mais buscadas; confirme que páginas prioritárias/profundas são rastreadas. 8. Verificação pontual de dependência de HTML bruto em 2–3 templates pesados em JS (os bots estão buscando apenas HTML?). 9. Divisão de códigos de status por bot; investigue novos agrupamentos de 403/429/404. 10. Presença de solicitações a robots.txt / llms.txt e quaisquer acessos a caminhos não permitidos.

Relate e aja 11. Registre os números do período em uma planilha contínua (acessos verificados por bot, % de spoofing, páginas principais, agrupamentos de erros) para manter tendência, não snapshots. 12. Combine com dados do lado das citações (grounding queries do Bing / recursos de IA do GSC) antes de concluir qualquer coisa sobre visibilidade. 13. Abra correções concretas: bloqueios intencionais versus acidentais, lacunas de renderização JS, links quebrados e regras precisas de user agent para falsificadores confirmados.

Nota de periodicidade: execute a verificação a cada período — não armazene em cache uma lista de IPs “conhecida como boa”. Crawlers furtivos reaparecem com novos IPs e UAs genéricos.

Playbook: “GPTBot (ou ClaudeBot) está recebendo 403/429 e não sei se isso é intencional”

Um runbook linear para o incidente comum — um bot de IA verificado está encontrando erros nos seus logs. Trabalhe na ordem.

Etapa 1 — Confirme primeiro que é o bot verdadeiro. Antes de tudo, use o método oficial atual de verificação do provedor nomeado. Se não existir, a identidade continua não verificada; não a promova silenciosamente a genuína nem a rebaixe a falsificada. O 403 ainda pode ser o WAF cumprindo seu papel.

Etapa 2 — Identifique a resposta exata e de onde ela vem. Extraia a divisão de códigos de status desse bot (aba Scripts). É 403 (bloqueado), 429 (limitado por taxa) ou 503? Anote se o bloqueio está na CDN/WAF, na configuração do servidor ou em regras relacionadas ao robots.txt.

Etapa 3 — Decida: o bloqueio é intencional?

• Você pretendia bloquear este bot (por exemplo, um crawler de treinamento do qual optou por não participar) → o 403 funciona como planejado. Mantenha a política de robots documentada separada de qualquer regra de abuso/segurança em nível de rede. Fim.
• Você NÃO pretendia bloqueá-lo (por exemplo, OAI-SearchBot/PerplexityBot e você quer visibilidade em buscas de IA) → continue.

Etapa 4 — Encontre a regra acidental. Culpados comuns: uma regra WAF “bot” ampla demais, um limite de taxa baixo demais para um crawler em rajadas (lembre-se do pico de 114 solicitações/minuto do GPTBot na WISLR — um limite por minuto pode disparar com rajadas legítimas), uma diretiva de robots.txt que você esqueceu ou um bloqueio por GEO/ASN que captura os intervalos do operador.

Etapa 5 — Corrija com precisão. Inclua o bot verificado na lista de permissões por user agent + intervalo de IP publicado, ou aumente especificamente o teto de limitação de taxa para ele. Não reduza a proteção para todos.

Etapa 6 — Verifique a correção nos logs. Depois de fazer o deploy, extraia novamente os logs desse bot. O agrupamento de 403/429 deve se transformar em 200/304 nas páginas importantes para você.

Etapa 7 — Refaça o baseline e observe. Registre a mudança na planilha contínua. Confira no próximo período — e fique atento ao bot reaparecer com outro UA caso você tenha pretendido bloqueá-lo (rastreamento furtivo).

Erros de análise de logs que produzem conclusões erradas

Cada item é uma crença encontrada na prática, por que está errado e o que fazer no lugar.

Mito: “Se meu robots.txt bloqueia um bot, ele não estará nos meus logs / não é um problema.” Por que está errado: robots.txt é uma solicitação, não uma aplicação de bloqueio. Buscadores acionados pelo usuário se excluem explicitamente, e alguns crawlers foram relatados como capazes de contornar bloqueios (rastreamento furtivo da Perplexity, Cloudflare em agosto de 2025). O bloqueio pode ser completamente ignorado. Faça isto: use os logs para verificar se a regra é respeitada — procure acessos a caminhos não permitidos e veja se o bot sequer solicita /robots.txt.

Mito: “Um user agent GPTBot/ClaudeBot nos meus logs significa que é realmente OpenAI/Anthropic.” Por que está errado: user agents são fáceis de falsificar — a HUMAN Security mediu 5,7% de falsos entre 16 bots, e Duane Forrester encontrou 81,8% de falsos entre suas próprias solicitações de busca ao vivo. Faça isto: compare o user agent e use o método oficial atual de verificação do operador quando existir; caso contrário, rotule a identidade como não verificada.

Mito: “Mais acessos de crawlers de IA = maior probabilidade de ser citado.” Por que está errado: não há dados causais ou correlacionais estabelecidos que sustentem isso. A recuperação é necessária, mas não suficiente — páginas muito rastreadas ficam constantemente sem citação. Faça isto: trate os logs como visibilidade apenas da etapa recuperada e combine-os com dados do lado das citações (grounding queries do Bing, recursos de IA do GSC).

Mito: “Todo crawler de IA tem o mesmo comportamento de renderização.” Por que está errado: os provedores não publicam um contrato compartilhado de JavaScript/subrecursos, e o comportamento observado difere conforme o agente e a amostra. Faça isto: compare a resposta bruta com a página renderizada, inspecione as solicitações de subrecursos por bot nomeado e rotule o resultado como observado, não universal.

Mito: “Os bots de IA pelo menos estão verificando meu llms.txt.” Por que está errado: a amostra de 48 dias da WISLR registrou zero solicitações a /llms.txt de qualquer bot de IA, em linha com o achado de aproximadamente 97% de não leitura no artigo AI crawlers. Faça isto: não trate solicitações a llms.txt como uma validação esperada; meça o que os bots realmente buscam.

Mito: “Bloqueio de rede e política de robots são o mesmo controle.” Por que está errado: robots comunica preferências de rastreamento; um firewall aplica acesso de rede e pode afetar tráfego não relacionado. Faça isto: use a regra documentada de user agent para a política e reserve o bloqueio de rede para uma resposta de abuso/segurança justificada separadamente.

Casos reais

Duane Forrester — taxas de spoofing testadas nos próprios logs. Forrester aplicou esse método exato ao site e publicou os números. Entre 33 solicitações de busca ao vivo, apenas 6 vieram de um IP publicado pelo fornecedor — taxa de spoofing de 81,8%; entre 799 solicitações com nome Googlebot, apenas 107 foram verificadas — aproximadamente 87% falsas (SEJ). Antes: confiar no user agent fazia o tráfego do seu “assistente de IA” parecer real. Depois: comparar nomes com listas de IP publicadas revelou que a maior parte era personificação. Lição: o método importa mais que os números específicos dele — como ele diz, extraia seu próprio intervalo de datas e descubra sua fração real.

WISLR — 48 dias de logs de CDN, a assinatura de rastreamento versus renderização. Tony Castillo analisou 288 566 linhas de logs de CDN (12 099 solicitações de IA/bots) ao longo de 48 dias (WISLR). Achados concretos: o GPTBot ficou ausente por semanas e depois fez uma rajada de 152 solicitações em três minutos (pico de 114 solicitações/minuto); o ChatGPT-User buscou zero imagens, CSS ou JS — extração puramente de HTML; e houve zero solicitações a /llms.txt durante toda a janela. Antes: você presumiria rastreamento constante e bots conscientes de JS. Depois: os logs mostram comportamento em rajada e somente HTML — n=1, dados de um único site, mas um retrato vívido do que uma análise real revela. Lição: o padrão de busca sem JS é a evidência direta por trás da checagem de rastreamento versus renderização.

Cloudflare — a proporção entre rastreamento e referral em escala de rede. Os dados agregados da Cloudflare mostram como pouco rastreamento se transforma em tráfego: para cada visitante que a Anthropic encaminha a um site, seus crawlers já visitaram dezenas de milhares de páginas (Cloudflare). Antes: a intuição de que rastreamento intenso significa engajamento. Depois: em escala de rede, a proporção é desequilibrada — o treinamento agora impulsiona a maioria da atividade de bots de IA, e bots de treinamento não têm a finalidade de enviar tráfego de volta (Cloudflare). Lição: uma página muito rastreada sem nenhum referral é normal, não um sinal de sucesso — exatamente por isso a frequência de rastreamento não prevê citações.

Prompts de IA prontos para uso

Prompts para copiar e colar em um LLM e acelerar a análise de logs de crawlers de IA. Sempre confira o resultado contra os logs brutos — LLMs alucinam, e um pipeline de verificação que confia em uma correspondência de IP alucinada é pior que nenhum pipeline.

Crie um parser de logs consciente de verificação

Write a Python script that parses combined-format Nginx access logs and, for each
request whose user-agent matches a known AI bot (GPTBot, OAI-SearchBot,
ChatGPT-User, ClaudeBot, Claude-User, PerplexityBot, Perplexity-User, CCBot,
Bytespider), does the following:

1. Extract timestamp, client IP, request path, status code, user-agent.
2. Fetch and cache OpenAI's current IP lists (gptbot.json, searchbot.json,
   chatgpt-user.json, adsbot.json) and Anthropic's current bots.json list.
3. Mark an OpenAI or Anthropic request VERIFIED only if the user-agent matches AND
   the client IP falls inside the matching provider-published ranges; mark providers
   without an official method UNVERIFIED, not spoofed.
4. Output two CSVs: verified requests and unverified ("spoofed") requests.
5. Print a summary: verified vs. unverified count per bot, and the top 20 fetched
   paths (verified only).

Do NOT count unverified requests in any per-bot metric. Add clear comments.

Resuma um relatório de códigos de status + rastreamento versus renderização

I'll paste a table of AI-bot log data (columns: bot, path, status_code,
file_extension). Produce:
- A per-bot status-code breakdown, flagging any 403/429/404 clusters.
- A raw-HTML dependency read: for each bot, the ratio of HTML requests to
  JS/CSS/image requests, and a note on whether the bot appears to fetch only HTML
  in this sample. Treat HTML-only on a JS-rendered page as a dependency risk, not
  proof of a universal no-JavaScript capability.
Keep every conclusion tied to a number from the data — do not infer beyond it.

DATA:
[paste]

Faça a triagem de um IP suspeito

A request in my logs claims to be [BOT NAME] from IP [IP ADDRESS]. Walk me through
verifying it: which operator IP-list file to check, how to test whether the IP is
in range, and the reverse+forward DNS fallback if it's not on a published list.
Tell me explicitly what result means "verified" vs. "treat as spoofed." Do not
guess whether this specific IP is legitimate — give me the steps to check.

Ferramentas para análise de logs de crawlers de IA

Aproximadamente de gratuita/fonte de verdade → paga/gerenciada:

• grep / PowerShell — a maneira mais rápida de contar acessos de bots e filtrar um log de acesso bruto levando a verificação em conta. Zero configuração; veja a aba Scripts.
• Screaming Frog Log File Analyser — importador de desktop com predefinições de bots de IA e a opção “Verify Bots When Importing”, que confere listas de IP confirmadas publicamente. Abas Response Codes, User Agents, URLs (ordene por Num Events) e IPs. Melhor para importações periódicas.
• ELK Stack (Elasticsearch / Logstash / Kibana) ou Splunk — ingestão contínua, painéis e alertas quando uma importação de desktop fica lenta ou você quer monitoramento contínuo.
• BigQuery — retenção de longo prazo e SQL em escala, normalmente alimentado pelo Cloudflare Logpush ou por uma extração GraphQL agendada de httpRequestsAdaptiveGroups.
• Cloudflare AI Crawl Control — para sites atrás da Cloudflare: visões gerenciadas da atividade dos crawlers, verificação de bots e conformidade com diretivas sem seu próprio pipeline.
• Google Search Console — Crawl Stats — não serve para bots de IA (somente Googlebot), mas é o modelo da divisão por crawler e código de resposta que você está reconstruindo para bots de IA a partir dos logs brutos.
• Bing Webmaster Tools — AI Performance — o contraponto do resultado de citações: combine suas grounding queries e contagens de citações com os logs de entrada de rastreamento.

O tráfego alegado de bots de IA dispara durante a noite

Sintoma: solicitações com o user agent de um crawler famoso aumentam repentinamente. Causa provável: spoofing, tráfego de monitoramento ou uma mudança real no rastreamento. Correção: verifique os IPs de origem conforme o método publicado atualmente pelo operador antes de atribuir o tráfego; depois segmente por ASN, caminho, status e horário.

Os logs mostram rastreamento, mas o conteúdo nunca é citado

Sintoma: bots verificados buscam páginas sem ganhos visíveis de citações. Causa provável: rastreamento é apenas evidência de elegibilidade; recuperação e seleção da resposta são etapas separadas. Correção: confirme que o bot recebeu HTML substancial e avalie indexabilidade, qualidade do trecho, adequação à consulta e corroboracão externa sem tratar a contagem de rastreamento como ranking.

Toda solicitação parece retornar 200

Sintoma: URLs ausentes e conteúdo bloqueado são registrados como sucesso. Causa provável: um app shell, uma regra da CDN ou uma página de erro personalizada retorna um soft 404. Correção: faça amostragem dos corpos das respostas e dos cabeçalhos finais e corrija o tratamento de status em vez de confiar apenas no status.

Bots verificados recebem um shell vazio

Sintoma: um navegador renderiza o conteúdo, mas as buscas correspondentes aos logs recebem pouco HTML útil. Causa provável: a página depende de JavaScript no cliente que o crawler não executa. Correção: compare a saída bruta e renderizada e entregue conteúdo e links essenciais no HTML por SSR, renderização estática ou outra estratégia confiável.

Métricas para logs de crawlers de IA

Recursos que valem seu tempo

Meus textos relacionados

• Como fazer uma análise de arquivos de log para SEO (Ahrefs, revisado por Patrick Stox e Michal Pecánek) — o modelo da era pré-IA de que este artigo é a sequência específica para IA: o que medir, ferramentas e verificação de bots.
• O que é análise de arquivos de log? (glossário do Ahrefs) — o complemento definicional.
• Conheça os novos rastreadores da web: bots de IA se aproximam dos bots de mecanismos de busca — minha análise no Cloudflare Radar da participação de rastreamento de bots de IA.
• Os bots de IA que cerca de 140 milhões de sites mais bloqueiam — dados de taxa de bloqueio em robots.txt na web aberta.
• 80% do nosso tráfego de busca por IA vai para a página inicial, páginas de produto e ferramentas gratuitas — análise da atividade de IA por tipo de página, análoga a “quais páginas são rastreadas”.

Minhas palestras

• Como a busca funciona (SlideShare) — minha explicação de rastreamento, renderização, indexação e ranking, útil para interpretar o que os bots fazem nos seus logs. (O aviso permanente se aplica: este é meu entendimento dos sistemas, não uma garantia de que esteja 100% completo ou correto.)

Do setor

• Por que a análise de logs importa para crawlers de IA e visibilidade na busca — Lauren Busby (Trebletree), Search Engine Land: a ideia de que “logs são a camada que faltava”, retenção e o enquadramento de 403/429.
• 81,8% do meu tráfego de “assistente de IA” era falso; o número do Googlebot foi pior — Duane Forrester, Search Engine Journal: o estudo de caso e método de verificação de primeira parte mais marcantes.
• Perplexity, rastreamento furtivo por IA e os impactos em GEO e na análise de logs — Clint Spaulding, Seer Interactive: por que bots bloqueados reaparecem parecendo humanos.
• Como monitorar bots de IA no Log File Analyser — Screaming Frog: tutorial prático da ferramenta com verificação na importação.
• A lacuna entre rastreamento e clique: dados da Cloudflare sobre bots de IA, treinamento e referências — Cloudflare: proporções entre rastreamento e referral em nível de rede e divisão entre treinamento e busca.
• A Anthropic rastreia dados da web? — documentação atual da Anthropic sobre finalidade dos bots e controle por robots.
• Documentação de bots/crawlers da OpenAI — strings de user agent e arquivos de IP publicados para verificação.

Estatísticas que vale citar

• Taxa de spoofing — 5,7% entre 16 crawlers de IA. A análise de duas semanas da HUMAN Security sobre tráfego que alegava ser de um dos 16 crawlers de IA conhecidos descobriu que aproximadamente 1 em 18 solicitações era falsificada (número do fornecedor transmitido pela SEJ).
• Taxa de spoofing — 81,8% nos logs de um profissional. A auditoria feita por Duane Forrester encontrou 27 de 33 solicitações de busca ao vivo vindas de IPs que os fornecedores não publicam; o número dele para Googlebot era aproximadamente 87% falso (SEJ).
• Relação rastreamento-referral, ClaudeBot versus OpenAI. Os dados da Cloudflare (semana de 25 de maio a 1º de junho de 2026) registraram aproximadamente 11 122 páginas rastreadas por referral para ClaudeBot e uma relação de aproximadamente 857:1 para OpenAI, contra cerca de 5:1 para Googlebot (Cloudflare).
• Treinamento impulsiona a maior parte da atividade de bots de IA. Segundo a Cloudflare, o treinamento agora representa quase 80% da atividade de bots de IA, contra 72% um ano antes — contexto para entender por que muito rastreamento sem referral é normal (Cloudflare).
• Uma janela real de logs: 288 566 linhas, 12 099 solicitações de bots, 48 dias. O estudo de caso da WISLR — com a rajada de 152 solicitações do GPTBot em 3 minutos e as buscas do ChatGPT-User sem imagens/CSS/JS (WISLR).

Teste seus conhecimentos: análise de logs de crawlers de IA

Cinco perguntas rápidas sobre extrair e ler logs de bots de IA. Escolha uma resposta para cada uma e depois confira.

Registro de alterações