Кратко

  • Июньский консенсус авторов роботов 1994 года выбрал /robots.txt, потому что существующие веб-серверы могли отдавать этот файл, а роботу хватало одного HTTP-запроса, чтобы найти правила.
  • Общая предсказуемая схема потребовала управления на уровне сайта и добровольного соблюдения; дискуссия 1995 года показала, что разрешения, идентификация робота и интервалы обхода — разные задачи.

Робот мог неожиданно нагрузить даже небольшой сайт. Во введении документа 1994 года «A Standard for Robot Exclusion» упоминаются жалобы 1993–1994 годов: некоторые роботы запрашивали страницы слишком часто или снова загружали одни и те же файлы; другие уходили в глубокие виртуальные деревья, к дублирующейся или временной информации и к CGI-сценариям, обращение к которым могло иметь побочные эффекты. Проблема была не в избытке страниц в Сети. Программа, переходившая по ссылкам, могла выйти за операционные границы сервера, а у владельца сайта не было общего способа сказать ей, где остановиться.

Предложенное решение — простой текстовый файл по фиксированному адресу. Перед обходом сайта робот должен был запросить локальный URL /robots.txt. Авторы объяснили выбор практическими причинами: механизм можно было реализовать на существовавшем веб-сервере, а робот находил политику за одно получение документа. Размещение в корне также избавляло от необходимости сообщать каждому роботу отдельный адрес для каждого сайта. В файле можно было назвать конкретного робота или использовать символ-заполнитель, а затем перечислить пути, которые не следует запрашивать. Общие правила и исключения помещались в разные группы.

Простота перенесла точку управления на границу сайта. Администратор сервера мог опубликовать одну политику для всего узла. Документ честно обозначал ограничение: владельцы отдельных документов не могли самостоятельно вести свои правила в этом едином файле. Локальный процесс мог бы собрать несколько списков в один, но способ такой сборки оставался за пределами предложения. Поэтому удобство единственного запроса сопровождалось вопросом о полномочиях внутри организации: кто вправе задавать правила обхода для всего сайта?

Статус договоренности был столь же определенным. Документ сообщает о консенсусе от 30 июня 1994 года между большинством авторов роботов и другими заинтересованными лицами; его также обсуждали в списке www-talk, а основу составлял предыдущий рабочий черновик. При этом текст подчеркивал, что это не официальный стандарт организации по стандартизации, его никто не обеспечивает принудительно, и нет гарантии, что его будут использовать все нынешние и будущие роботы. Авторы называли его общим механизмом, который большинство создателей роботов предлагает веб-сообществу. Это предложение координации, а не техническая преграда перед файлами.

Сообщение в архиве W3C www-talk за май 1995 года выявило другую границу. Кий Хинкли ответил, что файл разрешений может сказать роботу, куда не следует ходить, но не позволяет серверу распознать самого робота. Он также указал, что файл не запрашивают при каждом визите: более редкие обращения уменьшают нагрузку, а получить его может и обычный пользователь. Это свидетельство одного участника, а не измерение поведения всех роботов. Но оно разделяет три легко смешиваемые задачи: сообщить пожелание сайта, идентифицировать клиента и определить частоту его возвращений.

Позднее протокол получил иной институциональный статус. RFC 9309, опубликованный в сентябре 2022 года как документ IETF Standards Track, говорит, что определяет и расширяет метод, впервые описанный Мартейном Костером в 1994 году, добавляя уточнения, обработку ошибок и правила кэширования. RFC также проводит границу: роботам предлагается соблюдать правила, но это не форма разрешения на доступ. Переход от сообщества к стандарту не превратил файл в механизм аутентификации или принуждения.

Эта история показывает, где может находиться общее правило. Один предсказуемый файл снизил стоимость участия для администраторов сайтов и авторов роботов. Обратной стороной стало то, что администратор оказался редактором по умолчанию, а соблюдение зависело от клиента. Источники документируют проектное решение и последующую стандартизацию, но не сообщают, сколько сайтов приняли файл, сколько запросов он предотвратил и какую нагрузку сэкономил.

Источники

  • Мартейн Костер, “A Standard for Robot Exclusion”, документ консенсуса от 30 июня 1994 года, архивная копия проекта роботов WebCrawler: документ.
  • Кий Хинкли, “Re: Byte ranges (actually robots)”, архив W3C www-talk, 25 мая 1995 года: сообщение.
  • IETF, RFC 9309, “Robots Exclusion Protocol”, сентябрь 2022 года: RFC.