Crawl Stats do Search Console: guia prático para diagnosticar crawl budget

O Relatório de estatísticas de rastreamento (Crawl Stats) é um dos poucos lugares do Search Console onde você vê o Googlebot pela ótica do seu servidor: quantas requisições ele fez, o que respondeu, quanto baixou e quanto demorou. É um relatório para usuários avançados, e o próprio Google avisa: se o site tem menos de mil páginas, você provavelmente não precisa se preocupar com esse nível de detalhe. Mas se você opera um portal grande, e-commerce↳E-commerce21 conteúdosECBR Club: novo espaço para devs se conectarem ao ecossistema de e-commerceDev (Back & Front) · mai 2025TOTVS anuncia joint venture com VTEXMarketing Tech · mai 2019Jovens da Brasilândia recebem formação gratuita em tecnologiaGestão Dev & TI · jul 2025Ver tudo em Marketing Tech → ou um site que sofre com recrawl lento, é aqui que o crawl budget aparece de forma mensurável.

Abaixo mostro o caminho que eu percorro num site real para diagnosticar desperdício de rastreamento, gráfico por gráfico.

Pré-requisitos e onde clicar

O Crawl Stats só existe para propriedades no nível raiz: propriedade de Domínio (example.com) ou de prefixo de URL na raiz (https://example.com). Se a sua propriedade é https://example.com/blog/, esqueça, o relatório não aparece.

O caminho não fica no menu lateral óbvio. Você abre o Search Console, clica em Configurações (ícone de engrenagem, Property settings) e depois em Estatísticas de rastreamento. Foi o primeiro tropeço que vi gente ter: procurar no menu de indexação e não achar.

Antes de interpretar qualquer coisa, três fatos sobre os dados que mudam a leitura:

• São URLs reais requisitadas, não canônicas. Diferente de outros relatórios, aqui não há consolidação por canonical. Se o Googlebot pediu page1 que redireciona para page2 e depois page3, você vê três requisições separadas, e a resposta de redirect entra no tipo de arquivo Outro tipo de arquivo.
• Só conta o domínio selecionado. Um recurso hospedado fora (uma imagem em google.com/img.png dentro da sua página) não aparece. Já subdomínios abaixo do pai aparecem: em example.com você vê en.example.com, de.example.com etc.
• A cobertura é parcial. O Google admite como known issue que nem toda requisição é contada, então haverá diferença entre o log do seu servidor e os números daqui. Não trate como fonte contábil, trate como tendência.

Os três números do topo

O cabeçalho traz Total de solicitações de rastreamento, Tamanho total do download e Tempo médio de resposta. É aqui que o cruzamento com Core Web Vitals de servidor começa.

O tempo médio de resposta é o TTFB agregado que o Googlebot experimentou. Se ele subiu junto com o total de requisições, você tem um sinal clássico de servidor sob pressão de crawl. O tamanho total do download importa porque cada byte que o Googlebot baixa de recurso inútil (miniatura, CSS↳CSS31 conteúdosArquitetura CSS: CSS FuncionalDev (Back & Front) · set 2019Entendendo posicionamento com CSS de uma vez por todasDev (Back & Front) · jul 2025Sites que combinam estética e usabilidade: reflexos da evolução do CSSDev (Back & Front) · fev 2025Ver tudo em Dev (Back & Front) → duplicado, XML gigante) é byte que ele não gastou recrawleando conteúdo que muda.

Detalhe útil: se o Google já cacheou um recurso usado por várias páginas, ele só o baixa uma vez. Então download alto costuma vir de páginas/recursos únicos, não de assets compartilhados.

Host status: o primeiro lugar que eu olho

O Status do host resume se o Google encontrou problemas de disponibilidade nos últimos 90 dias. Verde é o que você quer. Se estiver vermelho, houve pelo menos um problema significativo na última semana, e vale investigar recorrência.

Ele se divide em três categorias, cada uma com um gráfico e uma linha pontilhada vermelha que marca o limiar de problema (por exemplo, falha de DNS acima de 5% das requisições num dia):

• Busca do robots.txt: taxa de falha nas requisições ao arquivo.
• Resolução de DNS: quando seu DNS não respondeu ou não reconheceu o host.
• Conectividade do servidor: quando o servidor não respondeu ou não completou a resposta.

O comportamento do robots.txt merece atenção porque é onde vejo mais crawl budget evaporar sem ninguém perceber. A regra do Google:

• 200 com arquivo (válido, inválido ou vazio) = sucesso. Erro de sintaxe não invalida a resposta, o Google só ignora a regra quebrada.
• 403/404/410 = sucesso também (significa "não existe robots.txt", pode rastrear tudo).
• 429/5XX = fracasso. E aqui está o problema.

Quando o robots.txt responde 5XX, o Google não usa o último válido de cara. Nas primeiras 12 horas ele para de rastrear o site e só fica pedindo o arquivo. De 12 horas a 30 dias, usa o último robots.txt bom que tem em mãos. Depois de 30 dias, se a home responde, ele age como se não houvesse robots.txt; se a home também caiu, para o rastreamento. Ou seja: um robots.txt que devolve 500 intermitente pode congelar seu rastreamento por meio dia sem gerar erro visível em outro lugar.

Crawl responses: onde mora o desperdício

A tabela de Respostas de rastreamento agrupa os códigos por percentual do total de requisições (não por URL). Em circunstâncias normais, a esmagadora maioria deveria ser 200.

O que eu caço aqui:

• 301/302/308/307: redirects são "bons", mas lembre que cada salto da cadeia conta como requisição. Uma cadeia A → B → C triplica o custo de rastreamento de um único destino. Encurtar cadeias de redirect é a correção de crawl budget mais barata que existe.
• 404: nem todo 404 precisa ser corrigido, às vezes é o comportamento certo. Mas volume alto de 404 vindo de links internos quebrados é budget jogado fora.
• 5XX (Server error): geram alertas de disponibilidade e devem ser corrigidos. Se o Google está sobre-rastreando e derrubando seu servidor, dá para pedir taxa de rastreamento menor, mas antes confirme se não é um problema de disponibilidade real.
• robots.txt não disponível: diferente de 404. Se aparecer aqui, releia a seção acima, é o pior tipo de resposta.

Clicando em qualquer linha você abre exemplos de URLs. O Google avisa que os exemplos não são exaustivos, são amostra representativa e podem ser ponderados por dia, então não conclua que uma URL não foi rastreada só porque não aparece na lista.

File type e Googlebot type: entendendo o que consome o crawl

A tabela de Tipo de arquivo mostra o percentual de respostas por formato (HTML, imagem, JS, CSS, PDF, JSON, XML, feed, e Outro tipo de arquivo, onde entram os redirects). O percentual é de respostas, não de bytes.

Se o tempo de resposta está ruim, é aqui que eu descubro o culpado: o Google está pedindo muitas imagens pequenas que deveriam estar bloqueadas? Está buscando recursos hospedados num terceiro lento? Clicando num tipo, você vê tempo médio de resposta por dia e número de requisições por dia, e consegue casar picos de lentidão de um tipo específico com picos de lentidão geral.

A tabela de Tipo de Googlebot revela quem fez as requisições:

• Smartphone / Desktop: rastreamento de páginas.
• Carregamento de recurso de página: fetch secundário de imagens e CSS para renderizar antes de indexar. Se uma imagem é carregada como recurso da página, ela conta aqui, não como Image.
• AdsBot: rastreia a cada ~2 semanas; pico aqui costuma ser novo alvo de Dynamic Search Ads.
• StoreBot: crawler de shopping de produtos.

Esse cruzamento é o que fecha o diagnóstico. Um pico de requisições sem tráfego novo correspondente muitas vezes é AdsBot ou recurso de página, não conteúdo. Se o pico é AdsBot depois que alguém subiu campanha, não é problema de SEO.

Crawl purpose e o que fazer com o diagnóstico

A última peça é o Motivo do rastreamento: Descoberta (URL nunca rastreada antes) versus Atualização (recrawl de página conhecida). Se você tem páginas que mudam rápido e não estão sendo recrawleadas o suficiente, garanta que estejam num sitemap; para páginas de mudança lenta, peça recrawl pontual. Se você subiu muito conteúdo novo ou um sitemap e não vê aumento em crawls de descoberta, algo está barrando a descoberta.

O fio que amarra tudo: cada requisição que o Googlebot gasta em redirect encadeado, 404 de link quebrado, recurso inútil ou tentativa de robots.txt que falha é requisição que ele não gastou descobrindo e atualizando o conteúdo que gera tráfego. O Crawl Stats é o único relatório que quantifica esse desperdício antes e depois da correção. Faça a mudança (encurtar redirects, estabilizar o robots.txt, bloquear recurso inútil), espere alguns dias e compare o percentual de 200 e o tempo médio de resposta. É engenharia mensurável, não adivinhação.

Fonte: Search Console — Relatório de estatísticas de rastreamento (Crawl Stats)