O arquivo robots.txt é uma das ferramentas mais antigas e poderosas no arsenal de um webmaster. Localizado na raiz de cada domínio, este arquivo de texto simples diz aos crawlers quais partes do seu site eles podem acessar e quais devem deixar em paz. Apesar de sua simplicidade, o robots.txt também é um dos arquivos mais frequentemente mal configurados na web. Uma única regra mal posicionada pode esconder um site inteiro dos mecanismos de busca ou expor seções que você pretendia manter privadas.

Este guia cobre tudo, desde a sintaxe fundamental até padrões avançados, para que você escreva regras de robots.txt com confiança.

Onde o robots.txt fica e como os crawlers o encontram

Todo crawler compatível, antes de solicitar qualquer outra URL em um domínio, busca o /robots.txt na raiz:

https://example.com/robots.txt

Regras importantes sobre o arquivo em si:

• Deve ser servido no caminho exato /robots.txt — não /Robots.txt, nem dentro de um subdiretório.
• Deve retornar um código de status 200 com o tipo de conteúdo text/plain. Se o servidor retornar um 404, os crawlers assumem que tudo é permitido. Um erro 5xx faz com que a maioria dos crawlers pause o rastreamento até que o arquivo fique disponível.
• O arquivo se aplica por origem (esquema + host + porta). Uma regra em https://example.com/robots.txt não governa https://blog.example.com ou http://example.com.
• O tamanho máximo do arquivo respeitado pelo Google é de 500 KiB. Qualquer coisa além desse limite é ignorada.

Sintaxe básica

Um arquivo robots.txt é composto por um ou mais grupos de regras. Cada grupo começa com uma ou mais linhas User-agent, seguidas por diretivas Disallow e/ou Allow:

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

A linha User-agent especifica a qual crawler as regras seguintes se aplicam. O caractere curinga * corresponde a qualquer crawler que não tenha seu próprio bloco específico. Os crawlers se associam ao bloco de User-agent mais específico disponível. Se ambos User-agent: * e User-agent: Googlebot existirem, o Googlebot usa apenas o bloco específico do Googlebot e ignora completamente o bloco curinga.

Disallow

Disallow: /path/ diz ao crawler correspondente para não acessar nenhuma URL que comece com /path/. Um Disallow: vazio (sem caminho) significa que nada é proibido — equivalente a acesso total.

Allow

Allow: /path/ permite explicitamente o acesso a URLs que correspondem ao padrão, mesmo que uma regra Disallow mais ampla as bloqueie. Isso é essencial para criar exceções.

Wildcards e correspondência de padrões

A especificação original do robots.txt de 1994 não incluía wildcards, mas Google, Bing e a maioria dos crawlers modernos suportam dois caracteres importantes de correspondência de padrões:

O asterisco: *

Corresponde a qualquer sequência de caracteres (incluindo uma string vazia). Exemplos:

• Disallow: /*.pdf — bloqueia todas as URLs que contêm .pdf em qualquer lugar do caminho.
• Disallow: /directory/*/page — bloqueia URLs como /directory/anything/page.

O cifrão: $

Ancora a correspondência ao final da URL. Sem $, os padrões correspondem como prefixos. Exemplos:

• Disallow: /*.pdf$ — bloqueia URLs que terminam com .pdf, mas permite /file.pdf?view=1 (porque a URL não termina em .pdf).
• Allow: /page$ — permite exatamente /page, mas não /page/subpage ou /page?q=1.

Allow vs Disallow: qual prevalece?

Quando uma URL corresponde tanto a uma regra Allow quanto a uma Disallow, a resolução depende da especificidade (comprimento do caminho). A implementação do Google segue esta lógica:

1. A regra com o caminho correspondente mais longo prevalece.
2. Se ambas as regras têm o mesmo comprimento, Allow tem precedência.

Exemplo:

User-agent: *
Disallow: /directory/
Allow: /directory/public/

Aqui, /directory/public/page.html é permitido porque /directory/public/ (20 caracteres) é mais longo que /directory/ (11 caracteres). Mas /directory/secret.html permanece bloqueado.

Esta é uma fonte comum de confusão. Sempre teste suas regras com um testador de robots.txt para confirmar o resultado para URLs específicas.

A diretiva Crawl-delay

Crawl-delay solicita que o crawler espere um número especificado de segundos entre requisições sucessivas:

User-agent: Bingbot
Crawl-delay: 10

Observações importantes:

• O Google ignora Crawl-delay completamente. Para controlar a taxa de rastreamento do Googlebot, use a configuração de Taxa de Rastreamento no Google Search Console.
• O Bing respeita. Um valor de 10 significa que o Bingbot esperará 10 segundos entre requisições.
• Yandex, Baidu e alguns outros crawlers também o respeitam, embora as implementações variem.
• Definir um valor excessivamente alto (ex.: 60) efetivamente interrompe o rastreamento. Use isso com moderação e apenas quando seu servidor genuinamente não suporta a carga.

A diretiva Sitemap

Você pode declarar sitemaps diretamente no robots.txt:

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

Pontos-chave:

• A diretiva Sitemap não está vinculada a nenhum bloco User-agent. Coloque-a no topo ou no final do arquivo — ela se aplica globalmente.
• A URL deve ser totalmente qualificada (URL absoluta com esquema).
• Você pode listar múltiplos sitemaps.
• Esta é uma dica de descoberta, não uma garantia. Enviar sitemaps através do Search Console ou Bing Webmaster Tools é mais confiável.

Erros comuns que quebram o rastreamento

1. Bloquear CSS e JavaScript

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

Mecanismos de busca modernos renderizam páginas para avaliar conteúdo e layout. Se você bloquear os recursos necessários para renderização, o crawler vê uma página quebrada — e pode rebaixá-la ou ignorá-la. Bloqueie apenas recursos que são genuinamente irrelevantes para a renderização de conteúdo público.

2. Usar Disallow para manter páginas fora do índice

Disallow impede o rastreamento, não a indexação. Se outras páginas linkam para uma URL bloqueada, o Google ainda pode indexá-la — apenas não terá conteúdo para exibir, resultando em uma listagem enigmática. Para realmente remover uma página do índice, use uma meta tag noindex ou cabeçalho X-Robots-Tag e permita que o crawler veja a página.

3. Esquecer a barra final

Disallow: /private   # bloqueia /private, /private.html, /privately, etc.
Disallow: /private/  # bloqueia apenas caminhos dentro do diretório /private/

O primeiro padrão é mais amplo do que a maioria das pessoas pretende. Sempre considere se você precisa da barra final.

4. Blocos wildcard e específicos conflitantes

Ter um bloco User-agent: * e um bloco específico de bot onde o bloco específico está vazio efetivamente dá ao bot acesso total — mesmo que o bloco curinga seja restritivo. Isso é por design, mas surpreende pessoas que assumem que as regras se acumulam.

5. Servir robots.txt atrás de um redirecionamento

Se /robots.txt retorna um 301 ou 302, a maioria dos crawlers seguirá o redirecionamento. No entanto, cadeias de redirecionamento, loops de redirecionamento ou redirecionamento para uma resposta que não seja text/plain farão com que os crawlers tratem o arquivo como indisponível. Mantenha simples: sirva o arquivo diretamente na raiz com uma resposta 200.

6. Não considerar crawlers de IA

Se seu robots.txt só tem um bloco User-agent: *, qualquer crawler de IA que você não bloqueou explicitamente terá o mesmo acesso que o Googlebot. Considere adicionar regras específicas para bots como GPTBot, ClaudeBot, PerplexityBot e Bytespider.

Testando seu robots.txt

Nunca implemente alterações no robots.txt sem testar. Ferramentas disponíveis incluem:

• Google Search Console — o Testador de robots.txt mostra como o Google interpreta suas regras para URLs específicas.
• Bing Webmaster Tools — funcionalidade de teste similar para o Bingbot.
• Spider.es — verifique quais crawlers (mecanismos de busca, bots de IA, ferramentas SEO) podem acessar qualquer URL do seu domínio, com a regra específica que controla cada veredicto.
• Ferramentas de linha de comando — bibliotecas como o urllib.robotparser do Python permitem automatizar testes em pipelines de CI/CD.

Um template sólido para começar

# Mecanismos de busca: acesso total
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /
Crawl-delay: 5

# Crawlers de IA: seletivo
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# Padrão: permitir com restrições
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

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

Adapte às suas necessidades. O princípio é simples: seja explícito sobre o que você permite, deliberado sobre o que bloqueia, e teste antes de implantar.

Considerações finais

O robots.txt é enganosamente simples. Algumas linhas de texto controlam se milhões de pessoas podem descobrir seu conteúdo através de mecanismos de busca e ferramentas de IA. Trate-o com o mesmo cuidado que dedica à configuração de segurança do seu site. Audite-o regularmente — especialmente à medida que novos crawlers de IA surgem — e use ferramentas como o Spider.es para verificar que sua política pretendida corresponde à realidade.