robots.txt ファイルの読み方：完全ガイド

当社の立場：当社はGeonodeであり、データ収集を行う方々にプロキシを販売しているため、robots.txtはお客様の業務のまさに中心に位置しています。 率直に言えば、このルールを順守することは、サイト運営者だけでなく、あなた自身の利益にもなるのです。 このファイルを尊重し、自身を識別し、適切なペースで動作するクローラーは、サイト運営者が許可することを選択できるものです。一方、これを無視するクローラーはブロックすべき迷惑な存在であり、ブロックすることは運営者にとっては安価ですが、あなたにとってはコストがかかります。 また、この件に関して標準規格自体が何を定めているかについても明確にしておきたい。RFCでは、これらのルールが「アクセス許可の一形態ではない」と明記されている。つまり、robots.txtを順守することは必要条件ではあるが十分条件ではなく、利用規約は別の問題である。

robots.txt とは何か、そして何ではないか

RFC自体の定義が最も明確です：

クローラーがURI空間全体を巡回することは、サービス所有者にとって不便な場合があります。本文書は、クローラーがURIにアクセスする際に遵守することが求められる、「Robots Exclusion Protocol」によって当初定義された規則を規定するものです。

これらのルールは、アクセス認証の一形態ではありません。

この最後の文には二重の意味があります。つまり、許可されていないパスは保護されていない（そのルールを強制するものは何もない）ということ、そして、許可されたパスであってもそれによって認証されたわけではないということです。なぜなら、許可はテキストファイルからではなく、規約や法律に基づいて与えられるものだからです。

セキュリティのセクションでは前半の部分が明確に述べられており、多くの人がこれを逆さまに理解しているため、引用する価値があります：

ロボット排除プロトコルは、有効なコンテンツセキュリティ対策の代わりにはなりません。robots.txt ファイルにパスを記載することは、それらを公に公開することになり、その結果、そのパスが発見可能になります。

つまり、Disallow: /admin/secret-reports/と記述することは、そのパスが存在することを世間に知らせることになります。robots.txtを作成する場合、これは機密性の高いパスをそこに一切記載しないべきという根拠となります。RFCでも明示的に推奨されているように、認証を使用してください。

フォーマット

ファイルは一連のグループで構成されます。各グループは、1行以上の「user-agent」行で始まり、その後にルールが続きます。

User-agent: *
Disallow: /admin/
Disallow: /search?
Allow: /search/help

User-agent: BadBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

クローラーが必ずサポートしなければならない3つの特殊文字：

末尾の空グループには意味があります。RFCでは、「最後のグループにはルールがなくてもよく、それは暗黙的にすべてを許可することを意味する」と記載されています。 したがって、末尾にUser-agent: quxbotがあり、その下に何も指定されていない場合、そのクローラーには無制限のアクセス権が与えられます。

パスが指定されていない**空のDisallow:**も、すべてが許可されていることを意味します。これは「制限なし」を表す慣例的な表現です。

Sitemap:はコア文法の一部ではありません。 RFC内のABNFには、実装者に対する「必要な追加の行（例：サイトマップ）を定義すること」という注記が含まれているため、これは必須機能というよりは広くサポートされている拡張機能です。Crawl-delayも同様のカテゴリーに属します。つまり、一般的であり、多くのクローラーでサポートされていますが、標準には含まれていません。

User-Agent の一致処理の仕組み

多くの人が想像しているよりも詳細であり、正しく理解しておく価値があります。

トークンは、User-Agentヘッダーの部分文字列です。 RFCの例：Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html)というヘッダーは、user-agent: ExampleBotのrobots.txt行に対応しており、そこでは「製品トークン（ExampleBot）はUser-Agent HTTPヘッダーの部分文字列である」と記されています。

一致判定は大文字小文字を区別しません。 「クローラーは、プロダクトトークンに一致するグループを見つけるために大文字小文字を区別しないマッチングを使用しなければならず、その後、そのグループのルールに従わなければならない。」

複数のマッチンググループは統合される。 「ユーザーエージェントに一致するグループが複数ある場合、一致したグループのルールは1つのグループに統合されなければならない。」 したがって、同じファイル内に2つの別々のUser-agent: ExampleBotブロックがある場合、2つ目のブロックが1つ目を上書きするのではなく、1つの統合されたルールセットが生成されます。

グループは1つだけであり、複数ではありません。 トークンに一致するグループがある場合は、そのグループを使用し、*グループは完全に無視します。ワイルドカードはフォールバックであり、特定のルールが追加される基準ではありません。 これは多くの人が驚く点ですが、独自のグループを持つクローラーは、一般的なルールの対象にはなりません。

そして、まったく一致するものがない場合： 「製品トークンに一致するグループがなく、かつ * という値を持つ User-Agent 行を含むグループが存在しない場合、あるいはグループがまったく存在しない場合、ルールは適用されません。」

一致の判定は順序ではなく、特定性による

この分野全体で最も頻繁に誤って説明されているルールです。

URIへのアクセスが許可されているかどうかを評価するために、クローラーは「allow」および「disallow」ルール内のパスをURIと照合しなければなりません（MUST）。この照合では、大文字と小文字を区別すべきです（SHOULD）。 照合は、パスの最初のオクテットから開始しなければならない。見つかった中で最も具体的な一致を使用しなければならない。最も具体的な一致とは、オクテットの数が最も多い一致のことである。

最初の一致が優先されるわけではない。最後の一致が優先されるわけでもない。最も長い一致が優先される。

RFC自体の例：

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

example.com/example/page/disallowed.gif の場合、Disallow の行の方が長いため、これが適用されます。これは、2番目に表示されていることや、親パスをカバーする Allow が存在することとは無関係です。

ファイル内の順序を逆にしてもしっかり同じ結果になります。順序は関係ありません。

さらに2つのルールで全体像が完成します。同等のルールがある場合は、Allow が優先されます： 「『allow』ルールと『disallow』ルールが同等である場合、『allow』ルールを使用すべきである（SHOULD）。」そして、一致しない場合は許可される：「グループ内のルールに、該当するユーザーエージェントとの一致が見当たらない場合、またはグループにルールが存在しない場合、そのURIは許可される。」

知っておくべきもう1つの詳細：「/robots.txt URIは暗黙的に許可される」ため、すべてを拒否するファイルであっても、それ自体を拒否することはない。

パスの照合には、パーセントエンコーディングによる正規化も含まれる。 ASCII 以外のオクテットおよび予約範囲内のオクテットは、比較の前に「パーセントエンコードされなければならない」一方、URI 内のパーセントエンコードされた ASCII オクテットは、予約済みでない限り「比較の前にデコードされなければならない」。実際には、これを自分で実装するのではなく、メンテナンスされているライブラリを使用することを推奨する。

ステータスコードがすべてを変える

ここでのルールは厳密ですが、しばしば無視されており、2つのルールの違いは甚大です。

成功。 「クローラーが robots.txt ファイルのダウンロードに成功した場合、クローラーは解析可能なルールに従わなければならない（MUST）。」

リダイレクト。 「クローラーは、権限が異なる場合でも、少なくとも5回連続するリダイレクトに従うべきである。」5回以内のリダイレクトを経て到達したファイルについては、「取得され、解析され、かつ最初の権限の文脈においてそのルールに従わなければならない」。5回を超えると、クローラーは「robots.txtファイルが利用できないものとみなしてもよい」。

利用不可 — 4xx。 「サーバーステータスコードが、robots.txt ファイルがクローラーから利用できないことを示している場合、クローラーはサーバー上の任意のリソースにアクセスしてもよい。」 404 は制限がないことを意味する。

到達不能 — 5xx。 これはよく誤解される点です：「サーバーまたはネットワークのエラーによりrobots.txtファイルに到達できない場合、これはrobots.txtファイルが未定義であることを意味し、クローラーは完全なアクセス禁止であるとみなさなければならない。」

5xxは完全に停止することを意味します。「これまで通り継続する」でも、「キャッシュされたコピーを無期限に使用する」でもなく、完全なアクセス拒否です。 RFCでは、長期的な例外が認められています。ファイルが「相当な期間（例えば30日間）にわたり」未定義である場合、クローラーはrobots.txtファイルが利用できないものとみなしてもよい……あるいはキャッシュされたコピーを使い続けてもよいとされています。

構文解析エラー。 「クローラーは、robots.txt ファイルの各行を解析しようと試みなければならない。クローラーは、解析可能なルールを使用しなければならない。」 形式が不正な行があってもファイルが無効になるわけではなく、読み取れる部分を使用する。

クローラーを開発する者にとっての実用的な意味は、対象サイトが一時的に利用不能になった場合、クロールを加速させるのではなく、一時停止させるべきだということです。これを逆にしてしまうと、すでに負荷に苦しんでいるサイトに過度な負荷をかけてしまうことになります。

キャッシュと制限

独自実装でつまずきがちな2つの運用要件。

少なくとも1日1回は更新すること。 「クローラーは、取得したrobots.txtファイルの内容をキャッシュしてもよい……ただし、robots.txtファイルにアクセスできない場合を除き、クローラーはキャッシュされたバージョンを24時間以上使用してはならない。」

クローラーの起動時に一度ファイルを取得し、1週間そのまま実行し続けることは準拠していません。サイトはルールを変更することがあり、長時間実行されるジョブはそれに気づく必要があります。

少なくとも500 KiBを解析すること。 「解析の制限は、少なくとも500キビバイトでなければならない。」大規模なサイトには大規模なファイルが存在し、恣意的に小さいサイズで切り捨ててしまうパーサーは、ルールを見逃してしまう。これは、クロールが準拠していると誤認させ、実際には準拠していない状態を作り出すため、ここで考えられる最悪の失敗モードである。

実際のファイルの読み込み

現実的な例を順を追って解説します。

User-agent: *
Disallow: /search
Allow: /search/about
Disallow: /*?sessionid=
Disallow: /*.pdf$
Crawl-delay: 2

User-agent: GPTBot
Disallow: /

User-agent: PartnerBot
Disallow:

Sitemap: https://example.com/sitemap_index.xml

行ごとに解説します：

**Disallow: /search

** は、/search

、/search/

、/search/results

といった、その文字列で始まるすべてのパスをブロックします。これは、一致の判定が最初のオクテットから始まり、$

が存在しないためです。

**Allow: /search/about

** はより長いため、この特定のパスに関してはこちらが優先されます。順序ではなく、最も長い一致が優先されるのです。

**Disallow: /*?sessionid=

** はワイルドカードを使用して、その前に何があるかに関係なく、セッションパラメータを含むすべてのパスをブロックします。

**Disallow: /*.pdf$

** は、.pdf

で終わる URL をブロックします。$

がない場合、/report.pdf.html

もブロックされてしまいます。

**Crawl-delay: 2

** は標準ではなく拡張ルールですが、これを適用することは良い慣行です。

**User-agent: GPTBot

に Disallow: /

を指定** すると、そのクローラーを完全に除外します。GPTBotにはこのルールのみが適用される点に注意してください。GPTBotは *

グループの対象ではないため、上記の Crawl-delay

はGPTBotには適用されません。

**User-agent: PartnerBot

で、Disallow:

が空の場合**、無制限のアクセスが許可されます。

**Sitemap:

** はURLインベントリを指しており、これはほとんどのファイルにおいて最も即座に役立つ行です。これの扱い方については、ウェブサイトの全ページを見つける方法で解説しました。

コードでこれを尊重する

メンテナンスされているパーサーを使用してください。特異性マッチングのルールだけでもバグの一般的な原因となりますが、パーセントエンコーディングによる正規化はさらに厄介です。

Python: urllib.robotparser は標準ライブラリに含まれており、単純なケースには十分です。Google のオープンソースパーサー robotstxt およびその Python バインディングは、RFC 9309 を正確に実装しています。Scrapy には RobotsTxtMiddleware が組み込まれており、新規プロジェクトではデフォルトで有効になっています。誰かがこれを無効にしていないか確認してください。

Node: 標準を実装しているメンテナンス中のパッケージがいくつかあります。

Go: RFC のマッチングルールに従ったライブラリが存在します。

どのツールを使用する場合でも、以下の 4 つの点を正しく設定してください：

起動時だけでなく、24 時間ごとに更新してください。 5xxを完全なアクセス拒否、404を制限なし**として扱うこと。 実際のプロダクトトークンでマッチングし、User-Agentヘッダーにそれが含まれていることを確認すること。 最大5回のリダイレクトを追跡し、元のホストのコンテキストでルールを適用すること。

さらに、RFCには記載されていないものの、同様に重要な5つ目のポイントがあります。スキップした項目をログに記録することです。予期せぬルールによってサイトの半分を黙って除外してしまうクローラーの場合、レポートの不備を指摘された数週間後に、初めてデータが欠落していることが判明することになります。

robots.txt が対象としない事項

両方向から誤解されがちなので、明確にしておく価値があります。

取得したデータをどのように扱ってよいかについては、一切言及されていません。 著作権、データベース権、利用規約はすべて個別に適用されます。

これは許可ではありません。 RFCにはその旨が明記されています。許可されたパスとは、サイト側がクローラーに対して回避を求めなかったパスを指すものであり、大量のデータ収集に対する同意とは異なります。

標準仕様にはレート制限は含まれていません。 Crawl-delay は拡張機能です。礼儀正しく振る舞うかどうかは、あなた次第です。

目的の区別は行われません。 標準的な構文では、ファイルが「インデックス作成は可、AIトレーニングは不可」と指定することはできませんが、現在では多くのサイトが、特定のAIクローラー用トークンを指定することで、これに近似した対応を行っています。EUのテキストおよびデータマイニングの枠組みでは、機械可読な権利留保が検討されており、それを表現するための仕組みは現在も定まりつつある段階です。

誰かを阻止することはできません。 これはあくまで要請に過ぎません。執行手段としては、レート制限、ブロック、および法的手続きがあります。これが、事業者が「阻止しなければならないクローラー」ではなく、「許可することを選択するクローラー」となるべき実用的な理由です。

よくある質問

robots.txtには法的拘束力がありますか？

それ自体にはありません。RFC 9309では、そのルールは「アクセス許可の一形態ではない」と明記されています。これは、クローラーに対して遵守を求める要請に過ぎません。 法的義務は、利用規約、著作権、データベース権、および管轄区域ごとの法律に由来するものであり、これらはファイルの内容にかかわらず適用されます。

robots.txtのルールは順序通りに照合されますか？

いいえ。これは、robots.txt に関して最も頻繁に繰り返される誤解です。仕様では、「見つかった中で最も具体的な一致を『MUST』使用しなければならない」と規定されています。ここで「最も具体的」とは、オクテット数が最も多いことを意味します。一致する部分が最も長いものが優先され、順序は関係ありません。同等の場合は、Allow が優先されます。

robots.txt が 404 を返した場合はどうなりますか？

そのファイルは「利用不可」であり、RFCではクローラーが「サーバー上の任意のリソースにアクセスしてもよい」と規定されています。ファイルが存在しないということは、制限がないことを意味します。これはサーバーエラーとは異なります。

robots.txtが500を返した場合はどうなりますか？

そのファイルは「到達不能」かつ未定義であり、クローラーは「完全なアクセス拒否であると見なさなければならない（MUST）」。サーバーエラーは、処理を継続するのではなく、完全に停止することを意味します。長い期間（RFCでは30日間を推奨）が経過した後、クローラーはそれを「利用不可」として扱うか、キャッシュされたコピーを使い続けることがあります。

robots.txtはどのくらいの頻度で取得すべきですか？

少なくとも24時間ごとに取得する必要があります。RFCでは、クローラーは「robots.txtファイルにアクセスできない場合を除き、キャッシュされたバージョンを24時間以上使用してはならない」と規定されています。起動時に一度取得して1週間そのままにするような行為は、規定に準拠していません。

特定のユーザーエージェントグループは、ワイルドカードグループに優先しますか？

置き換わります。グループ名が自社のプロダクトトークンと一致する場合、そのグループに従い、「*」グループは完全に無視されます。特定のルールは一般的なルールに追加されることはありません。同じトークンを指定する2つのグループは、1つに統合されます。

robots.txt における「*」と「$」は何を意味しますか？

「*」は任意の文字の 0 回以上の出現に一致し、「$」は一致パターンの終了を示します。どちらもクローラーがサポートしなければならない文字です。「Disallow: /*.pdf$」は .pdf で終わる URL をブロックします。$ がない場合、/file.pdf.html もブロックされてしまいます。

robots.txt を使って機密性の高いページを非表示にすることはできますか？

いいえ、そうすることはかえって事態を悪化させます。RFC のセキュリティに関するセクションには、「robots.txt ファイルにパスを記載すると、それらが公に公開され、その結果、そのパスが発見可能になってしまう」と記載されています。誰でもそのファイルを読むことができます。代わりに、仕様書で明示的に推奨されている認証を使用してください。

まとめ `

`robots.txt`` は短く、標準化されていますが、日常的に誤って実装されています。エラーの大部分は、以下の3つのルールに起因しています。

最も長い一致が優先されます。最初や最後ではありません。ファイルの後半にある Disallow は、それより前の Allow を上書きすることがあり、その逆も同様です。これは純粋に長さによるものです。 5xxは完全な拒否を意味する。これは直感的な実装とは正反対である。問題を抱えるサイトへのトラフィックは減らすべきであり、同じ量を維持すべきではない。また、ファイルは少なくとも毎日更新されなければならない。サイトは方針を変更することがあり、1週間前のキャッシュされたコピーでは準拠とはみなされないからだ。

独自にパーサーを作成するのではなく、メンテナンスされているパーサーを使用し、User-Agentヘッダーに実際に照合対象となるトークンが含まれていることを確認し、スキップした内容をログに記録して、データの欠落が予期せぬ事態ではなく意図的な判断となるようにしてください。

また、規格自体が示す注意点を常に念頭に置いてください。これらのルールは「アクセス権限の一形態ではない」のです。これらを順守することで、サイト運営者が許容できるクローラーとなることができますが、規格が何を許可しているか、また収集したデータをどのように利用できるかという別の問題については、これだけで解決されるわけではありません。