2019 年 7 月 1 日（月曜日）
Robots Exclusion Protocol（REP）は、25 年にわたり、ウェブに関する最も基本的かつ重要な要素でした。ウェブサイトの所有者は、自動ウェブ クライアント（ウェブクローラなど）からサイトへのアクセスを部分的にまたは完全に除外できます。
1994 年、自身もウェブマスターである Martijn Koster は、クローラによってサイトに過剰な負荷が生じる状態になった後、最初の標準を策定しました。他のウェブマスターからの情報も取り入れて REP が誕生し、ウェブサイトの所有者がサーバー リソースを簡単に管理できるよう検索エンジンによって採用されました。
しかし、REP は正式なインターネット標準に進化することはありませんでした。これは、デベロッパーがこのプロトコルについて長年にわたり異なる解釈をしてきたことを表します。リリース以来、この REP は今日の重要な課題に対応できるように更新されてはいません。曖昧な事実上の業界標準によってルールを正しく記述することが困難であったため、ウェブサイトの所有者にとってこれは困難な問題です。
ウェブサイトの所有者とデベロッパーが、クローラの制御方法について懸念する必要なく、インターネット上の優れたエクスペリエンスを実現できるようにしたいと考えていました。Google は、プロトコルの元の作成者、ウェブマスター、他の検索エンジンとともに、REP が最新のウェブでどのように使用されるかを記録し、IETF に提出しました。
提案された REP の草案は、Googlebot や他の主要なクローラだけでなく、REP を使用する約 5 億ものウェブサイトで使用されている、20 年を超える期間にわたる robots.txt ルールの実践経験を反映したものです。こうした詳細な制御により、パブリッシャーはクロールの対象や関心のあるユーザーに対する表示内容を決定できます。1994 年に作成されたルールは変更されませんが、robots.txt の解析とマッチングに関する未定義のシナリオが基本的に定義され、最新のウェブに拡張されます。次の点に注目してください。
- 任意の URI ベースの転送プロトコルで robots.txt を使用できます。たとえば、HTTP に限定されず、FTP や CoAP でも使用できます。
- デベロッパーは、robots.txt の最初の 500 KiB 以上を解析する必要があります。最大ファイルサイズを定義すると、接続を長時間開く必要がなくなり、サーバーに対して生じる不必要な負荷を軽減できます。
- 24 時間の新しいキャッシュ保存時間またはキャッシュ ディレクティブ値（使用可能な場合）により、ウェブサイトの所有者は必要に応じて随時 robots.txt を柔軟に更新でき、クローラは robots.txt リクエストによってウェブサイトに対して過剰な負荷をかけることがなくなります。たとえば、HTTP の場合は、キャッシュ保存時間を判断するために Cache-Control ヘッダーを使用できます。
- この仕様では、以前アクセスできた robots.txt ファイルがサーバー障害によりアクセス不能になった場合に、許可されていないページをクロールしても相応の期間クロールしないという仕様を規定しています。
また、インターネット ドラフトで Augmented Backus-Naur Form を更新し、robots.txt の構文をより明確に定義しました。これは、デベロッパーが行を解析するための重要な要素です。
RFC は Request for Comments の略です。Google は IETF にドラフトをアップロードして、インターネットの基本構成要素に関心のあるデベロッパーからのフィードバックを求めました。Google は、Googlebot 向けに提供する情報や Google 検索での表示に必要な情報をウェブ クリエイターの方から Google にお知らせいただけるようにすることに取り組んでいます。これは適切な形で実現する必要があります。
ご意見やご質問がございましたら、Twitter とウェブマスター コミュニティからお寄せください。いずれもオフラインとオンラインの両方でご利用いただけます。