Resumen

  • El consenso de junio de 1994 eligió /robots.txt porque los servidores web existentes podían servirlo y un rastreador podía obtener la política en una sola petición HTTP.
  • El diseño intercambió una convención común y previsible por administración a escala del sitio y cumplimiento voluntario; una conversación de 1995 mostró que permiso, identidad del robot y frecuencia de acceso eran cuestiones distintas.

Un rastreador podía convertir un sitio pequeño en una carga inesperadamente grande. En su introducción, el documento de 1994 «A Standard for Robot Exclusion» recuerda quejas de 1993 y 1994: algunos robots solicitaban páginas con demasiada rapidez o las recuperaban repetidamente; otros recorrían árboles virtuales muy profundos, contenido duplicado o provisional y scripts CGI cuya invocación podía causar efectos secundarios. El problema no era la falta de páginas en la Web. Era que un robot que seguía enlaces podía cruzar los límites operativos de un servidor sin que su operador tuviera un modo compartido de decirle dónde detenerse.

La respuesta propuesta fue un archivo de texto sencillo en una ubicación fija. Antes de recorrer el sitio, el robot obtendría la URL local /robots.txt. Sus autores explicaron motivos prácticos: podía implantarse en servidores web existentes y permitía descubrir la política con una sola descarga. La raíz evitaba que cada robot tuviera que aprender una dirección distinta para cada sitio. El archivo podía nombrar a un robot o usar un comodín y, a continuación, indicar rutas URL que no debía solicitar. Era posible combinar reglas generales y excepciones en registros separados.

Esa sencillez situaba el control en el límite del sitio. El administrador del servidor podía publicar una política común para todo el host. El documento reconocía lo que se perdía: los responsables de cada documento no podían mantener directamente sus propias reglas en ese único archivo. Un proceso local podía reunir listas de varios equipos, pero la propuesta dejó ese mecanismo fuera de alcance. La comodidad de una única descarga implicaba, por tanto, una pregunta de autoridad interna: ¿quién podía decidir la política que afectaba a las páginas del sitio?

El estatus de la convención era deliberadamente limitado. El documento habla de un consenso del 30 de junio de 1994 entre la mayoría de los autores de robots y otras personas interesadas; también había estado abierto a discusión en la lista www-talk y se basaba en un borrador anterior. Pero aclaraba que no era un estándar oficial respaldado por un organismo, que nadie lo hacía cumplir y que no existía garantía de que todos los robots actuales o futuros lo utilizaran. Sus autores lo describieron como una prestación común ofrecida por la mayoría de los autores de robots. Era una oferta de coordinación, no una barrera técnica ante los archivos.

Un mensaje de mayo de 1995 en el archivo W3C de www-talk mostró otro límite. Kee Hinckley respondió que un archivo de permisos podía decirle al robot qué debía evitar, pero no ayudar al servidor a reconocer quién era el robot. También dijo que el archivo no se consultaba en cada visita, para espaciar las recuperaciones y reducir la carga, y que cualquier persona podía solicitarlo. Su nota es la explicación de un participante, no un estudio del comportamiento de todos los rastreadores. Aun así, distingue tres tareas fáciles de confundir: expresar la preferencia de un sitio, identificar al cliente y decidir cada cuánto vuelve.

Más adelante, el protocolo adquirió otro estatus institucional. RFC 9309, publicado como documento IETF Standards Track en septiembre de 2022, dice que especifica y amplía el método de Martijn Koster de 1994, y añade definiciones más claras, gestión de errores e instrucciones de caché. El RFC también delimita su alcance: pide a los rastreadores que respeten las reglas, pero estas no son una autorización de acceso. Pasar de una convención comunitaria a una norma no convirtió el archivo en autenticación ni en un mecanismo de ejecución.

La historia permite ver dónde puede residir una regla común. Un archivo único y previsible reducía el coste de participar tanto para los operadores de sitios como para quienes escribían robots. A cambio, el administrador quedaba como editor predeterminado y el cumplimiento descansaba en el cliente. Las fuentes documentan una decisión de diseño y una trayectoria posterior de normalización; no cuantifican cuántos sitios adoptaron el archivo, cuántas peticiones evitó ni cuánto trabajo ahorró.

Fuentes

  • Martijn Koster, «A Standard for Robot Exclusion», documento de consenso del 30 de junio de 1994, copia del proyecto de robots de WebCrawler: documento.
  • Kee Hinckley, «Re: Byte ranges (actually robots)», archivo W3C www-talk, 25 de mayo de 1995: mensaje.
  • IETF, RFC 9309, «Robots Exclusion Protocol», septiembre de 2022: RFC.