Google Indexing API explained: what it does, who it's for, and its limits

The Google Indexing API is a free Google service that lets a verified site owner notify Google that a specific URL was added, updated or removed, so Googlebot can crawl it sooner than it would through a sitemap. Google's documentation, last updated July 16, 2026, limits it to one narrow job: pages with JobPosting structured data, or BroadcastEvent embedded in a VideoObject (livestreams). Every new project starts with a default quota of 200 publish requests per day, and Google describes that allowance as being for onboarding and testing.

That is the documented version. In SEO circles you will also hear that the API works on any page, blog posts included. That claim comes from vendor tests, not from Google, and the two stories need to stay apart if you are deciding whether to build anything.

What is the Google Indexing API?

The Google Indexing API is a push channel: instead of waiting for Google to rediscover a page, your server sends Google a notification with the URL and one of two types, URL_UPDATED or URL_DELETED. Google's quickstart says the API "prompts Googlebot to crawl your pages sooner than updating the sitemap."

The API does four things:

• Tell Google a URL is new or has changed (URL_UPDATED).
• Tell Google a URL has been removed (URL_DELETED).
• Check the last time Google received each kind of notification for a URL.
• Bundle up to 100 of those calls into one HTTP request (a batch).

Notice what is missing from that list. There is no "index this page" command. You are sending a notification, and Google decides what to do with it.

What pages does Google say the Indexing API is for?

Google says the Indexing API "can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject." That sentence appears on the quickstart, on the usage page and on the quota page. It is the only scope Google documents.

The reasoning is easy to see. Job listings and livestreams are short-lived. A job that closes on Friday is useless in search results on Monday, and a livestream matters mostly while it is live. For sites with "many short-lived pages like job postings or livestream videos," Google recommends the Indexing API over sitemaps, and in the same paragraph says it still recommends submitting a sitemap "for coverage of your entire site."

Why SEOs use it on ordinary pages anyway

Some SEO tool vendors report that the Indexing API works on any page. This is practitioner testimony, not Google policy. Rank Math, which built a WordPress plugin around the API, writes that in its internal tests and public beta, Google appeared to crawl and index submitted pages "regardless of its structured data."

Read the fine print, though. The same Rank Math article says it does "not recommend using it on money websites" and tells readers to proceed at their own risk. And requestindexing.com, one of the more careful explainers on this topic, states that "ordinary website pages are outside that supported use." That site also published a correction on 15 September 2026 so its guide now separates notification receipt from indexing and includes Google's approval requirement.

My view: "it worked in our tests" is a claim about a past moment on someone else's sites. It tells you nothing about what Google will do with your pages next month, and nothing in Google's documentation says it will act on them.

What Google says about abuse

Google's quickstart states that "all submissions through the Indexing API undergo rigorous spam detection" and that attempts to abuse the API, "including the use of multiple accounts or other means to exceed usage quotas, may result in access being revoked." The usage page adds that Google's spam policies apply to content submitted with the API. If your plan involves spinning up extra Cloud projects to multiply the 200-request quota, Google has named that exact behavior.

How does the Indexing API work?

The Indexing API works as a notice-and-maybe loop: you send a notice, Google acknowledges it, and Google may or may not crawl. Here is the sequence for an update:

1. Your system sends a POST to https://indexing.googleapis.com/v3/urlNotifications:publish with the page URL and the type URL_UPDATED. The Content-Type header must be application/json.
2. Google responds with HTTP 200 if it accepted the notification. According to Google, that 200 "means that Google may try to recrawl this URL soon."
3. If the page changes again later, you send another update notification.

The request body is one URL:

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

Deletions work the same way with URL_DELETED, with one precondition. Before you send it, the URL must return a 404 or 410, or the page must carry <meta name="robots" content="noindex" />. A 200 on a deletion means, in Google's words, that "Google may remove this URL from the index."

May. Both times. The acknowledgment confirms Google received your message, and that is all it confirms.

How do you set up the Google Indexing API?

You set up the Google Indexing API by creating a Google Cloud project, giving a service account Owner access to your site in Search Console, and authenticating with the indexing scope. Google's prerequisites page lays it out in this order:

1. Create a project and enable the API. Use Google's setup tool to create a project in the Google API Console and turn on the Indexing API.
2. Create a service account. On the Service Accounts page, create an account, then generate a key. Google recommends the JSON format. Google tells you to store it securely. Treat it like a password.
3. Verify your site in Search Console. Any verification method Search Console supports is fine.
4. Add the service account as a delegated Owner. In Search Console, add the service account's email address (it ends in iam.gserviceaccount.com) as an Owner of the property. Not a user. An Owner.
5. Get an access token. Authenticate with the OAuth scope https://www.googleapis.com/auth/indexing.
6. Request approval and quota. The default quota is for onboarding and testing. Production use needs Google's approval, covered in the next section.

Do you need a developer? Not for the Cloud and Search Console steps. For the code that sends requests (tokens, retries, batching, logging), yes, unless you use a plugin, and a plugin still needs every step above done first.

One consequence of step 4: you can only notify Google about URLs on properties where your service account is an Owner. The API cannot touch pages on sites you don't control, which rules it out for backlinks on other people's domains. If that is your problem, the guide to indexing backlinks covers the options.

What are the Indexing API quotas and limits?

The Google Indexing API allows 200 publish requests per day per project by default, and Google says that allowance exists "for API onboarding and submission testing." The full set of defaults from the quota and pricing page:

Quota	Default	What it covers
Publish requests	200 per day, per project	Both URL_UPDATED and URL_DELETED
Metadata (status) requests	180 per minute, per project	Read-only checks on the getMetadata endpoint
All endpoints combined	380 per minute, per project	Every request type

The daily quota resets at midnight Pacific Time, and Google notes that new quota can take up to 24 hours to become effective. You can view your current quota in the Google API Console.

Batching does not stretch the limit. Google says "quota is counted at the URL level," so a batch of 100 URLs spends 100 units. Batching saves HTTP connections, not quota.

To go beyond the default, you fill out Google's request form with your Cloud project details. The form is explicitly for approval "to use the API for pages with JobPosting or BroadcastEvent markup." Google also warns that "the quota may increase or decrease based on the document quality." So the approval path assumes your pages fit the documented scope. A blog asking for more quota is asking for something the form was not written for.

Pricing is simple: "All use of the Indexing API is available without payment." The cost is engineering time and the quota ceiling, not money.

What do the Indexing API endpoints do?

The Indexing API has three endpoints: one to publish notifications, one to check notification status, and one to batch calls together.

Endpoint	Method and URL	What it tells you
Publish	POST https://indexing.googleapis.com/v3/urlNotifications:publish	Whether Google accepted your update or deletion notice
Metadata	GET https://indexing.googleapis.com/v3/urlNotifications/metadata?url=ENCODED_URL	When Google last received each notification type for that URL
Batch	POST https://indexing.googleapis.com/batch	Up to 100 calls in one multipart HTTP request

The metadata endpoint is the one people misread. Google is blunt about it: the status request "doesn't tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request." If a dashboard shows green ticks based on this endpoint, those ticks mean "delivered," not "indexed." To see whether a page is indexed, use the URL Inspection tool in Search Console.

Google's errors reference was unavailable when this guide was checked in September 2026, so no exact error strings are quoted here. Practitioner guides from Rank Math and Job Boardly report the usual failures as permission errors when Google can't verify that the service account owns the site, and errors when the API was never enabled on the project. That is reported experience, not Google's reference.

Indexing API vs sitemap vs URL Inspection vs IndexNow: which should you use?

For most sites the answer is a sitemap plus occasional URL Inspection requests, with the Indexing API reserved for job and livestream pages. These are four different tools, and none of them guarantees indexing:

Method	Documented purpose	How the engine hears about the URL	Limit	Guarantees indexing?	Setup effort
Google Indexing API	Pages with JobPosting or BroadcastEvent in VideoObject	You push a notification	200 publish requests per day per project by default	No. A 200 means Google "may try to recrawl"	High: Cloud project, service account, Owner delegation, code
XML sitemap	Whole-site coverage and large numbers of URLs	Google reads the file when it chooses	50,000 URLs or 50MB uncompressed per sitemap file	No. Google calls a sitemap "merely a hint"	Low
URL Inspection, Request indexing	A small number of individual URLs	You click a button in Search Console	A quota applies; Google does not publish the number on its recrawl help page	No	Very low once the site is verified
IndexNow	Notifying participating search engines of changed URLs	You push a notification	Up to 10,000 URLs per POST request	No	Low: a key file on your site plus a request

Sources: Google's sitemap documentation, Google's page on asking Google to recrawl, and the IndexNow FAQ.

IndexNow is not a Google product. The IndexNow FAQ lists Amazon, Bing, Naver, Seznam.cz, Yandex and Yep as participating engines, and Google is not on that list. Pushing a URL through IndexNow tells those engines about it, not Google. Our IndexNow guide covers the protocol in detail.

Google's recrawl page also says plainly that "requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all," and that crawling "can take anywhere from a few days to a few weeks." Every method in the table is a request. For the one-page case, see how to submit a URL to Google; for a brand-new domain, start with how to submit a website to Google.

What are the risks of relying on the Indexing API?

The biggest risk of relying on the Indexing API is building a workflow on behavior Google has never promised. The specific problems:

• Outside job and livestream pages, you are relying on vendor test reports, not documentation. If Google changes how it treats those requests, you have no documented behavior to point to.
• Google says abuse, including multiple accounts to exceed quota, "may result in access being revoked."
• The 200 publish requests a day are a testing allowance, and approval for more is scoped to job and livestream pages.
• A 200 response and a metadata timestamp both look like success. Neither is evidence of indexing.
• If a page isn't indexed because it's thin, duplicated, blocked by robots.txt, or marked noindex, a notification does not change that.

That last point applies to every channel. Before you notify any engine about any URL, check that it resolves to its final address, returns 200, is not noindexed in a meta tag or an X-Robots-Tag header, and is not blocked in robots.txt. Bulk Indexer runs those checks before submission: redirects are followed so the final URL is submitted, and 404s, noindex and robots.txt blocks are caught and not charged. You can do the same checks by hand with a crawler and a spreadsheet.

Should you use the Indexing API for your site?

Use the Indexing API if you publish job postings or livestream pages with the right structured data. That is its documented purpose, Google recommends it over sitemaps for that content, and the free price makes it an easy call for any job board with a developer.

For everything else, my recommendation is no. Vendors say they have seen it work on blog posts, and maybe they have. You'd still be spending engineering time on an undocumented use, capped at a testing quota, with an approval process written for other content. Your time goes further on the basics: a clean sitemap, strong internal links to new pages, and URL Inspection for the handful of pages that matter most this week.

And if a tool or plugin sells you "Indexing API for any page," ask the question requestindexing.com's own correction answers: does it separate notification receipt from indexing? If the pitch blurs the two, walk away.

Google Indexing API FAQ

Is the Google Indexing API free to use?

Yes. Google's quota and pricing page states that "all use of the Indexing API is available without payment." The limits are quota and approval, not cost.

Can I use the Google Indexing API for a regular blog post or product page?

Google does not support it. The documented scope is pages with JobPosting or BroadcastEvent embedded in VideoObject. Some vendors report it working on other pages in their own tests, but that is anecdotal, and at least one of them advises against using it on money sites.

Does the Indexing API guarantee my page will be indexed?

No. A successful response means Google "may try to recrawl this URL soon." The status endpoint only confirms that your request was received, not that anything was indexed.

What is the daily limit for the Google Indexing API?

The default is 200 publish requests per day per project, covering both updates and deletions, reset at midnight Pacific Time. Status checks have a separate limit of 180 per minute, and all endpoints together are capped at 380 per minute.

How is the Indexing API different from Request indexing in Search Console?

Request indexing is a manual button in the URL Inspection tool, meant for a small number of URLs and subject to its own quota. The Indexing API is a programmatic push channel for job and livestream pages. Neither guarantees indexing.

Can the Indexing API remove a page from Google?

It can ask. Send URL_DELETED only after the page returns 404 or 410 or carries a noindex robots meta tag. Google's response says it "may remove this URL from the index," which is a request, not a confirmation.

Is the Indexing API the same as IndexNow?

No. The Indexing API is Google's own, restricted to job and livestream pages. IndexNow is a separate protocol supported by engines including Bing, Yandex, Naver, Seznam.cz, Yep and Amazon, and Google is not listed as a participant on indexnow.org.

If you manage large lists of URLs, Bulk Indexer submits your links through multiple indexing channels, with a per-URL status report and CSV export. A $1 trial gives you 50 credits to test on a small set first. Indexing is never guaranteed by anyone, us included, so start small and check the results in Search Console. See pricing or how it works.