Identificar a un cliente automatizado: User-Agent, dirección de contacto, reglas de robots y buenas prácticas de límite de frecuencia

Objetivo

Ser un cliente automatizado que el operador de un sitio pueda identificar en una línea de registro, contactar cuando algo falla y controlar mediante los mecanismos que ya existen, en lugar de uno que no se distingue de un abuso y acaba bloqueado por completo.

Requisitos previos

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

Pasos

1. Envía un User-Agent en cada petición con un token de producto, una versión y un enlace a la página de descripción, por ejemplo Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html). El RFC 9309 usa exactamente este formato y indica que la cadena de identificación debería describir la finalidad del rastreador; el RFC 9110 define la cabecera como una secuencia de identificadores de producto, con el más significativo primero, y desaconseja el detalle innecesariamente fino.
2. Elige el token de producto de modo que pueda aparecer en una línea user-agent de robots.txt: el RFC 9309 lo limita a letras, guiones bajos y guiones, y dice que debería ser una subcadena de la cabecera User-Agent. Así, con ExampleBot en la cabecera, el operador puede escribir user-agent: ExampleBot y dirigirse únicamente a tu cliente.
3. Antes de descargar páginas de un sitio, lee /robots.txt y aplica el grupo cuyo token coincida con el tuyo sin distinguir mayúsculas de minúsculas; si ninguno coincide, aplica el grupo *; si tampoco existe, el acceso no tiene restricciones. Compara las rutas desde el primer octeto y usa la regla más específica, como el RFC exige a los rastreadores.
4. No disfraces el cliente de navegador para eludir una regla; si un sitio bloquea tu token, la respuesta correcta es contactar con el operador mediante la dirección que has publicado, no cambiar de cabecera.
5. Trata 429 Too Many Requests (RFC 6585) como una instrucción: detente, espera al menos el valor de Retry-After si se indica (el RFC 9110 admite segundos o una fecha HTTP) y reanuda con una frecuencia menor. Aplica lo mismo a 503 con Retry-After.
6. Mantén un presupuesto por host, más reducido en sitios pequeños: pocas conexiones simultáneas y una pausa entre peticiones al mismo host. Guarda en cache lo que descargues y usa peticiones condicionales para que las lecturas repetidas no le cuesten nada al operador.
7. Envía una cabecera Accept que se corresponda con lo que puedes procesar y prefiere los formatos legibles por máquina que ofrezca el sitio (feeds, sitemaps, una API, llms.txt) frente al rastreo de HTML.

Resultado esperado

Tus peticiones aparecen en los registros de acceso bajo un único nombre reconocible, con una dirección de contacto operativa; un operador que quiera ralentizarte o excluirte puede hacerlo con una línea en robots.txt o con respuestas 429, y nunca tiene que bloquear un rango de direcciones que también da servicio a otras personas.

Límites y base de verificación

Esto es una síntesis de buenas prácticas y estándares, no un análisis jurídico; los términos del sitio y la legislación local son cuestiones aparte. El RFC 9309 regula a los rastreadores que leen páginas públicas; una API que usas con una clave tiene sus propios límites documentados, que prevalecen.

Rastreo o descarga iniciada por el usuario

El RFC 9309 se limita a los rastreadores. En el cliente conviene distinguir dos casos: un rastreo (recorrer enlaces, construir un índice, reunir material de entrenamiento) obedece a robots.txt sin excepciones y se identifica con un token de rastreador; una descarga iniciada por el usuario (una sola página, porque una persona la ha pedido en ese momento) se identifica con un token que lo indique, descarga solo esa página, no sigue enlaces, no conserva el contenido más allá de la sesión y no lo usa para entrenamiento. Varios operadores grandes publican tokens distintos para cada caso; un operador que ha prohibido los rastreadores normalmente ha decidido sobre el rastreo, no sobre un lector individual que actúa en nombre de una persona. Si un sitio bloquea también el token de descarga del usuario, esa decisión se respeta igualmente.