Search ConsoleのURL検査「インデックス登録をリクエスト」は何をしているのか ── 公式の言葉で確認する13項目（2026年9月時点）

01 何が起きたか — 「インデックス登録をリクエスト」を押すと、実際は何が起きているのか

「押せば早くなる」という思い込みと、公式の言葉のズレ

Search ConsoleのURL検査ツールには、URLを1つ入力すると「インデックス登録をリクエスト」というボタンが現れる場面がある。多くのWEBディレクターがこのボタンを、公開直後の記事や更新したページを早くGoogleの検索結果に反映させるための操作として使っている。SEOに関する解説記事の中にも、「更新したら必ずこのボタンを押すこと」という案内が並んでいることがあり、押すこと自体が一種の儀式のようになっている場面も見かける。だが、Search Console ヘルプの「URL検査ツール」ページを読むと、そこに書かれている説明は、期待されている効果と少しずれている。

"Submitting a request does not guarantee that the page will appear in the Google index."

（訳: リクエストを送信しても、そのページがGoogleのインデックスに掲載されることは保証されない。）

この一文は、ボタンを押す行為そのものの意味を規定している。リクエストは「掲載を約束する操作」ではなく、「インデックスキューに追加を依頼する操作」にすぎない。キューに入った後、どれくらいの優先順位で処理されるかについて、公式ページは具体的な説明を用意していない。「保証しない」という一文は控えめな表現に見えるが、この記事全体で確認する内容の前提になっている一文でもある。

「すぐにインデックスされた」体験は、リクエストの効果とは限らない

リクエストを送った後に実際にページが検索結果に出て、「効果があった」と感じることは珍しくない。だが、公式ページはリクエストを送らなくても通常のクロールでインデックスされる経路の存在を前提として書かれており、リクエストを送ったこととインデックスされたことの間に、公式に確認された因果関係が示されているわけではない。体感として効果を感じても、それがリクエストによるものか、通常のクロール順であればいずれ処理されていたものかを、公式の記述だけから切り分けることはできない。

「早く」ではなく「漏れなく」を目的にする視点

公開直後のページを1日でも早く検索結果に出したいという事情は、キャンペーンページや期間限定の告知など、実務では珍しくない。だが公式の記述を踏まえると、リクエストの役割は「速度を上げること」というより、「発見の経路を、通常のクロールとは別にもう1つ用意すること」に近い。内部リンクが少ないなど、通常のクロールでは発見されにくい構造のページに対して、リクエストという明示的な発見経路を足す、という位置づけで捉えると、公式の説明との食い違いが小さくなる。

02 なぜ・背景 — 「テスト」と「登録」が分かれている理由

「今のページ」を見る機能と、「Googleが持っているページ」を見る機能は別

URL検査ツールには、大きく分けて2つの見方がある。1つは、今まさに公開されているページをその場で取得して検査するライブテスト。もう1つは、Googleが過去にクロールして保存しているインデックス版の情報を表示する見方である。この2つを分けているのは、Googleの検索結果に実際に使われているデータが、今のページそのものではなく、最後にクロールされた時点のスナップショットだからである。

この構造は、当サイトが以前に確認した「テストが通ったことと、実際にサイトへ反映されていることは別」という論点（「リンク切れ0本」を確認して、安心しかけた）と同じ形をしている。自動化された確認は、確認できる範囲だけを保証する。ライブテストが保証しているのは「今のページを取得できるか」までであり、「その結果が検索結果に反映されているか」までは保証していない。

「クロール済みだが未登録」という、第三の状態

ページの状態は、単純に「登録済み」と「未登録」の2つに分かれるわけではない。ヘルプページには「Discovered - currently not indexed」という状態が説明されており、これはURLの存在をGoogleが発見しているが、まだインデックスに追加していない状態を指す。この状態は、ライブテストでは検出できない情報として明記されている。つまり、ライブテストで問題が無いように見えても、実際にはこの中間状態のまま止まっていることがある。

URL検査ツールには、画面操作以外の使い方もある

この記事で扱っているのは、Search Consoleの画面上でURLを1件ずつ検査する使い方である。公式にはこれとは別に、同じ検査結果をプログラムから取得できるURL Inspection APIも用意されている。多数のURLを定期的に確認したい場合、画面を1件ずつ開く代わりにAPI経由で状態を取得する運用も選択肢になるが、API自体にもリクエスト数の上限があり、画面操作の代わりに使えば制限が無くなるわけではない。

Search Console自体の不具合が、確認をさらに難しくすることもある

Search Consoleの数値そのものが常に正確とは限らない。当サイトも以前、Search Console側の表示に長期間の不具合があった事例を確認している（Google の数字は 11 ヶ月、壊れていた）。URL検査ツールの結果を1回だけ見て判断するのではなく、時間を置いて何度か確認する姿勢が必要になる。

03 この記事で出てくる用語

「インデックスキュー」という言葉が指すもの

公式ヘルプの英語表現では、リクエストの送信先を明確に「キュー（queue）」とは呼んでいないが、複数の箇所で「処理を待つ」という表現が使われており、この記事の中ではその状態を分かりやすく「インデックスキュー」と表現している。実際の内部処理の仕組みが公開されているわけではないため、先入れ先出しの単純な待ち行列であるとは限らない点には注意が必要である。

「クロール」と「インデックス」は、別の工程を指す

この記事の中で繰り返し出てくるクロールとインデックスは、しばしば同じ意味のように使われるが、公式の整理では別の工程である。クロールは、Googleのプログラムがページを取得しに来る工程を指す。インデックスは、取得した内容を解析し、検索結果に表示できる形でデータベースに登録する工程を指す。クロールされたページのすべてがインデックスされるとは限らず、「Discovered - currently not indexed」はまさに、クロールとインデックスの間で止まっている状態を表している。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どのURL、どのプロパティに使えるか

URL検査ツールが使えるのは、Search Consoleでプロパティとして所有権を確認済みのドメイン、またはURLプレフィックスに含まれるURLに限られる。所有権を確認していないドメインのURLは検査できない。また、インデックス登録のリクエストはURL単位の操作であり、複数URLをまとめて一括リクエストする機能は用意されていない。多くのページをまとめて知らせたい場合には、公式ヘルプ自身が別の方法を案内している。

"If you want many pages indexed, try submitting a sitemap."

（訳: 多くのページをインデックスさせたい場合は、サイトマップの送信を試してほしい。）

この一文は、個別リクエストとサイトマップという2つの経路の役割分担を公式が明示している数少ない箇所である。個別のURLを急いで知らせたいときはリクエスト、サイト全体の更新を継続的に知らせたいときはサイトマップ、という使い分けが前提になっている。

🅱 この記事が測っていないこと・分からないこと

公式ページには、リクエストを送った場合と送らなかった場合とで、インデックスされるまでの時間がどれだけ違うかという比較は示されていない。当サイトもこの記事の執筆にあたって、そうした比較実験は行っていない。「リクエストを送ると速くなる」という主張を、公式の記述だけから裏付けることはできない。また、1日あたりのリクエスト送信件数の上限が具体的に何件かについても、公式ページには数値の明記が無い。

リクエストを送る前に、直しておくべきこと

URL検査の結果でnoindexの指定やrobots.txtによるブロックが見つかった場合、その状態のままリクエストを送っても、Google側の判断は変わらない。原因を直さずに繰り返しリクエストを送る行為は、1日あたりの上限を消費するだけで、結果には結びつきにくい。まず原因を直し、ライブテストで解消を確認してから、あらためてリクエストを送るという順序を徹底したい。

🅲 手順 — 自分のサイトで確認する流れ

確認の流れは次のようになる。まずSearch Consoleにログインし、対象のプロパティを選択する。次に画面上部の検査バーに、確認したいページの完全なURLを貼り付ける。結果が表示されたら、Discovery（発見経路）・Crawl（クロール状況）・Indexing（Googleが選んだ正規URL）の3つの欄を確認する。ここで問題（noindexの指定・robots.txtによるブロック・重複と判定されている等）が見つかった場合は、先にその原因を直してからリクエストを送る。原因を直さずにリクエストだけを繰り返しても、同じ理由でまた保留になる可能性が高い。結果画面の右上には「ページのライブテスト」というボタンも並んでおり、修正を反映したページの状態をその場で取得し直せる。

05 明日、自分のサイトで確認できることチェックリスト

チェックリストの観点と、かかる時間の目安

ここまでの内容を、今日から手を動かせる作業に翻訳した。観点は、URL検査ツールの使い方の確認（5項目）、原因の切り分け（5項目）、複数ページへの対応（3項目）の3つに分かれる。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。

• Search Consoleで、リクエストを送りたいページのプロパティが所有権確認済みになっているか確認する
• 対象URLをURL検査ツールに貼り付け、「ライブテスト」と「インデックス登録済み」のどちらの結果を見ているかを画面上で区別する
• Indexing（インデックス）の欄で、Googleが選んだ正規URLが自分の意図したURLと一致しているか確認する
• Crawl allowed?（クロールの可否）の欄で、robots.txtによるブロックが表示されていないか確認する
• Indexing allowed?（インデックスの可否）の欄で、noindexの指定が表示されていないか確認する
• 「Discovered - currently not indexed」と表示されているURLを3件選び、共通する原因（サーバーの応答速度・重複判定など）が無いか書き出す
• 直近1週間以内にリクエストを送ったURLのうち、実際に検索結果への反映を確認できたものが何件あるか数える
• 1日あたりのリクエスト送信数が上限に達したという表示が出ていないか確認する
• 更新頻度の高いページ上位5件について、最終クロール日時が何日前になっているか書き出す
• サイト全体の更新を伝える手段として、サイトマップを最後に送信・更新したのがいつかを確認する
• 新規に10件以上のページを公開する予定がある場合、個別リクエストではなくサイトマップの更新を先に検討する
• indexnow.orgの参加プラットフォーム一覧を開き、自分が使っている検索エンジン向けの通知手段が足りているか確認する
• ここまでで見つかった問題を1件ずつ書き出し、優先度の高いものから3件を選んで今週中に直す

13項目の内訳は次のとおりである。最初の5項目はURL検査ツールの基本的な使い方、6番目から10番目までは原因の切り分け、11番目以降は複数ページへの対応に対応している。すべてに目を通す時間の目安は1ページあたり15分程度である。すでにサイトマップを定期的に更新している場合、11番目は読み飛ばしてよい。

06 代替・他の選択肢（表で）

Googleに更新を知らせる4つの手段

個別のリクエスト送信だけが、Googleに更新を知らせる手段ではない。以下は、それぞれの手段が「できること」と「できないこと・限界」を整理した表である。

4つの手段のうち、Googleに向けて確実に効くと公式が明言しているのは、サイトマップの送信だけである。URL検査でのリクエストは個別URLに限られ、IndexNowはGoogle検索には届かない。当サイトの🔧 WEBサイトのsitemap.xml作成ツールを使えば、サイトマップそのものを手早く用意できる。

表に入れなかった手段 — 「Fetch as Google」はもう無い

かつてSearch Consoleの前身にあたるツールには、「Fetch as Google」という個別ページの取得・インデックス送信機能が存在した。現在のURL検査ツールは、この機能の後継として整理されたものであり、名前も操作画面も変わっている。表に古い名称を入れなかったのは、現行の公式ページにこの名称での案内が存在しないためである。過去の記事や書籍でこの名称を見かけた場合は、現行のURL検査ツールに置き換えて読む必要がある。

サイトマップは、一度送れば終わりではない

サイトマップを送信する運用でよくある誤解の1つに、「一度Search Consoleに登録すれば、そのファイルの中身が更新されるたびに自動で伝わる」という思い込みがある。robots.txtにサイトマップの場所を記載していれば、Googleは定期的にサイトマップを再取得しに来るが、その頻度や間隔は公開されておらず、更新頻度の高いサイトほど、robots.txtへの記載に加えて、更新のたびにSearch Consoleから明示的に再送信する運用を組み合わせる方が確実である。

すぐに処理されないサイトには、共通する事情があることも

リクエストを送っても長く「Discovered - currently not indexed」のまま止まるサイトには、サーバーの応答速度やページ数の規模といった、クロールの受け入れ余力に関わる事情が共通して見られることがある。この受け入れ余力はクロールバジェットと呼ばれる考え方で、その2つの構成要素については別の記事で確認している（クロールバジェットを気にすべきサイトの条件）。個別のリクエストで発見の経路を増やしても、受け入れ側の余力そのものが不足していれば、処理が後回しになる状況は変わらない。

07 当サイトの実例

「数字」ではなく、運用の事実として確かめられること

このテーマについて、リクエスト送信の有無で反映速度を比較するような、数値としての実験はこの記事のために行っていない。そのため、ここに書けるのは測った数字ではなく、実際に続けている運用の事実である。当サイトでは記事を公開するたびに、サイトマップの更新とIndexNowへの通知を行っているが、Search ConsoleのURL検査ツールからの個別リクエストは行っていない。上の表で確認したとおり、IndexNowの通知先にGoogleは含まれていないため、Google向けに実際に効いている経路は、サイトマップの更新だけということになる。

この構成に至った背景には、以前に確認した「再クロールを待つ側になったときの体験」がある（再クロール待ち行列547件、当サイトの2週間）。個別のリクエストを積み重ねるより、サイト全体の更新を継続的にサイトマップで伝え続ける方が、運用としては続けやすいと判断している。

08 このテーマの、これまで

「Search Consoleの数字は、いつも正しいとは限らない」回

Search Console自体の表示に長期間の不具合があったことを確認した回がある（Google の数字は 11 ヶ月、壊れていた）。02章で触れた「1回だけ見て判断しない」という姿勢は、この回で確認した事例が背景にある。

「再クロールを待つ」経験を、そのまま公開した回

公式が示す「最長2週間」という再クロールの目安と、実際に待った経験を記録した回がある（再クロール待ち行列547件、当サイトの2週間）。07章で触れた運用判断は、この回の経験の延長線上にある。

「Search Consoleが教えてくれること」の基本を整理した回

Search Consoleというツール全体が何を教えてくれるのかを、基本から整理した回がある（Search Consoleが教えてくれること）。URL検査ツールは、その中の一機能という位置づけになる。データを読む力が問われるのは、URL検査ツールに限った話ではなく、Search Console全体に共通する姿勢である。

「受け入れ余力」という考え方を整理した回

クロールの受け入れ余力（クロールバジェット）を構成する2つの要素を確認した回がある（クロールバジェットを気にすべきサイトの条件）。06章で触れた「発見の経路を増やしても、受け入れ側の余力が無ければ処理は進まない」という関係は、この回で確認した内容が土台になっている。