robots.txtとは、検索エンジンのクローラーに対して「このパスはクロールしないでください」と伝えるためのテキストファイルです。サイトのルートディレクトリ（例: https://example.com/robots.txt）に設置し、クロール対象の制御やXMLサイトマップの場所を指定します。
robots.txtとは何か・なぜ必要か
robots.txt（Robots Exclusion Protocol）は、Webサイトの管理者が検索エンジンのクローラーに対してクロールの許可・拒否を伝えるための標準的な仕組みです。1994年に提案され、現在ではGoogle・Bing・Yahoo!など主要な検索エンジンがすべてサポートしています。
robots.txtが必要になる主な理由は以下の3つです。
- クロールバジェットの最適化 — 管理画面・検索結果ページ・パラメータ付きURLなど、インデックス不要なパスのクロールを抑制し、重要なページへのクロールリソースを集中させる
- サーバー負荷の軽減 — 大規模サイトでは、クローラーのアクセスがサーバー負荷の原因になることがある。不要なパスをブロックすることで負荷を軽減できる
- XMLサイトマップの通知 — robots.txtにSitemapディレクティブを記載することで、検索エンジンにサイトマップの場所を伝えられる
robots.txtでできないこと
robots.txtはクロールを制御するだけで、インデックスを制御する機能はありません。「Disallowしたページは検索結果に出ない」と誤解されがちですが、外部からリンクされている場合はURLだけがインデックスに残ることがあります。インデックスから確実に除外するには、noindex meta タグを使ってください。
robots.txtの基本構文
robots.txtは4つのディレクティブ（命令）で構成されます。テキストファイルとしてサイトのルートに設置するだけで機能します。
User-agent（対象クローラーの指定）
どのクローラーに対するルールかを指定します。*（アスタリスク）はすべてのクローラーを意味します。Googlebotなど特定のクローラーを個別に指定することも可能です。
Disallow（クロール禁止パスの指定）
クローラーにアクセスしてほしくないパスを指定します。パスは先頭一致で評価されるため、/admin/と書くと/admin/以下のすべてのURLがブロック対象になります。
Allow（クロール許可パスの指定）
Disallowで広くブロックしたパスの中で、特定のサブパスだけクロールを許可したい場合に使います。Googleは最も具体的な（長い）パスを優先する仕様です。
Sitemap（XMLサイトマップの指定）
XMLサイトマップの完全なURLを記載します。User-agentブロックの外に記述し、複数のサイトマップがある場合は複数行で指定できます。
実践的なrobots.txtの記述例
実際のWebサイトで使われるrobots.txtの典型的なパターンを紹介します。サイトの規模や構成に応じて、必要なルールを組み合わせてください。
一般的なWebサイトの例
全ページクロール許可（最小構成）
Disallowの値を空にすると「ブロックなし」になります。小規模なサイトで特にブロックするパスがない場合は、この最小構成にSitemapだけ指定するのがシンプルです。
よくある設定ミスとSEOへの影響
robots.txtの設定ミスは、サイト全体のSEOに重大な影響を与える可能性があります。以下のミスは実務で頻繁に発生するものです。
Disallow: / でサイト全体をブロック
最も危険なミスです。開発環境やステージング環境でDisallow: /を設定し、そのまま本番にデプロイしてしまうケース。サイト全体が検索結果から消え、発見が遅れると復旧に数週間〜数ヶ月かかることもあります。
noindexしたいページをrobots.txtでブロック
「インデックスから除外したいからDisallowする」という誤解に基づくミスです。robots.txtでブロックするとクローラーがnoindexタグを読めなくなるため、逆にインデックスに残り続ける可能性があります。Google公式ドキュメントでもこの点は明確に注意されています。
CSSやJavaScriptファイルのブロック
Googleはページをレンダリングして内容を評価するため、CSS・JavaScriptのクロールが必要です。これらをrobots.txtでブロックすると、Googlebotがページを正しくレンダリングできず、コンテンツの評価やCore Web Vitalsの測定に悪影響が出ます。
Sitemapディレクティブの記述ミス
SitemapのURLに相対パス（/sitemap.xml）を使ったり、HTTPSサイトなのにhttpで指定したりするケース。SitemapのURLは完全なURL（絶対パス）で記載する必要があります。
robots.txtのファイルパスが間違っている
robots.txtはドメインのルート直下（https://example.com/robots.txt）に設置する必要があります。サブディレクトリに配置しても検索エンジンは認識しません。また、文字コードはUTF-8で保存してください。
本番デプロイ前の必須確認
ステージング環境でrobots.txtにDisallow: /を設定している場合、本番デプロイ時に必ず解除してください。CI/CDパイプラインにrobots.txtの検証ステップを追加するのが最も確実な対策です。
フレームワーク別の注意点
主要なフレームワーク・CMSごとに、robots.txtの扱いが異なります。フレームワーク固有の挙動を理解しておかないと、意図しないクロール制御になりかねません。
WordPress
WordPressはデフォルトで仮想robots.txtを自動生成し、wp-admin/のブロックとSitemapの指定を含みます。カスタマイズする場合は、ルートディレクトリに実際のファイルを設置するか、Yoast SEO等のプラグインで管理します。
注意点: 「検索エンジンがサイトをインデックスしないようにする」設定（設定 → 表示設定）を有効にすると、robots.txtにDisallow: /が自動追加されます。開発中に有効にして戻し忘れるケースが多発しています。
Next.js
Next.js（App Router）では、app/robots.tsで動的にrobots.txtを生成できます。環境変数で本番/ステージングを切り替えることで、デプロイ事故を防げます。
注意点: public/robots.txtに静的ファイルを設置する方法もありますが、環境ごとの切り替えができないため、動的生成を推奨します。
静的サイト（HTML/Hugo/Gatsby等）
ルートディレクトリにrobots.txtファイルを直接設置します。ビルド時に自動生成する仕組みがない場合は、手動でのメンテナンスが必要です。サイト構成が変わったときにrobots.txtの更新を忘れないよう、ビルドスクリプトに組み込むのがベストプラクティスです。
robots.txt・サイトマップの設定をツールで診断する
robots.txtの構文を理解しても、実際に自分のサイトで正しく設定できているかを確認するのは別の問題です。特に以下のようなケースは、目視では見落としやすいポイントです。
- robots.txtが正しいURLで配信されているか
- XMLサイトマップがrobots.txtで正しく指定されているか
- 意図せずサイト全体をブロックしていないか
- XMLサイトマップの構文や設定自体に問題がないか
CodeQuest.work SEO で一括チェック
CodeQuest.work SEO では、URLを入力するだけでrobots.txtの存在確認・XMLサイトマップの設定状況・メタタグ・構造化データ・Core Web Vitalsなど45項目をまとめて無料診断できます。robots.txtの設定だけでなく、テクニカルSEO全体の健康状態を把握できるため、定期的なチェックに活用してください。
