noindex設定で事故が起きるのは、タグの書き方が難しいからではありません。検索結果から外したいURLと、検索結果に残すべきURLの線引きが曖昧なまま運用を始めてしまうからです。 公開確認ページ、資料請求完了ページ、サイト内検索結果、追跡パラメータ付き一覧、終了したキャンペーンページが同じ管理表に並ぶと、担当者はつい「ひとまず noindex」で片付けたくなります。ですが、その判断は後で大きな負担になりがちです。
Googleのクロールとインデックス登録とnoindex を使用してページを検索インデックスから除外にもある通り、クロールとインデックス登録は別の工程です。さらに noindex は、Google がそのページを取得して初めて効きます。つまり、noindex は「見せない設定」ではなく、「公開したまま検索結果だけ外す設定」です。 ここを取り違えると、重要ページまで落ちる、消したいURLが残る、Search Consoleでは直っているのに検索結果だけ古いまま、といった典型的な事故が起きます。
実務上の結論は明快です。noindex は最後に選ぶ手段であって、最初に頼る手段ではありません。 まずは「残す」「統合する」「削除する」の三択で出口を決め、そのうえで「公開は続けるが検索の入口にはしたくないURL」にだけ noindex を使うべきです。この順番を守るだけで、誤配信と復旧遅延の多くは防げます。
noindexの前に残す理由と出口を決める
最初に決めるべきなのは、metaタグの書き方でも、CMSのチェックボックスでもありません。そのURLを運営上どう扱うのかという出口です。 検索結果から外したい理由が曖昧なまま noindex を貼ると、数週間後に手戻りが起きます。公開は必要だが検索流入はいらないのか、重複しているので代表URLに寄せたいのか、役割を終えたので消したいのか。ここが違えば、選ぶ手段も変わります。
判断を先に固めるため、まずは次の表で整理してください。
手段 | 最初に選ぶべき場面 | 推奨の判断基準 | 例外 |
|---|---|---|---|
`noindex` | 完了ページ、印刷ページ、会員導線の入口前ページ、サイト内検索結果など、公開は必要だが検索の入口にしたくないURL | 本文の独自性が低く、自然検索から着地しても次の行動につながりにくいURL | 短期キャンペーンでも外部広告の着地先として使うなら、noindexではなく公開継続を優先 |
`canonical` | 並び替え、色違い、追跡パラメータ、同内容の一覧など、重複整理が目的のURL | 主コンテンツが8割以上同じで、代表URLを1本に集約したいとき | 内容差が大きい比較ページや地域別ページでは使い分けが必要 |
`301` | 移転、統合、旧キャンペーン終了後の後継ページ案内 | 代替先が明確で、利用者にも検索評価にも移動させたいとき | 後継先が弱く、利用者の期待を裏切るなら無理に301しない |
`404/410` | 役割を終え、代替先も不要なURL | 今後も案内価値がなく、内部リンクからも外せるURL | 外部リンクや資料配布で一定の流入が残るなら、先に移行導線を設計 |
ここは明確に見直してください。月間PV10万未満のBtoBサイトで、全URLの3%を超えて noindex を使っているなら、構造上の問題を noindex で覆っている可能性が高いため、設計から見直すべきです。 終了ページを残し過ぎている、パラメータ付きURLを量産している、カテゴリ設計が粗い。こうした原因の方を先に直してください。noindex の枚数が多いこと自体は成果ではありません。
一方で例外もあります。ECや大規模メディアのように、絞り込みや検索結果ページが日次で増えるサイトでは、noindex をテンプレート単位で使う方が安全です。この場合でも「検索価値のない派生URLだけに絞る」という原則は変わりません。重複整理で済むURLまで noindex に逃がすのは避けるべきです。 Googleの重複した URL の正規化と重複 URL の統合を読むと、重複問題の中心は canonical とリダイレクトだと分かります。noindex はその代わりではありません。
もう一点、明確にしておきたいことがあります。非公開にしたいページに noindex を使ってはいけません。 URLを知っていれば閲覧できますし、外部からリンクされれば存在も把握されます。契約者限定資料、採用管理画面、見積もり管理ページのように、閲覧制限そのものが目的のページは、認証やアクセス制御を選ぶべきです。noindex は機密管理の道具ではありません。
robots.txtより先にクロール許可を守る
noindex運用で最も多い失敗は、`robots.txt` まで一緒に閉じてしまうことです。Googleのrobots.txt の概要とrobots.txt ファイルの作成と送信でも、robots.txt はクロール制御の仕組みであり、検索結果から確実に外す指示ではないと説明されています。対して noindex は、Google がページを取得して初めて機能します。検索結果から外したいなら、まずクロールを通す。これは例外なく守るべき原則です。
現場では「見せたくないから robots.txt でも閉じる」という判断が起こりがちです。しかし Googlebot から見れば、その状態は「ページを取りに行けないので noindex を読めない」状態です。すると、URLだけが検索結果に残る、タイトルや説明が欠けた不自然な表示になる、過去に評価されたURLだけ残り続ける、といったやっかいな症状が出ます。リニューアル直後や大量整理の直後には、これが20URLどころか100URL単位で広がることも珍しくありません。
noindex対象URLに robots.txt を重ねるのは避けるべきです。 どうしても例外があるのは、次の条件をすべて満たす大規模サイトに限られます。
- noindex がすでに反映され、少なくとも30日以上、Search Console上で除外が安定している
- 対象URLが数万単位で、クロール負荷を下げる意味がある
- 配信層の設定差分を継続的に監査できる
この3条件を満たさないなら、robots.txt を重ねる利点より事故の方が大きくなります。月間PV100万未満のサイトであれば、そこまで複雑な制御は不要です。noindex を読ませて除外し、内部リンクとサイトマップからも外す。それで足ります。
判断の順序も決めておきましょう。修正後7〜14日たっても検索結果に残るURLがあるなら、最初に確認すべきは `robots.txt` の重複です。次に `X-Robots-Tag` の残り、最後に canonical の誤指定を見てください。順番を逆にすると、原因にたどり着くまで遠回りになります。
metaとヘッダーの役割分担を先に決める
HTMLページなら `meta robots`、PDFやCSVなどの非HTMLリソースなら `X-Robots-Tag`。この二分で管理するのが最も安全です。 Googleのnoindex を使用してページを検索インデックスから除外でも、HTMLではmetaタグ、非HTMLではHTTPヘッダーが使えると整理されています。通常のHTMLまでヘッダー主体で運用すると、CDNや配信層の差分が原因で見落としやすくなります。反対に、PDF資料が多いのにmetaタグしか見ていない運用も危険です。
運用をぶらさないため、ここは推奨をはっきりさせておきます。通常のHTMLページは `meta robots` を標準とし、非HTMLリソースだけを `X-Robots-Tag` で管理するべきです。 さらに、同じURLに meta とヘッダーの両方を使うなら、値は完全に一致させてください。片方が `noindex`、もう片方が `index,follow` のように食い違う状態では、運営側でも診断しづらく、テンプレート監査でも漏れやすくなります。
特に注意したいのがJavaScript依存ページです。GoogleのJavaScript SEO の基本を理解するでも、描画前後で重要な検索向けの指示が食い違わないようにする必要があります。JavaScript実行後にだけ noindex を差し込む設計は避けるべきです。 公開直後の初期HTMLに noindex が残っていた、逆に初期HTMLでは indexable だったのにクライアント側で noindex が追加された。こうした差分は実際によく起きます。`Live Test` では正常でも、Google が保持している版では古い noindex が残ると、検索結果の回復は遅れます。
判断基準を数値で置くなら、次の運用が現実的です。
- HTMLテンプレート数が20未満のサイト: `meta robots` の管理に統一し、編集画面での個別操作を減らす
- PDFや資料ファイルが月10本以上増えるサイト: `X-Robots-Tag` の棚卸しを四半期ごとに実施する
- 配信層が複数あるサイト: 本番公開時に主要テンプレート5本以上のレスポンスヘッダーを抜き取り確認する
例外は、静的ファイル配信が多く、CDNで一括ヘッダー管理した方が保守しやすい環境です。ただしその場合でも、HTMLだけはmetaタグ主体に戻した方が後工程の確認は楽になります。人が見つけやすい場所に検索制御を置く。 これが誤配信を減らす最短ルートです。
Search Consoleで誤判定を五段階で切り分ける
noindex の確認でよくある誤りは、Search Console を「登録依頼を送る道具」としてしか使わないことです。実務では逆で、Search Console は差分を切り分ける道具として使うべきです。 URL 検査ツールでは `Live Test` と Google が保持している結果を見比べられますし、ページのインデックス登録レポートでは、未登録理由が noindex なのか、重複なのか、発見不足なのかを切り分けられます。
切り分け順は、次の五段階で固定してください。順番を変えない方が、原因に早く届きます。
- まず `indexed result` を確認する
Google が保持している版に noindex が入っているか、canonical が想定通りかを見ます。ここで noindex が残っているなら、`Live Test` だけ見ても判断を誤ります。
- 次に `Live Test` を確認する
今見えているページが indexable か、HTTP応答が200か、描画後に別のタグが入っていないかを見ます。`indexed result` と `Live Test` が違うなら、デプロイ差分、キャッシュ、JavaScript、CDNヘッダーのいずれかです。
- HTTPヘッダーと転送を確認する
途中で302や307に流れていないか、`X-Robots-Tag` が残っていないか、locale切り替えで別URLに送られていないかを確認します。noindex事故のかなりの割合はHTMLではなく配信層の設定で起きます。
- Page indexing をテンプレート単位で見る
同じ除外理由が1件だけなのか、80件に広がっているのかで優先度が変わります。単発なら編集ミス、複数ならテンプレートか配信設定です。
- 修正後は再取得前に再テストする
`Live Test` で差分が消えていないのに検証を始めても意味がありません。まず `Live Test`、次に代表URLを数本、最後に検証を始めてください。
この順番を守ると、「noindex を外したのに戻らない」という相談の大半は解けます。修正後の観測も曖昧にしない方がよく、即時確認、24時間後、72時間後の三回で状態を追うべきです。 72時間たっても `indexed result` が古いままなら、HTMLだけでなくヘッダーのキャッシュとサイトマップ送信日時も見直してください。
Search Consoleの操作順をもう少し整理したい場合は、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切るも併せて読むと、登録依頼に頼り過ぎない確認手順を組みやすくなります。登録依頼を急ぐことより、誤った指示を消し切ることの方が優先です。
サイトマップと内部リンクを同じ順で整える
noindex を外しても戻りが遅いとき、原因は設定そのものより発見経路にあります。Googleのサイトマップの概要とサイトマップの作成と送信でも、サイトマップは検索結果に出したいURLを伝えるための手段です。したがって、noindex を付けたURLをサイトマップに長く残すべきではありません。 検索に残したいURLと、送信しているURLの方針がずれていると、管理レポートはすぐに濁ります。
ここでも判断基準は数値で置いた方が迷いません。サイトマップ内の noindex URL 比率が1%を超えたら要点検、5%を超えたら運用設計の見直しが必要です。 特に月次更新型のメディアで、過去の終了記事やパラメータURLがサイトマップに居座る状態は避けるべきです。Googleのインデックス登録にもある通り、すべてのURLがそのまま登録されるわけではありません。だからこそ、サイトマップは全部入りにするより、選び抜いたURLを載せる方が有効です。
内部リンクも同時に直してください。検索結果に残したいページへ、index対象ページから自然にリンクが集まる状態を作るべきです。 noindex ページからしか主要サービスページへ辿れない構造では、設定を外しても再評価が鈍ります。とくに比較記事、導入事例、サービス詳細の三層で構成されるサイトでは、重要ページへ渡る導線を index 対象ページ側に寄せ直す必要があります。
内部リンクの見直しでは、次の三つの場面で推奨が分かれます。
- 資料請求完了ページを noindex にする場合
完了ページそのものは noindex で問題ありません。一方で、関連サービスやFAQへの導線は完了ページに依存しない設計にするべきです。重要ページへの評価の受け皿を noindex ページ側に置かないでください。
- 追跡パラメータ付き一覧が量産される場合
まず canonical で代表URLへ寄せ、それでも検索の入口として不要な一覧だけを noindex にするべきです。パラメータURLを片端から noindex にする運用は、後で管理しきれなくなります。
- 終了キャンペーンページを整理する場合
後継ページがあるなら301、ないなら404/410を優先し、案内上どうしても公開を残すページだけを noindex にするべきです。終了ページを noindex のまま積み上げると、内部リンク構造がゆがみます。
内部リンクの配分まで見直すなら、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方と、アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計も有効です。noindex の見直しは単体作業ではありません。どのURLを検索の入口として育てるのかを再定義する作業として進めた方が、結果は安定します。
サイト規模に応じてnoindex運用の型を変える
同じ noindex でも、サイト規模によって採るべき管理方法は変わります。小規模サイトに大規模向けの承認手順を持ち込むと更新が止まりますし、大規模サイトを担当者の手作業だけで回すと、半年で全体像が見えなくなります。規模が大きいから noindex を増やすのではなく、判断を型に落とし込むべきです。
実務で使いやすい目安を表にまとめると、次の通りです。
サイト規模 | noindex対象比率の目安 | 推奨する運用 | 例外 |
|---|---|---|---|
月間PV10万未満 | 全URLの1〜3%以内 | 完了ページ、検索結果ページ、明確な重複ページに限定。個別判断より一覧表管理を優先 | 法規制や会員制導線で検索露出を避ける必要が強い場合は追加可 |
月間PV10万〜100万 | 全URLの3〜8%以内 | canonical と URL設計を先に整え、noindex は検索価値の低い派生一覧に限定 | 季節要因で短期URLが急増する時期は一時的に比率が上がる |
月間PV100万以上 | テンプレート単位で管理 | 編集画面での個別操作を減らし、配信層と監査で制御。公開直後の抜き取り確認を必須化 | 事業部単位でCMSが完全分離している場合は例外的に個別運用もあり得る |
会員導線や限定資料が多いサイト | 比率ではなく公開方針で管理 | noindex より認証と権限制御を優先。公開したまま残す理由があるページだけ noindex | 営業資料の抜粋版のように公開意図が明確なら noindex で運用可能 |
さらに、現場で迷いやすい場面ごとに推奨をはっきりさせます。
- 月間PV5万前後のBtoBサイトなら、カテゴリページを一括 noindex にする前に、流入実績と回遊価値を確認してください。実績が月10セッションでも問い合わせに寄与するなら、消すより改善が先です。
- 比較ページや絞り込み一覧が多いサイトなら、URL設計と canonical を先に直すべきです。noindex は最後の仕上げであって、最初の片付けではありません。
- 日次で大量URLが増える大規模サイトなら、人手判断を減らすべきです。noindex の追加・解除をテンプレート定義に閉じ込め、配信ヘッダーと Search Console の差分監査を自動化してください。
- 会員導線や採用導線を併設するサイトなら、noindex だけで守ろうとしてはいけません。閲覧制御が必要なページは認証に寄せるべきです。
例外も明示しておきます。地方拠点別のページや法的表示ページのように、流入は少なくても公開維持の意味が大きいURLがあります。そうしたページは noindex の対象にせず、最低限の内容改善と内部リンク補強で残した方がよい場合があります。「流入が少ない = noindex」ではありません。役割が薄いURLだけを外すべきです。
現場で起きやすい誤設定を先回りして防ぐ
現場で繰り返し起きる誤設定は、だいたい決まっています。ここを先に潰しておけば、noindex 運用はかなり安定します。
- 同じURLに `robots.txt` と noindex を重ねる
対処: まずクロールを許可し、noindex を読ませる。robots.txt は除外が安定した後に必要性を再判断する。
- canonical で寄せるべきURLを noindex にしてしまう
対処: 重複整理が目的なら canonical を優先する。代表URLを決めないまま noindex を貼らない。
- 終了ページを noindex のまま残し続ける
対処: 後継ページがあるなら301、なければ削除を優先する。公開維持の理由がないURLは片付ける。
- PDFや資料ファイルだけ検索結果に残る
対処: HTMLだけでなく `X-Robots-Tag` を点検する。資料配布が多いサイトでは、配信設定一覧を必ず持つ。
- JavaScript描画後にだけ noindex が変わる
対処: 初期HTMLと配信ヘッダーを確認し、検索制御をクライアント側の描画ロジックに依存させない。
- ステージングやプレビュー用の noindex が本番に混入する
対処: 公開直後に主要テンプレート5本以上を目視確認し、ヘッダー差分を監査する。
- Search Console の `Live Test` だけで完了判断をする
対処: `indexed result` を必ず見る。Google が保持している版が古いままなら、実ページだけ直っていても回復しない。
ここまで踏まえたうえで、公開前の実務チェックリストを置いておきます。この確認を通せないURLは、公開しない方が安全です。
- noindex対象URLを「残す」「統合する」「削除する」の三群で分類した
- `robots.txt` と noindex が同じURLで重なっていない
- HTMLの `meta robots` と `X-Robots-Tag` の値が矛盾していない
- canonical の向き先が noindex 方針と食い違っていない
- サイトマップから noindex URL を同じデプロイで外している
- 重要ページへの内部リンクが index 対象ページ側から確保されている
- Search Console で `indexed result` と `Live Test` の両方を確認した
- 修正後24時間と72時間で再確認する運用が決まっている
このチェックリストが重いと感じるなら、運用が複雑すぎます。その場合は noindex を増やすのではなく、テンプレートとURL設計を減らした方が改善効果は大きくなります。JPSM SEO 編集事業部でも、noindexの相談は設定変更だけで終わらせません。どのURL群が検索の入口として必要かを先に整理し、その後で実装に触る。 この順番を徹底しています。
明日から着手する修正の優先順位を固めておく
noindex設定の最新実務で外してはいけない結論は一つです。noindex は構造上の問題を隠す札ではなく、公開を続けたまま検索の入口だけを整理するための限定的な道具です。 だからこそ、最初にやるべきことはタグの追加ではありません。残すURLを守るために、外すURLの理由を先に決めることです。
実務で動く順番は、次の五つに固定してください。
- 対象URLを洗い出し、「残す」「統合する」「削除する」の三群に分ける
- noindex を使うURLだけを確定し、`robots.txt` の重複を解消する
- HTMLとヘッダーの検索制御を統一し、JavaScript後付けをやめる
- サイトマップと内部リンクを同じデプロイで直し、残したいURLへ評価を集める
- Search Console で `indexed result`、`Live Test`、72時間後の状態まで確認する
ここまでできれば、「とりあえず noindex」は卒業できます。次に着手すべき具体策は、今日中に noindex 対象URLの一覧を出し、三群に色分けすることです。 その分類が曖昧なままタグを書き換えても、来月また同じ問題が起きます。まずは一覧表を作り、代表URLと削除候補を決めてから実装に入ってください。