robots.txtとは?クロール制御の書き方と効く場面・不要な場面【2026年時点】
robots.txtは、サイトのルート直下に置く1枚のテキストファイルです。中身はクローラー向けの通行許可証で、「このパスは取りに来なくてよい」と伝えるためだけに存在します。ところが実務では、検索結果から消すつもりでDisallowを書き、URLだけが残り続ける事故が後を絶ちません。この記事では、RFC 9309の仕様、4つのディレクティブの書き方と優先順位、HTTPステータス別の挙動、noindexとの役割分担、生成AI向け制御の限界を整理します。
まとめ:robots.txtで制御できる範囲と、触らない判断の基準
robots.txtが伝えられるのは、クロールの可否だけです。検索結果への表示可否は伝えられません。Disallowを書いたURLでも、外部リンクなどから存在が知られていれば、スニペットなしのまま検索結果に載ります。確実に消すなら、クロールを許可したうえでmetaタグかHTTPヘッダのnoindexを返すか、404・410を返します。この一点を取り違えた設定は、消せず読まれずという最悪の結果に直結する。
もう一つの判断軸は、そもそも書く必要があるかどうかです。数十ページ規模のコーポレートサイトでは、作り込んでも順位にはまず反映されません。効くのは、絞り込み条件の組み合わせでURLが数万本に膨らむECサイトや、サイト内検索結果を大量に抱える会員サイトです。設定ミスで失うものは、正しく設定して得るものより常に大きい。まずURL総数を数え、クローラーが処理しきれない規模かどうかを確かめてください。
robots.txtの役割と、クロール制御が届く範囲・届かない範囲の定義
検索エンジンにクロールの可否を伝えるUTF-8テキストファイルの正体
robots.txtは、UTF-8でエンコードされたプレーンテキストファイルです。改行はCR、CRLF、LFのいずれでも解釈されます。HTMLでもXMLでもなく、テキストエディタで作って置けば機能する。ファイル名は小文字固定で、https://example.com/robots.txt のようにホストのルート直下から配信されている必要があります。
クローラーは、URLを取得する前にこのファイルを読み、ルールに照らして取得可否を判断します。robots.txtを読む段階では、本文もmetaタグもまだ見ていません。この順序が、noindexとの決定的な違いを生みます。クロールからインデックスまでの流れはクロールからランキングまでの工程で整理しています。
RFC 9309で標準化された仕様と500KiBという解析上限
robots.txtは長らく事実上の慣習でしたが、2022年9月にIETFのStandards Trackとして「Robots Exclusion Protocol」=RFC 9309が発行され、正式な標準になりました。RFC 9309はパーサーに最低500キビバイト(KiB)の処理を求め、Googleの仕様書も同じ500KiBを上限として、超えた部分は無視すると明記しています。キャッシュについては、到達不能な場合を除き24時間を超える使用を避けるべきとされ、Googleも通常24時間キャッシュすると書いています。書き換えても反映は即時ではない。丸一日は旧ルールで巡回される前提で段取りを組んでください。
Disallowでもインデックス登録は止まらない仕組みの理解
Googleの仕様書には、クロールを禁止したページについて「コンテンツはインデックスできないが、URL自体はインデックスされ、スニペットなしで検索結果に表示される場合がある」と書かれています。クロールを止めても、外部リンクやサイトマップ経由でURLの存在は伝わるからです。Googleサーチコンソールの「インデックス登録されましたが、robots.txt によりブロックされました」という警告は、これが原因です。タイトルも取得できないため、検索結果にはURL文字列だけが並びます。
User-agent・Disallow・Allow・Sitemapの記述ルールと優先順位
User-agentでクローラーを指定する際のグループ選択規則
1行目には対象クローラーを書きます。すべてを対象にするなら User-agent: *、Google検索の巡回だけなら User-agent: Googlebot です。User-agent行から次のUser-agent行までが1グループで、その中にDisallowとAllowを並べます。
クローラーは自分のトークン名に完全一致するグループがあればそれだけを読み、無ければアスタリスクのグループを読みます。両方書いた場合、Googlebotは共通グループを無視する。「全体に共通、Googlebotに追加」という書き方は成立しません。個別グループには共通ルールも書き直してください。
DisallowとAllowが競合したときの最長一致と緩い方の採用
Googleは競合するルールを、パスの文字数が最も長いもの、つまり最も具体的なものを優先して解決します。長さが同じで結論が割れるなら、制限の緩い方すなわちAllowを採用します。
Disallow: /admin/ と Allow: /admin/public/ を並べた場合、/admin/public/guide.html はAllow側のパスが長いためクロールされ、/admin/users.html はDisallowが効きます。ディレクトリ単位で閉じてから下層だけをAllowで開ける書き方は、この規則があるから成立します。
ワイルドカード*と行末記号$を使ったパスパターン指定の書き分け
パス指定では2つの記号が使えます。アスタリスクは任意の有効な文字が0個以上続くことを表し、ドル記号はURLの末尾を表します。並び替えパラメータの付いたURLをまとめて外すなら Disallow: /*?sort=、拡張子で切るなら Disallow: /*.pdf$ です。末尾記号を付け忘れると /guide.pdf.html のようなURLまで巻き込むため、拡張子指定では省略しないでください。
Sitemap行の絶対URL指定とcrawl-delay非対応の扱い
Sitemap行だけはUser-agentグループに属さず、ファイル内のどこに書いても全クローラーに伝わります。値は相対パスではなく絶対URLで指定する。一方、巡回間隔を指定する crawl-delay は、Googleがサポートしないと明言しているディレクティブです。Google以外の一部クローラーは独自に解釈します。
| 記述 | Googleの扱い | 実務での使いどころ |
|---|---|---|
| User-agent | サポート | クローラー別のグループ分け |
| Disallow | サポート | 取得させないパスの指定 |
| Allow | サポート | 禁止下層の部分的な解放 |
| Sitemap | サポート | サイトマップの所在通知 |
| crawl-delay | 非サポート | Google向けには使わない |
| noindex | 2019年に処理廃止 | metaタグ側で指定する |
設置場所とHTTPステータス別の挙動から見る運用上の落とし穴
ルートディレクトリ限定という配置制約とサブドメイン単位の分離
クローラーはサブディレクトリのrobots.txtを探しません。/blog/robots.txt を置いても読まれず、必ずホストのルート直下に1枚だけ置きます。ルールが適用される範囲は、robots.txtが配信されているホスト・プロトコル・ポート番号の組み合わせに限定されます。
この制約は、サブドメイン構成のサイトで効いてきます。www側のrobots.txtはshop側には適用されず、個別のファイルが要ります。サブディレクトリでメディアを運用しているなら親ドメインの1枚で足りる。CDNやリバースプロキシを挟む構成では、どのオリジンが返しているかを先に確かめてください。
5xx応答が12時間のクロール停止と30日キャッシュを招く条件
robots.txtが返すHTTPステータスによって、Googleの挙動は大きく変わります。とくに5xxの扱いは、障害時の被害を左右します。
| ステータス | Googleの挙動 |
|---|---|
| 2xx | 内容を通常どおり解釈する |
| 3xx | 5ホップまで追跡し以後404扱い |
| 4xx(429除く) | ファイル不在=全許可とみなす |
| 5xx・429 | 12時間クロールを止める |
| 5xxが継続 | 最大30日は前回キャッシュを使う |
404が返る状態は、全ページ許可と同じ意味になります。ファイルが無いこと自体は障害ではありません。危ないのは5xxで、不安定な12時間はサイト全体のクロールが止まり、その後も最大30日は古いキャッシュで判定され続けます。robots.txtだけは静的配信にし、アプリケーション層の障害に巻き込まれない構成が安全です。
ステージング環境の全ページ拒否設定を本番へ持ち込む事故の防ぎ方
公開直後に検索結果からサイトが消える事故の原因は、ほぼこれ一つです。開発環境で全ページを拒否する設定を書き、そのファイルを本番へデプロイしてしまうパターンです。Disallowでルートを閉じると、トップページを含む全URLの取得が止まります。
- robots.txtを環境別ファイルに分け、デプロイ時に環境変数で切り替える
- 本番リリースのチェックリストに、実配信内容の目視確認を入れる
- 公開当日にGoogleサーチコンソールのrobots.txtレポートで取得結果を確認する
- ステージングの非公開はBasic認証やIP制限で担保し、robots.txtに依存しない
4番目が本質です。ステージングをrobots.txtだけで隠す設計そのものが誤りで、URLを知られれば誰でも閲覧できます。認証で閉じておけば、本番へ持ち込んで困る記述が最初から生まれません。
noindex・canonical・サイトマップとの役割分担と使い分け
2019年9月1日に処理停止したrobots.txtのnoindex記述
かつてrobots.txtにnoindexと書く手法が一部で使われていました。Googleは2019年7月2日に未文書化ルールの整理を告知し、同年9月1日をもってnoindexを含む非公式ルールの処理コードを廃止しています。告知では、これらのルールが全robots.txtの0.001%を除いて他のルールと矛盾し、意図と異なる結果を招いていた点が理由に挙げられました。
代替手段も同時に示されています。クロールが許可されている前提で、robots metaタグまたはHTTPヘッダのnoindexを使うのが最も確実とされ、ページごと消すなら404か410を返す方法も案内されました。metaタグ側の指定値は、廃止済みの値も含めて廃止されたrobots metaタグの経緯と今すべき対応で追えます。
検索結果から確実に削除したいページで使う手段の選択基準と手順
目的別に手段は一意に決まる。クローラーの負荷を減らしたいならDisallow、検索結果から消したいならnoindex、同一内容が複数URLにあって評価が割れているならcanonicalでURLを1本に寄せます。パラメータ違いの束ね方はcanonicalタグによるURL正規化で扱っています。
すでにDisallowをかけたページを消す場合、手順に順序があります。先にDisallowを外してクロールを許可し、その状態でnoindexを返す。この順でなければ、クローラーはnoindexを読めません。禁止したまま待っても、URLは残り続けます。
サイトマップ送信とクロールバジェット配分における実務的な優先度
robots.txtが「来なくてよい場所」を伝えるのに対し、XMLサイトマップは「来てほしい場所」を伝えます。逆方向の施策で、優先度は同じではありません。数千ページ未満のサイトでは、サイトマップを正しく出す方が先です。設計の考え方はサイトマップがSEOとユーザビリティに効く理由で整理しています。
クロールバジェットの配分をrobots.txtで調整する価値が出るのは、生成されるURL総数がコンテンツの実数を大きく上回っているときだけです。目安は、実質的な記事数の10倍を超えるURLがクロール統計に現れているかどうか。そこに達していないサイトで先に手を入れても、順位は動きません。
生成AIクローラー制御でrobots.txtに期待できることの限界
GPTBotとGoogle-Extendedを個別に指定する記述の実例
主要な事業者は、学習用クローラーに専用のトークンを割り当てています。OpenAIは基盤モデルの学習向けにGPTBot、ChatGPTの検索機能で表示するための巡回に OAI-SearchBot を用意し、ユーザー操作を起点とするChatGPT-Userは別扱いとして文書化しています。Googleが学習系に割り当てているトークンはGoogle-Extendedです。
記述は通常のクローラーと同じ形式です。User-agent: GPTBot のグループを作ってDisallowを並べ、検索向けの巡回を残したいなら User-agent: Googlebot には触れません。学習だけを拒むのか、AI検索での引用も拒むのかで指定が変わります。一括で閉じると、AI検索経由の流入まで失う。
Google-Extendedの拒否が検索順位に影響しない理由
Googleは公式ドキュメントで、Google-ExtendedがGoogle検索への掲載に影響せず、ランキングシグナルとしても使われないと明記しています。Googlebotとは独立した製品トークンとして設計されているためです。「AI学習を拒否すると検索順位が落ちる」という懸念は、Googleに関しては成り立ちません。
判断すべきは順位ではなく、生成AIの回答内で引用されることに事業上の価値があるかどうかです。受託開発や専門サービスのように、指名検索と信頼獲得が受注につながる業態なら、学習を拒むより引用されに行く方が合理的です。有料の調査レポートを収益源にしているなら、GPTBotの遮断が理にかなっています。
llms.txtとの補完関係と、両方を設置する場合の運用管理コスト
AI向けの新しい規格としてllms.txtが提案されています。robots.txtがアクセスの可否を伝えるのに対し、llms.txtはサイトの構造と要点を機械が読みやすい形で示す仕様で、目的が重なりません。詳細はllms.txtとAIクローラー対応の考え方で扱っています。
両方を置く判断は、条件を付けて言い切ります。llms.txtは主要な事業者が遵守を約束した標準ではなく、2026年8月時点では提案段階の仕様です。ページ数が数百に達し、更新のたびに要約を保守できる体制があるサイト以外では、設置しない方がよい。中身が古くなったllms.txtは、置いていないより悪い情報を渡します。まずrobots.txtで可否を表明し、llms.txtは運用担当が固定できてから足してください。
robots.txtを新規に作るべきサイトと、触らない方がよいサイト
数十ページ規模のコーポレートサイトで新規設置が過剰になる条件
ページ数が数十から百程度で、動的なパラメータURLをほとんど生成しない構成なら、robots.txtに手を入れる効果はまず出ません。Googleのクローラーは、その規模のサイトを数日で巡回しきります。遮断すべき無駄なURLが存在しないのだから、削るものがない。
この規模で要るのは、Sitemap行を1行書いて所在を伝える程度です。WordPressの動的生成に任せてもかまいません。管理画面のパスを閉じる記述も、SEO上の効果はほぼゼロです。閉じたいURLの一覧を公開ファイルに書き出す点は認識しておいてください。
検索軸の絞り込みURLが大量に生成されるECサイトでの採用条件
作り込む価値が出るのは、URLの組み合わせ爆発が起きているサイトです。カラー・サイズ・価格帯・並び順の4軸で絞り込めるECサイトでは、実商品が1,000点でも生成されうるURLは数十万本に達します。サイト内検索の結果ページや日付単位のアーカイブも同じ性質を持ちます。
- クロール統計の取得URL数が、実コンテンツ数の10倍を超えている
- Googleサーチコンソールで「検出 – インデックス未登録」が数千件単位で滞留している
- 並び順や表示件数だけが違うURLが、サーバーログに繰り返し現れている
2つ以上に当てはまるなら、絞り込みパラメータの遮断に着手します。どれにも当てはまらないサイトで書き換えるのは、リスクだけを負う行為です。着手する場合も1回のリリースで閉じるパターンは1つに留め、クロール統計を2週間見てから次へ進めてください。着手順の全体像はSEO内部対策の優先度にまとめています。
Webサイト制作を開発会社へ委託する際の指示内容と検収確認項目
リニューアルや新規制作を外注するとき、robots.txtは仕様書から抜け落ちがちな項目です。発注側から明示すべき指示は3点あります。ステージング環境の非公開は認証で行うこと。本番用は環境別に管理し、デプロイ時に取り違えない仕組みにすること。静的配信とし、障害時に5xxを返さない構成にすること。
検収時は、本番ドメインのrobots.txtをブラウザで開いて中身を目視し、Googleサーチコンソールのレポートで取得ステータスが正常であることを確認します。加えて、トップページと主要カテゴリのURLをテスターに入れ、許可判定が返るかを見ます。ここまで確認して初めて公開です。内部設計の段階から検索流入の要件を含めて委託したい場合は、SEO内部施策・キーワード設計の支援内容をご確認ください。
よくある質問
robots.txtの設定と確認について、検索でよく尋ねられる質問に答えます。
robots.txtはどこにありますか?確認方法を教えてください
ブラウザのアドレス欄にドメイン名を入れ、末尾にrobots.txtを付けて開けば、現在の内容が表示されます。ルート直下以外のファイルはクローラーに読まれないため、この方法で見えないなら設置されていない状態です。判定を細かく確かめたいときは、Googleサーチコンソールのrobots.txtレポートから、最後に取得された内容とステータスを確認できます。反映には通常24時間程度のキャッシュ期間があります。
robots.txtがなくても問題ありませんか?
問題ありません。ファイルが存在せず404が返る状態は、すべてのクロールを許可する意思表示として扱われます。Googleは429を除く4xxを、有効なrobots.txtが存在しない場合と同じように処理します。数十ページ規模のサイトなら、無理に設置する必要はありません。危ないのは5xxで、12時間クロールが止まり、その後も最大30日は前回のキャッシュで判定されます。「無い」ことと「エラーを返す」ことは意味が違う。
robots.txtでブロックしたページが検索結果に出るのはなぜですか?
クロールを止めても、URLの存在自体は外部リンクなどから伝わるためです。Googleは、クロールを禁止されたページについて内容をインデックスできない一方、URLをインデックスしてスニペットなしで検索結果に表示する場合があると明記しています。検索結果から消すには、Disallowを解除してクロールを許可したうえで、robots metaタグかHTTPヘッダでnoindexを返します。順序を逆にすると、クローラーはnoindexを読めません。
WordPressでrobots.txtを編集するにはどうすればよいですか?
WordPressは実ファイルが無いときにrobots.txtを動的生成して返します。内容を変えるには、SEOプラグインの編集機能を使う方法と、ドキュメントルートに実ファイルを置く方法があります。実ファイルがあればWebサーバーが先に応答するため、動的生成は使われません。編集したのに反映されないときは、まず実ファイルの有無を疑ってください。「設定」の検索エンジン表示設定をオフにしたままだと、生成内容が全面拒否に変わります。
生成AIのクローラーはrobots.txtで拒否できますか?
主要な事業者のクローラーは拒否できます。OpenAIは学習用のGPTBotと検索表示向けの巡回を別トークンで公開し、GoogleはGemini学習やVertex AI向けにGoogle-Extendedを用意しています。指定はUser-agent行で個別に行う。Google-ExtendedはGoogle検索の掲載やランキングに影響しないと明記されているため、検索流入を維持したまま学習だけを拒めます。ただしrobots.txtは強制力のある仕組みではなく、遵守を表明していないクローラーには効きません。
関連記事
- SEO内部対策とは?クロール・インデックス・UXの3分類で施策を優先度順に解説:内部施策の着手順を扱います
- クロール・インデックス・ランキングまでの具体的なフローと全体像:クロールが止まると何が起きるかを追えます
- なぜサイトマップが重要なのか?SEOとユーザビリティの視点から解説:Sitemap行で通知する側の設計をまとめています
- canonicalタグとは?SEOでのURL正規化の目的・書き方・設定方法を解説:重複URLの評価分散をどう束ねるかを扱います
- llms.txtとは何か?AIクローラー対応の新たなrobots規格の概要:AI向け新規格との補完関係を解説しています