Lá em 2021 herdei um cliente — um varejista de e-commerce em Birmingham com cerca de 52 mil URLs indexadas — que não conseguia entender por que aproximadamente 18 mil de suas páginas de produtos não tinham sido rastreadas em mais de três meses. O time de desenvolvimento deles tinha sido apenas adivinhar. Adicionaram sitemaps XML. Fizeram ping no Google Search Console. Nada funcionou. Aí puxei seus logs de servidor bruto e em cerca de quarenta minutos a resposta ficou completamente óbvia: o Googlebot estava consumindo sua cota diária de rastreamento em URLs de filtros paginados, parâmetros de sessão e uma faceta de busca interna quebrada que gerava algo como 4 mil URLs únicos mas inúteis por semana. Total desperdício. 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.Server logs show exactly which pages Googlebot actually reads on a 50,000-page site; log analysis is the only ground truth for crawl-budget decisions.
É isso que análise de arquivo de log realmente é — não métricas de vaidade, não slides para sala de reunião, mas 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 é uma preocupação para um site institucional de 200 páginas. O Googlebot vai varrer isso em minutos. Mas uma vez que você passa de, digamos, 20 mil URLs — e definitivamente quando você está em 50 mil ou além — 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 (o quão rápido o Googlebot rastreia sem sobrecarregar seu servidor) e crawl demand (o quanto o Google realmente quer rastrear com base em sinais de popularidade e atualização).Google's own documentation calls this "crawl budget" and breaks it down into two components: crawl rate limit (how fast Googlebot crawls without hammering your server) and crawl demand (how much Google actually wants to crawl based on popularity and freshness signals).
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.which specific URLs are eating the budget. Server logs do. They show you every single request Googlebot made, to which URL, at what time, and what HTTP status code it received back. That's the raw material.
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 puxar logs de acesso bruto do painel ou via SFTP — procure no diretório /logs/. Em um VPS rodando Nginx, seu log de acesso normalmente está em /var/log/nginx/access.log. Apache o coloca em /var/log/apache2/access.log. Se você estiver em um CDN como Cloudflare, você vai precisar do Cloudflare Logpush (tier enterprise) ou vai ver apenas requisições do edge do CDN, não da origem — distinção importante.WordPress host like WP Engine or Kinsta, you can pull raw access logs from the dashboard or via SFTP -- look in the/logs/directory. On a VPS running Nginx, your access log is typically at/var/log/nginx/access.log. Apache puts it at/var/log/apache2/access.log. If you're on a CDN like Cloudflare, you'll need Cloudflare Logpush (enterprise tier) or you'll only see CDN-edge requests, not origin -- important distinction.
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..gz files. That's a normal size for a busy 50K-page site.
Analisando Logs Brutos Sem Perder a Cabeça
Você tem duas opções reais aqui:
- Screaming Frog Log File Analyser — Isso é o que eu uso 90% do tempo. Você importa os arquivos de log diretamente, filtra por user agent do Googlebot, e ele te dá um breakdown classificá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 desabar, o que importa. -- This is what I use 90% of the time. You import the log files directly, filter by Googlebot user agent, and it gives you a sortable breakdown of crawled URLs, crawl frequency, status codes, and response times. Honestly, for most agency work it's the right tool.Screaming Frog's log analyser handles files up to several GB without falling over, which matters.
- ELK Stack (Elasticsearch, Logstash, Kibana) — Mais configuração, significativamente mais poder. Se você tem necessidades de monitoramento contínuo para um cliente grande ou um contrato enterprise, isso vale o investimento. A Seahawk tem alguns clientes onde a gente leva logs diretamente para um dashboard Kibana. Tempo real, lindo, e você pode configurar alertas quando a frequência de rastreamento do Googlebot cai de repente. -- More setup, significantly more power. If you've got ongoing monitoring needs for a large client or an enterprise contract, this is worth the investment. Seahawk has a couple of clients where we pipe logs directly into a Kibana dashboard. Real-time, beautiful, and you can set alerts when Googlebot crawl frequency drops suddenly.
Para um audit pontual, Screaming Frog Log File Analyser é ok. 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.GoAccess -- it's open source, runs in the terminal, and processes large log files faster than almost anything else I've tested.
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
Classifique suas URLs por frequência de rastreamento — quantas vezes o Googlebot atingiu cada URL na janela de 30 dias. Você quase sempre vai encontrar uma distribuição bimodal. Um cluster de URLs importantes sendo rastreadas frequentemente (bom) e uma cauda longa de URLs de lixo que também estão sendo rastreadas frequentemente (muito ruim). Essa cauda de 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.?colour=red&size=M&sort=price_asc more often than it was visiting the actual category pages. Wild.
Breakdown de Código de Status
Filtre tudo o que não é um 200. Especificamente:
- 404s sendo rastreados repetidamente -- Esses são uma hemorragia de orçamento de rastreamento. Corrija-os com redirecionamentos 301 ou corrija os links internos que apontam para eles. -- These are a crawl budget haemorrhage. Fix them with 301 redirects or patch the internal links that point to them.
- Cadeias 301 -- Um redirecionamento que vai A → B → C são dois saltos desperdiçados. Googlebot os segue, mas custa orçamento e o PageRank vaza a cada salto. -- A redirect that goes A → B → C is two wasted hops. Googlebot follows them but it costs budget and PageRank leaks at each jump.
- Erros 500 -- Se Googlebot está acessando páginas que retornam 500s e depois as tenta novamente, você está desperdiçando orçamento E danificando sua pontuação de rastreabilidade no Google ao longo do tempo. -- If Googlebot is hitting pages that return 500s and then retrying them, you're wasting budget AND damaging your crawlability score with Google over time.
- 304 Not Modified -- Na verdade é aceitável. Significa que Google está verificando a atualização e seus cabeçalhos de cache estão funcionando corretamente. -- Actually fine. Means Google is checking freshness and your caching headers are working correctly.
Picos de Tempo de Resposta
Google já declarou publicamente que tempos de resposta do servidor lentos fazem Googlebot rastrear com menos agressividade. 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 cache no servidor antes de qualquer outra coisa. that slow server response times cause Googlebot to crawl less aggressively. If your logs show average response times above 500ms for crawled URLs -- particularly category or product pages -- that's a signal to fix your server-side caching before anything else.
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:
- Navegação facetada sem noindex ou disallow -- Filtros, seletores de cor, seletores de tamanho, ordens de classificação. Essas multiplicam sua contagem de URLs geometricamente. Uma categoria de produto com 10 opções de filtro e 5 ordens de classificação gera 50+ variantes de URL duplicadas. Em um site com 50K páginas, isso potencialmente gera centenas de milhares de URLs. -- Filters, colour pickers, size selectors, sort orders. These multiply your URL count geometrically. A product category with 10 filter options and 5 sort orders generates 50+ duplicate URL variants. Across a 50K-page site, that's potentially hundreds of thousands of URLs.
- Arquivos paginados rastreados infinitamente -- /page/2, /page/3.../page/847. Se o conteúdo da página 200 do seu arquivo de blog tem zero valor de busca orgânica, você precisa noindex-á-la ou desabilitar o caminho de paginação no robots.txt. --
/page/2,/page/3.../page/847. If the content on page 200 of your blog archive has zero organic search value, you need to either noindex it or disallow the pagination path in robots.txt. - IDs de sessão em URLs -- Plataformas CMS antigas (e algumas configurações legadas de WooCommerce) adicionam tokens de sessão como ?sessionid=abc123def456 às URLs. Cada sessão gera uma URL única. Googlebot rastreia todas elas. Essa é uma hemorragia de orçamento catastrófica em sites antigos. -- Old CMS platforms (and some legacy WooCommerce setups) append session tokens like
?sessionid=abc123def456to URLs. Every session generates a unique URL. Googlebot crawls all of them. This is a catastrophic budget leak on older sites. - Conteúdo duplicado via parâmetros de URL -- ?utm_source=email em links internos, parâmetros de rastreamento vazando em URLs rastreáveis, ?ref=homepage adicionado por plugins de afiliados. Corrija na ferramenta de parâmetro de URL do Google Search Console e canonicalize no nível HTML. --
?utm_source=emailin internal links, tracking parameters leaking into crawlable URLs,?ref=homepageappended by affiliate plugins. Fix in Google Search Console's URL parameter tool and canonicalise at the HTML level. - Páginas órfãs sem links internos mas ainda no sitemap -- Googlebot as encontra via sitemap, as rastreia, não encontra sinal interno, as deprioritiza ao longo do tempo. Mas ainda consomem orçamento em rastreamentos de descoberta. -- Googlebot finds them via sitemap, crawls them, finds no internal signal, deprioritises them over time. But they still eat budget on discovery crawls.
- Páginas soft 404 retornando status 200 -- Páginas de busca sem resultados, categorias vazias, perfis de usuários de contas deletadas. Google perde tempo rastreando essas páginas e às vezes as indexa. -- Search pages with no results, empty category pages, user profile pages for deleted accounts. Google wastes time crawling these and sometimes indexes them.
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:
- Disallow no robots.txt para padrões de URL que nunca devem ser rastreados -- parâmetros de sessão, combinações de filtros, URLs de resultado de busca interna. Uso regras com wildcard como Disallow: /*?sessionid=style. Teste cada regra no testador de robots.txt do Google Search Console antes de fazer deploy. for URL patterns that should never be crawled -- session parameters, filter combinations, internal search result URLs. I use
Disallow: /*?sessionid=style wildcard rules. Test every rule in Google Search Console's robots.txt tester before deploying. - 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. on paginated pages beyond page 2 or 3, depending on content freshness. Don't disallow pagination entirely or you break Googlebot's ability to discover linked content.
- Tags canonical em todas as variantes de URL parametrizadas apontando para a URL canonical limpa. Isso é segurança dupla além do robots.txt. on all parameterised URL variants pointing to the clean canonical URL. This is belt-and-braces alongside robots.txt.
- Corrija 404s na origem -- Atualize os links internos ou implemente redirecionamentos 301. Uso o crawler principal do Screaming Frog junto com os dados de log para encontrar quais páginas estão apontando para URLs mortas. -- Either update the internal links or implement 301 redirects. I use Screaming Frog's main crawler alongside the log data to find which pages are linking to dead URLs.
- Higiene do sitemap XML -- 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. -- Remove any URL from your sitemap that returns a non-200, is noindexed, or is a redirect. Your sitemap should be a curated list of pages you want indexed, nothing else.
Seahawk tinha um cliente fintech ano passado -- cerca de 65 mil 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 de URLs inúteis pelo Googlebot em 61% em seis semanas. Os 39% restantes do orçamento de rastreamento foram direcionados para páginas de produtos e categorias. A indexação de novo conteúdo caiu de uma média de 23 dias para 6 dias. Esse é o impacto no 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 mil páginas. Observe a tendência de frequência de rastreamento para suas 100 URLs com maior 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 desempenho do servidor ou 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?
Mais ou menos. 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 a velocidade com que esse conteúdo fresco é descoberto. Um site com orçamento de rastreamento com vazamento pode ter páginas novas não inspecionadas por semanas. Essa é uma desvantagem competitiva real se você está em um nicho de rápido movimento.
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. O que eu aconselha cautela é bloquear arquivos JavaScript ou CSS -- Googlebot precisa deles para renderizar suas páginas adequadamente. Muito conselho antigo de SEO diz para bloquear JS; ignore.
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 visível de forma proeminente no dashboard. Se você realmente não conseguir acessar logs brutos, a análise de bots do Cloudflare pode dar uma visão parcial para sites por trás do proxy Cloudflare, embora seja um pobre substituto dos dados de log reais. Considere trocar de host se isso for um bloqueador recorrente em uma conta de cliente grande.Cloudflare's bot analytics can give you a partial picture for sites behind the Cloudflare proxy, though it's a pale substitute for real log data. Consider switching hosts if this is a recurring blocker on a large client account.
As estatísticas de rastreamento do Google Search Console são suficientes?
Para um site pequeno, discutivelmente sim. Para qualquer coisa acima de 20 mil páginas, não. As estatísticas de rastreamento do GSC são agregadas por dia e não fornecem dados em nível de URL. Você pode ver que o Googlebot rastreou 12 mil páginas em uma terça, mas não quais eram essas 12 mil páginas. Arquivos de log fornecem essa resolução. Ambas as ferramentas juntas -- essa é a visão completa.which 12,000 pages. Log files give you that resolution. Both tools together -- that's the complete picture.
---
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.