【スクレイピング対策】robots.txtの確認方法を解説！
robots.txtは、クローラー（ボット）に対して「どのURLをクロールしてよいか／避けるべきか」を伝えるためのルールファイルです。スクレイピングの可否や、クロール時のトラブル回避を考えるなら、まずrobots.txtを正しく確認できることが重要です。本記事では、ブラウザ・コマンド・ツールでの確認手順と、読み方の要点を整理します。
- robots.txtの基本仕様と確認の最短手順
- Disallow/Allowの読み方と判定のコツ
- 確認時のよくある落とし穴と対処
robots.txtとは
robots.txtは、サイトのトップ（ルート）に置かれるテキストファイルで、クローラーに対するアクセスルール（Allow/Disallowなど）を記述します。標準仕様としてはRobots Exclusion Protocol（REP）があり、ファイルは原則として 「/robots.txt」 に配置されます。
重要: REPの仕様では、ルールは「/robots.txt（小文字）」で提供される必要があり、比較は基本的にパス先頭から行われ、最も具体的（最長一致）なルールが採用されます。また「/robots.txt」自体は暗黙的に許可されます。
注意: robots.txtはアクセス制御（認証）の代替ではありません。記載したパスは公開情報になり得るため、秘匿したい管理画面やファイルは、認証・IP制限など別の仕組みで守る必要があります（仕様のSecurity Considerationsでも注意喚起されています）。
参考: RFC 9309
確認方法の全体像
robots.txtの確認は、次の順で行うのが効率的です。
- URL直打ちで表示できるか（存在確認）
- HTTPステータスとリダイレクトの有無（取得確認）
- 内容（User-agent / Allow / Disallow / Sitemap）を読む
- 特定URLが許可か禁止かを判定する
なお、Googleはrobots.txtを取得して解析し、ホスト・プロトコル・ポート単位で適用範囲が決まる点などを明記しています。
手順1 URLで確認
まずは対象サイトのルート直下に robots.txt があるかを確認します。
ここで見るべきポイントは2つです。
- 表示されるか（404ではないか）
- 内容が意図したものか（CMSやプラグインの自動生成で想定外になっていないか）
注意: robots.txtは「サブディレクトリ配下」に置いても効きません。原則として /robots.txt に置かれます（仕様）。
参考: RFC 9309
手順2 curlで確認
ブラウザ表示だけだと、リダイレクトやステータスの見落としが起きがちです。スクレイピング用途では、HTTP的に「どう返ってくるか」を必ず確認しましょう。
ステータス確認
curl -I https://example.com/robots.txt期待値は基本的に 200 OK です。3xx（リダイレクト）や4xx/5xxが出る場合は、クローラー側の扱いも変わり得ます（特に到達不能時の扱いなどは仕様に定義があります）。
本文を取得
curl -s https://example.com/robots.txtUser-Agent別に確認
サイトによってはUser-Agentで挙動が変わることがあります。最低限、あなたのクローラーのUAで取得できるか確認します。
curl -s -A "MyCrawler/1.0" https://example.com/robots.txt重要: robots.txtのルール適用は「User-agentグループ」単位です。自分のクローラー名（User-agent）がどのグループにマッチするかを前提に読まないと、判定を誤りやすい点は押さえておきたいところです。
参考: RFC 9309
手順3 読み方の基本
robots.txtは、概ね次のような「グループ（User-agent）→ルール（Allow/Disallow）」の並びで書かれます。
User-agent: *
Disallow: /private/
Allow: /private/public-info/
Sitemap: https://example.com/sitemap.xml見るべきディレクティブ
- User-agent: どのクローラー向けルールか
- Disallow: クロールしてほしくないパス
- Allow: Disallowより優先させたい例外
- Sitemap: サイトマップの場所（REPの必須要素ではないが広く利用）
重要: 仕様上、Allow/DisallowはURIパスに対して先頭からマッチし、最も具体的（最長一致）のルールを採用します。AllowとDisallowが同程度に一致する場合はAllowが推奨されます。
参考: RFC 9309
判定の例
例えば次のルールがある場合、/private/public-info/ は許可、それ以外の /private/ は禁止という意図になります。
User-agent: *
Disallow: /private/
Allow: /private/public-info/手順4 可否の判定
特定URLがクロール許可かどうかは、次の観点で判断します。
- あなたのUser-agentにマッチするグループを特定
- 対象URLのパスに対してAllow/Disallowの一致を比較
- 最長一致（最も具体的）を採用
チェック表
| チェック項目 | 見る場所 | 判断のポイント |
|---|---|---|
| グループ一致 | User-agent | 自分のUAに最も適切な記述を探す |
| 禁止範囲 | Disallow | パス先頭から一致するか |
| 例外許可 | Allow | Disallowより具体的ならAllowが勝つ |
| robots.txt自体 | /robots.txt | 暗黙的に許可（取得できない場合は別問題） |
確認の落とし穴
ホスト違い
robots.txtはホスト・プロトコル・ポートごとに適用されます。例えば www.example.com と example.com は別扱いになり得ます。確認対象のURLと同じホストで /robots.txt を見ているか確認してください。
リダイレクト
robots.txt取得がリダイレクトされていると、クローラー実装によって追従や扱いが変わります。まずは curl -I で3xxが出ていないか確認し、必要なら -L で追従して実体を見ましょう。
curl -I -L https://example.com/robots.txt到達不能と取得不可
「404などで取得不可」と「5xxなどで到達不能」は扱いが異なり得ます。REPでは、到達不能時は原則として全面禁止を仮定する、などの挙動が定義されています。スクレイピング実装では、robots.txt取得エラー時にどう振る舞うか（停止する／リトライする／一定時間後に再判定する）を決めておくのが安全です。
注意: 「robots.txtが読めない＝自由にクロールしてよい」と短絡しないでください。サイト側の一時障害やWAF設定が原因の可能性もあります。
参考: RFC 9309
文字種とエンコード
仕様ではrobots.txtはUTF-8、メディアタイプはtext/plainが求められます。文字化けや不可解な判定が出る場合は、レスポンスヘッダ（Content-Type）と実ファイルの文字コードを確認してください。
curl -I https://example.com/robots.txt | sed -n '1,20p'スクレイピング実務の要点
robots.txt確認は「入口」にすぎません。実務では次も併せて確認するのが現実的です。
- 利用規約・API提供の有無（規約でスクレイピングを禁じているケース）
- アクセス頻度（レート制限）と負荷配慮
- 機微情報や個人情報に該当しないか
- ブロック回避目的の実装が不正アクセス等に抵触しないか（法務確認）
スクレイピングを安全化しませんか？
robots.txt確認から運用設計まで、炎上やブロックを避けるための進め方を整理できます。要件に合わせた実装・運用の相談も可能です。
まとめ
robots.txtの確認は、(1) /robots.txt を開いて存在確認し、(2) curl でHTTPステータスと本文を確認し、(3) User-agentグループとAllow/Disallowの最長一致で判定する、が基本です。特にスクレイピングでは、取得エラー時の扱い（停止・リトライ）や、規約・負荷配慮まで含めた運用設計が結果的にトラブルを減らします。
