Análise de Arquivos de Log

TL;DR — Seu servidor web mantém um registro de cada solicitação que recebe, incluindo visitas de bots de mecanismos de busca como o Googlebot. A análise de arquivos de log consiste em ler esse registro para ver exatamente quais das suas páginas os bots realmente buscaram, com que frequência e se encontraram erros. É o único lugar que mostra o que realmente aconteceu — mas a maioria dos sites pequenos não precisa disso.

Toque para expandir

The four-week chart compares automated and human requests to HTML content. Bot share is higher in the captured worldwide Cloudflare traffic period.

O que é um arquivo de log

Toda vez que alguém — uma pessoa, o Googlebot ou algum bot aleatório — solicita uma página do seu site, seu servidor escreve uma linha sobre isso em um arquivo. Esse arquivo é o seu log de acesso. Cada linha registra aproximadamente as mesmas coisas:

• quem pediu (um endereço IP e um nome de “user agent” como Googlebot),
• o que pediram (a URL),
• quando (um carimbo de data/hora) e
• o que receberam de volta (um código de status HTTP — 200 para OK, 404 para não encontrado, e assim por diante).

Acumule semanas dessas linhas e você terá um registro completo e honesto de como os mecanismos de busca rastreiam seu site. Não uma estimativa. As solicitações reais.

Por que se preocupar em ler isso

Outras ferramentas de SEO ou adivinham como os bots rastreiam você (uma ferramenta de rastreamento finge ser um mecanismo de busca e percorre seu site) ou resumem isso (o Google Search Console mostra uma visão amostrada e arredondada). Seus logs mostram a coisa real, solicitação por solicitação. Isso permite que você responda a perguntas como:

• Quais páginas o Googlebot realmente visita — e quais ele ignora?
• O bot está perdendo tempo com URLs de lixo em vez das suas páginas importantes?
• Os bots estão encontrando páginas quebradas (404) ou erros de servidor (5xx)?
• Há páginas que os bots nunca alcançaram?

A única regra que você não pode pular

Qualquer um pode fingir ser o Googlebot. O nome do user agent em uma linha de log é apenas texto — um scraper pode colocar Googlebot ali para passar despercebido pelas suas defesas. Então, antes de confiar em uma única linha “Googlebot”, você precisa verificar se é realmente o Google (há uma verificação simples de DNS para isso nas abas Avançado e Scripts). Pule a verificação e você tirará conclusões de tráfego falso.

Você realmente precisa disso?

Sinceramente? Provavelmente não, se você administra um site pequeno. A análise de arquivos de log compensa para sites grandes — dezenas de milhares de URLs, ecommerce com muitas páginas filtradas, sites passando por uma migração ou sites onde o Google diz que “descobriu” páginas, mas nunca as indexou. Se o seu site tem algumas centenas de páginas e todas são rastreadas sem problemas, seu tempo é melhor gasto em outras coisas. (Mesma lógica do orçamento de rastreamento — a maioria dos sites não precisa se preocupar com isso.)

Quer o fluxo de trabalho real — verificar bots corretamente, encontrar desperdício de rastreamento, identificar páginas órfãs? Mude para a aba Avançado.

TL;DR — Os logs são a verdade absoluta não amostrada para o rastreamento: cada solicitação, cada bot, cada código de status. O primeiro passo inegociável é verificar Googlebot/Bingbot via DNS reverso + direto (ou o JSON de faixas de IP publicadas pelo Google) — os user agents são falsificados constantemente, e todos os cálculos de rastreamento devem usar apenas o conjunto verificado. Depois, leia os logs para URLs e seções mais e menos rastreadas, frequência de rastreamento ao longo do tempo, códigos de status priorizados por frequência, desperdício de rastreamento (parâmetros, facetas, busca interna, paginação infinita), páginas órfãs e não rastreadas (cruzadas com um rastreamento) e a divisão do Googlebot entre dispositivos móveis e computadores. O Bing não publica faixas de IP oficiais, então a verificação por DNS em *.search.msn.com é o método recomendado. Os logs complementam as Estatísticas de Rastreamento do GSC — eles não as substituem. Em 2026, os bots de IA já representam uma parcela relevante do tráfego registrado.

Por que os logs são a verdade absoluta

Há três maneiras de “ver” como os mecanismos de busca rastreiam você, e elas não são iguais:

• Uma ferramenta de rastreamento (Screaming Frog SEO Spider, Ahrefs Site Audit) simula um rastreamento. Ela diz o que um bot poderia encontrar, não o que o Google de fato buscou.
• Estatísticas de rastreamento do GSC resumem o que realmente aconteceu, mas são amostradas, agregadas e limitadas (cerca de 1 000 linhas, ~90 dias, sem exportação por URL).
• Logs do servidor registram o que realmente aconteceu — cada solicitação, para cada bot, com a URL exata, o carimbo de data/hora e o código de status.

O guia de arquivos de log da Ahrefs que revisei diz claramente: os logs do servidor são “the most trustworthy source of information to understand the URLs that search engines have crawled.” (tradução) «a fonte de informação mais confiável para entender as URLs que os mecanismos de busca rastrearam». Essa é toda a razão pela qual esta técnica existe. Quando quero saber o que o Googlebot realmente fez — não o que ele poderia fazer, não um resumo arredondado — vou aos logs.

Uma linha de log típica contém o endereço IP, user agent, caminho da URL, carimbo de data/hora, método de solicitação (GET/POST) e código de status HTTP. Tudo abaixo é apenas fatiar esses campos de forma inteligente.

Quando você realmente precisa (e quando não precisa)

Seja honesto consigo mesmo aqui. A análise de arquivos de log é uma ferramenta para sites grandes. Ela se justifica em sites com dezenas de milhares de URLs, comércio eletrônico e navegação facetada, sites em meio a uma migração e sites presos em Discovered – currently not indexed. Como escrevi no meu guia sobre orçamento de rastreamento, “Most sites don’t need to worry about crawl budget, but there are few cases where you may want to take a look.” (tradução) «A maioria dos sites não precisa se preocupar com o orçamento de rastreamento, mas há alguns casos em que vale a pena analisar». Daniel Waisberg, do Google, fez uma observação semelhante sobre as Estatísticas de Rastreamento — de acordo com a cobertura do Search Engine Journal, o relatório não é uma grande preocupação para sites com menos de ~1 000 páginas.

Se o seu site de algumas centenas de páginas está sendo rastreado bem, pule isso e vá consertar algo com mais alavancagem.

Como obter seus logs (a parte mais difícil é o acesso)

Os logs ficam onde a solicitação realmente terminou:

• Apache e Nginx → o formato de log “combined” do Apache (o mais comum).
• Microsoft IIS → formato W3C.
• AWS ELB/ALB → formato ELB.
• CDNs (Cloudflare, Fastly, Akamai) → suas próprias exportações de log. Isso importa: em um site atrás de CDN, um log somente de origem perde os hits de cache de borda, então puxe os logs na camada que o bot realmente alcançou.

Busque no mínimo 30 dias, idealmente 90, para capturar a variação de frequência de rastreamento. E planeje atrito — obter acesso aos logs do servidor costuma ser a parte realmente difícil (barreira de DevOps). Até mesmo Googlers, em um episódio de migração do Search Off the Record, destacaram como os arquivos de log podem ser difíceis de obter na prática. Reserve tempo para solicitação.

Os logs não são apenas tráfego de bot — eles capturam todas as solicitações, incluindo visitantes reais, e podem conter valores de query string, identificadores de sessão ou outros dados sensíveis junto com o caminho da URL. A orientação de logging da OWASP é direta sobre isso: credenciais de autenticação, tokens de acesso e informações pessoalmente identificáveis geralmente não devem cair diretamente em um log; eles devem ser removidos, mascarados ou hashados primeiro. Incorpore isso aos seus controles de acesso e ao processo de exportação antes de entregar um arquivo de log a qualquer pessoa para análise, não depois.

Etapa 1 — Verifique se os bots são reais (faça isso antes de qualquer outra coisa)

Este é o passo que a maioria dos guias menciona em uma linha. Não faça isso. Muitos bots fingem ser Googlebot para passar por firewalls (Ahrefs). O user agent é texto não autenticado; trate cada linha “Googlebot” como uma afirmação a ser comprovada.

Googlebot — dois métodos válidos:

1. DNS reverso + direto (a verificação bidirecional). Os próprios passos do Google: execute uma consulta de DNS reverso no IP dos seus logs com o comando host; verifique se o domínio é googlebot.com, google.com ou googleusercontent.com; em seguida, execute uma consulta de DNS direto nesse hostname e verifique se ele resolve de volta para o IP original. O passo do DNS direto é o que torna isso confiável — um falsificador pode apontar o DNS reverso para um nome *.googlebot.com, mas apenas o caminho de ida e volta até o mesmo IP prova a autenticidade. (Comandos para macOS/Linux e Windows estão na aba Scripts.)
2. Compare com as faixas de IP publicadas pelo Google. O Google publica arquivos JSON com os IPs dos seus crawlers em formato CIDR — common-crawlers.json para o Googlebot e afins, além de special-crawlers.json, os arquivos do buscador acionado pelo usuário e um goog.json com todos os IPs do Google. Como observei no meu guia sobre o Googlebot, o Google “provided a list of public IPs you can use to verify the requests are from Google… You can compare this to the data in your server logs.” (tradução) «forneceu uma lista de IPs públicos que você pode usar para verificar se as solicitações são do Google… Você pode comparar isso com os dados nos logs do seu servidor».

Bingbot — apenas DNS. Este é o contraste principal: o Bing não publica oficialmente faixas de IP. As próprias palavras do Bing são de que ““…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet,”” (tradução) «…como outros mecanismos de busca, o Bing não publica uma lista de endereços IP ou faixas a partir das quais rastreamos a Internet», porque “the IP addresses or ranges we use can change any time.” (tradução) «os endereços IP ou faixas que usamos podem mudar a qualquer momento». Portanto, para o Bingbot, você faz DNS reverso + direto para um hostname que termina em *.search.msn.com (por exemplo, msnbot-157-55-33-18.search.msn.com), ou usa a ferramenta Verify Bingbot. (A Microsoft desde então lançou um JSON de IPs do bingbot, mas suas orientações oficiais de verificação ainda se concentram em DNS precisamente porque os IPs mudam.)

Depois, descarte os falsos. Faça toda a sua análise de rastreamento apenas com o conjunto verificado. “Googlebot” não verificado quase sempre é um scraper ou um bot falsificado e pertence a uma revisão de segurança, não à sua análise de desperdício de rastreamento.

Etapa 2 — O que procurar

Depois de trabalhar com hits verificados, aqui está a leitura:

• URLs e seções mais e menos rastreadas. Classifique as solicitações por URL e por diretório. É para onde seu orçamento de rastreamento está realmente indo — e geralmente é surpreendente.
• Frequência de rastreamento ao longo do tempo. Acompanhe as tendências de rastreamento por URL/seção para detectar quedas (uma migração quebrou algo) ou picos (uma nova seção, ou uma armadilha de spider gerando URLs infinitas).
• Códigos de status que os bots encontram, priorizados por frequência. Quantifique 200 vs. 301/302 (e cadeias), 404 e 5xx. Um 404 acessado 5 000×/semana é um problema diferente de um 404 acessado uma vez — corrija pela frequência de rastreamento, não pela mera existência.
• Desperdício de rastreamento. Navegação facetada, parâmetros de URL, resultados de busca interna e calendários/paginações infinitos podem consumir uma grande parte do orçamento de rastreamento em casos graves. Os logs mostram exatamente quais padrões de lixo os bots estão gastando tempo.
• Páginas órfãs e não rastreadas. Isso requer ambos os conjuntos de dados. Cruze os logs com um rastreamento do site: URLs nos logs, mas não no rastreamento = órfãs, redirecionamentos antigos ou páginas com links externos; URLs no rastreamento, mas não nos logs = páginas que o Google nunca buscou.
• Googlebot móvel vs. desktop. Divida por user agent. Após o mobile-first, deve ser majoritariamente Googlebot Smartphone — uma divisão com peso em desktop merece uma análise.
• Tempo de resposta e saúde do rastreamento. O aumento do tempo médio de resposta está correlacionado com a redução do rastreamento. De acordo com o artigo do SEJ sobre as orientações de Waisberg: “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (tradução) «Observe se o tempo médio de resposta aumenta de forma consistente. Segundo o Google, isso talvez não altere a taxa de rastreamento imediatamente, mas sinaliza que seus servidores podem não estar suportando toda a carga».

O que os logs NÃO dizem

Mantenha essas distinções claras ou você vai interpretar demais os dados:

• Rastreamento ≠ indexação. Uma URL que o Googlebot busca diariamente pode permanecer não indexada indefinidamente. Os logs comprovam busca, não status de indexação — combine-os com o relatório de indexação de páginas e a ferramenta de inspeção de URL do GSC para avaliar a indexação.
• Rastreamento ≠ posição, e mais rastreamento não ajuda. Como já disse repetidamente, “The rate of crawling isn’t going to impact your rankings.” (tradução) «A taxa de rastreamento não vai impactar seu ranqueamento». Não persiga o volume de rastreamento como se fosse uma alavanca de ranqueamento.
• noindex não reduz o rastreamento. noindex controla a indexação, não o rastreamento — para realmente interromper o rastreamento, use robots.txt ou um código de status.
• Rastreamento ≠ treinamento de modelo ou citação. Um hit verificado do GPTBot, ClaudeBot ou PerplexityBot prova que essa solicitação aconteceu — uma busca nessa camada. Isso não prova que a página foi usada para treinar um modelo, retida em qualquer lugar downstream ou citada em uma resposta de chat. Esses são resultados separados e não observados; não estique uma linha de log verificada além do que ela mostra.

A novidade de 2026: bots de IA estão por toda parte nos seus logs agora

O elenco de personagens em um arquivo de log moderno mudou. Na minha análise de dados do Cloudflare Radar (Conheça os novos rastreadores da web), os bots de mecanismos de busca ainda rastreiam mais — mas os bots de IA estão firmemente em segundo lugar e a caminho de ultrapassá-los dentro de alguns anos. GPTBot, ClaudeBot, PerplexityBot e companhia agora aparecem com frequência. Ao segmentar seus hits verificados por user agent, não se surpreenda ao encontrar rastreadores de IA rivalizando com os mecanismos de busca em participação de solicitações. (O Log File Analyser do Screaming Frog adicionou um tutorial dedicado a bots de IA exatamente para isso.)

Como isso se encaixa com o resto do rastreamento

Os logs são a camada de diagnóstico sob todo o cluster de rastreamento. É assim que você realmente mede o gasto de orçamento de rastreamento que os mecanismos descrevem de forma abstrata (Gary Illyes o define como “the number of URLs Googlebot can and is willing or is instructed to crawl” (tradução) «o número de URLs que o Googlebot pode, está disposto ou é instruído a rastrear»). É também como você pega armadilhas de rastreamento em flagrante — um espaço infinito de URLs de um calendário ou faceta aparece como uma enxurrada de solicitações quase idênticas — e como você confirma se seu trabalho de frequência de rastreamento (lastmod preciso, links internos para páginas importantes) realmente mudou o comportamento dos bots. E lembre-se de que eles complementam, não substituem, as Estatísticas de Rastreamento do GSC: o relatório é a visão inicial amostrada; os logs fornecem o detalhe não amostrado, por URL e para vários bots.

Resumo de IA

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

• Logs = verdade absoluta. Ferramentas de rastreamento simulam, o GSC amostra; os logs de acesso do servidor registram cada solicitação, cada bot, com URL, timestamp e código de status.
• Verifique antes de analisar. User agents são falsificados constantemente. Confirme o Googlebot via DNS reverso + direto ou o JSON de faixas de IP publicado pelo Google; confirme o Bingbot via DNS reverso para *.search.msn.com (o Bing não publica faixas de IP oficiais). Faça toda a matemática de rastreamento apenas no conjunto verificado.
• O que ler: URLs e seções mais/menos rastreadas; frequência de rastreamento ao longo do tempo; códigos de status priorizados por frequência (um 404 com 5 000 hits/semana ≠ uma vez); desperdício de rastreamento (parâmetros, facetas, busca interna, paginação infinita); páginas órfãs e não rastreadas (cruze com um rastreamento); divisão entre Googlebot mobile e desktop; aumento do tempo de resposta como um aviso de saúde do rastreamento.
• Não interprete demais: rastreamento ≠ indexação ≠ posição, mais rastreamento não ajuda no ranqueamento, noindex não reduz o rastreamento, e um hit verificado de bot de IA prova uma busca — não que a página foi usada para treinamento de modelo ou citada em uma resposta.
• Escopo: uma ferramenta para sites grandes / ecommerce / migração. A maioria dos sites pequenos não precisa dela.
• 2026: bots de IA (GPTBot, ClaudeBot, PerplexityBot) agora são uma parcela importante e crescente do tráfego de logs.
• Complementa o GSC Crawl Stats — use ambos.

Documentação oficial

Documentação de fonte primária para verificar rastreadores e ler dados de rastreamento.

Google

• Verificar solicitações de rastreadores e buscadores do Google — os dois métodos oficiais: DNS reverso + direto manual e correspondência com as faixas de IP publicadas.
• Como verificar o Googlebot (Blog da Central de Pesquisa) — o post complementar mais antigo, ainda citado.
• common-crawlers.json — IPs do Googlebot e de rastreadores comuns em formato CIDR (observação: “the IP addresses in the JSON files are represented in CIDR format” (tradução) «os endereços IP nos arquivos JSON são representados em formato CIDR»). Complementos: special-crawlers.json, user-triggered-fetchers.json e o goog.json de todo o Google.
• Visão geral dos rastreadores e buscadores do Google — todos os user agents do Google que você verá nos logs.
• Relatório de estatísticas de rastreamento (Ajuda) e o blog de lançamento — a visão oficial e amostrada que os logs complementam.

Bing / Microsoft

• Como verificar o Bingbot (ajuda do Webmaster) — a página oficial de verificação.
• Como verificar que o Bingbot é o Bingbot (blog) — o método canônico de DNS reverso + direto e a declaração de que o Bing não publica faixas de IP.
• Ferramenta Verificar Bingbot — cole um IP para verificá-lo.

Citações da fonte

Declarações registradas. Quando compatível, cada link é um link profundo que salta para a passagem citada na página de origem.

Google — verificação de rastreadores

• “Run a reverse DNS lookup on the accessing IP address from your logs, using the host command.” (tradução) «Execute uma consulta DNS reversa no endereço IP de acesso dos seus logs, usando o comando host.» Ver a citação
• “Verify that the domain name is either googlebot.com, google.com, or googleusercontent.com.” (tradução) «Verifique se o nome de domínio é googlebot.com, google.com ou googleusercontent.com.» Ver a citação
• “Run a forward DNS lookup on the domain name retrieved in step 1 using the host command on the retrieved domain name.” (tradução) «Execute uma consulta DNS direta no nome de domínio obtido na etapa 1 usando o comando host no nome de domínio obtido.» Ver a citação
• “Verify that it’s the same as the original accessing IP address from your logs.” (tradução) «Verifique se é o mesmo endereço IP de acesso original dos seus logs.» Ver a citação

Bing — verificação e nenhuma faixa de IP publicada

• “Perform a reverse DNS lookup using the IP address from the logs to verify that it resolves to a name that end with search.msn.com.” (tradução) «Execute uma consulta DNS reversa usando o endereço IP dos logs para verificar se ele resolve para um nome que termina com search.msn.com.» — Blog do Bing Webmaster. Ver a citação
• ““…like other search engines, Bing does not publish a list of IP addresses or ranges from which we crawl the Internet.”” (tradução) «…como outros mecanismos de busca, o Bing não publica uma lista de endereços IP ou faixas a partir das quais rastreamos a Internet.» — e o motivo: “the IP addresses or ranges we use can change any time, so responding to requests differently based on a hardcoded list is not a recommended approach.” (tradução) «os endereços IP ou faixas que usamos podem mudar a qualquer momento, então responder a solicitações de forma diferente com base em uma lista codificada não é uma abordagem recomendada.» Ver a citação

Patrick Stox — sobre para que servem os logs (do meu trabalho na Ahrefs)

• Os logs do servidor são “the most trustworthy source of information to understand the URLs that search engines have crawled.” (tradução) «a fonte de informação mais confiável para entender as URLs que os mecanismos de busca rastrearam.» Ver a citação
• “Many bots pretend to be Googlebot to get past firewalls.” (tradução) «Muitos bots fingem ser Googlebot para passar pelos firewalls.» Ver a citação
• “If you want to see hits from all bots and users, you’ll need access to your log files.” (tradução) «Se você quiser ver os acessos de todos os bots e usuários, precisará de acesso aos seus arquivos de log.» Ver a citação
• “The rate of crawling isn’t going to impact your rankings.” (tradução) «A taxa de rastreamento não vai impactar seu ranqueamento.» Ver a citação

Gary Illyes, Google — orçamento de rastreamento (o que os logs permitem medir)

• Orçamento de rastreamento é “the number of URLs Googlebot can and is willing or is instructed to crawl.” (tradução) «o número de URLs que o Googlebot pode, está disposto ou é instruído a rastrear.» Leia a cobertura

Daniel Waisberg, Google — tempo de resposta como sinal de saúde do rastreamento (enquadramento do SEJ sobre a orientação dele sobre o Relatório de Estatísticas de Rastreamento)

• “Watch out for a consistent increase in average response time. Google says it might not affect crawl rate immediately, but it’s a good indicator that your servers might not be handling all the load.” (tradução) «Fique atento a um aumento consistente no tempo médio de resposta. O Google diz que isso pode não afetar a taxa de rastreamento imediatamente, mas é um bom indicador de que seus servidores podem não estar lidando com toda a carga.» Ver a citação

Verifique se um bot é realmente Googlebot (DNS reverso + direto)

O user agent em uma linha de log é apenas texto — scrapers falsificam Googlebot para passar por firewalls. A única verificação confiável é DNS bidirecional: faça a consulta reversa do IP, confirme que o hostname é um domínio do Google, então faça a consulta direta desse hostname e confirme que ele resolve de volta para o mesmo IP.

macOS / Linux (usa host)

# 1) Reverse DNS the IP from your logs — it 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

Windows (uses nslookup)

:: 1) Reverse DNS the IP — confirm it ends in a Google domain
nslookup 66.249.66.1

:: 2) Forward DNS the returned hostname — confirm it matches the original IP
nslookup crawl-66-249-66-1.googlebot.com

Se a consulta reversa não terminar em um domínio do Google, ou se a consulta direta não retornar o IP original, não é Googlebot. (Para Bingbot, execute os mesmos dois passos, mas espere um hostname terminando em search.msn.com.) Você também pode pular o DNS e comparar o IP com as faixas publicadas pelo Google (common-crawlers.json, em formato CIDR).

Extrair e contar acessos de crawlers de um log bruto

Comandos rápidos de uma linha para um log de acesso Apache/Nginx em formato combinado. (Eles selecionam pela string do user-agent — lembre-se de verificar os IPs antes de confiar nas contagens.)

# Pull only the lines claiming to be Googlebot
grep -i "googlebot" access.log > googlebot-hits.log

# Count Googlebot hits per URL, most-crawled first
# (combined format: $7 is the request path)
grep -i "googlebot" access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Count Googlebot hits per status code (combined format: $9 is the status)
grep -i "googlebot" access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# List the URLs Googlebot hit that returned a 404, by frequency
grep -i "googlebot" access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn

# Get the unique IPs claiming Googlebot — the list you then verify by DNS
grep -i "googlebot" access.log | awk '{print $1}' | sort -u

Ajuste as posições dos campos $7/$9 se o seu formato de log for diferente (IIS/W3C e ELB ordenam os campos de forma diferente).

Fluxo de trabalho de análise de arquivos de log

• Obtenha os logs — logs de acesso do servidor, ou exportações de CDN/balanceador de carga. Em um site atrás de CDN, puxe também os logs de borda (a origem perde os hits de cache).
• Pegue uma janela suficiente — mínimo de 30 dias, ideal de 90.
• Verifique os bots primeiro — DNS reverso + direto, ou as faixas de IP publicadas pelo Google. Bingbot → DNS para *.search.msn.com.
• Descarte os falsos — faça todos os cálculos de rastreamento com o conjunto verificado; encaminhe o “Googlebot” falsificado para uma revisão de segurança.
• Classifique as URLs e seções mais e menos rastreadas — veja para onde vai o orçamento.
• Acompanhe a frequência de rastreamento ao longo do tempo — detecte quedas (migrações) e picos (novas seções, armadilhas de rastreamento).
• Totalize os códigos de status — 200 / cadeias 301-302 / 404 / 5xx, e priorize correções pela frequência de rastreamento, não apenas pela existência.
• Cace desperdício de rastreamento — parâmetros, navegação facetada, busca interna, paginação infinita/calendários.
• Encontre órfãos e páginas não rastreadas — cruze os logs com um rastreamento do site (nos logs mas não no rastreamento = órfão; no rastreamento mas não nos logs = nunca buscado).
• Verifique a divisão entre Googlebot mobile e desktop — deve ser majoritariamente Smartphone.
• Observe o tempo médio de resposta — uma tendência de alta pode limitar o rastreamento.
• Segmente os bots de IA — GPTBot, ClaudeBot, PerplexityBot, etc. agora são uma parte real do tráfego.
• Confirme com o GSC — combine os achados de rastreamento com as Estatísticas de Rastreamento e a Inspeção de URLs (rastreamento ≠ indexação).

O que construir na sua planilha de análise

Se você usa o Log File Analyser do Screaming Frog, o BigQuery ou o modelo de arquivo de log da Ahrefs, você está construindo as mesmas poucas visualizações. Depois de verificar os bots, analise cada linha em colunas e faça a pivotagem.

Colunas para extrair de cada linha de log

Pivotagens para construir

• Crawls por URL (e por diretório), em ordem decrescente — mais e menos rastreados.
• Crawls por código de status, depois código de status × URL (para que um 404 de alta frequência se destaque).
• Crawls por dia/semana, segmentados por seção — a tendência de frequência.
• Crawls por bot/user agent — a divisão mobile/desktop, além da participação de bots de IA.
• Uma junção logs vs. crawl (PROCV/mesclagem contra uma exportação de crawl do Screaming Frog ou da Ahrefs) para revelar órfãos e páginas nunca buscadas.

O guia da Ahrefs inclui um modelo para download que configura isso; o guia de análise de arquivos de log o linka.

Como ler um arquivo de log: o que procurar

Uma lente repetível para qualquer análise de log. Verifique primeiro; depois execute estas etapas.

1. Verifique, depois analise. Os dados são tão bons quanto a identidade do bot por trás deles. DNS reverso + direto (ou faixas de IP); analise apenas o conjunto verificado. Bots falsificados → segurança, não SEO.

2. Para onde está indo o orçamento? (mais vs. menos rastreado.) Classifique por URL e por seção. O objetivo é encontrar atenção gasta nos lugares errados — e páginas importantes recebendo pouca atenção.

3. O que os bots estão acessando? (códigos de status, por frequência.) 200 é saudável; cadeias 3xx, 404 e 5xx são vazamentos. Faça a triagem por com que frequência o bot acessa cada um, não apenas se o erro existe.

4. O que está sendo desperdiçado? (desperdício de rastreamento.) Parâmetros, navegação facetada, busca interna, paginação infinita/calendários — os clássicos sumidouros de orçamento. Os logs nomeiam os padrões exatos de problemas.

5. O que está faltando? (órfãos e não rastreados.) Cruze os logs com um rastreamento. Nos logs, mas não no rastreamento = órfão/redirecionamento antigo/link externo. No rastreamento, mas não nos logs = o Google nunca buscou.

6. Quem está rastreando? (segmentação de bots.) Googlebot móvel vs. desktop (deve ser maioria Smartphone), além da parcela de bots de IA que agora rivaliza com os mecanismos de busca.

7. O servidor está saudável? (tempo de resposta.) O aumento do tempo médio de resposta é um alerta precoce de que o rastreamento pode ser limitado.

Ferramentas para análise de arquivos de log

• Screaming Frog SEO Log File Analyser — a ferramenta desktop de trabalho pesado. Ela verifica automaticamente os bots de busca e sinaliza IPs falsificados, e tem filtros de User-Agent + Status de Verificação para análise granular de bots. Importe um rastreamento do SEO Spider e use o filtro “Not In URL Data” (tradução) «Não consta nos dados de URL» para encontrar órfãos — “URLs which were discovered in your logs, but are not present in the crawl data imported.” (tradução) «URLs que foram descobertas nos seus logs, mas não estão presentes nos dados de rastreamento importados». Ela também agora tem um tutorial dedicado para monitoramento de bots de IA. Ferramenta
• BigQuery (e Splunk / ELK Stack / Logflare / logz.io) — para armazenamento e consulta brutos e em larga escala quando o volume de logs é grande demais para uma ferramenta desktop.
• Ahrefs — cruze os logs com um rastreamento do Ahrefs Site Audit para encontrar órfãos e confirmar o que os bots alcançaram. (Minha ferramenta de casa.)
• Semrush Log File Analyzer, OnCrawl, Botify, JetOctopus — outras plataformas de rastreamento+logs, as três últimas voltadas para empresas.
• GSC Crawl Stats — a porta de entrada oficial, gratuita e amostrada. Complementar aos logs brutos, não um substituto: é agregada, limitada e não tem exportação por URL.
• Ferramenta Verify Bingbot — cole um IP para confirmar que é realmente o Bingbot: bing.com/toolbox/verify-bingbot.

Erros a evitar

• Confiar na string “Googlebot” sem verificá-la. Por que está errado: o user agent é texto não autenticado — qualquer pessoa pode colocar Googlebot em um cabeçalho de requisição para passar por defesas ou poluir sua análise com tráfego falso. Em vez disso, faça: execute DNS reverso + direto (ou compare com as faixas de IP publicadas pelo Google) antes que uma única linha conte para seus cálculos de rastreamento.
• Tratar as Estatísticas de rastreamento do GSC como o quadro completo. Por que está errado: elas são amostradas, arredondadas, limitadas a aproximadamente 1 000 linhas e ~90 dias, sem exportação por URL — elas resumem, não registram. Em vez disso, faça: use os logs como a fonte da verdade e as Estatísticas de rastreamento como um complemento, um acesso mais rápido.
• Puxar apenas logs de origem em um site com CDN. Por que está errado: um log de origem perde todas as requisições que o CDN atendeu pelo cache de borda, então você está analisando um quadro incompleto do que os bots realmente receberam. Em vez disso, faça: puxe os logs na camada que o bot realmente alcançou — a exportação do CDN/borda, não apenas o servidor de origem.
• Corrigir erros 404 e 5xx pela existência, não pela frequência. Por que está errado: um 404 acessado uma vez por mês e um 404 acessado 5 000 vezes por semana não são o mesmo problema, mas tratar cada linha de erro como igualmente urgente desperdiça esforço de correção. Em vez disso, faça: classifique os problemas de código de status pela frequência com que os bots realmente os acessam.
• Perseguir o volume de rastreamento como se fosse uma alavanca de ranqueamento. Por que está errado: mais rastreamento não move o ranqueamento — é um sinal de diagnóstico, não uma métrica de crescimento. Em vez disso, faça: use a frequência de rastreamento para detectar problemas (quedas, armadilhas de spider), não como um KPI a ser maximizado.
• Usar noindex para tentar parar o rastreamento. Por que está errado: noindex controla a indexação, não o rastreamento — o Google ainda precisa buscar a página para ver a tag. Em vez disso, faça: bloqueie o próprio rastreamento com robots.txt ou um código de status se esse for o objetivo real.
• Chamar uma URL de “órfã” apenas com base nos logs. Por que está errado: uma URL que aparece nos logs, mas não em um rastreamento recente, pode ser um redirecionamento antigo, um link externo ou uma órfã genuína — os logs sozinhos não podem dizer qual. Em vez disso, faça: cruze os logs com um rastreamento real do site antes de tirar conclusões em qualquer direção.

KPIs permanentes para análise de arquivos de log

Participação de bots verificados

• Métrica: acessos verificados do Googlebot/Bingbot ÷ todos os acessos que afirmam ser Googlebot/Bingbot pelo user agent.
• O que isso indica: quanto do seu “tráfego de bots” é, na verdade, scrapers falsificados em vez de mecanismos de busca reais.
• Como extrair: execute cada IP que afirma ser bot por DNS reverso + direto (ou o JSON de faixas de IP) e conte a taxa de aprovação.
• Referência / faixa realista: não há número universal — depende de quão agressivamente seu site é alvo de scraping. Uma participação verificada baixa ou em queda é o sinal para agir, não um limite fixo.
• Cadência: toda vez que você extrair uma nova janela de logs.

Participação de desperdício de rastreamento

• Métrica: % de requisições verificadas de bots que atingem parâmetros, facetas, busca interna ou paginação/calendários infinitos.
• O que isso indica: quanto do seu orçamento de rastreamento está indo para URLs inúteis em vez de páginas que importam.
• Como extrair: segmente os acessos verificados por padrão de URL (strings de consulta, caminhos conhecidos de facetas/busca).
• Referência / faixa realista: não há figura universal — é genuinamente situacional, dependendo da estrutura de URL e das facetas do seu site. Estabeleça sua própria linha de base na primeira extração e depois acompanhe a tendência.
• Cadência: janela de logs de 30 a 90 dias; reavalie após qualquer limpeza (regras de robots.txt, tratamento de parâmetros, correções de paginação).

Mix de códigos de status, ponderado por frequência

• Métrica: 200 / 3xx / 404 / 5xx como parcela das solicitações verificadas de bots.
• O que ela indica: Onde os bots estão gastando buscas em erros em vez de conteúdo ao vivo, e se isso está piorando.
• Como extraí-la: Some o campo de código de status das linhas de log verificadas.
• Referência / faixa realista: Não há meta universal — depende da idade do site e do histórico de redirecionamentos. Observe a tendência, não um único instantâneo; uma parcela crescente de 404/5xx é o sinal acionável.
• Cadência: 30–90 dias, ou imediatamente após uma migração.

Divisão entre Googlebot móvel e desktop

• Métrica: Parcela de acessos verificados do Googlebot vindos do user agent Smartphone vs. Desktop.
• O que ela indica: Se o Google está realmente rastreando você com prioridade móvel, como esperado após a indexação mobile-first.
• Como extraí-la: Segmente os acessos verificados pela string de UA do Googlebot (Smartphone vs. Desktop).
• Referência / faixa realista: Deve ser majoritariamente Smartphone para a maioria dos sites; uma divisão com peso em desktop merece investigação, não é uma falha grave por si só.
• Cadência: A cada extração de log.

Contagem de páginas órfãs / não rastreadas

• Métrica: URLs nos logs, mas não em um rastreamento recente (órfãs/links antigos), e URLs em um rastreamento recente, mas não nos logs (nunca buscadas).
• O que ela indica: Páginas que os bots não conseguem alcançar facilmente, e páginas para as quais você está linkando e que o Google nunca se preocupou em buscar.
• Como extraí-la: Junte a lista de URLs com acessos verificados a uma exportação de rastreamento do site (Screaming Frog, Ahrefs).
• Referência / faixa realista: Totalmente situacional — depende do tamanho do site e de quão recentemente você migrou ou reestruturou. Acompanhe a contagem ao longo do tempo em vez de comparar com um número externo.
• Cadência: Trimestral para sites grandes, ou imediatamente após uma migração.

Prompts prontos para copiar para análise de logs

Estes são para interpretar dados de log que você já extraiu e verificou — não para gerar dados de log (nunca deixe uma IA inventar linhas de log ou estatísticas).

Resuma o desperdício de rastreamento a partir de uma amostra de URLs

Here is a list of URL paths that verified Googlebot hits landed on, one per
line, from my server logs. Group them into patterns (query parameters,
faceted navigation, internal search, pagination/calendars, or "looks like a
real page"), and tell me which pattern has the most URLs. Don't invent URLs
that aren't in the list — only group what I've pasted.

[paste your URL list here]

Retorno esperado: um pequeno conjunto de grupos nomeados com suas contagens e uma indicação do grupo que parece concentrar o maior desperdício de rastreamento. Use isso como ponto de partida para conferir os caminhos reais, não como resposta definitiva.

Priorize uma análise de códigos de status

I have this table of HTTP status codes and how many times verified Googlebot
hit each one over the last 30 days. Rank them by which I should fix first,
weighting frequency over severity — a 404 hit 5,000 times matters more than a
500 hit twice. Explain the reasoning in one line per row.

status_code, hit_count
[paste your table here]

Retorno esperado: as mesmas linhas reordenadas por prioridade de correção, cada uma com uma justificativa breve. Antes de agir, confira se o raciocínio faz sentido no contexto do seu site.

Redija uma solicitação de acesso a logs para DevOps

Write a short, plain-English email to my DevOps/hosting team asking for
30-90 days of raw web server access logs (Apache/Nginx combined format, or
our CDN's edge logs if we're behind one) for [site name]. Explain in one
sentence why I need it (verifying real Googlebot/Bingbot crawl activity vs
GSC's sampled report) and ask what export format and delivery method works
for them.

Retorno esperado: um breve rascunho de email que você possa editar com o nome real do site. Revise o texto antes do envio; esta ferramenta não enviará mensagens em seu nome.

Explique um resultado de verificação de DNS

I ran a reverse DNS lookup on an IP from my server logs and then a forward
DNS lookup on the hostname it returned. Here's the raw output from the
`host` command. Tell me plainly whether this confirms the request came from
real Googlebot or Bingbot, and point to exactly which line proves or
disproves it.

[paste your host/nslookup output here]

Retorno esperado: um parecer em linguagem simples, vinculado à linha específica da saída. Trate-o como uma segunda opinião, não como substituto para a regra real: o nome do host termina em um domínio do Google ou do Bing, e a consulta direta retorna o IP original.

Recursos que valem seu tempo

Meus escritos relacionados

• Como fazer uma análise de arquivos de log para SEO [modelo incluído] — o guia fundamental da Ahrefs que revisei; o enquadramento e o modelo nos quais este artigo se apoia.
• Quando se preocupar com o orçamento de rastreamento? — quando a análise de logs vale (ou não) o seu tempo.
• O que é o Googlebot e como ele funciona? — os rastreadores e o histórico de verificação de IP.
• Conheça os novos rastreadores da web: bots de IA se aproximam dos bots de busca — por que seus logs parecem diferentes em 2026.
• Guia de SEO técnico para iniciantes — onde o rastreamento e os logs se encaixam no panorama geral.

Minhas palestras

• Como a busca funciona (SlideShare) — minha explicação sobre rastreamento: o Googlebot como mais de 1 000 sistemas, com muitos rastreadores especializados para computadores, dispositivos móveis, imagens, notícias, vídeos e anúncios, compartilhando um único conjunto de orçamento de rastreamento; e solicitações originadas principalmente de Mountain View. É uma verificação útil de coerência dos logs junto com uma validação adequada, nunca em seu lugar. (Aviso permanente: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Este é meu entendimento dos sistemas… não será 100% completo nem preciso».)

De outros

• Screaming Frog Log File Analyser — guia do usuário e tutorial sobre bots de IA.
• Search Engine Land — guia de análise de arquivos de log (Kody Wirth) — passo a passo prático cobrindo formatos, ferramentas e quais padrões procurar.
• Search Engine Journal — Como usar o relatório de estatísticas de rastreamento do Google — orientação de Daniel Waisberg (Google) sobre como ler as estatísticas de rastreamento, incluindo o aviso de tempo de resposta; o melhor complemento para a análise de logs.
• Search Engine Journal — Indexação e orçamento de rastreamento (Illyes + Splitt) — definição oficial de orçamento de rastreamento e como a qualidade impulsiona a demanda de rastreamento.
• Search Engine Roundtable — Endereços IP do Bingbot divulgados — aborda a nuance de que a Microsoft eventualmente publicou um JSON de IPs do bingbot, embora a orientação oficial ainda se concentre em DNS.
• Conductor — Análise de arquivos de log para SEO — explicação acessível sobre o que os logs revelam e como agir com base neles.
• r/TechSEO — a comunidade para depuração de rastreamento/índice.

Vídeos

• Google Search Central (YouTube) — explicações de Martin Splitt sobre rastreamento/renderização e a série Como a Busca do Google funciona; contexto útil sobre os bots cujos acessos você está verificando nos seus logs. Canal

Teste seus conhecimentos

Cinco perguntas sobre verificação de bots e leitura do que seus logs realmente mostram.

Registro de alterações