No dia 22 de julho de 2026, o Google reescreveu a documentação Optimize your crawl budget. O anúncio oficial tratou a mudança como ajuste de clareza, consistência terminológica e fluxo de leitura. A leitura linha a linha mostra outra coisa: três frases novas que mudam a forma correta de planejar performance de servidor, lançamento de site e presença em superfícies de IA.
A mais relevante delas não fala sobre indexação. Fala sobre disputa de recursos entre os robôs do próprio Google.
O que mudou de fato na documentação
A doc de crawl budget existe há anos e sempre foi tratada como assunto de site grande, coisa de e-commerce com cem mil URLs. A revisão de julho não altera esse recorte oficial, mas introduz definições que atingem qualquer site, de qualquer porte.
O que é crawl capacity limit
Crawl capacity limit é o teto de requisições simultâneas que o Google se permite fazer a um servidor sem degradar a experiência dos usuários daquele site. Ele é definido pela saúde do servidor, não pela vontade do site. Servidor rápido e estável eleva o teto. Lentidão, erros 5xx e timeouts derrubam o teto.
Sobre esse teto, o Google acrescentou uma afirmação que não existia na versão anterior: Every site starts with the same default, conservative crawl capacity limit
. Em português: todo site parte do mesmo limite padrão conservador, e os sistemas do Google elevam esse limite ao longo do tempo apenas se houver demanda real de rastreamento e o site continuar saudável.
O ponto crítico: a capacidade é compartilhada entre todos os crawlers
A segunda inserção é a mais importante do documento inteiro. O Google explicita que cada crawler tem uma demanda de rastreamento própria, porém o limite de capacidade é compartilhado entre todos eles. Demanda alta de um crawler reduz a capacidade disponível para os demais.
Isso significa que a frota inteira do Google divide o mesmo cano. Googlebot para busca orgânica, Googlebot-Image, Googlebot-News, GoogleOther e os agentes ligados aos produtos generativos consomem do mesmo orçamento de requisições que o servidor consegue absorver.
Vale uma precisão técnica que a maior parte do mercado erra: Google-Extended não é um crawler. É um token de controle usado no robots.txt para autorizar ou bloquear o uso do conteúdo em produtos generativos. A coleta em si continua sendo feita pelos user agents já existentes. Ou seja, não existe um “orçamento separado de IA” para negociar. Existe um orçamento único, e o conteúdo que alimenta resposta gerada compete pelo mesmo recurso que a indexação clássica.
A consequência prática do limite compartilhado
Em um servidor lento, o rastreamento para superfícies de IA e o rastreamento para indexação orgânica canibalizam um ao outro. Não é possível ganhar presença em resposta gerada sacrificando performance de infraestrutura, porque ambos consomem o mesmo teto de capacidade definido pela saúde do servidor.
Durante os últimos dois anos, performance de servidor foi discutida quase exclusivamente pela ótica de Core Web Vitals, ou seja, experiência do usuário e ranqueamento. A revisão de julho move o tema para outro lugar. Tempo de resposta agora é pré-requisito de elegibilidade para ser citado, porque conteúdo não coletado não entra em resposta alguma.
Site novo não tem crédito acumulado
A terceira inserção reorganiza o playbook de lançamento. Se todo site começa no mesmo patamar conservador, publicar duzentas URLs no dia da estreia não acelera nada. O efeito é o oposto: dilui um orçamento pequeno entre páginas de importância comercial muito desigual.
A sequência correta em um lançamento B2B é outra:
Framework de lançamento sob limite conservador
1. Núcleo comercial primeiro. Home, páginas de serviço, páginas de solução e contato. É o conjunto que precisa ser descoberto, renderizado e indexado nas primeiras semanas.
2. Infraestrutura antes do volume. Servidor com TTFB baixo, cache de página ativo, sitemap limpo, zero URLs de teste e nenhum redirecionamento em cadeia.
3. Conteúdo em ondas. Clusters editoriais liberados em blocos ao longo dos meses seguintes, acompanhando a elevação natural do teto de capacidade.
4. Poda contínua. Parâmetros de URL, paginação infinita, filtros combinatórios e páginas de baixa qualidade drenam orçamento sem devolver nada.
A arquitetura em ondas já era a prática recomendada por razões editoriais e de autoridade temática. A partir desta atualização, ela ganha justificativa documentada pelo próprio Google.
A ação técnica com maior retorno: responder 304 Not Modified
Entre as linhas novas, o Google passou a recomendar de forma explícita o suporte a requisições condicionais. Quando uma página não mudou desde a última coleta, devolver o status 304 informa ao robô que a versão em cache continua válida, o que economiza banda e processamento do servidor. Menos recurso gasto em revisita significa mais teto disponível para descoberta de conteúdo novo.
Aqui existe trabalho real, porque a maior parte dos sites WordPress em produção falha nesse ponto. O WordPress não envia cabeçalhos Last-Modified e ETag consistentes em páginas HTML geradas por PHP, e vários plugins de cache mal configurados enviam no-cache no documento principal.
Diagnóstico em trinta segundos
curl -sI https://dominio.com.br/pagina/ | grep -iE 'last-modified|etag|cache-control'
curl -sI -H 'If-Modified-Since: Tue, 21 Jul 2026 00:00:00 GMT' \
https://dominio.com.br/pagina/ | head -1Se a segunda linha não retornar HTTP/2 304, o site está reentregando o documento inteiro a cada revisita, consumindo capacidade que poderia estar sendo usada para rastrear páginas novas.
Tabela de diagnóstico
Sinal técnico, impacto no orçamento de rastreamento e correção
Sinal observado Impacto no crawl budget Correção TTFB acima de 600 ms Rebaixa o teto de capacidade para toda a frota de crawlers Cache de página em disco, PHP 8.3, OPcache, revisão de plugins Ausência de Last-Modified em HTML Impede requisição condicional, cada revisita custa a página inteira Emitir Last-Modified com base na data de modificação do conteúdo Erros 5xx intermitentes Redução imediata e automática da taxa de rastreamento Monitoramento de uptime e revisão de limites de recursos no host URLs com parâmetros indexáveis Consome orçamento em variações sem valor comercial Canonical, robots.txt e revisão de filtros de navegação Cadeias de redirecionamento Multiplica requisições por URL de destino Redirecionamento em salto único para o destino final
Implementação em WordPress
Antes de escrever qualquer código, verifique o cache de página. Configurações que servem HTML estático direto pelo servidor, como LiteSpeed Cache com LSCache ativo ou FastCGI cache no Nginx, já resolvem cabeçalhos condicionais na camada correta. Só faz sentido tratar em PHP quando o site entrega HTML dinâmico.
add_action('template_redirect', function () {
if (is_admin() || is_user_logged_in() || is_404() || !is_singular()) {
return;
}
$post = get_queried_object();
if (!$post instanceof WP_Post) {
return;
}
$modified = strtotime($post->post_modified_gmt . ' GMT');
header('Last-Modified: ' . gmdate('D, d M Y H:i:s', $modified) . ' GMT');
$since = isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])
? strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'])
: false;
if ($since && $since >= $modified) {
status_header(304);
exit;
}
}, 1);Duas ressalvas obrigatórias. A data de modificação do post não reflete alterações em elementos dinâmicos da página, como blocos de posts relacionados ou comentários, então o snippet não deve ser aplicado em templates que dependem desses elementos para estar atualizados. E em sites com WooCommerce, carrinho, checkout e minha conta precisam ficar fora da regra.
O que isso muda
A atualização não introduz um fator de ranqueamento novo. Ela torna explícita uma dependência que já existia e que quase ninguém estava tratando: infraestrutura é o limite superior de tudo o que vem depois. Conteúdo excelente em servidor lento é conteúdo parcialmente invisível, tanto para o índice orgânico quanto para as superfícies que geram resposta.
Para empresas B2B com sites institucionais de cinquenta a duzentas páginas, o roteiro imediato é curto: medir TTFB real, testar resposta condicional, eliminar cadeias de redirecionamento e revisar o que está no sitemap sem merecer estar. É um trabalho de poucas horas com efeito composto sobre todo o resto da estratégia.
Se você quer entender o próximo estágio dessa discussão, o de tornar o site legível não só para crawlers mas para agentes autônomos, vale a leitura do nosso material sobre Agent Readiness Score.
Auditoria técnica de rastreamento
A Safira é uma agência remota nacional de performance digital B2B, eleita TOP 11 agências de web design do Brasil pela Hostinger, com atuação em WordPress, SEO técnico, GEO, Google Ads e geração de leads B2B. A auditoria de crawl budget faz parte do nosso diagnóstico técnico padrão.
Fale com a Safira no WhatsApp e receba um diagnóstico técnico do rastreamento do seu site.
