Orçamento de rastreamento: você tem esse problema?

Orçamento de rastreamento (crawl budget) é a quantidade de páginas do seu site que um mecanismo de busca está disposto a buscar dentro de um período antes de direcionar a atenção para outro lugar. Ele nasce do cruzamento de dois limites distintos: o limite de taxa de rastreamento — quão forte o rastreador pode bater no seu servidor sem degradar a experiência de quem visita o site de verdade — e a demanda de rastreamento — o quanto o mecanismo de busca realmente quer suas páginas, com base em popularidade, frequência de atualização e qualidade percebida do conteúdo.

A resposta direta, antes de qualquer outra coisa: a maioria de quem está lendo isso não tem um problema de orçamento de rastreamento. É um conceito real e relevante em escala — catálogos enormes, navegação por facetas pesada, sites com centenas de milhares de URLs — mas para um blog, um site institucional ou uma loja com algumas centenas de páginas, quase sempre é a preocupação errada. Vale entender o mecanismo antes de gastar tempo tentando otimizá-lo.

O que compõe o orçamento, na prática

O limite de taxa de rastreamento é uma decisão de proteção. O rastreador monitora quanto tempo o servidor leva para responder e a taxa de erros que encontra; se as respostas começam a demorar mais ou a falhar, ele reduz a velocidade das requisições para não piorar a situação. Se o servidor responde rápido e de forma consistente, o limite sobe. Isso significa que a capacidade e a saúde da sua infraestrutura definem, sozinhas, metade da equação — nenhuma configuração de SEO muda esse lado.

A demanda de rastreamento é uma decisão de prioridade. Mesmo com capacidade sobrando, o rastreador não visita tudo com a mesma frequência: páginas populares, bem linkadas e que mudam com regularidade são revisitadas com mais frequência do que uma página estática enterrada a cinco cliques da home. URLs que o rastreador já conhece e considera de baixo valor recebem menos atenção com o tempo, mesmo que continuem tecnicamente acessíveis.

• Limite de taxa: resposta lenta ou erros de servidor reduzem a velocidade de rastreamento
• Limite de taxa: um servidor rápido e estável permite mais requisições por dia
• Demanda: popularidade e links internos/externos aumentam a frequência de revisita
• Demanda: conteúdo que muda pouco ou é percebido como de baixo valor perde prioridade

Quem realmente precisa se importar

Orçamento de rastreamento vira um problema real quando o número de URLs cresce mais rápido do que a capacidade do rastreador de acompanhar — normalmente em catálogos de e-commerce com muitas combinações de filtro, marketplaces com milhares de anúncios, ou publishers com arquivos enormes acumulados ao longo de anos. Nesses casos, o site não tem só muitas páginas: tem ordens de grandeza mais URLs geradas do que páginas que valem a pena indexar.

Três sinais indicam que você tem o problema de verdade, e não apenas a sensação de tê-lo. O primeiro é ver, em dados de log, o rastreador gastando a maior parte do tempo em URLs de parâmetro, sessão ou filtro em vez de páginas de conteúdo. O segundo é uma contagem de páginas indexadas muito acima da contagem real de páginas que você publicou — sinal de que variações e duplicatas estão entrando no índice. O terceiro é atraso: páginas novas ou atualizadas levando semanas para serem rastreadas e aparecerem nos resultados, mesmo estando linkadas corretamente.

Um exemplo concreto ajuda a calibrar a escala do problema. Uma loja com dois mil produtos, cada um com três opções de cor e cinco de tamanho combinadas em uma URL de filtro, mais três formas de ordenação, pode gerar bem mais de cem mil combinações de URL distintas — cinquenta vezes o número de páginas de produto reais. É esse tipo de proporção, não o número absoluto de produtos, que define se o catálogo tem um problema de orçamento de rastreamento ou apenas um catálogo grande e saudável.

• Catálogo grande com muitas combinações de filtro ou variação de produto
• Centenas de milhares de URLs, não centenas ou milhares
• Log mostra tempo do rastreador concentrado em URLs de parâmetro
• Índice muito maior que o número real de páginas publicadas
• Páginas novas demoram semanas para serem rastreadas pela primeira vez

Onde o orçamento vaza

URLs de faceta e filtro são a fonte mais comum de desperdício em catálogos grandes: cada combinação de cor, tamanho, faixa de preço e ordenação gera uma URL tecnicamente única, e a multiplicação dessas combinações pode superar em muito o número de produtos reais. Parâmetros de sessão e rastreamento — session ID, UTM, referral, IDs de clique — fazem a mesma coisa: cada valor diferente do parâmetro é, para o rastreador, uma URL nova até que ele aprenda que o conteúdo é idêntico.

Armadilhas de rastreamento (crawl traps) são um caso mais extremo: calendários que geram uma URL para cada mês futuro indefinidamente, buscas internas que aceitam qualquer string na URL, ou paginação que nunca termina. Cada uma dessas estruturas pode, sozinha, gerar mais URLs do que o resto do site inteiro.

Duas outras fontes recebem menos atenção mas custam caro: soft 404s — páginas que retornam status 200 mas mostram conteúdo vazio ou uma mensagem de "não encontrado" — continuam sendo revisitadas porque o servidor nunca sinaliza que estão mortas, e cadeias longas de redirecionamento, em que cada salto consome uma requisição extra antes de chegar ao destino final. E o servidor lento, mencionado antes, fecha o ciclo: um site que demora para responder é rastreado com menos frequência, o que significa menos URLs cobertas por dia, independentemente de quantas existam.

• Combinações de filtro e faceta em catálogos
• Parâmetros de sessão, UTM e rastreamento de clique
• Calendários infinitos e buscas internas sem limite
• Soft 404s (status 200 com conteúdo vazio ou de erro)
• Cadeias longas de redirecionamento
• Tempo de resposta do servidor acima do ideal

O que fazer, na ordem certa

O primeiro passo não é uma regra de bloqueio — é parar de gerar as URLs problemáticas na origem. Se a navegação interna do site já linka para a versão limpa e canônica de cada página, em vez de para cada combinação de filtro, uma parte grande do vazamento nunca chega a existir. Isso costuma exigir uma conversa com quem desenvolve o front-end, não apenas um ajuste de configuração de SEO.

O segundo passo é o robots.txt, usado para padrões inteiros e conhecidos — bloquear todo um diretório de calendário, todo um parâmetro de sessão, toda uma rota de busca interna. Uma regra em robots.txt impede que a requisição sequer aconteça, o que é exatamente o efeito que se busca: menos URLs consumindo o limite de rastreamento.

O terceiro passo, canônicas, entra onde a URL ainda precisa ser acessível — por exemplo, uma variação de filtro que alguém pode acessar diretamente por um link externo — mas você quer consolidar os sinais de relevância na versão principal. É importante entender a diferença: uma tag canônica ajuda a consolidar autoridade e evitar duplicação no índice, mas não impede o rastreamento da página, porque o rastreador só descobre a tag depois de baixar a página inteira.

É esse mesmo motivo que explica por que noindex não economiza orçamento de rastreamento. A diretiva noindex fica dentro da página — em uma meta tag ou em um cabeçalho X-Robots-Tag — e só é lida depois que o rastreador já fez o download completo do conteúdo. O rastreador gastou a requisição de qualquer forma; a única coisa que noindex evita é a entrada da página no índice, não a visita a ela. Para economizar rastreamento de verdade, a URL precisa nunca ser buscada — isso é trabalho do robots.txt ou, melhor ainda, de nunca gerar a URL em primeiro lugar.

• 1. Corrigir a geração de URLs na origem (navegação interna, front-end)
• 2. Robots.txt para padrões inteiros e conhecidos de URL problemática
• 3. Canônicas para consolidar variações que precisam continuar acessíveis
• Noindex não economiza rastreamento: a página ainda é baixada para a diretiva ser lida

Sitemaps e links internos como sinal de demanda

Um sitemap XML bem mantido não controla a velocidade de rastreamento, mas funciona como um sinal claro de demanda: é a lista do que você considera importante o suficiente para ser indexado. Um sitemap que mistura páginas canônicas com variações de filtro, parâmetros ou conteúdo duplicado dilui esse sinal — na prática, está dizendo ao rastreador para tratar lixo com a mesma prioridade de conteúdo real.

A profundidade da arquitetura de links internos tem um efeito parecido. Páginas linkadas a partir da home ou de páginas de categoria com boa autoridade tendem a ser rastreadas com mais frequência do que páginas órfãs ou enterradas a muitos cliques de distância. Se uma seção inteira do site depende de rastreamento e indexação e está estruturalmente isolada do resto da arquitetura de links, isso pesa contra ela antes mesmo de qualquer questão de conteúdo.

Como medir isso com dados de verdade

Duas fontes respondem à pergunta com dados reais, em vez de sensação. A primeira são os logs de servidor, filtrados para requisições verificadamente feitas pelo rastreador (não qualquer coisa que se identifique como tal no user-agent, o que qualquer script pode forjar), agrupadas por padrão de URL. Isso mostra exatamente onde o tempo de rastreamento está indo — se a maior fatia está em páginas de produto ou em parâmetros de sessão, por exemplo.

A segunda é o relatório de estatísticas de rastreamento do Search Console, que mostra o volume total de requisições ao longo do tempo, a distribuição por tipo de resposta, por tipo de arquivo e por finalidade da requisição, além da tendência de tempo de resposta do servidor. Um tempo de resposta subindo, junto com um volume de rastreamento caindo, é o padrão clássico de um servidor sobrecarregado limitando a própria cobertura. Cruzar esse relatório com a contagem de páginas indexadas mostra rapidamente se o problema é de fôlego do servidor, de excesso de URLs geradas ou dos dois ao mesmo tempo.

Sem esses dados, qualquer decisão sobre orçamento de rastreamento é um palpite. Vale a pena olhar para os números antes de reescrever regras de robots.txt ou reestruturar uma seção inteira do site — o problema pode estar em um lugar completamente diferente do que a intuição sugere.

Erros comuns ao lidar com o tema

O erro mais frequente é tratar orçamento de rastreamento como uma otimização universal, aplicando regras de bloqueio agressivas em um site de duzentas páginas que o rastreador cobre por completo todos os dias sem esforço. Nesse caso, o tempo é melhor investido em conteúdo e em corrigir problemas de indexação reais, não em engenharia de rastreamento.

O segundo erro é bloquear parâmetros ou padrões de URL sem antes confirmar, por amostragem, que nenhum deles carrega conteúdo único que deveria ser indexável. Uma regra de robots.txt malfeita pode esconder páginas válidas tão facilmente quanto elimina lixo — e como o robots.txt impede o próprio rastreamento, um engano ali é mais difícil de perceber do que um engano em uma tag canônica.