サーチコンソールでインデックス登録をリクエストできる上限回数は1日何件か

UPDATED

2026.09.11

読了

14 min

サーチコンソールでインデックス登録をリクエストできる回数には、1日あたりおよそ10件前後という実質的な上限があります。この上限を超えると「割り当て量を超えています」というエラーが表示され、通常は24時間程度で解除されます。Googleは具体的な数値を公表していませんが、多くのサイト運営者が経験している範囲では10件から12件程度でエラーが出始めるケースが目立ちます。新しく公開した記事を早くGoogleに見つけてもらいたいとき、この機能を使う場面は多いはずです。ですが、上限や仕組みを知らずに使うと、肝心なときにリクエストできなくなってしまいます。この記事では、上限の実態、割り当て量を超えたときの対処、リセットのタイミング、上限に達したあとに使える代替手段までをまとめました。

インデックス登録をリクエストの1日の上限は10件前後

Googleサーチコンソールの「URL検査」ツールには、任意のページについてクロールとインデックス登録を優先的に依頼できる「インデックス登録をリクエスト」というボタンがあります。以前は「Fetch as Google」という名前の機能でしたが、現在はURL検査ツールに統合されています。

この機能を使える回数には上限があり、Googleは具体的な数値を公式に発表していません。ただ、実際に運用しているサイト運営者の報告を見る限り、1つのプロパティにつき1日あたり10件から12件程度でエラーが出始めるケースが目立ちます。15件から20件程度まで通ったという声もあり、上限はアカウントの利用履歴やサイトの規模、直近のクロール状況によって変わると見られます。

海外のSEO担当者が検証した事例では、わずか5件のリクエストで「割り当て量を超えています」というエラーが出たという報告もありました。上限は固定された数字ではなく、サイトの状態によって大きく上下する変動的な割り当て量だと捉えたほうが実態に近いでしょう。

割り当て量はプロパティごとに個別に管理されます

複数のサイトを運営している場合、割り当て量はサイト単位、つまりプロパティごとに個別に管理されています。あるサイトで上限に達しても、別のドメインで運用している別サイトには影響しません。1つのGoogleアカウントに登録できるプロパティ数は最大1000個までとされており、多数のサイトを横断して管理したい場合は「プロパティセット」という機能で表示回数やクリック数をまとめて集計できます。ただしこれはあくまで計測データを集計する機能で、インデックス登録リクエストの割り当て量そのものを融通できるわけではありません。

「割り当て量を超えています」というエラーの原因

このエラーは、URL検査ツールの「インデックス登録をリクエスト」機能を短時間に使いすぎたときに表示されます。同じ日に大量のURLへ立て続けにリクエストを送った場合のほか、インデックス登録のリクエストをしていなくても、URL検査そのものを短時間に何度も繰り返すだけで頻度制限にかかることがあります。

サイト全体のクロールバジェット(Googleがクロールに割く負荷の総量)が少ない小規模なサイトで大量のリクエストを送った場合や、過去に不自然な使い方をした履歴があって割り当て量が通常より厳しく設定されている場合も、エラーが出やすくなります。

表示される文言は「割り当て量を超えています。このリクエストを処理できませんでした。また明日試してください。」という内容です。英語版のサーチコンソールでは「Quota Exceeded」という表示になります。

上限のリセットは24時間程度が目安です

上限は1日単位でリセットされますが、日本時間の午前0時にきっちり切り替わるわけではありません。Googleのクォータ管理は暦日ではなく、直近24時間のローリングウィンドウで動いている可能性が高いとみられています。

そのため、エラーが出てから数時間から半日ほどで再びリクエストできるようになることもあれば、丸1日近く待たないと解消しないこともあります。確実性を求めるなら、エラーが出てから25時間以上経過してから試すのが安全な目安です。

なお、この制限はサーチコンソール上の操作回数の制限であり、検索エンジンによるサイト全体の評価やクロール頻度を直接下げるものではありません。「割り当て量を超えています」と表示されても検索順位やサイトの評価が下がることはないので、過度に心配する必要はないでしょう。

上限に達した場合はサイトマップと内部リンクが代替手段になります

インデックス登録のリクエストが上限に達しても、Googleにページの存在を伝える方法は他にもあります。

まず有効なのがサイトマップの送信です。サーチコンソールの「サイトマップ」メニューからXML形式のサイトマップを送信しておくと、Googleはサイト内のURL一覧を把握しやすくなります。URL検査による個別リクエストが直接的で即時的な依頼であるのに対し、サイトマップの送信はサイト構造を間接的に案内するものです。サイトマップは何度でも再送信できるため、個別URLのリクエスト上限に達した場合でも、更新して再送信すれば新しいページの存在を伝えられます。

内部リンクの整備も効果があります。Googleのクローラーはリンクをたどってページを発見するため、アクセスの多いトップページや人気記事から新しいページへリンクを設置すると、発見される経路が増えます。即効性ではURL検査によるリクエストに劣りますが、サイト全体のクロール効率を高める土台になります。

他サイトからの被リンクも発見経路になります。SNSでの発信やプレスリリース、関連サイトへの寄稿を通じて外部リンクを増やすことも、間接的にインデックスを促す手段です。

WordPressを使っている場合は、Rank MathやYoast SEOといったプラグインが役立ちます。新規投稿時に自動でGoogleへ通知を送る機能や、後述するIndexing APIと連携する機能を備えたプラグインもあり、手動リクエストに頼らず公開と同時に通知を自動化できます。

robots.txtへのサイトマップ記載とサイト速度の改善も効きます

XMLサイトマップはサーチコンソールに送信するだけでなく、robots.txtにもサイトマップのURLを明記しておくと、Googlebot以外のクローラーにも発見されやすくなります。表示速度が極端に遅いページはクロールの効率が落ち、クロールバジェットを無駄に消費する原因になるため、速度の改善も間接的なインデックス促進につながります。加えて、SNSでの発信やソーシャルブックマークサービスへの登録で外部からのアクセス経路を増やすことも、Googleがページを発見する機会を増やします。何より効果があるのは、コンテンツを一定のペースで継続的に公開し続けることです。定期的に更新されているサイトはクローラーの巡回頻度自体が上がっていく傾向があり、新しいページも自然に見つかりやすくなっていきます。

Indexing APIの対象は求人情報とライブ配信動画に限られます

上限に頭を悩ませていると、代替策として「Indexing API」という言葉を目にすることがあります。ただし、この2つは仕組みも対象も別物です。

Google公式のIndexing APIは、本来「求人情報(JobPostingの構造化データを含むページ)」と「ライブ配信動画(BroadcastEventの構造化データを含むページ)」の2種類のコンテンツに限定して提供されています。プログラムからリクエストを送ることで対象ページの追加・更新・削除をGoogleへ通知できる仕組みで、Google Cloud Platformでプロジェクトを作成し、サービスアカウントを発行して利用します。

デフォルトのクォータは1日あたり200リクエストです。これを超える利用が必要な場合はGoogleに割り当て量の引き上げを申請できますが、反映までに2〜3週間ほどかかり、承認されたかどうかの明確な通知は来ません。実際にAPIを叩いて確認する必要があります。

通常のブログ記事への転用はグレーゾーンです

一部のSEO担当者や開発者の間では、求人情報やライブ配信以外の通常のブログ記事にもIndexing APIを転用する手法が広まっています。ただしこれはGoogleが公式に想定している用途の範囲外です。効果があったという報告がある一方、Googleの利用規約上はグレーゾーンの使い方であり、将来的に制限やペナルティの対象になる可能性がないとは言い切れません。記事単位のインデックスを急ぎたいだけであれば、通常のURL検査によるリクエストとサイトマップの送信、内部リンクの整備を優先したほうが安全です。

インデックス登録をリクエストしても反映されない原因はnoindexやcanonicalの設定です

上限とは別に、リクエストしたのに一向にインデックスされないというケースもよくあります。この場合はリクエストの回数以前に、ページ自体にインデックスを妨げる要因がないかを確認する必要があります。

ページにnoindexタグが設定されている場合や、robots.txtでクローラーのアクセスがブロックされている場合は、そもそもインデックスの対象になりません。別のURLを正としてcanonicalタグが指定されていて、Google側が別ページを優先して判断しているケースもあります。コンテンツの内容が薄い、既存ページと内容が重複していると判断された場合は、「登録済みだが除外」というステータスになることがあります。

サイト全体の評価やクロールバジェットが少なく優先度が低いと判断されている場合や、サーバーエラー・表示速度の問題でクロールが正常に完了していない場合も、インデックスされない原因になります。JavaScriptで動的に生成されているコンテンツは、クロール直後の時点ではGoogle側がレンダリングまで完了できておらず、内容を正しく読み取れていないこともあります。

URL検査ツールの結果画面には、こうした除外理由がある程度表示されます。リクエストを送る前に、まず現在のステータスを確認しておくことが大切です。

インデックス登録をリクエストする手順は3ステップです

実際の操作はそれほど複雑ではありません。まずサーチコンソールにログインし、対象のプロパティを選びます。左側メニューの「URL検査」をクリックし、画面上部の検索窓に確認したいページの完全なURL(https://から始まるもの)を貼り付けてEnterキーを押すと、数秒から数十秒ほどでGoogleが現在把握している情報を取得し、登録状況が表示されます。

まだインデックスされていない場合や、内容を更新して再クロールしてほしい場合は、画面右上あたりの「インデックス登録をリクエスト」というボタンをクリックします。Googleが該当URLをリアルタイムでテストし、問題がなければ「インデックス登録をリクエスト済み」というメッセージとともにリクエストがキューに追加されます。この一連の流れのなかで、URL検査そのものとインデックス登録のリクエストの両方が、1日あたりの割り当て量を消費する対象になっている点には注意が必要です。

「リクエストしたインデックス登録が完了しました」という表示は、あくまでGoogleへリクエストが正常に送信され、処理キューに入ったことを意味しています。実際にGoogleがページを再クロールしてインデックスへ反映するまでには、早ければ数分から数時間、通常でも1日程度、場合によっては1〜2週間ほどかかります。リクエスト直後にもう一度URL検査を行ってもすぐには結果が反映されないため、最低でも半日から1日程度は間隔を空けてから状況を確認したほうがよいでしょう。

「クロール済み-インデックス未登録」は品質判断の結果です

URL検査ツールやページインデックス登録レポートでは、上限とは別のステータスが表示されることもあります。代表的なのが「クロール済み-インデックス未登録」です。これはGoogleがページを実際にクロールしたものの、インデックスに登録しないと判断した状態を指します。

この状態になる要因としては、Googleの品質に関するガイドラインに照らして検索結果に表示する価値が低いと判断されている場合や、既存の他ページと内容が似通っている「カニバリゼーション」の状態にある場合、E-E-A-T(経験・専門性・権威性・信頼性)の観点で情報の裏付けが弱いと見なされている場合が挙げられます。サイト内に類似テーマ・類似構成のページが複数あると、Googleの評価が分散してどのページを優先すべきか判断がつかず、未登録のまま据え置かれるケースが増えています。

品質ガイドライン違反(不自然な被リンク、キーワードの乱用、自動生成された低品質なコンテンツ、隠しテキストなど)が明確に検出されている場合は、「手動による対策」としてサーチコンソール上に警告が表示されます。この場合は該当箇所を修正したうえで、「手動による対策」レポートから再審査をリクエストする必要があり、通常のインデックス登録のリクエストとは別の対応が求められます。

公開して間もないサイトやページは、Googleがまだ発見・巡回できていないだけというケースも多いので、数日程度様子を見るか、緊急性の高いページに限ってリクエストするという使い分けが現実的です。

上限を超えないための優先順位のつけ方

上限が限られている以上、すべてのページへ闇雲にリクエストを送るのではなく、優先順位をつけて使うことが重要です。

リクエストを送るべきなのは、公開したばかりで発見経路が少ない新規ページや、大幅にリライトして内容を大きく更新したページです。日々自動的にクロールされる主要ページや更新頻度の高いトップページは、リクエストを送らなくても自然にクロールされる可能性が高いといえます。

複数ページを一度に公開した場合は、すべてのURLに同時に手動リクエストを送るのではなく、まずサイトマップを更新・送信し、特に優先度の高い数ページだけを手動でリクエストするという使い分けが有効です。こうすることで、上限に達するリスクを抑えながら効率よく運用できます。

リクエストを送った後にすぐ効果を判断せず、数日から1週間程度の猶予を持って結果を確認する姿勢も欠かせません。インデックス登録のリクエストはあくまで優先度を上げる依頼であり、即時にインデックスされることを保証するものではないため、焦って同じURLに何度もリクエストを繰り返すと、かえって割り当て量を無駄に消費することになります。

品質評価ガイドラインへの抵触や、不正な被リンクの購入、大量に自動生成した低品質なコンテンツといった問題を抱えたままリクエストを繰り返しても、Googleがスパムと判断すればインデックスされない状態は変わりません。上限のやりくりより先に、ページそのものの品質とガイドライン遵守を優先する必要があります。

ボタンが反応しない場合はGoogle側の一時的な不具合の可能性があります

割り当て量とは別に、「インデックス登録をリクエスト」のボタン自体がグレーアウトしていたり、クリックしても「ページの操作が一時的に無効になっています」というメッセージが出て先に進めなかったりすることがあります。これは1日の割り当て量とは異なる原因で発生することが多く、Google側の一時的な技術的トラブルであるケースが少なくありません。この場合、利用者側でできることは限られているため、時間を置いて再度アクセスするか、サイトマップの送信やページ品質の改善など他の手段でクロールを促しながら復旧を待つのが現実的な対応です。

サーバー設定やアクセス制御が原因で、そもそもGooglebotからのアクセスが正しく処理できていない場合にも、同様に登録リクエストが正常に機能しないことがあります。海外のIPアドレスからのアクセスを一律で制限しているサーバー設定になっていないか、HTTPステータスコードが正しく200番台を返しているかといった技術的な点も確認しておくとよいでしょう。

「ページ」レポートで除外理由を一括確認できます

個別のURLを1件ずつURL検査ツールで調べるのは手間がかかります。サイト全体でどのページがインデックスされていないのかをまとめて把握したい場合は、左側メニューの「インデックス作成」内にある「ページ」レポートが役立ちます。このレポートでは「登録済み」ページと「登録されていない」ページの件数が一覧表示され、画面下部に「ページがインデックスに登録されなかった理由」ごとの内訳が表示されます。それぞれの理由をクリックすると、該当する具体的なURLの一覧を確認できます。

このレポートでは、問題の深刻度に応じて「エラー」と「警告」という区分で表示されることがあります。おおまかな違いは次のとおりです。

まとめて状況を把握したうえで、影響の大きいページから優先的にリクエストや原因の修正を行うと、限られた1日の割り当て量を無駄なく活用できます。

2025年6月には、Search Console Insightsの新バージョンがサーチコンソールのメイン画面に統合されました。パフォーマンスレポートやインデックスカバレッジの状況をより直感的に把握できるようになり、上昇・下降しているページや検索クエリの変化を確認しながら、優先的にリクエストすべきページを見極めるという使い方もできます。

まとめ:上限は約10件、リセットは24時間が目安です

サーチコンソールの「インデックス登録をリクエスト」機能には、公式な数値こそ公表されていないものの、実質的に1日あたり10件前後を目安とした上限があります。上限を超えると「割り当て量を超えています」というエラーが表示され、目安として24時間程度でリセットされます。この制限自体はサイトの検索評価に直接悪影響を与えるものではないため、過度に恐れる必要はありません。

上限に達してしまった場合は、サイトマップの送信、内部リンクや外部リンクの整備、CMSのプラグインによる自動通知など、手動リクエスト以外の手段を組み合わせるとよいでしょう。求人情報やライブ配信に限定されたIndexing APIをブログ記事に転用する手法もありますが、公式の想定用途とは異なるグレーゾーンの利用であることを理解したうえで検討する必要があります。

そもそもインデックスに登録されていないページは、どれだけ良いコンテンツを書いていても検索結果に一切表示されません。リクエストの回数そのものにこだわるより、noindexやrobots.txt、canonicalタグの設定に問題がないか、コンテンツの質やサイト全体の評価が十分かといった、インデックスされるための土台を整えることが、長期的にはもっとも確実な対策だといえるでしょう。