Robots.txt vs Noindex: 違いは何か（そしてそれぞれいつ使うべきか）

この2つは異なる問題を解決する

robots.txtはクロールを制御します — 検索エンジンのボットがそもそもURLを取得することを許可されているかどうかです。noindexタグはインデックス登録を制御します — クロールされたページが検索結果に表示されることを許可されているかどうかです。この2つを混同することは、消したいはずのページが検索結果に残ってしまったり、逆に見つけてほしいページが表示されなくなったりする最も一般的な原因の一つです。

robots.txtが実際に行うこと

robots.txt内のDisallowルールは、行儀の良いクローラーにそのURLを取得しないよう求めるものです。すでにインデックス登録されているページを削除するわけではありません。ブロックされる前にGoogleがそのURLをインデックス登録していた場合、あるいはどこかからリンクされているのを見つけて、ページ自体は取得せずにURLとアンカーテキストだけをインデックス登録していた場合、Googleはブロックを尊重して二度と再クロールしてチェックすることがないため、そのURLを（通常はタイトルや説明文なしで）無期限に表示し続けることがあります。

noindexが実際に行うこと

<meta name="robots" content="noindex">タグ（またはそれに相当するX-Robots-Tag HTTPヘッダー）は、すでにページを取得済みのクローラーに明示的にこう伝えます。読み込んでもよいが、インデックスには入れないでください、と。これは検索結果からページを削除する信頼できる方法ですが、クローラーが実際にそのページを取得し、タグを見ることを許可されている場合に限ります。

典型的な間違い: noindexしたいページもブロックしてしまう

あるURLがrobots.txtで拒否されており、かつnoindexタグも設定されている場合、そのnoindexタグは決して読まれません — クローラーはそもそもページを取得しないよう指示されているため、そのページ上にある指示を見ることができないのです。すでにインデックス登録されていた場合や、どこかからリンクされている場合、そのページはインデックス登録されたままになる可能性があります。Googleはブロックされて読めないタグを読まない限り、それを知る手段がありません。これは、サイトが意図せず何ヶ月も低価値なページを検索結果に残してしまう、実際によくあるパターンです。

robots.txtを使うべきとき

• 大規模サイトでのクロール予算の管理 — 内部検索結果やファセットフィルターの組み合わせといった、低価値で大量のパスからクローラーを遠ざけ、重要なページにより多くの時間を割かせる。
• ステージング環境、管理画面のルート、APIエンドポイントを完全にブロックする。
• コンテンツを確認するためであっても、まったくクロールしてほしくないページ — クロール自体が双方のリソースを消費するため。

noindexを使うべきとき

• 存在してほしく、クロール可能であってほしい（内部リンクのため、ユーザーのため、サイト構造のため）が、検索結果には決して表示させたくないページ — タグ/カテゴリのアーカイブ、1ページ目より先のページネーション、サンクスページなど。
• 完全に削除する準備はまだないが、閲覧者や内部ツールからはアクセスできる状態を保ちたい薄いコンテンツや重複コンテンツ。
• すでにインデックス登録されているページを削除する — これはページがクロール可能なままである場合にのみ機能します。Googleが実際にタグを見られる必要があるためです。

簡単な判断ルール

自問してください。クローラーは、そのページをどう扱うべきかを知るために、このページを読む必要があるか?もし指示がページ自身のコンテンツを見ることに依存しているなら（noindexタグのように）、robots.txtはクロールを許可しなければなりません。ページに何が書かれているかにかかわらずクロール自体を防ぎたいなら、robots.txtが正しい手段であり、noindexは決して読まれないため冗長です。クロール可能だが重複しているだけで完全に不要ではないコンテンツについては、canonicalタグの方がどちらよりも適していることがよくあります。