GoogleのIndexing API

TL;DR — Google Indexing APIは、画面上のボタンを押す代わりに、コードからGoogleへ 「このページが変わったので再クロールしてください」と通知する仕組みです。ただし、多くの解説が 省いている重要な制限があります。Googleが公式にサポートするのは、求人情報ページと ライブ配信ページだけです。ブログ記事や商品ページを早くインデックス登録させる近道ではなく、 Googleも繰り返しそう説明しています。

Indexing APIとは何か

ページを公開または更新すると、通常はGoogleが独自の予定で戻ってきて再クロールするのを待ちます。 Indexing APIでは、代わりにGoogleへ「このURLは新規または更新済みです」あるいは 「このURLはなくなったので削除してください」と通知をプッシュできます。ダッシュボードを 操作するのではなく、Googleのサーバーを呼び出す小さなプログラムから実行します。

強力な仕組みですが、それは設計対象の用途に正しく使った場合に限ります。

理解しておくべき1つのこと

GoogleがIndexing APIで公式にサポートするページは、次の2種類だけです。

1. 求人情報 — JobPosting構造化データを持つページ。求人は期限切れになるため、速やかに削除する必要があります。
2. ライブ配信 — BroadcastEvent構造化データを持つページ。ライブ動画のイベントは配信中にだけ意味を持ちます。

対象はこの2種類だけです。どちらも短期間で古くなる時間依存コンテンツなので、Googleは高速な通知経路を用意しました。

求人情報やライブ配信を扱わないなら、Indexing APIは使うべきツールではありません。 「数時間でインデックス登録」とうたうプラグインやSaaSが何を主張していても同じです。

無視すべき神話

オンラインで最も大きな誤解は、“Use the Indexing API to get any page indexed fast.” (翻訳) 「Indexing APIを使えば、どのページでもすぐにインデックス登録できる」というものです。 実際はそうではなく、Googleは通常ページへの利用を繰り返し誤用と位置付けています。成長施策として 販売するツールがあるため使われ続けていますが、Googleは悪用時にアクセスを取り消す可能性があると明記しています。

もう1つの落とし穴は、URL送信後の「成功」レスポンスです。これはGoogleがリクエストを受け取った ことだけを意味し、ページがインデックス登録されたことを意味しません。両者を曖昧にするツールは ありますが、Googleの公式文書は明確に区別しています。

より速いインデックス登録のために代わりにすること

通常ページ（ブログ、商品、記事）に実際に効く方法は地味ですが、確かなものです。

• Google Search ConsoleでXMLサイトマップを送信する。
• サイト内の既存ページから新しいページへ内部リンクを設置する。
• 薄い穴埋めではなく、ページを本当にインデックス登録する価値のある品質にする。
• 単発の対応では、Search ConsoleのURL検査にある**「インデックス登録をリクエスト」**を控えめに使う。

設定方法、実際のAPIメソッド、クォータ、Googleの正確な引用は、Advancedタブで確認できます。

TL;DR — Indexing APIは、Google Cloudで認証するREST API（v3）で、 URL_UPDATEDとURL_DELETEDの通知を受け付けます。Googleが公式にサポートするのは、 JobPostingとBroadcastEvent（VideoObject内のライブ配信）ページだけで、 一般コンテンツは対象外です。ステータスエンドポイントの200は受信確認であり、 インデックス登録の確認ではありません。Googleの姿勢は年々明確になっています。2022年の 「意味がない」から、2024年9月の文書へのスパム警告追加、2025年5月のMuellerによる 「スパマーが誤用している。適切に使うか、使わないでほしい」という警告へ進みました。 クォータを増やすための複数アカウント利用などの誤用では、アクセスを取り消される可能性があります。 一般ページにはサイトマップ、内部リンク、品質、必要時のGSC「インデックス登録をリクエスト」を使います。 なお、GoogleはIndexNowをサポートしていません。

Indexing APIの実態

Indexing APIはプログラムから使うプッシュ経路です。Google Cloudのサービスアカウントで認証する REST API（v3）を呼び出し、URLが追加・更新された（URL_UPDATED）、または削除すべき （URL_DELETED）とGoogleへ伝えます。サイトマップやSearch Consoleと並ぶURLの検出・更新手段ですが、 対象コンテンツの範囲は最も狭いものです。

私の検索の仕組みのスライド では、 Indexing APIをURL検出元として挙げつつ、**「用途が限定される」**と注記しています。この2語が全体像です。 実在し、機能しますが、正式に認められるのはウェブのごく一部に限られます。

Googleが公式にサポートしている用途

ここが最重要なので、Googleの表現をそのまま示します。Indexing APIは “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (翻訳) 「JobPostingまたはVideoObjectに埋め込まれたBroadcastEventを持つページの クロールにのみ使用できます」。対象はこの2種類の構造化データだけです。

• JobPosting — 求人情報ページ。期限切れの求人は利用者体験を損なうため、適時の追加と削除が重要です。
• BroadcastEvent（VideoObject内） — ライブ配信イベントのページ。配信中とその前後にだけ関連性があります。

なぜこの2種類だけなのか。どちらも本質的に時間依存で短命だからです。変更をすばやく通知する価値が、 通常のクロールで十分な常設ページよりはるかに高いというのがGoogleの説明です。

仕組み

前提条件

設定は簡単ではなく、ワンクリック機能ではありません。

• Indexing APIを有効にしたGoogle Cloudプロジェクト。Googleは*“need to tell Google about your client and activate access to the API.”* (翻訳) 「クライアントについてGoogleへ伝え、APIへのアクセスを有効にする必要がある」と説明しています。
• JSONキーファイルを持つサービスアカウント。キーは安全に保管します。
• サイトのSearch Console確認を済ませ、サービスアカウントを委任されたサイト所有者として追加します。
• OAuth: “Every call to the Indexing API must be authenticated with an OAuth token that you get in exchange for your private key,” (翻訳) 「Indexing APIへのすべての呼び出しは、秘密鍵と引き換えに取得するOAuthトークンで認証する必要がある」。スコープはhttps://www.googleapis.com/auth/indexingです。

2つの方法（ステータス確認を含む）

• URL_UPDATED — “To notify Google of a new URL to crawl or that content at a previously-submitted URL has been updated.” (翻訳) 「クロール対象の新しいURL、または以前送信したURLのコンテンツが更新されたことをGoogleへ通知する」。URLと"type": "URL_UPDATED"をPOSTします。成功時はHTTP 200になりますが、Googleの表現は*“means that Google may try to recrawl this URL soon,”* (翻訳) 「Googleが近いうちにこのURLを再クロールしようとする可能性がある」です。再クロールやインデックス登録を保証しません。
• URL_DELETED — 削除を依頼する前に、“the URL must return a 404 or 410 status code or the page must contain” (翻訳) 「URLが404または410を返すか、ページに」noindexメタタグを含める必要があります。両方ではなくどちらか一方です。条件を満たしたら、URLと"type": "URL_DELETED"をPOSTします。
• ステータス（GET） — メタデータ（latest_update、latest_remove、notify_time）を返します。ただし、GETは*“only returns whether you successfully submitted a request.”* (翻訳) 「リクエストを正常に送信したかどうかだけを返す」ため、実際にインデックス登録または削除されたかは分かりません。
• バッチ処理 — HTTP接続を減らすため、“combine up to 100 calls to the Indexing API into a single HTTP request.” (翻訳) 「Indexing APIへの最大100件の呼び出しを1つのHTTPリクエストにまとめる」ことができます。クォータはURL単位なので、10件を1バッチにしても10件分を消費します。

クォータ

Googleのデフォルトクォータには、1つではなく3つの枠があります。

• プロジェクトごとに1日200件のpublishリクエスト — URL_UPDATEDとURL_DELETEDの合計です。
• プロジェクトごとに1分180件のgetMetadata（ステータス）リクエスト。
• プロジェクトごとに全エンドポイント合計で1分380件。

3つとも*“initial default quota for testing”* (翻訳) 「テスト用の初期デフォルトクォータ」と説明されています。 超過利用には*“requires additional approval for usage and resource provisioning,”* (翻訳) 「利用とリソース提供に追加承認が必要」です。 Googleは*“the quota may increase or decrease based on the document quality.”* (翻訳) 「文書の品質に基づいてクォータが増減する場合がある」とも述べています。 複数のサービスアカウントやプロジェクトを作って日次枠を増やす「裏技」は、Googleが明示的に禁止する行為です。

通常のページに使えるか？Googleが実際に説明していること

短く言えば、公式にサポートされる方法では使えません。Googleは一貫してそう説明し、年々表現を強めています。

公式文書にはスパム警告があります。 2024年9月ごろ、Googleはクイックスタートへ “All submissions through the Indexing API undergo rigorous spam detection,” (翻訳) 「Indexing APIを通じたすべての送信は厳格なスパム検出を受ける」と、 “any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (翻訳) 「複数アカウントなどで利用クォータを超えようとする行為を含め、Indexing APIの悪用を試みるとアクセスを取り消される可能性がある」を追加しました。

Google担当者も何年も同じことを述べています。 2022年5月、John Muellerは建設車両のたとえを使い、 APIは*“is meant for very specific kinds of content,”* (翻訳) 「非常に限定された種類のコンテンツ向け」で、 別用途への利用は*“doesn’t really make sense.”* (翻訳) 「あまり意味がない」と説明しました。 2025年5月にはさらに強く、“We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases,” (翻訳) 「多くのスパマーがこのようにIndexing APIを誤用している。文書化され、サポートされる用途に限ることを勧める」、 “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (翻訳) 「適切に使うか、使わないでほしい。用途を問わず使えると提案したいなら、そう文書化する」と述べました。

2022年の「あまり意味がない」から、2024年の文書上のスパム警告、2025年の「適切に使うか使わない」へ 至る流れは、一度だけの発言ではなく複数年にわたる一貫した姿勢です。通常サイトも対象になると考えた ブロガーやSEO担当者から、用途外の通知がIndexing APIへ大量に送られているとも報じられています。

実際のリスクを正確に表現すると、 Muellerはアルゴリズム上のペナルティを保証してはいません。 公式サポート外でガイドラインに反し、不適切に送信したコンテンツはインデックスに残らない可能性があり、 アクセスを取り消される可能性がある、というのが正確です。必ず手動対策になると誇張すべきではありませんが、 リスクがないように装うべきでもありません。

ステータスエンドポイントの神話

多くのツールが誤るため、ここは独立して強調します。送信成功は受信確認であり、インデックス登録の約束ではありません。 ステータスGETは*“only returns whether you successfully submitted a request.”* (翻訳) 「リクエストを正常に送信したかどうかだけを返す」ものです。200を根拠にダッシュボードが 緑色の「インデックス登録済み」表示を出すなら、APIが伝えていないことを推測しています。

Indexing APIとインデックス登録をリクエスト、IndexNowの比較

よく混同される3つは、別々の仕組みです。

• Indexing API（Google）： プログラムから使えますが、JobPosting／BroadcastEventに限定され、3つの中で最も狭い仕組みです。
• インデックス登録をリクエスト（GSC URL検査）： 所有するどのページにも使えますが、1 URLずつ手動で、単発利用向けです。保証ではなくリクエストです。
• IndexNow： Bing、Yandex、Yep、Seznam、Naver向けのオープンな検索エンジン横断プッシュプロトコルで、Googleは利用していません。私はAhrefs Site AuditへのIndexNow統合に関わりましたが、Googleには届きません。

詳しい比較はFrameworksタブにあります。

一般ページに代わりにすること

求人情報やライブ配信を公開していないなら、Indexing APIは使うべきツールではありません。Googleも繰り返しそう述べています。 一般ページで使えるGoogle向けの手段は、地味ですが次のとおりです。

• サイトマップ — カバレッジと検出に使う。
• 内部リンク — 孤立ページは見つかりにくく、リンクされたページは検出されやすい。
• コンテンツ品質 — インデックス登録する価値をGoogleが判断します。薄いページは、どれほど送信しても「検出 - インデックス未登録」にとどまります。
• GSCの「インデックス登録をリクエスト」 — 本当に必要な単発ケースで控えめに使う。

Google以外のBingなどへ検索エンジン横断でプッシュするなら、IndexNowが適切です。 そもそもページがなぜインデックス登録されないかを知りたいなら、それはAPIではなくクロール頻度と品質の問題です。

AI要約

Advanced版の要点です。

• 何か： Google Cloudで認証し、URL_UPDATED／URL_DELETED通知をGoogleへ送るREST API（v3）。
• 最重要の事実： 公式対応はJobPostingとBroadcastEvent（ライブ配信）ページだけで、一般コンテンツは対象外。どちらも時間依存です。
• 最大の誤解： 「どのページでもすぐにインデックス登録できる」は誤りで、Googleは対象外利用を誤用と呼びます。成功レスポンスはリクエストの受信だけを確認します。
• 姿勢の変化： 2022年の「あまり意味がない」→ 2024年9月のスパム警告 → 2025年5月の「適切に使うか、使わない」へ明確化。
• リスク： 公式サポート外でガイドラインに反し、1日約200件の枠を複数アカウントで回避するとアクセスを取り消される可能性があります。必ず手動対策になるわけではありませんが、コンテンツが残る保証もありません。
• IndexNowとは別： IndexNowはBingやYandexなど向けでGoogleは利用しません。GSCの「インデックス登録をリクエスト」は、所有ページに手動で単発利用する別機能です。
• 通常ページ： サイトマップ、内部リンク、品質、必要時のGSC「インデックス登録をリクエスト」を使います。

公式ドキュメント

Googleによる一次情報です。

Google — インデックス登録 API

• Indexing APIクイックスタート — 概要、JobPosting／BroadcastEventの制限、スパム検出の警告。
• Indexing APIの使用方法 — URL_UPDATED／URL_DELETEDの方法とステータスエンドポイントの注意点。
• 前提条件 — Cloudプロジェクト、サービスアカウント、OAuthスコープ、Search Consoleの委任所有権。
• クォータと料金 — デフォルトクォータ（200件）と増枠時の承認。

Google — 一般ページの参考資料

• URLの再クロールをGoogleへ依頼する — 通常コンテンツで使うサイトマップとSearch Consoleの「インデックス登録をリクエスト」。
• Google検索の仕組みの詳細ガイド — URL検出とクロール→インデックス登録→配信の流れ。

出典からの引用

Googleによる公式発言です。各リンクは、出典ページ内の引用箇所へ移動します。

Google公式文書 — 対象範囲の制限

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (翻訳) 「Indexing APIは、JobPostingまたはVideoObjectに埋め込まれたBroadcastEventを持つページのクロールにのみ使用できます」— Google Search Central、Indexing APIクイックスタート。引用箇所へ移動
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” (翻訳) 「サイト所有者は、求人情報またはライブ配信動画のページが追加・削除されたとき、Googleへ直接通知できます」引用箇所へ移動

Google公式文書 — スパム警告（2024年9月ごろ文書へ追加）

• “All submissions through the Indexing API undergo rigorous spam detection.” (翻訳) 「Indexing APIを通じたすべての送信は厳格なスパム検出を受けます」引用箇所へ移動
• “Any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (翻訳) 「複数アカウントなどで利用クォータを超えようとする行為を含め、Indexing APIの悪用を試みるとアクセスを取り消される可能性があります」引用箇所へ移動

Google公式文書 — ステータスエンドポイントの注意点（神話の検証）

• “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がURLをいつインデックス登録または削除するかは分からず、リクエストを正常に送信したかどうかだけが返されます」— Google Search Central、「Indexing APIの使用方法」。引用箇所へ移動

Google公式文書 — クォータ

• “The default value is set to 200.” (翻訳) 「デフォルト値は200に設定されています」（publishリクエスト／日）— Google Search Central、「クォータと料金」。引用箇所へ移動
• “The default value is set to 180.” (翻訳) 「デフォルト値は180に設定されています」（getMetadataステータスリクエスト／分）と “The default value is set to 380.” (翻訳) 「デフォルト値は380に設定されています」（全エンドポイント／分）— 多くの解説が省く、ほかの2つのクォータ枠です。180の引用箇所へ移動 · 380の引用箇所へ移動
• “The quota may increase or decrease based on the document quality.” (翻訳) 「文書の品質に基づいて、クォータが増減する場合があります」— Google Search Central、「クォータと料金」。引用箇所へ移動

Google公式文書 — バッチ処理と削除

• “…you can combine up to 100 calls to the Indexing API into a single HTTP request.” (翻訳) 「Indexing APIへの最大100件の呼び出しを1つのHTTPリクエストにまとめることができます」— Google Search Central、「Indexing APIの使用方法」。引用箇所へ移動
• “…the URL must return a 404 or 410 status code or the page must contain” (翻訳) 「URLが404または410のステータスコードを返すか、ページに次のものが含まれている必要があります」noindexメタタグ — 削除を依頼する前の条件です。— Google Search Central、「Indexing APIの使用方法」。引用箇所へ移動
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” (翻訳) 「HTTP 200レスポンスは、Googleが近いうちにこのURLを再クロールしようとする可能性があることを意味します」— Google Search Central、「Indexing APIの使用方法」（URL_UPDATEDの説明）。引用箇所へ移動

Google Search AdvocateのJohn Mueller — Bluesky、2025年5月ごろ

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.” (翻訳) 「多くのスパマーがこのようにIndexing APIを誤用しています。そのため、文書化され、サポートされている用途に限ることを勧めます」
• “I’d just use it properly, or not use it. If we wanted to suggest that people could use it regardless, we’d document it as such.” (翻訳) 「適切に使うか、使わないでください。用途を問わず使えると勧めたいなら、そのように文書化します」関連記事を読む

GoogleのJohn Mueller — SEOオフィスアワー、2022年5月（「建設車両」のたとえ） “construction vehicles” (翻訳) 「建設車両」

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.” (翻訳) 「Indexing APIは非常に限定された種類のコンテンツ向けです。ほかの種類のコンテンツに使っても、あまり意味がありません」
• “It’s not that it’s illegal or that it will cause problems if you put construction vehicles on your medical website. But it doesn’t really make sense.” (翻訳) 「医療サイトに建設車両を載せても違法ではなく、問題が起きるわけでもありません。ただ、あまり意味がないのです」関連記事を読む

Indexing API — チートシート

対応する用途（これが全一覧）

2つの方法とステータス確認

バッチ処理： 最大100件の呼び出しを1つのHTTPリクエストにまとめられますが、クォータはバッチではなくURL単位で数えます。

要点

• デフォルトクォータは3枠： 1日200件のpublish、1分180件のステータス（getMetadata）、全エンドポイント合計で1分380件。増枠にはGoogleの承認が必要で、文書品質に応じて変動します。
• 200 ≠ インデックス登録済み。 成功レスポンスは送信を受け取ったことだけを確認します。
• 複数アカウントでクォータを回避するとアクセスを取り消される可能性があります。
• 認証： Google Cloudプロジェクト＋サービスアカウント＋OAuth。スコープはhttps://www.googleapis.com/auth/indexingで、サービスアカウントをGSCの委任所有者にします。
• IndexNowではありません。 サイトマップやGSC「インデックス登録をリクエスト」の代替でもありません。

最小限のpublish呼び出し（対応コンテンツのみ）

これは1件のURL_UPDATED通知の形です。JobPostingまたはBroadcastEvent構造化データを持つ ページだけに使用してください。 APIが正式に認めるのはその用途です。簡潔にするため、サービスアカウントキーを OAuthトークンへ交換する認証手順は省いています。実務ではGoogle APIクライアントライブラリでトークンを取得します。

リクエスト

POST https://indexing.googleapis.com/v3/urlNotifications:publish
Authorization: Bearer <OAUTH_TOKEN>
Content-Type: application/json

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_UPDATED"
}

削除を通知する場合（ページがなくなった、またはnoindexになった後）：

{
  "url": "https://example.com/jobs/senior-seo-analyst",
  "type": "URL_DELETED"
}

ステータス確認 — レスポンスが示すのはリクエストの受信だけで、何かがインデックス登録されたかではありません。

GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https%3A%2F%2Fexample.com%2Fjobs%2Fsenior-seo-analyst
Authorization: Bearer <OAUTH_TOKEN>

ここでの200は「送信を受け取った」という意味で、GoogleがURLをインデックス登録（または削除）した確認ではありません。

複数URLのバッチ処理： 100件を個別送信する代わりに、最大100件の呼び出しを1つのマルチパートHTTPリクエストとして https://indexing.googleapis.com/batchへ送れます。ただしクォータはURL単位なので、100件のバッチは日次枠を100件消費します。 GoogleのAPIクライアントライブラリ（Java、Python、JavaScript、PHP、.NET）が形式を処理するため、独自実装する価値はほとんどありません。

Indexing APIとインデックス登録をリクエスト、IndexNowの比較

判断の軸は、どの種類のページがあり、どの検索エンジンを対象にするかです。それに応じて経路を選びます。

選び方

1. 求人情報やライブ配信を自動通知したい？ → Indexing API。
2. 一般ページをBing／Yandex／Yepへプッシュしたい？ → IndexNow。
3. 通常ページ1件をGoogleに再クロールしてほしい？ → GSC「インデックス登録をリクエスト」。
4. 一般ページをGoogleへ大規模に登録したい？ → プッシュボタンはありません。サイトマップ＋内部リンク＋品質、そして待つことです。

捉え方： Indexing APIはAPIなので最も強力に聞こえますが、コンテンツ種別で見ると最も範囲が狭い仕組みです。強力さと適用範囲は同じではありません。

ツール

• Google Cloud Console — プロジェクトを作成し、Indexing APIを有効にして、認証用のサービスアカウントJSONキーを生成します。
• Google Search Console — URL検査 — 通常ページではこちらが実用的です。クロール、レンダリング、登録状況を確認し、単発時に**「インデックス登録をリクエスト」**を使います。
• Google Search Console — サイトマップとカバレッジ — サイトマップを送信し、登録済み、「検出 - インデックス未登録」、除外の状態を確認します。
• Google APIクライアントライブラリ — JWT署名を独自実装せず、OAuthトークン交換を安全に処理する方法です。
• IndexNow統合（Ahrefs Site Auditなど） — Google以外のBingなどへ横断プッシュする経路です。一般ページへプログラムで通知したい場合に適しています。

時間を使う価値のあるリソース

私の関連記事

• Googlebotとは何か、どのように機能するか — リンク、サイトマップ、RSS、GSC、APIなど、GoogleのURL検出元の中でIndexing APIが占める位置。
• 「検出 - インデックス未登録」の修正方法 — ページが登録されない本当の理由を扱います。修正はプッシュAPIではなく品質と内部リンクです。
• テクニカルSEO初心者ガイド — クロールとインデックス登録を全体像の中で説明します。

私の講演資料

• 検索の仕組み （SlideShare）— 検出、クロール、レンダリング、インデックス登録、ランキングを順に説明し、URL検出のスライドではIndexing APIを「用途が限定される」としています。いつもの注意書きは*“This is my understanding of systems… not going to be 100% complete or accurate.”* (翻訳) 「これは私が理解している仕組みであり、完全でも100%正確でもありません」です。

IndexNow（検索エンジン横断の類似機能。Googleは利用しません）

• Ahrefs Site AuditのIndexNow統合 — GoogleではなくBing／Yandex／Yep向けに、私が実際に推奨するプッシュ経路です。
• Site AuditからIndexNowへページを送信する方法。

その他の資料

• GoogleがIndexing API文書へスパム警告を追加 （Search Engine Journal、2024年9月）— スパム検出の文言が追加された時期を記録しています。
• Google、非対応コンテンツへのIndexing API利用を再びやめるよう警告 （Search Engine Roundtable、2025年5月）— MuellerのBluesky上の警告を報じています。
• Indexing APIの誤用がSEO上の問題につながる可能性 （StanVentures、2025年5月）— Muellerの発言を逐語掲載し、アクセス取消しのリスクを説明します。
• 通常サイトでIndexing APIを使うべきかというGoogleの回答 （iLoveSEO、2022年5月）— Muellerの「建設車両」のたとえを含むオフィスアワーの書き起こしです。
• GoogleのIndexing APIにブロガーが殺到 （Optimixed）— ブロガーとSEO担当者による対象外利用を扱います。
• r/TechSEO — クロールとインデックス登録のデバッグを扱うコミュニティです。

よくある問題

Indexing APIで実際に起きる問題を、症状→原因→修正の順で整理します。

「200レスポンスを受け取ったのにページがインデックス登録されない」

• 症状： URL_UPDATED呼び出しまたはステータスGETは成功するのに、ページが検索へ出ず、Search Consoleも「検出 - インデックス未登録」のままです。
• 原因： 200はGoogleが通知を受け取ったことだけを確認します。公式文書どおり、ステータスエンドポイントは*“only returns whether you successfully submitted a request”* (翻訳) 「リクエストを正常に送信したかどうかだけを返す」ため、クロール、登録、削除の結果は分かりません。
• 修正： APIレスポンスを登録確認として扱わず、Search ConsoleのURL検査またはカバレッジで実際の状態を確認します。十分待っても未登録なら、問題はAPI呼び出しではなく検出や品質です。

「Indexing APIへのアクセスを取り消された」

• 症状： 以前成功していた呼び出しが失敗し、Google CloudまたはSearch Consoleでサービスアカウントのアクセスが失われています。
• 原因： Googleは、“any attempts to abuse the Indexing API, including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked.” (翻訳) 「複数アカウントなどで利用クォータを超えようとする行為を含め、Indexing APIを悪用するとアクセスを取り消される可能性がある」と明記しています。典型例は、JobPosting／BroadcastEvent以外の送信や、1日約200件の枠を追加アカウントで回避することです。
• 修正： 送信内容を監査し、JobPostingまたはBroadcastEvent構造化データを持たない一般コンテンツなら停止します。Muellerの表現は*“I’d just use it properly, or not use it.”* (翻訳) 「適切に使うか、使わないでほしい」です。今後サポート対象内に収める以外の正式な異議申立て経路は文書化されていません。

「通常のページへの送信が何もしていないように見える」

• 症状： 通常の記事や商品ページへURL_UPDATEDを送っても、クロールもインデックス登録も速くなりません。
• 原因： Googleがサポートする2種類のコンテンツではありません。Indexing APIは “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” (翻訳)「JobPosting、またはVideoObjectに埋め込まれたBroadcastEventを含むページのクロールにのみ使用できます」。この範囲外の送信は、文書化されたサポート対象のシグナルではありません。
• 修正： バグではなくツール選択の誤りです。一般ページにはサイトマップ、内部リンク、単発時のSearch Console「インデックス登録をリクエスト」を使います。

「クォータ上限に達している」

• 症状： 1日200件前後、または200件未満でも短時間の集中送信時に失敗やスロットリングが始まります。
• 原因： デフォルト枠は、publish（URL_UPDATED／URL_DELETED）が1日200件、ステータス（getMetadata）が1分180件、全エンドポイント合計が1分380件です。ステータス確認を集中させると日次枠より先に分単位の制限へ達します。いずれかの上限を超えるには、Googleがいう*“requires additional approval for usage and resource provisioning”* (翻訳)「利用とリソースの割り当てに関する追加承認」が必要です。また、付与されるクォータは*“may increase or decrease based on the document quality.”* (翻訳)「文書品質に基づいて増減する場合がある」と説明されています。
• 修正： 正当に多数のJobPosting／BroadcastEventを更新する場合はGoogle Cloudから増枠を申請します。明示的な悪用に当たる追加アカウントやプロジェクトで回避してはいけません。

チェックリスト

Indexing APIに触れる前に

• 送信対象にJobPosting、またはBroadcastEventをVideoObjectに埋め込んだ構造化データが実際にあることを確認する。
• どちらでもなければ停止し、サイトマップ、内部リンク、品質、必要時のGSC「インデックス登録をリクエスト」を使う。
• 送信量が初期値約200件／日に収まるか、増枠申請が必要か判断する。

設定する

• Google Cloudプロジェクトを作成または選択し、Indexing APIを有効にする。
• サービスアカウントを作成してJSONキーをダウンロードし、安全に保管する。公開リポジトリへコミットしない。
• Search Consoleでサイトを確認する。
• サービスアカウントのメールをSearch Consoleの委任されたサイト所有者として追加する。
• スコープhttps://www.googleapis.com/auth/indexingでサービスアカウントキーをOAuthトークンへ交換できることを確認する。

通知を送信する

• 新規・更新した対応ページにはURL_UPDATED、削除する対応ページにはURL_DELETEDを選び、そのページが削除済みまたはnoindex済みであることを確認する。
• URLと正しいtypeをhttps://indexing.googleapis.com/v3/urlNotifications:publishへPOSTする。
• 200は受信確認だけで、登録や削除の証明ではないと扱う。
• 実際の状態確認が必要ならSearch ConsoleのURL検査またはカバレッジで追跡する。

ガイドラインの範囲内にとどまる

• このAPIではJobPosting／BroadcastEventページだけを送信する。
• クォータ回避のため複数アカウントやプロジェクトを作らず、正規の増枠を申請する。
• 対象か不明なら「対象外」と扱い、サイトマップ、内部リンク、「インデックス登録をリクエスト」を使う。

クイズ

Indexing APIの理解を確認する5問です。

変更履歴