Como ler um ficheiro robots.txt: um guia completo

A nossa posição: somos a Geonode e vendemos proxies a pessoas que recolhem dados, pelo que o robots.txt se situa diretamente no centro do trabalho dos nossos clientes. A verdade é que respeitar este ficheiro é do seu interesse, não apenas do site. Um rastreador que respeite o ficheiro, se identifique e regule o seu ritmo é um rastreador que os operadores do site podem optar por permitir. Um rastreador que o ignore é um incómodo a ser bloqueado, e o bloqueio é barato para eles e caro para si. Também queremos deixar claro o que a própria norma diz sobre o assunto: a RFC afirma claramente que estas regras «não constituem uma forma de autorização de acesso» — por isso, respeitar o ficheiro «robots.txt» é necessário, mas não suficiente, e os termos de serviço são uma questão à parte.

O que é e o que não é o ficheiro robots.txt

A própria definição da RFC é a mais clara que existe:

Pode ser inconveniente para os proprietários de serviços que os rastreadores visitem a totalidade do seu espaço de URIs. Este documento especifica as regras originalmente definidas pelo «Protocolo de Exclusão de Robôs» que os rastreadores devem respeitar ao aceder a URIs.

Estas regras não constituem uma forma de autorização de acesso.

Esta última frase tem um duplo significado. Significa que um caminho não permitido não está protegido — nada impõe a aplicação da regra — e significa que um caminho permitido não está, por isso, autorizado, porque a permissão decorre de termos e da lei, e não de um ficheiro de texto.

A secção sobre segurança torna a primeira parte explícita e vale a pena citá-la, porque muitas pessoas interpretam-na ao contrário:

O Protocolo de Exclusão de Robôs não substitui medidas válidas de segurança de conteúdos. Listar caminhos no ficheiro robots.txt expõe-nos publicamente e, assim, torna-os detetáveis.

Assim, Disallow: /admin/secret-reports/ informa ao mundo que esse caminho existe. Se estiver a escrever um ficheiro «robots.txt», esse é um argumento para não incluir de todo caminhos sensíveis nele — utilize a autenticação, tal como recomendado explicitamente pela RFC.

O formato

Um ficheiro é uma sequência de grupos. Cada grupo começa com uma ou mais linhas «user-agent» e é seguido por regras.

User-agent: *
Disallow: /admin/
Disallow: /search?
Allow: /search/help

User-agent: BadBot
Disallow: /

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

Três caracteres especiais que os rastreadores DEVEM suportar:

Um grupo vazio no final tem significado: o RFC refere que «o último grupo pode não ter regras, o que significa que permite implicitamente tudo». Assim, um User-agent: quxbot no final, sem nada abaixo dele, concede a esse rastreador acesso irrestrito.

Um Disallow: vazio sem caminho também significa que tudo é permitido — é a forma convencional de dizer «sem restrições».

Sitemap: não faz parte da gramática principal. A ABNF na RFC inclui uma nota aos implementadores para «definirem linhas adicionais de que necessitem (por exemplo, Sitemaps)», pelo que se trata de uma extensão amplamente suportada, em vez de uma funcionalidade obrigatória. Crawl-delay está na mesma categoria: comum, respeitada por muitos rastreadores e não incluída na norma.

Como funciona a correspondência do User-Agent

É mais específico do que a maioria das pessoas pensa, e vale a pena compreender bem.

O token é uma substring do seu cabeçalho User-Agent. O exemplo da RFC: um cabeçalho de Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html) corresponde a uma linha robots.txt de user-agent: ExampleBot, e refere que «o token do produto (ExampleBot) é uma substring do cabeçalho HTTP User-Agent».

A correspondência não distingue maiúsculas de minúsculas. «Os rastreadores DEVEM utilizar a correspondência insensível a maiúsculas e minúsculas para encontrar o grupo que corresponda ao token do produto e, em seguida, obedecer às regras desse grupo.»

Os grupos de correspondência múltiplos são fundidos. «Se houver mais do que um grupo que corresponda ao user-agent, as regras dos grupos correspondentes DEVEM ser combinadas num único grupo.» Assim, dois blocos «User-agent: ExampleBot» separados no mesmo ficheiro produzem um conjunto de regras combinado, em vez de o segundo substituir o primeiro.

O resultado é um único grupo, não vários. Se um grupo corresponder ao seu token, deve utilizar esse grupo e ignorar completamente o grupo «*» — o curinga é um recurso de fallback, não uma base à qual regras específicas se adicionam. Isto surpreende as pessoas: um rastreador com o seu próprio grupo não está também sujeito às regras gerais.

E se nada corresponder: «Se nenhum grupo corresponder ao token do produto e não houver nenhum grupo com uma linha user-agent com o valor *, ou se não houver grupos presentes, nenhuma regra se aplica.»

A correspondência baseia-se na especificidade, não na ordem

A regra mais frequentemente interpretada de forma errada em toda esta área.

Para avaliar se o acesso a um URI é permitido, um rastreador DEVE comparar os caminhos nas regras «allow» e «disallow» com o URI. A correspondência DEVE ter em conta maiúsculas e minúsculas. A correspondência DEVE começar pelo primeiro octeto do caminho. DEVE ser utilizada a correspondência mais específica encontrada. A correspondência mais específica é aquela que tem o maior número de octetos.

Não é a primeira correspondência que prevalece. Não é a última correspondência que prevalece. A correspondência mais longa prevalece.

O próprio exemplo da RFC:

User-Agent: foobot
Allow: /example/page/
Disallow: /example/page/disallowed.gif

Para example.com/example/page/disallowed.gif, a linha Disallow é mais longa, pelo que se aplica — apesar de aparecer em segundo lugar e apesar de uma regra Allow abranger o caminho pai.

Inverta a ordem no ficheiro e nada muda. A ordem é irrelevante.

Duas regras adicionais completam o quadro. Em caso de empate, prevalece a regra «Allow»: «Se uma regra de «permissão» e uma regra de «proibição» forem equivalentes, então a regra de «permissão» DEVE ser utilizada.» E a ausência de correspondência significa permissão: «Se não for encontrada nenhuma correspondência entre as regras de um grupo para um agente de utilizador correspondente ou se não houver regras no grupo, o URI é permitido.»

Mais um pormenor que vale a pena saber: «O URI /robots.txt é implicitamente permitido», pelo que um ficheiro que proíbe tudo não se proíbe a si próprio.

A correspondência de percursos também envolve a normalização por codificação percentual. Os octetos fora do ASCII e aqueles no intervalo reservado «DEVEM ser codificados em percentagem» antes da comparação, e um octeto ASCII codificado em percentagem na URI «DEVE ser descodificado antes da comparação», a menos que seja reservado. Na prática: utilize uma biblioteca atualizada em vez de escrever isto por si próprio.

Os códigos de estado mudam tudo

As regras aqui são precisas, frequentemente ignoradas, e a diferença entre duas delas é significativa.

Sucesso. «Se o rastreador descarregar com sucesso o ficheiro robots.txt, o rastreador DEVE seguir as regras analisáveis.»

Redirecionamentos. «Os rastreadores DEVEM seguir pelo menos cinco redirecionamentos consecutivos, mesmo entre autoridades.» Um ficheiro acedido através de cinco redirecionamentos «DEVE ser obtido, analisado e as suas regras seguidas no contexto da autoridade inicial». Para além de cinco, um rastreador «PODE assumir que o ficheiro robots.txt não está disponível.»

Indisponível — 4xx. «Se um código de estado do servidor indicar que o ficheiro robots.txt está indisponível para o rastreador, então o rastreador PODE aceder a quaisquer recursos no servidor.» Um código 404 significa que não há restrições.

Inacessível — 5xx. Este é o que as pessoas costumam interpretar mal: «Se o ficheiro robots.txt estiver inacessível devido a erros do servidor ou da rede, isso significa que o ficheiro robots.txt está indefinido e o rastreador DEVE assumir uma proibição total.»

Um código 5xx significa parar completamente. Não «continuar como antes», nem «utilizar a cópia em cache indefinidamente» — proibição total. O RFC permite, no entanto, uma solução a longo prazo: se o ficheiro estiver indefinido «durante um período de tempo razoavelmente longo (por exemplo, 30 dias), os rastreadores PODEM assumir que o ficheiro robots.txt está indisponível... ou continuar a utilizar uma cópia em cache.»

Erros de análise. «Os rastreadores DEVEM tentar analisar cada linha do ficheiro robots.txt. Os rastreadores DEVEM utilizar as regras que possam ser analisadas.» Uma linha malformada não invalida o ficheiro; utiliza-se o que for possível ler.

A implicação prática para quem estiver a escrever um rastreador: uma indisponibilidade temporária no destino deve interromper o rastreio, não acelerá-lo. Entender isto ao contrário significa sobrecarregar um site que já está com dificuldades.

Armazenamento em cache e limites

Dois requisitos operacionais que costumam apanhar de surpresa as implementações desenvolvidas internamente.

Atualizar, pelo menos, diariamente. «Os rastreadores PODEM armazenar em cache o conteúdo do ficheiro robots.txt obtido... Os rastreadores NÃO DEVEM utilizar a versão em cache por mais de 24 horas, a menos que o ficheiro robots.txt esteja inacessível.»

Recolher o ficheiro uma única vez quando o rastreador arranca e mantê-lo ativo durante uma semana não está em conformidade. Os sites alteram as suas regras, e uma tarefa de longa duração precisa de detetar essas alterações.

Analisar pelo menos 500 KiB. «O limite de análise DEVE ser de, pelo menos, 500 kibibytes.» Os sites de grande dimensão têm ficheiros de grande dimensão, e um analisador que trunque num tamanho arbitrariamente menor irá ignorar regras silenciosamente — o que constitui o pior modo de falha possível neste contexto, porque resulta num rastreador que acredita estar em conformidade, quando na verdade não está.

Ler um ficheiro real

Análise de um exemplo realista.

User-agent: *
Disallow: /search
Allow: /search/about
Disallow: /*?sessionid=
Disallow: /*.pdf$
Crawl-delay: 2

User-agent: GPTBot
Disallow: /

User-agent: PartnerBot
Disallow:

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

Linha a linha:

**Disallow: /search

** bloqueia /search

, /search/

, /search/results

— qualquer coisa que comece com essa cadeia de caracteres, uma vez que a correspondência começa no primeiro octeto e não existe $

.

**Allow: /search/about

** é mais longo, pelo que prevalece para esse caminho específico. A correspondência mais longa, e não a ordem.

**Disallow: /*?sessionid=

** utiliza o curinga para bloquear qualquer caminho que contenha um parâmetro de sessão, independentemente do que o preceda.

**Disallow: /*.pdf$

** bloqueia URLs que terminam em .pdf

. Sem o $

, também bloquearia /report.pdf.html

.

**Crawl-delay: 2

** é uma extensão e não um padrão, e respeitá-la é uma boa prática.

**User-agent: GPTBot

com Disallow: /

** exclui totalmente esse rastreador. Note-se que o GPTBot recebe apenas esta regra — não está também sujeito ao grupo *

, pelo que o Crawl-delay

acima não se aplica a ele.

**User-agent: PartnerBot

com um Disallow:

vazio** concede acesso ilimitado.

**Sitemap:

** aponta para o inventário de URLs, que é a linha mais útil de imediato na maioria dos ficheiros. Abordámos o que fazer com ela em como encontrar todas as páginas de um site.

Respeitar isso no código

Utilize um analisador sintático atualizado. A regra de correspondência de especificidade, por si só, é uma fonte comum de erros, e a normalização por codificação percentual é ainda pior.

Python: urllib.robotparser está na biblioteca padrão e é adequado para casos simples; o analisador de código aberto do Google robotstxt e as suas ligações para Python implementam a RFC 9309 com precisão. O Scrapy tem RobotsTxtMiddleware integrado e ativado por predefinição em novos projetos — verifique se ninguém o desativou.

Node: existem vários pacotes mantidos que implementam a norma.

Go: existem bibliotecas que seguem as regras de correspondência da RFC.

Seja qual for a sua escolha, certifique-se de que cumpre estes quatro pontos:

Atualize a cada 24 horas, e não apenas uma vez no arranque. Trate os códigos 5xx como proibição total e os 404 como ausência de restrições. Faça a correspondência com o token real do seu produto e certifique-se de que o cabeçalho User-Agent o contém. Siga até cinco redirecionamentos, aplicando as regras no contexto do host original.

E um quinto ponto que não consta do RFC, mas que é igualmente importante: registe o que ignoraste. Um rastreador que exclui silenciosamente metade de um site devido a uma regra que não esperavas é aquele em que os dados em falta são descobertos semanas mais tarde por alguém que questiona por que razão um relatório parece estar errado.

O que o ficheiro robots.txt não abrange

Vale a pena ser explícito, porque as pessoas tendem a interpretar mal o seu conteúdo, tanto num sentido como noutro.

Não diz nada sobre o que pode fazer com os dados que recolher. Os direitos de autor, os direitos sobre bases de dados e os termos de serviço aplicam-se de forma independente.

Não se trata de uma autorização. O RFC afirma-o diretamente. Um caminho permitido é aquele que o site não pediu aos rastreadores para evitar, o que não é o mesmo que consentimento para a recolha em massa.

Não existe um limite de frequência na norma. Crawl-delay é uma extensão. Ser educado é da sua responsabilidade.

Não distingue finalidades. Um ficheiro não pode indicar «indexação sim, treino de IA não» na sintaxe padrão, embora muitos sites agora se aproximem disso ao nomear tokens específicos para rastreadores de IA. O quadro da UE relativo à mineração de texto e dados contempla reservas de direitos legíveis por máquina, e os mecanismos para as expressar ainda estão a ser definidos.

Não pode impedir ninguém. Trata-se de um pedido. A aplicação consiste na limitação de taxa, no bloqueio e em processos legais — o que constitui a razão prática para que o operador opte por permitir esse rastreador, em vez de ter de o impedir.

Perguntas frequentes

O ficheiro robots.txt é juridicamente vinculativo?

Por si só, não. A RFC 9309 estabelece que as suas regras «não constituem uma forma de autorização de acesso» — trata-se de um pedido que se solicita aos rastreadores que respeitem. As obrigações legais decorrem dos termos de serviço, dos direitos de autor, dos direitos sobre bases de dados e da legislação específica de cada jurisdição, sendo que todas estas se aplicam independentemente do que o ficheiro indique.

As regras do ficheiro robots.txt são comparadas por ordem?

Não, e este é o erro mais comum a este respeito. A especificação exige que «a correspondência mais específica encontrada DEVE ser utilizada», sendo que «mais específica» significa o maior número de octetos. A correspondência mais longa prevalece, a ordem é irrelevante e, em caso de empate, aplica-se o princípio «Allow».

O que acontece se o ficheiro robots.txt devolver um erro 404?

O ficheiro está «indisponível» e a RFC indica que o rastreador «PODE aceder a quaisquer recursos no servidor». A ausência de ficheiro significa que não há restrições. Isto é diferente de um erro do servidor.

E se o robots.txt devolver um código 500?

O ficheiro está «inacessível» e indefinido, e o rastreador «DEVE assumir uma proibição total». Um erro de servidor significa parar completamente, não continuar. Após um longo período — a RFC sugere 30 dias —, um rastreador pode tratá-lo como indisponível ou continuar a utilizar uma cópia em cache.

Com que frequência devo consultar o ficheiro robots.txt?

Pelo menos a cada 24 horas. O RFC afirma que os rastreadores «NÃO DEVEM utilizar a versão em cache por mais de 24 horas, a menos que o ficheiro robots.txt esteja inacessível». Consultar o ficheiro uma vez no arranque e mantê-lo ativo durante uma semana não está em conformidade.

Um grupo específico de user-agents substitui o grupo «wildcard»?

Sim, substitui-o. Se um grupo indicar o token do seu produto, deve seguir esse grupo e ignorar completamente o grupo «*» — as regras específicas não se somam às gerais. Dois grupos que indiquem o mesmo token são fundidos num único.

O que significam «*» e «$» no ficheiro robots.txt?

«*» corresponde a zero ou mais caracteres quaisquer, e «$» marca o fim do padrão de correspondência. Ambos são caracteres que os rastreadores DEVEM suportar. «Disallow: /*.pdf$» bloqueia URLs que terminam em «.pdf»; sem o «$», também bloquearia «/file.pdf.html».

Posso usar o robots.txt para ocultar páginas confidenciais?

Não, e fazê-lo só piora a situação. A secção de segurança da RFC refere que «listar caminhos no ficheiro robots.txt expõe-nos publicamente e, assim, torna-os detetáveis». Qualquer pessoa pode ler o ficheiro. Utilize a autenticação, que a especificação recomenda explicitamente em vez disso.

Conclusão: O «

robots.txt» é curto, padronizado e frequentemente implementado de forma errada. Três regras são responsáveis pela maioria dos erros.

A correspondência mais longa prevalece, não a primeira nem a última. Um «Disallow» mais abaixo no ficheiro pode substituir um «Allow» acima dele e vice-versa, apenas com base no comprimento. Um código 5xx significa proibição total, o que é o oposto do que uma implementação intuitiva faz — um site com problemas deve receber menos tráfego da sua parte, não a mesma quantidade. E o ficheiro deve ser atualizado pelo menos diariamente, porque os sites mudam de opinião e uma cópia em cache com uma semana não está em conformidade.

Utilize um analisador mantido em vez de criar o seu próprio, certifique-se de que o seu cabeçalho User-Agent contém efetivamente o token que espera que seja correspondido e registe o que ignorou, para que a falta de dados seja uma decisão e não uma surpresa.

E tenha sempre em conta a própria advertência da norma. Estas regras «não constituem uma forma de autorização de acesso» — respeitá-las torna o seu rastreador num operador com quem se pode conviver, mas não resolve as questões separadas sobre o que os termos permitem e o que pode fazer com o que recolhe.