Análise de logs para SEO: o que o rastreador fez

Análise de logs para SEO é o processo de ler o arquivo bruto que o seu servidor gera a cada requisição e extrair dali o que os rastreadores de busca realmente fizeram no seu site: quais URLs visitaram, quantas vezes, em que sequência e com que código de resposta. É um tipo de dado diferente de qualquer outro que você usa em SEO. O Google Search Console mostra uma amostra agregada e com atraso. Uma ferramenta de crawl simula seu próprio rastreamento, seguindo as regras que você configurou nela, não as do Googlebot. O log do servidor é o único registro de primeira mão do que o bot efetivamente fez, porque foi o seu próprio servidor que recebeu e respondeu àquela requisição.

Essa diferença muda o tipo de pergunta que dá para responder. Em vez de perguntar "essa página está indexada?", você passa a perguntar "o Google sequer visitou essa URL, quando visitou pela última vez, e o que ela devolveu naquele exato momento?". É a diferença entre inferir o comportamento do rastreador e verificá-lo linha por linha. Por isso times técnicos maduros tratam o log como uma fonte separada de dado, não como um substituto do Search Console nem como uma curiosidade de infraestrutura que só interessa ao time de DevOps.

O que existe dentro de uma linha de log (e por que ela é insubstituível)

Um log de acesso padrão, no formato combined do Apache ou do Nginx, registra uma linha por requisição recebida pelo servidor. Cada linha carrega um punhado de campos fixos: o IP de origem, o timestamp exato com data, hora e fuso, o método HTTP e a URL solicitada, o código de status devolvido, o tamanho da resposta em bytes, o referer quando enviado pelo cliente, e o user-agent declarado. Não é uma amostra, não é uma média, não é uma estimativa — é o registro literal de cada requisição que bateu na sua infraestrutura, na ordem em que chegou.

É por isso que o log é insubstituível. O relatório de rastreamento do Search Console agrega dados por dia e mostra amostras de URLs, não o total exaustivo. Um crawler de terceiros, mesmo um bom, simula um rastreamento com as próprias regras de profundidade e prioridade — ele te diz o que uma aranha genérica encontraria, não o que o Googlebot decidiu visitar. O log é o único dos três que documenta um evento real: o bot pediu essa URL, nesse segundo, e o servidor respondeu assim.

• IP de origem da requisição
• Timestamp exato, com data, hora e fuso
• Método HTTP e URL solicitada
• Código de status devolvido (200, 301, 404, 500…)
• Tamanho da resposta em bytes
• Referer, quando o cliente envia
• User-agent declarado pelo cliente

Onde conseguir os logs e em que formato eles chegam

O caminho até o arquivo depende de onde o site está hospedado. Em hospedagem compartilhada com cPanel, os logs brutos de acesso normalmente ficam disponíveis para download direto no painel, sem precisar de acesso root — mas costumam ser rotacionados e apagados depois de alguns dias, então baixar com regularidade é o que garante ter histórico quando você precisar dele. Em VPS ou servidor dedicado com Apache ou Nginx configurados por você, o access.log fica direto no sistema de arquivos, normalmente em formato combined, e a retenção depende só da política de rotação que você definiu.

Sites atrás de CDN ou proxy reverso, como Cloudflare, adicionam uma complicação: se o repasse do IP real do cliente não estiver configurado (via X-Forwarded-For ou equivalente), todo hit no log de origem aparece como vindo do IP do edge da CDN, não do bot de verdade — o que inviabiliza qualquer verificação de origem. Vale checar isso antes de confiar em qualquer análise feita sobre logs de um site atrás de CDN. Como complemento, várias CDNs oferecem exportação de logs no nível de borda (Logpush, na Cloudflare, por exemplo), que registra até requisições respondidas por cache e que nunca chegam a tocar o servidor de origem — uma visão que os logs de origem sozinhos não têm.

Sobre formato: o combined log format tradicional é texto delimitado por espaço, lido com grep e awk sem dificuldade. Configurações mais novas de Nginx e a maioria das exportações de CDN entregam logs estruturados em JSON, mais fáceis de processar programaticamente. Um site com tráfego relevante gera facilmente alguns gigabytes de log por dia, então a estratégia certa é filtrar já na ingestão — por user-agent, por faixa de data, por caminho de URL — em vez de tentar abrir o arquivo inteiro numa planilha.

• Hospedagem compartilhada (cPanel): raw logs baixáveis no painel, geralmente rotacionados e apagados em poucos dias
• VPS ou servidor próprio: access.log do Apache ou Nginx, formato combined configurável, retenção sob seu controle
• Atrás de CDN: confirme se o IP real do cliente está sendo repassado — senão todo hit parece vir do edge
• Exportação de logs de CDN (ex.: Logpush): captura até requisições respondidas por cache, que nunca chegam à origem

Confirmando que o bot é mesmo quem diz ser

Este passo é o que mais gente pula, e é o que mais compromete uma análise de log. O user-agent que aparece numa linha de log é só uma string que o cliente escolheu enviar — não é uma credencial, não é verificado por nada no protocolo HTTP. Qualquer script pode se identificar como "Googlebot" no cabeçalho da requisição, e uma parte considerável do tráfego que se apresenta assim numa análise real não é o Google: são scrapers, ferramentas de terceiros mal configuradas, ou bots que usam o nome do Googlebot para tentar contornar bloqueios e limites de taxa. Se você tira conclusões sobre orçamento de rastreamento a partir de hits não verificados, está medindo a população errada e vai tomar decisões em cima de um dado que nunca foi o Google.

A verificação correta é reverse DNS seguido de um forward DNS de confirmação — é o método que o próprio Google recomenda, exatamente porque um reverse DNS sozinho pode ser manipulado por quem controla o DNS reverso do IP de origem. O processo tem três passos: primeiro, pegue o IP de origem da linha de log. Segundo, faça o reverse DNS lookup desse IP (comando host ou nslookup); o hostname retornado precisa terminar em algo como googlebot.com ou google.com para ser um candidato legítimo do Googlebot. Terceiro, faça o forward DNS lookup desse mesmo hostname e confirme que ele resolve de volta exatamente para o IP original — só aí o hit está verificado. Qualquer linha que falhe numa das duas checagens deve ser descartada antes de entrar em qualquer contagem.

Existe uma alternativa mais rápida para verificação em lote: o Google publica listas de faixas de IP dos seus rastreadores em formato JSON, que podem ser usadas para filtrar um volume grande de linhas de uma vez. É prática para triagem inicial, mas essas listas precisam ser mantidas atualizadas, e o reverse-DNS-com-confirmação continua sendo o teste definitivo quando a dúvida é sobre um hit específico.

• Pegue o IP de origem da requisição que alega ser o bot
• Faça o reverse DNS: o hostname deve terminar em .googlebot.com ou .google.com
• Confirme com um forward DNS: esse hostname precisa resolver de volta para o mesmo IP original
• Descarte qualquer hit que falhe em uma das duas checagens antes de tirar qualquer conclusão

O que os logs respondem que nenhuma outra fonte responde

Depois da verificação, o que sobra é um conjunto de dados que nenhuma outra ferramenta de SEO consegue reconstruir sozinha, porque é um registro completo, não uma amostra nem uma simulação.

Dois desses pontos merecem um exemplo concreto. Em e-commerce com navegação por facetas — filtros de cor, tamanho, faixa de preço, ordenação — cada combinação de filtro pode gerar uma URL com parâmetro própria, e o log frequentemente mostra o rastreador visitando centenas dessas combinações com a mesma frequência que visita páginas de produto de verdade. Isso é orçamento de rastreamento sendo gasto em superfície que não converte, e o log é a única forma de enxergar essa proporção de forma direta, hit por hit. Para achar páginas órfãs, o método é cruzar a lista de URLs que aparecem no log com o inventário real do site — seu próprio crawl mais o sitemap atual. Qualquer URL que aparece rastreada no log mas não está em nenhuma das duas listas é órfã: geralmente uma sobra de uma estrutura antiga, ou o destino de um link externo que ainda existe em algum lugar da web mesmo que ninguém mais aponte para ela de dentro do site.

• Quais URLs são realmente rastreadas e com que frequência — o log mostra a prioridade real do rastreador, não uma suposição baseada na estrutura do site
• Quanto do orçamento de rastreamento vai para páginas sem valor de SEO — parâmetros de sessão, busca interna, variações de ordenação
• URLs de parâmetro e navegação por facetas consumindo hits que poderiam ir para conteúdo novo ou páginas de produto
• Páginas órfãs, rastreadas mesmo sem receber nenhum link interno atual
• Padrões de erro ao longo do tempo — um pico de 500 sempre no mesmo horário aponta para servidor sob carga, não para um bug estático; um pico de 404 numa data específica aponta para uma migração ou remoção mal feita
• O intervalo entre publicar uma página e o primeiro rastreamento dela, comparando o timestamp de publicação com a primeira linha de log verificada naquela URL

Uma primeira análise, passo a passo, em um site de porte médio

Não precisa de um pipeline sofisticado para começar. Para um site de porte médio, um bloco de sete a trinta dias de log já revela padrão suficiente para um primeiro diagnóstico útil — trinta dias captura melhor variações semanais, mas sete já mostra os problemas mais gritantes.

O roteiro prático: primeiro, filtre as linhas cujo user-agent contenha o nome do bot de interesse e aplique a verificação de reverse DNS com confirmação descrita acima, descartando o que não passar. Segundo, agrupe as linhas restantes por URL e conte os hits — a lista ordenada da maior para a menor contagem já mostra, sem nenhuma análise adicional, onde o orçamento de rastreamento está sendo gasto de fato. Terceiro, agrupe por código de status e veja a proporção entre 200, redirecionamentos (301/302), erros de cliente (404/410) e erros de servidor (500) — uma fatia grande fora do 200 já é um sinal a investigar. Quarto, cruze a lista de URLs rastreadas com o inventário real do site (seu próprio crawl mais o sitemap): o que foi rastreado mas não está no inventário é lixo ou órfã; o que está no inventário e nunca foi rastreado é um possível problema de link interno ou de prioridade. Quinto, olhe individualmente as páginas mais importantes para o negócio — não a média do site — e confira a frequência de visita e o status devolvido especificamente para elas.

Para o volume de um site médio, uma planilha ou uma consulta simples com grep e awk já resolve o trabalho. Ferramentas dedicadas, como um analisador de log de rastreamento ou uma consulta em um data warehouse, só passam a valer o esforço quando o arquivo diário chega na casa dos milhões de linhas — antes disso, a complexidade extra não compensa.

• Reúna de 7 a 30 dias de log bruto
• Filtre por user-agent do bot e aplique a verificação de reverse DNS com confirmação
• Agrupe por URL e conte os hits, do maior para o menor
• Agrupe por código de status e veja a proporção de cada faixa
• Cruze URLs rastreadas com o inventário real do site (crawl próprio + sitemap)
• Confira individualmente a frequência e o status das páginas mais importantes do negócio

Quando vale a pena — e quando é esforço desperdiçado

Análise de log compensa quando o orçamento de rastreamento é de fato um recurso escasso: sites grandes ou muito dinâmicos, e-commerce com navegação por facetas gerando milhares de combinações de URL, portais que publicam várias páginas por dia, ou qualquer site que acabou de passar por uma migração ou replataforma. Nesses casos, o log frequentemente revela um problema que nenhuma outra fonte mostraria — porque nesses casos o rastreamento realmente está sendo racionado, e a única forma de saber para onde ele está indo é olhar o registro bruto.

Para um site pequeno, com algumas dezenas de páginas e estrutura estável, o relatório de estatísticas de rastreamento do Search Console, combinado com um monitoramento básico de erros, normalmente já entrega o sinal necessário. Montar um pipeline de log para quarenta páginas raramente compensa o esforço para a maioria dos times — vale guardar esse investimento para um site onde o rastreamento de fato é um recurso disputado. Mesmo um site pequeno pode se beneficiar de uma análise pontual logo depois de um evento específico, como uma migração grande ou uma queda perceptível de páginas indexadas — nesse caso, como diagnóstico único, não como hábito recorrente.