Log file analysis: o que o Googlebot esta realmente fazendo

Search Console reporta 18 mil paginas rastreadas por dia. Seu log de Nginx mostra 47 mil hits do Googlebot, sendo 31 mil em URLs que voce achou que tinha aposentado em 2023. Bem-vindo a parte do SEO que ninguem coloca no pitch deck. Log file analysis e a unica fonte que mostra o que o crawler de fato fez, em qual ordem, com qual frequencia e em qual status code. O resto e narrativa. Antes de qualquer auditoria seria, eu paro de olhar dashboards bonitos e abro um .gz de 8GB no terminal.

O ponto de partida e simples: 30 dias de logs brutos, filtro por user-agent do Googlebot validado por reverse DNS (host 66.249.x.x precisa resolver para googlebot.com), e agregacao por URL, status code e timestamp. Ferramentas como Screaming Frog Log File Analyser resolvem ate 5M de linhas; acima disso, BigQuery ou um pipeline com DuckDB e mais barato. Se voce ainda nao roda BigQuery + GSC: queries que sua agencia nao roda junto, esta deixando metade do sinal na mesa. Os dois se complementam: GSC diz qual query, log diz qual URL o bot priorizou.

A primeira descoberta costuma ser desconfortavel. Em um e-commerce que auditei mes passado, 62% do crawl ia para URLs com parametros de filtro (?cor=azul&tam=M) que nao deviam existir no indice. Isso e Crawl budget: quando se preocupar e como medir queimado em pagina sem valor de busca. A correcao foi cirurgica: canonical apontando para a categoria limpa, parametros no robots.txt e revisao do sitemap. Em 21 dias, o crawl de PDPs reais subiu 34%. Nada disso aparece no relatorio de cobertura ate o estrago estar feito.

Status codes contam a historia que ninguem quer ler. Se 12% das requisicoes do Googlebot retornam 304, esta tudo bem - significa que seu Last-Modified esta funcionando. Se 8% retornam 301, e aceitavel. Acima de 15% de redirects em cadeia, voce esta sangrando equity como discuto em Redirects 301 vs 302: impacto real no ranking. E quando aparecem 5xx esporadicos correlacionados com horarios de pico, o problema nao e SEO, e infra - mas o impacto bate em ranking duas semanas depois. Plote status code por hora num grafico simples e padroes saltam.

Frequencia de crawl por tipo de pagina e o sinal mais subutilizado. Categorias rastreadas a cada 6 horas, PDPs a cada 3 dias, posts de blog a cada 11 dias - esse delta importa. Se um cluster que voce considera estrategico esta sendo visitado uma vez por mes, voce tem problema de Interlinking inteligente: o mapa de autoridade interna e provavelmente de Topical authority: como construir clusters que rankeiam. Cruzar isso com Content decay: identificando posts que estao perdendo trafego revela quais URLs perderam atencao do bot antes de perderem trafego, o que da uma janela de 30-60 dias para agir.

Tres queries que rodo em todo projeto novo. Primeira: top 100 URLs por hits do Googlebot que retornam 404 - so isso ja paga a consultoria. Segunda: URLs no sitemap que nao receberam crawl em 60 dias - candidatas a poda ou reescrita conforme Reescrever ou refazer: a decisao por dados de SERP. Terceira: URLs com crawl alto mas zero impressoes no GSC - quase sempre paginas tecnicas vazando autoridade. Documente, priorize por impacto estimado, e ataque em sprints de duas semanas. Nada de planilha de 400 linhas que ninguem executa.

Takeaway pratico: agende uma extracao mensal dos logs, mantenha um historico de 13 meses (para comparacao year-over-year sem ruido sazonal), e crie alertas para tres metricas - taxa de 5xx do Googlebot acima de 2%, queda de 20% em hits para URLs estrategicas, e aparicao de novos clusters de URLs nao desejadas no top 50 de crawl. Log file analysis nao e projeto pontual, e instrumentacao continua. Quem trata como auditoria anual descobre o problema seis meses depois do trafego cair.