WEBサイトGoogleはIndexing APIの上限のページを10月16日に更新し、既定の上限は1つのプロジェクトあたり1日200件と書いた。使えるのは求人とライブ配信の動画のページだけ ── 自分のサイトでの使用と、対象の種類かを確認する13項目（2026年10月時点）
GoogleはIndexing APIの上限のページを10月16日に更新し、既定の上限は1つのプロジェクトあたり1日200件と書いた。使えるのは求人とライブ配信の動画のページだけ ── 自分のサイトでの使用と、対象の種類かを確認する13項目（2026年10月時点）
目次
- 01 何が起きたか — Googleは10月16日にIndexing APIの上限のページを更新し、既定の上限は1つのプロジェクトで1日200件と書いた
- 02 なぜ・背景 — Indexing APIは、短い期間で入れ替わるページのための道具である
- 03 用語 — Indexing API、通知の種類、サービスアカウント、JobPosting、BroadcastEvent、上限
- 04 型別 — 使ってよいページか、使っているか、上限に届くかを3つに分けて確かめる
- 05 自分のサイトで確認するチェックリスト
- 06 代替・他の選択肢 — 一般のページを知らせる道は、3通りある
- 07 当サイトで確かめたこと
- 08 このテーマの、これまで
- 09 この記事のまとめ
01 何が起きたか — Googleは10月16日にIndexing APIの上限のページを更新し、既定の上限は1つのプロジェクトで1日200件と書いた
2026年10月16日の更新履歴
Google検索セントラルの更新履歴に、2026年10月16日の項目が出た。題は「Updating the Indexing API quota page」（訳: Indexing APIの上限（クォータ）のページを更新する）である。書かれていることは短い。内容は「上限のページを、今の上限と手続きに合わせて更新した」、理由は次の1文だけである。2026年10月17日に、更新履歴と、更新されたページの本文を、開いて読んだ。
"To document the current quota limits for the Indexing API and remove an outdated form."
（訳: Indexing APIの、今の上限を文書にし、古くなったフォームを取り除くため。）
先に断っておく。この記事は、公式の文書に書かれていることと、書かれていないことを分けて書く。更新履歴は、何をどう変えたかの詳しい中身を書いていない。更新の前のページ本文は、この記事を書いた時点で、保存された写しを見つけられなかったので、「何が消えたか」を、本文の差で確かめることはできなかった。
更新後のページに書かれている上限
更新後の「Quota and pricing information」（訳: 上限と料金の情報）には、3つの上限と、料金が書かれている。上限はどれも、1つのプロジェクトあたりの既定の値である。表にまとめる。
| 上限の名前 | 既定の値 | 何の数か |
|---|---|---|
| 1日あたり（公開の通知） | 200件 | 1つのプロジェクトあたり、公開の通知を送る窓口への要求の数。更新（URL_UPDATED）と削除（URL_DELETED）の両方を含む。1日の上限は太平洋時間の0時に戻り、新しい上限が効くまで最大24時間かかりうる |
| 1分あたり（状態の読み取り） | 180件 | 1つのプロジェクトあたり、通知の状態を読む窓口（読み取りのみ）への要求の数 |
| 1分あたり（すべての窓口） | 380件 | 1つのプロジェクトあたり、すべての窓口の合計 |
料金については、次の1文がある。
"All use of the Indexing API is available without payment."
（訳: Indexing APIのすべての利用は、支払いなしで使える。）
書かれていないこと
注意
更新後のページの本文には、上限を増やす手続きも、申請の窓口も出てこない。更新履歴は「古くなったフォームを取り除いた」と書くだけで、取り除く前のフォームが何だったかも、これからどうすれば上限を増やせるかも書いていない。「増やせなくなった」とも、「増やせる」とも、書かれていない。この記事も、どちらも書かない。
同じ日に、「Using the Indexing API」（訳: Indexing APIを使う）と「Indexing API Quickstart」（訳: Indexing APIのクイックスタート）のページにも、最終更新が2026年10月16日と表示されている。ただし、更新履歴が挙げているのは上限のページだけで、2つのページの何が変わったかは、書かれていない。
02 なぜ・背景 — Indexing APIは、短い期間で入れ替わるページのための道具である
使えるのは、2種類のページだけ
Googleの文書は、Indexing APIを、求人の掲載ページか、ライブ配信の動画のページを、Googleの索引へ更新・削除するよう知らせるための道具と説明している。使える範囲は、1文で限られている。
"The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject."
（訳: Indexing APIは、JobPostingか、VideoObjectの中に埋め込まれたBroadcastEventのあるページを、取得させるためにだけ使える。）
つまり、ブログの記事、商品のページ、会社の案内のような一般のページは、対象に入っていない。構造化データのJobPostingは求人の掲載を、BroadcastEventはライブ配信を、表す書き方である。
短い期間で入れ替わるページに向く理由
クイックスタートの文書は、求人やライブ配信のように、短い期間しか存在しないページが多いサイトでは、Indexing APIが検索結果の中身を新しく保つのに役立つ、と説明している。ページを1つずつ、個別に押して知らせられるからである。求人の文書も、求人のURLについては、サイトマップより先にGooglebotに取得を促せるので、Indexing APIを使うことを勧める、と書いている。ただし、サイト全体のためには、サイトマップの提出も引き続き勧めている。
2024年の更新履歴に書かれていたこと
Indexing APIの上限と使い方は、過去にも更新履歴に出ている。2024年9月4日の項目は、既定の上限は初期設定とテストのためのもので、使うには追加の承認が要ると書いた。2024年9月11日の項目は、Indexing APIへの送信にはスパムの検出が掛かること、上限を超えようとすると、アクセスが取り消されることがあると書いた。
"To better explain that the default quota is for initial setup and testing, and it requires additional approval for usage and resource provisioning."
（訳: 既定の上限が、初期設定とテストのためのもので、使うことと資源の用意には、追加の承認が必要だと、よりよく説明するため。）
2026年10月16日に更新された上限のページの本文には、この「追加の承認」という言い方は、見当たらない。なぜ消えたかは、書かれていない。昔の説明が、今も有効かどうかは、この記事では分からない。
一般のページは、別の道がある
一般のページを、Googleに知らせる道は、サイトマップと、Search ConsoleのURL検査の依頼である。Googleの文書は、数が多いときはサイトマップ、個別のURLにはURL検査、と分けている。URL検査の依頼は、Search ConsoleのURL検査「インデックス登録をリクエスト」は何をしているのか ── 公式の言葉で確認する13項目（2026年9月時点）に書いた。サイトマップの各項目の読み方は、サイトマップのpriorityとchangefreqはGoogleに使われず、lastmodは正確なときだけ使われる ── 自社のサイトマップの各項目を確認する14項目（2026年10月時点）に書いた。
03 用語 — Indexing API、通知の種類、サービスアカウント、JobPosting、BroadcastEvent、上限
Indexing APIと通知の種類
用語
Indexing APIは、サイトの持ち主が、ページが追加された、更新された、消えたことを、Googleに直接知らせるための仕組みである。知らせる内容は、URL_UPDATED（新しい、または更新した）と、URL_DELETED（消した）の2つで、状態を読む操作もある。
サービスアカウントと所有者の委任
Indexing APIは、人のログインではなく、サービスアカウントという、プログラム用のアカウントで呼ぶ。文書は、このアカウントのメールアドレスを、Search Consoleで、サイトの（委任された）所有者として追加する手順を求めている。つまり、使っているサイトの所有者の一覧に、サービスアカウントのメールが入っている。
JobPostingとBroadcastEvent
JobPostingは、求人の掲載を表す構造化データで、BroadcastEventは、ライブ配信の動画を表す構造化データである。後者は、動画のページで、VideoObjectの中に書く形で使う。Googleの動画の文書は、BroadcastEventを書くと「LIVE」の表示が付く場合があり、そのときはIndexing APIを使って、Googleが適切な時に取得するようにする、と書いている。
上限（クォータ）と、太平洋時間
用語
上限（クォータ）は、一定の期間に送れる要求の数である。Indexing APIの1日の上限は、日本の時刻ではなく、太平洋時間の0時で区切られる。日本の時刻に直すと、米国の夏時間の期間は午後4時、それ以外の期間は午後5時になる。この日本時間への直し方は、上限のページには書かれておらず、この記事の計算である。
04 型別 — 使ってよいページか、使っているか、上限に届くかを3つに分けて確かめる
A. この記事が当てはまるサイト
当てはまるのは、求人の掲載ページか、ライブ配信の動画のページを持つサイトである。もう1つは、サイトのどこかが、Indexing APIを使って、一般のページを知らせているかもしれないサイトである。後者は、CMSのプラグインや、外部の制作会社が入れた仕組みが、持ち主の知らないところで呼んでいることがある。
B. 公式が書いていないこと
書かれていないのは、上限を増やす方法、増やせるサイトの条件、上限を超えたときの扱いの詳細、一般のページに使ったときに何が起きるか、である。一般のページに使うと、どうなるかは、文書に書かれていないので、この記事も「止められる」「罰せられる」などとは書かない。書かれているのは、対象の種類が限られていることと、スパムの規則が当てはまること、複数のアカウントで上限を回避しないこと、である。
C-1. 対象の種類か、通知の前に確かめる
通知を送る前の確認は、2つである。1つ目は、ページが求人の掲載か、ライブ配信の動画かである。2つ目は、構造化データを実際に書いているかである。判断の順番を、図にした。
C-2. 3つの通知の、条件と意味
Indexing APIの通知には、3つの種類がある。条件と、200が返ったときの意味を、表にまとめた。
| 操作 | 送る前の条件 | 200が返ったときの意味 |
|---|---|---|
| 更新（URL_UPDATED） | 新しいページか、中身を変えたページ。1回の要求に1つのURL。まとめるときは最大100件 | Googleが、このURLをまもなく取得しようとする「かもしれない」 |
| 削除（URL_DELETED） | URLが404か410を返す、またはページにnoindexのmetaタグがある | Googleが、このURLを索引から外す「かもしれない」 |
| 状態の取得 | URLをURLエンコードして指定する | 最後に通知を受けた時刻が分かる。索引に入った時刻や外した時刻は分からない |
"The GET request doesn't tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request."
（訳: GETの要求は、Googleがいつ索引に入れた、または外したかは教えてくれない。要求をうまく送れたかだけを返す。）
表で大事なのは、200は「受け取った」であって、「索引に入った」ではない点である。Googleの別の文書も、取得を依頼しても、検索結果に入ることは、すぐにも、まったくも、保証されないと書く。
実務のヒント
1日200件は、更新と削除の合計である。まとめて100件送っても、数は100件ぶん減る。文書も、1つの要求にまとめても、上限は1件ずつ数える、と書く。1日の通知の数は、必ず日ごとに書き出しておく。
C-3. 使っているかを探す3か所
自分のサイトでIndexing APIを使っているかは、持ち主が覚えていないことがある。探す場所は3つある。1つはサイトの側で、コードや設定、予約実行の一覧に、呼び出し先の文字列（indexing.googleapis.com）があるかを調べる。2つ目はSearch Consoleで、プロパティの所有者の一覧に、サービスアカウントのメールが入っているかを見る。3つ目はGoogle API Consoleで、Indexing APIが有効なプロジェクトがあるかを見る。
3つとも無いことは、「自分の管理下では使っていない」という意味までである。制作会社や、別のアカウントが、別のプロジェクトから呼んでいる場合は、場所1と場所3には出ない。場所2は、持ち主が追加した所有者だけが出るので、ここに知らないメールがないかを見ることが、いちばん手堅い確認になる。
C-4. 上限と、エラーの読み方
Indexing APIが返すエラーの文書には、上限に関するものが並んでいる。1日の上限に達したときは「dailyLimitExceeded」（訳: 1日の上限を超えた）、一定の時間に要求が多すぎるときは、429の「rateLimitExceeded」（訳: 上限を超えた）が返る。上限の数字は、Google API Consoleで確かめる。数字は、自分のプロジェクトの画面が正である。
通知の送り先のページが、削除の条件を満たしていないときの、サイトの側の確かめ方は、404や410を返すか、noindexが付くかである。404と410の扱いは、Googleの文書では、どちらも「内容が無い」と扱う。ステータスを返す側の確認は、🔧 WEBサイト内のリンク漏れ・チェックツールで、リンク先のアクセスステータスを、まとめて一覧にできる。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目5から7は、Search ConsoleとGoogle API Consoleの画面を開く。使っていないサイトも、項目1・3・5・6で、「使っていない」と書ける。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 自分のサイトで、求人（JobPosting）か、ライブ配信の動画（VideoObjectの中のBroadcastEvent）の構造化データを書いたページが何種類あるか、ソースを開いて数えて書く
- 項目1が0のときは、「対象のページは無い」と日付つきで書き、項目4・7・8・9・10・12を飛ばすと書く
- サイトのコード、設定ファイル、予約実行の一覧、プラグインの一覧で、indexing.googleapis.comを検索し、見つかった場所と件数を書く
- 使っているCMSやプラグインの設定画面を開き、Googleへの通知（Indexing API）の項目があるかを、「ある」「ない」で書く
- Search Consoleでプロパティの所有者の一覧を開き、gserviceaccount.comで終わるメールの数と、全員の名前を書く
- Google API Consoleでプロジェクトの一覧を開き、Indexing APIが有効なプロジェクトの数を書く
- 項目6のプロジェクトで、Indexing APIの割り当ての画面を開き、1日の公開の通知の上限の数字と、直近の使用数を書く
- 直近の送信の記録から、通知したURLを10件選び、1件ずつ、求人かライブ配信の動画のページかを「対象」「対象外」で書く
- 項目8で「対象外」があるときは、そのページの種類と、通知を止めるか、サイトマップやURL検査の依頼に替えるかを書く
- 直近7日の通知の件数を、更新と削除を合わせて日ごとに書き、200件に対する割合を添える
- サイトマップを開き、先頭から10件のURLのlastmodの有無を数えて書く
- 求人やライブ配信の動画のページがあるときは、掲載が終わった3ページを開き、404か410が返るか、noindexが付くかを書く
- 項目1から12の結果を、「使っているか」「対象か」「上限」の3列の表にまとめ、日付をつけて保存する
時間が限られているときは、項目1・3・5・6の4つだけでも、対象の種類を持つか、自分の管理下で使っているかの見当は付く。
06 代替・他の選択肢 — 一般のページを知らせる道は、3通りある
対象の種類でないページを、Googleに知らせるなら、Indexing APIでなく、次の道がある。どれも、「すぐ載る」ことは保証されない。
サイトマップを出す
数が多いページを、まとめて知らせる方法である。Googleは、サイトマップ全体を読み込み、lastmodが前回の取得より新しいページを、取得し直す、と求人の文書に書いている。lastmodは、正確なときだけ使われる。サイトマップの上限や、分割の考え方は、サイトマップには「50,000 URL・50MB」という上限がある ── 分割とインデックス化を確認する13項目（2026年9月時点）に書いた。
URL検査で個別に依頼する
URLを1つずつ、Search Consoleの画面から依頼する方法である。Googleの文書は、プロパティの所有者か、フルユーザーでないと、依頼できないと書く。個別のURLの依頼には上限があり、同じURLに何度も依頼しても、早く取得されるわけではない。
"Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all."
（訳: 取得を依頼しても、検索結果に入ることが、すぐに、あるいは、まったく、起きるとは限らない。）
IndexNowを使う
IndexNowは、サイトの持ち主が、ページの追加・更新・削除を、検索エンジンへ知らせる仕組みである。公式のページは、Microsoft Bing、Naver、Seznam.cz、Yandex、Yepが対応していると書く。Googleは、そのページの一覧に出ていない。IndexNowで送った内容が、Googleの索引にどう扱われるかは、この記事では確かめていない。Indexing APIの代わりに、IndexNowを使えるかを考えるときは、送る先の検索エンジンが違うことを、先に押さえる。
待つ
Googleの文書は、取得には数日から数週間かかることがある、と書く。急ぐページが、対象の種類でないときは、サイトマップを正確に保ち、内部リンクを整えて、待つ、という選び方もある。
実務のヒント
一般のページにIndexing APIを使えると書いた古い解説や、プラグインの説明を見たときは、公式の文書の日付と、書かれている種類を、先に開いて確かめる。本文が「求人とライブ配信の動画のページ」と書いていれば、その範囲で使う。
07 当サイトで確かめたこと
当サイト（WEBサイトサポート）で、この記事の項目1と項目3にあたる確認を、2026年10月17日に行った。確かめたのは、公開されているページの内容と、サイトマップに載っているURLである。
対象の種類のページがあるか
当サイトのサイトマップには、387のURLが載っている。そこから無作為に40ページを選び、ページのソースを開いて、JobPostingとBroadcastEventの文字列を探した。見つかったページは0件だった。当サイトは、求人の掲載ページも、ライブ配信の動画のページも、持っていない。
当サイトの知らせ方
当サイトは、Indexing APIを使っていない。新しい記事を公開したときは、サイトマップを更新し、Search Consoleでは、人が画面からURL検査の依頼を送っている。あわせて、IndexNowで、対応する検索エンジンに知らせている。この3つは、すべて「対象の種類でないページを知らせる道」にあたる。
確かめていないこと
40ページの無作為の選び方は、サイト全体の387ページを調べたものではない。サーバーの内側を探して、Indexing APIの呼び出しの文字列が1つもないことまでは、この記事では書かない。当サイトに、求人かライブ配信の動画のページが加わるときは、この記事の項目1から確かめ直す。
08 このテーマの、これまで
| 日付 | できごと |
|---|---|
| 2020年5月1日 | 更新履歴に、Indexing APIでURLを消すとき、noindexのmetaタグを選べると加えた、という項目が出た |
| 2024年9月4日 | 更新履歴に、既定の上限は初期設定とテストのためのもので、使うには追加の承認が要ると明確にした、という項目が出た |
| 2024年9月11日 | 更新履歴に、Indexing APIへの送信にスパムの検出が掛かると明確にした、という項目が出た |
| 2026年10月16日 | Indexing APIの上限のページが、今の上限と手続きに合わせて更新され、古くなったフォームが取り除かれた。既定の上限は1つのプロジェクトあたり1日200件と書かれている |
| 2026年10月17日 | この記事の確認の日。更新履歴と、更新後のページの本文を読み、当サイトのサイトマップから40ページを選んで確かめた |
この表の2020年・2024年の項目は、Googleの更新履歴の記述を要約したもので、当時のページの本文は、この記事では確かめていない。サイトを知らせる仕組みは、当サイトのブログでも、以前に扱った。
- sitemap に書いた URL が Google から見えていなかった日 — 末尾スラッシュの落とし穴と1分検証
- Google が求める 4 層整合性 — sitemap・canonical・内部リンク・末尾スラッシュを curl 3 行で揃える
- 出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴
- Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日
- Search Consoleに「検索の生成AI」の設定が加わった ── 当サイトの画面を開いたら、自分の値は無く、親のドメインから受け継いでいた
現在の貴方のIPアドレス
このサイトで書いている人
