Google Search Consoleで「検出-インデックス未登録」が増え続けているのに、コンテンツの品質やrobots.txtを見直しても改善しない。そんな状態が続いていませんか。
私が運営するコーポレートサイトで、55ページが「検出-インデックス未登録」になる事態が発生しました。原因を調べたところ、記事の内容やサイトの権威性ではなく、サイトマップ生成コードに潜んでいた2つのバグが根本原因でした。
修正後、サイトマップのURL数は132から228に増加。これまでGoogleに認識すらされていなかった104件の記事が、正しくサイトマップに掲載されるようになりました。
この記事では、「検出-インデックス未登録」を引き起こしたサイトマップのバグの具体的な内容と、その発見・修正方法を実体験をもとに解説します。
サイトマップの不備で55ページが「検出-インデックス未登録」になった経緯
異変に気づいたのは、GSC（Google Search Console）のページインデックスレポートを確認したときでした。「検出-インデックス未登録」のステータスに55件ものページが表示されていたのです。
「検出-インデックス未登録」とは、GoogleがURLの存在を認識しているにもかかわらず、まだクロール（ページの読み込み）すら行っていない状態です。つまり、Googleの検索結果に一切表示されないことを意味します。
最初はコンテンツの品質や内部リンクの不足を疑いました。しかし、いくつかのURLを個別に検査しても技術的な問題は検出されず、「順番待ち」の状態が続くだけ。そこでサイトマップ自体を検証することにしました。
結果として見つかったのは、サイトマップ生成コードに潜んでいた2つの致命的なバグでした。
原因1: 存在しないURLがサイトマップに7件含まれていた
サイトマップのXMLを直接確認したところ、/services/undefinedというURLが7件含まれていました。
私のサイトはNext.js（App Router）で構築しており、sitemap.jsでサービスページのURLを動的に生成しています。問題はここにありました。サービスデータの配列からslugプロパティを参照してURLを組み立てていたのですが、実際のデータにはslugというプロパティが存在しなかったのです。
JavaScriptでは、存在しないプロパティにアクセスするとエラーではなくundefinedが返ります。その結果、/services/undefinedというURLが7件、サイトマップに混入していました。
なぜ気づけなかったのか
このバグの厄介な点は3つあります。
- ビルド時にエラーが出ない: JavaScriptの仕様上、undefined参照はランタイムエラーにならない
- XMLの形式としては正しい:
/services/undefinedはURL形式として有効なため、XMLバリデーションを通過する - サイトの表示に影響しない: サイトマップは裏方のファイルであり、ユーザーが目にすることはない
Googleはサイトマップに掲載されたURLを「サイトオーナーがインデックスしてほしいと宣言したURL」として扱います。そのため存在しないURLであっても、定期的にクロールを試みます。毎回404を返すURLに対してクロールバジェット（Googleがサイトに割り当てるクロールリソース）が浪費され続けていたのです。
原因2: CMS APIの取得上限で記事の半数がサイトマップから漏れていた
もうひとつの原因はさらに深刻でした。ヘッドレスCMS（MicroCMS）のAPIには、1回のリクエストで取得できる件数にデフォルトの上限（100件）があります。
サイトマップ生成コードでは、APIから全記事を取得してURLリストを出力していましたが、ページネーション（複数回リクエストで全件取得する処理）を実装していませんでした。記事数が100件を超えた時点で、101件目以降の記事がサイトマップから完全に欠落していたのです。
記事の総数は204件。つまり約半数の104件がサイトマップに含まれていなかったことになります。
サイトの成長とともに発生する「時限爆弾」
この問題が特に危険なのは、サイトの成長期に突然発生する点です。
- 開設当初は記事が少ないため、APIの取得上限に引っかからない
- サイトマップは正常に動いているように見える
- 記事が増えて100件を超えた瞬間から、サイトマップが不完全になる
- しかしサイト上では記事は正常に表示されるため、欠落に気づくきっかけがない
MicroCMSに限らず、Contentful、Strapi、Newtなど主要なヘッドレスCMSのほとんどにAPIの取得上限があります。ヘッドレスCMSでサイトを構築している場合、サイトマップ生成時のページネーション実装は必須と考えてください。
サイトマップの不備がSEOに与える3つの悪影響
1. クロールバジェットの浪費
Googleは各サイトに割り当てるクロールリソースに上限を設けています。Google公式のクロールバジェット管理ガイドでは、サイトマップにはインデックス可能な正規URLのみを含めるべきと明記されています。
404を返すURLやリダイレクトが混入していると、その分だけ本来クロールすべきページへのリソースが削られます。特に中小規模のサイトではクロールバジェット自体が限られているため、1件の無駄なURLでも影響が大きくなります。
2. サイトマップ未掲載ページのインデックス遅延
サイトマップに含まれていないページは、Googleが内部リンクを辿って発見するまでインデックスされません。サイトマップ経由での発見と比べ、インデックスまでの時間が数日から数週間以上遅延する可能性があります。
新規記事を公開しても検索結果に表示されない期間が長引くほど、タイムリーなトラフィックを取り逃がすことになります。SEOにおいて記事の鮮度は重要な評価要因であり、インデックスの遅延はそのまま機会損失に直結します。
3. サイト全体の品質シグナルへの影響
サイトマップに掲載したURLの多くが404やリダイレクトを返す状態が続くと、Googleはそのサイトの管理品質が低いと判断する可能性があります。これはサイト全体のクロール頻度やインデックス優先度に波及します。
私のケースでは、サイトマップの132URLのうち55件（42%）が「検出-インデックス未登録」でした。提出したURLの4割がインデックスに至らない状態は、サイトの信頼性シグナルとして決して好ましくありません。
修正方法と再発防止の4ステップ
ステップ1: サイトマップのURL数を実際のページ数と突合する
まずサイトマップが出力しているURL数と、サイト内の実際のページ数が一致しているか確認します。
GSCの「サイトマップ」レポートで「検出されたURL数」を確認し、想定より少なければ取得漏れを疑いましょう。ブラウザで/sitemap.xmlに直接アクセスし、XMLの中に覚えのないURLやundefinedが含まれていないかも目視でチェックしてください。
ステップ2: サイトマップの全URLをレスポンスチェックする
サイトマップに含まれるすべてのURLが200（正常）を返すか確認します。curlやスクリプトで一括チェックすると効率的です。
404やリダイレクト（301/302）が見つかった場合、そのURLの生成ロジックに問題があります。プロパティの参照ミスやパスの組み立てロジックを確認しましょう。
ステップ3: ヘッドレスCMSのAPIページネーションを実装する
ヘッドレスCMSを使用している場合、APIのデフォルト取得件数の上限を必ず確認してください。
修正のポイントは、APIレスポンスに含まれるtotalCount（全件数）と取得済み件数を比較し、全件取得するまでリクエストを繰り返すことです。offsetパラメータで取得開始位置をずらしながら、すべてのコンテンツを取得するループ処理を実装します。
現在のコンテンツ数が上限以下であっても、将来の増加に備えてページネーションを最初から実装しておくことを強くお勧めします。
ステップ4: 修正後にサイトマップを再送信する
サイトマップの修正とデプロイが完了したら、GSCの「サイトマップ」レポートから再送信を行います。Googleが新しいサイトマップをクロールし、追加されたURLのインデックスを開始します。反映には通常2〜4週間を要します。
修正後の変化と今後の経過
2つのバグを修正した結果、サイトマップのURL数は132から228に増加しました。存在しないURLの除去（7件減）と、漏れていた104件の記事の追加によるものです。
GSCのサイトマップレポートでは「検出されたURL」が即座に正しい数値に更新されたことを確認しています。「検出-インデックス未登録」の解消にはGoogleのクロールサイクルに依存するため、2〜4週間の経過観察を続ける予定です。
この経験から得た最大の教訓は、サイトマップは「一度設定したら終わり」ではないということです。
まとめ: サイトマップの定期チェック項目
サイトの成長とともに、気づかないうちにサイトマップが不完全になるリスクがあります。月に一度は以下の4点を確認してください。
- サイトマップのURL数と実際のページ数が一致しているか
- サイトマップ内のURLがすべて200を返すか（404やundefinedが混入していないか）
- ヘッドレスCMSのAPI取得件数が全件をカバーしているか
- GSCの「検出-インデックス未登録」が異常に増加していないか
「検出-インデックス未登録」の原因として、コンテンツ品質やrobots.txtの設定ミスはよく紹介されています。しかし今回の実体験で分かったのは、サイトマップ生成コードのバグという見落としやすい原因も存在するということです。同じ症状でお悩みの方は、ぜひサイトマップの中身を直接確認してみてください。
ホームページの技術的な問題でお困りの方は、こちらの記事も参考にしてください。
