robots.txtファイルは、ウェブマスターが持つ最も古く、最も強力なツールの一つです。すべてのドメインのルートに置かれるこのプレーンテキストファイルは、クローラーにサイトのどの部分にアクセスでき、どの部分にアクセスすべきでないかを伝えます。そのシンプルさにもかかわらず、robots.txtはウェブ上で最も頻繁に設定ミスされるファイルの一つでもあります。たった一つの誤ったルールが、サイト全体を検索エンジンから隠したり、非公開にすべきセクションを公開してしまう可能性があります。

このガイドでは、基本構文から高度なパターンまですべてをカバーし、自信を持ってrobots.txtルールを記述できるようにします。

robots.txtの配置場所とクローラーによる検出方法

すべての規格準拠クローラーは、ドメイン上の他のURLをリクエストする前に、まずルートの/robots.txtを取得します：

https://example.com/robots.txt

ファイルに関する主なルール：

• 正確なパス/robots.txtで提供される必要があります — /Robots.txtではなく、サブディレクトリ内でもありません。
• text/plainコンテンツタイプとともに200ステータスコードを返す必要があります。サーバーが404を返す場合、クローラーはすべてが許可されていると見なします。5xxエラーが返される場合、ほとんどのクローラーはファイルが利用可能になるまでクロールを一時停止します。
• ファイルはオリジンごと（スキーム＋ホスト＋ポート）に適用されます。https://example.com/robots.txtのルールはhttps://blog.example.comやhttp://example.comには適用されません。
• Googleが認識する最大ファイルサイズは500 KiBです。それを超える部分は無視されます。

基本構文

robots.txtファイルは、1つ以上のルールグループで構成されます。各グループは1つ以上のUser-agent行で始まり、Disallowおよび/またはAllowディレクティブが続きます：

User-agent: Googlebot
Disallow: /private/
Allow: /private/public-page.html

User-agent: *
Disallow: /tmp/
Disallow: /internal/

User-agent

User-agent行は、後続のルールが適用されるクローラーを指定します。ワイルドカード*は、独自の固有ブロックを持たないすべてのクローラーにマッチします。クローラーは利用可能な最も具体的なUser-agentブロックに自身をマッチさせます。User-agent: *とUser-agent: Googlebotの両方が存在する場合、Googlebotはgooglebot固有のブロックのみを使用し、ワイルドカードブロックは完全に無視します。

Disallow

Disallow: /path/は、マッチしたクローラーに/path/で始まるURLにアクセスしないよう指示します。パスのない空のDisallow:は、何もDisallowしないことを意味し、フルアクセスと同等です。

Allow

Allow: /path/は、より広いDisallowがブロックする場合でも、パターンにマッチするURLへのアクセスを明示的に許可します。例外を設けるために不可欠です。

ワイルドカードとパターンマッチング

1994年のオリジナルのrobots.txt仕様にはワイルドカードが含まれていませんでしたが、Google、Bingおよびほとんどの最新クローラーは2つの重要なパターンマッチング文字をサポートしています：

アスタリスク：*

空文字列を含む任意の文字シーケンスにマッチします。例：

• Disallow: /*.pdf — パスのどこかに.pdfを含むすべてのURLをブロックします。
• Disallow: /directory/*/page — /directory/anything/pageのようなURLをブロックします。

ドル記号：$

マッチをURLの末尾に固定します。$なしでは、パターンはプレフィックスとしてマッチします。例：

• Disallow: /*.pdf$ — .pdfで終わるURLをブロックしますが、URLが.pdfで終わらない/file.pdf?view=1は許可します。
• Allow: /page$ — 正確に/pageのみを許可し、/page/subpageや/page?q=1は許可しません。

Allow vs Disallow：どちらが勝つか？

URLがAllowとDisallowの両方のルールにマッチする場合、解決は具体性（パスの長さ）に依存します。Googleの実装は次のロジックに従います：

1. より長いマッチングパスを持つルールが勝ちます。
2. 両方のルールが同じ長さの場合、Allowが優先されます。

例：

User-agent: *
Disallow: /directory/
Allow: /directory/public/

ここで、/directory/public/page.htmlは許可されます。なぜなら/directory/public/（20文字）が/directory/（11文字）より長いからです。しかし/directory/secret.htmlはブロックされたままです。

これはよくある混乱の原因です。robots.txtテスターでルールをテストし、特定のURLに対する結果を必ず確認してください。

Crawl-delayディレクティブ

Crawl-delayは、クローラーに連続するリクエスト間に指定された秒数を待つよう要求します：

User-agent: Bingbot
Crawl-delay: 10

重要な注意点：

• GoogleはCrawl-delayを完全に無視します。Googlebotのクロールレートを制御するには、Google Search Consoleのクロールレート設定を使用してください。
• Bingはこれを遵守します。値が10の場合、Bingbotはリクエスト間に10秒待機します。
• Yandex、Baiduおよび一部の他のクローラーもこれを遵守しますが、実装は異なります。
• 過度に高い値（例：60）を設定すると、事実上クロールが停止します。サーバーが本当に負荷を処理できない場合にのみ控えめに使用してください。

Sitemapディレクティブ

robots.txtで直接サイトマップを宣言できます：

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

主なポイント：

• SitemapディレクティブはどのUser-agentブロックにも紐付けされません。ファイルの上部または下部に配置してください—グローバルに適用されます。
• URLは完全修飾（スキーム付きの絶対URL）である必要があります。
• 複数のサイトマップをリストできます。
• これは発見のヒントであり、保証ではありません。Search ConsoleやBing Webmaster Toolsを通じてサイトマップを送信する方がより信頼性があります。

クロールを壊すよくあるミス

1. CSSとJavaScriptのブロック

User-agent: *
Disallow: /assets/
Disallow: /js/
Disallow: /css/

最新の検索エンジンはコンテンツとレイアウトを評価するためにページをレンダリングします。レンダリングに必要なリソースをブロックすると、クローラーは壊れたページを見ることになり、評価を下げたりスキップしたりする可能性があります。公開コンテンツのレンダリングに本当に関係ないリソースのみをブロックしてください。

2. Disallowを使ってページをインデックスから除外しようとする

Disallowはクロールを防止するものであり、インデックスを防止するものではありません。他のページがDisallowされたURLにリンクしている場合、Googleはそれをインデックスに含める可能性があります—ただし表示するコンテンツがないため、曖昧なリスティングになります。ページをインデックスから完全に削除するには、noindexメタタグまたはX-Robots-Tagヘッダーを使用し、クローラーがページを見られるよう許可してください。

3. 末尾のスラッシュを忘れる

Disallow: /private   # /private、/private.html、/privatelyなどをブロック
Disallow: /private/  # /private/ディレクトリ内のパスのみブロック

最初のパターンは、ほとんどの人が意図するよりも広範囲です。末尾のスラッシュが必要かどうかを常に検討してください。

4. ワイルドカードと固有ブロックの競合

User-agent: *ブロックとボット固有のブロックがあり、固有ブロックが空の場合、ワイルドカードブロックが制限的であっても、そのボットに事実上フルアクセスを付与します。これは設計通りですが、ルールが蓄積されると想定する人には驚きとなります。

5. リダイレクト経由でrobots.txtを配信する

/robots.txtが301や302を返す場合、ほとんどのクローラーはリダイレクトに従います。ただし、チェーンリダイレクト、リダイレクトループ、またはtext/plain以外のレスポンスへのリダイレクトは、クローラーにファイルを利用不可として扱わせます。シンプルに保ちましょう：ルートで200レスポンスとともにファイルを直接配信してください。

6. AIクローラーを考慮していない

robots.txtにUser-agent: *ブロックしかない場合、明示的にブロックしていないAIクローラーはGooglebotと同じアクセス権を持ちます。GPTBot、ClaudeBot、PerplexityBot、Bytespiderなどのボットに固有のルールを追加することを検討してください。

robots.txtのテスト

テストせずにrobots.txtの変更をデプロイしないでください。利用可能なツールには以下があります：

• Google Search Console — robots.txtテスターは、特定のURLに対してGoogleがルールをどのように解釈するかを表示します。
• Bing Webmaster Tools — Bingbotの同様のテスト機能です。
• Spider.es — 検索エンジン、AIボット、SEOツールなど、どのクローラーがドメインの任意のURLにアクセスできるかを、各判定を制御する具体的なルールとともに確認できます。
• コマンドラインツール — Pythonのurllib.robotparserのようなライブラリで、CI/CDパイプラインでのテストを自動化できます。

堅実なスターティングテンプレート

# 検索エンジン：フルアクセス
User-agent: Googlebot
Allow: /

User-agent: Bingbot
Allow: /
Crawl-delay: 5

# AIクローラー：選択的
User-agent: GPTBot
Disallow: /premium/
Allow: /blog/

User-agent: Google-Extended
Disallow: /

# デフォルト：制限付き許可
User-agent: *
Disallow: /admin/
Disallow: /tmp/
Disallow: /search?*

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

ニーズに合わせて調整してください。原則はシンプルです：許可するものについて明示的に、ブロックするものについて慎重に、デプロイ前にテストすることです。

まとめ

robots.txtは見かけよりも奥深いものです。数行のテキストが、何百万もの人々が検索エンジンやAIツールを通じてコンテンツを発見できるかどうかを制御します。サイトのセキュリティ設定と同じ注意を払いましょう。定期的に監査し—特に新しいAIクローラーが登場した際には—Spider.esのようなツールを使用して、意図したポリシーが現実と一致しているか確認してください。