Indexação de sites em 2026: como funciona o crawl budget e como não desperdiçá-lo

Imagine que você construiu um shopping center com dez mil lojas, mas o fiscal que emite as licenças de funcionamento aparece uma vez por dia e consegue inspecionar apenas quinhentas portas. E metade do tempo ele passa nos depósitos, nos estoques e nos banheiros, para onde suas próprias placas o levaram por acidente. É exatamente assim que a indexação de sites se apresenta na maioria dos projetos de médio e grande porte. O robô de busca chega, gasta recursos com lixo e vai embora sem ter visto suas melhores páginas.

Em 2026, esse problema se agravou. Os mecanismos de busca ficaram bem mais seletivos: o índice deixou de ser um depósito infinito onde se guarda tudo. Ao mesmo tempo, uma onda de novos crawlers que coletam dados para modelos de IA caiu sobre os servidores, e eles competem pela mesma largura de banda dos bots de busca. O dono do site que não gerencia como seu recurso é rastreado perde não pontos abstratos, mas dinheiro de verdade: produtos novos não entram na busca por semanas, preços atualizados ficam desatualizados, e as landing pages de campanhas permanecem invisíveis.

Este guia é dedicado a um tema específico: como os mecanismos de busca decidem o que e quando rastrear no seu site, e como influenciar essa decisão. De propósito, não vamos repetir como montar um sitemap ou escrever diretivas para robôs. No nosso blog, esses temas são tratados separadamente. Aqui falaremos do próprio mecanismo: do que acontece entre o momento em que o robô descobre a existência de uma URL e o momento em que a página aparece no índice.

Para quem isso é útil? Para profissionais de marketing cujas novas landing pages demoram demais para serem indexadas. Para desenvolvedores cujo servidor geme sob a carga dos bots, mas cujas seções importantes continuam sem ser rastreadas. Para afiliados com dezenas de sites e centenas de landing pages, onde a velocidade de entrada no índice afeta diretamente o retorno do investimento. Para donos de e-commerce e agregadores, onde a navegação facetada gera milhões de endereços. Vamos destrinchar a teoria em linguagem clara, apresentar quatro métodos práticos com instruções passo a passo, mostrar erros típicos, ferramentas e cases reais com números. Ao final do artigo, você terá um framework completo de gestão de crawl budget que pode ser aplicado já nesta semana.

Fundamentos: como funciona a indexação de sites e o que é crawl budget

Começamos pelo básico, porque é justamente aí que mora a maioria dos equívocos. Muitos acham que a indexação de sites acontece de forma instantânea e automática: publicou a página, e ela está na busca. Na prática, cada URL passa por várias etapas e pode travar em qualquer uma delas.

As cinco etapas do caminho de uma página até o índice

1. Descoberta. O mecanismo de busca fica sabendo que o endereço existe: por um link interno, por um link externo, pelo sitemap, por um contador de analytics ou por uma notificação. A URL descoberta entra na fila.
2. Planejamento. O sistema decide quando e se vale a pena rastrear esse endereço. São considerados o valor estimado da página, o histórico de alterações, a carga no servidor e a prioridade atual da fila.
3. Rastreamento (crawling). O robô envia uma requisição HTTP e recebe a resposta: código HTML, status, cabeçalhos. É aqui que o tal orçamento é gasto.
4. Processamento e renderização. O código recebido é analisado, os links são extraídos e, se necessário, a página vai para a fila de execução de JavaScript. Em seguida, o sistema avalia o conteúdo, determina o endereço canônico e verifica a existência de duplicatas.
5. Indexação. A página é adicionada ao índice e fica disponível para ranqueamento, ou é rejeitada: como duplicata, como conteúdo de baixo valor, como bloqueada por diretivas.

Repare: rastreamento e indexação são eventos diferentes. A página pode ser rastreada, mas não indexada. E o contrário também: uma URL pode ser indexada com base em sinais externos, sem um rastreamento completo do conteúdo. Entender essa diferença elimina metade dos erros na hora de diagnosticar.

O que é crawl budget

Crawl budget (orçamento de rastreamento) é a quantidade de URLs que o robô de busca está disposto e é capaz de rastrear no seu site em um determinado período. Ele se compõe de dois fatores.

• Limite de velocidade de rastreamento (crawl capacity limit) - quantas conexões e requisições paralelas o robô pode abrir sem sobrecarregar seu servidor. É o teto técnico. Ele cresce dinamicamente quando o servidor responde rápido e de forma estável, e cai com erros, timeouts e respostas lentas.
• Demanda de rastreamento (crawl demand) - o quanto o mecanismo de busca está interessado no seu conteúdo. Páginas populares, atualizadas com frequência e bem citadas são requisitadas com mais frequência. Páginas órfãs de baixa qualidade podem não ser requisitadas por meses, mesmo com o limite livre.

O orçamento final é o menor dos dois valores. O servidor pode aguentar mil requisições por segundo, mas se o robô não vê demanda, ele virá buscar dez páginas. E o inverso: o conteúdo pode ser desejado, mas se o servidor retorna erros, o limite será reduzido.

Quem isso afeta

A posição oficial dos grandes mecanismos de busca: o crawl budget se torna um problema real para sites a partir de algumas dezenas de milhares de páginas com alterações frequentes, ou de um milhão de páginas em geral. Isso é verdade, mas com uma ressalva. Um site pequeno com dois mil endereços também pode sofrer se, desses dois mil, mil e quinhentos forem lixo técnico, e o orçamento, por causa da juventude do domínio e de uma massa de links fraca, for de cem URLs por dia. A proporção importa mais do que os números absolutos. Por isso, a pergunta "quanto orçamento eu tenho" sempre vem acompanhada da pergunta "no que ele está sendo gasto".

Imersão profunda: como os robôs tomam decisões em 2026

Agora vamos olhar por dentro do mecanismo. Os algoritmos exatos dos mecanismos de busca são fechados, mas pela documentação oficial, patentes, experimentos e logs de grandes projetos, o quadro fica bastante nítido.

Uma fila com prioridades, não uma lista

O robô não percorre o site "em ordem". Todas as URLs conhecidas ficam numa enorme fila, onde cada endereço tem uma nota de prioridade. Ela se forma a partir de vários fatores:

• Importância por links - quantidade e qualidade de links internos e externos para a URL. A home e as seções de primeiro nível quase sempre estão no topo da fila.
• Frequência de alteração prevista. Se a página mudou nos últimos dez rastreamentos todas as vezes, o robô virá mais cedo. Se nunca mudou, o intervalo vai aumentar.
• Utilidade histórica. Páginas que recebem cliques na busca são rastreadas com mais frequência. Páginas que foram rastreadas e rejeitadas perdem prioridade.
• Tipo e padrão de URL. Os sistemas aprendem com padrões de endereço. Se centenas de páginas no formato /catalog/?sort=price se revelaram duplicatas, todo o padrão receberá prioridade reduzida.
• Estado do servidor. Cada resposta 5xx, cada timeout, é um sinal para reduzir a intensidade para todo o host.

Daí uma conclusão importante: o crawl budget não é só a quantidade de requisições, mas também sua distribuição. Você pode ter um limite generoso e, mesmo assim, ver o robô rechecando pela décima vez no dia uma página vazia de filtro, ignorando um produto novo.

Duas ondas de processamento e o custo do JavaScript

Os robôs modernos sabem executar JavaScript, mas fazem isso numa fila separada, com recurso separado. Primeiro, o sistema processa o HTML original, extrai dele os links e o conteúdo. Se a página depende de scripts, ela é enviada para renderização, que pode acontecer horas ou dias depois. Links que só aparecem após a execução do JS serão descobertos com atraso. Conteúdo carregado por script é avaliado mais tarde.

Para sites em frameworks de client-side sem renderização no servidor, isso significa gasto duplo: o orçamento de rastreamento é gasto no HTML, o de renderização na execução do código, e entre eles se perde tempo. Em 2026, essa continua sendo uma das principais causas de indexação lenta em projetos tecnologicamente modernos. Um paradoxo, não é?

Status que você precisa saber ler

Nos painéis de webmasters existem vários status, cada um apontando para uma etapa específica do problema.

• Descoberta, não indexada. O robô sabe do endereço, mas ainda não o rastreou. Sintoma clássico de déficit de orçamento ou de prioridade baixa: a fila é longa e a URL está no fim dela.
• Rastreada, não indexada. O robô obteve o conteúdo e decidiu não adicioná-lo ao índice. Isso já não é uma questão de orçamento, mas de qualidade, duplicação ou conteúdo raso. O orçamento, nesse caso, foi gasto em vão.
• A página é uma cópia, o endereço canônico foi escolhido não pelo usuário. O sistema encontrou uma duplicata e escolheu outra URL. Cada página dessas é um rastreamento jogado no lixo.
• Erro de servidor ou redirecionamento. Sinal direto de que o orçamento está indo para endereços que não funcionam.

Especificidades do Yandex

O robô do Yandex funciona por princípios semelhantes, mas com particularidades. Ele tem uma cota separada para reindexação forçada, limitada por dia. Usa ativamente os dados do contador de analytics para descobrir páginas novas. É sensível à vinculação regional e pode rastrear o mesmo endereço no contexto de regiões diferentes. E é bastante agressivo no início do conhecimento com o site: um projeto novo pode receber um pico de requisições que depois se estabiliza. Ignorar esses detalhes ao trabalhar no mercado russo não é uma opção.

O que mudou até 2026

Três tendências definem o cenário atual. Primeira: o índice ficou mais rígido. Os buscadores dizem abertamente que não são obrigados a indexar tudo. Páginas rasas, padronizadas, geradas sem valor, são descartadas na fase de processamento. Segunda: o aumento do número de crawlers de IA. Bots que coletam dados para modelos de linguagem podem gerar uma carga comparável à dos bots de busca, e às vezes superior. Eles não trazem tráfego de busca, mas consomem recursos do servidor e, indiretamente, reduzem o limite dos robôs de busca de verdade. Terceira: a frescor do conteúdo como sinal de demanda se intensificou. Sites que realmente atualizam páginas recebem mais atenção, e a simulação de atualização pela troca de data sem alterar o conteúdo é reconhecida e punida com redução de prioridade.

Método 1: Auditoria de logs do servidor como base da gestão de orçamento

Se você quer gerenciar algo, precisa medir. Os painéis de webmasters fornecem estatísticas agregadas de rastreamento, mas elas são suavizadas, atrasadas e incompletas. A única fonte de verdade sobre para onde o robô realmente vai são os logs do seu servidor. Esse é o primeiro e principal método.

Por que usar logs se existe o painel de webmaster

O relatório de estatísticas de rastreamento mostra o número total de requisições, o tamanho médio da resposta e a distribuição por tipos. Mas ele não diz que o robô passou 40% do tempo em páginas de ordenação do catálogo. Não mostra que uma seção importante não foi visitada há três semanas. Não revela que metade das requisições a produtos retorna redirecionamento. Os logs mostram tudo isso, URL por URL.

Instruções passo a passo para a auditoria

1. Coletar logs de pelo menos 30 dias. Para sites com rastreamento esporádico, melhor 60-90 dias. Confirme que todos os nós estão sendo logados: balanceadores, CDN, servidores individuais. Omissão de um nó distorce o quadro.
2. Separar as requisições dos robôs de busca. Filtre pela string User-Agent, mas sempre verifique a autenticidade: robôs reais vêm de faixas de IP conhecidas, publicadas pelos mecanismos de busca, e são confirmados por consulta reversa de DNS. Bots falsos se passando por robôs de busca podem chegar a um terço do total nos logs. Contá-los é analisar ruído.
3. Classificar as URLs por tipo. Divida os endereços em categorias: home, seções, fichas de produto ou artigos, páginas com parâmetros, paginação, busca interna do site, institucionais, recursos estáticos, inexistentes. Para isso, basta um conjunto de expressões regulares conforme a estrutura dos endereços.
4. Montar uma tabela consolidada. Para cada categoria, calcule: número de requisições do robô, participação no total, distribuição dos códigos de status, tempo médio de resposta, quantidade de URLs únicas. Compare com o valor de negócio de cada categoria.
5. Encontrar as lacunas. Compare a lista de URLs rastreadas pelo robô com a lista de URLs da sua estrutura de site. Vão aparecer dois grupos: endereços que são rastreados mas não deveriam existir, e endereços que deveriam ser rastreados mas nunca foram visitados.
6. Calcular a frequência de visita às páginas-chave. Para as cem URLs mais importantes, observe o intervalo entre as visitas do robô. Se produtos novos são visitados a cada duas semanas, essa é a sua velocidade real de indexação.

Uma linha típica de log com a qual você vai trabalhar se parece com isso:

66.249.66.1 - - [12/Feb/2026:08:14:22 +0300] "GET /catalog/phones/?sort=price&page=17 HTTP/1.1" 200 48211 "-" "Mozilla/5.0 (compatible; Googlebot/2.1)"

Só de bater o olho nela já se vê muita coisa: o robô veio buscar a décima sétima página de uma lista ordenada por preço. A probabilidade de essa página ser valiosa para o índice tende a zero. E linhas assim, nos logs de uma grande loja, são dezenas de milhares por dia.

O framework dos quatro quadrantes

Os resultados da auditoria ficam bem organizados numa matriz "é rastreado - não é rastreado" versus "é valioso - não é valioso".

• Rastreado e valioso. Zona de normalidade. A tarefa é garantir que a frequência de visita corresponda à frequência de alteração.
• Rastreado e não valioso. Zona de vazamento. É aqui que o orçamento queima. Primeiro alvo a eliminar.
• Não rastreado e valioso. Zona de oportunidade perdida. Para cá é preciso redirecionar o recurso liberado, via links internos e sinais de prioridade.
• Não rastreado e não valioso. Zona de repouso. Não é preciso fazer nada, mas vale garantir que essas páginas não comecem a ser descobertas de repente.

Checklist de sinais de alerta nos logs

• Mais de 20% das requisições do robô vão para URLs com parâmetros que não geram conteúdo único.
• Mais de 10% das respostas ao robô são redirecionamentos ou erros 404.
• Existem respostas 5xx ou o tempo de resposta ao robô ultrapassa dois segundos em uma parcela relevante das requisições.
• Páginas comerciais-chave são visitadas menos de uma vez por semana, apesar de alterações diárias de preço e estoque.
• O robô requisita URLs que não estão nem na estrutura nem no sitemap: sinal de "vazamento" de endereços por scripts, links antigos ou invasão.
• Uma parcela significativa das requisições vai para recursos estáticos que não são cacheados e são servidos do zero toda vez.

A auditoria de logs é o trabalho mais subestimado do SEO técnico. Ela exige tempo, mas depois dela todos os outros métodos deixam de ser adivinhação e se tornam cirurgia de precisão.

Método 2: Eliminar os devoradores de crawl budget

Com o mapa de vazamentos pronto, partimos para a eliminação. O princípio aqui é importante: não tentar corrigir tudo de uma vez, mas atacar as maiores fontes. Vamos ver os devoradores típicos e como lidar com cada um.

Navegação facetada e parâmetros de URL

O maior inimigo da indexação de sites grandes. Um catálogo com dez filtros de cinco valores cada teoricamente gera milhões de combinações de endereços. O robô, encontrando links para elas, vai percorrer todas, honestamente. O que fazer:

• Defina quais combinações de filtros têm demanda de busca real. Normalmente são filtros únicos e alguns pares raros: "tênis vermelho", "notebook 16 polegadas". Estes mantemos abertos, com conteúdo único, títulos e descrições.
• Todas as outras combinações, além de ordenações, alternadores de visualização e quantidade por página, não devem gerar URLs indexáveis. As opções: indicar o endereço canônico da categoria base, implementar a filtragem sem alterar a URL, usar a diretiva noindex.
• Links para combinações sem valor não devem ser links normais no HTML. Se o robô não os vê, não gasta com eles. Essa é a opção mais econômica.

Paginação e espaços infinitos

Listas com centenas de páginas, calendários de eventos com rolagem infinita para frente, arquivos por dia - tudo isso são "espaços infinitos" onde o robô pode ficar preso. Soluções: limitar a profundidade da paginação a um número razoável, não criar links para datas vazias, dar ao robô links diretos para itens profundos por meio de categorias e tags, e não apenas pela rolagem sequencial.

Duplicatas de origem técnica

O mesmo conteúdo está disponível em endereços com e sem barra no final, em maiúsculas e minúsculas, com e sem index.php, em http e https, com e sem www, com e sem utm. Cada variante é uma requisição separada. A regra é simples: um conteúdo, um endereço. Todas as variantes devem retornar redirecionamento 301 para o principal, ou pelo menos conter o endereço canônico. Verifique isso não por amostragem, mas em massa, com um crawler por todo o site.

Cadeias de redirecionamento e links quebrados

O robô, ao receber um 301, faz uma segunda requisição. Se ali também houver redirecionamento, faz uma terceira. Uma cadeia de quatro redirecionamentos gasta cinco requisições para uma única página. Além disso, cadeias longas podem simplesmente se romper: o robô para de seguir depois de alguns saltos. O mesmo vale para links internos para páginas removidas: cada clique neles é uma requisição que retornou 404, ou seja, orçamento jogado fora. A tarefa: todos os links internos devem levar direto ao endereço final com resposta 200.

Soft 404 e páginas vazias

Página "produto não encontrado" com código 200, categoria vazia, resultado de busca sem resultados - tudo isso é soft 404. O robô recebe uma resposta completa, gasta recurso no processamento e depois percebe que não há conteúdo. Páginas vazias devem retornar 404 ou 410 honesto, ou simplesmente não existir.

Busca interna e seções institucionais

Páginas de resultado de busca interna, carrinho, área do cliente, páginas de comparação de produtos, versões para impressão - o robô não deve chegar lá por links. Aqui entram justamente as diretivas para robôs, mas lembre que essa ferramenta é tratada em detalhe em outro artigo do blog.

Detalhe importante: noindex não economiza orçamento

Um equívoco comum: colocou noindex, problema resolvido. Não. Para ver o noindex, o robô precisa requisitar a página. Ele fará isso com menos frequência do que em páginas indexáveis, mas fará. Só uma coisa economiza orçamento: a ausência de links para a URL ou o bloqueio de rastreamento. Para remover lixo já indexado, o mais rápido é o código 410: ele comunica de forma inequívoca que a página foi removida para sempre, e o robô para de voltar mais rápido do que no caso do 404.

Algoritmo de priorização de correções

1. Para cada fonte de vazamento, anote a participação nas requisições do robô, com base na auditoria de logs.
2. Avalie a dificuldade de correção: configuração de servidor - fácil, alteração de template - médio, reformulação da lógica de filtros - difícil.
3. Avalie o risco: as mudanças podem afetar tráfego ou jornadas de usuário.
4. Comece pela combinação "grande participação - correção simples - risco baixo". Normalmente são redirecionamentos, links quebrados e duplicatas técnicas. Em seguida, passe para parâmetros e facetas.
5. Após cada etapa, dê ao robô duas a três semanas e reveja os logs. O orçamento liberado deve se redistribuir para páginas valiosas. Se isso não aconteceu, passe para o terceiro método.

Método 3: Arquitetura do site e sinais de prioridade para o robô

Liberar orçamento é metade do trabalho. Agora é preciso direcioná-lo para onde ele traz benefício. O robô segue sinais, e os principais são a estrutura de links e a frescor.

Profundidade de cliques como medida de prioridade

Quanto mais longe a página está da home na cadeia de links, menor sua prioridade na fila de rastreamento. Regra prática: todas as páginas que devem gerar tráfego precisam ser alcançáveis em no máximo três ou quatro cliques. Um produto numa subcategoria na vigésima página de paginação está na profundidade sete ou oito - para o robô, é uma zona praticamente invisível. Como reduzir a profundidade:

• Páginas hub: seções que reúnem links para dezenas de páginas finais por tema.
• Blocos de interlinking em fichas e artigos: "produtos semelhantes", "leia também", "vistos juntos com frequência". Eles não só retêm usuários como criam caminhos extras para o robô.
• Links para páginas novas a partir da home e das seções: um bloco de "novidades" acelera diretamente a descoberta e o rastreamento.
• Coleções por tags e temas como rotas alternativas para conteúdo profundo.

Frescor como combustível da demanda

O robô vem com mais frequência onde algo muda. Mas a mudança precisa ser real: descrição atualizada, avaliações novas, preço em dia, seção de artigo complementada. Mudar a data de publicação sem alterar o conteúdo é reconhecido rapidamente e trabalha contra você. Um bom truque prático é incluir nas páginas importantes blocos dinâmicos, mas com significado: últimas avaliações, promoções em vigor, novidades relacionadas. A página vive, e o robô percebe isso.

Cabeçalhos Last-Modified honestos

Se o servidor informa corretamente a data da última modificação e suporta requisições condicionais, o robô pode verificar a página e receber um 304 Not Modified sem baixar o corpo. É uma requisição muito barata: quase não consome limite e, ao mesmo tempo, atualiza a informação de atualidade. Configure isso para todas as páginas estáticas ou de rara alteração. Mas o cabeçalho precisa ser honesto: se a data muda a cada requisição, o robô deixa de confiar nele.

Consolidação de conteúdo raso

Dez páginas de cem palavras sobre temas próximos são dez requisições do robô e, muito provavelmente, dez decisões de "não indexar". Uma página completa de mil palavras é uma requisição e alta probabilidade de entrar no índice. Procure clusters de páginas fracas: fichas de produto sem descrição, notícias curtas, páginas de características isoladas. Una-as, fazendo redirecionamento dos endereços antigos para o novo.

Lançamento controlado de páginas novas

Um erro comum é publicar cem mil endereços novos no site em um único dia. O robô verá o pico, mas seu orçamento não crescerá instantaneamente. A fila se estenderá por meses, e a prioridade das páginas novas será distribuída aleatoriamente. Melhor lançar em ondas: primeiro as seções mais valiosas, com links diretos dos níveis superiores, depois as seguintes. E, com antecedência de algumas semanas, reforçar a infraestrutura do servidor e o interlinking interno.

Consistência de sinais

O robô se perde quando os sinais se contradizem. O endereço canônico aponta para uma página que redireciona para uma terceira. As versões de idioma se referenciam incorretamente. O sitemap contém endereços com noindex. Cada contradição são requisições extras para esclarecer e uma queda de confiança no site como um todo. Uma vez por trimestre, faça uma verificação de consistência: todos os endereços canônicos respondem 200, todos apontam para si mesmos, todos os links dentro do site levam às versões canônicas.

Checklist de arquitetura

• Todas as páginas valiosas são alcançáveis em 3-4 cliques a partir da home.
• Páginas novas recebem links das seções nas primeiras 24 horas.
• Não há páginas órfãs entre as URLs comerciais.
• Last-Modified e suporte a requisições condicionais estão configurados e corretos.
• Clusters de páginas rasas foram unificados ou removidos.
• Endereços canônicos, redirecionamentos e atributos de idioma não se contradizem.
• O lançamento de novas seções é planejado em ondas, com preparação prévia.

Método 4: Performance, renderização e monitoramento contínuo da indexação

O quarto método trata do teto técnico do orçamento e do sistema de controle. Aqui o papel dos desenvolvedores é especialmente grande, e para os profissionais de marketing é importante entender o que exatamente exigir.

Velocidade de resposta para o robô

O limite de rastreamento depende diretamente de quão rápido o servidor responde ao robô. A métrica-chave é o tempo até o primeiro byte. A prática mostra: com respostas estáveis mais rápidas que 300-500 milissegundos, o robô vai aumentando a intensidade aos poucos; com respostas acima de um a dois segundos, ele reduz. Atenção: o que importa é a velocidade para o robô, não para o usuário com cache de navegador aquecido. O robô costuma requisitar páginas frias, então o cache de HTML no servidor para requisições não autenticadas é o que dá o maior efeito. Verifique o tempo de resposta nos logs com filtro pelo robô, não na analytics geral.

Erros de servidor e códigos de sobrecarga

Respostas 5xx são a forma mais rápida de derrubar o orçamento. Algumas centenas de erros em uma hora, e o robô pode reduzir a intensidade por dias. Se o servidor estiver realmente sobrecarregado, o mais correto é retornar 503 ou 429 com o cabeçalho Retry-After: é um sinal claro de "volte depois", que não é interpretado como site quebrado. Mas use isso apenas temporariamente. Um problema separado e traiçoeiro: sistemas de proteção contra sobrecarga e atividade suspeita que começam a bloquear o robô ou a mostrar a ele uma página de verificação. Nos logs, isso aparece como respostas 403 ou 200 com código de captcha em vez de conteúdo. Inclua obrigatoriamente as faixas oficiais dos robôs de busca nas exceções dos sistemas de proteção e verifique regularmente que o robô vê exatamente o seu conteúdo.

Renderização sem surpresas

Para sites em frameworks JavaScript, o padrão de 2026 é a renderização no servidor ou a geração prévia de HTML. O robô precisa receber no código-fonte todo o conteúdo crítico e todos os links. Verifique isso com a ferramenta de inspeção de URL do painel de webmaster: compare o HTML renderizado com o que o usuário vê. Se os links para produtos só aparecem após a execução do script, a descoberta de páginas novas vai atrasar semanas. Acompanhe também o tamanho do HTML: os robôs limitam o volume do documento baixado, e páginas pesadas, com megabytes de dados embutidos, podem ser processadas de forma incompleta.

Crawlers de IA e concorrência por recursos

A nova realidade: bots que coletam dados para modelos de linguagem podem gerar dezenas de por cento de toda a carga automatizada. Eles não trazem tráfego de busca diretamente, mas deixam o servidor mais lento, o que reduz o limite para os robôs de busca. A solução é estimar a participação desses bots nos logs e decidir conscientemente a quais deles permitir acesso e com que intensidade. Parte deles respeita as diretivas padrão; para os demais, usam-se limites de frequência de requisições no nível do servidor. Isso não é bloquear atividade útil, mas gerenciar os recursos da sua infraestrutura.

Sistema de monitoramento da indexação

Uma auditoria pontual fica obsoleta em um mês. É preciso um sistema. Veja como montá-lo passo a passo.

1. Coleta diária de métricas dos logs. Número de requisições dos robôs, distribuição por categoria de URL, participação de erros, tempo médio de resposta. Automatize com um script que exporta para uma planilha ou banco de dados.
2. Controle semanal dos status nos painéis de webmasters. Dinâmica do número de páginas indexadas, crescimento das excluídas, surgimento de novos tipos de erro.
3. Verificação da presença real no índice. Os painéis mostram dados com atraso e nem sempre completos. Para páginas críticas - novas landing pages, produtos, artigos - vale verificar a presença na busca diretamente pela URL exata ou por um trecho único de texto. Em verificações massivas, os mecanismos de busca rapidamente começam a mostrar captcha a partir de um único endereço IP. Aqui entram em cena os proxies móveis com rotação: as requisições se distribuem por endereços de operadoras de telefonia reais, o que permite coletar dados de forma estável e no volume correspondente ao tamanho do seu site. Além disso, por meio de um proxy de uma região específica, é possível ver a busca como os usuários daquela região a veem, o que é crítico para sites com vinculação regional.
4. Verificação da disponibilidade do site para bots a partir de diferentes redes. Periodicamente, requisite páginas-chave a partir de endereços IP externos, incluindo redes móveis, para confirmar que os sistemas de proteção não estão devolvendo captcha ou bloqueio em vez de conteúdo. É uma verificação simples via proxy que revela problemas antes que eles apareçam nas estatísticas de rastreamento.
5. Alertas. Configure alertas para aumento abrupto de erros ao robô, queda de mais de 30% no número de requisições em 24 horas e surgimento de novos padrões de URL nos logs. A reação precoce economiza semanas de recuperação.

Esse circuito de monitoramento transforma a gestão do crawl budget de uma ação pontual em um processo contínuo. E esse é o único jeito de manter o resultado.

Erros típicos que queimam o crawl budget

Vamos reunir em um só lugar o que não se deve fazer. Cada um desses itens nós encontramos em projetos reais, e quase todos custaram aos donos meses de visibilidade perdida.

• Envios forçados em massa para reindexação. As ferramentas de solicitação de indexação servem para páginas importantes e pontuais. Enviar milhares de URLs por dia via scripts não aumenta o orçamento, e ensina o sistema a ignorar suas solicitações. Envie apenas o que realmente mudou e é importante.
• Apostar no noindex como forma de economia. Já falamos: o robô vem de todo jeito. Se o objetivo é não gastar requisições, é preciso remover links ou bloquear o rastreamento, e não a indexação.
• Ignorar bots falsos na análise. Sem verificar o IP, você analisa uma mistura do robô de verdade com scrapers de concorrentes. As conclusões serão erradas.
• Páginas de filtro abertas "por via das dúvidas". O argumento "vai que alguém busca por isso" leva a milhões de combinações rastreadas. Abra apenas o que tiver demanda comprovada.
• Mudança brusca de estrutura de URL sem plano. Migrar todo o site para novos endereços de uma só vez é dobrar a fila: o robô precisa rastrear os redirecionamentos antigos e as páginas novas. Planeje por seções.
• Servidor lento "só para bots". Os usuários recebem páginas cacheadas, e o robô, a geração fria com consultas ao banco. Ele vê um site lento e baixa o limite.
• Proteção anti-DDoS que bloqueia robôs de busca. Clássico: depois de contratar um serviço de proteção, a indexação parou, e nos logs só há 403 para o robô. As faixas dos robôs precisam estar na whitelist.
• Conteúdo e links apenas via JavaScript. O robô os verá com atraso ou não verá. Elementos críticos devem estar no HTML original.
• Geração automática de milhares de páginas "para os termos de busca". Páginas padronizadas sem valor único não só não são indexadas, como puxam para baixo a avaliação do site inteiro. O orçamento é gasto, e o resultado é negativo.
• Ausência de monitoramento após as correções. Fez a auditoria, corrigiu, esqueceu. Seis meses depois, um novo release adicionou um parâmetro na URL, e tudo se repetiu. O controle precisa ser contínuo.
• Substituir atualização real por fictícia. Mudar a data, trocar parágrafos de lugar, adicionar blocos vazios em nome da "frescor". O sistema reconhece isso e reduz a prioridade em vez de aumentá-la.

Se você reconheceu nessa lista pelo menos três itens do seu projeto, você não está sozinho. Segundo nossas observações, num e-commerce médio estão presentes cinco ou seis desses problemas ao mesmo tempo. A boa notícia é que todos são solucionáveis.

Ferramentas e recursos para trabalhar com indexação

O ferramental certo reduz a auditoria de semanas para dias. Vamos dividi-lo por tarefa.

Painéis de webmasters

Google Search Console e Yandex Webmaster são a base obrigatória. No primeiro, são criticamente importantes o relatório de indexação de páginas com divisão por motivo de exclusão, o relatório de estatísticas de rastreamento com dados por host, códigos de resposta e tipos de arquivo, e a ferramenta de inspeção de URL com a possibilidade de ver o HTML renderizado. No segundo, as seções de indexação com histórico de rastreamento, estatísticas de rastreamento, diagnóstico do site e a ferramenta de reindexação com cota diária. As duas fontes fornecem dados agregados com atraso, então são usadas como referência, não como fonte única.

Analisadores de log

• Screaming Frog Log File Analyser - ferramenta desktop prática para volumes médios: importação de logs, verificação de robôs, cruzamento com dados do crawler.
• GoAccess - analisador leve para um resumo rápido direto no servidor.
• Stack baseado em ClickHouse ou Elasticsearch com visualização - solução para projetos grandes, com milhões de linhas por dia. Permite construir dashboards e alertas em tempo real.
• Scripts próprios em Python com bibliotecas de parsing de logs e pandas para agregação - a opção mais flexível para desenvolvedores.

Crawlers para auditar a estrutura

Screaming Frog SEO Spider, Sitebulb, Netpeak Spider e soluções em nuvem para sites grandes. A tarefa é obter a lista completa de URLs do site com profundidade de cliques, códigos de status, endereços canônicos, redirecionamentos e links internos. O cruzamento dessa lista com os logs dá a matriz dos quatro quadrantes. Opção importante: modo de rastreamento com execução de JavaScript para comparar com o modo normal. A diferença mostra o que o robô verá com atraso.

Verificação de performance

Lighthouse e PageSpeed Insights para o quadro geral, mas para o crawl budget o que importa mais são as métricas de servidor: tempo até o primeiro byte nos logs com filtro pelo robô, monitoramento de disponibilidade a partir de vários pontos, testes de carga antes de lançamentos grandes.

Monitoramento de presença no índice e de resultados regionais

Para verificação massiva de indexação e posições, usam-se scripts próprios ou serviços de SERP. Em ambos os casos, o volume de requisições aos mecanismos de busca é significativo, e a partir de um único endereço elas rapidamente esbarram em captcha. Proxies móveis com rotação de IP resolvem essa tarefa: as requisições partem de endereços de operadoras móveis reais, se distribuem por um pool, e o targeting por região permite ver a busca pelos olhos do usuário da cidade desejada. Isso é especialmente importante para projetos com subdomínios regionais e para afiliados que acompanham a indexação de dezenas de landing pages ao mesmo tempo. A mesma ferramenta ajuda a verificar como o site responde a usuários de redes móveis e se a proteção não está bloqueando tráfego legítimo.

Notificações aos mecanismos de busca

O protocolo IndexNow permite informar instantaneamente sobre páginas novas e alteradas aos sistemas que o suportam, incluindo o Yandex. Isso não aumenta o orçamento, mas ajuda o robô a definir prioridades e a não gastar requisições rechecando páginas inalteradas. Use-o para mudanças reais, não para disparar o site inteiro em massa.

Cases: como a gestão do orçamento muda a indexação na prática

A teoria convence, os números provam. Três cases da prática, com dados anonimizados.

Case 1: e-commerce de eletrônicos, 180 mil produtos

Problema. Produtos novos apareciam no índice 18 a 25 dias após a publicação. Havia cerca de 70 mil páginas no índice, com 180 mil produtos. O painel de webmaster mostrava 2,3 milhões de URLs no status "descoberta, não indexada".

Diagnóstico. A auditoria de logs de 45 dias mostrou: o robô fazia cerca de 95 mil requisições por dia. Dessas, 61% iam para URLs com parâmetros de ordenação e filtros, 12% para paginação além da décima página, 8% para redirecionamentos de endereços antigos depois de uma migração de dois anos antes. Fichas de produto respondiam por 14%.

Ações. Links para ordenações e alternadores de visualização foram trocados por elementos sem URL. Ficaram abertas 340 páginas de filtro com demanda comprovada; as demais receberam o endereço canônico da categoria. A paginação foi limitada a 30 páginas, com a adição de coleções por tags para acessar produtos profundos. As cadeias de redirecionamento foram reduzidas a um único salto, e os links internos atualizados para os endereços finais. Foi ativada a resposta 304 para páginas inalteradas.

Resultado após 8 semanas. O número total de requisições do robô quase não mudou - cerca de 100 mil por dia. Mas a participação das fichas de produto subiu de 14% para 58%. Produtos novos passaram a entrar no índice em 2 a 4 dias. O número de páginas indexadas cresceu para 152 mil. O tráfego orgânico para as fichas de produto aumentou 34% no trimestre, sem um único link externo novo. O que surpreende: a carga no servidor diminuiu, porque o robô deixou de gerar requisições pesadas de filtros ao banco de dados.

Case 2: rede de 40 sites para arbitragem de tráfego

Problema. O dono lançava landing pages para campanhas em várias dezenas de domínios. Parte das landing pages era indexada em um dia, parte não era indexada por semanas, e não dava para prever. A verificação manual de indexação levava horas e vivia esbarrando em captcha.

Diagnóstico. Os logs mostraram que, em domínios jovens, o robô fazia 20 a 40 requisições por dia, e metade ia para páginas institucionais do template: políticas, formulários, páginas de agradecimento, que se duplicavam em cada landing page. Além disso, o serviço de proteção em um terço dos domínios entregava ao robô uma página de verificação em vez de conteúdo.

Ações. As páginas institucionais do template foram retiradas da navegação e bloqueadas para rastreamento. As faixas dos robôs foram incluídas nas exceções da proteção. As landing pages novas passaram a receber um link da home do domínio no momento da publicação, e a notificação de nova página passou a ser enviada via IndexNow. O monitoramento de indexação foi automatizado: um script diário verifica a presença de cada landing page na busca por meio de um pool de proxies móveis com rotação, sem captchas e com verificação regional para cada campanha.

Resultado. O tempo mediano para uma landing page entrar no índice caiu de 9 dias para 1,5 dia. A proporção de páginas não indexadas em uma semana caiu de 38% para 4%. O tempo de controle da indexação caiu de várias horas por dia para zero trabalho manual: o relatório chega automaticamente.

Case 3: portal de mídia em framework JavaScript, 400 mil artigos

Problema. Depois da migração para renderização no cliente, artigos novos apareciam no índice com atraso de 3 a 7 dias, e para um recurso de notícias isso é catastrófico. O painel mostrava crescimento do número de páginas no status "rastreada, não indexada".

Diagnóstico. A inspeção de URL mostrou que o HTML original continha apenas o esqueleto; todo o texto e os links para matérias relacionadas eram carregados por script. O robô recebia a página, colocava na fila de renderização, e só dias depois via o conteúdo. Os links para artigos novos no feed também só apareciam após a renderização, então a descoberta atrasava. Além disso, os logs mostraram que crawlers de IA geravam 44% de toda a carga automatizada, e o tempo de resposta ao robô de busca nos horários de pico passava de 2,5 segundos.

Ações. Foi implementada renderização no servidor para páginas de artigos e feeds, e o conteúdo crítico e os links foram movidos para o HTML original. Para os crawlers de IA, foram definidos limites de frequência de requisições no nível do servidor. Foi configurada uma camada separada de cache de HTML para requisições não autenticadas. Foi implementado um bloco de últimas matérias na home, com links diretos.

Resultado após 6 semanas. O tempo de resposta ao robô caiu para 280 milissegundos em média. O número de requisições do robô de busca cresceu 2,1 vezes - o limite subiu junto com a velocidade. Artigos novos passaram a ser indexados em 20 a 60 minutos. O número de páginas "rastreada, não indexada" caiu 71%. Impressiona como uma solução tecnicamente simples - entregar o conteúdo em HTML - deu tanto efeito.

FAQ: perguntas complexas sobre indexação de sites e crawl budget

Como saber se eu realmente tenho um problema de crawl budget, e não de qualidade de conteúdo?

Olhe os status. Se predomina "descoberta, não indexada", o robô não chega às páginas: é orçamento e prioridade. Se predomina "rastreada, não indexada", o robô chegou mas rejeitou: é qualidade ou duplicação. Muitas vezes os dois problemas coexistem, e então a solução do primeiro agrava o segundo: o orçamento liberado vai para páginas que continuarão sem ser indexadas. Trabalhe em paralelo: limpe os vazamentos e, ao mesmo tempo, melhore ou consolide o conteúdo fraco.

Dá para aumentar o crawl budget diretamente, pedindo ao mecanismo de busca?

Não. Não existem ferramentas de aumento manual do limite, e as antigas configurações de velocidade de rastreamento foram descontinuadas. O orçamento cresce por dois canais: um servidor rápido e estável eleva o teto técnico, e o aumento do valor e da atualidade do conteúdo, junto com a massa de links, eleva a demanda. Todo o resto é gestão da distribuição do recurso já existente.

Quanto tempo passa entre as correções e a mudança de comportamento do robô?

Os primeiros movimentos nos logs aparecem em 7 a 14 dias: o robô começa a requisitar menos os padrões removidos. A redistribuição estável leva de 4 a 8 semanas. O esquecimento total de blocos de URLs antigas leva meses, às vezes mais de um ano: o robô volta de vez em quando para checar se reapareceram. Não espere efeito imediato e não reverta as mudanças em uma semana.

Os crawlers de IA influenciam a indexação nos mecanismos de busca?

Diretamente, não: os robôs de busca têm orçamento próprio e independente. Indiretamente, sim. Se os bots de IA geram uma carga que deixa o servidor mais lento para responder ao robô de busca, o limite de rastreamento cai. A solução não é bloqueio total, mas gestão: estime a participação de cada bot nos logs, limite a frequência de requisições dos que não trazem valor e acompanhe separadamente o tempo de resposta ao robô de busca.

Vale remover do índice páginas de baixo tráfego para liberar orçamento?

Só depois de analisar. Uma página sem tráfego pode fazer parte de um cluster, sustentar outras páginas com links ou ter valor de conversão por acessos diretos. O critério de remoção não é o tráfego em si, mas a ausência de valor único: duplicatas, fichas vazias antigas, páginas padronizadas rasas. Melhor unificá-las com redirecionamento ou removê-las com código 410. Remover em massa "tudo o que não traz tráfego" costuma prejudicar mais do que ajudar.

Como verificar corretamente a indexação de milhares de páginas sem ser bloqueado por captcha?

Distribua as requisições no tempo e por endereços IP. A verificação a partir de um único endereço esbarra em captcha depois de algumas dezenas de requisições. Proxies móveis com rotação resolvem essa tarefa de forma tecnicamente correta: cada requisição parte de um endereço de operadora móvel real, o que corresponde ao comportamento de um usuário comum. Adicione pausas entre as requisições, rotação de cabeçalhos e verifique apenas as páginas realmente importantes, não o site inteiro todo dia. Para o quadro completo, combine verificações diretas com os dados dos painéis de webmasters.

Por que no painel de webmaster o número de páginas rastreadas cresce, mas o de indexadas cai?

Sinal clássico de vazamento: o robô descobriu uma nova fonte de URLs lixo e a está rastreando ativamente, mas essas páginas não passam na indexação. Procure nos logs novos padrões de endereço que surgiram nas últimas semanas: muitas vezes é resultado de um release com um novo parâmetro, da ativação de um novo widget ou de um erro no template de links. Quanto mais rápido encontrar a fonte, menos vai precisar limpar.

Um site pequeno de 500 páginas precisa fazer algo?

Problemas absolutos de orçamento não o ameaçam, mas as proporções importam aqui também. Se das 500 páginas, 300 são duplicatas técnicas e endereços institucionais, o robô, num domínio jovem com orçamento de algumas dezenas de requisições por dia, vai gastar boa parte nelas. Faça uma verificação básica: um conteúdo, um endereço; sem cadeias de redirecionamento; sem links para 404; servidor rápido; links para páginas novas a partir da home. Isso basta para que a indexação do site funcione de forma previsível.

Como saber se o robô vê o meu conteúdo e não uma página de verificação do serviço de proteção?

Três formas. Primeira: a ferramenta de inspeção de URL do painel de webmaster mostra exatamente o que o robô recebeu. Segunda: os logs - observe os códigos de resposta e o tamanho da resposta ao robô. Se o tamanho é suspeitosamente igual e pequeno para páginas diferentes, provavelmente está sendo servido um placeholder. Terceira: requisite suas páginas a partir de endereços externos de redes diferentes, incluindo móveis, via proxy: se a proteção dispara neles, há risco de disparar também no robô. As faixas dos robôs de busca devem estar na whitelist de qualquer sistema de proteção.

Conclusão: o crawl budget como recurso gerenciável

Vamos resumir. A indexação de sites não é um evento, mas um processo com recurso limitado. O robô de busca vem até você com um determinado limite de requisições, e no que ele vai gastá-las define quais páginas aparecerão na busca e com que rapidez. Esse limite se compõe da capacidade técnica do servidor e do interesse do mecanismo de busca no seu conteúdo. Os dois componentes podem ser captados, medidos e desenvolvidos.

Vimos quatro métodos que, juntos, formam um ciclo completo. A auditoria de logs dá o quadro objetivo: para onde o robô realmente vai e onde o orçamento vaza. A eliminação dos devoradores - facetas, parâmetros, duplicatas, redirecionamentos, soft 404 - libera recurso. A arquitetura e os sinais de prioridade direcionam o recurso liberado para páginas valiosas, via profundidade de cliques, interlinking e frescor honesto. A performance e o monitoramento elevam o teto técnico e impedem que os problemas voltem. Os cases mostraram que, com o número de requisições do robô inalterado, é possível quadruplicar a proporção de rastreamentos úteis e reduzir o tempo de indexação de páginas novas de semanas para horas.

O que fazer agora? Propomos um plano concreto para o primeiro mês.

1. Semana 1. Exporte os logs de 30 a 60 dias, filtre os robôs confirmados, classifique as URLs e monte a matriz dos quatro quadrantes. Em paralelo, capture as métricas atuais dos painéis de webmasters como linha de base.
2. Semana 2. Elimine os vazamentos simples: cadeias de redirecionamento, links internos quebrados, duplicatas técnicas de endereço. Inclua as faixas dos robôs na whitelist da proteção. Verifique o tempo de resposta ao robô e configure o cache de HTML.
3. Semana 3. Resolva parâmetros e facetas: defina as combinações valiosas e elimine as demais de aparecerem em links. Limite a paginação e os espaços infinitos. Verifique se o conteúdo crítico e os links estão presentes no HTML original.
4. Semana 4. Reforce a arquitetura: reduza a profundidade de cliques para páginas valiosas, adicione blocos de interlinking e novidades, configure Last-Modified e respostas 304. Inicie o monitoramento automático: métricas diárias dos logs, status semanais dos painéis, verificação da presença de páginas-chave no índice por meio de um pool de proxies móveis com targeting regional.

Oito semanas após o início, compare os logs com a linha de base. Se a participação de páginas valiosas nas requisições do robô cresceu e o tempo para páginas novas entrarem no índice diminuiu, o sistema está funcionando. Se não, volte à matriz de quadrantes: quase sempre haverá uma fonte de vazamento não contabilizada.

O crawl budget é um raro exemplo de recurso em SEO que está totalmente sob o seu controle. Você não pode obrigar o mecanismo de busca a amar o seu site. Mas pode fazer com que cada visita dele seja gasta com o máximo de proveito. Em 2026, quando o índice ficou seletivo e a concorrência pela atenção do robô aumentou, isso já não é higiene técnica, mas vantagem competitiva. Salve este guia, volte aos checklists daqui a um trimestre e certifique-se de que o seu fiscal passa o tempo nos corredores das lojas, e não nos depósitos.