Lá em 2021 herdei um cliente, uma varejista de e-commerce em Birmingham com cerca de 52.000 URLs indexadas, que não conseguia descobrir por que aproximadamente 18.000 de suas páginas de produto não tinham sido rastreadas em mais de três meses. O time de dev deles estava chutando. Adicionando sitemaps XML. Avisando Google Search Console. Nada funcionava. Aí peguei os logs do servidor brutos e em cerca de quarenta minutos a resposta era completamente óbvia: Googlebot estava queimando sua cota diária de rastreamento em URLs de paginação com filtros, parâmetros de sessão e uma faceta de busca interna quebrada que gerava algo como 4.000 URLs únicos mas inúteis por semana. Desperdício total. Completa besteira.
Ponto-chave: logs de servidor mostram exatamente quais páginas o Googlebot realmente lê em um site de 50 mil páginas; análise de logs é a única verdade absoluta para decisões de crawl budget.
É para isso que análise de arquivo de log serve realmente, não para métricas de vaidade, não para slides de sala de reunião, mas para descobrir exatamente o que um rastreador está fazendo no seu site em qualquer terça-feira e cortar a gordura sem piedade.
Por Que Orçamento de Rastreamento Realmente Importa em Escala
Aqui está a coisa que a maioria das pessoas entende errado. Crawl budget não é preocupação para um site de brochura com 200 páginas. Googlebot varre isso em minutos. Mas quando você passa, digamos, 20.000 URLs, e definitivamente quando você está em 50.000 ou mais, o rastreador do Google toma decisões explícitas sobre o que priorizar. A própria documentação do Google chama isso de "crawl budget" e o divide em dois componentes: crawl rate limit (a velocidade com que Googlebot rastreia sem sobrecarregar seu servidor) e crawl demand (o quanto Google realmente quer rastrear baseado em sinais de popularidade e atualização).
Ambos podem ser manipulados. Mas você não pode manipular o que não consegue medir. E você não consegue medir corretamente sem os logs.
Ferramentas de análise como Google Search Console fornecem um relatório de estatísticas de rastreamento. É bom como ponto de partida. Mas é agregado, atrasado, e não diz quais URLs específicas estão consumindo o budget. Logs de servidor fazem isso. Mostram cada requisição que o Googlebot fez, para qual URL, em que hora, e qual código de status HTTP recebeu. Esse é o material bruto.
Obtendo os Logs
Parece óbvio, mas é aqui que a maioria das pessoas empaca. Dependendo da sua configuração de hospedagem, os logs ficam em lugares diferentes.
Em um host WordPress gerenciado como WP Engine ou Kinsta, você pode extrair logs de acesso brutos do dashboard ou via SFTP, procure no diretório /logs/. Em uma VPS rodando Nginx, seu access log fica tipicamente em /var/log/nginx/access.log. Apache coloca em /var/log/apache2/access.log. Se você está em um CDN como Cloudflare, você precisará de Cloudflare Logpush (tier enterprise) ou só verá requisições de CDN-edge, não da origin, diferença importante.
Para aquele cliente de Birmingham, eles estavam em um servidor gerenciado Kinsta. Puxei 30 dias de logs, que totalizaram cerca de 4.2GB de arquivos comprimidos .gz. Esse é um tamanho normal para um site ocupado com 50K páginas.
Analisando Logs Brutos Sem Perder a Cabeça
Você tem duas opções reais aqui:
- Screaming Frog Log File Analyser, Isso é o que uso 90% do tempo. Você importa os arquivos de log diretamente, filtra por user agent Googlebot, e ele dá um breakdown ordenável de URLs rastreadas, frequência de rastreamento, status codes e tempos de resposta. Honestamente, para a maioria do trabalho de agência é a ferramenta certa. O log analyser do Screaming Frog lida com arquivos de até vários GB sem cair, o que importa.
- ELK Stack (Elasticsearch, Logstash, Kibana), Mais setup, significativamente mais poder. Se você tem necessidades de monitoramento contínuo para um cliente grande ou um contrato enterprise, vale a pena o investimento. Seahawk tem alguns clientes onde alimentamos logs diretamente em um dashboard Kibana. Em tempo real, bonito, e você pode configurar alertas quando a frequência de rastreamento do Googlebot cai de repente.
Para um audit único, Screaming Frog Log File Analyser é adequado. Para qualquer coisa contínua, construa a ELK stack ou pelo menos considere GoAccess, é open source, roda no terminal, e processa arquivos de log grandes mais rápido que quase qualquer outra coisa que testei.
O Que Você Realmente Deve Procurar
Uma vez que os dados estão carregados, a maioria das pessoas fica olhando para eles sem saber que perguntas fazer. Aqui está o que eu realmente procuro em uma auditoria de log:
Distribuição de Frequência de Crawl
Ordene suas URLs por frequência de rastreamento, quantas vezes Googlebot acessou cada URL na janela de 30 dias. Você quase sempre encontrará uma distribuição bimodal. Um cluster de URLs importantes sendo rastreadas frequentemente (bom) e uma cauda longa de URLs lixo que também estão sendo rastreadas frequentemente (muito ruim). Essa cauda lixo é seu problema.
No site de Birmingham, os top 500 URLs rastreados incluíram 340 combinações de filtro/faceta. Nenhuma delas estava indexada. Nenhuma delas tinha nenhum volume de busca. O Googlebot estava visitando ?colour=red&size=M&sort=price_asc mais frequentemente do que estava visitando as páginas de categoria real. Selvagem.
Breakdown de Código de Status
Filtre tudo o que não é um 200. Especificamente:
- 404s sendo rastreados repetidamente, Essa é uma hemorragia de crawl budget. Corrija com redirects 301 ou conserte os links internos que apontam para eles.
- 301 chains, Um redirecionamento que vai A → B → C é dois hops desperdiçados. O Googlebot segue eles mas custa budget e o PageRank vaza a cada salto.
- 500 errors, Se o Googlebot está atingindo páginas que retornam 500s e depois tentando novamente, você está desperdiçando budget E prejudicando sua crawlability score com Google ao longo do tempo.
- 304 Not Modified, Na verdade tudo bem. Significa que Google está verificando freshness e seus caching headers estão funcionando corretamente.
Picos de Tempo de Resposta
Google disse publicamente que tempos de resposta lentos do servidor fazem o Googlebot rastrear menos agressivamente. Se seus logs mostram tempos de resposta médios acima de 500ms para URLs rastreadas, particularmente páginas de categoria ou produto, esse é um sinal para corrigir seu caching do lado do servidor antes de qualquer outra coisa.
Identificando os Assassinos de Orçamento
Vou dar a você uma lista dos pontos que vejo consumindo orçamento de rastreamento em sites grandes, em ordem aproximada de frequência com que os encontro:
- Faceted navigation sem noindex ou disallow, Filtros, color pickers, seletores de tamanho, ordenações. Esses multiplicam sua contagem de URL geometricamente. Uma categoria de produto com 10 opções de filtro e 5 ordenações gera 50+ variantes de URL duplicadas. Em um site de 50K páginas, isso é potencialmente centenas de milhares de URLs.
- Paginated archives crawled infinitamente, /page/2, /page/3.../page/847. Se o conteúdo na página 200 do seu arquivo de blog tem zero valor de busca orgânica, você precisa ou fazer noindex ou disallow do caminho de paginação no robots.txt.
- Session IDs em URLs, Plataformas CMS antigas (e alguns setups WooCommerce legacy) anexam session tokens como ?sessionid=abc123def456 às URLs. Cada sessão gera uma URL única. Googlebot rastreia todas elas. Isso é um vazamento de budget catastrófico em sites mais antigos.
- Duplicate content via URL parameters, ?utm_source=email em links internos, parâmetros de rastreamento vazando em URLs rastreáveis, ?ref=homepage anexado por plugins de afiliados. Corrija na URL parameter tool do Google Search Console e canonicalize no nível HTML.
- Orphaned pages sem links internos mas ainda no sitemap, Googlebot as encontra via sitemap, as rastreia, não encontra sinal interno, deprioritiza elas ao longo do tempo. Mas elas ainda consomem budget em discovery crawls.
- Soft 404 pages retornando status 200, Páginas de busca sem resultados, páginas de categoria vazias, páginas de perfil de usuário para contas deletadas. Google desperdiça tempo rastreando essas e às vezes as indexa.
Corrigindo o Que Você Encontra
Honestamente, a análise é a parte mais fácil. A implementação é onde os projetos ficam políticos.
Aqui está meu fluxo de trabalho real quando termino uma auditoria de logs e preciso apresentar recomendações:
- Robots.txt disallow para padrões de URL que nunca devem ser rastreados, parâmetros de sessão, combinações de filtros, URLs de resultados de busca interna. Uso regras Disallow: /*?sessionid=style com wildcard. Teste cada regra no testador de robots.txt do Google Search Console antes de fazer deploy.
- Noindex + nofollow em páginas paginadas além da página 2 ou 3, dependendo da atualização do conteúdo. Não desabilite a paginação inteiramente ou você quebra a capacidade do Googlebot de descobrir conteúdo vinculado.
- Tags canonical em todas as variantes de URL parametrizadas apontando para a URL canonical limpa. Isso é segurança dupla além do robots.txt.
- Corrija 404s na origem, atualize os links internos ou implemente redirecionamentos 301. Uso o crawler principal do Screaming Frog junto com dados de log para encontrar quais páginas estão linkando para URLs mortas.
- Higiene do XML sitemap, remova qualquer URL do seu sitemap que retorne um status diferente de 200, esteja noindexada ou seja um redirecionamento. Seu sitemap deve ser uma lista curada de páginas que você quer indexadas, nada mais.
Seahawk teve um cliente fintech no ano passado, cerca de 65.000 páginas, principalmente conteúdo dinâmico, onde apenas corrigir o robots.txt para bloquear padrões de URL de busca interna reduziu o rastreamento do Googlebot de URLs lixo em 61% dentro de seis semanas. Os 39% restantes do orçamento de rastreamento foram direcionados para páginas de produto e categoria. A indexação de novo conteúdo caiu de uma média de 23 dias para 6 dias. Esse é o impacto do mundo real.
Configurando Monitoramento Contínuo
Um audit de log é um snapshot. Boa gestão de crawl budget é contínua. Como isso realmente funciona na prática?
No mínimo, recomendo extrair e analisar logs mensalmente para qualquer site acima de 30.000 páginas. Analise a tendência de frequência de rastreamento para suas 100 URLs que geram mais receita. Se a frequência de visitas do Googlebot a essas páginas está diminuindo, algo mudou, novos vazamentos de orçamento de rastreamento, problemas de performance do servidor, ou uma queda no sinal de PageRank.
Se você quer ser mais sofisticado, configure GoAccess como um cron job para processar snapshots de logs diários e enviar um relatório de resumo por email. Leva cerca de duas horas para configurar e te poupa de perder erosão lenta do crawl budget entre audits trimestrais.
FAQ
Crawl budget importa se eu já estou totalmente indexado?
De certa forma. Indexação completa hoje não significa que permaneça assim. Se você está publicando novo conteúdo regularmente, novos produtos, novos posts de blog, novas landing pages, o orçamento de rastreamento determina com que velocidade esse conteúdo fresco é encontrado. Um site com orçamento de rastreamento com vazamento pode ter novas páginas sem inspeção por semanas. Essa é uma desvantagem competitiva real se você está em um nicho em movimento rápido.
Devo bloquear o Googlebot inteiramente de certas subpastas usando robots.txt?
Sim, em casos específicos. Áreas de admin, caminhos de staging, resultados de busca interna e URLs de filtro com muitos parâmetros são todos candidatos razoáveis para regras Disallow. A única coisa que eu alertaria é contra bloqueamento de arquivos JavaScript ou CSS, o Googlebot precisa deles para renderizar suas páginas corretamente. Muito conselho SEO antigo diz para bloquear JS; ignore isso.
Quantos dados de log devo analisar?
30 dias é o ponto ideal para a maioria dos sites. Menos que isso e você não verá padrões de rastreamento de baixa frequência. Mais que isso e os tamanhos de arquivo ficam difíceis de lidar a menos que você esteja rodando uma stack ELK adequada. Para sites de e-commerce sazonais, às vezes vejo 60 dias abrangendo um período de pico para entender o comportamento de rastreamento sob carga de tráfego.
E se meu host não fornecer acesso aos logs brutos?
Pressione seu provedor de hospedagem, a maioria dos hosts gerenciados têm isso disponível mesmo que não seja destacado de forma proeminente no painel. Se você realmente não conseguir obter logs brutos, a análise de bots do Cloudflare pode dar uma visão parcial para sites atrás do proxy Cloudflare, embora seja um substituto pobre para dados de log reais. Considere trocar de host se isso for um bloqueador recorrente em uma conta de cliente grande.
As estatísticas de rastreamento do Google Search Console são suficientes?
Para um site pequeno, argumentavelmente sim. Para qualquer coisa acima de 20K páginas, não. As estatísticas de rastreamento do GSC são agregadas por dia e não apresentam dados no nível de URL. Você pode ver que o Googlebot rastreou 12.000 páginas em uma terça-feira, mas não quais são as 12.000 páginas. Arquivos de log oferecem essa resolução. Ambas as ferramentas juntas, essa é a visão completa.
---
Olha, a maioria dos SEOs pula a análise de log files porque parece território de DevOps. Não é glamouroso. Você está fazendo grep em gigabytes de timestamps e user-agent strings. Mas em sites grandes, é a diferença entre chutar onde seu crawl budget está indo e realmente saber. E saber, na minha experiência, sempre vale as duas horas que leva para puxar os dados.
Leitura relacionada: Pesquisa de palavras-chave com IA em 2026: o que é, por que tradicional, busca com IA e SEO multilíngue.