Google Indexing API: who it is actually for, and what to use instead
The Google Indexing API accepts two page types — job postings and livestream broadcast events — and nothing else. Here is the eligibility test, the quota, why plugins say otherwise, and the three routes that are open to every other kind of page.
The Google Indexing API accepts two kinds of page and refuses everything else. Google's own quickstart states the rule in one sentence: it "can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject". If your pages are articles, products, category listings or documentation, this API is not a faster route for them, and no plugin changes that. Three other routes do work, and they are listed below.
Before you start
This chapter is the boundary version of a thing the handbook already covers as a procedure. The ordinary publishing routine — sitemap, request indexing, push to the other engines — is in get your page indexed faster, and the realistic waiting times are in how long does it take to get indexed. Read this one when someone on the team asks why you are not using the API that a WordPress plugin advertises.
What the Google Indexing API is for
Two page types, both short-lived by nature. A job posting expires when the role is filled; a livestream event page is worthless the day after the stream. Both are cases where the gap between publishing and crawling destroys the value of the page, which is the problem this API exists to solve.
The quickstart is unusually direct about the limit and about what to do instead: "However, we still recommend submitting a sitemap for coverage of your entire site." Read those two sentences together and the shape is clear — the API is a narrow supplement, and the sitemap remains the general mechanism (Indexing API quickstart, read 2026-09-02).
Read the second type carefully, because it is narrower than it looks. The wording is BroadcastEvent embedded in a VideoObject — a page about a scheduled live broadcast, marked up as such. An ordinary video page does not qualify, and neither does an event page with no stream attached. Two of the three words in that phrase are doing work.
It supports three operations, and the third one is the one people forget exists.
| Operation | What it does |
|---|---|
| Update a URL | Tells Google a page is new or has changed |
| Remove a URL | Tells Google the page is gone |
| Get the status of a request | Returns your notification history for a URL |
Access is not open by default either. Google states that the API "provides a default 200 quota for API onboarding and submission testing, and it requires additional approval for usage and resource provisioning". A default quota sized for testing is a strong hint about who the API was built for.
An API with an eligibility rule is not a shortcut with a queue. It is a different door, and yours may not open with that key.
Why so many tools say otherwise
Because the endpoint does not check your page type at submission time. You can POST any URL to it and receive a response, and that response looks like success. Nothing in the immediate reply says "this page was ineligible", so a plugin author can build a feature, watch it return 200, and ship it in good faith.
Google addresses the outcome rather than the mechanics: "All submissions through the Indexing API undergo rigorous spam detection. 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." That sentence covers deliberate abuse of quota. It does not describe what happens to one ordinary blog URL submitted once, and we have not tested it, so treat the risk as undefined rather than as zero.
The more reliable objection is simpler. A mechanism whose eligibility rule you do not meet cannot be the reason anything improves, so any speed-up you observe after installing such a plugin came from something else — usually the sitemap it also started updating.
Do it: the eligibility test
Three steps, each with a finish line you can check today.
- Look for the two types in your delivered HTML with the command below. Finish line: a count for each type across a representative page of every template you publish.
- If both counts are zero everywhere, stop here and use the routes in the table below. Finish line: a decision written down, so nobody re-opens it in three months.
- If you do publish job postings or livestream pages, request access and keep the API for those templates only. Finish line: the integration is wired to one template, not to your publish hook.
# Do these pages carry either eligible type?
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/page > page.html
grep -c '"@type" *: *"JobPosting"' page.html
grep -c '"@type" *: *"BroadcastEvent"' page.htmlDeliverable: the eligibility table and the three routes that work
First, which pages qualify. The left column is what you publish; the right column is the honest answer.
| Page type | Indexing API? | Use instead |
|---|---|---|
Job posting with JobPosting | Yes | — |
Livestream page with BroadcastEvent in a VideoObject | Yes | — |
| Blog post, guide, documentation | No | Sitemap, then URL Inspection for the one that matters |
| Product or category page | No | Sitemap with accurate lastmod |
| Event page without a livestream | No | Sitemap |
| Deleted page | No | Return 404 or 410, let it drop out |
Second, the three routes that are open to everyone. Each has a documented behaviour and a documented limit, and none of them is instant.
| Route | Best for | Documented limit |
|---|---|---|
Sitemap with accurate lastmod | Everything, always on | Discovery, not a promise of crawling |
| URL Inspection request indexing | One page you care about today | Has a quota; repeat requests do not speed it up |
| IndexNow | Bing and Yandex | A different network from Google's |
Google's guidance on the middle route is worth quoting because it removes two common hopes at once: "Keep in mind that there's a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won't get it crawled any faster", and "Requesting a crawl does not guarantee that inclusion in search results will happen instantly or even at all" (Ask Google to recrawl your URLs, read 2026-09-02). The same page gives the expected wait as "anywhere from a few days to a few weeks", and directs anyone with volume back to the sitemap: "If you have large numbers of URLs, submit a sitemap."
The third route is a separate system with its own setup, covered in IndexNow setup. It reaches Bing and Yandex. It is not a way into Google, and any tool that presents one button as "push to all search engines" is describing two different networks as one.
Three ways this goes wrong
The expensive one is wiring the API into your general publish hook because a tutorial showed it working. Every post you publish then goes to an endpoint that has no use for it, your service account accumulates a submission history full of ineligible URLs, and the sitemap work that would have helped never gets done.
The second is reading the 200 response as confirmation. The reply tells you the request was accepted and parsed. It does not tell you the URL was eligible, and it does not tell you anything about crawling — those are separate questions that this endpoint was never designed to answer.
There is a version of the first mistake that costs more than time. A site that publishes job listings alongside ordinary content sometimes wires the API at the site level rather than the template level, so every article goes out through the same pipe as the listings. The listings were the eligible half, and now the submission history is mostly pages that were not. Wire it to the template.
The third is treating the 200-per-day default as the ceiling to optimise against. That quota exists for onboarding and testing; a real job board applies for more. Building a queue and a rate limiter around the test allocation is effort spent on the wrong number.
Where this stops
Two limits, and both matter more than the procedure above.
We do not know what submitting an ineligible URL actually costs. Google documents spam detection and the possibility of access being revoked for quota abuse, and says nothing about a single mistaken submission. We have not run that experiment and will not report a number we do not have. The reason to stop is that the mechanism does not apply to your pages, which is a sufficient reason on its own.
None of the three working routes makes indexing happen. They make discovery happen sooner. Whether Google then indexes the page depends on the page, and if it never gets crawled at all the problem is usually further upstream — reachability, not notification. Before optimising a notification pipeline, confirm an engine can fetch and read the page with the QueryWin gap check.
Common questions
Can I use the Google Indexing API for blog posts?
No. The documented rule limits it to pages carrying JobPosting or BroadcastEvent embedded in a VideoObject, and a blog post carries neither. Submitting one is not blocked at the endpoint, which is why the belief persists.
What is the Indexing API quota?
Google describes "a default 200 quota for API onboarding and submission testing", with more requiring approval. Read that as an allocation for building the integration rather than as a daily publishing budget.
Do the WordPress Indexing API plugins work?
They send the request successfully. Whether the request does anything for a page type outside the documented scope is a different question, and the documentation answers it: the API can only be used for those two types.
What is the fastest legitimate way to get a page crawled?
An accurate sitemap for everything, plus URL Inspection for the single page you care about right now. Google's own estimate for the wait is a few days to a few weeks, and repeat submissions of the same URL do not shorten it.
Does IndexNow submit to Google?
IndexNow reaches Bing and Yandex, which is a different network. It is worth doing for those engines on its own merits, and it does not replace anything in this chapter.
Part of the QueryWin handbook · Level 3
