Como identificar um cliente automatizado: User-Agent, endereço de contato, regras de robots e etiqueta de limite de taxa

Objetivo

Ser um cliente automatizado que o operador de um site consiga identificar em uma linha de log, contatar quando algo der errado e controlar pelos mecanismos que já existem, em vez de um cliente indistinguível de abuso e bloqueado por completo.

Pré-requisitos

Controle sobre os cabeçalhos HTTP que o cliente envia e sobre a sua taxa de requisições. Uma página que descreva o que o cliente faz e como falar com o seu operador.

Passos

1. Envie um User-Agent em todas as requisições, com um token de produto, uma versão e um link para a página de descrição, por exemplo Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html). A RFC 9309 usa exatamente esse formato e diz que a string de identificação deve descrever a finalidade do crawler; a RFC 9110 define o cabeçalho como uma sequência de identificadores de produto, com o mais importante primeiro, e desaconselha detalhes desnecessariamente minuciosos.
2. Escolha o token de produto de modo que ele possa aparecer em uma linha user-agent do robots.txt: a RFC 9309 o restringe a letras, sublinhados e hifens e diz que ele deve ser uma substring do cabeçalho User-Agent. Assim, com ExampleBot no cabeçalho, o operador pode escrever user-agent: ExampleBot e se dirigir somente ao seu cliente.
3. Antes de buscar páginas de um site, leia /robots.txt e aplique o grupo cujo token corresponda ao seu, sem diferenciar maiúsculas de minúsculas; se nenhum corresponder, aplique o grupo *; se não houver nenhum, o acesso é irrestrito. Compare os caminhos a partir do primeiro octeto e use a regra mais específica, como a RFC exige dos crawlers.
4. Não disfarce o cliente de navegador para contornar uma regra; se um site bloquear o seu token, a resposta é contatar o operador pelo endereço que você publicou, e não trocar de cabeçalho.
5. Trate 429 Too Many Requests (RFC 6585) como uma instrução: pare, espere pelo menos o valor de Retry-After, se houver um (a RFC 9110 permite segundos ou uma data HTTP), e então retome com uma taxa menor. Aplique o mesmo a 503 com Retry-After.
6. Mantenha um orçamento por host, mais baixo para sites pequenos: poucas conexões simultâneas e uma pausa entre requisições ao mesmo host. Use cache para o que já foi buscado e requisições condicionais, para que leituras repetidas não custem nada ao operador.
7. Envie um cabeçalho Accept que corresponda ao que você consegue processar e prefira os formatos para máquinas que o site oferece (feeds, sitemaps, uma API, llms.txt) a rastrear HTML.

Resultado esperado

Suas requisições aparecem nos logs de acesso sob um único nome reconhecível, com um endereço de contato que funciona; um operador que queira reduzir seu ritmo ou barrá-lo consegue isso com uma linha no robots.txt ou com respostas 429, sem nunca precisar bloquear uma faixa de endereços que também atende outras pessoas.

Limites e base de verificação

Isto é etiqueta e uma síntese de padrões, não uma análise jurídica; os termos do site e a lei local são questões à parte. A RFC 9309 trata de crawlers que leem páginas públicas; uma API que você chama com uma chave tem limites próprios, documentados, que prevalecem.

Rastreamento ou busca acionada pelo usuário

A RFC 9309 se aplica a crawlers. Distinga dois casos no cliente: um rastreamento (seguir links, montar um índice, coletar material de treinamento) obedece ao robots.txt sem exceção e se identifica com um token de crawler; uma busca acionada pelo usuário (uma única página, porque uma pessoa pediu naquele momento) se identifica com um token que deixe isso claro, busca apenas aquela página, não segue links, não guarda o conteúdo além da sessão e não o usa para treinamento. Vários grandes operadores publicam tokens separados para os dois casos; um operador que bloqueou crawlers normalmente decidiu sobre o rastreamento, não sobre um único leitor agindo em nome de uma pessoa. Quando um site bloqueia também o token de busca do usuário, essa decisão igualmente deve ser respeitada.