Guias de robots.txt

Crawl-delay no robots.txt: suporte do Google e alternativas

Veja o que Crawl-delay significa, por que o Googlebot não suporta a diretiva e como diagnosticar carga excessiva de rastreamento com segurança.

Por Robots.txt Tools Editorial TeamÚltima verificação em 2026-09-133 min de leitura
Crawl-delay no robots.txt: suporte do Google e alternativas

Crawl-delay aparece em muitos exemplos de robots.txt, mas é uma das diretivas mais confundidas. Para Google SEO, o ponto central é simples: o Googlebot não suporta Crawl-delay em robots.txt. Colocar um número de segundos não força o Googlebot a esperar esse intervalo.

Outros crawlers podem oferecer suporte como extensão própria. Portanto, consulte a documentação do operador do bot e não trate a linha como padrão universal.

Exemplo comum

User-agent: ExampleBot
Crawl-delay: 10

A intenção costuma ser pedir cerca de dez segundos entre requisições. Porém, o RFC 9309 padroniza o núcleo do Robots Exclusion Protocol; nem todo campo histórico faz parte de uma implementação comum.

Por que a diretiva pode gerar falsa segurança

Se você adiciona Crawl-delay durante um pico e o bot ignora a diretiva, nada muda. A causa real pode ser:

  • muitas URLs de filtros e facetas;
  • calendários, buscas ou parâmetros que geram espaços infinitos;
  • respostas 5xx provocando tentativas repetidas;
  • bots que não respeitam robots.txt;
  • um User-agent diferente daquele que está sendo limitado;
  • aplicação lenta, tornando caro um volume normal de requisições.

Comece pelos logs: User-agent, frequência, caminhos e status HTTP.

Não use 401 ou 403 para desacelerar o Googlebot

Se /robots.txt responder 401 ou 403, o Google trata a maioria desses 4xx — com exceção de 429 — como ausência de um robots.txt válido. Ou seja, ele pode assumir que não existem restrições.

HTTP/1.1 403 Forbidden

não é um controle de crawl rate e pode impedir a leitura das regras que você queria aplicar.

429 e 5xx são sinais diferentes

429 Too Many Requests e erros 5xx indicam sobrecarga/indisponibilidade e podem reduzir temporariamente o rastreamento. Não devem ser usados como substituto permanente de uma arquitetura saudável.

Corrija primeiro explosões de URL, restrinja apenas caminhos realmente desnecessários, melhore cache/capacidade e use controles específicos do provedor quando existirem.

Para caminhos desnecessários, use Disallow com cuidado

User-agent: *
Disallow: /busca-interna/
Disallow: /cart/
Disallow: /session/

Sitemap: https://example.com/sitemap.xml

Isso reduz solicitações às rotas em vez de espaçar todo o tráfego. Mas Disallow não equivale a noindex.

Em sites grandes, foque eficiência de rastreamento

Em e-commerce, marketplaces e portais, importa mais saber se o crawler chega às páginas canônicas importantes sem gastar recursos em combinações duplicadas. Analise filtros, ordenação, busca interna, IDs de sessão, preview e paginações de baixo valor.

Fluxo seguro de diagnóstico

  • identifique o crawler real nos logs;
  • confira suporte oficial a Crawl-delay;
  • meça volume e caminhos mais acessados;
  • investigue explosões de URL;
  • confira status, tamanho e encoding de /robots.txt;
  • confirme que páginas e recursos importantes continuam acessíveis;
  • procure padrões de 429 e 5xx;
  • teste a alteração com URLs reais;
  • monitore logs depois do deploy.

Para o Googlebot, a conclusão é direta: não dependa de Crawl-delay; corrija armadilhas de rastreamento e use mecanismos que o Google realmente suporta.

Guias relacionados