Elyson Gums
Atualizado em 31/10/2026
16 min de leitura
O Google muda mais rápido do que você consegue acompanhar? Não se preocupe, isso é comum pra muita gente.
Se inscreva na nossa Newsletter e fique por dentro das novidades de SEO.
Inscreva-se
A análise de logs de servidor é o processo técnico de coleta, verificação e interpretação dos registros brutos de acesso de um servidor web. Por meio deles, é possível auditar empiricamente o comportamento de web crawlers e obter definições sem ambiguidade sobre a frequência, os caminhos percorridos e os códigos de resposta encontrados.
Os logs de servidor documentam todas as requisições efetivamente processadas. Consta ali a quantidade de hits ao servidor, o tempo para enviar os dados, quais páginas foram acessadas, quais não foram, quais erros foram encontrados, entre outras informações.
Portanto, os logs do servidor são os dados brutos da rastreabilidade de um site. Isto é, a fonte definitiva para observar como os crawlers de IA e de mecanismos de busca acessam um domínio, e quais seções eles deixam de visitar. Portanto, são diferentes de fontes como Search Console e GA4, que oferecem dados parciais, filtrados ou por amostragem.
A análise de logs do servidor é o processo de tratamento e auditoria dos registros de conexões e requisições HTTP/HTTPS processadas pelo site.
Esses dados têm algumas particularidades, inacessíveis em outras fontes de dados de SEO:
A principal finalidade da análise de logs é a solução de problemas complexos de SEO técnico, difíceis de mensurar com dados de terceiros. Portanto, são realizadas esporadicamente, durante cenários de alto impacto, como picos ou quedas de tráfego, suspeita de consumo ineficiente de crawl budget, migrações, entre outros.
Os servidores web gravam os logs no formato de texto ASCII, uma linha por transação HTTP, na ordem em que elas acontecem.
Cada servidor segue um formato próprio:
Ao longo deste texto, seguiremos usando Apache, NGINX e IIS como exemplos.
O caminho de uma requisição até o registro de um log segue cinco etapas:
Os dois formatos mais comuns são o Combined, usado pelo NGINX e compatível com Apache, e o W3C, usado pelo IIS e por servidores proxy. O formato CLF é mais antigo e entrega menos informações.
A sintaxe de cada formato muda, mas, em linhas gerais, eles armazenam os mesmos dados essenciais de cada requisição.
Uma linha é composta por sete elementos:
| Elemento | NGINX e Apache | W3C |
| Endereço IP do cliente | $remote_addr ou %h. Se o acesso passa por proxy, registra o IP do proxy (documentação do Apache). | c-ip |
| Timestamp | [$time_local] ou %t, entre colchetes, no formato [dia/mês/ano:hora:minuto:segundo fuso]. | date e time, em dois campos (YYYY-MM-DD e HH:MM:SS), em GMT/UTC. |
| Método HTTP | Dentro de “$request”. Exemplos: GET (buscar conteúdo), POST (enviar dados), HEAD (verificar cabeçalhos). | cs-method |
| URL solicitada | Dentro de “$request”, com a versão do protocolo (por exemplo /artigos/seo-tecnico.html HTTP/1.1). | cs-uri ou cs-uri-stem |
| Código de status HTTP | $status ou %>s: 2XX (sucesso), 3XX (redirecionamento), 4XX (erro do cliente), 5XX (erro do servidor), etc. | sc-status |
| Tamanho da resposta | $body_bytes_sent ou %b, sem os cabeçalhos HTTP. | sc-bytes ou bytes |
| User-Agent | “$http_user_agent” ou %{User-agent}i, entre aspas. | cs(User-Agent) |
Exemplo de linha Combined (NGINX e Apache):
# $remote_addr – remoteuser[time_local] “$request” $status bodybytessent”http_referer” “$http_user_agent”
66.249.66.1 – – [26/Oct/2026:14:32:10 -0300] “GET /categoria/seo-tecnico HTTP/1.1” 200 15420 “https://www.google.com/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
Exemplo de linha W3C (Microsoft IIS):
#Version: 1.0
#Date: 2026-10-26 17:32:10
#Fields: date time c-ip cs-method cs-uri-stem sc-status sc-bytes cs(User-Agent)
2026-10-26 17:32:10 66.249.66.1 GET /categoria/seo-tecnico 200 15420 “Mozilla/5.0+(compatible;+Googlebot/2.1;++http://www.google.com/bot.html)”
É o cruzamento desses campos que permite as análises de logs de servidor. Por exemplo, filtrar por user-agent permite identificar se o tráfego é legítimo ou se há um scraper malicioso falsificando sua identidade (spoofing). Como os dados ficam armazenados em ordem cronológica, é possível acompanhar variações em longos intervalos de tempo, ao longo de meses.
Os dados das ferramentas de analytics são coletados no navegador (client-side). Portanto, qualquer interferência na execução de scripts pode limitar o que é registrado, o que altera a confiabilidade nas análises. É por isso que os logs de servidor são considerados a fonte “definitiva” para entender a interação de robôs com um site.
Há duas diferenças principais entre as métricas externas e os logs de servidor.
A primeira é a forma de coleta. Ferramentas externas usam tags JavaScript, que devem ser executadas no navegador do usuário, como a tag do Google. Se houver algum bloqueio, não há registro. Já a coleta de logs é passiva e não depende de interação do lado do cliente.
A segunda é a precisão sobre quais URLs foram acessadas. Há várias formas de mapear o tráfego, mas elas não mostram o cenário completo. Citando apenas algumas: o rastreamento simulado mostra o que um robô consegue descobrir pelos links; o Search Console mostra o que o Google exibiu e indexou; e o analytics registra visitas de usuários, geralmente filtrando bots.
Os logs de servidor registram todas as requisições, sem exceção. Por isso, eles são a fonte mais completa para auditorias minuciosas. Na rotina de SEO, a maioria das decisões não exige esse nível de detalhe.
Gestão de rastreamento é o conjunto de processos para direcionar os recursos dos buscadores e IAs para as URLs prioritárias de um site. A análise de logs permite identificar o desperdício desses recursos.
Tal ação é relevante sobretudo para os sites grandes, com dez mil URLs ou mais. Nesses sites, os logs mostram como o Googlebot e o Bingbot distribuem suas requisições entre as URLs.
A análise de logs de servidor permite realizar os seguintes tipos de análises:
Veja abaixo três tipos de análises úteis na resolução de problemas de SEO técnico.
Spoofing é a falsificação do User-Agent, o cabeçalho no qual um agente de rastreamento se identifica. Por meio dos logs, é possível verificar o IP, identificar os bots suspeitos e posteriormente bloqueá-los.
Bots que praticam o spoofing são maliciosos. Eles tentam se mascarar para fazer raspagens não autorizadas e burlar diretrizes do robots.txt. Esse tipo de bot também desrespeita os limites do servidor, causando sobrecargas devido ao excesso de requisições.
Por fim, esses bots podem prejudicar as análises, já que os dados dos robôs falsos e verdadeiros ficam misturados.
Veja abaixo como fazer a verificação nos logs de servidor, de acordo com a documentação do Google:
Armadilhas de rastreamento são páginas de baixo valor que atrapalham os web crawlers, intencionalmente ou não. Elas criam caminhos difíceis de seguir, como loops ou excesso de páginas. Elas estão entre as maiores fontes de desperdício de crawl budget e podem ser identificadas via análise de logs.
O Google aponta seis tipos principais de URLs de baixo valor:
Elas estão no grupo de URLs mais difíceis de rastrear para o Google, apresentado pelos engenheiros Gary Illyes e Martin Splitt no início de 2026.
Por meio dos logs de servidor, é possível entender se essas URLs difíceis ou de baixo valor foram requisitadas, e com qual frequência. Isto, por sua vez, orienta a otimização e ajuda a definir as prioridades.
As melhores práticas são:
Os códigos de status HTTP são enviados pelo servidor, indicando se uma requisição foi concluída com sucesso, se houve erros e quais foram. Eles ficam armazenados nos logs e podem ser auditados.
No SEO técnico, os códigos HTTP mais relevantes são:
O campo no Apache é %>s. No NGINX, é $status. No IIS, é sc-status.
Para realizar as análises:
Em sites com muito tráfego ou muitas URLs, o volume de logs cresce rápido.
Segundo a documentação do Apache HTTP Server 2.4, um log cresce em média 1 MB a cada 10.000 requisições. Logo, se houver dezenas de milhões de requisições por dia, os arquivos tornam-se muito pesados, o que inviabiliza o processamento manual e exige uma arquitetura com automações em camadas.
O artigo web server log analysis, publicado na IJCRT, propõe um pipeline de dados com cinco estágios:
Regex e ferramentas de linha de comando (CLI) são estratégias para filtrar os milhões de linhas de logs geradas por dia em um site grande. Elas permitem reduzir o volume inicial de registros, o que acelera o diagnóstico e economiza recursos.
Pressione as frases abaixo para ver exemplos de aplicação para SEO técnico.
# Linhas com requisições do Googlebot, Bingbot ou Yandex
grep -Ei “Googlebot|Bingbot|YandexBot” access.log > bots_filtrados.log
# Para arquivos compactados (.gz), usar o zgrep:
zgrep -Ei “Googlebot|Bingbot|YandexBot” access.log.gz > bots_filtrados.log
grep “Googlebot” access.log | awk ‘{print $1}’ | sort | uniq -c | sort -nr | head -n 20
awk ‘$0 ~ /Googlebot/ && $9 ~ /^[45]/ {print $1, $4, $7, $9}’ access.log
grep “Googlebot” access.log | sed -n ‘s/.*”GET []* HTTP.*/\1/p’ | sort | uniq -c | sort -nr | head -n 30
Outro recurso amplamente usado na análise de logs de sites grandes são os dashboards e ferramentas de parsing de logs. Elas permitem importar arquivos para um software como o Screaming Frog, o que habilita monitoramento contínuo, com ingestão de eventos e registros em tempo real.
Entre as stacks de observabilidade usadas para isso estão a ELK (Elasticsearch, Logstash e Kibana) e o Loggly. Ferramentas de SIEM têm função semelhante.
Um pipeline de dados para logs tem, geralmente, três etapas principais:
Deste modo, é possível explorar os numerosos registros de um site grande, sem recorrer sempre às análises manuais extensas e demoradas.
As consultorias de SEO técnico da SEO Happy Hour incluem a análise de logs de servidor para detectar anomalias complexas. Entre elas, instabilidade em servidor, quedas de visibilidade em tráfego orgânico, entre outras. Entre em contato e saiba mais.
Elyson Gums é redator na SEO Happy Hour. Trabalha com redação e produção de conteúdo para projetos de SEO e inbound marketing desde 2014, em segmentos B2C e B2B. É bacharel em Jornalismo (Univali/SC) e mestre em Comunicação Social (UFPR).
Comentários