Robots.txtの標準化仕様が(今さら)提出される

みんな知ってるし使ってるRobots.txtですが、実は今まで標準仕様というものが存在せず、みんななんとなくで運用されてきました。
しかしこれではさすがに困るよってことで、初出から25年経った今になってついにというかようやくというか、RFCが提出されました。
ちなみにRFCの最初に書かれてるMartijn Kosterは、Robots.txtを最初に考えた人です。

ということで以下は対象のRFC、Robots Exclusion Protocolの日本語訳です。

Robots Exclusion Protocol

Abstract

この文書は、Martijn Kosterが1996年に定義したRobots Exclusion Protocolを標準化し、拡張したものです。
サービス所有者が自分のコンテンツに対し、クローラと呼ばれる自動アクセスクライアントからのアクセスを制御する方法を提供します。

1. Introduction

この文書は、RFC3986で定義されているURIによってアクセスできるリソースを提供するサービスにアクセスするクライアントに対して適用されます。
たとえばHTTPは、ブラウザがWebページのコンテンツ表示するクライアントです。

クローラは自動化されたクライアントです。
たとえば検索エンジンは、RFC8288で定義されているように、索引付けのため再帰的にリンクを辿るクローラを所有しています。

クローラがURI空間にアクセスすると、サービス所有者にとっては不便になる可能性があります。
このドキュメントは、クローラがURIにアクセスするときに従わなければならない(MUST)規則を定義します。

この規則は、認可形式ではありません。

1.1. Terminology

キーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY"、"OPTIONAL"はBCP 14、RFC2119、RFC8174としての意味で解釈されます。

2. Specification

2.1. Protocol definition

このプロトコル言語は、ルールとグループで構成されます。

Rule：クローラがURIにアクセスする方法を定義する、キーと値のペアで構成される行。The Allow and Disallow linesを参照のこと。

Group：1つ以上のRule行が後に続く、ユーザエージェントを記載した行。グループは、ユーザエージェント行もしくはファイル終端で区切られます。"User-agent line"を参照のこと。最後のグループはルールを含まなくてもかまわず、その場合は暗黙的に全てを許可します。

2.2. Formal syntax

以下の書式はRFC5234で定義される拡張バッカス・ナウア記法(ABNF)で表記されます。

robotstxt = *(group / emptyline)
group = startgroupline                ; グループをユーザエージェント行で開始
       *(startgroupline / emptyline) ; ユーザエージェント行を複数行配置可能
                                     ; 
       *(rule / emptyline)           ; そのUAに対するルール
                                     ; 

startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL

rule = *WS ("allow" / "disallow") *WS ":"
      *WS (path-pattern / empty-pattern) EOL

; 任意の追加行を登録可能。
; パーサは理解できないところは寛容に読み飛ばすこと。

product-token = identifier / "*"
path-pattern = "/" *(UTF8-char-noctl) ; 有効なURIパターン
empty-pattern = *WS

identifier = 1*(%x2d / %x41-5a / %x5f / %x61-7a)
comment = "#"*(UTF8-char-noctl / WS / "#")
emptyline = EOL EOL = *WS [comment] NL ; 末尾コメントをつけてもいい(MAY)
NL = %x0D / %x0A / %x0D.0A
WS = %x20 / %x09

; RFC3629で定義されたUTF8のうち、制御文字以外を使用可能

UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-noctl = %x21 / %x22 / %x24-7F ; Ctrl、スペース、#
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
        %xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
        %xF4 %x80-8F 2( UTF8-tail )

UTF8-tail = %x80-BF

2.2.1. The user-agent line

クローラは自分の所属するグループを表すために製品トークンを設定します。
製品トークンに使用できる文字は"a-zA-Z_-"だけ(MUST)です。
クローラは、サービスを使用する際に識別用に製品トークンを送信しなければなりません(SHOULD)。
たとえばHTTPの場合、製品トークンはuser-agentヘッダに含める必要があります(SHOULD)。

HTTP header	robots.txtのuser-agent line
user-agent: Mozilla/5.0 (compatible;ExampleBot/0.1;https://www.example.com/bot.html)	user-agent:ExampleBot

クローラは製品トークンが一致するグループを見つけ、そしてそのグループのルールに従わなければなりません(MUST)。
ユーザエージェントに合致するグループが複数ある場合、ルールをひとつにまとめなければなりません(MUST)。
このマッチングにおいて大文字小文字は区別されません(MUST)。
一致するグループが存在しない場合、クローラは"*"のユーザエージェントで指定された最初のグループに従わなければなりません(MUST)。
いずれの条件にも当てはまらなかった場合、あるいはグループが全く存在しなかった場合、ルールは何もありません。

2.2.2. The Allow and Disallow lines

ルールの行は、対応するパスと一致するURIへのアクセスが許可されているか否かを示します。
URIへのアクセスが許可されていることを確認するために、ロボットはURIが許可リストもしくは拒否リストに入っていないかチェックします(MUST)。
このマッチングにおいて大文字小文字は区別されます(SHOULD)。
見つかったうちで最も正確に一致した対象を使わなければなりません(MUST)。

同じ詳細度で許可と不許可が両方ある場合、許可されます(SHOULD)。
グループ内に一致するルールが見つからない、あるいはグループ内にルールがない場合、URIは許可されます。
/robots.txtは暗黙的に許可されます。

robots.txtのパスは、US-ASCIIコードの範囲外の文字列はRFC3986で定義されているパーセントエンコードでなければなりません(MUST)。

US-ASCIIコードの文字列が見つかった場合、それがRFC3986で予約されていないかぎり、比較する前にエンコードしてはいけません(MUST)。
差異が見つかる前に行の終端に達した場合にのみ、その行に一致したと見做されます。

以下は例です。

Path	エンコード表記	マッチング文字列
/foo/bar?baz=quz	/foo/bar?baz=quz	/foo/bar?baz=quz
/foo/bar?baz=http://foo.bar	/foo/bar?baz=http%3A%2F%2Ffoo.bar	/foo/bar?baz=http%3A%2F%2Ffoo.bar
/foo/bar/U+E38384	/foo/bar/%E3%83%84	/foo/bar/%E3%83%84
/foo/bar/%E3%83%84	/foo/bar/%E3%83%84	/foo/bar/%E3%83%84
/foo/bar/%62%61%7A	/foo/bar/%62%61%7A	/foo/bar/baz

最初のユーザエージェント行の前にあるルールなど、どのグループにも属していない規則については、クローラは無視します(SHOULD)。

2.2.3. Special characters

クローラは、以下の特殊文字を解釈する必要があります(SHOULD)。

Character	解説	例
#	コメント	allow: / # ここはコメント #この行は全てコメント
$	行末を表す	allow:/this/path/exactly$
*	0文字以上の文字列	allow:/this/*/exactly

URIが特殊文字と一致する場合、クローラはパーセントエンコードを使用すべきです(SHOULD)。

パターン	URI
/path/file-with-a-%2A.html	https://www.example.com/path/file-with-a-*.html
/path/foo-%24	https://www.example.com/path/foo-$

2.2.4. Other records

クライアントは、robots.txtプロトコルに含まれないレコードを解釈してもかまいません(MAY)。
たとえばsitemapなどがあります。

2.3. Access method

robots.txtはサービスの最上位パスに配置し、全て小文字の"/robots.txt"でアクセス可能でなければなりません(MUST)。
文字コードはRFC3629で定義されているUTF-8でなければなりません(MUST)。
メディアタイプはRFC2046で定義されている"text/plain"でなければなりません(MUST)。

RFC3986に従うと、robots.txtのURIは以下のようになります。

"scheme:[//authority]/robots.txt"

たとえば、HTTP、FTPでのURIは以下のとおりです。

http://www.example.com/robots.txt
https://www.example.com/robots.txt
ftp://ftp.example.com/robots.txt

2.3.1. Access results

クローラがrobots.txtを正常にダウンロードできた場合、クローラは規則に従わなければなりません(MUST)。

robots.txtへのリクエストに対し、サーバはHTTP 301 / 302リダイレクトを返すことがあります。
クローラは、RFC1945で定義されているとおり、最低5回はリダイレクト要求に従う必要があります(SHOULD)。

5回以内にrobots.txtに到達できた場合は、そのファイルを解析し、その規則に従わなければなりません(MUST)。
5回で到達できなかった場合、クローラはrobots.txtを使用できないと解釈してもかまいません(MAY)。

robots.txtが利用不能である場合もあります。
たとえばHTTPでは、400から499のステータスコードは利用不能を表します。
robots.txtに対して利用不能であるステータスコードが帰ってきた場合、クローラはあらゆるファイルにアクセス可能(MAY)です。
または24時間以内のキャッシュがあればそれを使用することもできます(MAY)。

サーバエラーやネットワークエラーによりrobots.txtにアクセスできない場合、クローラは完全に不許可であると想定しなければなりません(MUST)。
たとえばHTTPでは、500から599のステータスコードは到達不能を表します。
それ以外の未定義のステータスコードである場合も、クローラはrobots.txtが到達不能であると想定しなければなりません(MUST)。
かなりの長期間(たとえば30日)robots.txtに到達不能である場合、クライアントはrobots.txtが到達不能であると扱ってもよい(MAY)し、キャッシュを使い続けることも可能です(MAY)。

パースエラーがある場合でも、クローラはrobots.txtを行ごとに解析しなければなりません(SHOULD)。
クローラは解析できた規則は使用しなければなりません(MUST)。

2.4. Caching

クローラは、取得したrobots.txtをキャッシュすることができます(MAY)。
RFC2616で定義されている標準のキャッシュ制御を使用できます(MAY)。
robots.txtが到達不能である場合を除き、24時間を超えてキャッシュを使用することはできません(SHOULD NOT)。

2.5. Limits

クローラは、少なくとも500KiBのrobots.txtに対応しなければなりません(MUST)。

2.6. Security Considerations

Robots Exclusion Protocolを、セキュリティ対策として使用してはいけません(MUST NOT)。
robots.txtにURIを載せると、そのURIは公開されるため、検出が可能になります。

2.7. IANA Considerations

IANAのアクションは特にありません。

3. Examples

3.1. Simple example

以下に簡潔な例を示します。

・foobot：一般的なケースです。単独のユーザエージェントトークンと、それに続くルール。
・barbot/bazbot：ひとつ以上のユーザエージェントをグループ化可能。
・quxbot：ファイルの終わりには空の規則を指定可能。

User-Agent : foobot
Disallow : /example/page.html
Disallow : /example/disallowed.gif

User-Agent : barbot
User-Agent : bazbot
Allow : /example/page.html
Disallow : /example/disallowed.gif

User-Agent: quxbot

3.2. Longest Match

2つの規則にひっかかる場合、最も長くマッチするものを使用しなければなりません(MUST)。
以下の例では、example.com/example/page/disallow.gifにアクセスしてきた場合は、/example/page/disallowed.gifの規則が適用されます(MUST)。

User-Agent : foobot
Allow : /example/page/
Disallow : /example/page/disallowed.gif

Author's Address

Martijn Koster
Stalworthy Manor Farm
Suton Lane, NR18 9JG
Wymondham, Norfolk
United Kingdom
Email: [e-mail]

Gary Illyes
Brandschenkestrasse 110
8002, Zurich
Switzerland
Email: [e-mail]

Henner Zeller
1600 Amphitheatre Pkwy
Mountain View, CA 94043
USA
Email: [e-mail]

Lizzi Harvey
1600 Amphitheatre Pkwy
Mountain View, CA 94043
USA
Email: [e-mail]

感想

使う側としては現状の書き方は変わらないので、特に意識して何かを変更したりする必要は特にありません。

この仕様が必要になるのは、パーサやクローラを書いている側です。
もっとも、この手のパーサを一から書くのも大変です。
Googleがパーサを公開しているので、必要があればこちらを使用しましょう。

日本語記事

Google、REP（ロボット排除プロトコル）のWeb標準化に乗り出す / ITMedia
Googleがウェブサイト管理に欠かせない「robots.txt」のインターネット標準化を推進 / Gigazine