robots.txtとは?「クローラーを止めるファイル」という誤解が招く公開事故
自社サイトのrobots.txtを初めて開いて編集しようとしたとき、「ここに書けば、そのページは検索エンジンから隠せる」と考えてしまう人は少なくありません。ファイル名に「robots」、記述に「Disallow(禁止)」という強い言葉が並ぶと、そこがアクセスを制御する境界線のように見えるからです。
この記事では、RFC 9309(Robots Exclusion Protocol)とGoogle検索セントラルの公式ガイドという2つの一次情報から、robots.txtが実際には何をする仕組みで、何をする仕組みではないのかを整理します。
先に結論の方向性だけ置きます。robots.txtは「アクセスを禁止する」仕組みではなく、「クロールしてほしくない場所を、良識あるクローラーに向けてお願いする」仕組みです。この違いを取り違えると、隠したかったはずのパスが逆に公開されたり、消したかったページがインデックスされたまま残ったりします。
30秒で要点
- RFC 9309は「これらのルールはアクセス認可の一形式ではない(These rules are not a form of access authorization)」と明記している。robots.txtは強制力のあるアクセス制御ではない
- robots.txtに列挙したパスは、そのファイル自体が公開情報になる。隠したいパスを書くと、かえって発見されやすくなる
- robots.txtが取得できないとき、HTTPステータスコードによってクローラーの挙動は正反対になる(400番台は全面許可、500番台は全面禁止)
- Disallowされたページでも、他サイトからリンクされていればインデックスされることがある。その場合、検索結果に説明文は付かない
| 用語 | 意味 |
|---|---|
| robots.txt | サイトのクロールに関する希望を、クローラーに向けて記述する公開ファイル |
| Disallow | 「このパスにはアクセスしないでほしい」という記述。命令ではなく要請 |
| アクセス認可 | 権限のない相手のアクセスを技術的に遮断する仕組み(robots.txtはこれに該当しない) |
| noindex | 検索結果への掲載そのものを制御する、robots.txtとは別の仕組み |
robots.txtは、何の仕組みなのか
robots.txtの仕様を定めたRFC 9309(IETF Standards Track、2022年9月発行)は、Introductionの末尾に独立した一文でこう書いています。「These rules are not a form of access authorization.」——これらのルールはアクセス認可の一形式ではない、という宣言です。
この一文が意味するのは、robots.txtがパスワード認証やファイアウォールのような、破ったら技術的に弾かれる仕組みではないということです。robots.txtが規定しているのは、あくまで「良識あるクローラーが自主的に従う、クロールに関する取り決め」です。従うかどうかはクローラー側の実装に委ねられており、悪意のあるクローラーやスクレイパーは最初からこの取り決めを無視して動きます。
なぜ「Disallow」を「禁止」だと誤読してしまうのか
この誤解が起きるのは、不注意のせいではありません。ファイル名が「robots」、記述されるディレクティブが「Disallow」という、日常語としては強い禁止のニュアンスを持つ単語だからです。人は見慣れない技術仕様に出会ったとき、まず単語の意味から動作を推測します。「Disallow=許可しない」という言葉を見れば、「そこにはアクセスできなくなる」と読むのは自然な反応です。
しかし実際にrobots.txtが担っているのは、アクセスの可否ではなく「クロールしてよいかどうかの意思表示」です。ウェブサーバーがそのパスへのリクエストを技術的に拒否しているわけではなく、「クロールしないでください」という取り決めをファイルに書いて置いているだけです。取り決めを守る主体は、あくまでクローラー側の実装であり、ファイルそのものに強制力はありません。
この取り違えが実害につながるのは、次に説明する「公開ファイルである」という性質と組み合わさったときです。
Disallowに書いたパスは、そこで初めて世界に公開される
RFC 9309のSecurity Considerations(セキュリティ上の考慮事項)は、次のように警告しています。「Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable.」——robots.txtにパスを列挙することは、そのパスを公開し、発見可能にする、という指摘です。
robots.txt自体は、誰でもブラウザから直接開ける公開ファイルです。管理画面へのパスや、公開前のステージング環境へのパスを「隠すために」Disallowへ書いてしまうと、そのファイルを見た第三者に「ここに何かがある」と教えることになります。隠したいという意図と、実際に取っている行動が正反対の結果を生む典型例です。本当に見られたくないパスは、robots.txtに書くのではなく、認証やアクセス制御など、技術的にアクセスを遮断できる別の仕組みで守る必要があります。
robots.txtが読めないとき、クローラーはどう動くのか
もう一つ、見落とされやすい仕様があります。robots.txtの取得を試みたとき、サーバーがどう応答するかによって、クローラーの挙動が正反対になるという規定です。
RFC 9309では、HTTPの応答が400番台(Unavailable。ファイルが存在しない等)の場合、クローラーはサーバー上の任意のリソースにアクセスしてよいとされています。一方、応答が500番台(Unreachable。サーバー側のエラー)の場合は、クローラーは完全な禁止(complete disallow)を仮定しなければならないとされています。
言い換えると、robots.txtを置き忘れている状態(404)は「全面許可」に倒れ、サーバーが一時的に落ちている状態(5xx)は「全面禁止」に倒れます。この2つは似たような「robots.txtが読めない状況」に見えますが、結果は正反対です。サイト移行やサーバー障害の際にrobots.txtが一時的に取得不能になると、意図しないタイミングで全面許可・全面禁止のどちらかに切り替わってしまう可能性がある、という点は覚えておく価値があります。
Disallowしたのに、検索結果に出てくる理由
Google検索セントラルの公式ドキュメント(最終更新2025年12月10日)は、robots.txtについてこう説明しています。「it is not a mechanism for keeping a web page out of Google」——ウェブページをGoogleから排除するための仕組みではない、という明言です。
具体的には、robots.txtでdisallowされたページであっても、他のサイトからリンクされていれば、Googleにインデックスされる可能性があります。ただしその場合、検索結果にはページの中身を要約した説明文(スニペット)が付きません。Googleはページ本文をクロールしていないため、内容を要約できないからです。「Disallowしたのにインデックスされている」という現象は不具合ではなく、この仕様どおりの挙動です。
確かなことと、まだ確かではないこと
確かなこと:RFC 9309が、robots.txtをアクセス認可の仕組みではないと明記していること。Disallowに列挙したパスが公開情報になること。400番台と500番台でクローラーの挙動が正反対になると規定されていること。Google公式ガイドが、robots.txtを検索結果からの排除手段ではないと説明していること。
まだ確かではないこと:これらはRFC 9309(標準仕様)とGoogleのクローラーの挙動にもとづく整理であり、すべての検索エンジン・AIクローラーが同じ挙動をするとは限りません。自社サイトが使っているCMSやサーバーが、RFC 9309にどこまで厳密に準拠した形でrobots.txtを配信できているかも、個別に確認が必要です。
判断軸の提示
ここまでの整理から、robots.txtを編集するときの判断軸を1つ提案します。
「クロールしてほしくない」と「見られたくない・隠したい」を、別の要求として扱うこと。
前者はrobots.txtの役割であり、良識あるクローラーへの意思表示として機能します。後者は認証やアクセス制御など、技術的にアクセスを遮断できる仕組みの役割です。この2つを同じ1つのファイルで解決しようとすると、robots.txtに書いたパスが公開されてしまう、あるいはDisallowしたのにインデックスされ続けるといった、意図と結果のずれが起こります。
自分でも試せる、最小の検証
自社サイトのrobots.txt(https://自社ドメイン/robots.txt)を開き、Disallowに列挙されているパスを1つずつ確認してください。その中に、本当は存在自体を知られたくない管理画面や社内向けページのパスが含まれていないかを見ます。
もし該当するパスが見つかった場合、それはrobots.txtの設定ミスではなく、「隠す」という目的に対して間違った道具を使っている状態です。そのパスを本当に守りたいなら、robots.txtから削除したうえで、認証やIPアドレス制限など、アクセスそのものを技術的に制御できる仕組みに切り替える必要があります。
この記事で扱ったような、自社サイトの技術的な設定を整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。
状況を整理する(15分)