Webサイトの技術的な最適化(テクニカルSEO)を進める上で、検索エンジンの動きを正しくコントロールすることは非常に重要です。その中心的な役割を担うのが「robots.txt」です。
本記事では、robots.txtの役割から、よく混同されるnoindexタグとの決定的な違い、そして運用上の注意点について詳しく解説します。
robots.txtとは
robots.txt(ロボットテキスト)は、Webサイトのルートディレクトリに配置するテキストファイルです。検索エンジンのクローラに対して、サイト内のどのディレクトリやファイルにアクセスしてよいか、またはクロールしないかを伝えるための「プロトコル(規約)」です。
- 配置場所
必ずドメインのルート直下(例:https://example.com/robots.txt)に配置する必要があります。 - AIクローラへの対応
近年ではGooglebotなどの検索用クローラだけでなく、ChatGPT(GPTBot)やGoogle GeminiといったAIの学習用クローラも巡回しています。これらAIによるコンテンツ利用を制限したい場合も、robots.txtでUser-agentを指定してブロックすることが実務上の標準となっています。
【重要】robots.txtとnoindexタグの違い
robots.txtの役割は、「クロールの拒否」であり、「インデックス(検索結果への表示)の拒否」ではありません。そのため、検索結果への表示を制御したい場合は、noindexタグを使用しましょう。
- robots.txt(クロールの制御)
クローラがページの中身を読みに行くことを防ぎます。ただし、外部からのリンクがある場合、中身を読まないままURLだけが検索結果に表示されることがあります。 - noindexタグ(インデックスの制御)
クローラがページの中身を読んだ上で、「このページを検索結果に出さないでください」という命令を処理します。
注意点:noindexとrobots.txtの併用はしない
検索結果から消したいページに対して、robots.txtでブロックをかけてはいけません。クローラがそのページを訪問できなくなるため、ページ内に記述されたnoindexタグを認識できず、検索結果に残り続けてしまうからです。
robots.txtを設定すべき対象ページ
通常、コーポレートサイトやブログなどを運用する場合、robots.txtは、「全て許可」で問題ありません。設定が必要になるのは、以下のような特殊なケースです。
- クロールバジェットの節約(大規模サイト向け)
URLが数十万件以上ある大規模サイトの場合、優先度の低いページ(古いアーカイブなど)をブロックすることで、重要なページにクローラを集中させます。 - サーバー負荷の低減
通常はクローラの巡回でサーバーがダウンすることはありません。しかし、動的に生成される複雑なURL(検索フィルタなど)にクローラが無限に入り込み、サーバーリソースを枯渇させる場合は設定をします。
設定対象の具体例:
- ログインが必要なページ:検索エンジンに知らせる必要がない領域。
- サイト内検索結果ページ:低品質な重複URLが無限に生成されるため。
- 巨大なメディアファイル:帯域を著しく消費する動画ファイルなど。
robots.txtで解決できないこと
robots.txtは万能ではありません。あくまでも、クロールの有無を制御するのが目的です。
以下の目的には、適切な別の技術を用います。
- 重複コンテンツ対策(canonical)
似た内容のページが複数ある場合、robots.txtでブロックしても評価の分散は防げません。URLを正規化したい場合は「canonical」タグを使用します。 - 完全な非公開化(Basic認証・IP制限)
robots.txtで指定したパスは、URLを直接入力すれば誰でも閲覧可能です。また、悪意のあるボットはrobots.txtを無視します。機密情報を守るにはサーバー側で「Basic認証」などのアクセス制限をかける必要があります。
robots.txt設定上の注意点
robots.txtの設定ミスはサイト全体の検索流入を失わせるリスクがあります。
実装時には以下の項目を必ず確認してください。
設定内容を事前に確認する
robots.txtの記述を間違えると、本来インデックスされるべきページが取得されず、検索結果にサイトが表示されないという事態になります。
これを防ぐためには、書式を正しく理解するだけでなく、Googleサーチコンソールの「robots.txt レポート」で確認をして、意図した通りの挙動になるかを確認してください。
検索エンジンのインデックスは操作できない
robots.txtはクローラを制御するものであり、検索インデックス(すでに検索結果に出ている情報)を直接制御するものではありません。
たとえば、Disallowを指定しても、すでにインデックスに登録されているコンテンツが即座に削除されることはありません。検索結果から特定のURLを急ぎで削除したい場合は、robots.txtではなく、Googleサーチコンソールの「削除ツール」を使用してください。
Disallowはインデックス登録を完全には阻止できない
robots.txtでクローラの巡回をブロックしても、そのページがインデックス登録されるケースがあります。
Googleの公式ヘルプによると、他のサイトからそのURLへリンクが張られている場合、クローラが中身を読めなくても「URLとアンカーテキスト情報」だけでインデックスを作成することがあります。インデックス登録を確実に拒否したい場合は、robots.txtではなくnoindexメタタグを使用してください。
重複コンテンツへの対応はできない
内容が酷似している「重複コンテンツ」の対策として、robots.txtで片方のURLをブロックすることは推奨されません。
ブロックされたページの評価は正規ページに統合されず、サイト全体の評価が分散したままになるためです。URLの評価を一本化したい場合は、canonicalタグ(URL正規化)を適切に設定してください。
画像やCSS・JavaScriptをブロックしない
HTMLから参照される画像、CSS、JavaScriptファイルをブロックすると、Googlebotがページを正しくレンダリング(描画)できなくなります。
現在のGoogleは、ページがユーザーにどう見えているか、どのようなUX(ユーザー体験)を提供しているかを重視しています。 リソースをブロックして描画が崩れると、コンテンツを正しく認識できないだけでなく、レイアウトの安定性や視認性が低いと判定され、ランキングに悪影響を及ぼす可能性があります。リソースファイルへのアクセスは原則として許可してください。
クローラ以外はアクセス制御できない
robots.txtによる制限は、あくまでクローラが自発的に守る「紳士協定」です。サーバー側で物理的なアクセス制限をかけるものではありません。
重要なフォルダをDisallowで指定しても、URLを知っているユーザーや、robots.txtを無視する悪意のあるボットは自由にアクセスできてしまいます。機密情報を守る場合は、.htaccessによるBasic認証(Digest認証)やIP制限を設定してください。
URLに日本語が含まれているときは、パーセントエンコーディング不要
/tag/キャンペーン/ のように、URLパスに日本語が含まれている場合、AllowやDisallowにパーセントエンコーディング(%E3%82%AD など)を使用する必要はありません。
日本語をそのまま記載し、ファイルを UTF-8 で保存してください。現在のGoogleクローラはマルチバイト文字をそのまま解釈できます。
例:URLパス「/tag/キャンペーン/」を拒否する場合
User-agent:*
Disallow:/tag/キャンペーン/
robots.txtでの拒否指定はサイトマップにも影響する
XMLサイトマップにURLを記載して「巡回してください」と伝えても、robots.txtでそのURLをDisallow(拒否)していれば、クローラは巡回しません。サイトマップとrobots.txtの間で矛盾した指示が出ないよう、整合性を確認してください。
503エラーを絶対に返却しない
robots.txtにアクセスした際、サーバーが503エラー(Service Temporarily Unavailable)を返すと、Googleは「サイト全体がメンテナンス中」と判断し、サイトへのクローリングを全面的に中止します。
正常に稼働しているサイトであれば、robots.txtが必ず 200 OK を返す状態であることを、サーバーログやツールで確認しておきましょう。
まとめ
robots.txtは、検索エンジンのクローラに対して「どのページを優先し、どのページを避けるべきか」を伝える重要な指示書です。
- クロールを「ブロック」するのが役割であり、インデックス登録を防ぐものではない。
- noindexタグとの併用は注意が必要。検索結果から消したい場合はnoindexのみを使用する。
正しい知識を持って設定することで、サイトの巡回効率(クロールバジェット)を最大化し、SEO評価の向上に繋げることができます。具体的な記述方法や、最新のGoogle Search Consoleを使った反映確認の手順については、「robots.txtの書き方から反映方法までの実装手順を解説」で詳しく解説します。






