robots.txtの書き方|disallow設定と確認手順の基本
この記事の要点
- robots.txtはクロールを制御するファイルで、インデックス削除には使えない
- 基本はUser-agent・Disallow・Allow・Sitemapの4要素で組み立てる
- 2026年はAI学習用クローラーへの対応と定期的な見直しが必須
robots.txtを触りたいけれど「1行間違えるとサイト全体が検索から消えるのでは」と手が止まっていませんか。この不安はもっともで、実際に本番で事故が起きやすいファイルです。
この記事では、robots.txtの書き方とdisallowの設定手順を、コピペで使える記述例つきで解説します。AI学習クローラーへの対応や、設定後の確認方法、noindexとの違い、現場でやりがちな失敗までまとめました。読み終わるころには、自社サイトに安全な1枚を用意できる状態になります。
Contents / 目次
robots.txtの結論。まず押さえる4つの要素と役割

結論からお伝えします。robots.txtは「検索エンジンのクローラーに、どのURLを見に来ていいか/来ないでほしいかを伝えるための指示書」です。つまり、サイトの入口に立って交通整理をする案内係のような役割を持ちます。
ここで最初に理解してほしい大事な線引きがあります。robots.txtは「クロール(巡回)を止めるファイル」であって、「インデックス(検索結果への登録)を消すファイルではない」という点です。この違いを取り違えると、後述する失敗の多くにつながります。
robots.txtで扱う指示は、たった4つの要素で組み立てられます。まずはこの4つの役割を押さえましょう。
| 要素 | 意味 | 使いどころ |
|---|---|---|
| User-agent | どのクローラー向けの指示かを指定する | 全クローラーなら「*」、特定ボットなら名前を書く |
| Disallow | クロールを禁止するパスを指定する | 管理画面・検索結果ページ・重複URLなど |
| Allow | Disallowした中で例外的に許可するパス | 禁止フォルダ内の一部ファイルだけ見せたいとき |
| Sitemap | XMLサイトマップの場所を絶対URLで伝える | サイト全体の構造をまとめて知らせる |
robots.txtとは、この4要素を組み合わせてクローラーへの案内ルールを書いたテキストファイルのことです。難しいプログラムではなく、メモ帳で書ける単純なテキストです。だからこそ、記述ミスがそのまま事故につながるので、書き方の型を正しく覚えることが安全への近道になります。
ポイント。robots.txtは必ずサイトのルート(例 https://example.com/robots.txt)に1枚だけ置きます。サブフォルダに置いてもクローラーは読み取りません。
robots.txtの書き方。安全に作る5ステップ

ここからは実際の作り方を、手を動かせる順番で解説します。いきなり本番サーバーを書き換えず、下書き→確認→反映の流れで進めるのが事故を防ぐコツです。次の5ステップで進めましょう。
ステップ1。禁止したいURLを棚卸しする
最初にやるのは記述ではなく、洗い出しです。「クローラーに見に来てほしくないURL」を紙かメモに書き出します。ここが曖昧だと、後の記述で迷子になります。
棚卸しの対象になりやすいのは、検索結果に出す必要がなく、かつ数が多くてクローラーの負担になるページです。代表例を挙げます。
- 管理画面・ログイン系:/wp-admin/ など運用者しか使わない領域
- サイト内検索の結果ページ:/?s= のような無限に増えるURL
- カート・購入手続き:/cart/ や /checkout/ など個人ごとのページ
- パラメータ付きの重複URL:並び替えや絞り込みで生成される ?sort= 系
ステップ2。基本の記述をテキストで書く
棚卸しが終わったら、実際の記述に落とします。WordPressサイトを例にした、そのまま出発点に使える基本形がこちらです。自社の状況に合わせて中身を変えてください。
# robots.txt for example.com 最終更新 2026-07-10
# [自社ドメインとパスに合わせて書き換える]
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /?s=
Disallow: /cart/
Disallow: /checkout/
Sitemap: https://example.com/sitemap.xml
読み方を補足します。1行目の「#」で始まる行はコメントで、クローラーは無視します。更新日や目的をメモしておくと、後で見返したときに助かります。
「User-agent: *」は「すべてのクローラーに対して」という意味です。続く「Disallow: /wp-admin/」で管理画面を巡回対象から外し、その直後の「Allow」で、動作に必要な admin-ajax.php だけは例外的に許可しています。最後のSitemap行は、必ず「https://」から始まる絶対URLで書くのがルールです。
ステップ3。AI学習クローラーへの方針を決める
2026年に新しく必要になったのが、この判断です。従来の検索用クローラーとは別に、生成AIの学習のためにサイトを巡回するクローラーが登場しています。自社の記事や画像をAIの学習に使われたくない場合は、robots.txtで意思表示ができます。
AI学習用クローラーを拒否したい場合の記述例です。代表的なUser-agent名やコントロールトークンを並べています。ただしクローラー名やコントロールトークンは各社の判断で追加・変更されるため、最新の正確な名称は各社の公式ドキュメントで確認してください。
# AI学習用クローラーを拒否する例(名称は各社公式で最新を確認)
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
ここで注意したいのは、AI学習用クローラーの指定が検索インデックスやAI検索の露出にどう影響するかは、各社の仕様によって異なるという点です。指定できる項目や対象範囲も変わることがあります。実際に設定する前に、各クローラーを提供する会社の公式ドキュメントで最新の内容を必ず確認してください。
robots.txtは「善意のクローラー」への依頼にすぎません。ルールを無視して巡回する悪質なボットも存在します。 どうしても遮断したい相手には、サーバー側やCDNでのIP単位のブロックなど、別の手段が必要になります。
ステップ4。ルートにアップロードする
書き上げたファイルは、必ず「robots.txt」というファイル名(すべて小文字)で保存し、サイトのルートに置きます。FTPソフトやサーバーのファイルマネージャーで、トップページの index ファイルと同じ階層にアップロードします。
WordPressの場合、SEO系プラグインの管理画面から編集できることも多いです。ただしプラグインの画面名やメニューはバージョンで変わるため、正確な操作は使用中プラグインの公式ヘルプで確認してください。どの方法でも、最終的に「https://自社ドメイン/robots.txt」でファイルが表示されればOKです。
ステップ5。反映後に必ず確認する
アップロードしたら、放置せず必ず動作を確認します。まずブラウザのアドレス欄に「https://自社ドメイン/robots.txt」と入力し、書いた内容がそのまま表示されるかを見ます。ここで古い内容やエラーが出るなら、置き場所かキャッシュを疑います。
次に、Google Search Consoleでクロール状況を確認します。 記述の詳しいルールは、Google公式の「robots.txt の作成」で解説されているので、迷ったら一次情報にあたるのが確実です。 設定を反映したあとの点検には、SEO内部対策のチェックリストもあわせて使うと抜けが減ります。
robots.txtを整えると何が変わるのか

結論として、robots.txtの整備は「検索順位を直接上げる魔法」ではありません。しかし、サイトの土台を安定させ、間接的にSEOを支える効果があります。ここを誤解すると期待外れになるので、正確にお伝えします。
いちばん大きな効果は、クロールバジェットの最適化です。クロールバジェットとは、ひとことで言うと「検索エンジンが自社サイトを巡回してくれる回数の予算」のことです。この予算には限りがあります。
もし検索結果ページやパラメータ違いの重複URLが大量にあると、クローラーはそうした重要度の低いページの巡回に予算を使い果たしてしまいます。robots.txtで無駄なURLへの巡回を止めれば、その分の予算を、本当に見てほしい商品ページや記事に回せます。とくにページ数の多い大規模サイトほど、この差が効いてきます。
成果を出しているサイトに共通するのは、次のような状態です。
- 重要ページに巡回が集中している:新しい記事や更新が、検索結果に早く反映される
- サーバー負荷が下がっている:不要な巡回が減り、表示速度の悪化を防げる
- 不要な重複URLへの巡回を抑えられる:ただし重複ページの評価集約はrobots.txtの役割ではなく、canonicalやnoindexで行う点に注意(Disallowはクロールを止めるだけで、被リンクがあればブロック済みURLもインデックスされ得る)
もう一点、地味ですが重要な効果があります。ステージング環境(公開前のテスト用サイト)を守れることです。robots.txtとあわせて適切な設定をしておけば、未完成のページが検索に出てしまう事故を防げます。robots.txtは派手な施策ではありませんが、こうした「守りの効果」でサイト全体の信頼性を底上げしてくれます。スマホでの見え方も含めた土台づくりについては、モバイルファーストインデックス対応のチェック項目も参考になります。
robots.txtでやりがちな失敗と回避法

ここが、この記事でいちばん読んでほしい部分です。robots.txtは1文字の違いが大きな事故になります。現場で本当によく見かける失敗を、起きる状況・結果・防ぎ方のセットで4つ紹介します。
失敗1。テスト用の全ブロックを本番に持ち込む
これは最も多く、最も被害が大きい失敗です。開発中はサイト全体を隠すために「Disallow: /」(全ページ禁止)と書きます。この設定を、公開時に消し忘れて本番サーバーにそのままアップロードしてしまうのです。
失敗2。noindexのつもりでDisallowを使う
「このページを検索結果に出したくない」と思ってDisallowで巡回を止める、という取り違えもよく起きます。冒頭でも触れた、robots.txtの役割を誤解したパターンです。
Disallowでクロールを止めても、他サイトからリンクされていれば、そのURLは検索結果に表示されることがあります。しかもクローラーが中身を読めないため、説明文が変な形で出ることもあります。
検索結果から確実に消したいページには、robots.txtではなく、そのページ自体に「noindex」の指示(メタタグまたはX-Robots-Tag)を入れます。この場合、noindexを読ませるためにあえてクロールを許可する必要がある点にも注意してください。
失敗3。CSSやJavaScriptをまとめてブロックする
「関係なさそうなフォルダは念のため全部止めておこう」と考え、CSSやJavaScriptの入ったフォルダごとDisallowしてしまうケースです。よかれと思ってやる分、たちが悪い失敗です。
これらのファイルはページの見た目やレイアウトを組み立てる部品です。ブロックするとGoogleがページを正しくレンダリング(描画)できず、「崩れた低品質なページ」と誤解されて評価が下がることがあります。 防ぎ方は、デザインや動作に関わるファイルは止めないと最初から決めておくことです。Search Consoleでブロックされたリソースが報告されていないか、定期的にチェックすると安心です。
失敗4。大文字・小文字やサブドメインを見落とす
Googleのrobots.txt仕様では、パス指定は大文字と小文字を区別すると明記されています。 「/Admin/」と「/admin/」は別物として扱われるため、片方だけ書いて安心していると、もう片方が素通りになります。
また、サブドメイン(例 shop.example.com)は、それ自体に別のrobots.txtが必要です。本体ドメインのrobots.txtは、サブドメインには効きません。 防ぎ方は、実際のURLの表記をコピーして正確に書くこと、そしてサブドメインごとに1枚ずつファイルを用意することです。小さな見落としが抜け穴になるので、書いたら実URLで一つずつ照合しましょう。
robots.txt運用の落とし穴と、任せどころの本音
最後に、教科書には載りにくい現場の本音をお伝えします。robots.txtは「一度書いたら終わり」のファイルではなくなっています。ここを知っておくと、判断を誤りません。
かつては、robots.txtは一度設定すれば数年放置できるものでした。しかし2025年以降、AI関連のクローラーが次々と登場し、状況が変わりました。新しいクローラーが出るたびに「これは許可するのか、拒否するのか」を判断し直す必要が出てきています。 放置していると、知らないうちに自社コンテンツが大量に持ち出される、という事態も起こり得ます。
そしてもう一つ、正直にお伝えしたい妥協点があります。robots.txtで拒否と書いても、それを守るかどうかは各クローラーの良心に委ねられているという事実です。行儀のよい検索エンジンは従いますが、無視して巡回するボットも実在します。
つまり、robots.txtは「お願い」であって「防壁」ではありません。本気で遮断したいなら、サーバーやCDNでのブロックといった、別レイヤーの対策とセットで考える必要があります。
内製と外注の切り分けで言えば、線引きはこうです。小規模なサイトで、止めたいURLが管理画面や検索結果ページ程度なら、この記事の記述例をベースに自社で十分対応できます。一方で、ECサイトや大規模メディアのように、次のような段階になると、1行の判断ミスが売上に直結します。
- パラメータ付きURLが数万単位で存在する
- 複数のサブドメインをまたぐ
- AIクローラーの流入を細かく制御したい
ここは無理に独力で抱え込まず、公開前に第三者の目を通す価値が高い領域です。
判断の目安。「本番のrobots.txtを書き換えるのが怖い」と感じたら、それは慎重さの表れであり正しい感覚です。怖いまま勘で反映するより、確認手順を一つ増やすか、詳しい人に一度見てもらうのが安全です。
よくある質問
robots.txtは必ず作らないといけないの?
必須ではありません。ファイルがなければ、クローラーは全ページを巡回してよいと判断します。 小規模サイトなら無理に作る必要はありませんが、管理画面や重複URLを除外したい、AIクローラーを制御したい場合は用意すると効果的です。
Disallowを書けば検索結果から消える?
消えません。Disallowは巡回を止めるだけで、検索結果への表示を防ぐものではありません。 他サイトからリンクされていればURLが表示されることもあります。 確実に消したいなら、ページ側にnoindexの指示を入れてください。
設定を変えたら、すぐ反映される?
すぐには反映されません。反映されるのはクローラーが次にrobots.txtを読みに来るタイミングで、所要時間はサイトやクローラーによって大きく異なります。急ぎのときはSearch Consoleから確認と再取得を促すのが確実です。
AIクローラーは全部ブロックすべき?
一律にする必要はありません。自社コンテンツを学習に使われたくないなら拒否、と目的で決めます。指定が何に影響するかは各社の仕様によって異なるため、各クローラーの公式ドキュメントを確認したうえで、切り分けて判断するのがおすすめです。
robots.txtの見直しに不安があるときは
ここまで読んで、「手順は分かったけれど、本番で書き換えるのはやっぱり怖い」と感じた方もいると思います。robots.txtは影響範囲が大きいぶん、その慎重さはとても正しい感覚です。自社サイトのどこを止め、どこを残すべきか、現状を一緒に整理するだけでも構いません。コレットラボではSEOの土台づくりからご相談を承っていますので、気になった方はお気軽にお声かけください。まずは現状を聞かせていただくところから始めましょう。
30分の無料相談
現状をお聞きし、優先順位を一緒に整理します。
予約する →