Search Consoleで未登録URLが増えると、「登録リクエストを続けるか」「記事を直すか」「統合・削除するか」の判断に迷います。公開した記事やサービスページが検索に出ず、サイトマップを送り直しても変わらない中小企業の経営者・Web担当者に向けて、確認順を整理します。
結論は、検索へ出すURLかどうかを先に決め、最終クロール日、技術条件、正規URL、内部リンクとサイトマップ、内容の固有性の順に調べることです。その結果を、待機、技術修正、内容改善、統合、除外へ仕分けます。
Googleは「クロール済み - インデックス未登録」を、クロール済みでもインデックスには登録していない状態と説明しています。今後登録される場合も、されない場合もあり、クロールリクエストを再送信する必要はないとされています。Google ヘルプ
未登録URLがすべて問題とは限らない
ページ インデックス登録レポートで未登録になっていても、直ちにエラーとは限りません。Googleは、主要ページの正規版は登録状況を確認する一方、重複URL、意図したnoindex、robots.txtによる制御、代替のない削除ページの404などは未登録でも妥当な場合があると説明しています。Google ヘルプ
最初に自社で決めるのは、そのURLの「希望状態」です。問い合わせや購入、採用などにつながる固有ページなら検索へ出す候補です。既存ページの複製、絞り込み条件だけが違うURL、移転前URLなどは、統合や除外が適している可能性があります。
基礎用語はインデックスの基本的な意味とSEOとの関係で補足し、ここでは実務上の仕分けに進みます。
| 確認した状態 | 主な確認点 | 次の候補 | 急がないケース |
|---|---|---|---|
| 最終クロールが公開・更新前 | 公開日、更新日、最終クロール日 | 待機 | 現在のページに設定不整合がない |
| 検索へ出したいが技術条件に問題がある | noindex、robots.txt、HTTP状態 | 技術修正 | 除外や転送が意図どおり |
| Googleが別URLを正規としている | canonical、類似性、転送 | 統合または正規化修正 | 選ばれたURLが意図した代表ページ |
| 技術条件は整うが近接ページと重なる | 検索意図、固有情報、役割 | 内容改善または統合 | 既存ページで目的を満たす |
| 検索へ出す必要がない | 公開目的、代替ページ | 除外 | noindex、転送、404が希望どおり |
希望状態と現状が一致するURLには作業を増やさず、不一致のURLだけを次の確認へ進めます。件数順ではなく、事業上の役割が明確な主要URLから着手します。
最終クロール日と現在の公開状態をそろえる
Search Consoleの表示は、Googleが最後にクロールした時点の情報です。公開後にnoindexを外したり本文を直したりしても、最終クロールが変更前なら、レポートと現在のページは一致しません。Googleも、URL検査のクロール日と、その後の修正有無を照合するよう案内しています。Google ヘルプ
確認は次の順で進めます。
- URL検査で最終クロール日を記録する
- CMSの履歴で、現在のページを最後に変更した日を確認する
- 「公開URLをテスト」で、現在のページへアクセスできるかを見る
- クロールが変更前なら待機、変更後でも未登録なら次の原因へ進む
公開URLのテストが通っても、重複や正規化まで現在の状態として判定されるわけではありません。Googleは、ライブテストでは特に重複や正規化の条件をテストしないと説明しています。Google ヘルプ
修正直後は登録リクエストを連打せず、再確認日を決めます。古い判定を直そうとしているのか、現在も残る原因を直すのかを分けるためです。
noindex・robots.txt・HTTP状態を確認する
内容を書き直す前に、Googleがページを取得し、インデックス登録を検討できる状態かを確認します。検索へ出したいURLにnoindex、クロール制限、リダイレクト、4xx・5xxがあれば、本文より設定修正が先です。
noindexは、HTMLのmetaタグまたはHTTPヘッダーでインデックス登録を止める指定です。検索へ出したいページなら削除し、意図的な除外ページならそのままで構いません。Googleは、公開中のページとレスポンスヘッダーを確認し、対象にするならnoindexを取り除くよう案内しています。Google ヘルプ
robots.txtはクロール可否を制御する仕組みです。ブロックしたままではGoogleがページ内のnoindexを確認できず、robots.txtだけで検索結果からの除外を確実にする方法でもありません。Google ヘルプ+1
HTTP状態は希望状態と照合します。残すページは通常表示できるか、移転済みなら転送先が正しいか、代替のない削除ページなら404でよいかを見ます。リダイレクト元は登録されず、代替のない404は必ずしも問題ではありません。Google ヘルプ+1
ホームページを含めて広範囲に検索へ出ない場合は、ホームページ全体が検索に出ないときの基本確認も参照してください。URL固有の問題か、テンプレートやサーバーを含む全体問題かで、依頼範囲が変わります。
Googleが選んだ正規URLと重複を確認する
正規URLとは、同一または非常に似た内容を持つ複数URLの代表です。Googleは重複ページをまとめ、シグナルに基づいて正規URLを選びます。運営者はcanonical、リダイレクト、サイトマップで希望を伝えられますが、別URLが選ばれる場合もあります。Google for Developers+1
URL検査では、対象URL、ユーザー指定の正規URL、Googleが選択した正規URLを並べます。別URLが選ばれていたら、canonicalタグだけでなく、本文の類似性、HTTPとHTTPS、絞り込み・並び替えのパラメータURL、旧URLからの転送も確認します。Google ヘルプ+1
別URLが選ばれたときの分岐
- 意図した重複：選ばれたURLが代表として適切なら、未登録URLを無理に登録させず、内部リンクとサイトマップも代表URLへそろえる
- 別ページとして残す：異なる検索意図を担うなら、canonical、内部リンク、サイトマップを整え、内容の役割を分ける
- 旧URLを廃止する：利用者を新URLへ移すなら、canonicalだけで残さず、適切なリダイレクトを検討する
分岐後は指示の矛盾をなくします。同じページについて、canonicalはA、サイトマップはB、内部リンクはCという状態を残さないようにします。正規URLの選択をnoindexで操作する方法も推奨されていません。Google for Developers
内部リンクとサイトマップは役割が違う
内部リンクは、利用者とクローラーがサイト内をたどる経路です。GoogleがURLを見つけるには、既知のページからのリンクやサイトマップなどが必要とされています。検索へ出したいページは、関連ページや一覧から自然に到達できる状態にします。Google ヘルプ
サイトマップは、新規・更新ページを知らせ、検索結果へ出したい正規URLをまとめる資料です。同じ内容を指すURLが複数ある場合は、代表となる正規URLを含め、他のURLは原則として含めない考え方が示されています。Google for Developers
ただし、サイトマップはcanonicalやリダイレクトより弱い正規化シグナルです。「クロール済み」ならURLはすでに取得されているため、再送信だけでは重複、設定不整合、内容の役割重複は解消しません。Google for Developers+1
対象URLの有無だけでなく、除外予定URLやリダイレクト元が混在していないか、内部リンクが非正規URLへ向いていないかまで確認します。
内容を改善するか統合するかを決める
技術条件と正規URLに問題がない場合は、そのURLを独立ページとして残す理由を確認します。見るのは文字数ではなく、誰のどの疑問に答えるか、既存ページと役割が分かれているか、自社が公開できる固有情報があるかです。
改善して残すページ
固有の検索意図と事業上の役割があるなら改善候補です。タイトルだけを変えるのではなく、対象読者、判断条件、提供範囲、手順、選び方、一次情報など、そのページで得られる内容を補います。公開できない実績や数値は作らず、実際に説明できる事業情報を使います。
近接ページと結論が似ていても、片方が概要、もう片方が具体条件や手順を担うなど、役割を説明できるなら分けて残せます。分ける理由がなければ、文章量を増やす前に統合が候補です。
統合または除外するページ
複数ページが同じ検索意図へ同じ答えを返すなら、代表ページを選び、必要な内容を統合します。廃止URLから利用者を移す必要があればリダイレクトし、内部リンクとサイトマップも代表URLへ更新します。
検索へ出す必要はないが利用者には残すページならnoindex、代替ページがある廃止URLなら転送、代替がないなら404というように、公開目的と行き先で処理を分けます。Googleの説明でも、重複ページや意味のある情報を含まないURLなど、すべてが登録対象になるわけではありません。Google ヘルプ
これで、変更後の再取得待ちなら「待機」、設定不整合なら「技術修正」、独自の役割があるなら「内容改善」、役割が重なるなら「統合」、検索対象にしないなら「除外」と分類できます。
制作会社へ渡すURL別確認表
制作会社へURL一覧だけを渡すと、検索へ出すページ、統合するページ、意図的に除外するページが混ざります。自社が決める公開目的と、制作会社が調べる技術条件をURLごとに分けます。
最低限、そろえておきたい項目は次のとおりです。
- URL：調査対象の完全なURL
- 検索へ出す目的：誰に何を見つけてもらうページか
- 最終クロール日：URL検査に表示された日付
- HTTP状態：通常表示、リダイレクト、4xx、5xxなど
- noindex：HTMLまたはHTTPヘッダーでの有無
- robots.txt：対象URLのクロール可否
- 正規URL：ユーザー指定とGoogle選択
- 内部リンク：どの主要ページや一覧から到達できるか
- サイトマップ：記載の有無と非正規URLの混在
- 近接ページ：同じ検索意図や似た内容を持つURL
- 再確認日：修正・公開後に見直す日
希望状態が未記入のURLは、技術的に直せても事業判断が残ります。この一覧を、設定修正、コンテンツ整理、転送、経過確認へ分ける材料にします。
| 資料 | 記録する内容 | 自社で決めること | 制作会社に確認すること |
|---|---|---|---|
| URL別台帳 | URL、希望状態、最終クロール日、現状 | 検索へ出すか、統合・除外するか | Search Consoleと公開ページの差分 |
| 技術確認票 | HTTP、noindex、robots.txt、転送 | 意図した公開・除外・転送か | テンプレート、ヘッダー、サーバーの修正箇所 |
| 内容比較票 | 検索意図、固有情報、近接ページ、代表URL | 改善ページと統合先 | canonical、内部リンク、サイトマップの変更範囲 |
| 公開後記録 | 修正日、確認方法、再確認日 | 優先順位と判断期限 | 公開URLテスト、再クロール後の状態、残課題 |
この表の用途は、自社判断、技術調査、コンテンツ整理、公開後確認の担当分けです。「URL」「希望状態」「判断根拠」を一組にし、何をもって完了とするかまで共有します。
まとめ
「クロール済み - インデックス未登録」は、再登録の回数ではなく、URLの役割と原因別の修正で扱います。検索へ出すURLを選び、最終クロール日、技術条件、正規URL、発見経路、内容の固有性を確認すれば、待つURLと直すURLを分けられます。
制作会社へ渡す情報は、未登録件数だけでは足りません。URLごとの希望状態、Googleが選んだ正規URL、近接ページ、再確認日まで共有します。単発の登録依頼ではなく、サイト構造とコンテンツの両面を対象にしたSEO診断へつながります。
参考資料
- ページ インデックス登録レポート（Google Search Console ヘルプ。ページの登録状況、未登録理由、URL検査の確認に使用。2026年7月19日確認）
- Google のクロールとインデックス登録（Google 検索セントラル。最終更新日：2025年12月31日 UTC）
- URL 正規化とは何か（Google 検索セントラル。最終更新日：2026年7月14日 UTC）
- rel="canonical" などを利用して正規 URL を指定する方法（Google 検索セントラル。最終更新日：2026年7月14日 UTC）
- サイトマップの作成と送信（Google 検索セントラル。最終更新日：2026年7月13日 UTC）
