Em algum lugar 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 estagnado em aproximadamente 34.000 páginas indexadas havia 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 correto.
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.On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
Esse projeto mudou completamente como penso sobre crawl budget. Não a teoria — eu tinha lido a documentação do Google, assistido aos vídeos do Search Central, sabia o que era crawl budget. Mas saber e realmente gerenciar em escala são duas coisas completamente diferentes. O que se segue é tudo o que eu diria a mim mesmo se pudesse voltar àquela terça-feira de manhã em março de 2022, quando puxei as estatísticas de rastreamento no Google Search Console e senti meu estômago descer.was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
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.fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
Crawl rate limit é a velocidade com que Googlebot pode rastrear sem sobrecarregar seu servidor. Crawl demand é quanto Google quer rastrear — determinado por quão popular suas URLs são e com que frequência mudam. Multiplique esses dois fatores e você tem uma ideia aproximada de quanto tempo de rastreamento seu site recebe.wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
Para a maioria dos sites com menos de 1.000 páginas, isso é irrelevante. Google rastreia tudo. Mas quando você chega a dezenas de milhares — e absolutamente quando ultrapassa seis dígitos — Googlebot começa a fazer escolhas. Vai priorizar. Vai ignorar. E se você não o configurou para priorizar o que importa, ele alegremente gastará seu tempo rastreando suas URLs com parâmetro de ID de sessão e suas páginas de facetas filtradas enquanto seus novos 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 do catálogo tinha um sistema de filtro facetado — cor, tamanho, material, marca — sem tratamento de parâmetros de URL configurado em lugar nenhum. Cada combinação de filtro gerava uma URL única. Você poderia 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./shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
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âmetros de URL no Google Search Console — marcando os parâmetros de filtro como "Não altera o conteúdo da página" para sinalizar a Googlebot consolidar. Segundo, e mais importante, o time de desenvolvimento implementou uma estratégia apropriada de canonical, apontando todas as combinações de filtros de volta para a página de categoria base. Também adicionamos noindex às páginas filtradas de baixo valor que não podiam ser canonicalizadas de forma prática.noindex to low-value filtered pages that couldn't practically be canonicalised.
Dentro de cerca de oito semanas, a contagem de páginas indexadas começou a subir. Não explosivamente — gradualmente. O que é na verdade o que você quer. Um pico súbito em 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.Crawl Stats report in Search Console. That number should be much higher.
O relatório Crawl Stats mostra a você requisições de rastreamento média por dia, tempo de resposta médio e — crucialmente — o que Googlebot está realmente rastreando dividido por propósito (descoberta vs. atualização). Se seus rastreamentos de "atualização" dominam e os rastreamentos de descoberta são mínimos, Google está gastando seu tempo verificando páginas que já conhece. Não encontrando novas. Esse é um sinal de que seus links internos provavelmente são superficiais ou seu XML sitemap não está fazendo nada útil.
No projeto de 91.000 páginas, estávamos em cerca de 2.400 requisições de rastreamento por dia. Para um site desse tamanho, isso significa que teoricamente Google levaria cerca de 38 dias para rastrear tudo uma vez — assumindo que cada requisição atingisse uma página única e útil. Não era. Aproximadamente 40% das requisições de rastreamento estavam acertando 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 sitemaps que herdo estão errados. Não dramaticamente errados -- apenas silenciosamente, inutilmente errados.
Problemas comuns que vejo:
- Páginas no sitemap que retornam 404s ou redirecionamentos 301
- Páginas com noindex 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 incorretasdates that are static or just wrong- 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 grande projeto de catálogo, o sitemap tinha 91.000 URLs em um único arquivo. Ele também estava incluindo todas as URLs filtradas que já tinham sido geradas -- mais de 40.000 das quais tinham noindex. O Googlebot estava processando esse arquivo enorme e depois descobria que a maioria das URLs não deveria ser rastreada mesmo assim. Sinal desperdiçado dos 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.<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Os dados do Bing Webmaster Tools (sim, vale a pena verificar -- o Bing às vezes mostra padrões de comportamento de rastreamento que sugerem problemas estruturais que o Google também está enfrentando) mostraram o tempo de processamento do sitemap cair mais de 60%.
Linkagem Interna: A Alavanca Que Você Realmente Controla
Aqui há algo que genuinamente não apreciei até a Seahawk Media assumir 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 uma estrutura de URL limpa. O problema era a profundidade de links internos. Milhares de artigos estavam efetivamente órfãos -- nenhum link interno 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.only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
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.WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
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
- Referenciar páginas cruzadas que têm bons links -- encontrar clusters temáticosare well-linked -- find topical clusters
- Construa links internos contextuais de páginas de alto tráfego para baixo nas páginas pouco linkadas
- Validar na ferramenta Inspeção de URL do Search Console que páginas recém-vinculadas mudam de "Descoberta -- não indexada no momento" para "Rastreada"
Esse status "Descoberta -- não indexada no momento" no Search Console é seu aviso. Significa que o Google sabe que a página existe mas não priorizou buscá-la. Melhorar links internos geralmente é a forma 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 as ferramentas de rastreamento davam a maior parte do que você precisava. Eu estava errado.
Arquivos de log dizem 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 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 ativos do lado do admin que deveriam ter sido bloqueados em robots.txt. Ninguém tinha configurado isso apropriadamente. Páginas de documentação que não tinham sido rastreadas em quatro meses.actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
A Log File Analyser do Screaming Frog é a ferramenta que uso. Não é glamourosa, mas é confiável. Importe seus logs de servidor, filtre pelo user agent do Googlebot e ordene pela frequência de acessos por URL. Os padrões que emergem são quase sempre esclarecedores -- e quase sempre incluem algo sendo rastreado que não deveria ser. is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
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 com status "Discovered -- currently not indexed" ou "Crawled -- currently not indexed"
Esse segundo status -- "Crawled -- currently not indexed" -- é diferente e vale a pena separar. Significa que o Google buscou a página e decidiu não a indexar, geralmente devido a conteúdo fraco ou problemas de duplicação próxima. Nenhuma quantidade de otimização de crawl budget 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. Crawl budget se torna uma preocupação genuína em larga escala -- tipicamente acima de 10.000 a 15.000 páginas, ou em sites onde uma grande porção de URLs são geradas dinamicamente.
Enviar um sitemap diretamente vai resolver problemas de orçamento de crawl?
Não. Um sitemap ajuda com descoberta -- ele diz ao Google que essas URLs existem. Mas se seu site tem problemas estruturais (spam de navegação facetada, resposta lenta do servidor, ligação interna rasa), um sitemap não vai sobrepor 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 crawl budget mas significando que o Google não consegue ler nenhum sinal nessa 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 crawl budget especificamente, disallow é mais efetivo em URLs genuinamente inúteis (caminhos de admin, resultados de busca interna). Para páginas de faceta filtradas onde você quer que o Google entenda o conteúdo mas não o indexe, noindex com um canonical é geralmente o caminho certo.Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
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 em contagens de páginas indexadas levou cerca de seis a oito semanas após as correções principais serem implementadas. Não espere mudanças da noite para o dia -- o Googlebot precisa fazer o re-rastreamento, reavaliar, 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 cresceram de 34.000 para pouco mais de 71.000 em cinco meses. Não perfeito -- havia páginas de produto genuinamente fracas 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. Mais ou menos.