robots.txt の書き方 — クロールを制御する
robots.txt は、サイトのどこをクロールしてよいかをクローラーに伝える、サイト直下に置く 1 枚のテキストファイルです。User-agent・Disallow・Allow・Sitemap の 4 種類の行で書きます。ただし robots.txt が止められるのは「クロール」だけで、「インデックス」は止められません。この違いを取り違えると、検索から消したいページが逆に残り続けます。設置場所・書式・よくある事故までを順に解説します。
robots.txt とは何ですか？
robots.txt は、サイトのどこをクロール（巡回）してよいかをクローラーに伝えるテキストファイルです。サイトの直下に 1 つだけ置き、User-agent でクローラーを指定し、Disallow でアクセスを控えてほしいパスを書きます。あくまで「お願い」であり、行儀のよいクローラーは従いますが、無視するボットを技術的に締め出す力はありません。
robots.txt は、検索エンジンや AI のクローラーが最初に読みにくる1 枚のテキストファイルです。 正式には Robots Exclusion Protocol（RFC 9309）として標準化されており、「このサイトのどこを巡回してよいか」をクローラーに伝えます。ここで肝心なのは、robots.txt が示すのは あくまでお願いだという点です。Googlebot のような行儀のよいクローラーは従いますが、悪意のあるボットは 平気で無視します。アクセスを技術的に禁止する仕組みではないことを、最初に押さえてください。
どこに置き、どう書きますか？
必ずサイトのルート直下（https://example.com/robots.txt）に置きます。サブディレクトリに置いても読まれません。中身は User-agent 行でクローラーを指定し、続く Disallow 行でクロールを控えてほしいパス、Allow 行で例外的に許可するパスを書きます。最後に Sitemap 行でサイトマップの場所を絶対 URL で示すのが定番です。
置き場所は 1 か所しかありません。ドメインの直下、つまり https://example.com/robots.txt です。https://example.com/blog/robots.txt のようにサブディレクトリへ置いても、クローラーは見に行きません。 サブドメイン（shop.example.com など）は別サイト扱いなので、それぞれに robots.txt が要ります。
# サイト直下に置く: https://example.com/robots.txt
# すべてのクローラー向けの既定ルール
User-agent: *
Disallow: /admin/
Disallow: /cart/
Allow: /admin/help/ # Disallow の中の例外を許可
# サイトマップの場所は絶対 URL で示す
Sitemap: https://example.com/sitemap.xmlファイルは UTF-8 のプレーンテキストで、1 行に 1 ルールを書きます。# から行末まではコメントです。Sitemap 行だけは User-agent の指定に関係なく全体に効くので、慣習として末尾にまとめて書きます。
User-agent・Disallow・Allow は何を意味しますか？
User-agent は「どのクローラー向けの指示か」、Disallow は「クロールを控えてほしいパス」、Allow は「Disallow の中で例外的に許可するパス」を表します。User-agent: * はすべてのクローラーを指し、Disallow: / はサイト全体、Disallow: /admin/ は特定ディレクトリを対象にします。パスは前方一致で、より具体的なルールが優先されます。
robots.txt で日常的に使うディレクティブは、実質この 4 つだけです。まず User-agent でクローラーを名指しし、 その下に続く Disallow / Allow が、その名指ししたクローラーへの指示になります。
| 行 | 意味 | 例 |
|---|---|---|
User-agent | どのクローラー向けの指示か | User-agent: * |
Disallow | クロールを控えてほしいパス | Disallow: /admin/ |
Allow | Disallow 内で例外的に許可するパス | Allow: /admin/help/ |
Sitemap | サイトマップの場所（絶対 URL） | Sitemap: .../sitemap.xml |
パスは前方一致で判定されます。Disallow: /admin は /admin で始まる URL すべて（/administrator も含む）にかかります。ディレクトリだけを対象にしたいなら、末尾に / を付けてDisallow: /admin/ とします。Allow と Disallow が競合したときは、より具体的（＝マッチする文字数が長い）なルールが勝つのが Google の解釈です。
Disallow すれば検索結果から消えますか？
消えるとは限りません。robots.txt の Disallow はクロールを止めるだけで、インデックス（検索結果への登録）を止める指示ではないからです。外部から被リンクされたページは、クロールされなくても URL やアンカーテキストだけがインデックスされ、検索結果に出ることがあります。確実に消すには、そのページを Disallow せず noindex を使います。
ここが robots.txt で最も誤解されている点です。「クロールを止める」ことと「インデックスを止める」ことは別です。 Disallow はクローラーの巡回を止めますが、検索結果への登録（インデックス）を止めるものではありません。 むしろ Disallow したページに他サイトからリンクが張られていると、Google はそのページの中身を読めないままURL とアンカーテキストだけで検索結果に載せてしまうことがあります。「クロールを禁止したのに検索に出る」という現象は、これが原因です。
| やりたいこと | robots.txt の Disallow | 正しい手段 |
|---|---|---|
| クロールの負荷を減らしたい | ○ 有効 | Disallow でクロールを抑制する |
| 検索結果から確実に消したい | × 不十分（URL だけ残る） | noindex を使う（そのページは Disallow しない） |
| 秘密情報を守りたい | × 逆効果（在り処を公開） | 認証・アクセス制御で保護する |
見せたくないページを robots.txt で隠せますか？
隠せません。むしろ在り処を教えてしまうので逆効果です。robots.txt 自体は誰でも閲覧でき、Disallow に書いたパスはそのまま公開されます。秘匿したい情報は robots.txt ではなく、認証（ログイン必須）やアクセス制御で守ります。検索結果に出したくないだけなら noindex を、そもそも見せたくないならサーバー側で保護するのが正解です。
robots.txt はそれ自体が公開ファイルです。誰でも https://example.com/robots.txt を開けば中身を読めます。 つまり Disallow: /secret-admin/ と書くことは、「ここに管理画面があります」と全世界に案内しているのと同じです。 攻撃者は真っ先に robots.txt を見ます。隠したい場所ほど robots.txt に書いてはいけません。
- 検索に出したくないだけ — noindex を使う（Disallow ではない）
- そもそも見せたくない — ログイン必須にする、IP 制限をかけるなど、サーバー側で保護する
robots.txt はセキュリティの道具ではありません。「巡回のマナーを伝える案内板」であって、鍵ではないと考えてください。
AI クローラーだけを個別に制御できますか？
できます。User-agent にクローラー名を指定すれば、AI クローラーだけを個別に許可・拒否できます。たとえば GPTBot や ClaudeBot といった名前を User-agent 行に書き、その下に Disallow を続けます。ただし従うかどうかはクローラーの良識次第で、名前を偽るボットには効きません。どの AI クローラーをどう扱うかは別記事で整理しています。
User-agent はワイルドカード（*）だけでなく、クローラーの名前で個別に指定できます。 これを使えば、通常の検索エンジンには開放しつつ、生成 AI の学習クローラーだけを拒否する、といった細かい制御が可能です。 名前の一致は先頭一致・大文字小文字を区別しないのが一般的です。
# すべてのクローラーへの既定ルール
User-agent: *
Disallow: /private/
# GPTBot だけ全面的に拒否する
User-agent: GPTBot
Disallow: /
# ClaudeBot は許可する（Disallow を空にする = 制限なし）
User-agent: ClaudeBot
Disallow:ただし、これも相手が名乗りに従い、robots.txt を尊重してくれる前提です。User-agent を偽装するボットには効きません。 どの AI クローラーが何を名乗り、許可・拒否それぞれに何の損得があるかは、GPTBot・ClaudeBot を許可すべきか、拒否すべきかで詳しく整理しています。 「何が書いてあるか」を AI 向けに案内する llms.txt とも役割が異なります。
よくある事故は何ですか？
最も多いのは、開発中に入れた Disallow: / を本番で消し忘れ、サイト全体がクロール拒否される事故です。ほかに robots.txt をサブディレクトリに置いて読まれない、Disallow で隠したつもりの管理画面が URL だけ丸見え、CSS や JS を Disallow してページの描画評価を妨げる、といった失敗があります。公開前に必ず中身を確認します。
robots.txt の事故は、たいてい「1 行の書き間違いがサイト全体に効く」という性質から生まれます。特に多いのが次のケースです。
# ★ 開発中はこれで全ページのクロールを止められる
User-agent: *
Disallow: /
# ↑ この 2 行を本番に残すと、サイト全体が検索から消えていく。
# 「公開時に Disallow: / を消し忘れる」が最も多い事故。- Disallow: / の残置 — 開発・ステージング環境で全面拒否したまま本番へ反映し、サイトが丸ごと圏外になる
- 設置場所の誤り — サブディレクトリに置いて読まれない、サブドメインに置き忘れる
- 秘匿目的の誤用 — 隠したいパスを Disallow に書いて、かえって在り処を公開する
- CSS・JS の Disallow — リソースを塞ぐと Google がページを正しく描画・評価できず、順位に悪影響が出うる
正しく効いているか確認するには？
まずブラウザで自サイトの /robots.txt を開き、意図した内容がそのまま表示されるかを目視します。次に Google Search Console の robots.txt レポートで、Google が最後に読んだ内容とエラーの有無を確認します。特定の URL がクロール可能かは URL 検査ツールで個別に検証できます。公開後も、更新のたびに見直すのが安全です。
robots.txt は書いて終わりではなく、「実際にその内容で配信されているか」の確認までが仕事です。手順はシンプルです。
- 目視 — ブラウザで
https://（自サイト）/robots.txtを開き、意図した内容がそのまま返るか確認する - Search Console — robots.txt レポートで、Google が最後に取得した内容と、構文エラーの有無を見る
- URL 検査 — 特定のページがクロール可能かを、URL 検査ツールで 1 件ずつ確かめる
サイトのリニューアルや CMS の移行では、robots.txt が意図せず差し替わることがあります。公開直後と、更新のたびに見直すのを習慣にしてください。本ツールの診断でも、robots.txt の有無や Sitemap 行の記載を機械的に確認できますが、「その Disallow が本当に意図どおりか」は最後は人が読んで判断する必要があります。