robots.txtを正式な仕様へ

25年にも渡り、Robots Exclusion Protocol(以下：REP)はWeb上での最も基本的かつ大事な要素の1つでした。サイトオーナーは、Webクローラー等の自動クライアントに対して、サイト内の部分的なところや全体的なところでアクセスを制限したりすることが可能です。
1994年にMartijn Koster(彼自身もウェブマスター)氏がWebクローラーからの負荷を回避すべく、自分自身のサイト向けに開発した仕様が最初でした。その後、他のウェブマスターからも追加要件やフィードバックを経てREPは生まれ、各検索エンジンにも利用されるようになり、結果的に様々なサイトオーナーがREPを使うことで、サーバーリソースを管理しやすくなりました。
しかし、REPは公式なインターネット標準(IETF)として機能していませんでした。つまり、サイト運用者側は長年に渡りこのRFPをそれぞれの解釈で、それぞれちょっと違って解釈していたりしました。また、だからといって、この微妙な認識違いをカバーするようなアップデートも今まで行われていませんでした。そのことで、サイト運用者には正しい表記ルールを理解することが難しくなっており、それが大きな課題でした。

そこで、私たちは、クローラーに対する制御を心配することなく、サイトオーナーや運用者がインターネットで素晴らしい体験を提供できるようにサポートしたいと思っています。元々のプロトコル作成者(Martijn Koster氏)や他のウェブマスター、検索エンジンと一緒になって、私たちは現代のWeb上でどのようにREPが使われているのか文書化し、インターネット標準(IETF)に提出しました。

提案したREPのドラフト版は、Googlebotや他の主要クローラーのrobots.txt利用ルール、またREPを使っている約5億のWebサイトを元に、20年以上もの実績値を反映した内容となっています。この非常に細かな制御方法によって、どの部分をクロールさせ、どんな潜在ユーザーに表示させたいかを、サイト運用者が決定しやすくなります。これは、1994年に作られた仕様書から特別な変更があるわけではなく、基本的にrobots.txtの読み込みと合致性について定義されていなかった内容を現代のWebに合わせて定義したという意味合いが強いです。
具体的には以下の通りです：

1. 全てのURIに基づく転送プロトコルはrobots.txtを使用して設定できます。例えば、今までのHTTPに限らず、FTPでもCoAPでも同じように使えます。
2. サイト運用者は、robots.txt内の500KiB分までを読み込まれるようにすること。こうして容量の最大値を定義することで、接続時間が長くならないようにし、また不必要なサーバー負担を軽減することができます。
3. 新規版の最大キャッシュ時間は24時間で、キャッシュディレクティブ値が利用可能な状態であれば、サイト運用者はいつでもrobots.txtの更新が出来るようになり、robots.txtのリクエストによるクローラーの負荷も軽減されます。例えばHTTPの場合、Cache-Controlヘッダーを使用してキャッシュ時間を設定することができます。
4. 今回の仕様では、サーバー障害によりrobots.txtがアクセスが出来なくなった場合でも、既に認識されたdisallowページは引き続き長時間クロールされないような仕様になるよう設計しています。

さらに、拡張版Backus–Naur formを使ってネット上のドラフトを更新し、サイト運用者が列を読み込むのに重要なrobots.txtの構文をより明確に定義しました。

RFC(Request for Comments)は文字通り、コメント募集で、インターネットの基本要素を気にするサイト運用者からフィードバックをもらえるよう、IETFにドラフトをアップロードしました。Googlebotが読み込む適切な情報量、ひいては検索に表示されるページ量がどれくらいか、Googleが正しく理解できるためにサイト運用者の方々のご意見も承っています。
＜以下略＞

引用）Webmaster Central Blogより意訳