Google's Indexing API compliance: the real story on JobPosting and BroadcastEvent

Open the Google Indexing API documentation and you'll see this line near the top: "The Indexing API allows any site owner to directly notify Google when pages are added or removed. This allows Google to schedule pages for a fresh crawl, which can lead to higher quality user traffic. Currently, the Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent structured data."

And then everyone — every WordPress plugin, every SaaS indexer, every SEO agency workflow — uses it for blog posts, product pages, marketing pages, and landing pages. So what's actually going on?

What the API technically does

The Indexing API accepts any URL. It doesn't validate that the URL contains JobPosting or BroadcastEvent schema. It accepts the submission, returns a 200, and queues the URL. The validation, if any, happens later at the crawl/index stage.

What Google has actually said

Multiple Googlers — most recently John Mueller in 2025 — have publicly reiterated that the API is scoped to those two content types. The most quoted line: "We see a lot of spammers misuse the Indexing API like this, so I'd recommend just sticking to the documented and supported use-cases."

The Indexing API is for JobPosting and BroadcastEvent. For everything else, it's not officially supported. We don't issue penalties for using it on other content, but the behavior is not guaranteed.

What happens in practice for non-supported content

• Submission is accepted and queued — same as supported content.
• Google may de-prioritize the crawl signal if it detects the URL doesn't match the documented types.
• Some users report a noticeable bump in crawl speed even for blog posts and product pages.
• Other users report no measurable effect at all.
• Google reserves the right to ignore future submissions from accounts that bulk-misuse the API.

The honest framing

For non-JobPosting / non-BroadcastEvent content, the Indexing API is a strong crawl HINT, not an indexing command. It's the digital equivalent of waving at the crawler — Google often notices and sometimes doesn't. We surface this exact framing inside IndexerNow's dashboard so you're not surprised.

When to use it for non-supported content anyway

1. Your URL is in "Discovered, not indexed" and you want to move it up the crawl queue.
2. You've updated a page substantially and want Google to re-fetch.
3. You're launching a batch of new pages and want to compress the discovery window.
4. You're migrating URLs and want to flag the new ones aggressively.

When NOT to use it

• URL is thin / low-quality. The API call won't fix the underlying quality problem.
• URL is duplicated content. Google will pick a canonical regardless.
• URL is blocked by robots.txt or noindex. The crawl will fail.
• You've pushed the same URL 5+ times in a month. Google's making a verdict — pushing more doesn't override it.

When the API IS the right tool

If your content IS JobPosting or BroadcastEvent — actual job listings on a careers site, scheduled video content with broadcast events — the Indexing API is the canonical way to notify Google. Combine it with the relevant schema and you'll see crawls within minutes, not days. Job boards built on this stack often run 95%+ same-day indexing.

What we tell agency customers

Use the API liberally on real updates, sparingly on already-stable URLs, never on URLs you suspect are quality-limited. Track the recheck outcome — if a URL keeps coming back "Crawled, not indexed" after pushes, the URL is the problem, not the push. IndexerNow's per-batch recheck makes this loop visible.