言語

発見済み – 現在インデックス未登録

Google Search Consoleの「Discovered – currently not indexed」が示す状態、Crawledとの違い、発生理由、クロール処理能力とクロール需要の診断、現実的な対策を説明します。

初回公開：2026年6月23日 · 最終更新：2026年8月11日 · 上級者向け
AI執筆者：AI v2
このページには証拠シグナルが1件あります

「Discovered – currently not indexed」は、GoogleがURLを発見したものの、まだ取得していない状態です。最終クロール日は空欄で、Crawled – currently not indexedとの違いは、ページが取得済みかどうかです。原因はサーバー側のクロール処理能力、またはサイト構造・内部リンク・コンテンツ価値によるクロール需要に分けて調べます。重要URLへの内部リンク、重複や低価値URLの整理、安定したサーバー運用を優先し、インデックス登録のリクエストは少数の重要URLに限ります。クロールされてもインデックス登録が保証されるわけではありません。

要点 — “Discovered – currently not indexed” (翻訳) 「発見済み – 現在インデックス未登録」は、GoogleがURLを発見したもののまだクロールしていない状態です。最終クロール日が空欄であることが、“Crawled – currently not indexed” (翻訳) 「クロール済み – 現在インデックス未登録」と分ける決定的な事実です（後者は取得したが保存しなかった状態）。Googleが見る2つの要因は、クロール処理能力（今取得するとサーバーに負荷がかかるため再スケジュールする）と、クロール需要（サイトやページが取得コストに見合わないという品質・内部リンクのシグナル）です。サイト全体に現れるパターンであることも多いため、まず内部リンク、内容の品質、クロール浪費、優先ページへのリンクを見直し、大規模サイトではサーバーの速度と安定性も確認します。“Request indexing” (翻訳) 「インデックス登録をリクエスト」は少数URLを後押しするだけで、原因を直しません。クロールされてもインデックス登録が保証されるわけではありません。

Googleの説明から分かること

ページのインデックス登録レポートの定義をそのまま示すと、“The page was found by Google, but not crawled yet. Typically, Google wanted to crawl the URL but this was expected to overload the site; therefore Google rescheduled the crawl. This is why the last crawl date is empty on the report.” (翻訳) 「Googleがページを発見したものの、まだクロールしていない。通常、GoogleはURLをクロールしようとしたが、サイトに過大な負荷がかかると見込まれたため、クロールを後日に再スケジュールした。そのためレポートの最終クロール日は空欄になる。」 この主張の根拠 Google defines Discovered - currently not indexed as a page it found but has not yet crawled, with an empty last crawl date. 対象範囲： Google Search Console Page Indexing status. 信頼度： 高 · 検証日： Google: Page indexing report 最後の一文が決め手です。最終クロール日が空欄 = まだ取得されていないということです。GSCでURLを検査しても、クロール記録は表示されません。

これはクロール前の待ち行列の状態です。インデックス登録後に削除されたわけでも、ペナルティを受けたわけでもありません。GoogleはURLの存在を知っています。サイトマップ、内部リンク、外部リンクなどから届いたURLを、まだ取得していないだけです。

DiscoveredとCrawled – currently not indexedの違い

ここは正確に区別すべき点です。2つのステータスは根本原因も対策も反対になります。詳細な比較表はCheat Sheetsタブに置き、要点だけをまとめると次のとおりです。

  • Discovered – currently not indexed（発見済み – 現在インデックス未登録） = まだ取得されていない。最終クロール日は空欄で、Googleが（まだ）クロールを割り当てなかったという、クロール優先度・処理能力のシグナルです。
  • Crawled – currently not indexed（クロール済み – 現在インデックス未登録） = 取得されたが保存されていない。最終クロール日があり、Googleが今回はインデックス登録しないと判断した状態です。重複、薄い内容、別URLへの正規化など複数の原因があり、単一の「品質判定」ではありません。
この主張の根拠 Google defines Discovered - currently not indexed as a page it found but has not yet crawled, with an empty last crawl date. 対象範囲： Google Search Console Page Indexing status. 信頼度： 高 · 検証日： Google: Page indexing report

見落とされがちな点は、Discoveredから抜けてもインデックス登録されるとは限らないことです。Crawled – currently not indexedへ移ったあとも滞留する場合があります。クロールは入口であって保証ではありません。 この主張の根拠 Google says repeated recrawl requests for the same URL do not make crawling faster and recommends sitemaps for many URLs. 対象範囲： URL Inspection request indexing; crawling still does not guarantee indexing. 信頼度： 高 · 検証日： Google: Ask Google to recrawl URLs

最終クロール欄が空なら上流の問題です。GoogleはURLを知っているものの、まだクロールを実行していません。 出典： Google Search Console ヘルプ

GoogleはURLを認識しています。強調されたDiscovered（発見済み – 現在インデックス未登録）分岐では、まだ取得されておらず、最終クロール欄は空です。診断の中心はクロール優先度または処理能力です。Crawled（クロール済み – 現在インデックス未登録）分岐では、Googleがページを取得したものの登録しておらず、最終クロール日に日付があります。診断の中心はインデックス選択、ページ価値、重複、レンダリング、競合するシグナルです。

© Patrick Stox LLC · CC BY 4.0 ·

Googleがページを「Discovered」に残す理由

Googleはクロールを2つの側面からなる予算として説明しています。Discoveredは、そのどちらかに問題があるときに現れる代表的な症状です。

クロール処理能力 — サーバー側

Googleは、クロール処理能力の上限、つまりサーバーの応答に合わせて調整する同時接続数の最大値を計算します。クロールバジェットのガイドには、“Google’s crawlers calculate a crawl capacity limit, which is the maximum number of simultaneous parallel connections that Google can use to crawl a site,” (翻訳) 「Googleのクローラーは、サイトをクロールするために使用できる同時並列接続の最大数であるクロール処理能力の上限を計算します。」また、“if the site slows down or responds with server errors, the limit goes down and Google crawls less.” (翻訳) 「サイトの速度が落ちたりサーバーエラーを返したりすると上限が下がり、Googleのクロール量も減ります。」とあります。遅い応答、タイムアウト、5xxエラーはすべてクロールを抑制します。処理能力がボトルネックなら、取得する余地がないためURLがDiscoveredに積み上がります。

クロール需要 — サイトの品質と構造

もう一方は、GoogleがそのURLをクロールしたいかどうかです。Discoveredの問題の多くはここにあります。Googleのシステムは、URLのパターン、内部リンク、サイト全体の品質からクロール優先度を推定します。ページが深い階層に埋もれている、孤立している、大量の低価値な類似ページの1つに見える、といった場合は需要が弱く、待ち行列に残ります。

Googleの大規模サイト向けクロールバジェットガイドは、このステータスを明示的に取り上げています。ガイドの対象は*“Sites with a large portion of their total URLs classified by Search Console as Discovered - currently not indexed.”* (翻訳) 「総URLの大部分がSearch ConsoleでDiscovered - currently not indexedに分類されているサイト」です。つまりGoogle自身が、Discoveredをクロールバジェット（処理能力と需要）の制約と結び付けています。対象として挙げるのは、URLが数百万あるサイト、急速に変化しておおむね1万ページを超えるサイト、DiscoveredのURL比率が高いサイトですが、これらは厳密な閾値ではなく大まかな分類目安です。規模がそれより小さいサイトでは、ハードな処理能力上限の証拠と決めつけず、背景資料として扱ってください。

ページ単位の不具合ではなく、サイト全体のシグナルであることが多い

多くの場合、この見方が役立ちます。ただし、Googleが頻度として公表した数字ではなく、観察に基づくパターンです。Discoveredは、単独の「ページXに欠陥がある」という意味ではほとんどありません。URLのパターンやサイト全体の品質から、ページのカテゴリ全体を積極的にクロールする価値が低いとGoogleが推定していることが多いのです。これはURLパターンやテンプレートの挙動から導く実務上の推論であり、1つのURLについてステータス自体が証明する事実ではありません。John Muellerは、このステータスの主な要因として、サーバーの処理能力とサイト全体の品質を繰り返し説明しています。URLの自動生成しすぎ、内部リンク不足、重要ページの優先度を上げるためにサイト全体を強化する必要性など、実際の原因はヘルプ文書の「過負荷」より広い、という趣旨です（業界報道を介したオフィスアワーの要約で、逐語引用ではありません）。

規模も関係します。Gary Illyesはポッドキャストで、業界報道を通じて「サイトの約90%はクロールバジェットを考える必要がない」と広く引用されています。ただし、その数字を元の録音と照合していないため、確認済み統計ではなく広く伝えられた近似値として扱います。方向性としては、小規模・中規模サイトで真のクロール処理能力上限に達する可能性は低く、Discoveredのバックログが続くなら、サーバーの壁よりも品質、内部リンク、クロール浪費という需要の問題であることが多いでしょう。サイト規模だけで決めつけず、Crawl Statsとログで確認してください。

原因を切り分ける診断方法

修正する前に、処理能力の制約か需要の制約かを確認します。

  • 処理能力を確認する。 GSC Crawl Stats（平均応答時間、ホストステータス、レスポンスコードの内訳）とサーバーログで、遅い応答、5xx、タイムアウトの急増を調べます。サーバーがGoogleのクロールを明らかに抑えているなら、処理能力の問題です。
  • 需要を確認する。 内部リンクの深さ（ホームページから何クリックか）、孤立ページ（リンクがないページ）、サイト全体の品質（薄い、重複、自動生成されたURLパターン）を確認します。Discovered URLが特定のテンプレートや低価値グループに偏っていれば、需要の問題が疑われます。

「大半のサイトはX」という一般的な頻度だけで対策を選ばないでください。自分のURLパターンの分類、サーバーログ、Crawl Stats、内部リンク数、サイトマップとインベントリの対応、対象グループの事業上の重要度という、目の前の根拠から判断します。小規模・中規模サイトでは需要に傾くことが多く、大規模サイト、EC、プログラム生成サイトでは両方が関係しがちですが、対策を決める前に自社データで確認してください。

対策

多くのサイトで効果が大きい順に、次のレバーを検討します。

内部リンクを強化し、孤立ページを直す

内部リンクは、管理しやすい需要のレバーです。どこからもリンクされないページや、何クリックも深いページがDiscoveredに集中します。ホームページ、ハブページ、主要ナビゲーションなど、Googleが頻繁にクロールするページから重要URLへリンクし、サイト構造上の階層を浅くします。

コンテンツ品質を高め、薄いページや重複ページを統合する

GoogleがURLパターンから「低価値」と読んでいる場合、ページ数を増やしても役に立ちません。Muellerのページ数削減に関する説明から学ぶべき点は、サイトを改善せずにインデックス登録可能なページ数だけ減らしても、サイトは良くならないということです。ページ数の手術だけでは、品質起因のDiscovered問題は直りません（オフィスアワーの回答を要約したもので、逐語引用ではありません）。薄いページやほぼ重複するページを統合し、残すページには本当にクロールする価値を持たせます。

クロール浪費を減らす

ファセットナビゲーション、URLパラメータ、セッションID、ソフトエラー、無限に続くURL空間は、典型的な「Discoveredの製造機」です。価値の低いURLに処理能力を使わせるため、本来のコンテンツに到達しにくくなります。ECサイトやプログラム生成サイトで特に大きな浪費が生じます。不要なクロールを削れば処理能力が空き、URLパターンからGoogleが読み取る品質シグナルも明確になります（crawl budgetとspider trapsも参照）。

サーバーを高速化し、安定させる

処理能力の側面では、高速で安定した応答がクロール処理能力の上限を引き上げます。Google自身の説明どおり、サイトが遅くなったりエラーを返したりするとクロール量は減ります。5xxエラーを直し、応答時間を短縮し、タイムアウトをなくします。

優先ページへのリンクを獲得する

外部リンクは、リンク先ページのクロール需要を高めます。ただし効果はゆっくり現れます。本当に重要なページには有効なレバーですが、即時に切り替わるスイッチではありません。バックリンク1本でURLが一晩でDiscoveredから抜けるとは考えないでください。

「インデックス登録をリクエスト」を使う場合、使わない場合

早めにクロールしたい少数の本当に重要なURLにだけ使います。大量のDiscovered URLに対する解決策として扱ってはいけません。規模を広げられず、Googleも再送信は不要だと明示しています。兄弟ステータスのCrawledについても、Googleの案内はクロールのためにURLを再送信する必要はないというものです。Discoveredも同様です。リクエストは待ち行列を少し後押しするだけで、ページの優先度が下がった理由を変えません。

何もしなくてよい場合

Discoveredが少数あるだけなら、通常のトリアージとして許容できます。GoogleがURLを発見したものの、まだ優先していないだけで、後から自然にクロールする可能性があります。本当に価値の低いURLが数件なら放置しても問題ありません。多数または重要なURLがDiscoveredに滞留している場合に、背後の処理能力・需要の問題へ対応します。

「多数または重要な割合」を測るときは、まず分母を定義します。ページのインデックス登録レポートの各ステータスのサンプル一覧は1000 URLで上限があり、影響を受けた全URLを表示する保証もありません。エクスポートされた例だけを完全な一覧と見なさず、レポートの件数を自分のサイトマップやURLインベントリ（サンプルだけではない）と比較し、行数ではなく事業上の重要度とトラフィック可能性で優先順位を付けます。

特殊ケース：大規模サイト、ECサイト、プログラム生成サイト

ここではDiscoveredが見た目だけの問題ではなくなります。数百万URL、ファセットナビゲーション、ほぼ重複する商品ページ、無限のパラメータ空間を持つサイトは、Googleがクロールしたい量をはるかに超えるURLを生成するため、設計上の理由で大部分がDiscoveredに残ります。手順はまずクロール浪費を減らすこと（統合、必要に応じた低価値領域のクロール抑制、パラメータ爆発の修正）、次に重要URLへの内部リンクと品質改善で需要を高め、最後にサーバー処理能力を整える順です。権威性の弱い新しいサイトにも、需要が弱いため重要度の低いページが待たされるという、同じ問題の穏やかな形が起きます。

この問題の位置付け

DiscoveredはPage Indexingレポートにあるステータスの1つで、クロール段階の問題です。そのため対策はcrawl budget、内部リンク、インデックス登録の基本に寄ります。兄弟のCrawled – currently not indexedは、同じ不満が品質段階で現れたものです。GoogleがそもそもURLを発見して取得する上流段階はcrawling、その後の下流段階はindexingを参照してください。

専門家メモを追加

専門家の引用を固定

新しい人物ですか？まず、 /admin/experts/ → 専門家の引用を固定 から未登録プロフィールを作成してください。