Por volta da página 47.000 de um relatório de rastreamento, genuinamente considerei uma mudança de carreira. O site, um grande catálogo de e-commerce baseado no Reino Unido com cerca de 91.000 URLs indexáveis, estava com aproximadamente 34.000 páginas indexadas há seis meses. Sem crescimento. O cliente estava convencido de que algo estava "quebrado". Eu disse a ele que nada estava quebrado. Eu estava pela metade certo.
Ponto-chave: Em um site com 91.000 páginas, Googlebot rastreia o que sua arquitetura determina: links internos, disciplina de sitemap e eliminação de desperdício definem quais páginas ficam indexadas.
Aquele projeto mudou completamente como penso sobre orçamento de rastreamento. Não a teoria, eu tinha lido a documentação do Google, tinha assistido aos vídeos do Search Central, sabia o que era orçamento de rastreamento. Mas conhecer e realmente gerenciar em escala são duas coisas completamente diferentes. O que segue é tudo o que eu diria a mim mesmo se pudesse voltar àquela terça-feira de março de 2022 quando puxei os estatísticas de rastreamento no Google Search Console e senti meu estômago cair.
O Que Orçamento de Rastreamento Realmente Significa (E O Que Não Significa)
Eis o que confunde as pessoas constantemente: crawl budget não significa "o número de páginas que o Google vai indexar para você". Significa aproximadamente o número de URLs que o Googlebot vai buscar dentro de uma janela de crawl específica, que o próprio Google define como uma combinação de crawl rate limit e crawl demand.
Limite de taxa de rastreamento é a velocidade com que o Googlebot pode rastrear sem sobrecarregar seu servidor. Demanda de rastreamento é quanto o Google quer rastrear, impulsionado por quão popular suas URLs são e com que frequência mudam. Multiplique essas duas alavancas juntas e você tem uma ideia aproximada de quanto atenção de rastreamento seu site recebe.
Para a maioria dos sites com menos de 1.000 páginas, isso é irrelevante. O Google vai rastrear tudo. Mas uma vez que você está nos dezenas de milhares, e absolutamente uma vez que você ultrapassa seis dígitos, o Googlebot começa a fazer escolhas. Vai priorizar. Vai ignorar. E se você não o configurou para priorizar a coisa certa, vai alegremente gastar seu tempo rastreando suas URLs com parâmetro de ID de sessão e suas páginas de faceta filtrada enquanto seus novos lançamentos de produtos passam despercebidos por semanas.
Isso não é hipotético. É o que aconteceu no projeto de 91.000 páginas.
O Problema de Navegação com Facetas Que Ninguém Me Avisou
A navegação com facetas é o maior assassino de orçamento de rastreamento que já encontrei em sites grandes. Consistentemente. Toda vez.
O site de catálogo tinha um sistema de filtro facetado, cor, tamanho, material, marca, sem nenhum tratamento de parâmetro de URL configurado em lugar algum. Cada combinação de filtro gerava uma URL única. Você podia selecionar "azul", "médio", "algodão" e "MarcaX" e obter /shop?colour=blue&size=medium&material=cotton&brand=brandx. Depois alguém inverteu a ordem e obteve /shop?size=medium&colour=blue&brand=brandx&material=cotton. URL diferente, conteúdo idêntico.
Executei um rastreamento no Screaming Frog (versão 18, que lida muito melhor com renderização de JavaScript do que versões antigas) e encontrei mais de 200.000 URLs sendo geradas apenas pelo sistema de filtros. O Googlebot estava visitando essas. Constantemente. Enquanto milhares de páginas de produtos legítimas permaneciam não indexadas.
O Conserto Que Realmente Funcionou
Abordamos isso em dois estágios. Primeiro, configurei o tratamento de parâmetro de URL no Google Search Console, sinalizando os parâmetros de filtro como "Não altera o conteúdo da página" para sinalizar ao Googlebot consolidar. Segundo, e mais importante, a equipe de desenvolvimento implementou uma estratégia de canonical adequada, apontando todas as combinações de filtro de volta para a página de categoria base. Também adicionamos noindex a páginas filtradas de baixo valor que não podiam ser canonicalizadas na prática.
Dentro de cerca de oito semanas, a contagem de páginas indexadas começou a subir. Não explosivamente, steadily. Que é na verdade o que você quer. Um pico repentino de páginas indexadas às vezes pode desencadear uma reavaliação do Google em vez de uma vitória limpa.
Estatísticas de Rastreamento no Search Console: Os Dados Que a Maioria Das Pessoas Ignora
Auditei perto de 80 sites nos últimos três anos especificamente para problemas de crawl. Talvez 15% das pessoas que entregaram esses sites para mim tinham olhado o relatório de Crawl Stats no Search Console. Esse número deveria ser muito maior.
O relatório de Estatísticas de Rastreamento mostra a você solicitações de rastreamento médias por dia, tempo de resposta médio e, crucialmente, o que o Googlebot realmente está rastreando, dividido por finalidade (descoberta vs. atualização). Se seus rastreamentos de "atualização" estão dominando e rastreamentos de descoberta são mínimos, o Google está gastando seu tempo verificando novamente páginas que já conhece. Não encontrando novas. Esse é um sinal de que seu link interno provavelmente é superficial ou seu mapa do site XML não está fazendo nada útil.
No projeto de 91.000 páginas, estávamos com cerca de 2.400 solicitações de rastreamento por dia. Para um site desse tamanho, isso significa que o Google teoricamente demoraria cerca de 38 dias para rastrear tudo uma vez, assumindo que cada solicitação atingisse uma página única e útil. Não era. Aproximadamente 40% das solicitações de rastreamento estavam atingindo cadeias de redirecionamento ou duplicatas inflacionadas por parâmetros.
Tempo Médio de Resposta Importa Mais do Que Você Pensa
Uma coisa que subestimei no início da minha carreira: Googlebot é genuinamente sensível à velocidade do servidor. Não de uma forma de classificação (bem, não diretamente), mas de uma forma de vontade de rastrear. Servidores lentos fazem o Googlebot recuar. Google vai reduzir sua taxa de rastreamento para evitar estressar um servidor em dificuldades.
O site de catálogo tinha um Time to First Byte em torno de 1.8 segundos em páginas de categoria durante pico de tráfego. Depois que o cliente migrou de hospedagem compartilhada para um VPS dedicado com cache apropriado (WP Rocket para cache de página, Redis para cache de objeto), TTFB caiu para menos de 400ms. Solicitações de rastreamento por dia subiram notavelmente nos seis semanas seguintes. Correlação, obviamente, mas tenho visto esse padrão muitas vezes demais para ignorar.
Sitemaps XML: Pare de Tratá-los Como uma Formalidade
A maioria dos mapas do site que herdo estão errados. Não dramaticamente errados, apenas silenciosamente, inútilmente errados.
Problemas comuns que vejo:
- Páginas no sitemap que retornam 404s ou redirecionamentos 301
- Páginas noindexadas incluídas no sitemap (isso confunde o Googlebot, você está simultaneamente dizendo "rastreie isto" e "não indexe isto")
- <lastmod>datas que são estáticas ou simplesmente incorretas
- Sitemaps com 70.000+ URLs em um único arquivo (o limite é 50.000 por arquivo, e arquivos grandes desaceleram o processamento)
- Nenhum arquivo de índice de sitemap, apenas um blob XML monolítico
No projeto de grande catálogo, o sitemap tinha 91.000 URLs em um único arquivo. Também estava incluindo cada URL filtrada que tinha sido gerada, mais de 40.000 das quais eram noindexadas. O Googlebot estava processando esse arquivo gigantesco e depois descobrindo que a maioria das URLs não deveria ser rastreada mesmo assim. Sinal desperdiçado nos dois lados.
Reconstruímos a arquitetura do sitemap como um índice de sitemap apropriado apontando para sitemaps filhos segmentados: um para páginas de categoria principal, um para páginas de produtos (dividido em dois arquivos devido ao volume), um para conteúdo editorial. Cada arquivo com menos de 40.000 URLs. <lastmod>valores gerados dinamicamente a partir da data de última modificação real no banco de dados. Sem páginas com noindex, sem redirecionamentos.
Os dados do Bing Webmaster Tools (sim, vale a pena verificar, o Bing às vezes mostra padrões de comportamento de rastreamento que indicam problemas estruturais que o Google também está enfrentando) mostraram queda no tempo de processamento do sitemap de mais de 60%.
Linkagem Interna: A Alavanca Que Você Realmente Controla
Aqui está algo que genuinamente não apreciei até a Seahawk Media pegar um grande site de conteúdo, aproximadamente 65.000 artigos, para um cliente de mídia em 2020. O site tinha problemas de orçamento de rastreamento apesar de ter um sitemap bem formado e estrutura de URL limpa. O problema era a profundidade de links internos. Milhares de artigos eram efetivamente órfãos, sem links internos apontando para eles de nenhuma página rastreada.
O Googlebot não segue apenas sitemaps. Ele segue links. Se uma página só é descoberta através de uma entrada de sitemap e tem zero links internos, ela é deprioritizada. Isso não está oficialmente documentado em termos nítidos, mas a própria orientação do Google sobre internal linking deixa claro que links crawláveis de páginas importantes é como o Googlebot prioriza descoberta.
Para aquele cliente de mídia, auditamos links internos usando a ferramenta Site Audit do Ahrefs e identificamos cerca de 12.000 artigos com três ou menos links internos apontando para eles. Construímos um bloco automatizado de "artigos relacionados" no CMS (WordPress, bloco Gutenberg customizado) que puxava conteúdo contextualmente similar. Ao longo do trimestre seguinte, as páginas indexadas naquele site cresceram de 41.000 para mais de 58.000. Mesma autoridade de domínio. Mesma taxa de produção de conteúdo. Apenas links internos melhores.
A abordagem numerada que agora uso em toda auditoria de site grande:
- Execute um rastreamento completo com Screaming Frog e exporte dados de links internos
- Identifique cada página com menos de três links internos de entrada
- Referência cruzada contra páginas que têm bons links, encontre clusters temáticos
- Construa links internos contextuais de páginas de alto tráfego para baixo nas páginas pouco linkadas
- Valide na ferramenta Inspeção de URL do Search Console que páginas recém-vinculadas mudem de "Descoberta, atualmente não indexada" para "Rastreada"
Esse status "Descoberta, atualmente não indexada" no Search Console é seu canário. Significa que o Google sabe que a página existe, mas não priorizou sua busca. Melhorar links internos geralmente é a maneira mais rápida de resolver isso.
Análise de Arquivo de Log: Desconfortável Mas Necessária
Vou ser honesto, análise de arquivo de log é algo que evitei por anos. Parecia uma profundidade desnecessária quando ferramentas de rastreamento ofereciam a maior parte do que você precisava. Eu estava errado.
Arquivos de log contam o que o Googlebot realmente fez, não o que você infere que fez a partir do seu sitemap ou ferramenta de rastreamento. Em um projeto, uma empresa de SaaS com cerca de 8.000 páginas de documentação de produto, a análise de log revelou que o Googlebot estava gastando quase 30% do seu tempo de rastreamento em URLs adjacentes a /wp-admin/ e assets do lado do admin que deveriam ter sido bloqueados em robots.txt. Ninguém tinha configurado isso corretamente. Páginas de documentação que não tinham sido rastreadas em quatro meses.
O Log File Analyser do Screaming Frog é a ferramenta que uso. Não é glamouroso, mas é confiável. Importe seus logs de servidor, filtre pelo user agent do Googlebot, e ordene por frequência de acerto de URL. Os padrões que emergem são quase sempre esclarecedores, e quase sempre incluem algo sendo rastreado que não deveria ser.
Quando se Preocupar e Quando Deixar em Paz
Nem todo site grande precisa de gerenciamento agressivo de crawl budget. Se você tem 10.000 páginas e 9.800 estão indexadas, não comece a mexer nos controles. Você criará problemas onde nenhum existe.
O gerenciamento de crawl budget realmente vale a pena quando:
- Você tem mais de ~15.000 páginas indexáveis
- Sua contagem de indexadas atingiu um platô apesar de novo conteúdo sendo adicionado
- Crawl Stats mostra requisições de rastreamento médias bem abaixo do que você esperaria para seu volume de páginas
- Você vê milhares de URLs em status "Descoberto, atualmente não indexado" ou "Rastreado, atualmente não indexado"
Esse segundo status, "Rastreado, atualmente não indexado", é diferente e vale a pena separar. Significa que o Google buscou a página e decidiu não indexá-la, geralmente por causa de conteúdo fino ou problemas de quase-duplicação. Nenhuma quantidade de otimização de orçamento de rastreamento resolve um problema de qualidade.
---
FAQ
Orçamento de crawl afeta sites pequenos?
Raramente de forma significativa. Se seu site tem menos de 1.000 páginas e carrega rapidamente, o Google quase certamente rastreará tudo independentemente. Orçamento de rastreamento se torna uma preocupação genuína em escala, tipicamente acima de 10.000 a 15.000 páginas, ou em sites onde uma grande porção de URLs é gerada dinamicamente.
Enviar um sitemap diretamente vai resolver problemas de orçamento de crawl?
Não. Um sitemap ajuda na descoberta, diz ao Google que essas URLs existem. Mas se seu site tem problemas estruturais (spam de navegação facetada, resposta lenta do servidor, linking interno raso), um sitemap não vai sobrescrever esses sinais. Pense em um sitemap como uma sugestão, não um comando.
Como eu verifico se o Googlebot está desperdiçando crawl em URLs inúteis?
Comece com o relatório Crawl Stats no Google Search Console e veja quais tipos de URL estão recebendo mais solicitações. Depois faça referência cruzada com um crawl do Screaming Frog para identificar padrões de URL de alto volume que são duplicatas, noindexadas, ou de baixo valor. Análise de arquivo de log vai dar a você o panorama mais preciso se você tiver acesso aos logs do servidor.
Devo usar `noindex` ou `robots.txt disallow` para economizar orçamento de crawl?
Ferramentas diferentes para trabalhos diferentes. Disallow no robots.txt impede que o Googlebot busque a página, economizando orçamento de rastreamento mas significando que o Google não consegue ler nenhum sinal dessa página. Noindex permite que o Google busque a página mas diz a ele para não incluir a página nos resultados de busca. Para orçamento de rastreamento especificamente, disallow é mais efetivo em URLs verdadeiramente inúteis (caminhos de admin, resultados de busca interna). Para páginas de faceta filtrada onde você quer que o Google entenda o conteúdo mas não a indexe, noindex com canonical geralmente é a escolha certa.
Qual é um prazo realista para ver melhorias depois de corrigir problemas de crawl budget?
Honestamente, depende da sua taxa de rastreamento. No projeto de 91.000 páginas, movimento significativo nas contagens de páginas indexadas levou cerca de seis a oito semanas depois que os principais ajustes foram implementados. Não espere mudanças da noite para o dia, o Googlebot precisa re-rastrear, re-avaliar, e o pipeline de indexação tem sua própria latência além disso.
---
O projeto de 91.000 páginas terminou bem. Páginas indexadas subiram de 34.000 para pouco mais de 71.000 em cinco meses. Não perfeito, havia genuinamente páginas de produto finas que mereciam não ser indexadas, mas o conteúdo que importava foi encontrado. O cliente parou de perguntar se algo estava quebrado. E eu parei de considerar mudanças de carreira por volta da página 47.000 de relatórios de rastreamento. Na maioria das vezes.
Leitura relacionada: Pesquisa de palavras-chave com IA em 2026: o que é, por que é tradicional, Redirecionamentos 301 vs 302: qual realmente importa para SEO, e palavras-chave LSI em 2026: o que são, o que não são, o que.