要約

  • 1994年6月のロボット作者間の合意は、既存のWebサーバーで提供でき、HTTPで一度取得すれば見つかる /robots.txt を採用した。
  • 共通の予測可能な規則と引き換えに、管理はサイト単位となり、遵守は任意のままだった。1995年の議論は、許可の提示、ロボットの識別、アクセス間隔が別の問題であることを示した。

クローラーは、小さなサイトにも予想外の負荷をもたらし得る。1994年の文書「A Standard for Robot Exclusion」は、1993年から94年に寄せられた苦情を紹介する。リクエストを短時間に連発したり、同じファイルを何度も取得したりするロボットがいた。深い仮想ディレクトリー、重複または一時的な情報、取得によって投票のような副作用を起こすCGIスクリプトへ進むロボットもあった。問題はWebにページが多すぎることそのものではない。リンクをたどるプログラムがサーバーの運用上の境界を越えても、管理者が停止場所を共通の方法で伝えられなかったことだ。

提案された解決策は、決まった場所に置く単純なテキストファイルだった。サイトを巡回する前に、ロボットはローカルURL /robots.txt を取得する。既存のWebサーバーに実装しやすく、文書を一つ取得するだけで規則を見つけられる、というのが作者の説明だった。ルートに置けば、サイトごとに別の発見先をロボットへ教える必要もない。ファイルには特定のロボット名またはワイルドカードと、取得してはならないURLパスを書ける。通常ルールと例外は、別のグループに分けて記述できた。

この簡潔さは、制御の置き場をサイト境界に定めた。サーバー管理者はホスト全体に適用する一つの方針を公開できる。文書はその代償も明記している。一つのファイルを個々の文書の管理者がそれぞれ直接編集することはできない。複数のリストをまとめるローカルな仕組みは考えられるが、仕様の対象外だった。一回の取得で済む便利さは、組織の内側で誰がクローラー方針を決めるのかという問いを残した。

共通ルールの位置づけも明確だった。原文は、1994年6月30日に多数のロボット作者と関係者の間で合意に達し、www-talkでも議論が可能で、前の作業草案を土台にしたと記す。その一方、標準化団体や企業が支える公式規格ではなく、強制機関もなく、すべてのロボットが使う保証もないと断っていた。作者たちはこれを、多数のロボット作者がWebコミュニティに提供する共通の仕組みと説明した。ファイルを物理的に遮断する仕掛けではなく、協調の申し出だった。

1995年5月のW3C www-talkアーカイブにあるメールは、別の境界を浮かび上がらせる。Kee Hinckleyは、権限を示すファイルで「どこへ行かないか」は伝えられても、サーバーが誰のアクセスかを見分けることはできないと返答した。また、負荷を抑えるため毎回取得されるわけではなく、間隔も空けられ、一般の人もファイルを取得できると述べた。これは一人の参加者の説明であり、すべてのクローラーの行動を測った調査ではない。それでも、サイトの希望を示すこと、クライアントを識別すること、次の訪問時刻を決めることが別の仕事だと分かる。

その後、プロトコルは別の制度的地位を得た。IETFのRFC 9309は2022年9月のStandards Track文書として、Martijn Kosterが1994年に定義した方法を規定・拡張し、用語、エラー処理、キャッシュの説明を加えた。さらに、そのルールはクローラーに尊重を求めるもので、アクセス認可ではないと明言する。コミュニティの慣行が標準になっても、認証や強制の仕組みに変わったわけではない。

この歴史は、共通ルールをどこに置くかを示す。予測しやすい一つのファイルは、サイト運営者にもロボット作者にも参加コストを下げた。その代わり、管理者が既定の編集者となり、遵守はクライアントに委ねられた。資料が示すのは設計上の選択と後年の標準化であり、採用サイト数、阻止したリクエスト数、削減した負荷ではない。

出典

  • Martijn Koster, “A Standard for Robot Exclusion,” 1994年6月30日付の合意文書、WebCrawler robotsプロジェクトの保存版：文書。
  • Kee Hinckley, “Re: Byte ranges (actually robots),” W3C www-talkアーカイブ、1995年5月25日：メール。
  • IETF, RFC 9309, “Robots Exclusion Protocol,” 2022年9月：RFC。