Como um cliente automatizado se identifica: User-Agent, contato, robots.txt e limites de taxa

Objetivo

Um cliente automatizado que o operador consiga reconhecer numa linha de log, contatar em caso de problemas e controlar com os meios existentes, em vez de um cliente indistinguível de abuso e bloqueado em bloco.

Pré-requisitos

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

Passos

1. Enviar em cada requisição um User-Agent com token de produto, versão e 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 esta forma e exige que o identificador descreva a finalidade do crawler; a RFC 9110 define o cabeçalho como uma sequência de identificadores de produto, o mais importante primeiro, e desaconselha detalhes desnecessariamente minuciosos.
2. Escolher o token de produto de modo que possa aparecer numa linha user-agent do robots.txt: a RFC 9309 permite apenas letras, sublinhados e hífenes e exige que o token seja uma substring do cabeçalho User-Agent. Assim, um operador pode atingir exatamente este cliente com user-agent: ExampleBot.
3. Antes de obter páginas de um site, ler /robots.txt e aplicar o grupo cujo token corresponda ao seu, sem diferenciar maiúsculas de minúsculas; se não houver correspondência, vale o grupo *; se este também faltar, o acesso é irrestrito. Comparar os caminhos a partir do primeiro octeto e aplicar a regra mais específica, como a RFC exige dos crawlers.
4. Nunca disfarçar o cliente de navegador para contornar uma regra; se um site bloquear o token, o caminho é contatar o endereço publicado, não trocar de cabeçalho.
5. Tratar 429 Too Many Requests (RFC 6585) como uma instrução: parar, esperar pelo menos o tempo indicado em Retry-After (a RFC 9110 permite segundos ou uma data HTTP) e depois retomar com uma taxa menor. O mesmo vale para 503 com Retry-After.
6. Manter um orçamento por host: poucas conexões simultâneas e uma pausa entre requisições ao mesmo host, com mais folga em sites pequenos. Guardar em cache o que foi obtido e usar requisições condicionais, para que leituras repetidas não custem nada ao operador.
7. Enviar um cabeçalho Accept que corresponda ao que o cliente consegue processar e preferir formatos legíveis por máquina (feeds, sitemaps, uma API, llms.txt) ao crawling de HTML.

Resultado esperado

As requisições aparecem nos logs de acesso sob um nome reconhecível, com um endereço de contato funcional; um operador que queira frear ou excluir o cliente pode fazê-lo com uma linha no robots.txt ou com respostas 429, sem nunca precisar bloquear uma faixa de endereços que atinja também outros.

Limites e base de verificação

É etiqueta e resumo de padrões, não um enquadramento jurídico; os termos de uso e a legislação local são questões à parte. A RFC 9309 regula crawlers em páginas públicas; uma API usada com chave tem limites próprios documentados, que prevalecem.