SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Search Consoleで“Excluded by 'noindex' tag”が増えたとき、最初の30分でやること

Search Consoleで“Excluded by 'noindex' tag(noindexにより除外)”が増えたときに、最初の30分で「意図したnoindex」と「事故のnoindex」を切り分けて止血するチェックリストです。

著者: 川原更新: 2026-05-16検索改善RSS
Xで共有FacebookLinkedIn
料金相談

Search Consoleで “Excluded by 'noindex' tag(noindex により除外)” が増えたとき、最初の30分でやるべきことは「全部のnoindexを外す」ではなく、(1) noindexが“意図した運用”なのか、(2) テンプレ/ヘッダ/配信事故で“重要ページまでnoindexになっている”のか を短時間で切り分けて、止血することです。

この記事は、最初の30分で「直せば戻る事故」を先に潰し、次の1時間で触る場所(テンプレ/ミドルウェア/URL設計/一覧設計)を固定するチェックリストです。

関連:

  • /media/search-console-indexing-drop-first-30-minutes
  • /media/robots-txt-crawl-stop-first-30-minutes
  • /media/search-console-drop-first-30-minutes

0. まず結論(先にやる順番)

  1. 代表URLを3つだけ選ぶ(重要 + 典型 + 正常)
  2. URL検査で「noindexの発生源(meta/HTTPヘッダ)」を確定する
  3. 事故なら止血(重要ページのnoindexを外す/配信を戻す)
  4. 意図したnoindexなら、入口(内部リンク/サイトマップ/canonical)を整える

1. “noindexが増えた”は、良い場合と悪い場合がある

noindexは「検索結果に出したくないページ」を制御するための正攻法です。一方で、次のようなケースは事故として扱います。

  • 料金/機能/購入導線など 収益に近い重要ページ が noindex になっている
  • 記事/商品などの 主要コンテンツの大半 が noindex になっている
  • “昨日まで普通だった”のに、テンプレ変更やデプロイ直後に急増した

2. 代表URLを3つだけ選ぶ(3分)

代表URLを3つだけ選びます(全件は追いません)。

  • 代表A: “Excluded by noindex” の上位URL(典型)
  • 代表B: 同じテンプレの“本来インデックスされるべきページ”(重要)
  • 代表C: 正常にインデックスされている類似ページ(比較用)

原因はだいたい数パターンに収束します。まずは比較できる材料を揃えます。

3. URL検査で「noindexの発生源」を確定(10分)

Search ConsoleのURL検査で、代表URLについて次を確認します。

  • noindex が HTMLのmeta に出ているか(<meta name="robots" content="noindex"> など)
  • noindex が HTTPヘッダ で出ているか(X-Robots-Tag: noindex など)
  • “Googleが取得したHTML” が 想定のページ か(WAF/認証/エラー画面の差し替えではないか)
  • canonical が変なURLを指していないか(重複/入口ミスの可能性)

ここでの目的は「原因推理」ではなく、“どこからnoindexが出ているか”を確定することです。

4. 事故なら止血(重要ページだけ先に救う)(10分)

事故パターンは、だいたい次のどれかです。

  • テンプレ/レイアウトの条件分岐が誤り、重要ページまでnoindex
  • 認証必須ページ扱いになっていて、共通ヘッダで noindex を付与
  • edge/キャッシュ/ABテストの出し分けで “別HTML” を返している
  • ミドルウェア変更で、特定パスが意図せず noindex 対象に入った

最初の30分は「全体最適」より 重要ページの止血 を優先します。

  • 重要ページが noindex: 即座に外す(テンプレ条件/ヘッダ付与/配信を戻す)
  • 重要ページが救えたら: 代表Aの“典型”も同じ原因かを確認し、まとめて修正する

5. 意図した noindex なら「入口」と「混入」を整える(5分)

noindex運用自体が正しい場合でも、入口が汚れているとムダなクロールと誤解が増えます。

  • noindexページがサイトマップに混ざっていないか(混ざるとノイズが増える)
  • 内部リンクで noindexページを入口にしていないか(重要導線は避ける)
  • 一覧/検索/タグ等の “0件ページ” を量産していないか(必要なら noindex + 明確な案内)

6. 次の1時間でやること(恒久対応の入口)

  • noindex対象の ルール化(どの種類のページをnoindexにするか)
  • テンプレ/ミドルウェア/ヘッダの付与条件を 1か所に集約
  • 重要ページの “インデックス可能性チェック” を デプロイ前のチェックリスト に追加

相談(最短で止血したい場合)

「重要ページを救いたい」「noindexの混入を止めたい」という状況なら、SiteOpsで “30分でやること”の手順化 と 再発防止の運用設計 まで一緒に詰められます。

  • まずは、代表URL 3件(重要1 + 典型1 + 正常1)だけでOKです
  • その場で “事故のnoindex” と “意図したnoindex” を切り分け、触る場所を固定します

参考にした一次情報

  • Google Search Central: Block Search indexing with noindex
  • Google Search Central: URL Inspection tool

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Search Consoleでクロール異常(Crawl anomaly)が増えたとき、最初の30分でやること検索改善更新: 2026-05-18Search ConsoleでAlternate page with proper canonical tagが増えたとき、最初の30分でやること検索改善更新: 2026-05-17Search ConsoleでNot found (404)が急増したとき、最初の30分でやること検索改善更新: 2026-05-15
前の記事Search ConsoleでDuplicate, Google chose different canonicalが増えたとき、最初の30分でやること次の記事Cloudflare 1102でサイトマップが落ちるとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ