コラム /
Search Console の「クロール済み - インデックス未登録」を放置してはいけない ─ 除外の切り分けと復旧の実務
📖 約5分 / 公開日: 2026/06/04
「新しく公開したページが検索に出ない」「リニューアル後に流入が落ちた」という相談を分解すると、順位の問題ではなくインデックスの問題であるケースが目立ちます。Search Console のページレポートで「クロール済み - インデックス未登録」に数百ページ溜まっているのに、誰も見ていなかった。気づいたのは月間流入が3割減ってから。この流れを2025年だけで6件見ました。
インデックス除外は放置すると雪だるま式に増えます。原因の切り分け手順と、復旧までの現実的な時間感をまとめます。
## まず4つの分類を区別する
ページレポートの「インデックス未登録」には十数種類の理由が並びますが、実務で対処が必要なものは実質4つです。
「noindex タグによって除外されました」は設定事故の可能性が最も高い分類です。WordPress なら表示設定の「検索エンジンがサイトをインデックスしないようにする」、Next.js なら metadata の robots 指定、ステージング環境の設定が本番に持ち込まれた事故。リニューアル直後にこれが起きると全ページが一斉に落ちます。実際、リニューアルから3週間「なぜか流入がゼロに近い」と相談を受けたコーポレートサイトでは、テーマの functions.php に開発会社が検証用に仕込んだ noindex 出力が残っていました。コードを1行消すだけの修正に、発見まで3週間かかったわけです。
「代替ページ（適切な canonical タグあり）」は、URL パラメータ付きページや www あり/なしの正規化が働いている場合は正常な動作です。ただし、canonical が誤って全ページからトップページに向いている事故もここに混ざります。テンプレート修正時に canonical の出力を変数ではなく固定値にしてしまうミスは、ページの見た目に何も変わらないため発見が遅れます。正常と事故が同じ分類に並ぶので、件数だけ見て安心しないでください。
「クロール済み - インデックス未登録」が最も厄介です。Google がページを取得した上で「登録する価値がない」と判断した状態。技術的な誤りではないため、直すべき設定が存在しません。
「検出 - インデックス未登録」はクロールすらされていない状態で、内部リンク構造かクロールバジェットの問題です。数万ページ規模の EC やデータベース型サイトで起きやすく、数百ページの小規模サイトでこれが大量に出る場合はサーバの応答速度を疑います。TTFB が2秒を超えているサイトでは、クロール頻度自体が絞られます。
## 「クロール済み - インデックス未登録」の現実的な対処
この分類に落ちるページの典型は、検索パラメータの組み合わせで自動生成された一覧ページ、本文200字程度のタグページ、他ページとほぼ同内容の地域別ページです。
対処は2方向しかありません。ページを統合・削除してサイト全体の品質評価を上げるか、該当ページの内容を独自性のあるものに作り直すか。
判断基準として使っているのは「そのページにしかない情報が3つ以上あるか」です。なければ統合が正解です。地域別ページを47都道府県分量産して大半が除外された不動産サイトでは、実績データを載せられる12地域に絞り、残りを301リダイレクトで統合したところ、8週間で主要ページのインデックスが回復し、流入は施策前の1.4倍になりました。ページ数を減らして流入が増える経験は、量産で SEO をやってきた担当者ほど受け入れがたいようですが、2024年以降の Google では珍しくありません。
逆効果なのは、除外されたページを URL 検査ツールの「インデックス登録をリクエスト」で連打することです。リクエストは1日10数件で頭打ちになる上、品質起因の除外には効きません。リクエストで一時的に登録されても、数日から数週間で再除外されます。リクエスト機能は新規公開ページや修正直後のページの再クロール促進に使うもので、品質判定を覆す道具ではありません。
もう一つ、React や Vue のクライアントサイドレンダリングで組まれたサイトも、この分類に落ちやすい構造を持っています。Googlebot は JavaScript を実行しますが、レンダリングキューの待ち時間があり、初期 HTML がほぼ空のページは評価が不安定になります。CSR のままインデックスが安定しない場合、Next.js や Nuxt での SSR/SSG 化が根本対処です。prerender.io のような動的レンダリングサービスで凌ぐ手もありますが、Google 自身が非推奨に転じた経緯があり、新規採用はおすすめしません。
## やってはいけない操作が2つある
切り分けの過程で事故を広げる操作が2つあります。
1つ目は「削除リクエスト」ツールの誤用です。インデックスから消したいページに使うものを、「一度消してから入れ直せばリセットされるのでは」という発想で正常なページに使ってしまう。削除リクエストは約6ヶ月間の非表示措置であり、取り消しても反映には時間がかかります。リセット効果はありません。
2つ目は robots.txt と noindex の併用です。除外したいページを robots.txt でブロックすると、Googlebot はそのページの noindex タグを読めなくなり、「ブロックされているがインデックスには残る」という中途半端な状態が発生します。インデックスから消したいなら noindex を先に読ませ、消えたことを確認してからブロックする。順序を逆にすると数ヶ月単位で残骸が残ります。
## リニューアル後の除外は別物として扱う
サイトリニューアル後にインデックスが崩れた場合、原因の探し方が変わります。最初に確認すべきは旧 URL からのリダイレクト網羅率です。
URL 構造を変えたのに 301 リダイレクトが主要20ページ分しか張られていない、これが定番です。Screaming Frog で旧サイトマップの全 URL をクロールし、301 が返らない URL を洗い出す。この作業を省いたリニューアルは、ほぼ確実に3〜6ヶ月の流入低迷を招きます。被リンクが旧 URL に向いたまま 404 を返している期間は、ドメイン全体の評価が削られ続けます。
回復には除外発生から概ね2〜4ヶ月かかります。リニューアル前の準備で防ぐのが正解で、起きてからの特効薬はありません。リダイレクトを後から張っても、失われた期間の流入は戻らないと考えてください。
sitemap.xml の lastmod も見直しが必要です。全 URL が同一日時になっているサイトマップは生成プラグインの設定ミスで、Google は lastmod を信用しなくなります。更新したページだけが正しい日時を返す状態が必須です。
## 監視体制だけは先に作る
インデックス除外は、発生から発覚までの時間が被害の大きさを決めます。Search Console の管理画面を毎週見るという運用が半年続いた現場を見たことがないので、自動化を推奨します。
Search Console API でインデックス済み URL 数を日次取得し、前週比で5%以上減ったら Slack に通知する。Google Apps Script なら2時間で組めて、ランニング費用はゼロです。これだけで「3割減ってから気づく」事態は確実に防げます。
ページ数が数百以下のサイトなら、site: 検索での概算チェックでも最低限は足ります。精度は低いものの、桁が変わる規模の異常なら拾えます。
除外が出てから慌てて対処するより、検知の仕組みを先に仕込む方が圧倒的に安上がりです。リニューアルを控えているなら、リダイレクト設計と監視設定をセットで予算に入れてください。そこを削った見積もりは、安いのではなく後払いになっているだけです。
インデックス除外は放置すると雪だるま式に増えます。原因の切り分け手順と、復旧までの現実的な時間感をまとめます。
## まず4つの分類を区別する
ページレポートの「インデックス未登録」には十数種類の理由が並びますが、実務で対処が必要なものは実質4つです。
「noindex タグによって除外されました」は設定事故の可能性が最も高い分類です。WordPress なら表示設定の「検索エンジンがサイトをインデックスしないようにする」、Next.js なら metadata の robots 指定、ステージング環境の設定が本番に持ち込まれた事故。リニューアル直後にこれが起きると全ページが一斉に落ちます。実際、リニューアルから3週間「なぜか流入がゼロに近い」と相談を受けたコーポレートサイトでは、テーマの functions.php に開発会社が検証用に仕込んだ noindex 出力が残っていました。コードを1行消すだけの修正に、発見まで3週間かかったわけです。
「代替ページ（適切な canonical タグあり）」は、URL パラメータ付きページや www あり/なしの正規化が働いている場合は正常な動作です。ただし、canonical が誤って全ページからトップページに向いている事故もここに混ざります。テンプレート修正時に canonical の出力を変数ではなく固定値にしてしまうミスは、ページの見た目に何も変わらないため発見が遅れます。正常と事故が同じ分類に並ぶので、件数だけ見て安心しないでください。
「クロール済み - インデックス未登録」が最も厄介です。Google がページを取得した上で「登録する価値がない」と判断した状態。技術的な誤りではないため、直すべき設定が存在しません。
「検出 - インデックス未登録」はクロールすらされていない状態で、内部リンク構造かクロールバジェットの問題です。数万ページ規模の EC やデータベース型サイトで起きやすく、数百ページの小規模サイトでこれが大量に出る場合はサーバの応答速度を疑います。TTFB が2秒を超えているサイトでは、クロール頻度自体が絞られます。
## 「クロール済み - インデックス未登録」の現実的な対処
この分類に落ちるページの典型は、検索パラメータの組み合わせで自動生成された一覧ページ、本文200字程度のタグページ、他ページとほぼ同内容の地域別ページです。
対処は2方向しかありません。ページを統合・削除してサイト全体の品質評価を上げるか、該当ページの内容を独自性のあるものに作り直すか。
判断基準として使っているのは「そのページにしかない情報が3つ以上あるか」です。なければ統合が正解です。地域別ページを47都道府県分量産して大半が除外された不動産サイトでは、実績データを載せられる12地域に絞り、残りを301リダイレクトで統合したところ、8週間で主要ページのインデックスが回復し、流入は施策前の1.4倍になりました。ページ数を減らして流入が増える経験は、量産で SEO をやってきた担当者ほど受け入れがたいようですが、2024年以降の Google では珍しくありません。
逆効果なのは、除外されたページを URL 検査ツールの「インデックス登録をリクエスト」で連打することです。リクエストは1日10数件で頭打ちになる上、品質起因の除外には効きません。リクエストで一時的に登録されても、数日から数週間で再除外されます。リクエスト機能は新規公開ページや修正直後のページの再クロール促進に使うもので、品質判定を覆す道具ではありません。
もう一つ、React や Vue のクライアントサイドレンダリングで組まれたサイトも、この分類に落ちやすい構造を持っています。Googlebot は JavaScript を実行しますが、レンダリングキューの待ち時間があり、初期 HTML がほぼ空のページは評価が不安定になります。CSR のままインデックスが安定しない場合、Next.js や Nuxt での SSR/SSG 化が根本対処です。prerender.io のような動的レンダリングサービスで凌ぐ手もありますが、Google 自身が非推奨に転じた経緯があり、新規採用はおすすめしません。
## やってはいけない操作が2つある
切り分けの過程で事故を広げる操作が2つあります。
1つ目は「削除リクエスト」ツールの誤用です。インデックスから消したいページに使うものを、「一度消してから入れ直せばリセットされるのでは」という発想で正常なページに使ってしまう。削除リクエストは約6ヶ月間の非表示措置であり、取り消しても反映には時間がかかります。リセット効果はありません。
2つ目は robots.txt と noindex の併用です。除外したいページを robots.txt でブロックすると、Googlebot はそのページの noindex タグを読めなくなり、「ブロックされているがインデックスには残る」という中途半端な状態が発生します。インデックスから消したいなら noindex を先に読ませ、消えたことを確認してからブロックする。順序を逆にすると数ヶ月単位で残骸が残ります。
## リニューアル後の除外は別物として扱う
サイトリニューアル後にインデックスが崩れた場合、原因の探し方が変わります。最初に確認すべきは旧 URL からのリダイレクト網羅率です。
URL 構造を変えたのに 301 リダイレクトが主要20ページ分しか張られていない、これが定番です。Screaming Frog で旧サイトマップの全 URL をクロールし、301 が返らない URL を洗い出す。この作業を省いたリニューアルは、ほぼ確実に3〜6ヶ月の流入低迷を招きます。被リンクが旧 URL に向いたまま 404 を返している期間は、ドメイン全体の評価が削られ続けます。
回復には除外発生から概ね2〜4ヶ月かかります。リニューアル前の準備で防ぐのが正解で、起きてからの特効薬はありません。リダイレクトを後から張っても、失われた期間の流入は戻らないと考えてください。
sitemap.xml の lastmod も見直しが必要です。全 URL が同一日時になっているサイトマップは生成プラグインの設定ミスで、Google は lastmod を信用しなくなります。更新したページだけが正しい日時を返す状態が必須です。
## 監視体制だけは先に作る
インデックス除外は、発生から発覚までの時間が被害の大きさを決めます。Search Console の管理画面を毎週見るという運用が半年続いた現場を見たことがないので、自動化を推奨します。
Search Console API でインデックス済み URL 数を日次取得し、前週比で5%以上減ったら Slack に通知する。Google Apps Script なら2時間で組めて、ランニング費用はゼロです。これだけで「3割減ってから気づく」事態は確実に防げます。
ページ数が数百以下のサイトなら、site: 検索での概算チェックでも最低限は足ります。精度は低いものの、桁が変わる規模の異常なら拾えます。
除外が出てから慌てて対処するより、検知の仕組みを先に仕込む方が圧倒的に安上がりです。リニューアルを控えているなら、リダイレクト設計と監視設定をセットで予算に入れてください。そこを削った見積もりは、安いのではなく後払いになっているだけです。