Robots.txt SEO：クロールを効率的に制御

robots.txt の役割 — できることとできないこと

Robots.txt はサイトのルートに置かれるプレーンテキストファイルです（https://example.com/robots.txt）。その役割は限定的で、ルールに従うクローラーにクロールの指示を与えるものです。価値の低い領域への不要な取得を減らし、クロールの効率を改善するために使ってください。インデックス登録の制御や機密情報の隠蔽には頼らないでください。

クロールを制御するもので、インデックス登録を制御するものではありません

Disallow 指令は準拠するクローラーが特定の URL パスを取得するのを防ぎます。ページがクロール禁止になっている場合、検索エンジン は外部シグナル（例：リンク）に基づいてその URL をインデックスする可能性がありますが、ページの HTML や meta robots タグは確認できません。確実にインデックス登録を防ぐには、クロールを許可して クローラー が meta robots の noindex タグを読み取るか、リソース自体に対して X-Robots-Tag レスポンスヘッダーで noindex を指定できるようにしてください。

公開されており助言的なもので、セキュリティ対策にはなりません

robots.txt は公開されており助言的な性格のファイルです：誰でも /robots.txt で内容を読めますし、悪意あるクローラーはその指示を無視する可能性があります。機密情報やプライベートなパスを robots.txt に列挙しないでください。アクセス制御の手段ではなく、クローリング制御用の文書として扱ってください。

基本構文と一般的なディレクティブ

ほとんどのサイトは少数のディレクティブセットを使います。仕様と主要検索エンジンが採用する実用的な拡張は、基本的なパターン、ワイルドカード、サイトマップへの参照をサポートします。ルールはシンプルに保ち、可能であればコメントで意図を記載してください。

主なディレクティブ（例はそのままの行で示しています）:

• User-agent: <bot-name> — 特定のクローラーを指定します。すべてのクローラーには User-agent: * を使用してください。
• Disallow: /path/ — /path/ 以下のパスの取得を禁止します。
• Allow: /path/file.js — Disallow された親パスの下でも明示的にそのパスを許可します（主要検索エンジンがサポート）。
• Sitemap:https://example.com/sitemap.xml— クローラーにあなたのXML sitemap（複数可）
• ワイルドカード: *（任意の文字列に一致）や $（文字列末尾）は主要エンジンで実務的にサポートされています。クエリパラメータのパターン指定では慎重に使用してください。
• 非標準ディレクティブ: Crawl-delay や Host は一部のクローラで認識されますが、元の標準仕様の一部ではありません — 対象とするユーザーエージェントで挙動をテストしてください。

robots.txt がインデックス化とランキングにどのように影響するか

クロール、インデックス化、ランキングは別段階です: robots.txt はクロール段階（クローラがURLを取得するかどうか）に影響します。インデックス化にはクローラがページのコンテンツや meta/X-Robots-Tag を読むことが必要です。ランキングはその後のプロセスで、ページ内容由来のシグナルの一部に依存します。クローラがページを取得できないと、これらのコンテンツ由来シグナルは利用できません。

実務上の帰結:

• robots.txt でページをブロックすると、検索エンジンはそのページを取得して meta robots の noindex タグや構造化データを読み取ることができなくなります。
• 重要なリソース（CSS/JS）がブロックされていると、mobile-first indexingレンダリングが正しく行えずページを正しく認識できない可能性があります。Google はモバイル版を主要な基準として使用しているため、crawling and indexing, また、Googlebot Smartphone がデフォルトのクローラである（2024年7月時点）ため、モバイルでのレンダリングに必要なリソースは許可してください。

検証: クローラが実際にどのようにページを見ているかをどのようにテストするか

外部からrobots.txtへのアクセス性と内容を確認し、実際のクローラーからのリクエストに対するサイトの応答を検証します。管理しているページについては、サーバーログ、直接取得、およびSearch Consoleのツールを使用してください。

curlによる簡易チェック

robots.txtのHTTPレスポンスヘッダー（ヘッダーのみ）を取得するには：

• curl -I https://example.com/robots.txt — レスポンスヘッダーのみが返されます。ステータスコードとContent-Typeを確認してください。

特定のUser-Agentとしてファイル本体（HTMLおよびディレクティブ）を取得するには：

• curl -A \"Googlebot\" https://example.com/robots.txt — 指定したUser-Agent文字列を用いてファイル本体が返されます。

サーバーログと実際のクロールの証拠

サーバーログを点検して /robots.txt へのリクエストや、Googlebot や Bingbot のようなクローラーのUser-Agentを確認してください。ログからはフェッチ頻度、レスポンスコード、クローラーがアクセス禁止のURLを試行したかどうかが分かります。ご自身が所有するページについては、Search ConsoleのURL Inspectionを使ってクロールやインデックスのシグナルを確認してください。第三者のページについては、site:クエリでの確認は指標にはなりますが決定的ではありません。

よくある間違いと対処法

robots.txt の管理で避けるべき頻出エラー。

• レンダリングに必要な CSS/JS をブロックしている場合：対策 — mobile rendering pipeline で必要なアセットのパスを許可し、Googlebot Smartphone がページを正しくレンダリングできるようにする。
• robots.txt によって URL を noindex にできると期待する誤解：対処法 — 当該ページの Disallow を削除し、meta robots noindex または X-Robots-Tag ヘッダーを使用して検索エンジンに指示を示す。
• robots.txt に機密性の高い URL を列挙すること：対処法 — robots.txt にプライベートなパスを公開せず、認証や適切なサーバー側のアクセス制御で保護する。
• 意図せず有効なページにマッチする過度に複雑なワイルドカードルール：対処法 — 各パターンをサンプル URL でテストし、コメントで意図を明記する。ルールは可能な限り具体的にする。

robots.txt に関する推奨戦略

保守的で検証可能なアプローチを採用する：robots.txt は最小限にし、クローラーには Sitemap を示し、インデックス管理はページレベルの meta/X-Robots-Tag に頼ることを推奨する。

実践的なパターン：

• デフォルトで許可＋Sitemap：User-agent: * と Sitemap ディレクティブを含め、クローラーが構造を速やかに把握できるようにする。
• 価値の低いクエリページやサイト内検索結果は Disallow する一方で、正規コンテンツにマッチするパラメータパターンをブロックしないよう注意する。パラメータ処理は sitemap や canonical タグで行う方が望ましい。
• ステージングや開発環境：ステージングが公開中はクローラーをブロックするが、ローンチ前にそのブロックを解除または変更すること。本番前の資産を保護する唯一の手段として robots.txt に頼らない。

カスタマイズできる例

サイトマップがあるシンプルなサイト

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

一般的なCMS（admin-ajaxを許可）

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Sitemap: https://example.com/sitemap_index.xml

ステージングのブロック（公開サーバーだがまだ本番化していない）

User-agent: *
Disallow: /

警告: ステージング用のブロックはローンチ前に必ず解除してください。また、robots.txtが変更された場合に検索エンジンや第三者に誤ってインデックスされないよう、ステージング環境には認証で保護をかけてください。

大規模運用におけるrobots.txtの管理

大規模サイトでは、robots.txtを構成アーティファクトとして扱ってください。ソース管理に含め、プルリクエストで変更をレビューし、サイトと一緒にデプロイしてステージングと本番で環境固有のファイルが正しく反映されるようにします。デプロイされたrobots.txtを取得して代表的なURLに対するルールの構文を検証するテストを自動化してください。

複数のサブドメインを運用している場合、robots.txt はホストごとに有効であることを忘れないでください。example.com/robots.txt に書かれたルールは sub.example.com には適用されません。

よくある質問

robots.txt はページが検索結果に表示されるのを防げますか？

確実ではありません。robots.txt はクローラーがページを取得するのを止められますが、検索エンジンは外部リンクやその他のシグナルに基づいて URL をインデックスすることがあります。インデックスを防ぎたい場合は、クロールを許可した上でページに meta robots noindex タグを設置するか、クローラーが指示を読み取れるよう X-Robots-Tag: noindex レスポンスヘッダーを設定してください。

Google が私の robots.txt に従っているかどうかはどう確認しますか？

外部からは、次の URL を取得して確認します。https://example.com/robots.txtcurl でファイルとステータスコードを確認し、サーバーログで Googlebot の robots.txt へのリクエストや、クロールされるはずのページへのリクエストを確認し、所有しているページは Search Console の URL Inspection でクロール試行やインデックス状況を確認してください。site: クエリは公開上の目安になりますが決定的ではありません。

robots.txt で URL パラメータをブロックすべきですか？

注意が必要です。パラメータ付き URL をブロックするとクロール予算を節約できる場合がありますが、パターンが広すぎると正規化された（canonicalized）あるいはインデックスされたコンテンツを隠してしまうリスクがあります。可能であれば canonical タグ、サイトマップでのパラメータ処理、またはサーバー側のリダイレクトを優先し、パターンは展開前に十分にテストしてください。

Crawl-delay を頼りにしても安全ですか？

Crawl-delay は非標準のディレクティブで、クローラーごとにサポート状況が異なります。クロールレートの制御が必要なサイトでは、サーバー側でのレート制限や、robots メタタグ特定のページに対して設定するか、クローラーごとに異なる設定は、例えば Bing Webmaster Tools。ターゲットにするユーザーエージェントでの挙動は必ずテストしてください。