IndexNow URL submission: setup, events and error handling

IndexNow tells participating search engines that a URL has been added, changed or deleted. Bing recommends it for automated notifications across participating engines. Bing’s submission guidance distinguishes this from its Bing-only submission options.

For an SEO team, the useful question is whether a published change produced the right notification and what happened afterwards. A green integration badge cannot answer that on its own. The developer needs an event, a verified host, a request and a response. The SEO lead needs evidence about the page that the search engine subsequently found.

Consider a hypothetical Barcelona business publishing service pages in Spanish, Catalan and English. Its editor corrects a service description, retires an outdated offer and publishes a translated page. Those changes need different follow-up checks, even if the same submission mechanism handles them. The aim is to keep a reliable record of changed public URLs without asking an editor to remember an extra task after every publication.

Define success before connecting the API

According to the protocol documentation, HTTP 200 confirms receipt; HTTP 202 means receipt with key validation pending. Neither status reports index inclusion. IndexNow’s response specification is the contract your submission log should follow.

Give the workflow separate milestones: change visible in production, notification received, crawl observed and index status checked. Assign an owner to the gaps. If the deployment succeeded but there is no notification, investigate the publishing integration. If the endpoint received the URL, move the investigation to discovery and the page itself. Repeating a successful request does not supply the missing evidence.

Bing explicitly says IndexNow guarantees neither crawling nor indexing. Its setup guide states that limit. Treat rankings, organic traffic and AI citations as separate outcomes too; none is a sensible acceptance criterion for a notification request.

Submission sharing applies to participating engines. Google is absent from the endpoint list in the official IndexNow FAQ. Do not describe an IndexNow receipt as a Google submission. Keep Google Search Console checks in their existing workflow, and keep the XML sitemap inventory maintained independently.

Choose one submission owner

First check whether your CMS, plugin or hosting setup already sends notifications. Bing’s setup directory lists supported integrations and recommends checking existing activity in Webmaster Tools. Prefer an existing integration if you can verify its events and diagnose its failures. Build a sender when you need control it cannot provide. This is a maintenance decision, so involve whoever will repair it when a release goes wrong.

Ask the person maintaining that integration to demonstrate a recent change. Which public URL did it send? Was the notification triggered by a saved draft, an editor pressing Publish or a completed deployment? Can you see removals? Who receives an alert if requests fail? These questions are more useful than comparing plugin screenshots.

For a static website, use the successful production release as the starting point. A file saved in a repository is still only an intended change. Build failures, release cancellations and deployment delays belong before notification. Send notifications only after the expected content or response is available on the public host.

Choose a named maintainer and record the chosen sender in the team’s operations notes. Before adding another plugin or deployment hook, review the existing submission workflow. If overlapping senders cannot be avoided, document which events each owns and how you will reconcile their logs. An unexplained increase in request volume should lead to an investigation, not a celebration.

Verify the host and key location

For manual setup, the FAQ specifies a key of 8–128 characters using letters, digits or hyphens. The key instructions also require public access without a login. Use a generated value for your site; the strings below are illustrative placeholders.

The root verification file is UTF-8 text named after the key with a .txt suffix, containing the key itself. IndexNow documents ownership verification through that file. For an example host, a proposed setup would be:

Host: www.example.com
Key: 61af7490d82b4e718093a420f96cbe25
File URL: https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt
File content: 61af7490d82b4e718093a420f96cbe25

Check the deployed file directly with an HTTP client. Inspect the body as well as the status: an application fallback can return a branded HTML page where you expected plain text. Test without an administrator session, and confirm that a firewall challenge or login screen has not replaced the response. Store the test evidence alongside the integration configuration.

An alternative file location requires keyLocation. A file beneath /catalog/ authorises that URL prefix, not unrelated /services/ pages. The protocol’s location rules make root placement the simpler choice for a whole-site sender.

This deserves attention on multilingual sites. Putting the key under an English folder because the developer happens to work there is an avoidable configuration mistake. Plan the verification scope before choosing a convenient directory. The same-host condition also means you should treat an apex domain and its www host deliberately, rather than assuming one file covers both.

Subdomains require their own verification files, according to the IndexNow FAQ. Keep a configuration record for each host you operate. Include the production host, key identifier, file URL, responsible team and last verification date. The publicly served verification file is expected; unrelated deployment credentials have no place in it.

During a future key change, coordinate the deployed file and sender configuration as one release. Test the new file before directing production requests to it. Retain enough information about the previous configuration to understand any older queued attempt, and ensure the worker uses the configuration you actually intend when it retries.

Send one representative request before a batch

The API supports a single URL through GET and a set through JSON POST, with up to 10,000 URLs per POST. The submission documentation defines those forms. For operational testing, begin with one real, recently changed public URL; do not start by exporting your entire site.

This illustrative POST body follows the documented fields. Replace the example host, key and URLs with values you control:

{
  "host": "www.example.com",
  "key": "61af7490d82b4e718093a420f96cbe25",
  "keyLocation": "https://www.example.com/61af7490d82b4e718093a420f96cbe25.txt",
  "urlList": [
    "https://www.example.com/en/services/",
    "https://www.example.com/ca/serveis/"
  ]
}

Use https://api.indexnow.org/indexnow with JSON and the Content-Type application/json; charset=utf-8 header. Bing’s manual setup example shows this request structure. The example above describes a request body, not a script that has submitted these pages.

For GET, encode the page URL as a query parameter. The protocol requires URL escaping. With a POST body, use your client’s JSON serializer and retain valid absolute URLs in the list. Avoid hand-concatenating strings, especially when a path contains accented characters or a query contains an ampersand.

During the initial test, record the exact submitted URL, selected endpoint, timestamp, status and response headers. Compare the logged URL with the browser address of the intended page. Preserve its language prefix, path case and trailing slash convention. Do not send a preview hostname just because it came from the deployment provider’s success message.

Only expand to batches after that trace is understandable. Group by verified host and place an explicit upper bound on batch size. The 10,000-URL ceiling is a protocol limit, not a target that requires waiting until you have enough changes. Choose smaller working batches when they make failed requests easier to inspect or replay.

Decide which events deserve a notification

Create an event policy with the editorial team. The recommendations below are intended for a business website; adapt the examples to the content you publish. Use the public outcome of the change to decide whether an event belongs in the queue.

IndexNow accepts redirected URLs and deleted URLs returning 404 or 410. The FAQ explicitly covers both. Do not reuse a sitemap export filter that drops every non-200 URL: your notification policy needs to preserve intentional removals.

For a withdrawn offer, store the old address before deleting the CMS record. Otherwise, the publishing system may leave the worker without an address to notify. Keep the removal event distinguishable in your own log, even though the submitted payload is a URL list. A later reviewer should know why a missing page was deliberately sent.

For a move, verify the old address and the new destination independently. Check the intended 301 or other redirect response in production. If the destination is also new or changed, include it as its own event. Do not interpret a redirect test as proof that the search engine has already fetched the destination.

Use deliberate rules for translated content. In the hypothetical Barcelona example, changing Spanish copy alone does not prove that the Catalan or English response changed. Conversely, a shared service detail may affect every locale once deployed. Derive affected URLs from the published output or content relationships, then inspect a sample. Keep canonical and hreflang checks in the site’s technical SEO audit, rather than expecting notifications to correct those relationships.

For frequently changing pages, the official FAQ recommends at least 5 minutes between meaningful repeat notifications. Its automation guidance favours substantive updates over cosmetic changes. Apply that spacing rule after deciding whether a change needs sending. An unchanged page does not need a timer.

Keep a recoverable queue

For a custom integration, a practical design is a durable list of pending production changes. Save the URL with its event time, release identifier and intended outcome. Let a worker send that list separately from the editor’s publishing action. This is an implementation recommendation: the team should be able to retry delivery without asking an editor to republish content.

Coalesce closely spaced changes to the same URL before dispatch. Preserve the latest meaningful public state and enough history to diagnose what happened. If a page is published and then withdrawn before the worker runs, the reviewer needs to understand that sequence. Avoid a success flag that erases the event’s purpose.

If a batch fails validation, retain it with its member URLs for inspection. Rebuilding the list from current content may omit the deleted URLs that originally caused the notification. Keep retries tied to the recorded events, with checks for newer changes that supersede them.

Document restart behaviour. After a worker crash, which records remain pending? After a release rollback, which URLs now need a new notification? Make these questions part of acceptance testing while the queue is small. One recoverable failure is better evidence of operational readiness than a large collection of successful test requests.

Handle errors according to their cause

The response codes below follow Bing’s IndexNow setup reference. The suggested actions are operational recommendations; they do not promise a particular response on the next attempt.

Keep 200 and 202 distinct in your records. A 202 is a reason to watch verification, not to send the same batch repeatedly. Check public file access and configuration before treating persistent pending validation as a content issue. If the worker marks both responses simply as “indexed”, correct the label before anyone builds a report on it.

For 429, honour Retry-After when provided; participating engines set their own limits. The official rate-limit guidance does not publish one universal daily allowance. Never calculate an assumed daily entitlement by multiplying the maximum batch size by a guessed request frequency.

When a transient network failure, timeout or server error leaves delivery uncertain, use a bounded retry policy. A reasonable engineering approach is increasing delays with jitter, a maximum attempt count and an alert when that limit is reached. These are design choices, not extra IndexNow API guarantees. Preserve the failure details so the next person can tell a connection problem from a rejected request.

Before replaying a backlog, check that the sender still targets the correct production host and that the key file remains available. Repair permanent errors first. Replaying thousands of malformed requests faster only makes the original problem harder to investigate. For a queue that grows after a release, compare new event volume with successful delivery and inspect repeated failures by cause.

Check what happened after receipt

Bing Webmaster Tools exposes submission source and time, plus crawl and index status for sampled URLs. Its help page says unspecified submission time zones use UTC. The IndexNow reporting documentation defines those fields. Account for that when comparing a deployment log with an editor’s clock in Spain.

Pick a small, stable set of meaningful events for follow-up. Include a new page, an updated page and an intentional removal if your release contains them. Save the observation time alongside every status. A report captured before the next crawl cannot establish what the engine did with the latest content.

Bing’s Insights announcement describes reports for submitted, crawled and indexed URLs, with detail on the latest 1,000 submissions. The announcement supports using that view for diagnosis. Keep your own event log for a durable audit trail instead of treating a recent sample as a complete historical export.

Use Bing URL Inspection to compare index information with a live fetch. According to its documentation, the Live URL test reports redirects without following them automatically; inspect the destination separately. Record whether each observation came from the index view or the live test.

If the notification for a new page is received but the page remains unindexed, inspect accessibility, robots.txt, noindex and the declared canonical. Then review whether the content is useful and distinct. Keep the notification status visible while investigating the page; those are different pieces of evidence. Our server log analysis guide covers the separate work of establishing crawler activity from logs.

For an intentional removal, reverse the success question: has the obsolete result disappeared after the engine processed the changed response? Do not classify every submitted-but-unindexed URL as a failure. A useful report records the intended outcome beside the observed one, so a deleted offer is not mixed with a newly published service page.

Roll out with a short acceptance record

Start with one production host and a controlled publishing event. Verify the key file, capture the request and classify its response. Test a recoverable failure through your integration’s test environment or a mocked endpoint; avoid deliberately flooding the public API. Show that the queued event survives and that a corrected request can complete delivery.

Next, check one genuine update and one real removal when they occur. Record what the editor changed, when the public response changed, which URL the worker sent and what follow-up evidence is available. If you cannot connect those facts, fix the gap before enabling every content type.

Keep the release note modest: the integration sends eligible production changes, records delivery results and supports investigation. Any claim about faster indexing needs separate observations and a suitable comparison. Any question about later Copilot source selection belongs in the Bing AI Performance guide.

For the next publication, ask your team to produce one complete URL trace. The result should be understandable to the editor, the developer maintaining the sender and the SEO specialist checking the page. That is the evidence you need before expanding the workflow.