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

要点 — “Discovered – currently not indexed” (翻訳) 「発見済み – 現在インデックス未登録」は、Google Search ConsoleでGoogleがページを発見したものの、まだ取得（クロール）していないことを示します。そのため検索結果には表示されません。最終クロール日は空欄です。現時点でクロールする価値が低いと判断されたか、取得がサーバーに負荷をかけると見込まれた場合に起こります。重要ページへ到達しやすくし、クロールする価値を明確にすることが対策であり、“Request indexing.” (翻訳) 「インデックス登録をリクエスト。」を繰り返すことではありません。

このステータスの意味

Google Search Consoleを開き、Page Indexingレポートへ進むと、ページがステータス別に表示されます。“Discovered – currently not indexed” (翻訳) 「発見済み – 現在インデックス未登録」は、GoogleがURLの存在を知っているものの、まだ実際にはクロールしていないURLの分類です。 Evidence for this claim Google defines Discovered - currently not indexed as a page it found but has not yet crawled, with an empty last crawl date. Scope: Google Search Console Page Indexing status. Confidence: high · Verified: 2026-07-14 Google: Page indexing report

ページが検索結果に表示されるまでには、次の3段階があります。

1. クロール — Googleがページを取得します。
2. インデックス登録 — Googleがページをデータベースに整理して保存します。
3. 配信（順位付け） — 誰かが検索したとき、Googleがページを表示します。

“Discovered” (翻訳) 「発見済み」のページは、最初の段階の前で止まっています。GoogleはURLを（通常はサイトマップやリンクから）発見して処理待ちリストに加えたものの、まだ取得できていません。URL検査ツールで最終クロール日が空欄になっていることが、最も分かりやすい兆候です。まだ一度もクロールされていないためです。

Googleがページを “Discovered” (翻訳) 「発見済み」のままにする理由

簡単に言えば、理由は2つです。

• サイトに負荷をかけたくない。 今すぐ追加のページをクロールするとサーバーが遅くなる可能性がある場合、Googleは取得を控え、後で再スケジュールします。
• そのページの優先度が低い。 サイト（またはその一部分）が薄い内容や重複ページで構成されていたり、目的のページへ到達しにくかったりすると、GoogleはそのURLのクロール優先度を下げます。これは妥当な診断候補ですが、レポートのステータスだけで証明される事実ではありません。

“Crawled – currently not indexed” (翻訳) 「クロール済み – 現在インデックス未登録」との違い

この2つのステータスはよく似ているため混同されます。違いを決めるのは、クロール済みかどうかの一語です。

• Discovered（発見済み） — Googleはまだページを取得していません。最終クロール日は空欄です。
• Crawled – currently not indexed（クロール済み – 現在インデックス未登録） — Googleは取得したものの、今回は保存しないと判断しました。最終クロール日が表示されます。

つまりDiscoveredは「まだ順番が来ていない」問題、Crawledは「確認したが見送った」問題です。段階が異なるため、対策も異なります。

実際に役立つ対策

• すでにクロールされているページから対象ページへリンクする。 ホームページ、主要ナビゲーション、人気記事などからリンクします。どこからもリンクされない孤立ページは、原因の1つになり得ます。
• ページを本当に役立つ内容にし、他ページのほぼ同じ複製にしない。
• XMLサイトマップに登録する。 Googleがページを発見する助けにはなりますが、優先順位が上がるとは限りません。
• サーバーを高速かつ安定させる。

多くの人が誤解する点

“Request indexing” (翻訳) 「インデックス登録をリクエスト」を何度もクリックしても、対策にはなりません。少数の重要URLを後押しすることはできますが、数百、数千ページには拡張できず、Googleが優先度を下げた理由も解決しません。セクション全体が”Discovered” (翻訳) 「発見済み」に滞留しているなら、それはサイトの品質、構造、またはサーバーについてのシグナルであり、ボタン1つで解決する問題ではありません。 Evidence for this claim Google says repeated recrawl requests for the same URL do not make crawling faster and recommends sitemaps for many URLs. Scope: URL Inspection request indexing; crawling still does not guarantee indexing. Confidence: high · Verified: 2026-07-14 Google: Ask Google to recrawl URLs

サーバーの問題か品質の問題かを見分け、規模の大きい対策へつなげる完全な診断を読みたい場合は、Advancedタブへ進んでください。

要点 — “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をクロールしようとしたが、サイトに過大な負荷がかかると見込まれたため、クロールを後日に再スケジュールした。そのためレポートの最終クロール日は空欄になる。」 Evidence for this claim Google defines Discovered - currently not indexed as a page it found but has not yet crawled, with an empty last crawl date. Scope: Google Search Console Page Indexing status. Confidence: high · Verified: 2026-07-14 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への正規化など複数の原因があり、単一の「品質判定」ではありません。

見落とされがちな点は、Discoveredから抜けてもインデックス登録されるとは限らないことです。Crawled – currently not indexedへ移ったあとも滞留する場合があります。クロールは入口であって保証ではありません。 Evidence for this claim Google says repeated recrawl requests for the same URL do not make crawling faster and recommends sitemaps for many URLs. Scope: URL Inspection request indexing; crawling still does not guarantee indexing. Confidence: high · Verified: 2026-07-14 Google: Ask Google to recrawl URLs

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を参照してください。

AI要約

Advanced版の要点を短くまとめます。

• 何を示すか: GSCのページのインデックス登録ステータスで、GoogleがURLを発見したがクロールしていないことを示します。最終クロール日は空欄で、クロール前の待ち行列の状態であり、ペナルティではありません。
• Crawledとの違い: Discoveredはまだ取得されていない（クロール優先度・処理能力のシグナル）。Crawledは取得済みで、複数の原因を踏まえてインデックス登録を評価中です。Discoveredから抜けても登録は保証されません。
• 2つの主因（Googleの説明）: クロール処理能力（今取得するとサーバーに負荷がかかるため再スケジュール）とクロール需要（品質・内部リンクの面で取得コストに見合わない）です。クロールバジェットのガイドは大規模・急速に変化するサイトを主な対象とし、規模は厳密な境界ではなく目安としています。
• サイト全体のシグナルであることが多い: URLパターンとサイト全体の品質から優先度を推定するという、実務上の推論です。単一URLについてステータスが証明する事実ではありません。
• 診断: 処理能力はCrawl Statsとログ、需要は内部リンクの深さ、孤立ページ、サイト全体の品質で確認します。Gary Illyesの「約90%」という数字は元録音で未検証なので、自社データで確かめます。
• 対策: 内部リンクと孤立ページ、品質、薄い・重複ページ、ファセットやパラメータによる浪費、サーバー速度、優先ページへのリンクを順に改善します。
• リクエスト: インデックス登録のリクエストは少数URLを後押しするだけで、規模を広げられず、原因も直しません。品質を改善せずにページ数だけ減らしても効果はありません。
• 測定: レポートのサンプル一覧は各ステータス1000行が上限で完全とは限らないため、自分のURLインベントリを分母に割合を測ります。

公式ドキュメント

検索エンジンが公開する一次資料です。

Google

• ページのインデックス登録レポート — “Discovered – currently not indexed” (翻訳) 「発見済み – 現在インデックス未登録」と”Crawled – currently not indexed,” (翻訳) 「クロール済み – 現在インデックス未登録」を含む各ステータスの定義。
• クロールバジェットを最適化する — クロール処理能力とクロール需要を説明し、Discovered URLの割合が高いサイトにも触れるガイド。
• Google検索の仕組み：詳細ガイド — クロール、インデックス登録、配信、URL発見の流れと、全ページが各段階を通過するとは限らない理由。
• クロールとインデックス登録 — robots、サイトマップ、クロール制御の基礎。

Bing / Microsoft

• Bing Webmaster Tools — ヘルプ — Bingは”Discovered – currently not indexed”という完全一致のラベルを使わず、URL Inspection / Site Explorerでインデックス状況を示し、クロール割当とコンテンツ価値でクロールを管理します。引用時はBingの現在の用語を確認してください。

出典からの引用

Googleによる記録に残る説明です。各リンクは引用箇所へ直接移動します。

Google — ページのインデックス登録レポートの定義

• “Discovered - currently not indexed: 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 Search Console Help, Page Indexing report。 引用箇所へ移動

Google — 比較のための兄弟ステータス

• “Crawled - currently not indexed: The page was crawled by Google but not indexed. It may or may not be indexed in the future; no need to resubmit this URL for crawling.” (翻訳) 「クロール済み – 現在インデックス未登録：Googleがページをクロールしたものの、インデックス登録していません。将来登録される可能性はありますが、このURLをクロールのために再送信する必要はありません。」 — Google Search Console Help, Page Indexing report。 引用箇所へ移動

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のクローラーは、サイトをクロールするために使用できる同時並列接続の最大数であるクロール処理能力の上限を計算します。」 — Google Search Central, クロールバジェットを最適化するガイド。 引用箇所へ移動
• 同じガイドは、“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に分類されているサイト」にも適用されます。 引用箇所へ移動

“Discovered – currently not indexed” (翻訳) 「発見済み – 現在インデックス未登録」のトリアージチェックリスト

修正を始める前に、上から順に確認して問題の種類を特定します。

• ステータスを確認: GSCのURL検査で最終クロール日が空欄か確認します（空欄なら本当にDiscoveredで、Crawledではありません）。
• 処理能力を確認: Crawl Stats（平均応答時間、ホストステータス）とサーバーログで、遅い応答、タイムアウト、5xx急増を調べます。
• 需要を確認: 対象URLが孤立していたり、サイト構造の深い階層に埋もれていないか確認し、内部リンクの深さを記録します。
• 品質を確認: 本当に異なるページではなく、薄い、ほぼ重複、自動生成のURLパターンになっていないか調べます。
• クロール浪費を確認: ファセット、パラメータ、セッションID、ソフトエラー、無限空間がURL数を膨らませていないか確認します。
• 内部リンク: 重要なDiscoveredページが、Googleがすでにクロールするホームページ、ハブ、ナビゲーションからリンクされ、クリック数も多すぎないことを確認します。
• サイトマップ: 対象URLをXMLサイトマップに含めます（発見には役立ちますが、優先順位を直接上げるレバーではありません）。
• サーバーの健全性: 高速で安定した応答を保ち、5xxとタイムアウトを最小化します。
• 範囲を決める: 価値の低いURLが数件なら放置してもよく、多数または重要な割合が滞留するなら需要・処理能力の原因を直します。
• インデックス登録をリクエスト: 本当に重要なURLを少数だけ対象にし、まとめて修正する手段にはしません。

6つのメンタルモデル

1. Discovered = 発見済みだが未取得。 最終クロール日が空欄なら、それが診断の中心です。取得済みならDiscoveredではなくCrawledです。まずこの区別を正しく行い、その後の判断を揃えます。

2. 処理能力と需要を分ける。 URLがDiscoveredに残る理由は、Googleがクロールできなかった（サーバー処理能力）か、クロールしたくなかった（品質、リンク、優先度による需要）の2つです。作業前にどちらかを診断します。Crawl Statsとログは処理能力、リンクの深さ・孤立ページ・サイト全体の品質は需要を示します。

3. ページ単位のバグではなく、サイト全体のシグナルであることが多い。 GoogleがURLパターンと全体品質からクロール優先度を推定するというのは、パターンの挙動に基づく実務上の推論であり、1つのURLについてステータスが証明する事実ではありません。Discoveredは、単一ページの欠陥よりも、ページカテゴリに関するシグナルであることが多いでしょう。まず自分のデータでパターンを確認し、ページではなくパターンを直します。

4. クロールは入口であって保証ではない。 Discoveredから抜けても、取得という機会を得るだけです。Crawled – currently not indexedに入り、その後も登録されないことがあります。クロール段階だけでなく、品質段階まで計画します。

5. 小規模・中規模サイトは需要に制約されることが多い。 真のクロール処理能力上限が問題になるのは主に非常に大きなサイトです。小規模・中規模サイトでDiscoveredが見られるなら、サーバーの壁より内部リンクと品質という需要を先に確認します。サイト規模だけで決めず、Crawl Statsとログで裏付けます。

6. インデックス登録のリクエストは後押しであり治療ではない。 数件のURLを待ち行列の上位へ動かすだけで、優先度が下がった理由は変わらず、規模も広げられません。本当の対策には構造的なレバーを使います。

DiscoveredとCrawledの違い、そして対策マップ

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

処理能力と需要 — どちらの問題か

要点

• Discoveredは最終クロール日が空欄という意味で、これが区別の中心です。
• Googleの2つの要因はクロール処理能力とクロール需要です。
• Gary Illyesが「約90%のサイトはクロールバジェットを心配する必要がない」と広く引用されていますが、業界報道によるもので独自検証はありません。確認済み統計ではなく方向性の目安です。小規模・中規模サイトの継続的なDiscoveredは、処理能力上限より品質・リンクの問題であることが多いでしょう。
• インデックス登録をリクエストは規模を広げられず、原因も直しません。再送信は不要です。
• クロールされてもインデックス登録は保証されません。
• ページのインデックス登録レポートは各ステータスの例を1000件までしか示さず、完全な一覧とは限りません。自分のURLインベントリを分母にして割合を測ります。

なぜGoogleはこれらのURLをクロールしないのか

処理能力と需要を切り分けるツール

• Log File Analyzer — Googlebotのリクエストが減っているか、どのURLパターンがリクエストを消費しているか、エラーがあるかを確認します。
• Robots.txt Tester — クロール欠落をスケジュール判断とみなす前に、アクセス遮断を除外します。
• Sitemap Validator — 優先する正規URLが存在し、サイトマップを取得でき、構造も健全か確認します。
• Link Analyzer — 対象ページがサイトマップにあるだけでなく、クロール可能な内部リンク経路を持つか調べます。

検証テスト

テスト：内部リンクとサイトマップの修正でクロールが発生するか

実施: 内部リンクとサイトマップを修正して公開し、URLのサーバーログ履歴とURL検査のステータスを確認します。 期待結果: Googlebotが正規URLをリクエストし、最終クロール欄が空欄ではなくなります。 失敗の解釈: URLの発見・優先度シグナルが弱い、別バリエーションが競合している、またはサイト全体のクロール需要に問題が残っています。 監視期間: 通常のクロール周期を使い、すぐに訪問されると決めつけず、同じ優先度のページと比較します。 ロールバック条件: 新しいリンクが意図しないナビゲーションや重複URL経路を作った場合だけリンクを外し、それ以外は残るシグナルを診断します。

テスト：サーバー処理能力の修正でクロールが戻るか

実施: サーバー修正をデプロイし、サーバーログでGooglebotのリクエスト量、応答時間、エラー応答を比較します。 期待結果: 以前のエラーや遅延パターンがなくなり、成功したクローラーリクエストが回復します。 失敗の解釈: 処理能力の制約が残っているか、制限要因が処理能力ではなくクロール需要です。 監視期間: 複数のクロール周期と、修正前のベースラインで使った同じ曜日・時刻のパターンを比較します。 ロールバック条件: デプロイによってクローラー向けエラーや応答遅延が増えた場合は戻します。

問題の測り方

Discovered・未登録URLの母数

指標: このステータスにある送信済み正規URLの件数と割合を、自分のサイトマップ・URLインベントリを分母にして測ります。レポートのサンプル行だけを分母にしません。 分かること: Googleがクロールするより速くバックログが増えているかどうか。 取得方法: ページのインデックス登録レポートをエクスポートし、サイトマップまたはテンプレート別に分けます。ステータスごとの例は1000 URLが上限で完全とは限らないため、国勢調査ではなくサンプルとして扱います。 目安: テンプレート別にベースラインを作り、普遍的な割合ではなく、優先インベントリのバックログが縮小することを目標にします。 頻度: 対策中は毎週、安定後は毎月。

発見から最初のクロールまでの時間

指標: 公開またはサイトマップ登録から、最初のGooglebotリクエストまでの経過時間。 分かること: 優先度と処理能力の変更がスケジューリングを改善したかどうか。 取得方法: 公開・サイトマップの時刻と、サーバーログで最初に確認されたリクエストを結合します。 目安: 自サイトで同種のページを比較します。クロール周期は普遍的な閾値を置けないほど変動します。 頻度: 毎月、またはテンプレート・サーバーに重要な変更を加えた後。

クローラーの成功と浪費

指標: 重要URLへの成功したGooglebotリクエストを、エラーや価値の低いURLパターンと比較します。 分かること: 関心のあるインベントリにクロール処理能力を使えているかどうか。 取得方法: サーバーログをステータスコードとURLパターンで分割します。 目安: 修正前の構成をベースラインにし、エラーを増やさず優先URLの割合が改善することを求めます。 頻度: 診断中は毎週、安定後は毎月。

バックログ分析用のプロンプト

テンプレート単位の原因を見つける

「Discovered – currently not indexed」のURLエクスポートをテンプレートとURLパターンでグループ化してください。各グループでサイトマップへの掲載、内部リンク数、公開日、サーバーログで最初に確認された時刻を比較します。処理能力、クロール浪費、クロール需要の仮説を根拠順に並べ、必要な根拠がない原因は断定しないでください。

対策サンプルを優先順位付けする

影響を受けたURLから、優先度の高いページ、低いページ、新しいページ、古いページ、主要テンプレートごとの代表的なテスト集合を選んでください。仮説ごとに1つの変更を提案し、観測可能な合格シグナルとロールバック条件を示してください。 データ：[行を貼り付け]

理解度を確認する

参照する価値のある資料

関連する記事

• 「Discovered – currently not indexed」の修正方法 — 確認したAhrefsガイド。クロールバジェット、コンテンツ品質、内部リンク、バックリンク、技術的問題という5つの診断領域と、それぞれの対策を扱います。
• 初心者向けテクニカルSEOガイド — クロールとインデックス登録が全体像のどこに位置するかを説明します。

公式資料

• Page Indexing report (Google) — 2つのステータス定義の出典。
• クロールバジェットを最適化する（Google） — クロール処理能力と需要、およびこのステータスを明示的に扱う文書。

その他

• 「Discovered Currently Not Indexed」の修正（Search Engine Journal） — Muellerの処理能力と品質の整理を紹介する記事。
• 「Discovered - currently not indexed」の理解と解決（Search Engine Land） — Dan Taylorによる診断の解説。
• 「Discovered – Currently Not Indexed」の修正方法（Onely） — サーバーログを使って処理能力と品質の原因を診断する技術解説。
• GoogleによるDiscovered – Currently Not Indexedの説明（Search Engine Roundtable） — Barry SchwartzによるGoogle関係者の発言報道。
• r/TechSEO — クロールとインデックス登録を診断するコミュニティ。

変更履歴