「新しく公開したページが、いつまでもインデックスされない。Indexing API で申請すれば早まるのではないか」という相談があります。あるいは、提案書に「Indexing API を使ってインデックスを高速化します」と書かれていて、それが妥当かどうかを判断したい、という状況もあります。
API（システム連携の窓口）の名前が "Indexing" なので、インデックスを申請する窓口のように読めます。そして調べ始めると、まず出てくるのは上限と費用の情報です。1日何件まで送れるのか、有料なのか。
最初は、ここを押さえれば判断できると考えていました。上限が足りるなら使う、足りないなら別の手を考える、という順序です。
しかし公式ドキュメントを上から読むと、順序が逆でした。上限や費用の前に、適用範囲が書かれています。 そしてその範囲は、2種類のページに限定されています。範囲の外では、1日200件という上限も、無料という条件も、何も約束していません。
この記事の見立てはここです。性能（上限・費用）より先に、適用範囲を読む。 範囲の判定が付かないうちは、上限の数字は判断材料になりません。
扱わないものを先に置きます。範囲外のサイトが取れる他の手段——検索順位を上げる方法や、クロールを促す他の経路——は、この記事では扱いません。それぞれ別の公式資料に基づいて判断する必要があり、ここで裏取りなしに並べると、同じ種類の思い込みを足すことになります。
30秒で要点
- 公式クイックスタートは適用範囲を明記している。JobPosting を持つページか、VideoObject に埋め込まれた BroadcastEvent を持つページのクロールにのみ使用できる
- したがって通常の記事・サービスページ・商品ページは、最初から対象外である。公式に「インデックスが早まる」という効果の記述は無い
- 範囲内なら既定値は、publish が1日200件（URL_UPDATED と URL_DELETED の合計）、メタデータ取得が毎分180件、全エンドポイント合計が毎分380件。日次分は太平洋時間0時にリセット
- 費用は無料。ただしクォータ増枠の申請手順は、2026年10月26日時点のページに記載が無い
- 2026年10月16日の更新はページの更新であり、上限値の変更ではない。理由欄には古いフォームを削除したことが挙げられている
- 範囲外利用の帰結は公式に記述が無い。記述があるのは濫用（複数アカウントでのクォータ超過を含む）についてで、アクセス取り消しにつながる場合があるとされる
公式が書いている適用範囲は、2種類のページだけ
Indexing API のクイックスタートには、次の一文があります（2026年10月26日に取得して確認）。The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.
訳せば「Indexing API は、JobPosting を持つページか、VideoObject に埋め込まれた BroadcastEvent を持つページのクロールにのみ使用できる」です。
ここに出てくる3つの名前は、ページに埋め込む構造化データの型です。同じページは、この API の位置づけを "For websites with many short-lived pages like job postings or livestream videos"（求人情報やライブ配信動画のような、短命なページを多く持つサイト向け）と書いており、型名と実際のページ種別はこの一文で対応が付きます。
- JobPosting — 求人情報のページに付ける型
- BroadcastEvent — 配信イベントを表す型
- VideoObject — 動画を表す型で、BroadcastEvent はこの中に埋め込まれる形で使われる
想定されているのは "site owners"、つまりサイトの所有者が自分のサイトについて通知する用途です。
「のみ」（only）という語が書かれていることが、この記事の出発点です。 公式は、使える対象を列挙したのではなく、使える対象を限定しています。
そして、この一文と並んで確認しておくべきことがあります。このページには「インデックスが早まる」という効果の記述がありません。 範囲の限定はあり、効果の約束はない。提案書に「Indexing API でインデックスを高速化します」と書かれていた場合、その根拠は公式ドキュメントの外にあります。
対象かどうかを判定する手順
判定は、サイト全体ではなくページ単位です。
- そのページに JobPosting の構造化データが入っているかを確認する。求人情報ページであっても、構造化データを実装していなければ条件の形になりません
- 入っていない場合、VideoObject の中に BroadcastEvent が埋め込まれているかを確認する
- どちらでもないなら、そのページは公式が示す適用範囲の外です
3 に当たった場合、そこで止まります。上限が200件で足りるかどうかの検討は、範囲内のページについての話です。
ここで、判定が「サイト単位」になりやすい点に触れておきます。求人ページを持つサイトでも、サイト内のブログ記事や会社案内は別のページです。求人ページがあることは、同じサイトの記事ページが対象になることを意味しません。
範囲内で運用する場合の上限と費用
適用範囲に入っているなら、次に上限の設計です。クォータと料金のページには、既定値として次の3つが書かれています（2026年10月26日に取得して確認）。
表が収まらない場合は、横にスクロールできます
| 対象 | 既定値 | 補足 |
|---|---|---|
| publish リクエスト | 1日 200件 | URL_UPDATED と URL_DELETED の両方を含む |
| メタデータ取得（getMetadata） | 毎分 180件 | 読み取り専用のリクエスト |
| 全エンドポイント合計 | 毎分 380件 | 上記2つを含む合計 |
運用設計で効いてくるのは、1日200件が更新と削除の合計だという点です。更新通知だけで200件を見込んでいると、削除通知を送る分が入りません。求人情報は掲載終了が定期的に発生するため、削除の件数は無視できない規模になりえます。
リセットの挙動も書かれています。
The daily quota resets at midnight Pacific Time, which means new quota can take up to 24 hours to become effective.
日次クォータは太平洋時間の午前0時にリセットされ、新しいクォータが有効になるまで最大24時間かかりうるとされています。日本時間で設計するときは、この時差を足した時刻が切り替わり点になります。
費用については一文です。
All use of the Indexing API is available without payment.
利用は無料です。ただし、無料であることと、件数を増やせることは別です。 既定値は200件であり、そこから増やす手順について次の節で触れます。
なお、ここに挙げた3つはいずれも「既定値」です。同ページは、実際の値を Google API Console で確認するよう案内しています。設計の前に、自分のプロジェクトの表示値を見るのが順序です。
「2026年10月に上限が変わった」とは書かれていない
クォータについて調べると、2026年10月の更新履歴に行き当たります。Google 検索セントラルの更新履歴には、2026年10月16日の項目として次が掲載されています（2026年10月26日に取得して確認）。
- タイトル: "Updating the Indexing API quota page"
- 説明: "Updated the Indexing API quota page to reflect the current quota limits and process."
- 理由: 現行のクォータ上限を文書化し、古いフォーム（an outdated form）を削除するため
読み取れるのは「ページが現行の上限とプロセスを反映するよう更新された」ことです。「上限値そのものが変更された」とは書かれていません。 この2つは似ていますが、運用への影響が逆になります。前者なら設計を変える必要はなく、後者なら見直しが必要です。
そして理由欄の「古いフォームを削除した」という記述は、もう1つの事実と整合します。2026年10月26日時点のクォータ・料金ページには、増枠を申請する手順・フォーム・連絡先に相当する記述がありません。 クォータ関連のリンクは、現在の値を Google API Console で確認する案内だけです。
つまり、「増枠はどこから申請するのか」を探しても、現時点の公式ページには行き先がありません。探して見つからないのは、見落としではなく、削除されたフォームを探している可能性があります。
範囲外で使ったらどうなるのか、は書かれていない
ここは正直に書く必要があります。適用範囲の外で使った場合に何が起きるかについて、公式ドキュメントに記述がありません。 ペナルティがあるとも、無視されるだけだとも書かれていません。今回確認した3ページのいずれにも、その記述はありませんでした。
記述があるのは、別の行為についてです。クイックスタートは、API の濫用——複数アカウントを使ってクォータ上限を超えることを含む——について、アクセスが取り消される場合があると述べています。
この2つを混ぜないことが重要です。「範囲外のページに送った」と「クォータ超過のために複数アカウントを使った」は、別の行為です。 後者の帰結が書かれていることを、前者の帰結として読み替えることはできません。
実務上の結論は、記述の有無に関わらず同じになります。公式が範囲を限定していて、範囲外での効果の記述が無いなら、送っても得られるものが分からないという状態です。帰結が不明であることは、実行する理由にはなりません。
なぜ「申請窓口」だと思ってしまうのか
ここまで読んでも、名前の印象は残ります。理由は3つあります。
第一に、名前が機能を広く見せます。 "Indexing API" という名前には、求人情報と配信動画に限るという情報が入っていません。名前から範囲を推測すると、必ず広く読みます。
第二に、検索して最初に出てくるのが上限と費用の情報です。 「1日200件」「無料」という数字は具体的で、記事やまとめページで引用されやすい形をしています。一方「JobPosting か BroadcastEvent のみ」は、構造化データの型名が入るため、要約から落ちやすい。数字は運ばれ、範囲は運ばれません。
第三に、困っている状況が判断を急がせます。 インデックスされないページを前にしているとき、探しているのは「使える手段」です。使える条件を確認する作業は、手段を1つ減らす作業になります。減らす方向の情報は、求めている形の答えではありません。
この3つは、誰かが誤情報を流した結果ではなく、調べる順序から自然に生まれます。
仕様が何を約束しているかを読む、という判断軸
この構造は、Indexing API に固有のものではありません。検索に関わる仕様には、名前から推測される機能と、仕様が約束している範囲がずれているものがいくつかあります。
- canonical タグは正規URLの「指示」ではなく、Google が選ぶ際の手がかりである — canonicalタグは「指示」ではない｜Googleが正規URLを選ぶ仕組みと、設定しても無視される理由
- robots.txt はアクセス制御ではなく、クロールの制御である — robots.txt・noindex・認証の違い：公開と検索掲載を分けて守る
- sitemap の lastmod は再クロールの約束ではなく、サイト側の申告である — sitemapのlastmodは何を書く？Googleが値を使う条件と、priority・changefreqの扱い
いずれも、各記事の側で仕様を確認しています。共通しているのは読む順序です。何ができるかを先に想像せず、仕様が何に適用され、何を約束しているかを先に読む。この順序にすると、「使えるかどうか」の判定が、効果の期待より前に終わります。
SEO（検索エンジン最適化）の施策で判断を誤るのは、効果の大小を読み違えたときより、適用範囲の外で効果を期待したときのほうが多い、というのが実感です。範囲外では、効果は小さいのではなく、仕様が何も述べていません。
手元で試せる最小の確認
提案書や社内の検討メモに「Indexing API」が出てきたら、1つだけ確認してください。
「対象にするページには、JobPosting か BroadcastEvent が入っていますか」と聞く。
入っているなら、上限の設計の話に進めます。1日200件が更新と削除の合計であることを踏まえて、件数を見積もる段階です。
入っていない、あるいは「構造化データは実装していない」という答えなら、その時点で範囲の外です。次に聞くことは「では、何を根拠に高速化できると考えていますか」になります。公式ドキュメントの中には、その根拠はありません。
この確認には、API の利用登録もコードも要りません。対象ページのソースを1枚見るだけで終わります。
確かなことと、確かでないこと
確かなこと（2026年10月26日に3ページを取得して確認した範囲）：クイックスタートが適用範囲を JobPosting と VideoObject 内の BroadcastEvent に限定していること。既定値が publish 1日200件（更新と削除の合計）・メタデータ毎分180件・全エンドポイント合計毎分380件であること。日次クォータが太平洋時間0時にリセットされ、有効化に最大24時間かかりうること。利用が無料であること。クォータ・料金ページに増枠申請の手順が無いこと。2026年10月16日の更新履歴が、ページの更新と古いフォームの削除を述べていること。濫用についてアクセス取り消しの記述があること。
確かでないこと：適用範囲の外で使った場合に何が起きるかは、公式に記述がなく、今回確認できていません。「無視される」「ペナルティがある」のどちらも、裏付けを持ちません。また、既定値から増枠する方法が存在しないのか、公開された窓口が無いだけなのかも、ページの記述からは判断できません。
この記事が扱っていないこと：範囲外のサイトがインデックスについて取れる他の手段には触れていません。それぞれ別の公式資料に基づく判断が必要で、ここでは裏取りをしていないため扱いません。また、更新履歴は動きます。2026年10月26日時点でページ上の最新項目は10月23日のもので、10月16日の項目は過去の項目として掲載されている状態です。
新しい手段を検討するときに立ち返る問い
立ち返りたいのは、「この仕様は、何に適用されると書いてあるか」という問いです。何ができるかではなく、何に適用されるか。順序を変えるだけで、検討に入る前に判定が終わります。
もう1つは、「効果の記述は、公式のどこにあるか」という問いです。Indexing API の場合、適用範囲の記述はあり、効果の記述はありませんでした。効果の話が公式の外から来ているなら、その出所を確かめる必要があります。
名前は、機能を説明するために付けられたものではありません。範囲を説明するために付けられているわけでもない。範囲は、名前ではなく本文に書かれています。
参考資料・引用元
- Indexing API Quickstart（Google 検索セントラル。適用範囲・想定利用者・濫用に関する記述。2026年10月26日に取得して確認）
- Indexing API Quota and pricing（Google 検索セントラル。既定クォータ値・リセット時刻・費用。2026年10月26日に取得して確認）
- What's new in Google Search Central documentation（Google 検索セントラル。2026年10月16日「Updating the Indexing API quota page」の項目。2026年10月26日に取得して確認）