WEBサイトnoindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目
noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目
01 何が起きたか — 「robots」という名前を共有する3つの設定
止めているものが、3つとも違う
WEBサイトの一部を検索結果から遠ざけたいとき、選べる設定は主に3つある。robots.txt・noindexメタタグ（またはX-Robots-Tagヘッダー）・リンクのrel="nofollow"属性である。どれも「robots」という語を含み、どれも検索エンジンへの指示だという点は共通している。だが公式ドキュメントを読むと、この3つは止めている対象がまったく異なることが分かる。robots.txtは「クロール（サイト内を巡回して情報を集める行為）」を止め、noindexは「インデックス登録（検索結果に載せること）」を止め、nofollowは「リンクを通じた評価の受け渡し」を止める。この違いを整理せずに設定すると、消したいページが消えず、消したくないページのリンク評価だけが失われる、という食い違いが起きる。
公式ドキュメントの構成そのものが、別々の仕組みであることを示している
Google Search Centralのドキュメントを見ると、robots.txtの仕様は「robots.txtの導入」ページに、noindexメタタグとX-Robots-Tagヘッダーは「robotsメタタグ」ページに、そしてnofollow・sponsored・ugcといったリンクの属性は「アウトバウンドリンクの分類」ページに、それぞれ独立して記載されている。3つがまとめて1ページで解説されているわけではなく、目的の異なる別々の仕組みとして扱われていることが、ドキュメントの構成そのものから読み取れる。さらに、この3つの関係を横断的に整理した「インデックス登録のブロック」という別ページも存在し、そこには3つを混同したときに起きる具体的な失敗パターンが明記されている。robots.txt・robotsメタタグ・User-Agentという呼び方の一部にrobotsという語が繰り返し登場するため、「robots関連の設定をどれか1つやっておけば足りる」という誤解が生まれやすい。実際には、robots.txtに書くDisallowと、HTMLの<head>に書くnoindexメタタグは、同じファイルにもタグにも共存していない、別々の場所に置く別々の指示である。この記事では、この3つの設定を型別に整理し、WEBディレクターが自分のサイトで今日から確認できる手順にまで落とし込む。
02 なぜ・背景 — 3つの指示は、届く相手も強さも違う
robots.txtは「お願い」、noindexは「直接指示」
robots.txtは、サイトのルート直下に置くテキストファイルで、どのUser-Agent（クローラー）に対して、どのパスへのアクセスを控えてほしいかを記述する。Googleのクローラーのように仕様に従う（準拠する）クローラーは、robots.txtの指示を尊重してクロールを控える。ただし、これはあくまでクローラー側の任意の協力に依存する仕組みであり、robots.txtの記述自体にアクセスを物理的に遮断する力はない。準拠しないクローラーやツールに対しては、robots.txtは何の効力も持たない。
これに対してnoindexは、そのページ・メディア・リソースを検索結果に表示しないよう、クローラーに直接指示するルールである。設置方法は2通りあり、HTMLページであれば<head>内に<meta name="robots" content="noindex">を置く方法、PDFや画像などHTML以外のファイルであればHTTPレスポンスヘッダーにX-Robots-Tag: noindexを付与する方法がある。この指示が機能するための絶対条件は、クローラーがそのページに実際にアクセスできることである。robots.txtが「お願い」にとどまるのに対し、noindexは「読まれさえすれば確実に従われる直接指示」であるという点で、両者は強さの性質からして異なる。
注意
robots.txtでクロールを禁止したページに、noindexメタタグを書いても効果がない。Google公式ドキュメントは「noindexルールが有効に機能するためには、そのページやリソースがrobots.txtファイルによってブロックされていてはならず、かつクローラーがアクセス可能な状態でなければならない」と明記している(Block Search indexing with noindex（訳: noindexで検索インデックス登録をブロックする）)。さらに「ページがrobots.txtファイルでブロックされている、またはクローラーがそのページにアクセスできない場合、クローラーはnoindexルールを一度も見ることができず、そのページは検索結果に表示され続ける可能性がある」とも書かれている（同ページ）。クロールを禁止した時点で、noindexは読まれる機会そのものを失う。
「nofollow」という同じ語が、実は2つの別物を指している
ここが最も混同されやすい点である。「nofollow」という語は、実は2つの別々の仕組みを指して使われている。1つは、個々の<a>タグに付与するrel="nofollow"属性。もう1つは、robotsメタタグ・X-Robots-Tagの中で指定するページ単位のnofollowルールである。robotsメタタグの仕様は、後者のnofollowルールを「このページ上のリンクをたどらない。このルールを指定しない場合、Googleはページ上のリンクを使用して、リンク先のページを発見する可能性がある」と定義しており(前掲のRobots meta tag仕様)、<meta name="robots" content="noindex, nofollow">のように、noindexと同時に指定する書き方も公式に示されている（同ページ）。つまりそのページ自体を検索結果から外しつつ、そのページ上の全リンクの評価も渡さない、という組み合わせが1つのタグで表現できる。
一方、個々のリンクに付けるrel="nofollow"属性は、ページ全体ではなくそのリンク1本だけを対象にする。「他サイトへのリンクを通じて、自サイトの評価をそのリンク先に渡したくない」「そのリンク先をクロールしてほしくない」という場合に使う。公式ドキュメントは、広告・有料掲載のリンクにはrel="sponsored"を、コメント欄やフォーラム投稿などユーザーが生成したリンクにはrel="ugc"を推奨し、それ以外でリンク先との関連付けを避けたい場合にrel="nofollow"を使うよう案内している(Qualify your outbound links to Google（訳: Googleへのアウトバウンドリンクを分類する）)。同ページには「nofollowは以前この種のリンクに推奨されていたもので、今でも許容される付け方だが、sponsoredの方が望ましい」という記載もある（同ページ）。「ページのmetaタグに書くnofollow」と「個々のリンクに付けるrel="nofollow"属性」は、名前が同じでも対象の粒度が違う別の設定である。
robotsメタタグには、noindex・nofollowのほかにも複数のルールが定義されている。列挙されている値にはall・noindex・nofollow・none（noindexとnofollowをまとめて指定するのと同等）・nosnippet（検索結果に説明文や画像プレビューを出さない）・max-snippet・max-image-preview・max-video-preview・notranslate・noimageindex・unavailable_afterなどがあり、カンマ区切りで複数を同時に指定できる(前掲のRobots meta tag仕様)。これらはすべて「そのページが読まれた後に何をするか」を指示するルールであり、robots.txtのように「読ませるかどうか」を決めるものではない。この階層の違いを押さえておくと、どのルールをどこに書けばよいかで迷いにくくなる。
03 この記事で出てくる用語
用語
クロール：検索エンジンのクローラーがサイト内のページを巡回し、内容を取得する行為そのもの。robots.txtが制御するのはこの行為であって、その後のインデックス登録ではない。
用語
インデックス登録：クロールして取得したページの内容を、検索エンジンのデータベースに登録し、検索結果に表示できる状態にすること。noindexメタタグ・X-Robots-Tagが直接制御するのはこの段階である。
クロールとインデックス登録は、別の段階
この記事全体の前提になるのが、「クロール」と「インデックス登録」は連続してはいるが別の段階だという区別である。robots.txtでクロールを禁止しても、そのURL自体は他サイトからのリンクなどを通じてGoogleに知られることがあり、その場合はURLだけが説明文（スニペット）なしで検索結果に表示されることがある。robots.txtの仕様ページには、この挙動が次のように明記されている。
"Google can't index the content of pages which are disallowed for crawling, but it may still index the URL and show it in search results without a snippet."
（訳: Googleは、クロールを禁止されたページのコンテンツをインデックスすることはできないが、そのURL自体はインデックスされ、スニペットなしで検索結果に表示されることがある。）
(前掲のHow Google interprets the robots.txt specification) 「robots.txtでDisallowにしたのに検索結果からURLが消えない」という症状は、この仕様どおりの挙動であることが多い。robots.txtは「中身を読ませない」ための設定であって、「URLの存在自体を検索エンジンに知られない」ための設定ではない、という点を切り分けて理解しておく必要がある。
04 型別 — 適用範囲・この記事が測っていないこと・手順
🅰 適用範囲 — どの設定を、どんな場面で使うか
検索結果への出方を制御したい場面は、大きく3つに分けられる。第一に「検索結果には出したくないが、サイト内の巡回自体は許してよいページ」にはnoindexを使う。具体的には、会員限定ページ・管理画面のログイン後の画面・絞り込み検索の組み合わせで大量に生成されるファセットナビゲーションのURL・フォーム送信後のサンクスページなどが該当する。第二に「そもそもクローラーに巡回してほしくない領域」にはrobots.txtを使う。開発中や検証用のディレクトリ、内部検索の結果ページ、無限にパラメータの組み合わせが増えるURL群などが該当する。第三に「特定のリンク先とだけ関連付けを避けたい」場合にはnofollow・sponsored・ugcのいずれかをリンクに付与する。この3つは組み合わせて使うものであり、どれか1つで足りるものではない。
制作会社・代理店のようにクライアントサイトを複数運用する立場では、もう一つ確認しておきたい点がある。noindexを外し忘れたまま本番公開してしまう事故は、公開ページ全体が検索結果から消えるという重大な失敗につながる。本番公開の直前チェックに「noindexが残っていないか」の確認を必ず含める運用にしておくと、この種の事故を防ぎやすい。
🅱 この記事が測っていないこと・分からないこと
公式ドキュメントを確認しても、いくつかの点は明確に書かれていない。第一に、robots.txtでブロックしていたページのブロックを解除し、noindexに切り替えた場合、実際に検索結果から消えるまでにかかる具体的な日数は公表されていない。第二に、noindexを設定した直後にどれくらいの頻度でクローラーが再訪してその変更を認識するかも、サイトやページの性質によって変わるため、一律の数字は示されていない。第三に、robots.txtの記述を検索エンジン以外の一般的なクローラー・ボットがどこまで尊重するかは、そのクローラーの実装次第であり、robots.txtの仕様自体はこれを保証しない。「設定したら何日で反映されるか」を一律の数字で語ることはできない。
🅲 手順 — 自分のサイトで確認する流れ
実際の確認は、次の4段階で進める。第一に現状の棚卸しとして、robots.txtの中身と、主要なページ種別ごとのmetaタグ出力を書き出す。第二に矛盾の検出として、robots.txtでブロックしているパスに、noindexが設定されているページが含まれていないかを照合する。第三に実際の見え方の確認として、Google検索のsite:演算子や、Search Consoleの「ページのインデックス登録」レポートで、意図と実際の状態が一致しているかを見る。第四に内部リンクの点検として、noindexを設定したページへ、サイト内の他のページからリンクが張られていないかを確認する。この4段階を実際の作業に翻訳したものが、次章のチェックリストである。
05 明日、自分のサイトで確認できることチェックリスト
まず何を数えるか
ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、現状把握（robots.txtとmetaタグの中身を書き出す）、矛盾の検出（ブロックとnoindexが重なっていないか）、実際の見え方の確認（Search Consoleと実URL）、内部リンクの点検、の4つに分かれる。
実務のヒント
サイト内の全ページを1件ずつ手作業で確認するのは現実的ではない。内部リンクがnoindexページを指していないかをまとめて洗い出したい場合は、当サイトの🔧 WEBサイト内のリンク漏れ・チェックツールで一括確認できる。Search Consoleのレポート名や項目の意味に迷ったときは、🔧 Google Search Console お助けツールで用語と画面の対応を確認すると早い。
- 自分のサイトのrobots.txtを開き、Disallowに指定されているパスを全て書き出す
- 書き出したパスのうち、検索結果に出したくないページと、単にクロールを節約したいだけのページを分けて数える
- 検索結果に出したくないページに、robots.txtのDisallowとnoindexメタタグの両方を同時に設定していないか確認する
- 該当するページを1件選び、Google検索でsite:演算子を使って検索し、説明文なしでタイトルだけ表示されていないか確認する
- トップページ・カテゴリページ・記事詳細ページのソースコードを1ページずつ開き、metaタグが何を出力しているか確認する
- ブラウザの開発者ツールのNetworkタブで3ページ分を開き、X-Robots-Tagヘッダーが付与されているか確認する
- 会員限定ページや管理画面を5件選び、noindexが正しく出力されているか確認する
- 広告・アフィリエイトリンクを3件選び、rel="sponsored"が付与されているか確認する
- コメント欄やユーザー投稿機能がある場合、そこからのリンクにrel="ugc"が付与されているか確認する
- Search Consoleの「ページのインデックス登録」レポートを開き、「noindexタグによって除外されました」の件数を確認する
- 同じレポートで「クロール済み - インデックス未登録」の件数を確認し、noindex以外の原因が疑われるかを見分ける
- サイト内のリンクチェックツールを使い、noindexを設定したページへの内部リンクが何本あるか数える
- 絶対に検索結果から消えては困るページを3件選び、noindexが誤って設定されていないか確認する
- robots.txtの最終更新日時をサーバー上で確認し、直近1ヶ月以内に変更されていないか照らし合わせる
- 今日確認した内容を1ヶ月後に同じ手順で再確認する予定を、カレンダーに入れる
15項目の内訳と、かかる時間の目安
15項目は4つの観点に対応している。それぞれの観点にどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。
| 観点 | 該当する項目 | 目安時間 |
|---|---|---|
| 現状把握・矛盾の検出 | 1〜7番目（7項目） | 15〜20分 |
| 実際の見え方の確認 | 8〜11番目（4項目） | 10〜15分（データ反映待ちは別途） |
| 内部リンクの点検 | 12〜13番目（2項目） | 5分 |
| 運用の継続 | 14〜15番目（2項目） | 2分 |
すべてに目を通す時間の目安は1サイトあたり30〜40分程度である（Search Consoleのレポートを新規で確認する場合は、データの反映を待つ時間が別途必要になる）。すべてのページを一度に見る必要はなく、まずページ種別ごとに1件ずつ確認するところから始めるとよい。
06 代替・他の選択肢（表で）
4つの手段の、できることとできないこと
ここまで見た3つの設定に加えて、検索結果への出方を制御する手段は他にもある。以下は、それぞれの手段が「できること」と「できないこと・限界」を整理した表である。
| 手段 | できること | できないこと・限界 |
|---|---|---|
| robots.txt （Disallow） | 準拠するクローラーによるクロールそのものを止められる | アクセス制御ではない。既にインデックス済みのURLがそのまま検索結果に残ることがある |
| noindexメタタグ・ X-Robots-Tag | 検索結果への表示を直接止められる（クロールは許可した上で） | クロールされない状態だと、このタグ自体が読まれず効果が出ない |
| rel="nofollow"・ sponsored・ugc | 個々のリンクに対する評価の受け渡しを避けられる | ページ単位の制御ではない。強制のディレクティブではなくヒントとして扱われる |
| サイト全体の パスワード保護 | クロール自体を技術的に遮断できる（認証なしでは中身に到達できない） | 一般公開したいページには使えない。実装の手間が大きい |
ページを完全に消したい場合、noindexだけでは足りないことがある
「今すぐ検索結果から消したい」という要望に対して、noindexは即効性のある手段ではない。Google公式ドキュメントも「サイトのページをGoogleの検索結果から迅速に削除する必要がある場合は、削除に関するドキュメントを参照してください」と案内している(前掲のBlock Search indexing with noindex)。Search Consoleの削除ツールは、この「今すぐ」に応える手段だが、公式ヘルプは「申請が成功しても、効果が続くのは約6ヶ月間だけ」と明記しており(Remove information from Google（訳: Googleから情報を削除する）)、恒久的な対応ではない。恒久的に消したいならnoindexかrobots.txt、今すぐ一時的に隠したいなら削除ツール（ただし約6ヶ月限定）、という役割分担になる。この判断はクロールとインデックスの区別を理解していないと迷いやすく、AIクローラーへの対応を含めて「通す」「止める」の切り分けを整理した回では、robots.txtとllms.txtという別の仕組みの役割分担を扱っている(AIクローラーは1つではない ── robots.txt・llms.txtで「通す」「止める」を切り分ける)。また、「クロール済み」というステータスと「インデックス未登録」の違いを整理した回もあり(「クロール済み」と「検出」、インデックス未登録の違い)、本記事の03章で扱ったクロールとインデックスの段階の違いを、Search Console側の表示という角度からさらに詳しく確認できる。
07 自社サイトで確認したこと — 内部リンクがnoindexページを指していた実例
「リンク切れゼロ」の確認だけでは足りなかった
当サイトが公開しているブログでは、内部リンクの点検を「リンク切れ（404）が発生していないか」という観点だけで行い、いったんは0件という結果を得た回がある。しかし、リンク先のHTTPステータスをさらに詳しく調べたところ、リンク切れではないものの、内部リンクの59.2%が、noindexを設定した記事への導線になっていたことが記録されている(archives/134)。リンクは正常に機能している（404にはならない）ため、リンクチェックだけでは見つからない種類の食い違いである。
本記事の12番目のチェック項目に反映した理由
この実例は、本記事05章のチェックリストで「内部リンクチェックツールで、noindexページへのリンク本数を数える」という項目を、単なる404チェックとは別に独立させた理由でもある。リンクが生きているかどうかと、リンク先が検索結果に出るページかどうかは、別の確認項目として扱う必要がある。noindexを設定した記事へ大量の内部リンクが集まっている状態は、読者の導線としては機能していても、サイト内の評価をnoindexページへ向け続けている状態でもあり、リンク構造を見直す際の判断材料になる。
この種の食い違いは、サイトの規模が大きいほど発見が遅れやすい。記事数が少ないうちであれば全ページを目視で確認することも現実的だが、記事数が増えるにつれて、noindexの設定状況と内部リンクの飛び先を機械的に突き合わせる仕組みが必要になる。「消す設定」と「導線を作る作業」は、別々の担当者・別々のタイミングで行われることが多いため、両者を定期的に突き合わせる工程を運用に組み込んでおかないと、この種の食い違いは自然には解消しない。
08 このテーマの、これまで
「同じ記事が2本ないか」を先に確認した回
noindexを設定する典型的な理由の一つに、重複したページの整理がある。ある記事を「重複しているはずだ」と判断してnoindexを付ける前に、実際に内容が重複しているかどうかを、タイトルの一致だけに頼らず数分で確かめる方法を扱った回がある(archives/129)。noindexは一度設定すると気づかれにくいため、設定する前の確認作業の質が結果を左右する。
「測定中」のまま止まっていた回と、その後の運用
ラベルとして「測定中」と書いてあると、実際にはその測定が長期間行われなくなる、という事例を、公開から52日分のログを開いて確認した回がある(archives/135)。本記事05章の最後の項目「1ヶ月後に同じ手順で再確認する予定を入れる」は、この事例と同じ失敗を繰り返さないための項目である。一度チェックリストを実行して満足するのではなく、次に確認する日をその場で決めておくことが、運用を止めないための具体的な手立てになる。07章で触れたnoindexページへの内部リンクの実例も、単発の発見で終わらせず、記事を書き直すたびに内部リンクの飛び先を確認する運用へとつなげている(archives/134)。本記事のチェックリストと合わせて確認すると、自分のサイトでも同じ食い違いが起きていないかを、より具体的に洗い出せる。
現在の貴方のIPアドレス
このサイトで書いている人
