Google Indexing API

TL;DR — The Google Indexing API is a way for site owners to tell Google “this page changed, please re-crawl it” through code instead of clicking buttons. But here’s the catch most guides skip: Google only officially supports it for job-posting pages and livestream pages. It is not a shortcut to get your blog posts or product pages indexed faster — Google has said so over and over.

What the Indexing API is

When you publish or change a page, you normally wait for Google to come back and re-crawl it on its own schedule. The Indexing API is a way to push a notification to Google instead — “hey, this URL is new/updated” or “this URL is gone, drop it.” You do it with code (a small program calling Google’s servers), not by clicking around in a dashboard.

That sounds powerful, and it is — for the exact things it’s built for.

The one thing to understand

Google only officially supports the Indexing API for two kinds of pages:

1. Job postings — pages with JobPosting structured data (job listings, which expire and need to come down quickly).
2. Livestreams — pages with BroadcastEvent structured data (live video events, which only matter during the broadcast).

That’s it. Both are time-sensitive content that goes stale fast, which is why Google built a fast lane for them.

If you don’t have job listings or livestreams, the Indexing API is not your tool — no matter what a “get indexed in hours” plugin or SaaS tells you.

The myth to ignore

The single biggest myth online is: “Use the Indexing API to get any page indexed fast.” It doesn’t work that way, and Google has repeatedly called using it for normal pages misuse. People do it anyway because tools sell it as a growth hack — but Google can (and says it will) revoke your access for abusing it.

There’s a second trap, too: when you submit a URL and get a “success” response, that only means Google received your request. It does not mean the page got indexed. Plenty of tools blur that line; Google’s own docs are clear about it.

What to do instead for faster indexing

For regular pages (blogs, products, articles), the things that actually help are boring but real:

• Submit an XML sitemap in Google Search Console.
• Link to your new pages from other pages on your site.
• Make the page genuinely worth indexing (quality, not thin filler).
• For a one-off, use “Request indexing” in Search Console’s URL Inspection tool — sparingly.

Want the technical version — setup, the actual API methods, quotas, and the exact Google quotes? Switch to the Advanced tab.

TL;DR — The Indexing API is a Google Cloud–authenticated REST API (v3) that accepts URL_UPDATED and URL_DELETED notifications. Google officially supports it only for JobPosting and BroadcastEvent-in-VideoObject (livestream) pages — not general content. A 200 from the status endpoint confirms receipt, not indexing. Google’s stance has hardened over years: 2022 (“doesn’t make sense”) → Sept 2024 (a spam warning added to the docs) → May 2025 (Mueller: “spammers misuse the Indexing API… use it properly, or not use it”). Misuse, including multiple accounts to inflate quota, can get access revoked. For general pages, your levers are sitemaps, internal links, quality, and occasional GSC “Request indexing” — and remember Google does not support IndexNow.

What the Indexing API actually is

The Indexing API is a programmatic push channel: a REST API (v3), authenticated through a Google Cloud service account, that you call to tell Google a URL was added/updated (URL_UPDATED) or should be removed (URL_DELETED). It sits alongside sitemaps and Search Console as a way for Google to discover and refresh URLs — but it’s the narrowest of the bunch by content type.

In my How Search Works deck, I list the Indexing API as a URL-discovery source with the tag “limited use cases” — which is the whole story in two words. It’s real, it works, and it’s only sanctioned for a sliver of the web.

What Google officially supports it for

This is the load-bearing fact, so I’ll state it the way Google does. The Indexing API “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” That’s it — two structured-data types:

• JobPosting — job-listing pages. They expire, and stale jobs are a bad user experience, so timely add/remove matters.
• BroadcastEvent in a VideoObject — livestream event pages. They’re only relevant during (and just around) the broadcast.

Why only these two? Both are inherently time-sensitive and short-lived. The rationale Google gives is that fast notification of changes matters far more for these than for evergreen pages, which the normal crawl handles fine.

How it works

Prerequisites

Setup is non-trivial — this isn’t a one-click feature:

• A Google Cloud project with the Indexing API enabled. As Google puts it, you “need to tell Google about your client and activate access to the API.”
• A service account with a JSON key file, stored securely.
• Search Console verification of the site, then add your service account as a delegated site owner.
• OAuth: “Every call to the Indexing API must be authenticated with an OAuth token that you get in exchange for your private key,” using the scope https://www.googleapis.com/auth/indexing.

The two methods (plus a status check)

• URL_UPDATED — “To notify Google of a new URL to crawl or that content at a previously-submitted URL has been updated.” POST the URL with "type": "URL_UPDATED". A successful call gets an HTTP 200 — Google’s own wording is that this “means that Google may try to recrawl this URL soon,” not that it will, or that the crawl will result in indexing.
• URL_DELETED — before you request removal, Google requires that “the URL must return a 404 or 410 status code or the page must contain” a noindex meta tag — it’s an either/or, not “delete the page and also add noindex.” Once that’s true, POST the URL with "type": "URL_DELETED" so Google drops it.
• Status (GET) — returns metadata (latest_update, latest_remove, notify_time). The critical caveat, verbatim: the GET request “only returns whether you successfully submitted a request.” It does not tell you whether Google actually indexed or removed anything.
• Batching — to cut down on HTTP connections, you can “combine up to 100 calls to the Indexing API into a single HTTP request.” Quota is still counted per URL: 10 requests in one batch still uses 10 requests of quota.

Quotas

Google’s default quota has three separate dimensions, not just one number:

• 200 publish requests/day per project — covers both URL_UPDATED and URL_DELETED calls combined. This is the number most guides cite.
• 180 getMetadata (status) requests/minute per project.
• 380 requests/minute per project across all endpoints combined.

All three are described as “initial default quota for testing” — going beyond them “requires additional approval for usage and resource provisioning,” via a request form, and Google notes “the quota may increase or decrease based on the document quality.” The common “hack” of spinning up multiple service accounts or projects to inflate the daily quota is exactly what Google forbids (see below).

Can you use it for normal pages? What Google actually says

Short answer: no, not in a supported way — and Google has been remarkably consistent and increasingly blunt about it.

The docs carry a spam warning. Around September 2024, Google added language to the quickstart making the stance explicit: “All submissions through the Indexing API undergo rigorous spam detection,” and “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.”

The reps have said it for years. Back in May 2022, John Mueller framed it with his construction-vehicles analogy: the API “is meant for very specific kinds of content,” and using it elsewhere “doesn’t really make sense.” By May 2025 the tone was sharper — Mueller: “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases,” and “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.”

That arc — 2022 “doesn’t make sense” → 2024 spam warning in the docs → 2025 “spammers misuse… use it properly or not use it” — is a multi-year pattern, not a one-off. Coverage has also noted the API gets effectively inundated by bloggers and SEOs treating normal sites as if they qualified.

The real risk, stated precisely. Mueller stops short of promising an algorithmic penalty. The honest framing is: it’s unsupported and against the guidelines, content pushed in improperly may not stay indexed, and your access can be revoked. Don’t overstate it as a guaranteed manual action — but don’t pretend it’s free, either.

The status-endpoint myth

This one deserves its own line because so many tools get it wrong: a successful submission is receipt confirmation, not an indexing promise. The status GET “only returns whether you successfully submitted a request.” If a dashboard shows you a green “indexed” badge off the back of a 200, it’s inferring something the API never told it.

Indexing API vs Request Indexing vs IndexNow

Three things get conflated constantly. They’re different mechanisms:

• Indexing API (Google): programmatic, but content-restricted to JobPosting/BroadcastEvent. The narrowest of the three.
• Request Indexing (GSC URL Inspection): works for any page you own, but it’s manual, one URL at a time, and meant for occasional use — and it’s a request, not a guarantee.
• IndexNow: the open, cross-engine push protocol (Bing, Yandex, Yep, Seznam, Naver) — and Google does not use it. It’s the cross-engine analog to the Indexing API, and the one I actually champion: I helped ship the IndexNow integration in Ahrefs Site Audit. But it doesn’t reach Google.

(Full breakdown in the Frameworks tab.)

What to do instead for general pages

If you’re not posting jobs or livestreams, the Indexing API is not your tool, and Google has said so repeatedly. Your real Google levers are the unglamorous ones:

• Sitemaps — for coverage and discovery.
• Internal links — orphan pages struggle; linked pages get found.
• Content quality — Google decides what’s worth indexing; thin pages stall at “Discovered – currently not indexed” no matter how hard you push them.
• GSC “Request indexing” — for genuine one-offs, sparingly.

For cross-engine pushing (Bing and friends, not Google), IndexNow is the right tool. And if you care about why pages aren’t getting indexed in the first place, that’s a crawl-frequency and quality question, not an API question.

AI summary

A condensed take on the Advanced version:

• What it is: a Google Cloud–authenticated REST API (v3) for pushing URL_UPDATED / URL_DELETED notifications to Google.
• The one fact that matters: officially supported only for JobPosting and BroadcastEvent (livestream) pages — not general content. Both are time-sensitive by design.
• The #1 myth: “it indexes any page fast.” It doesn’t; Google calls broader use misuse. A successful submission only confirms Google received the request, not that anything was indexed.
• Google’s stance hardened over time: 2022 “doesn’t make sense” → Sept 2024 spam warning added to the docs → May 2025 Mueller “spammers misuse… use it properly, or not use it.”
• Risk: unsupported/against guidelines; multiple accounts to beat the ~200/day quota can get access revoked. Not necessarily a manual penalty — but content may not stick.
• Not the same as IndexNow (cross-engine, Bing/Yandex/etc. — Google doesn’t use it) or GSC Request Indexing (any page, manual, occasional).
• For normal pages: sitemaps + internal links + quality + occasional GSC Request Indexing.

Official documentation

Primary-source documentation from Google.

Google — Indexing API

• Indexing API Quickstart — the overview, the JobPosting/BroadcastEvent restriction, and the spam-detection warning.
• How to Use the Indexing API — the URL_UPDATED / URL_DELETED methods and the status-endpoint caveat.
• Prerequisites — Cloud project, service account, OAuth scope, and Search Console delegated ownership.
• Quota and pricing — the default quota (200) and the approval needed for more.

Google — context for general pages

• Ask Google to recrawl your URLs — sitemaps and the Search Console “Request indexing” path for normal content.
• In-Depth Guide to How Google Search Works — where URL discovery and the crawl → index → serve pipeline fit.

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google docs — the restriction

• “The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” — Google Search Central, Indexing API Quickstart. Jump to quote
• “The Indexing API allows site owners to directly notify Google when their job posting or livestreaming video pages are added or removed.” Jump to quote

Google docs — the spam warning (added to the documentation around September 2024)

• “All submissions through the Indexing API undergo rigorous spam detection.” Jump to quote
• “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.” Jump to quote

Google docs — the status-endpoint caveat (myth-buster)

• “The GET request doesn’t tell you when Google indexes or removes a URL; it only returns whether you successfully submitted a request.” — Google Search Central, How to Use the Indexing API. Jump to quote

Google docs — quota

• “The default value is set to 200.” (publish requests/day) — Google Search Central, quota & pricing. Jump to quote
• “The default value is set to 180.” (getMetadata status requests/minute) and “The default value is set to 380.” (all endpoints/minute) — the two other quota dimensions most guides skip. Jump to 180 · Jump to 380
• “The quota may increase or decrease based on the document quality.” — Google Search Central, quota & pricing. Jump to quote

Google docs — batching and removal

• “…you can combine up to 100 calls to the Indexing API into a single HTTP request.” — Google Search Central, How to Use the Indexing API. Jump to quote
• “…the URL must return a 404 or 410 status code or the page must contain” a noindex meta tag — before requesting removal. — Google Search Central, How to Use the Indexing API. Jump to quote
• “An HTTP 200 response means that Google may try to recrawl this URL soon.” — Google Search Central, How to Use the Indexing API (on URL_UPDATED). Jump to quote

John Mueller, Google Search Advocate — Bluesky, ~May 2025

• “We see a lot of spammers misuse the Indexing API like this, so I’d recommend just sticking to the documented & supported use-cases.”
• “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.” Read the coverage

John Mueller, Google — SEO office-hours, May 2022 (the “construction vehicles” framing)

• “The indexing API is meant for very specific kinds of content. And using it for other kinds of content doesn’t really make sense.”
• “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.” Read the coverage

Indexing API — cheat sheet

Supported use cases (this is the whole list)

The two methods

Batching: combine up to 100 calls into one HTTP request — quota still counts per URL, not per batch.

Fast facts

• Default quota has three parts: 200 publish requests/day, 180 status (getMetadata) requests/minute, 380 requests/minute across all endpoints. Quota beyond that needs Google’s approval and can shift with document quality.
• 200 ≠ indexed. A success response confirms submission received, nothing more.
• Multiple accounts to beat the quota = access revoked (per the docs).
• Auth: Google Cloud project + service account + OAuth, scope https://www.googleapis.com/auth/indexing, service account added as a GSC delegated owner.
• Not IndexNow (cross-engine, not Google). Not a replacement for sitemaps or GSC Request Indexing.

A minimal publish call (for supported content only)

This is the shape of a single URL_UPDATED notification. Only use it for pages with JobPosting or BroadcastEvent structured data — that’s what the API is sanctioned for. The auth step (exchanging your service-account key for an OAuth token) is omitted for brevity; in practice you’d use a Google API client library to get the token.

The request

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"
}

To signal a removal (after the page is gone or noindexed):

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

Checking status — note the response tells you only that the request was received, not whether anything was indexed:

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

A 200 here means “we got your submission” — it is not a confirmation that Google indexed (or removed) the URL.

Batching multiple URLs: you can combine up to 100 individual calls into a single multi-part HTTP request to https://indexing.googleapis.com/batch instead of firing 100 separate requests — but quota is still counted per URL, so a 100-call batch still uses 100 requests of your daily allowance. Google’s API client libraries (Java, Python, JavaScript, PHP, .NET) handle the batch formatting for you; hand-rolling it is rarely worth it.

Indexing API vs Request Indexing vs IndexNow

The decision framework: figure out what you have and which engine you care about, then pick the channel.

How to choose

1. Got job postings or livestreams, and want to automate? → Indexing API.
2. Want to push general pages to Bing/Yandex/Yep? → IndexNow.
3. Want Google to recrawl one normal page, once? → GSC “Request indexing.”
4. Want general pages indexed at scale on Google? → There’s no push button. Sitemaps + internal links + quality. (And patience — see crawl frequency.)

The mental model: the Indexing API sounds like the most powerful of the three because it’s an API, but by content type it’s the narrowest. Power and scope aren’t the same thing.

Tools

• Google Cloud Console — create the project, enable the Indexing API, and generate the service-account JSON key you’ll authenticate with.
• Google Search Console — URL Inspection — for normal pages, this is your real tool: check how a URL was crawled/rendered/indexed, and use “Request indexing” for occasional one-offs.
• Google Search Console — Sitemaps & Coverage — submit sitemaps and see what’s indexed, “Discovered – currently not indexed,” or excluded.
• Google API client libraries — the cleanest way to handle the OAuth token-exchange for Indexing API calls (rather than hand-rolling JWT signing).
• IndexNow integration (Ahrefs Site Audit, etc.) — for the cross-engine push channel (Bing and others, not Google). The right tool when you want the programmatic-push behavior people wish the Indexing API gave them for general pages.

Resources worth your time

My related writing

• What Is Googlebot & How Does It Work? — where the Indexing API sits among Google’s URL-discovery sources (links, sitemaps, RSS, GSC, and the API).
• How to Fix “Discovered – currently not indexed” — the real “why won’t my pages index” page; the fix is quality and internal links, not a push API.
• The Beginner’s Guide to Technical SEO — where crawling and indexing fit in the bigger picture.

My speaking

• How Search Works (SlideShare) — my walkthrough of discovery, crawling, rendering, indexing, and ranking; the URL-discovery slide tags the Indexing API “limited use cases.” (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)

On IndexNow (the cross-engine sibling — note Google does not use it)

• IndexNow integration in Ahrefs Site Audit — the push channel I actually endorse, for Bing/Yandex/Yep rather than Google.
• How to submit pages to IndexNow within Site Audit.

From others

• Google Adds Spam Warning To Indexing API Documentation (Search Engine Journal, Sept 2024) — documents when the spam-detection language went in.
• Google Again Says Stop Using Indexing API For Unsupported Content (Search Engine Roundtable, May 2025) — Barry Schwartz covers Mueller’s Bluesky warning to stop misusing the API.
• Misuse of Indexing API Could Lead to SEO Issues (StanVentures, May 2025) — reproduces Mueller’s May 2025 Bluesky quotes verbatim and explains the access-revocation risk.
• Google Answers Whether Using the Indexing API for a Normal Website Is Good or Bad (iLoveSEO, May 2022) — transcript of Mueller’s “construction vehicles” office-hours framing.
• Google Says Its Indexing API Is Inundated by Bloggers (Optimixed) — covers how off-label use by bloggers and SEOs has overwhelmed the API.
• r/TechSEO — the community for crawl/index debugging.

Common issues

Problems people actually run into with the Indexing API, in symptom → cause → fix order.

”I got a 200 response but the page still isn’t indexed”

• Symptom: The URL_UPDATED call (or the status GET) returns success, but the page never shows up in search, or Search Console still says “Discovered – currently not indexed.”
• Cause: A 200 only confirms Google received the notification. Per Google’s own docs, the status endpoint “only returns whether you successfully submitted a request” — it doesn’t tell you whether anything was crawled, indexed, or removed.
• Fix: Stop treating the API response as an indexing confirmation. Check actual indexing status in the URL Inspection tool in Search Console, or the Coverage report. If the page still isn’t indexed after a reasonable wait, the issue is discovery/quality (see “What to do instead” in the Advanced tab), not the API call.

”My Indexing API access got revoked”

• Symptom: Calls that used to work start failing, or Google Cloud/Search Console shows the service account’s access has been pulled.
• Cause: Google states plainly that “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.” The most common trigger is submitting non-JobPosting/non-BroadcastEvent pages, or spinning up extra service accounts to get around the ~200/day default quota.
• Fix: Audit what you’ve been submitting — if it’s general content (blog posts, product pages, anything without JobPosting or BroadcastEvent structured data), stop. The API is not documented to support it, and Mueller has said directly: “I’d just use it properly, or not use it.” There’s no documented appeal path beyond staying inside the supported use case going forward.

”Submissions for normal pages don’t seem to do anything”

• Symptom: You submit URL_UPDATED for a regular article or product page and nothing changes — no faster crawl, no faster indexing.
• Cause: The content type isn’t one of the two Google supports. The Indexing API “can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject.” Submissions outside that scope aren’t a documented, supported signal.
• Fix: This isn’t a bug to fix — it’s the wrong tool. For general pages, use a sitemap, internal links, and (for occasional one-offs) “Request indexing” in Search Console’s URL Inspection tool instead.

”I’m hitting the quota limit”

• Symptom: Submissions start failing or getting throttled — either around 200/day, or in shorter bursts even under 200/day.
• Cause: Google actually enforces three separate default quotas: 200 publish (URL_UPDATED/URL_DELETED) requests per day, 180 status (getMetadata) requests per minute, and 380 requests per minute across all endpoints combined. A burst of status checks can throttle you on the per-minute limits well before you hit the daily 200. Going beyond any of these “requires additional approval for usage and resource provisioning,” and Google notes the granted quota “may increase or decrease based on the document quality.”
• Fix: If you’re legitimately publishing/updating that many JobPosting or BroadcastEvent pages a day, request a quota increase through Google Cloud — don’t create extra service accounts or projects to work around it, since that’s explicitly named as the kind of abuse that gets access revoked.

Checklists

Before you touch the Indexing API

• Confirm the pages you want to submit actually carry JobPosting structured data, or BroadcastEvent embedded in a VideoObject — the only two content types Google supports.
• If neither applies, stop here. Use sitemaps, internal links, content quality, and occasional GSC “Request indexing” instead — not the API.
• Decide whether your submission volume will realistically fit inside the default ~200/day quota, or whether you’ll need to request an increase.

Setting it up

• Create (or choose) a Google Cloud project and enable the Indexing API in it.
• Create a service account and download its JSON key file; store it securely (never commit it to a public repo).
• Verify your site in Search Console if it isn’t already.
• Add the service account’s email as a delegated site owner in Search Console.
• Confirm you can exchange the service-account key for an OAuth token with scope https://www.googleapis.com/auth/indexing (typically via a Google API client library rather than hand-rolled JWT signing).

Submitting a notification

• Pick the right method: URL_UPDATED for a new or changed supported page, URL_DELETED after the page is gone or noindexed.
• POST the URL with the correct type field to https://indexing.googleapis.com/v3/urlNotifications:publish.
• Treat a 200 response as receipt confirmation only — not proof the page was indexed or removed.
• Follow up in Search Console (URL Inspection or Coverage) if you need to confirm actual indexing status.

Staying inside the guidelines

• Only submit JobPosting/BroadcastEvent pages through this API — nothing else.
• Don’t create multiple service accounts or projects just to exceed the quota; request a legitimate increase instead.
• If you’re not sure whether a page qualifies, treat that as “it doesn’t” and use sitemaps/internal links/Request indexing for it instead.

Quiz

Five questions to check what actually stuck about the Indexing API.

Google Indexing API

The Google Indexing API lets site owners notify Google directly when a URL is added, updated, or removed. Google officially supports it only for pages with JobPosting or BroadcastEvent (livestream) structured data — not for general content.

Related: Crawling, Indexing

Google Indexing API

The Google Indexing API is a Google Cloud–authenticated REST API (v3) that accepts URL_UPDATED and URL_DELETED notifications, letting you push a change signal directly to Google instead of waiting for the next crawl. Unlike submitting a sitemap or clicking “Request indexing” in Search Console, it’s a programmatic channel — but a narrowly scoped one.

The key fact people miss: Google officially supports it only for pages with JobPosting structured data or BroadcastEvent embedded in a VideoObject (livestream). It is not a general-purpose “index any page faster” tool. Google restricts supported use to time-sensitive content where freshness matters most — job listings (which expire) and livestream events (relevant only during the broadcast).

Two more things to keep straight. First, a successful submission only confirms Google received your request; it does not confirm anything was indexed. Second, Google warns that misuse — including spinning up multiple accounts to exceed quotas — can get your access revoked. For general pages, your real Google levers are sitemaps, internal links, content quality, and the occasional Search Console “Request indexing” — not this API. It’s also distinct from IndexNow, the cross-engine push protocol that Bing and others use but Google does not.

Related: Crawling, Indexing

Changelog