What pages can you actually submit to Google Indexing API?

What most people get wrong about the Indexing API

The Google Indexing API sounds like a shortcut to faster crawling. Submit a URL, Google indexes it immediately. That is the pitch — and it is only half-true.

The Indexing API is not a general-purpose URL submission endpoint. It was built for a very specific use case, and Google enforces that restriction at the schema level. Submit the wrong type of URL, and your request silently passes — no error, no indexing, just wasted quota.

The two eligible content types

As of 2026, Google officially recognises exactly two structured data types that unlock Indexing API eligibility:

1. JobPosting — job listing pages that include a valid JobPosting JSON-LD schema
2. BroadcastEvent — live streaming event pages that include a valid BroadcastEvent JSON-LD schema wrapped inside a VideoObject

That is the complete list. No other structured data types confer Indexing API eligibility — not Product, not Article, not FAQPage. If the page does not have one of these two schema types implemented correctly, the Indexing API will not expedite indexing regardless of how many times you submit it.

JobPosting eligibility in detail

A page qualifies as a JobPosting submission target when it meets all of these conditions:

• The page HTML contains a <script type="application/ld+json"> block
• That block includes a schema with "@type": "JobPosting"
• The schema includes the required properties: title, description, datePosted, hiringOrganization, and at least one of jobLocation or applicantLocationRequirements
• The validThrough date has not passed (expired postings may be deprioritised)
• The canonical URL of the page matches the URL you are submitting

BroadcastEvent eligibility in detail

BroadcastEvent eligibility is stricter and more time-sensitive. The schema must:

• Use a VideoObject as the top-level type
• Include a publication property that references a BroadcastEvent object
• The BroadcastEvent must have isLiveBroadcast: true
• The startDate must be set (ISO 8601 format with timezone)
• The endDate should be set; without it, Google may not process the submission correctly

Because BroadcastEvent content is time-bounded, submissions should ideally happen 6–24 hours before the stream starts. Submitting too early (more than a few days out) or after the event ends reduces the likelihood that Google will process the request.

What happens when you submit an ineligible URL

Google's servers accept the request and return HTTP 200. The URL is added to an internal queue, but because it does not qualify for priority processing, it receives no special treatment. It will be crawled on Google's normal schedule — which might be days or weeks away depending on your site's crawl budget.

This is the most dangerous aspect of the Indexing API. The absence of an error creates a false sense of confidence. Teams submit hundreds of ineligible URLs, deplete their daily quota of 200 requests, and spend weeks wondering why indexing has not improved.

Your daily quota and how to protect it

The standard quota is 200 requests per day per Google Cloud project. You can request an increase through the Google Cloud Console, but approval is not guaranteed, and Google expects you to demonstrate that you are submitting only eligible content.

Quota resets at midnight Pacific time. If you submit 200 ineligible URLs before your eligible ones, those eligible pages get nothing. Protect your quota by running eligibility checks before any submission attempt.

The correct submission workflow

A robust Indexing API workflow looks like this:

1. Crawl the page and extract JSON-LD structured data
2. Check whether the schema type is JobPosting or BroadcastEvent
3. Validate required fields using Google's schema requirements
4. Verify the page canonical URL matches the submission URL
5. Confirm the page returns HTTP 200 and is not blocked by robots.txt or noindex
6. Only then call https://indexing.googleapis.com/v3/urlNotifications:publish

IndexPilot runs all of these checks automatically before a single API call is made. Each URL gets an eligibility verdict — Eligible (JobPosting), Eligible (BroadcastEvent), or Not eligible — so you only consume quota on URLs that will actually benefit from submission.