Submit & index · Google Indexing API
Google Indexing API submission without the setup and quota headaches
The Google Indexing API is the right way to tell Google about new and changed pages, but using it directly means service accounts, JSON keys, quota limits and code you have to maintain. Most teams either never get it running or build a brittle script that breaks the next time something changes.
Submit · monitor coverage · official methods only
Ready to check coverage
Paste a sitemap to sweep every URL for index status, then submit the missing ones through the official Google Indexing API and Bing IndexNow.
Coverage
indexed
Avg time to index
URLs submitted
Now eligible
Live, interactive · sample data · official methods only
Official Google Indexing API · Bing IndexNow · verified sitemaps · no spam, no PBNs
In short
The Google Indexing API lets you notify Google directly when a page is added or removed so it can crawl it quickly. Officially it supports two page types: pages with JobPosting structured data and pages with a BroadcastEvent embedded in a VideoObject. The default quota is 200 publish requests per day per project. For all other page types, the scalable ways to speed up indexing are XML sitemaps and the Search Console URL Inspection tool, not the Indexing API.
Last updated July 2026
Indexing gives you the full benefit of the Google Indexing API with none of the plumbing. Connect your property once and submit URLs in bulk, on publish or on a schedule, while we handle credentials, batching and quotas in the background. Submission is paired with monitoring, so you see which pages got crawled and indexed and which did not, with a reason. It is white-hat by design, official methods only, and we never claim to force indexing, because Google decides what to index.
Official methods only
White hat · no spam, no PBNs
Why it works
What your team gets with google indexing api
No credential wrangling
Connect once and we manage the service account, keys, batching and quotas, so you never touch a JSON file or hit a rate limit by surprise.
Bulk and scheduled
Submit thousands of URLs in one pass, or have new and updated pages submitted automatically the moment they change.
Submission with proof
Every API submission is tracked through to a crawl and index result, so you see outcomes instead of just firing requests.
What it handles
Submitted, monitored and fixed, automatically
Indexing submits your URLs through the official Google Indexing API, Bing IndexNow and clean XML sitemaps, watches coverage across both engines, and flags any page that drops out with a plain-English reason so you can resubmit and get it back.
- Submits URLs in bulk through the official Indexing API
- Handles credentials, batching and quota limits for you
- Auto-submits new and updated pages on publish
- Confirms which submissions led to indexing
- Stays entirely within approved, white-hat methods
Not indexed yet
/blog/seo-guide-2026 is discovered but not indexed
thin content signal, queued for re-crawl via the Indexing API
Why Indexing
One place to submit, monitor and fix coverage
Not a black-hat indexer that risks your site, not a free checker that only tells you the bad news. Indexing unifies official submission and live coverage monitoring, the white-hat way, across Google and Bing.
Submits the official way
Bulk-submit through the Google Indexing API, Bing IndexNow and clean XML sitemaps. We speed discovery and re-crawl using methods the engines support, never spam, PBNs or black-hat tricks.
Monitors coverage live
You do not refresh a search bar one URL at a time. Indexing watches which pages are in Google and Bing, catches anything that drops out, and tracks time-to-index across your whole site.
Diagnoses and resubmits
Every non-indexed page comes with a plain-English reason, then auto-resubmits through the official API so it gets another shot. Google still decides, but nothing waits in the dark.
At a glance
What the Google Indexing API can and cannot do
The facts that decide whether the API is the right tool for your pages, straight from Google's own documentation.
| Aspect | The reality | What it means for you |
|---|---|---|
| Supported page types | Officially JobPosting and BroadcastEvent in a VideoObject only | For general pages, sitemaps and URL Inspection are the right tools |
| Default quota | 200 publish requests per day, per project | Bulk work needs prioritisation, not brute force |
| What it does | Notifies Google to crawl or drop a URL quickly | It speeds discovery, it does not decide indexing |
| Credentials | A Google Cloud service account with a JSON key | The setup is where most direct integrations break |
| Bing equivalent | Google does not use IndexNow | Bing needs its own channel; the two do not overlap |
What the Indexing API is officially for
This is the part most guides skip, and it matters. Google's documentation is explicit that the Indexing API supports two things: pages with JobPosting structured data, and pages hosting a livestream with a BroadcastEvent embedded in a VideoObject. It was built for time-sensitive content where a URL appears and disappears fast, like a job that closes or a stream that ends. Using it for a normal blog post or product page is outside its stated scope.
The quota reflects that narrow purpose. The default is 200 publish requests per day per project, which is small on purpose. If you have seen a much larger per-minute figure quoted, that traces back to an error that lived in Google's own docs for a while. The honest read is that the Indexing API is a precise tool for a specific job, not a general bulk indexer for a whole site.
The honest way to speed indexing for ordinary pages
If your pages are not job postings or livestreams, the Indexing API is not your channel, and no reputable tool should pretend otherwise. The methods that actually move general pages are the ones Google points you to: a clean, current XML sitemap, strong internal links from pages that already get crawled, and the URL Inspection tool for priority URLs. These are slower than a direct API ping, but they are the approved path and they work.
That is exactly why this tool leans on all of the official channels together rather than overselling one API. Sitemaps and IndexNow carry the volume, the Indexing API handles the JobPosting and BroadcastEvent pages it is meant for, and the URL Inspection API confirms the results. Anyone promising instant indexing of arbitrary pages through the Indexing API is describing something Google does not support.
Why the setup is where teams give up
Even when the Indexing API is the right tool, using it directly is fiddly. You create a Google Cloud project, generate a service account, download and secure a JSON key, grant that account owner access to the property, then write and maintain code that batches requests and respects the quota. Every one of those steps is a place a do-it-yourself integration quietly breaks, usually months later when a key rotates or a permission changes.
The value of a managed setup is that the plumbing stops being your problem. You connect the property once, and the credentials, batching, quota handling and retries run in the background. You submit URLs and see results, without babysitting a script or getting surprised by a rate limit mid-launch.
Google Indexing API quotas, endpoint and what one request looks like
The API is smaller than its reputation. There is one endpoint that matters, it takes one kind of payload, and it does two things.
Every publish call goes to https://indexing.googleapis.com/v3/urlNotifications:publish, and Google requires the Content-Type header on those calls to be application/json. The body carries a URL and a notification type, and there are exactly two types: URL_UPDATED, meaning this page is new or has changed and should be crawled, and URL_DELETED, meaning it has been removed and should be dropped. That is the whole surface area. There is no method that asks Google whether a URL is indexed, and no method that forces indexing.
The quotas are the part people hit first and misread. Google documents a default of 200 publish requests per day per project, and a default of 380 requests per minute per project across all endpoints. The daily figure is the binding one for almost everybody, because 200 URLs a day is nothing on a large catalog and it is a project limit rather than a per-site limit, so several properties running through one Google Cloud project share it.
You can ask for more, but read what you are asking for. Google's quota page ties the request for additional quota to gaining approval to use the API for pages carrying JobPosting or BroadcastEvent markup. In other words the escape hatch from 200 a day exists for the two content types the API is officially for, which is the same restriction the rest of this page keeps coming back to.
Setup is where most teams stop. You create a Google Cloud project, enable the Indexing API on it, create a service account, download its JSON key, and then add that service account's email address as an owner of the property in Search Console. Miss the last step and every call returns a permission error that reads as though the API is broken, when in fact Google simply has no evidence you own the site.
- Endpoint: https://indexing.googleapis.com/v3/urlNotifications:publish
- Content-Type must be application/json
- Two notification types only: URL_UPDATED and URL_DELETED
- Default quota: 200 publish requests per day, per Cloud project
- Default rate: 380 requests per minute, per Cloud project
- More quota is tied to approval for JobPosting or BroadcastEvent pages
- The service account must be an owner of the property in Search Console
Indexing API, sitemap, or Search Console: which one for which job
These three get discussed as alternatives and they are not. They do different jobs, and choosing badly is why teams build an Indexing API integration and see nothing change.
A sitemap is the baseline and it is not optional. It is how Google learns that URLs exist at all, it covers your whole site rather than a handful of pages, it costs nothing to maintain once generated, and it is the only one of the three with no rate limit worth worrying about. Its weakness is that it is a hint. Listing a URL in a sitemap does not oblige Google to crawl it, and large sites routinely have thousands of sitemap URLs sitting undiscovered.
Search Console's URL Inspection tool with Request Indexing is the manual lane. It works on any page type, it is genuinely fast when it works, and it is capped at roughly ten to twelve URLs per property per day. That cap makes it a tool for individual priority pages, not a workflow.
The Indexing API is the fast lane with a narrow gate. It is genuinely quick, and Google documents it for pages with JobPosting or BroadcastEvent markup. Sending ordinary blog posts and product pages through it is widely done and Google has repeatedly said it is not what the API is for, which means it is not something to build a business process on.
The honest sequence for a normal site is therefore: a complete, clean sitemap as the foundation, real internal links so that discovered URLs also look worth crawling, Request Indexing by hand for the few pages that genuinely cannot wait, and the Indexing API only if you actually publish job postings or livestreams. Then monitor coverage, because none of the four guarantees anything and the only way to know is to check.
- Sitemap: whole-site discovery, no practical limit, a hint rather than a promise
- Request Indexing in Search Console: any page type, roughly 10 to 12 URLs a day
- Indexing API: fast, 200 a day by default, officially for JobPosting and BroadcastEvent
- Internal links: unlimited, free, and the signal that a discovered URL is worth crawling
- None of them forces indexing, so coverage monitoring is what closes the loop
Keep reading
- The Google Indexing API Explained: What It Can and Cannot Do The Google Indexing API explained: how it works, the page types it officially supports, its real limits, and how to use it correctly to speed up discovery and re-crawl.
- Link Indexer vs Google Indexing API: Which to Buy A link indexer works on URLs you do not own. Google documents the Indexing API only for JobPosting and BroadcastEvent pages. Most sites need neither.
- How Long Does Google Take to Index a Page? (2026 Data) How long does Google take to index a page? Real 2026 ranges from hours to weeks, what drives the time-to-index, and how to speed up discovery the white-hat way.
Good questions
Questions about google indexing api
Explore more
More ways teams get every page indexed
Stop guessing. Get every page indexed and keep it that way.
Bulk-submit your URLs through the official Google and Bing channels, monitor coverage, and resubmit anything that drops out, automatically. White hat only, so we speed discovery without ever guaranteeing what Google chooses to index.
Google Indexing API · Bing IndexNow · sitemaps · coverage monitoring · official methods only