Crawl budget: quando se preocupar e como medir

Crawl budget e o tipo de assunto que so aparece na conversa quando ja virou problema. O Google publicou em 2017 que sites com menos de alguns milhares de URLs nao precisam se preocupar, e essa frase virou desculpa para ignorar o tema ate em e-commerces com 800 mil PDPs. O ponto de virada raramente e o numero de URLs no sitemap, e sim a razao entre paginas uteis e paginas que o Googlebot encontra. Quando essa razao cai abaixo de 30%, voce ja esta sangrando rastreamento, mesmo que o trafego organico ainda nao mostre.

O primeiro sinal pratico aparece no Search Console, em Configuracoes > Estatisticas de rastreamento. Se o numero de solicitacoes diarias cai 40% em duas semanas sem mudanca de servidor, ou se o tempo medio de resposta sai de 300ms para 1.2s, voce tem um problema de orcamento. Outro sintoma classico: paginas novas demorando mais de 10 dias para serem indexadas em um site que costumava receber Googlebot no mesmo dia. Antes de mexer em qualquer coisa, vale fazer uma Como auditar SEO on-page sem cair em achismos honesta para descartar que o problema esta no proprio conteudo.

O diagnostico real mora nos logs do servidor. Filtrar por user-agent do Googlebot em 30 dias de log do Nginx ou Cloudflare revela coisas que GSC nunca vai mostrar: quantas vezes o bot bateu em URLs com parametro ?sort=, quantas vezes voltou em 404, quantos hits em paginacoes infinitas geradas por filtros facetados. Em um cliente nosso, 62% do crawl ia para URLs com tres ou mais parametros, todas canonicas para a versao limpa. A solucao nao foi noindex, foi corrigir links internos e revisar Canonical tags: erros comuns que sangram trafego organico para parar a hemorragia na origem.

Tres armadilhas tecnicas concentram a maioria dos casos. A primeira e robots.txt mal configurado bloqueando recursos que o renderizador precisa, e ai entra a leitura obrigatoria sobre robots.txt: armadilhas que bloqueiam indexacao silenciosamente. A segunda e sitemap inflado com URLs 404, redirecionadas ou com noindex, problema coberto em Sitemap XML moderno: prioridade, lastmod e o que ignorar. A terceira, mais sutil, e JavaScript que so renderiza conteudo apos interacao, fazendo o Googlebot ver paginas vazias e gastar quota tentando entender. O guia de JavaScript SEO: renderizacao, hydration e indexacao cobre os padroes que funcionam em 2026 com Next.js e Astro.

Para medir com precisao, monte uma query no BigQuery cruzando o export do GSC com os logs do CDN. Conte URLs distintas rastreadas por dia, agrupe por padrao de path (/p/, /c/, /blog/, /tag/), e calcule a razao entre rastreadas e indexadas. Se /tag/ representa 35% do crawl mas 2% das impressoes, voce tem um vazamento claro. Esse tipo de analise esta detalhado em BigQuery + GSC: queries que sua agencia nao roda e em Log file analysis: o que o Googlebot esta realmente fazendo, que mostra como separar Googlebot real de bots que falsificam user-agent (cerca de 18% do trafego que se identifica como Googlebot, segundo dados da Cloudflare em 2024).

Existe um momento em que o problema deixa de ser tecnico e vira de arquitetura. Sites com mais de 100 mil URLs ativos precisam de logica de priorizacao no proprio HTML: lastmod confiavel, interlinking que reflete a importancia comercial das paginas, e remocao agressiva de variacoes que nao geram demanda. Se sua categoria principal recebe menos hits do Googlebot que uma pagina de tag obsoleta, o problema nao e o orcamento, e o desenho. Como takeaway pratico: rode log analysis de 30 dias antes do proximo trimestre, classifique URLs em tres baldes (ativos, dormentes, lixo) e ataque o terceiro balde primeiro. Crawl budget se recupera em 6 a 8 semanas quando voce para de alimentar o que nao deveria existir.