Search Console を開くと、「未登録」が増えただけで現場がざわつくことがあります。サイト移行やカテゴリ再編、CMS 改修の直後であれば、なおさらでしょう。ただし、その不安に引っ張られて件数の大きい行から順に直し始めると、手戻りが増えます。Google の ページのインデックス登録レポート は全体傾向をつかむための道具であり、重要ページの生死を判定する画面ではありません。重要ページの状態確認には URL 検査ツール を使うべきだと、Google 自身も明記しています。
インデックスカバレッジエラー対応で本当に守るべきなのは、「未登録件数をきれいにすること」ではなく、「売上、問い合わせ、指名検索の入口になる URL を Google の評価対象に戻すこと」です。ここを取り違えると、絞り込み URL や古いパラメータ付き URL を一週間かけて整える一方で、サービス詳細やカテゴリトップが埋もれたままになります。現場で痛いのは、この順番の誤りです。
この記事では、Google の クロールとインデックス登録、インデックス登録、重複した URL の正規化 を土台にしながら、JPSM SEO 編集事業部が実務で採る判断順を整理します。結論を先に言えば、件数ではなく重要 URL、設定画面だけでなく実クロール、単発修正ではなく信号の整合です。この三つを押さえれば、インデックスカバレッジエラーは短時間で切り分けやすくなります。
件数の増減より重要URLの状態を先に見る
最初にやるべきなのは、重要 URL を三段階に分けることです。 未登録件数の大きい理由を先に読むのではなく、売上や集客への影響が大きい URL を 30〜100 本に絞ってください。月間 PV が 10 万未満のサイトなら 30 本前後、10 万〜100 万なら 50 本前後、100 万以上なら 100 本前後から始めるのが現実的です。これ以上広げると初動が鈍り、これ以下だとページの型ごとの不具合を見落としやすくなります。
Google は ページのインデックス登録レポート で、500 ページ未満の小規模サイトなら、このレポートを常時追わず `site:` 検索や重要ページの確認から始めてもよいと案内しています。ここから分かるのは、すべての URL を平等に扱う必要はないということです。逆に言えば、500 ページ未満のサイトで毎週レポート全体を眺め続けるより、重要ページの URL 検査を優先するほうが早く成果につながります。
重要 URL の線引きは、次の表まで具体化しておくべきです。会議のたびに「このページも大事かもしれない」と候補が増える組織ほど、先に基準を固定したほうが速く進みます。
URL群 | 優先度 | 先に確認する理由 | 目安 |
|---|---|---|---|
サービス詳細、料金、比較、カテゴリトップ | 最優先 | 売上と問い合わせに近く、ここが未登録だと機会損失が大きい | 10〜30 URL |
指名検索で入口になるページ、主要記事、主要導線ページ | 高 | 検討初期の流入を支えるため、未登録の放置コストが高い | 20〜40 URL |
絞り込み、並び替え、計測パラメータ、古い一覧 | 低 | Google が重複や低価値と判断しても不自然ではない | 必要時のみ確認 |
ここで強く勧めたいのは、「未登録は悪、登録済みは善」という見方を捨てることです。Google は ページのインデックス登録レポート の中で、重複 URL はインデックスされないことがあり、それ自体は問題ではないと説明しています。また 重複した URL の正規化 でも、Google が代表 URL を選ぶ前提が示されています。問題は未登録件数そのものではなく、事業側が残したい URL と Google が代表と見なした URL がずれていることです。
実務では、次の基準で判断すると迷いにくくなります。
- その URL は売上、問い合わせ、指名検索のどれに関わるか。
- 直近 30 日で自然検索流入またはコンバージョン補助に入っているか。
- サイト構造上、その URL が親ページや主要一覧から 3 クリック以内にあるか。
- 同じページの型の URL が 10 本以上あり、同じ症状が広がる可能性があるか。
例外もあります。たとえばサイト移行直後で 301 の設計が崩れ、旧 URL から新 URL への評価移行が止まっている場合は、古い URL 群の修正を先に進めるべきです。また、法務や採用など公開必須のページが noindex になっている場合も、流入規模に関係なく最優先に引き上げます。重要 URL 起点が基本ですが、法的リスクと移行事故は例外として別枠で扱ってください。
原因は三つの画面とクロールログで切り分ける
インデックスカバレッジエラーの調査で、最初からツールを増やしすぎるのは得策ではありません。最初の一時間は、ページのインデックス登録レポート、URL 検査、クロールログの三つに絞るべきです。 これだけで、「Google が見つけていないのか」「見つけたが採用していないのか」「設定が矛盾しているのか」の大半を分けられます。
ページのインデックス登録レポートでは、件数の多さより理由の急増時点を見ることが重要です。前週比で急に増えたのか、特定の公開日に跳ねたのか、特定のページの型だけ増えているのか。この三点が見えれば、原因はかなり絞れます。Google は同レポートで、例示 URL が最大 1,000 件に限られるとも案内しています。つまり、一覧に出ていないから安全とは言えません。件数が 5,000 を超えるサイトでは、表示された見本だけで判断しないほうが安全です。
URL 検査では、「インデックス済みの状態」と「ライブテストの状態」を必ず分けて読むべきです。 Google は URL 検査ツール で、ライブテストはリアルタイムの取得結果であり、サイトマップ掲載、重複判定、品質や手動対応などすべての条件を確認するわけではないと明記しています。ライブテストが通っても、インデックス済みの状態が古いままなら、検索結果にはまだ反映されていません。ライブテストが成功したから修正完了と判断するのは避けるべきです。
クロールログでは、難しい分析は不要です。重要 URL ごとに次の四点を見れば足ります。
- Googlebot Smartphone が直近 14 日に来ているか
- 最終クロール時の HTTP ステータスが 200 か
- レスポンスが 5xx やタイムアウトで不安定になっていないか
- canonical 先や主要本文がクロール時点で出力されていたか
この四点で、発見不足と採用不足の切り分けが進みます。ログが見られない環境でも、CDN ログや WAF ログがあれば代用できます。例外として、会員制ページや一部のプレビュー環境のように Googlebot がそもそも到達しない構成なら、ログより公開設定とリンク構造の確認を先に置いたほうが妥当です。
初動で使う確認手順は、次の六項目に固定すると迷いません。
- 重要 URL 台帳を作り、売上系、集客系、指名系の三群に分ける。
- 各 URL の URL 検査で、インデックス済みの canonical とライブテストの状態を並べて記録する。
- HTTP ステータスが 200 以外の URL を除外し、転送や 404 を先に整理する。
- Googlebot Smartphone の直近 14 日アクセス有無を確認する。
- 重要 URL が XML サイトマップに載っているかを見て、不要 URL が混ざっていないかも確かめる。
- モバイル表示で主要本文、見出し、内部リンクが欠けていないかを目視する。
Search Console の操作をチームに共有したい場合は、Googleインデックス登録を早めたいときの実務手順。Search Consoleを道具として使い切る も役立ちます。ただし、操作方法を覚えるだけでは足りません。どの URL を先に見て、どの画面で事実確認をするかまで決めて初めて、調査が業務になります。
canonicalと除外設定の役割を混同しない
インデックスカバレッジエラーが長引く現場では、canonical、noindex、robots.txt、サイトマップが互いに違う方向を向いていることが珍しくありません。ここで必要なのは設定を増やすことではなく、各手段の役割を一つずつ分けることです。 役割が曖昧なまま「とりあえず両方入れる」を続けると、Google 側の解釈はむしろ不安定になります。
Google は 重複した URL の正規化 で、canonical は希望を伝える手段であって絶対命令ではないと説明しています。つまり、`rel="canonical"` を書けば必ずその URL が代表になるわけではありません。内部リンク、サイトマップ、リダイレクト、HTTP/HTTPS の統一など、他の信号とそろって初めて強く働きます。canonical だけで重複問題を片づけようとする設計は弱いと考えるべきです。
一方で noindex を使用してページを検索インデックスから除外 では、`noindex` を有効にするにはそのページを Googlebot が取得できなければならず、robots.txt で遮断すると `noindex` が読まれないと明記されています。ここは誤解が多いところですが、検索結果から確実に外したいページに対して、robots.txt だけを使うのは避けるべきです。 robots.txt は robots.txt の概要 にあるとおり、主目的はクロール制御です。検索結果からの除外手段とは役割が違います。
実務では、次の表に沿って使い分けると混線しにくくなります。
手段 | 使うべき場面 | 先に避けるべき誤用 | 例外 |
|---|---|---|---|
canonical | 内容が近い URL 群から代表 URL に評価を寄せたいとき | 代表 URL と内部リンク先がずれているまま canonical だけ入れる | 商品色違いのように差分が薄い群では有効 |
noindex | 検索結果に出したくないが、クロールは許可したいページ | robots.txt で塞いだまま noindex を入れる | 一時的に除外したい検証ページでも使える |
robots.txt | 不要なクロールを抑えたいとき | 検索結果から消す目的で使う | サーバー負荷が高い大規模絞り込み群では有効 |
サイトマップ | 残したい canonical URL をまとめて知らせたいとき | noindex や重複 URL まで大量に載せる | 重要 URL だけの小さなサイトマップは検証向き |
ここでの推奨は明確です。重複 URL を整理したいなら、最初に canonical の向き先、内部リンク先、サイトマップ掲載 URL を一致させるべきです。 反対に、検索結果から外したいページなら noindex を採り、robots.txt はクロール負荷を抑える用途に限定するべきです。役割を混ぜると、原因の特定も修正確認も難しくなります。
また、Google は サイトマップの概要 と サイトマップの作成と送信 で、サイトマップは重要な URL を伝える手段だが登録を保証しないと案内しています。したがって、新規記事が埋もれているときに、内部リンクを弱いまま放置してサイトマップ送信だけで済ませるのは不十分です。月間 PV 10 万未満のサイトでは、カテゴリ導線と関連記事リンクの不足のほうが、サイトマップ未送信より深刻なことが少なくありません。内部リンク設計を深めるなら、内部リンク最適化の2026年実務 回遊を増やすだけで終わらない評価配分の考え方 と アンカーテキスト最適化の最新実務 2025年更新ガイダンスから逆算する内部リンク設計 を合わせて読むと、修正の方向がそろいやすくなります。
未発見の重要ページを四十八時間で立て直す
重要 URL が `Discovered - currently not indexed` や `Crawled - currently not indexed` に入っているとき、404 の山を先に片づけるより、未発見または未採用の重要ページを二日で立て直すほうが優先です。 404 が数千件あっても、それが古いキャンペーンや終了したお知らせなら、今の売上への影響は限られます。反対に、主要サービスページやカテゴリトップが未登録なら、検索流入も指名以外の接点も止まってしまいます。
JPSM SEO 編集事業部では、重要 URL を復旧するときの順番を次のように固定しています。
- HTTP ステータスを 200 にそろえる。
- 自己参照 canonical を確認し、別 URL へ飛んでいないかを見る。
- noindex、x-robots-tag、robots.txt の三点で矛盾がないか確認する。
- 親カテゴリ、関連記事、パンくずから最低 3 本、できれば 5 本の内部リンクを入れる。
- 重要 URL だけをまとめた小さなサイトマップに掲載する。
- 修正を反映したあとに URL 検査で再確認し、最後にインデックス登録をリクエストする。
この順番にしている理由は、Google が ページのインデックス登録レポート で「見つけられないページはリンクやサイトマップから辿れるようにするべき」と説明しているからです。さらに、同レポートではホームページから他ページへ辿れる設計も推奨されています。つまり、サイトマップは補助であり、主役は内部リンクです。 とくに新規記事や新規カテゴリは、公開当初に親ページから 1 本しかリンクされていない状態だと埋もれやすくなります。
ここで迷いやすいのが `Crawled - currently not indexed` の扱いです。これは品質だけの話として片づけないほうがいいでしょう。もちろん内容が薄いページは不利ですが、実務では canonical ずれ、内部リンク不足、ページの型の差分の小ささ、モバイル本文不足が混ざっていることが多いからです。Google の モバイル ファースト インデックスに関するベスト プラクティス では、モバイル版とデスクトップ版で主要内容をそろえるよう求めています。主要本文がモバイルで省略されているなら、品質評価以前に構成上の問題です。
JavaScript に依存したページも優先度を上げるべきです。JavaScript SEO の基本を理解する では、Google がレンダリング後の HTML を見て内容を理解する前提が示されていますが、初回 HTML に主要本文や主要リンクが薄い構成は安定しません。重要なサービスページや比較ページでは、本文と主要リンクを初回 HTML に含めるべきです。 例外は、会員向けダッシュボードや検索結果に出す必要のない機能ページです。そこまで SSR や事前生成を広げる必要はありません。
修正確認の進め方にも順番があります。Google は ページのインデックス登録レポート で、修正確認は同じ問題の全インスタンスを直してから依頼する前提だと説明しています。したがって、1 URL だけ直してすぐ検証を始めるのは避けるべきです。 先にページの型単位、URL 群単位で潰し切ってから進めたほうが失敗しにくく、再確認も早く終わります。
サイト規模に応じて監視と修正の単位を変える
インデックス改善は、サイト規模を無視すると空回りします。同じ手順を全サイトに当てるのではなく、月間 PV と対象 URL 数で監視粒度を変えるべきです。 ここを曖昧にすると、小規模サイトで過剰な仕組みを作るか、大規模サイトで手作業に依存するかのどちらかに偏ります。
月間 PV 10 万未満、重要 URL が 300 未満のサイトでは、重要 URL 台帳と週次点検で十分です。おすすめの運用は、主要 URL を 30 本に絞り、毎週 1 回だけ URL 検査と `site:` 検索を行うやり方です。この規模で先にログ分析基盤を整えるより、カテゴリ導線、関連記事リンク、canonical の自己参照確認を済ませたほうが改善は早く進みます。例外は、サイト移行直後か、JavaScript で本文を出し分けている場合です。この二つは小規模でもログやレンダリング確認を入れたほうが安全でしょう。
月間 PV 10 万〜100 万、対象 URL が 500〜1 万程度のサイトでは、ページの型単位の監視へ切り替えるべきです。記事、カテゴリ、サービス、特集、採用など、型ごとに未登録理由を分けて見ないと、影響範囲を読み違えます。この帯では、重要 URL を 50 本に絞ったうえで、ページの型別に canonical、meta robots、内部リンク本数、サイトマップ掲載の有無を週次で点検するのが現実的です。新規公開が週 10 本を超えるなら、重要 URL 専用サイトマップを分けるべきです。
月間 PV 100 万以上、複数部署が更新するサイトでは、Search Console だけに依存しないほうがいいでしょう。例示 URL の上限があるため、事故の広がりを十分につかめないからです。この規模では、ページの型別の 200 応答率、Googlebot 到達率、noindex 混入率、canonical 不一致率を日次で見る運用が必要です。重要 URL は 100 本以上を別管理にし、週次ではなく日次で異常を監視するべきです。例外は、更新頻度が低い IR や採用中心のサイトです。その場合は日次までは不要で、公開日ベースの監視で足ります。
EC や大規模データベース型サイトでは、全部を登録させようとする発想を捨てるべきです。重複 URL の統合 と robots.txt の概要 を踏まえると、並び替え、絞り込み、ページネーション、在庫変動 URL のどれを残し、どれを捨てるかを先に決めたほうが早く進みます。対象 URL が 1 万を超えるなら、代表 URL の固定、内部リンクの収束、サイトマップの精査、不要クロールの抑制を同時に進めるべきです。ここを後回しにすると、インデックス改善ではなくクロール浪費への対処に追われます。
規模別の推奨をまとめると、次の三つです。
- 小規模サイトは「重要 URL 単位」で見る。
- 中規模サイトは「ページの型単位」で見る。
- 大規模サイトは「ページの型単位に加えてログ指標」で見る。
この切り替えを曖昧にしないことが、五つ目の判断軸です。やることを増やすより、どの単位で異常を捉えるかを先に決めたほうが失敗しません。
再発を防ぐ公開前チェック実務を定着させる
インデックスカバレッジエラーは、修正より再発防止のほうが重要です。毎回 Search Console を見て慌てる運用から抜けるには、公開前チェックを開発と編集の共通手順にするべきです。 ツールを増やす必要はありません。確認項目を固定し、誰が見ても同じ結論になる状態を先に作ることが大切です。
公開前に最低限確認したいのは、次の七項目です。
- 重要ページが 200 を返し、不要な転送を挟んでいないか。
- canonical が自己参照または意図した代表 URL を向いているか。
- `noindex`、x-robots-tag、robots.txt が矛盾していないか。
- 親カテゴリ、パンくず、関連記事から 3 本以上の内部リンクが入っているか。
- XML サイトマップに掲載すべき URL だけが載っているか。
- モバイル版とデスクトップ版で主要本文と見出しが一致しているか。
- JavaScript 実行前の HTML に主要本文と主要リンクが含まれているか。
この七項目は、CMS 改修時にも記事公開時にも使えます。とくに 3 と 4 は、編集担当と技術担当の認識差が出やすいポイントです。編集側は「公開したから見つかるはず」と考えがちですが、技術側は「canonical は入っている」と答えがちです。そこに内部リンク本数とサイトマップ掲載可否まで加えて同じ表で見ると、会話が具体的になります。
よくある誤解も先に潰しておいたほうがいいでしょう。robots.txt で検索結果から外せると思わないこと、ライブテスト成功をインデックス確定と見なさないこと、canonical を書けば代表 URL が固定されると思い込まないこと。 この三つを外すだけで、インデックス事故の再発率はかなり下がります。仕組みの話に見えて、実際には判断の順番の話です。
支援を外に求めるべき場面もあります。重要 URL の定義が部署ごとにずれる、サイト移行後に canonical と内部リンクの設計が噛み合わない、大規模サイトでログ監視の基準が作れない。この三つのどれかに当てはまるなら、担当者の気合いだけでは回りません。JPSM SEO 編集事業部でも、Search Console の数字を追う前に、重要 URL の線引き、ページの型別の除外設計、公開前チェック表の作成から整理することが多くあります。インデックス改善は、根性論ではなく設計の問題です。
最後に、明日からではなく今日やるべき順番を置いておきます。
- 重要 URL を 30〜100 本だけ選び、売上系、集客系、指名系に分ける。
- その URL 群だけ URL 検査を回し、インデックス済み状態とライブテストの差分を記録する。
- canonical、noindex、robots.txt、内部リンク、サイトマップの矛盾を同じ表にまとめる。
- 未発見または未採用の重要ページから先に直し、404 の山は後回しにする。
- 同じ問題を持つ URL 群を直し切ってから検証を始め、二〜四週間は変化を追う。
インデックスカバレッジエラーは、件数を追う仕事ではありません。重要 URL を守る順番を守れるかどうかで、改善速度が決まります。まずは今日中に重要 URL 台帳を作り、最上位の 10 URL だけでも URL 検査と設定確認を終えてください。それが、遠回りを止める最初の一手です。