robots.txtの書き方｜クロールを制御する基本

robots.txtとは何か・何をするファイルか

robots.txtは、サイトのルート直下（例：https://example.com/robots.txt）に配置するテキストファイルで、検索エンジンのクローラーに対してアクセスしてよいパス・してほしくないパスを伝えます。ここで最も重要な前提は、robots.txtは「クロール（巡回）を制御する」ものであって、「インデックス（検索結果への登録）を拒否する」ものではないという点です。Disallowでブロックしたパスであっても、外部からリンクされているなどの理由でURL自体が検索結果に表示されることがあります。つまりrobots.txtは、クローラーの巡回対象を整理してサーバー負荷を抑えたり、意味のないパスへの巡回を減らしたりする用途に向いており、「検索結果に出したくない」という目的には別の手段が必要です。この違いを理解しないまま設定すると、意図と異なる結果を招くことがあります。

基本構文（User-agent・Disallow・Allow）

robots.txtは、対象となるクローラーを指定するUser-agentと、その対象に対する許可・不許可を示すルールの組み合わせで構成されます。User-agentには、すべてのクローラーを対象とする場合はアスタリスクを、特定のクローラーを対象とする場合はその名前を指定します。Disallowは巡回してほしくないパスを、Allowは（Disallowで広くブロックした中で例外的に）巡回を許可したいパスを指定します。たとえば管理画面のパスや検索結果ページのような、クロールさせる意味の薄いパスをDisallowで指定するのが典型的な使い方です。パスは前方一致で解釈され、記述はスラッシュから始めます。空のDisallow（値なし）は「すべて許可」を意味します。記述の順序や解釈にはクローラーごとの差もあるため、意図した挙動になっているかは必ず確認が必要です。仕様は変更される場合があります。最新情報はGoogleの公式ドキュメントをご確認ください。

Disallowはインデックス拒否ではない

robots.txtで最も誤解されやすいのがDisallowの意味です。Disallowはクローラーの巡回を止めるだけであり、そのURLを検索結果から除外することを保証しません。むしろ注意が必要なのは、あるページをrobots.txtでブロックすると、クローラーがそのページの中身を読めなくなるため、ページ内に設置したnoindex（検索結果に出さないための指示）も読み取れなくなるという点です。結果として、noindexを設定したつもりでもrobots.txtでブロックしているために指示が届かず、URLが検索結果に残り続けるという矛盾した状況が起こり得ます。検索結果に確実に出したくないページがある場合は、robots.txtでブロックするのではなく、そのページをクロール可能な状態にしたうえでnoindexを設定するのが正しい考え方です。クロール制御とインデックス制御は別物であるという原則を、常に念頭に置く必要があります。

noindexとの正しい使い分け

検索に関する「見せたくない・巡回させたくない」という要望は、目的ごとに手段が分かれます。検索結果に表示させたくないページは、ページ側にnoindexを設定します。これはHTMLのmeta robotsやHTTPヘッダーのX-Robots-Tagで指定でき、クローラーがそのページを読み込める状態であることが前提です。一方、サーバー負荷の軽減や、大量のパラメータURLへの無駄な巡回を減らしたい場合はrobots.txtのDisallowが向いています。両者を組み合わせる際は順番が重要で、noindexを効かせたいならまずクロールを許可し、noindexが認識されてURLがインデックスから外れたのを確認してから、必要に応じてクロール制御を検討します。最初からrobots.txtでブロックしてしまうと、前述のとおりnoindexが読まれず逆効果になります。「巡回を減らしたい」のか「検索に出したくない」のかを切り分けて手段を選ぶことが肝心です。

サイトマップの記述とよくある事故

robots.txtには、XMLサイトマップの場所を示す記述を含めることができます。サイトマップのURLを記載しておくと、クローラーがサイトの構造を把握する手がかりになります。一方で、robots.txtは設定を誤ると影響が非常に大きいファイルでもあります。最も深刻な事故は、サイト全体をブロックする記述を本番環境に残してしまうケースです。開発中に全ページの巡回を止める設定をしたまま公開してしまうと、サイト全体がクロールされなくなり、検索での評価に大きな影響が出ます。また、CSSやJavaScriptのファイルをブロックすると、Googleがページを正しく描画できず、モバイル対応やページ内容の評価に支障が出ることがあります。公開前には、意図せず重要な資産をブロックしていないかを必ず確認します。

特定のクローラーだけを制御したい場合

robots.txtは、User-agentを指定することで対象となるクローラーごとにルールを分けられます。すべてのクローラーに共通のルールを適用したい場合はアスタリスクを使い、特定のクローラーだけに別のルールを設けたい場合はそのクローラー名を指定してブロックの範囲を切り替えます。ただし、robots.txtの指示に従うかどうかは各クローラーの実装に依存します。主要な検索エンジンのクローラーは記述を尊重する傾向がありますが、行儀の悪いクローラーの中にはrobots.txtを無視してアクセスするものもあります。したがって、外部に一切知られたくない情報や、アクセス自体を確実に防ぎたいページを守る手段としてrobots.txtに頼るのは適切ではありません。robots.txtに記載したパスは、ファイル自体が公開されているため、外部から閲覧可能である点にも注意が必要です。機密性のある領域は、robots.txtでの記述ではなく、認証（ログイン）やサーバー側のアクセス制限といった技術で保護するのが正しい考え方です。robots.txtはあくまで、行儀の良いクローラーに対する巡回の案内役だと位置づけておくと、役割を誤らずに済みます。

設定後のテストと確認方法

robots.txtは影響範囲が広いため、設定後の検証が欠かせません。まず、ブラウザで自サイトのrobots.txtに直接アクセスし、記述内容と実際に配信されているファイルが一致しているかを確認します。次に、Googleサーチコンソールを使って、特定のURLがクロール可能かどうかを検査します。URL検査ツールでは、対象URLがrobots.txtによってブロックされていないか、インデックス登録の可否を含めて状況を確認できます。重要なページが誤ってブロックされていないか、逆にブロックしたいパスが確実に対象になっているかを、実際のURLで一つひとつ確かめる運用が安全です。robots.txtの変更はサイト全体の巡回に関わるため、公開前後での確認を習慣化し、想定外の挙動を早期に発見することが望ましい進め方です。

よくある質問（FAQ）

Qrobots.txtでDisallowすれば検索結果から消えますか？

Aいいえ。robots.txtはクロール（巡回）を制御するもので、インデックス（検索結果への登録）を拒否するものではありません。ブロックしても外部リンクなどが理由でURLが検索結果に表示されることがあります。検索に出したくない場合はnoindexを使います。

Qnoindexとrobots.txtはどちらを使えばいいですか？

A検索結果に出したくないならnoindex、巡回自体を減らしたいならrobots.txtです。注意点として、robots.txtでブロックするとクローラーがページを読めず、ページ内のnoindexも認識されなくなります。noindexを効かせたいURLはブロックしないでください。

Qrobots.txtはどこに置けばいいですか？

Aサイトのルート直下（例：https://example.com/robots.txt）に配置します。サブディレクトリに置いても正しく認識されません。ドメイン単位で1つのrobots.txtが基本です。

QCSSやJavaScriptをブロックしても問題ないですか？

A推奨されません。これらをブロックするとGoogleがページを正しく描画できず、ページ内容やモバイル対応の評価に支障が出ることがあります。表示に必要な資産はクロール可能にしておくのが安全です。

Q開発環境の設定を本番に残すとどうなりますか？

Aサイト全体をブロックする記述を本番に残すと、サイトがほとんどクロールされなくなり検索での評価に大きな影響が出ます。公開前にrobots.txtの内容を必ず確認することが重要です。

Q設定が正しいか確認する方法はありますか？

Aブラウザで自サイトのrobots.txtに直接アクセスして内容を確認し、GoogleサーチコンソールのURL検査で個別URLがブロックされていないかを検査します。重要なページが誤ってブロックされていないかを実URLで確かめます。