「robots.txt を書きたいが、構文や注意点が分からない」と悩んでいませんか。本記事では、中小企業のSEO担当者向けに、robots.txtの基本構文（User-agent / Disallow / Allow / Sitemap）、よく使う5パターンのコピペ例、設置場所、確認方法、noindexとの使い分け、よくある失敗と対策、運用ルールまで体系的に解説します。記述ミスでサイトの検索流入を消さないための実務ガイドです。
robots.txtとは｜検索エンジンに「巡回ルール」を伝えるテキストファイル
robots.txt とは、検索エンジンのクローラーに「どのページを巡回してよいか／ダメか」を伝えるテキストファイルのことです。サイトのルートディレクトリに置く形式で、SEO 担当者が押さえるべき基本ルールが詰まっています。
robots.txtの役割（クロールの制御）
robots.txt の主な役割は、クロール（巡回）の制御です。クローラーとは、検索エンジンがWeb上のページを巡回するプログラムのことです。例えば、Googlebotがサイトを訪問してページを読み込む動きを指します。
robots.txt で「ここから先は読み込まないでください」と指示することで、不要なクロールを抑制できる仕組みです。サーバー負荷の軽減や、低品質ページのクロール回避に役立ちます。
誰が読むファイルか（クローラー＝Googlebot 等）
robots.txt を読むのは、検索エンジンのクローラーです。代表的なクローラーは次の通りとなります。
- Googlebot：Google検索のクローラー
- bingbot：Microsoft Bing のクローラー
- DuckDuckBot：DuckDuckGo のクローラー
- AhrefsBot / SemrushBot：SEOツールのクローラー
- ChatGPT-User / GPTBot：OpenAI のクローラー（生成AI学習用）
ユーザーが読むファイルではなく、ロボット同士の通信ルールという位置づけです。
noindex / canonical との違いを1枚で整理
robots.txt は noindex や canonical と混同されがちです。役割を整理します。
- robots.txt：クロール（巡回）自体を拒否する
- noindex：クロールは許可、検索結果に表示しない
- canonical：複数URLのうち「正規版」を指定する
3つは目的が異なるため、組み合わせて使う場面が多くなります。混同を防ぐには、「クロール／インデックス／正規化」の3軸で考える発想が要点です。
robots.txt基本構文｜4つのディレクティブを押さえる
robots.txt の基本構文は、4つのディレクティブで構成されます。User-agent / Disallow / Allow / Sitemap の4つを押さえれば、ほぼすべてのケースに対応できます。
対象クローラーを指定
User-agent: *必ず最初に書く。
「*」は全クローラー指定
クロール禁止パスを指定
Disallow: /admin/管理画面・会員ページ等
Disallow配下で例外許可
Allow: /admin/admin-ajax.phpWPのajaxエンドポイント等
サイトマップXMLのURL指定
Sitemap: https://example.com/sitemap.xmlクロール効率化のため
最低限この1行は入れる
User-agent｜対象クローラーの指定
User-agent は、ルールの対象クローラーを指定するディレクティブです。
User-agent: *
* は「全クローラー」を意味します。特定クローラーだけを対象にしたい場合は、User-agent: Googlebot のように記述する形式です。
Disallow｜クロール禁止のパス指定
Disallow は、クロールを禁止するパスを指定するディレクティブです。
Disallow: /admin/
Disallow: /private/
これで /admin/ 配下と /private/ 配下がクロール対象外になります。複数のDisallow行を並べる形で、複数パスを指定できる構造です。
Allow｜Disallow配下で例外的に許可
Allow は、Disallow で禁止したパスの中で「ここだけは許可」する例外を指定するディレクティブです。
Disallow: /admin/
Allow: /admin/public-info.html
このようにすれば、/admin/ 配下は基本クロール拒否ですが、/admin/public-info.html だけはクロール許可される設定になります。
Sitemap｜サイトマップのURLを指定
Sitemap は、サイトマップ XML の場所を伝えるディレクティブです。
Sitemap: <https://example.com/sitemap.xml>
サイトマップを明記すると、クローラーが効率よくサイト構造を把握できる仕組みです。中小企業のサイトでも、最低限この1行は入れておく価値があります。
中小企業のサイトでよく使う5パターン
robots.txt の書き方は、サイトの規模や構成で変わります。中小企業のサイトで実際に使われる5パターンを整理しました。コピペで使える具体例つきです。
パターン1｜全クローラーに全許可（基本形）
最もシンプルな基本形です。全クローラーにすべてのページを巡回させる構成となります。
User-agent: *
Disallow:
Sitemap: <https://example.com/sitemap.xml>
「Disallow:」のあとに何も書かない場合、すべて許可の意味になります。最初の1枚として扱いやすい形です。
パターン2｜管理画面・会員ページを除外
WordPress サイトでよく使われる形式です。管理画面と会員専用ページをクロール対象から外します。
User-agent: *
Disallow: /wp-admin/
Disallow: /members/
Allow: /wp-admin/admin-ajax.php
Sitemap: <https://example.com/sitemap.xml>
Allow で admin-ajax.php を許可しているのは、サイトの動的機能を正しく動かすためです。
パターン3｜開発・テスト環境を完全遮断
開発環境やステージング環境にrobots.txt を置く場合、サイト全体を遮断する形式が標準です。
User-agent: *
Disallow: /
Disallow: / でルート以下すべてをクロール拒否します。本番環境に間違ってこの記述を残すと致命的なため、後述の運用ルールで予防が必要です。
パターン4｜特定クローラーのみブロック
特定のSEOツールクローラーや、AIクローラーをブロックしたい場合の形式となります。
User-agent: AhrefsBot
Disallow: /
User-agent: GPTBot
Disallow: /
User-agent: *
Disallow:
最後に「全クローラーには全許可」を入れることで、それ以外のクローラーへの影響を防ぎます。
パターン5｜サイトマップを明記
最後に、サイトマップ明記の重要性を改めて整理します。
User-agent: *
Disallow:
Sitemap: <https://example.com/sitemap.xml>
Sitemap: <https://example.com/news-sitemap.xml>
サイトマップが複数ある場合は、複数行で記載できる構造です。中小企業のサイトでも、ニュース／ブログ／製品ページなどでサイトマップが分かれている場合があります。
robots.txtの設置場所と確認方法
robots.txt は「サイトのルートディレクトリ」に置くのが鉄則です。設置後は、確認手順で動作を検証してください。
設置場所｜https://example.com/robots.txt
設置場所のルールは1つだけで、「サイトのルート直下」です。
- 正しい：
<https://example.com/robots.txt> - 間違い：
<https://example.com/seo/robots.txt>（サブディレクトリは無効） - サブドメイン：
<https://blog.example.com/robots.txt>（別ファイルが必要）
サブドメインを使う場合は、それぞれのサブドメインごとにrobots.txt を置く必要があります。
Search Console「robots.txt テスター」での確認
Google Search Console の「robots.txt レポート」または旧「robots.txt テスター」で、構文エラーや動作を確認できます。
- 構文エラーの有無
- 特定URLがクロール許可されているか
- Google が読み込んだ最新のrobots.txt
中小企業のSEO担当者は、設置直後とその後の変更時に毎回チェックする運用を推奨します。
ブラウザで直接アクセスして表示確認
最も手軽な確認方法は、ブラウザでrobots.txt に直接アクセスすることです。
<https://自社ドメイン/robots.txt> を開いて、意図通りの内容が表示されているか確認します。3秒で完了する確認方法のため、変更直後は毎回実施することを推奨します。
noindexとの使い分け｜「クロール」と「インデックス」を分けて考える
robots.txt と noindex は混同されがちですが、役割が異なります。中小企業の SEO 担当者が押さえる「使い分けの判断基準」を整理しました。
robots.txt＝クロール拒否、noindex＝表示拒否
両者の役割を1行で整理します。
- robots.txt：クローラーがページを読みに来ない（巡回拒否）
- noindex：クローラーは読むが、検索結果に表示しない（表示拒否）
「クロール」と「インデックス」を分けて考えるのが、使い分けの出発点となります。
両者を併用するとnoindexが効かない罠
意外と知られていない罠が、「robots.txt と noindex を併用するとnoindex が効かない」点です。
robots.txt でクロール拒否すると、クローラーはページを読み込めません。読み込めなければ、ページ内に書かれた noindex タグも認識できない構造になります。
「検索結果に出したくない」ページには、noindex のみを使い、robots.txt では遮断しない設計が正解です。
ケース別の使い分け早見表
中小企業のサイトでよくあるケース別に、使い分けを整理します。
- 管理画面：robots.txt で Disallow（クロール不要）
- 会員ページ：robots.txt で Disallow（クロール不要）
- サンクスページ：noindex のみ（クロールはOK、表示NG）
- 重複コンテンツ：noindex または canonical（表示制御）
- PDFファイル：X-Robots-Tag で noindex（タグ埋め込み不可）
判断基準を1枚にまとめ、運用ルールに落とし込むのが定石です。
よくある失敗3つと対策｜「Disallow:/」「拡張子ミス」「サイトマップ書き忘れ」
robots.txt の記述ミスは、サイトの検索流入を一瞬で消す危険があります。中小企業で頻発する3つの失敗パターンと、回避するための運用ルールを整理しました。
ステージング用 robots.txt を本番にコピー
サイト全体がクロール拒否→検索流入ゼロ
/admin と /admin/ の違いを誤認
意図しないURLまで遮断
Sitemap行が無くクローラー巡回非効率
新規ページ発見が遅れる
失敗1｜「Disallow: /」を本番に残してサイト全体遮断
最も致命的な失敗が、Disallow: / の本番残しです。開発環境の robots.txt をそのまま本番にコピーしてしまうと、サイト全体がクロール拒否となり検索流入がゼロになります。
対策は、本番反映前のチェックリスト整備です。リリース前に robots.txt の中身を目視確認することを運用ルール化してください。
失敗2｜拡張子・パス指定の書き間違い
「Disallow: /admin」と「Disallow: /admin/」では意味が異なります。前者は /admin で始まるすべてのURL（/administrator も含む）を拒否、後者は /admin/ 配下のみ拒否です。
対策は、Search Console の「robots.txt レポート」でテスト確認することです。意図したURLがちゃんと拒否／許可されるかを検証してから本番反映する流れにしてください。
失敗3｜サイトマップの記述忘れで巡回効率低下
robots.txt にサイトマップ記述を入れ忘れると、クローラーの巡回効率が下がります。新規ページの発見が遅れる構造を招くため、SEO上のロスとなります。
対策は、テンプレ化された robots.txt 雛形の用意です。1行追加するだけで防げる失敗のため、初期設計時に標準で入れるルールにしてください。
robots.txt運用を仕組み化する3ルール
robots.txt は、設置して終わりではなく「サイト運用の仕組み」として管理すべき対象です。中小企業が運用を安定させる3つのルールを共有します。
本番事故を予防
ステージング→テスター→本番→ブラウザ確認の4段階
致命的な検索流入消失を予防
後日の原因特定を容易に
Git コミット or 変更管理シートに日付／変更者／理由
問題発生時の巻き戻しが迅速
想定外ブロックを早期発見
「クロール済み未登録」と「robots.txt ブロック」を確認
長期的な検索資産を守る
ルール1｜本番反映前にステージング環境で動作確認
最初のルールは、本番反映前のステージング確認です。robots.txt の変更は、ステージング環境でテストしてから本番にデプロイする運用ルールを設けます。
- ステージング環境で意図した動作になるか確認
- Search Console テスターで構文エラーを検出
- 本番反映後にもブラウザで再確認
3段階の確認で、致命的事故を予防できる流れになります。
ルール2｜変更履歴を Git / スプレッドシートで管理
2つ目のルールは、変更履歴の管理です。「いつ、誰が、なぜ変更したか」を記録に残します。
- Git運用：robots.txt をリポジトリで管理しコミット履歴に残す
- スプレッドシート：日付／変更者／変更内容／変更理由を記録
履歴があれば、後日の問題発生時に原因特定が容易になる仕組みです。
ルール3｜月次の Search Console チェックで異変を発見
3つ目のルールは、月次のSearch Console点検です。「robots.txt ブロック」エラーがないかを月初に確認します。
- 「インデックス登録」レポートの「クロール済みでインデックス未登録」を点検
- robots.txt によるブロックが意図通りか確認
- 異変があれば即時の調査と修正
長期的に価値を積み重ねる発信を続けるためには、こうした地味な点検が事業の検索資産を守る土台となります。
まとめ｜robots.txtは「クロール制御の基本ファイル」
robots.txt とは、検索エンジンのクローラーに巡回ルールを伝えるテキストファイルです。中小企業のSEO担当者が押さえる要点は、次の3つです。
- 4ディレクティブを押さえる：User-agent / Disallow / Allow / Sitemap
- noindex との使い分けを判断基準で持つ：クロール拒否 vs 表示拒否
- 運用ルールで仕組み化する：本番前確認・履歴管理・月次点検
短期的な作業ではなく、サイトの検索流入を守る「長期運用の仕組み」として位置づけてください。今日からの設置・確認・運用ルール導入で、致命的事故を防ぎながら検索資産を育てていきましょう。
よくある質問
robots.txtは必須ですか？
必須ではありませんが、設置を強く推奨します。設置しないとサイトマップの明示やクローラー制御ができず、SEO上の効率が下がります。中小企業の場合、最低限「サイトマップ明記＋管理画面除外」の2行でも置く価値があります。
robots.txtで指定したパスは100%クロールされなくなりますか？
正規のクローラー（Googlebot等）は従いますが、悪質なクローラーは無視するため100%遮断とは言い切れません。機密情報の保護はrobots.txtではなく、Basic認証やIP制限など別の手段で行ってください。
WordPressのrobots.txtはどう編集しますか？
AIOSEOやRank MathなどのSEOプラグインから編集できます。コード編集が不要なため中小企業に推奨される方法です。手書きで置きたい場合は、サーバーのルートディレクトリにrobots.txtを直接アップロードします。
Disallow: /admin/ と書けば管理画面は守られますか？
クロール拒否はできますが、URLを知っている人のアクセスは制限できません。管理画面のセキュリティはBasic認証・IPアドレス制限・二要素認証など複数の防御策の組み合わせで実現してください。
robots.txtの変更はすぐに反映されますか？
Googleが robots.txt をキャッシュするため、変更が反映されるまで最大24時間程度かかる場合があります。急ぎたい場合は Search Console の「robots.txt テスター」から再取得をリクエストできます。
