URL Indexing API and MCP Server

The URL indexing API creates a batch with POST /api/v1/submissions. One request carries up to 10,000 URLs for one property, with an optional batch name and an optional priority. Every URL in the batch then goes to three channels: the Google Indexing API, the Search Console URL Inspection API and IndexNow for Bing.

curl -X POST https://searchanalysis.io/api/v1/submissions \
  -H "Authorization: Bearer $SEARCHANALYSIS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: deploy-2026-10-06-001" \
  -d '{
    "propertyId": "YOUR_PROPERTY_ID",
    "urls": [
      "https://example.com/blog/new-post",
      "https://example.com/blog/updated-guide"
    ],
    "name": "Deploy 2026-10-06",
    "priority": "HIGH"
  }'

Retry Safely With Idempotency-Key

Send an Idempotency-Key header with a value unique to this publish, like your build number. When a timeout makes your job retry, the same key returns the original batch instead of creating a duplicate. Your CI step stays safe to rerun, and a CMS webhook that fires twice for one save creates one batch when both calls carry the same key.

What the Response Contains

The response describes the batch you created, including its batchId. Pass that id to GET /api/v1/submissions/{batchId} to read progress.

What Gets Filtered

URLs outside the site's domain, duplicates and invalid formats show Dropped and are never sent. A URL already actively tracked on your account inside 30 days is skipped and reported. URLs over the day's Google Indexing API submission quota wait for the next UTC window and keep their place in line. Priority decides who goes first inside your own queue, so a HIGH product launch leaves ahead of a LOW archive refresh.

The URL indexing API lists your batches with GET /api/v1/submissions. Every submission on SearchAnalysis.io becomes a batch with its own page, an optional name and a source, so this endpoint is the index of everything your account has sent, from any of the six ways to submit.

curl https://searchanalysis.io/api/v1/submissions \
  -H "Authorization: Bearer $SEARCHANALYSIS_API_KEY"

Batch Sources

Uses in a Pipeline

• Find the batch your last deploy created by its name, then read its detail.
• Audit what sitemap monitoring auto-submitted, using the scheduled scan source.
• Review batches an AI agent created through the MCP server.
• Feed a dashboard of your own with batch names and sources.

Naming batches pays off here. A name like the release tag or the CMS post slug turns this list into a readable log of your publishing. The name is optional on the POST, and a batch without one still appears with its source.

This endpoint returns batches, not URL rows. For the state of each URL inside a batch, call the batch detail endpoint with its batchId. In the app, a batch page lists its URLs 100 per page, and the Monitor shows every URL across batches with filters for All, Indexed, Pending and Failed.

The URL indexing API returns one batch, with per-URL and per-channel state, from GET /api/v1/submissions/{batchId}. This is the endpoint your pipeline polls to learn what Google confirmed.

curl https://searchanalysis.io/api/v1/submissions/BATCH_ID \
  -H "Authorization: Bearer $SEARCHANALYSIS_API_KEY"

Three Channels per URL

• GOOGLE_INDEXING: a URL_UPDATED notification. Google's HTTP 2xx shows as Processing, never Indexed.
• GOOGLE_SEARCH_CONSOLE: the URL Inspection API. This row carries the confirmation and is the only one that turns Indexed.
• BING: an IndexNow notification. Accepted shows as Processing.

States and Their Labels in the App

Polling on the Ladder

Inspections follow a fixed ladder: about 10 minutes after submission, then +15 minutes, +1 hour, +6 hours and every 24 hours, up to 6 checks across about 3 days. Polling the Search Console row faster than the ladder returns the same state. After the ladder, a daily fallback keeps checking unconfirmed URLs. A Failed row carries its error text, and transactional email covers the two outcomes a person cares about: "Indexed: <url>" when a URL is confirmed and "Submission failed: <url>" with the error. The Google index checker page covers the verdict fields behind the Indexed state.

The URL indexing API lists the sites on your account with GET /api/v1/properties. A property is a site you added and connected, and its id is the propertyId every POST needs. Without a valid id, a submission has no site to belong to.

curl https://searchanalysis.io/api/v1/properties \
  -H "Authorization: Bearer $SEARCHANALYSIS_API_KEY"

How a Property Gets Set Up

1. Add the site in SearchAnalysis.io.
2. Connect Google with OAuth. Tokens are encrypted at rest with AES-256-GCM and decrypted only in memory at call time.
3. Pick the matching Search Console property: a domain property (sc-domain:) or a URL-prefix property. Inspections run against this property.
4. Host the 32-character hex IndexNow key SearchAnalysis.io generates at https://yourdomain/{key}.txt. The product fetches it and checks the contents match before it sends IndexNow notifications.

Why the Property Matters

The property sets the boundaries of a batch. URLs outside the site's domain are Dropped before sending. URL Inspection quotas count per property: 2,000 inspections a day and 600 a minute. The IndexNow budget of 10,000 URLs a day counts per property too.

Call this endpoint once when you configure a job, store the id, and send it with each POST. An agency running many client sites maps each site to its own id, and each site keeps its own inspection quota, so one large client does not use up another client's inspections. The IndexNow submission page covers the key file step in full.

The URL indexing API reports remaining engine quota from GET /api/v1/quota. SearchAnalysis.io respects each engine's quota and never fights it, so this endpoint tells you how much of today's capacity is left before you send a large batch.

curl https://searchanalysis.io/api/v1/quota \
  -H "Authorization: Bearer $SEARCHANALYSIS_API_KEY"

When to Call It

• Before a migration or a catalog launch, to see how much of the day is left.
• In a dashboard, next to your own publish counts.
• After a large POST, to confirm the queue is working through the batch.
• Inside an agent, through the matching MCP tool get_quota, which accepts a property scope.

The Google Indexing API quota is the tightest of the three and it is shared across the whole Google Cloud project. Google notes that "The quota may increase or decrease based on the document quality." Google's other Indexing API limits are 180 getMetadata requests a minute and 380 requests a minute across endpoints. The Google Indexing API submission page explains how the queue spends the daily quota, with priority deciding order inside your own queue.

The URL indexing MCP server starts most conversations with list_properties. The tool returns the sites on your account, each with the property id that submit_urls needs. It covers the same ground as GET /api/v1/properties for an AI client.

Add the Server to Claude Code

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

The server is remote, at https://searchanalysis.io/mcp, and it authenticates with a bearer API key you create in Settings. Other MCP clients that support remote HTTP servers point at the same address.

Inputs

None to supply. The tool reads the properties tied to your API key, and each one maps to a Search Console property: a domain property (sc-domain:) or a URL-prefix property.

Example Prompts

• "List my SearchAnalysis.io properties and show the id for example.com."
• "Which of my sites are connected to SearchAnalysis.io?"

An agent that manages several client sites calls this tool first, matches the domain in your request to a property, and carries that id into the submission. A person never has to copy an id by hand. If a site is missing from the list, add and connect it in the app: connect Google with OAuth, pick the Search Console property and verify the IndexNow key file. The llms.txt for AI agents file lists the machine endpoints an agent can read before it calls any tool.

The URL indexing MCP server submits URLs with submit_urls. The tool creates a batch, sends every URL to the Google Indexing API, the URL Inspection API and IndexNow, and returns a batchId you pass to check_submission. It does the same work as POST /api/v1/submissions, with the AI client filling in the inputs from your request.

Example Prompts

• "Submit these three URLs to SearchAnalysis.io for example.com with high priority and name the batch October launch."
• "Send every URL in the list I pasted above to SearchAnalysis.io for the docs site."

Rules the Tool Follows

• URLs outside the site's domain, duplicates and invalid formats are Dropped.
• A URL already actively tracked on your account inside 30 days is skipped and reported.
• URLs over the day's Google Indexing API quota wait for the next UTC window.
• The batch shows the source MCP on its batch page.

An agent that writes and publishes pages, then calls submit_urls with the new addresses, closes the loop between writing and indexing. The IndexNow submission channel carries the same URLs to Bing in the same call, and IndexNow engines share what they receive with the other participating engines, including Yandex, Seznam, Naver and Yep.

The URL indexing MCP server lists your batches with list_submissions, the tool counterpart of GET /api/v1/submissions. Each batch carries its name and its source: web, API, MCP or scheduled scan.

Inputs

None needed for a basic call. The AI client reads the list and filters or summarizes it for you in the conversation, so a question like the ones below needs no extra syntax from you.

Example Prompts

• "Show my recent SearchAnalysis.io batches and their names."
• "Which batches came from the scheduled scan this week?"
• "Find the batch named October launch and give me its batch id."

Where It Fits in a Conversation

This tool answers the question an agent asks when it lacks a batchId: which batch am I looking for? An agent in a new conversation does not have earlier batch ids, so the list is where it looks them up. A person who submitted URLs from the web app yesterday asks the agent today, and the agent finds the batch here, then passes its id to check_submission.

Batches tagged scheduled scan come from sitemap monitoring auto-submit, which scans every 6 hours and submits newly discovered URLs. Listing them is a quick way to ask an agent what your sitemaps sent this week without opening the app.

Clear batch names make this tool more useful. Give each submission a name your agent can match, like a release tag or a campaign name. A batch without a name still lists with its source.

The URL indexing MCP server reports a batch's progress with check_submission. The tool takes the batchId that submit_urls returned and returns each URL with its per-channel state, the same data as GET /api/v1/submissions/{batchId}.

Input

The batchId returned by submit_urls, or one found with list_submissions.

Example Prompts

• "Check the batch you just submitted and tell me which URLs are indexed."
• "Which URLs in batch October launch failed, and what was the error?"
• "Summarize the batch from this morning's deploy by channel."

Reading the Answer

Ask an agent too early and most rows show Processing, because Google has not answered the first inspection yet. The first inspection runs about 10 minutes after submission and the ladder continues for about 3 days, so a check an hour later gives a fuller answer. A Failed row carries its error text, and the Monitor in the app offers bulk retry. Transient Google errors (429, 5xx or network) retry after 30 minutes on their own, so a brief outage clears without a prompt from you. The Google index checker page explains the inspection that turns a row Indexed.

The URL indexing MCP server checks one page with check_url_index_status. The tool takes the exact URL and returns the index status SearchAnalysis.io holds for it from URL Inspection.

Input

The exact URL. Pass it the way you submitted it, with the same protocol, host and path, so the tool matches the tracked URL. A redirect source and its destination are two different URLs, and Google indexes the destination.

Example Prompts

• "Is https://example.com/pricing indexed in Google according to SearchAnalysis.io?"
• "Check the index status of the post I published this morning."

What Sits Behind the Status

Every inspection SearchAnalysis.io runs stores Google's health snapshot: verdict, coverageState, robotsTxtState, indexing state, the Google-selected canonical and the last crawl time. A URL counts as Indexed when the verdict is PASS or the coverage state says indexed.

After a URL turns Indexed it is inspected again every 7 days for as long as the site is connected. If a recheck finds it not indexed, the status turns amber Not indexed, a deindex event that deindex monitoring tracks across the site.

For a URL that was never submitted, start with the free indexability checker, which tests status, redirects, robots.txt, directives, canonical and content without sign-up. It states plainly that it cannot tell whether a page is in Google, which is the job of URL Inspection on a verified property.

The URL indexing MCP server reports remaining engine quota with get_quota, the tool counterpart of GET /api/v1/quota. The call accepts an optional property scope, so one call answers for one site or for the whole account.

Inputs

An optional property id from list_properties. Leave it out for the account view, or pass it to see one site. The Google Indexing API figure is shared across the whole Google Cloud project, while URL Inspection and IndexNow figures count per property.

Example Prompts

• "How much SearchAnalysis.io quota is left today?"
• "Before you submit, check the quota for example.com."

Limits the Tool Reports Against

A careful agent calls get_quota before a large submit_urls. URLs over the day's quota still enter the batch: they wait for the next UTC window and keep their place in line, so the check is for planning. The Google Indexing API submission page explains why that quota is the tightest of the three.

Quota windows reset in UTC, so a submission late in your local evening may land in the next window. Drip-feed submission, paced over a number of days, is PLANNED and will give agents a way to spread a large list on purpose.