Google Indexing API: What It Actually Supports (and What It Does Not)

The Google Indexing API has a reputation problem. It is widely described online as a way to get any page indexed instantly, and that is not what it is. Google documents it as supporting exactly two things: pages with JobPosting structured data, and pages with BroadcastEvent markup for live streams. Everything else is outside what it supports.

That is worth stating plainly at the top, because a great deal of time gets spent wiring up service accounts in the hope of forcing blog posts into the index. This guide covers what the API genuinely does, how to set it up properly if you have the content types it serves, the quota you get, and what to use instead when you do not.

What the Indexing API Is For

Both supported types share one characteristic: the content expires. A job listing closes. A live stream ends. In both cases a stale search result is actively bad — a user clicking a job that was filled a week ago is a poor experience, and Google would rather hear about the change immediately than discover it on the next crawl.

So the API exists to solve a freshness problem for high-churn content, not a discovery problem for ordinary pages. A jobs board turning over thousands of listings a week is the intended user. A blog publishing twice a month is not.

Why It Will Not Index Your Blog Posts

You will find plenty of guides suggesting the API works for any URL, and people who report that it seemed to help. Treat those claims carefully. Google’s documented support is limited to the two types above, and behaviour outside a documented contract can change without notice and is not something to build a process on.

There is also a more practical objection. If your pages are not being indexed, notification speed is almost never the constraint. Google has usually already seen the URL and decided not to index it. That is a judgement about the page, and the common causes are:

• Thin or duplicated content that does not justify a separate index entry — see thin content and duplicate content.
• Crawl or directive problems: a stray noindex, a robots.txt block, or a canonical pointing elsewhere.
• Pages Google has explicitly parked as crawled — currently not indexed or discovered — currently not indexed.
• Weak internal linking, so the page looks unimportant relative to the rest of the site.

None of those are fixed by telling Google about the URL faster. Working through why pages are not indexed is the productive route.

How to Set It Up

If you do have JobPosting or BroadcastEvent pages, the setup is straightforward but has one step people consistently miss.

1. Create a Google Cloud project and enable the API

In the Google Cloud console, create a project (or reuse one) and enable the Indexing API on it from the API library.

2. Create a service account and download its key

Create a service account under that project and generate a JSON key. That file is a credential — keep it out of your repository and out of client-side code. Anyone holding it can submit on your behalf.

3. Add the service account as an owner in Search Console

This is the step that trips everyone up. Take the service account’s email address — it looks like name@project-id.iam.gserviceaccount.com — and add it as an owner of your property in Search Console, under Settings, Users and permissions. Not a full user. Owner.

Skip this and every call returns a permission error even though your credentials are perfectly valid, which is a genuinely confusing failure mode because nothing about the error points at Search Console.

4. Send a request

Publish notifications go to the urlNotifications:publish endpoint with an OAuth token derived from your service account key:

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

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

The two accepted values for type are URL_UPDATED, for a new or changed page, and URL_DELETED, for one that has been removed. Send URL_DELETED when a job closes — that is the case the API handles best, and the one most implementations forget to wire up.

You can also check what you last submitted for a URL through the urlNotifications/metadata endpoint, which is useful for debugging whether a submission actually landed.

Quota and Batching

New projects start with a default publishing quota of 200 requests per day. If you run a large jobs board that is genuinely restrictive, and you can request an increase through the API console.

Batch requests let you bundle up to 100 calls into a single HTTP request, which helps you stay within rate limits and reduces overhead. It does not multiply your allowance — each URL still counts against the daily quota.

One practical note: submitting the same unchanged URL repeatedly is wasted quota at best. Trigger submissions from an actual content change event, not from a scheduled job that re-sends everything.

What to Use Instead

For ordinary pages, three mechanisms do the work the Indexing API is often wrongly expected to do.

A clean XML sitemap. This remains Google’s canonical inventory of what exists on your site. If it contains errors, non-canonical URLs or blocked pages, that is a real indexing problem — and unlike the Indexing API, it is one you can actually fix. Our XML sitemap guide covers what belongs in one.

Request Indexing in Search Console. The URL Inspection tool’s manual button works for any page type. It is one URL at a time with a daily limit, so it suits the occasional genuinely important page rather than bulk work.

IndexNow, for the other engines. Google does not participate, but Bing and Yandex do, it works for any page type, and it takes an afternoon to implement. See IndexNow for the protocol and how it sits alongside your sitemap.

The Honest Summary

The Google Indexing API is a narrow, well-designed tool for two specific content types with a genuine freshness problem. If you run a jobs board or stream live events, set it up — it does what it says, and the URL_DELETED path alone is worth the effort.

If you are looking at it because your pages are not getting indexed, it is not the answer, and building it will cost you a day and change nothing. The reason those pages are not indexed is on the page or in your sitemap, and that is where the fix is too.

Frequently Asked Questions