Cómo se identifica un cliente automatizado: User-Agent, dirección de contacto, robots.txt y límites de frecuencia

Objetivo

Un cliente automatizado que el operador pueda reconocer en una línea de log, contactar cuando haya problemas y controlar con los medios disponibles, en lugar de un cliente indistinguible de un abuso y bloqueado de forma indiscriminada.

Requisitos previos

Control sobre las cabeceras HTTP enviadas y sobre la frecuencia de las peticiones. Una página que describa qué hace el cliente y cómo contactar con su operador.

Pasos

1. Enviar en cada petición un User-Agent con token de producto, versión y enlace a la página descriptiva, por ejemplo Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html). El RFC 9309 usa exactamente este formato y exige que el identificador describa la finalidad del rastreador; el RFC 9110 define la cabecera como una secuencia de identificadores de producto, el más importante primero, y desaconseja incluir detalles innecesariamente finos.
2. Elegir el token de producto de modo que pueda aparecer en una línea user-agent de robots.txt: el RFC 9309 solo permite letras, guiones bajos y guiones, y exige que el token sea una subcadena de la cabecera User-Agent. Así, un operador puede dirigirse exactamente a este cliente con user-agent: ExampleBot.
3. Antes de descargar páginas de un sitio, leer /robots.txt y aplicar el grupo cuyo token coincida con el propio sin distinguir mayúsculas de minúsculas; si no hay coincidencia, se aplica el grupo *; si tampoco existe, el acceso no tiene restricciones. Comparar las rutas a partir del primer octeto y aplicar la regla más específica, como el RFC exige a los rastreadores.
4. No hacer pasar nunca al cliente por un navegador para eludir una regla; si un sitio bloquea el token, el camino es contactar por la dirección publicada, no cambiar de cabecera.
5. Tratar 429 Too Many Requests (RFC 6585) como una instrucción: detenerse, esperar como mínimo el tiempo indicado en Retry-After (el RFC 9110 admite segundos o una fecha HTTP) y continuar después con una frecuencia menor. Lo mismo vale para 503 con Retry-After.
6. Llevar un presupuesto por host: pocas conexiones simultáneas y una pausa entre peticiones al mismo host, más generosa en sitios pequeños. Guardar en cache lo descargado y usar peticiones condicionales, para que las lecturas repetidas no le cuesten nada al operador.
7. Enviar una cabecera Accept acorde con lo que se puede procesar y preferir los formatos pensados para máquinas (feeds, sitemaps, una API, llms.txt) al rastreo de HTML.

Resultado esperado

Las peticiones aparecen en los logs de acceso con un nombre reconocible y una dirección de contacto que funciona; un operador que quiera frenar o excluir al cliente puede hacerlo con una línea en robots.txt o con respuestas 429, y nunca tiene que bloquear un rango de direcciones que afecte también a otros.

Límites y base de verificación

Se trata de buenas prácticas y de un resumen de estándares, no de una valoración jurídica; los términos de uso y la legislación local son cuestiones aparte. El RFC 9309 regula los rastreadores en páginas públicas; una API utilizada con clave tiene sus propios límites documentados, que prevalecen.