Formalização da especificação do protocolo de exclusão de robôs

Segunda-feira, 1º de julho de 2019

Há 25 anos, o protocolo de exclusão de robôs (REP, na sigla em inglês) é um dos componentes mais básicos e essenciais da Web. Ele permite que os proprietários de sites excluam clientes automatizados, como rastreadores da Web, de modo parcial ou completo.

Em 1994, o webmaster Martijn Koster criou o padrão inicial quando rastreadores estavam sobrecarregando o site dele. Com ajuda de outros webmasters, o REP nasceu e foi adotado por mecanismos de pesquisa para ajudar os proprietários de sites a gerenciar os recursos de servidores com mais facilidade.

No entanto, o REP nunca foi transformado em um padrão oficial da Internet, e os desenvolvedores interpretaram o protocolo de maneira diferente ao longo dos anos. Desde que foi criado, o REP não foi atualizado para abranger os casos atuais. Esse é um problema difícil para os proprietários de sites, porque o padrão ambíguo dificultava a criação de regras.

Nosso objetivo era ajudar proprietários de sites e desenvolvedores a criar experiências incríveis na Internet, em vez de se preocupar com o controle de rastreadores. Junto com o autor original do protocolo, dos webmasters e de outros mecanismos de pesquisa, documentamos como o REP é usado na Web moderna e o enviamos à IETF.

O rascunho proposto do REP reflete mais de 20 anos de experiência no mundo real com as regras de robots.txt usadas pelo Googlebot e por outros rastreadores importantes, além de cerca de meio bilhão de sites que usam o REP. Esses controles refinados permitem que o editor decida o que rastrear no site e possivelmente mostrar aos usuários interessados. Ele não muda as regras criadas em 1994, mas define essencialmente todos os cenários indefinidos de análise e correspondência de robots.txt e estende essas situações para a Web moderna. Em especial, os seguintes casos:

  1. Qualquer protocolo de transferência com base em URI pode usar o robots.txt. Por exemplo, não é mais limitado a HTTP e também pode ser usado para FTP ou CoAP.
  2. Os desenvolvedores precisam analisar pelo menos os primeiros 500 kibibytes de um robots.txt. Definir um tamanho máximo de arquivo garante que as conexões não fiquem abertas por muito tempo, o que diminui a pressão desnecessária nos servidores.
  3. Um novo tempo máximo de armazenamento em cache de 24 horas ou valor de diretiva de cache, se disponível, dá aos proprietários do site a flexibilidade de atualizar o robots.txt sempre que quiserem, e os rastreadores não sobrecarregam os sites com solicitações de robots.txt. Por exemplo, no caso do HTTP, os cabeçalhos Cache-Control podem ser usados para determinar o tempo de armazenamento em cache.
  4. Agora a especificação indica que, quando um arquivo robots.txt acessível anteriormente se torna inacessível devido a falhas do servidor, as páginas não permitidas conhecidas não sejam rastreadas por um período razoavelmente longo.

Além disso, atualizamos o formulário integrado Backus-Naur no rascunho da Internet para definir melhor a sintaxe do robots.txt, que é essencial para que os desenvolvedores analisem as linhas.

RFC é a sigla em inglês de "solicitação de comentários", ou seja: fizemos upload do rascunho para a IETF para receber feedback de desenvolvedores interessados nos elementos básicos da Internet. Estamos trabalhando para oferecer aos criadores de conteúdo da Web os controles necessários para informar a quantidade de informações que eles querem disponibilizar ao Googlebot e, por extensão, qualificar para exibição na Pesquisa. Precisamos fazer isso da melhor forma.

Se quiser enviar um comentário, fazer perguntas ou apenas conversar, fale com a gente pelo Twitter e na nossa Comunidade de webmasters, tanto off-line como on-line.