Google Indexing API: what it actually covers

Officially, the Google Indexing API covers exactly two things: pages with JobPosting structured data, and pages with BroadcastEvent embedded in a VideoObject (livestreams). Google’s own documentation states that limit plainly. It is not a general-purpose “index my blog post” endpoint — despite an entire product category having been built on treating it as one.

Last updated 2026-07-28

What is the Google Indexing API?

It is a single HTTP endpoint that tells Google a specific URL has been created, updated or removed. You POST one URL at a time to urlNotifications:publish, authenticated with OAuth 2.0, as a verified owner of that site in Search Console.

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

{
  "url": "https://example.com/page",
  "type": "URL_UPDATED"
}

type is either URL_UPDATED (created or changed) or URL_DELETED (removed). There is a companion read endpoint, urlNotifications/metadata, which tells you when Google last received a notification for a URL — note that this is notification state, not index state.

The required OAuth scope is https://www.googleapis.com/auth/indexing. The authenticated identity — a service account or a user — must be a verified owner of the property in Search Console. There is no way around that requirement, and it is the thing that stops the API being used to spam other people’s domains.

Which page types does Google officially support?

Two, and only two: pages with JobPosting markup, and pages with BroadcastEvent embedded in a VideoObject. Google’s documentation says the Indexing API can only be used to crawl pages with one of those two markup types.

That restriction is not a footnote or a soft recommendation — it is the stated scope of the product, and the quota-increase request form is explicitly for gaining approval to use the API for those two markup types.

Google Search Advocates have said repeatedly and publicly that site owners should stick to the documented use cases, and have warned that non-conforming use may simply stop working. That is not a theoretical risk: TagParrot, one of the better-known automated indexing services, shut down in 2024 after Google tightened enforcement of the API’s intended scope. Any product whose entire value depends on this endpoint working for ordinary pages is one policy change from being worthless.

What are the real quotas and limits?

The default is 200 publish requests per day per Google Cloud project, counting both URL_UPDATED and URL_DELETED. There are also per-minute ceilings: 180 requests per minute for read-only getMetadata calls, and 380 per minute across all endpoints. Use of the API is free of charge.

The scoping detail that catches people out: the daily quota is per Google Cloud project — effectively per OAuth client — not per website. If you manage eight sites through one Cloud project, all eight share the same 200 submissions a day. Anyone running more than a couple of sites needs to think about allocation, not just volume.

The daily quota resets at midnight Pacific Time, and Google notes that newly granted quota can take up to 24 hours to take effect. Increases are requested through a form, and approval is tied to actually using the API for JobPosting or BroadcastEvent content.

What does a 200 response actually mean?

It means Google received and accepted the notification. That is all. It is not confirmation that the page was crawled, and it is emphatically not confirmation that the page was indexed.

The gap between those three things is where most disappointment in this category comes from. A successful submission tells you the notification half of the job succeeded — the half you control. Whether Google then crawls the URL depends on crawl scheduling, and whether it indexes the page depends on its assessment of the content. Neither is exposed through this API.

If you want to know whether a URL is actually indexed, the Search Console URL Inspection tool and the Page indexing report are the only authoritative sources. And if a lot of your URLs are sitting in “Discovered — currently not indexed”, no amount of API submission will move them — that is a content verdict, not a discovery problem.

Service account or OAuth client — which should I use?

Both work. A service account is the path Google’s own documentation takes, and requires adding the service account’s email address as an owner of the property in Search Console. A desktop OAuth client authenticates as you, so it inherits the ownership you already have and needs no extra Search Console step.

The practical trade-off is where the credential lives. A service account is a long-lived key file, which is convenient for servers and awkward on a laptop. A user OAuth client is a short-lived token refreshed from a refresh token, which suits a desktop app.

How do I set the Indexing API up?

Five steps, once, in about five minutes: create a Google Cloud project, enable the Indexing API in it, configure an OAuth consent screen, create a client credential, and confirm the identity is a verified owner in Search Console.

Indexa walks through exactly this flow with screenshots at the Google setup guide.

How does Indexa use this API?

Indexa submits through your Google Cloud project and your OAuth client, so it spends your own 200-per-day quota rather than reselling someone else’s. It sends one URL_UPDATED notification per URL to the publish endpoint, tracks the daily budget across every site you have added, and stops cleanly when the budget is gone.

The concrete behaviour, since vague claims are not much use to anyone evaluating this:

Because the Google half of this is officially restricted, Indexa treats it as one of two channels rather than the whole product. The other is IndexNow, which has no such restriction and covers Bing, Yandex, Seznam, Naver and Yep. Indexa is $19 once with no subscription; it submits URLs, and it does not claim to guarantee indexing.