Search Console「検出 - インデックス未登録」「クロール済み - インデックス未登録」が続くときの原因の切り分けと対処。ドメイン移行直後に増えたときの扱い

この記事の結論：Search Console が示す「検出 - インデックス未登録」は、Googleが URL を見つけたもののまだクロールしていない状態で、原因はクロールの優先度や見つけられ方の側にあります。「クロール済み - インデックス未登録」は、クロールはされたうえで登録が見送られた状態で、原因はページの中身や重複の側にあります。切り分けは、URL 検査で canonical・最終クロール日・取得の可否を見て、どちらの状態かと、技術的な問題が無いかを先に分けます。そのうえで、前者は内部リンク・サイトマップ・サーバーの応答を、後者は似たページの統合や内容の見直しを行います。ドメインやホストを変えた直後に前者が増えるのは珍しいことではなく、301 と canonical とサイトマップがそろっていれば、数週間は推移を見るのが基本です。

この記事は、毎週 Search Console を見ても「ページ」のレポートで未登録の数が減らずに困っている担当者と開発者に向けた、切り分けの手順です。後半では、このブログの置き場所を WordPress の外へ移して静的サイトにし、正式なホストを www 付きに変えた日に、実際に URL 検査で見た結果と、そのあとにしたことを記録しています。Google側の説明は、記事の終わりに並べた資料で照らし合わせています（確認は2026年10月3日）。

2つの状態は、Googleがどこまで進んだかが違う

「検出」と「クロール済み」は、Googleの処理がどの段階で止まっているかを表しています。止まっている段階が違えば、見る所も手の打ち方も変わります。

ヘルプには、サイトのすべてのURLが登録されると期待すべきではなく、登録されるのは canonical のページだけだとも書かれています。未登録の数がゼロにならないこと自体は、異常ではありません。

原因の切り分けは、URL検査から始める

どちらの状態でも、最初に URL 検査で1本ずつ事実を確かめます。数の多さに目を奪われてサイト全体を直し始める前に、代表のURLを数本選んで次の順に見ます。

1. ユーザーが指定した canonical と、Google が選んだ canonical を比べる。 食い違っていれば、問題は重複の側です。別のURLが代表として選ばれています
2. 最終クロール日を見る。 日付が無ければ「まだ来ていない」、あれば「来たが見送られた」です。レポートの分類と合っているかも確かめます
3. 「公開URLをテスト」で、今のページが取得できるかを見る。 robots.txt での拒否、noindex、取得の失敗が無いかを確かめます
4. 手元でもレスポンスを確かめる。 ステータスが200か、canonical が自分自身の正式なURLを指しているか、robots の meta に noindex が入っていないかを見ます

curl -sI https://www.example.co.jp/article/ | head -3
curl -s  https://www.example.co.jp/article/ | grep -o '<link rel="canonical"[^>]*>\|<meta name="robots"[^>]*>'

5. 同じ内容に届くURLが他に無いかを見る。 末尾の / の有無、www の有無、? の付いたURL、http と https の違いで、同じページが別のURLとして返っていないかを確かめます

ここで技術的な問題が見つかれば、先にそれを直します。何も見つからなければ、状態ごとの対処に進みます。

「検出 - インデックス未登録」は、見つけやすさとクロールの負担を見直す

Googleが「まだ取りに来ていない」状態なので、URL の存在をはっきり伝え、取りに来やすい状態にします。

サイトマップの lastmod は、Googleが「一貫して正確だと確かめられる場合に使う」と説明している項目です。このブログでは、記事のページにだけ最終更新日を入れ、一覧のページには付けていません。一覧のページは、記事が増えるたびに中身が変わり、日付が実態を表さないためです。記事が1本も無いカテゴリーやタグの一覧は、noindex にしたうえでサイトマップから外し、クロールしてほしいURLだけが載るようにしています。

登録のリクエストには1日の上限があり、同じURLへの依頼を重ねてもクロールは早まらない、とGoogleは書いています。数が多いときは、リクエストよりもサイトマップと内部リンクで伝えます。

「クロール済み - インデックス未登録」は、ページの中身と重複を見直す

Googleが読んだうえで見送った状態なので、送り直しても結果は変わりにくく、ページの側を変えます。

• 同じ問いに答えるページが2本以上ないか。 似た題・似た見出しのページが並んでいると、片方だけが選ばれやすくなります。内容を1本にまとめ、もう片方は 301 で寄せます
• 検索する人の問いに答えきれているか。 題に対して中身が薄い、答えが最後まで出てこない、といったページは、内容を足すか、ほかのページに統合します
• サイトの目的から外れたページを抱えていないか。 残す理由が無いページは、noindex にしてサイトマップから外す選択肢もあります

このブログでも、移行の作業の途中で、記事ごとに検索での表示回数（Search Console）と内容を見比べ、同じ問いの記事をまとめる案と、noindex にする案を作りました。まとめるときは、統合元のURLを転送の設定ファイル（_redirects）に1行ずつ書いて統合先へ 301 で送り、統合元の記事はページを出さない設定にする、という手順を決めています。まとめる・外すの判断は、作業する前に一覧にして、記事ごとに理由を書いてから進めます。

ドメイン移行やホスト変更の直後に増えたときは、転送とサイトマップを確かめて待つ

移行の直後は、Googleにとって新しいURLが一度に増えるため、「検出 - インデックス未登録」が増えやすい時期です。慌ててページを直す前に、移行の設定が正しいかだけを確かめ、あとは推移を見ます。

このブログで移行した日に見た状態

このブログは2026年10月2日に、WordPress をやめて、Astro で作る静的サイト（配信は Cloudflare）に置き換え、同時に正式なホストを www なしから www 付きへ変えました。旧サイトでは www なしが正式で、www 付きは www なしへ転送していました。つまり Google から見ると、記事のパスは同じでも、www 付きのURLは「これまで転送元だったURL」が正式なURLに変わった形です。

切り替えた日に、主な記事を中心に www 付きのURLを25件、URL 検査で調べました（状態名は英語のまま保存しています）。

把握されていなかった3件のうち1件は、すでに無い記事で、近い記事へ 301 で寄せたURLでした。登録済みの4件にはトップページが含まれていました。

そのあとにしたこと

1. 転送が1回で届くかを確かめた。 www なしと *.pages.dev は、Pages の関数で書いたミドルウェアが、パスと ? 以降を保ったまま www へ 301 で送ります。末尾の / もこの1回の転送の中で付け、転送が2回続かないようにしました
2. canonical とサイトマップを www にそろえた。 canonical・サイトマップ・構造化データのURLは、すべて同じ設定の値から作っています
3. 旧サイトのサイトマップのURLを、新しいサイトマップへ 301 で送った。 /sitemap.xml や /wp-sitemap.xml など、旧サイトで使われていたサイトマップのURLが404のままだと、新しいURLを見つけてもらうのが遅れると考えたためです
4. 新しいサイトマップを送信（Search Console）し、主な記事から登録をリクエストした。 1日の上限に達したので、残りは翌日に回しました
5. Bing などには IndexNow で全URLを知らせた。 IndexNow の鍵のファイルをサイトに置き、URLの一覧を送るスクリプトを用意しています

Googleのサイト移転の説明では、ドメインやサブドメインを移すときはアドレス変更ツールを使いますが、www あり・なしの切り替えには要らないとされています。また、中規模のサイトで新しいURLが古いURLに置き換わるまで数週間以上かかることがあり、転送は少なくとも1年は残すよう書かれています。このブログも、移行の結果がどう出たかはまだ判断できる時期ではないので、登録の推移は数週間後にこの記事へ追記します。移行の作業そのものの手順は、旧ブログからURLを変えずに引っ越した作業の記録にまとめています。

移行の直後に、やらない方がよいこと

• 転送元の旧URLを robots.txt で拒否する。 拒否すると Googlebot が旧URLを取りに来られず、301 の転送先に気づけません
• 転送を早く外す。 評価の引き継ぎに時間がかかるため、少なくとも1年は残します
• 未登録のURLを毎日リクエストし直す。 上限を使い切るだけで、早くはなりません
• 未登録だからと noindex にする。 移行の直後の「検出」は、待てば解消することが多い状態です。中身に問題があるのは「クロール済み」の方です

毎週見るところを決めておく

移行のあとや、未登録の数を減らしたい時期は、見る所を固定して週に1回記録すると、変化の理由を追いやすくなります。

「ページ」のレポートで修正を検証にかけると、終わるまでに通常2週間ほど、場合によってはそれ以上かかるとヘルプにあります。直した日を記録に残しておくと、数字が動いたときに、どの手が効いたのかを後から追えます。

検索とAIの両方で見つけてもらう取り組み（LLMO）を、株式会社bundlyzeでは毎月の数字の記録とあわせて自社の会社サイトで続けています。数字の読み方から、ページの統合や移行の設計までを外の目で見てほしいときは、SEO・LLMO対策の支援で進め方を紹介しています。

参照したヘルプと検索セントラルの説明（確認：2026年10月3日）

• 各状態の意味、すべてのURLが登録されるわけではないこと、修正の検証にかかる期間 → ページ インデックス登録レポートのヘルプ
• 新しいURLに置き換わるまでの期間、転送を残す期間、アドレス変更ツールが要らない場合、サイトマップの扱い → URL の変更を伴うサイト移転の説明
• リクエストの上限、繰り返しても早まらないこと、クロールにかかる期間 → 再クロールを依頼する方法の説明
• 登録のリクエストに1日あたりの上限があること → URL 検査ツールのヘルプ
• lastmod の扱い → サイトマップの作り方と送り方の説明
• URLの変更を参加している検索エンジンへ知らせる仕組み（Google 以外） → IndexNow