Google Indexing API Submission With Confirmed Results

The Indexing API's documented scope fits in one sentence on Google's quota and pricing page: "The Indexing API can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject." That sentence names two structured data types. Every other kind of page sits outside the scope Google writes down.

What the Scope Means for Your URLs

• A page with JobPosting structured data matches the documented scope. SearchAnalysis.io labels it Eligible.
• A page with BroadcastEvent structured data matches the documented scope too, and it gets the same Eligible label.
• A blog post, product page or landing page without either type falls outside the documented scope. SearchAnalysis.io labels it Best-effort and the submission proceeds best-effort.
• A page the product could not read gets Unknown, and the label says exactly that.

Why Best-effort URLs Still Go Out

Most content sites carry no JobPosting or BroadcastEvent markup, so Best-effort is the normal label for them. SearchAnalysis.io sends the URL_UPDATED notification, shows the label beside the URL, and leaves the outcome to Google. You see the documented scope next to every URL you send, and you decide with that in view.

The confirmation comes from a separate channel. The Google index checker inspects the URL through Search Console and turns it Indexed only on a PASS verdict or an indexed coverage state. A Best-effort URL that Google indexes turns green the same way an Eligible one does.

The Google Indexing API sets a default quota of 200 publish requests per day per Google Cloud project. Both URL_UPDATED and URL_DELETED notifications count as publish requests. The quota belongs to the project, so every site that sends through the same project draws from the same 200.

How SearchAnalysis.io Spends the Quota

1. Workers take URLs from your queue in priority order: High first, then Normal, then Low.
2. Each URL sent to Google uses one publish request from the project's 200.
3. When the day's quota is spent, the remaining URLs stay Queued and wait for the next UTC window.
4. In the next window they go out in the same order, so a URL keeps its place in line.

SearchAnalysis.io respects the quota and never fights it. When the count reaches 200, sending stops for the day. A waiting URL shows Queued, the label for a URL that was received and is waiting for a worker.

You can read the remaining quota at any time. The REST API returns it from GET /api/v1/quota, and the MCP tool get_quota returns the same figures to an AI agent. The SearchAnalysis.io developer documentation describes both, and the public OpenAPI document lists the endpoint.

A list of 1,000 URLs on an idle project takes at least 5 UTC days of Indexing API quota, while the Search Console and IndexNow rows run on their own limits.

An Indexing API batch request groups up to 100 URL notifications into one HTTP call. Batching cuts round trips between the sender and Google. Each notification inside the batch is still its own publish request, so a full batch of 100 uses half of the default daily quota.

Two meanings of the word batch meet here. Your submission in SearchAnalysis.io becomes a batch with its own page, an optional name and a source: web, API, MCP or scheduled scan. That batch holds up to 10,000 URLs. The Google batch request is the smaller unit the workers send, at most 100 URLs at a time and never past the day's quota.

A 10,000-URL batch in SearchAnalysis.io turns into many Google batch requests spread over many UTC days.

Retries Without Duplicates

Batches created through the submission REST API accept an Idempotency-Key header. A retry with the same key returns the original batch instead of creating a duplicate. That protects your quota when a CI job or an agent retries after a timeout. GET /api/v1/submissions/{batchId} returns the batch with per-URL, per-channel state.

The Google Indexing API accepts two notification types, and both count against the daily publish quota. URL_UPDATED reports a new or changed URL. URL_DELETED reports a URL that was removed.

Why SearchAnalysis.io Sends URL_UPDATED

Submission exists to get pages crawled and indexed, so each URL you add goes out as one URL_UPDATED notification on the GOOGLE_INDEXING channel. The same URL gets two more status rows: GOOGLE_SEARCH_CONSOLE for the URL Inspection confirmation, and BING for an IndexNow notification.

Duplicates and Filtered URLs

A URL already tracked on your account inside 30 days is skipped and reported, and it is not resent. That 30-day dedup keeps repeat pastes from spending quota twice on one page. URLs filtered out before sending show as Dropped, with the reason: a URL outside the site's domain, a duplicate, or an invalid format.

Pages That Leave Your Site

When a page drops out of your sitemap, sitemap monitoring marks it Removed in the page inventory and keeps its first seen and last seen dates. For URLs that were Indexed, the 7-day recheck keeps inspecting them, so a later not-indexed result shows up as an amber Not indexed deindex event.

The Google Indexing API has a read call next to its publish call. getMetadata returns what Google holds about the notifications sent for a URL, and it runs under its own per-minute limit. Google's quota page lists the defaults per project.

These per-minute limits sit beside the daily publish quota of 200. A project can read notification metadata far more often than it can publish new notifications, and the URL Inspection API has separate limits again.

Where SearchAnalysis.io Gets Index Status

SearchAnalysis.io treats no Indexing API response as proof of indexing. For index status it calls the Search Console URL Inspection API, which returns a verdict, a coverageState, a robotsTxtState, the indexing state, the Google-selected canonical and the last crawl time. Those fields are stored with every inspection.

• URL Inspection allows 2,000 inspections a day per property (site).
• URL Inspection allows 600 inspections a minute per property.
• Per project, Google allows 10,000,000 inspections a day and 15,000 a minute.
• Transient errors (429, 5xx, network) retry after 30 minutes.

Each inspection becomes a row in the URL's check history with its time, its state (INDEXED, NOT_INDEXED or ERROR), its coverage state and its source. The Google index checker shows that history on the URL detail page.

More Indexing API quota is Google's decision. The default is 200 publish requests a day per project, and Google's quota page states: "The quota may increase or decrease based on the document quality." The number can move in either direction, and Google is the one who moves it.

What Changes the Number

• Google sets the default of 200 publish requests per day per project.
• Google states the quota follows document quality, up or down.
• Adding sites to the same project adds no quota, because the 200 is shared across the whole project.
• SearchAnalysis.io cannot raise your quota. It reads what is left and plans the queue around it.

Getting More From the Quota You Have

1. Mark the pages that matter most as High priority so they go out first.
2. Let the 30-day dedup skip URLs you already sent.
3. Check the eligibility label: Eligible pages match Google's documented scope.
4. Send Bing traffic through IndexNow submission, which runs on a separate budget of 10,000 URLs a day per property.

Drip-feed submission is PLANNED. It will spread a batch over a number of days you choose. Today, the queue sends what the quota allows and holds the rest for the next UTC window.

Your scripts can watch the remaining quota through GET /api/v1/quota in the SearchAnalysis.io developer documentation, and an AI agent can ask the MCP tool get_quota.

An accepted Indexing API notification is an HTTP 2xx response from Google. It means Google received the URL_UPDATED notification. It does not confirm a crawl, and it does not confirm indexing. SearchAnalysis.io shows it as Processing with the note "ping accepted", and it never shows it as Indexed. The note tells you the ping arrived and nothing beyond that.

GOOGLE_INDEXING        Queued > Sending > Processing (ping accepted)
GOOGLE_SEARCH_CONSOLE  Queued > Sending > Processing > Indexed (verdict PASS)
BING                   Queued > Sending > Processing (accepted)

Green means verified and nothing else. Only the GOOGLE_SEARCH_CONSOLE row can turn green, and it does so when the URL Inspection verdict is PASS or the coverage state says indexed. At that moment SearchAnalysis.io sends a transactional email with the subject "Indexed: <url>". A failed send produces a "Submission failed: <url>" email with the error.

After a URL turns Indexed, it is inspected again every 7 days for as long as the site is connected. A later not-indexed result shows amber Not indexed, which deindex monitoring treats as a deindex event.

SearchAnalysis.io reaches the Google Indexing API and the Search Console URL Inspection API through Google OAuth. You add a site, connect Google with OAuth, and pick the matching Search Console property. Inspections need a verified property, so the property you pick is the one the confirmation comes from.

Property Types You Can Pick

• A domain property, written as sc-domain: followed by your domain.
• A URL-prefix property, written as the full address it starts with.

How Google Tokens Are Stored

API keys for the SearchAnalysis.io REST API are separate from Google OAuth. You create bearer API keys in Settings. Your scripts, CI jobs and AI agents use those keys to submit URLs, and they never hold your Google tokens.

The remote MCP server at https://searchanalysis.io/mcp takes the same bearer API key. In Claude Code, you add it with one command and get six tools: list_properties, submit_urls, list_submissions, check_submission, check_url_index_status and get_quota.

claude mcp add --transport http searchanalysis https://searchanalysis.io/mcp

The SearchAnalysis.io privacy policy and terms of service describe how account data is handled.

Eligible is the Indexing API label SearchAnalysis.io gives a URL when its page HTML contains JobPosting or BroadcastEvent structured data. Those are the two types Google names in the Indexing API's documented scope, so an Eligible URL is the kind of page Google writes the API for.

What the Product Reads

• The HTML of the page at the submitted URL.
• The structured data inside that HTML.
• A JobPosting type, or a BroadcastEvent type.
• Finding either one sets the label to Eligible.

What Eligible Tells You

An Eligible URL matches Google's documented scope. Google still decides what it crawls and indexes, so an Eligible URL follows the same path as every other URL: Queued, Sending, Processing, and Indexed only after a URL Inspection PASS.

When your queue is longer than the day's quota, Eligible URLs are good candidates for High priority. They match the scope Google documents, and the 200 daily publish requests are shared across the project. The label sits on the URL detail page next to the per-channel status and the latest verdict fields from the Google index checker.

If an Eligible page later drops out of the index, the 7-day recheck shows it as amber Not indexed, the same way it treats any other URL. The label never changes how a URL is confirmed.

Best-effort is the Indexing API label for a URL whose page HTML has no JobPosting or BroadcastEvent structured data. It is the normal label for most content sites: blogs, documentation, product pages and landing pages. Submission proceeds best-effort, which means the URL_UPDATED notification goes out and Google decides what happens next.

What to Do With Best-effort URLs

1. Leave them in the queue. The label describes the page and records the documented scope beside it.
2. Keep your sitemap current. Sitemap monitoring scans every 6 hours and can submit new URLs on its own.
3. Watch the Search Console row. A PASS verdict turns the URL Indexed whatever its eligibility label says.
4. Check pages that stay unconfirmed with the free indexability checker for blocks, redirects or thin content.

A URL that stays not indexed after the confirmation ladder keeps getting a daily fallback check. If Search Console reports "Crawled, currently not indexed", the guide to Crawled, currently not indexed covers what that reason means.

Best-effort does not change the status labels. The Google Indexing row still reads Processing once Google accepts the notification, and green still needs URL Inspection.

Unknown is the Indexing API label for a URL whose eligibility SearchAnalysis.io could not determine. The product tried to read the page HTML for JobPosting or BroadcastEvent structured data and did not get an answer either way. The label reports that plainly and does not guess Eligible or Best-effort.

Checks Worth Running on an Unknown URL

The free indexability checker fetches one public URL as SearchAnalysisBot/1.0 and runs six checks, with a 10-second fetch timeout and a 2 MB page cap:

1. Page loads: a non-2xx HTTP status fails.
2. Redirects: it follows up to 5, and Google indexes the destination, so submit the destination.
3. robots.txt: the Googlebot group wins over *, and the longest matching rule decides.
4. Indexing directives: noindex or none in meta robots or X-Robots-Tag.
5. Canonical: self-referencing passes, and pointing elsewhere or missing warns.
6. Content: under about 100 words of visible text warns as thin.

Where the Answer Comes From

Eligibility and index status are separate. Whatever the label, the GOOGLE_SEARCH_CONSOLE row inspects the URL on its schedule and turns it Indexed on a PASS verdict. If the inspection reports a fetch problem, the stored coverageState and robotsTxtState explain it in Google's own words.

The indexability checker cannot tell whether a page is in Google. That needs Search Console URL Inspection on a verified property, which is what joining the SearchAnalysis.io waitlist gets you access to.