Search Consoleで「ページがインデックスに登録されていません」と表示されても、原因は1つではありません。「検出 – インデックス未登録」「クロール済み – インデックス未登録」「noindex」「重複」「リダイレクト」では、最初に確認する場所が違います。
この記事では、登録リクエストを何度も送る前に、Search Consoleの表示から原因を切り分ける順番を整理します。
30秒で結論：まずURL検査で「クロールできるか」「インデックス登録を許可しているか」「canonicalはどれか」を確認します。技術的に問題がなければ、次に検索意図の重複・内容の具体性・内部リンクを見直します。Google公式は「クロール済み – インデックス未登録」について、再送信が不要な場合もあると案内しています。
最初に見る｜未登録状態と確認する場所
| Search Consoleの主な状態 | 何が起きている？ | 最初に確認すること |
|---|---|---|
| 検出 – インデックス未登録 | GoogleはURLを発見したが、まだクロールしていない | サーバー負荷、内部リンク、サイトマップ、クロール需要 |
| クロール済み – インデックス未登録 | Googleはページをクロールしたが、現時点では登録していない | 内容の独自価値・重複・検索意図・ページ品質 |
| noindexで除外 | ページ側がインデックス登録を拒否 | meta robots / HTTPヘッダー / WP設定 |
| 重複・Googleが別canonicalを選択 | 別URLを正規URLと判断 | canonical、重複URL、パラメータ、内部リンク |
| ページにリダイレクトあり | 現URLではなく転送先を処理 | 301/302の意図、リンク先、ループ |
| 404・ソフト404 | ページがない、または実質的に内容がないと判断 | HTTPステータス、本文、URL設計 |
「未登録」という同じ結果でも、原因が違うので対処も変わります。
1. 「検出 – インデックス未登録」のとき
Google公式ヘルプでは、この状態を「URLは見つけたがまだクロールしていない」と説明しています。通常、Googleがクロールしようとしたものの、サイトへの負荷などを考慮して後回しにしたケースが含まれます。
確認する順番
- URLがXMLサイトマップに含まれているか
- 関連記事から内部リンクされているか
- サーバーが5xxやタイムアウトを返していないか
- robots.txtでGooglebotを不必要に制限していないか
- 同じような薄いURLを大量生成していないか
新規サイトや大量ページ追加では、すべてを同時に手動送信するより、重要ページの優先度とサイト構造を整理します。
2. 「クロール済み – インデックス未登録」のとき
この状態は、Googleがページを取得済みです。Google公式は「今後インデックスされる場合も、されない場合もある」と案内し、再クロールのために再送信する必要はないと説明しています。
ここで「robots.txtを直せば必ず解決」と決めつけるのは早いです。クロールできているなら、技術問題だけでなく、Googleがそのページを検索結果に追加する価値をどう判断しているかも見ます。
内容面で確認する5項目
- 同じ検索意図の記事がサイト内に複数ないか
- タイトルの約束に本文が具体的に答えているか
- 比較記事なのに価格・機能・制限が抽象的ではないか
- 公式情報の要約だけで、独自の整理・判断材料がない状態ではないか
- 古い情報や更新日だけ新しい記事になっていないか
TameshiTechのような比較サイトでは、サービス名だけ差し替えた似た構成を増やすより、「この記事でしか分からない比較軸」を明確にします。
3. noindexで除外されているとき
noindexは、検索エンジンへ「このページをインデックスに入れないでほしい」と伝える指定です。意図して付けたページなら問題ではありません。
公開記事を登録したいのにnoindexになっている場合は、WordPress・SEOプラグイン・Cocoon設定・HTTPヘッダーを確認します。
WordPressで見る場所
- 投稿編集画面のnoindex設定
- SEOプラグインの投稿単位設定
- 「検索エンジンがサイトをインデックスしないようにする」設定
- テスト環境から本番へ移行した際の設定残り
設定を直したあと、公開URLテストでGoogleがインデックス可能と判断するか確認します。
4. canonicalが別URLを指しているとき
同じ内容へ複数URLでアクセスできると、Googleは代表URLを選びます。Search Consoleで「ユーザーが指定したcanonical」と「Googleが選択したcanonical」が違う場合、なぜ別URLが代表と判断されたのかを見ます。
確認例：
- HTTPとHTTPSが混在していないか
- www有無が混在していないか
- パラメータ付きURLを大量に内部リンクしていないか
- 同じ本文を別スラッグで公開していないか
- canonicalは自己参照なのに内部リンクが別URLへ向いていないか
canonicalは「書けば必ず従う命令」ではありません。サイト内のURL設計・リダイレクト・内部リンクもそろえます。
5. 404・ソフト404・リダイレクトのとき
削除したページが404なのは正常な場合があります。問題は、公開したい記事が誤って404になっている、または本文がほぼなくGoogleにソフト404と判断されるケースです。
対処の考え方
| 状況 | 対処 |
|---|---|
| 本当に削除した記事 | 404/410のままでよい場合がある。不要な内部リンクを外す |
| URL変更した記事 | 旧URL→新URLへ適切に301。内部リンクも新URLへ更新 |
| 本文が薄くソフト404 | 検索意図に答える内容を追加するか、不要なら統合・削除を検討 |
| リダイレクトループ | 転送チェーン・プラグイン・https/www設定を確認 |
インデックスされないときの実務チェックリスト
次の順番なら、同じ場所を何度も確認しにくくなります。
A. 技術
- URLが200を返す
- Googlebotをrobots.txtで遮断していない
noindexがない- canonicalが意図どおり
- サイトマップに正しいURLが入っている
B. 発見・クロール
- 関連ページから内部リンクされている
- 孤立ページになっていない
- サーバーが安定して応答している
- 不要なURLを大量生成していない
C. 内容
- その検索意図に対する答えが冒頭から分かる
- 競合ページと比べて具体的な比較・手順・一次情報がある
- 自サイト内の別記事と役割が重複していない
- 料金・仕様が現行情報と一致している
D. 送信
- 重要URLだけ公開URLテスト
- 問題修正後に必要なら登録リクエスト
- 大量URLはサイトマップで伝える
「リクエスト送信」は最後の補助
URL検査の登録リクエストは便利ですが、本文の不足やcanonicalの不一致を直す機能ではありません。
手動リクエストの上限については、Search Consoleのインデックス登録リクエスト上限と対処で整理しています。Googleは具体的な固定上限件数を公開していないため、「毎日○件送ればいい」という運用にしない方が安全です。
僕なら未登録URLをこの順番で直す
TameshiTechのような記事サイトなら、僕は次の順に確認します。
- 404・noindex・canonical・robotsなど明確な技術問題を除外
- GSCで「検出」か「クロール済み」かを分ける
- 内部リンクがあるか確認
- 同じ検索意図の記事が他にないか確認
- タイトルどおりの具体情報があるか読む
- 古い価格・仕様を更新
- 重要記事だけ公開URLテスト→必要なら登録リクエスト
- 数日〜数週間の変化をGSCで確認
これなら、送信ボタンを押すだけの対策になりません。
よくある質問
クロール済みなのに登録されないのはペナルティですか？
その表示だけでペナルティとは判断できません。Google公式は、ページがクロールされたが現時点でインデックスされていない状態として説明しています。
長文にすれば登録されますか？
文字数だけでは判断できません。検索意図に答え、他ページと重複せず、具体的な価値があるかを確認します。
毎日インデックス登録リクエストを送れば早くなりますか？
Googleは、繰り返し送信すれば必ず早くなるとは案内していません。大量URLはサイトマップを利用します。
サイトマップに入っていれば必ず登録されますか？
いいえ。サイトマップはURLの発見を助ける仕組みで、インデックス登録を保証するものではありません。
確認した主な公式情報
- Google Search Console：ページのインデックス登録レポート
- Google Search Console：URL検査ツール
- Google Search Central：canonicalの指定
- Google Search Central：robots metaタグ
Search Console全体の見方はSearch Consoleの使い方、リンク構造の改善は内部リンクとは？SEO効果を高める貼り方も参考にしてください。
コメント