IndexNow Setup: Notify Search Engines When URLs Change

Use IndexNow for change notifications

IndexNow tells participating services that a URL has changed. It does not upload your article body or replace the page itself. The practical starting point is a publishing event: an article becomes public, a product’s availability changes, or an obsolete page is removed. Send the affected URL after the new state is available to visitors. Notifying a URL before a deployment completes can direct a crawler towards the previous version. Connect notification to successful publication rather than to an editor pressing a button that merely starts a build.

Keep the notification stream separate from your complete content inventory. The XML sitemap guide covers the durable list of preferred public pages. This article addresses event handling and verification for the changed subset. A fictional documentation publisher with two thousand articles might amend three pages during a release. Its change queue should identify those three addresses and their deployed revisions. Resubmitting all two thousand on every release hides the meaningful changes and makes operational failures harder to investigate.

Check whether an existing integration already handles it

Before writing code, inspect your CMS, hosting service and SEO tooling for an existing IndexNow integration. The protocol’s FAQ recommends checking platform support first. Establish what triggers the integration, which hostname it submits and where you can see failures. “Enabled” is not enough evidence if nobody knows whether a draft save, public update or removal generates the notification. Ask for one recent example and trace it from publication to recorded response. This avoids building a second integration that sends duplicate events without adding useful control.

If you do implement your own worker, define its boundary. It should accept publication events from your trusted system, not arbitrary URL submissions from anonymous visitors. Give it a fixed allowed origin and a fixed IndexNow endpoint in configuration. Keep deployment credentials separate from the notification key and do not include customer data in submitted URLs. The public URL is the item being disclosed. Preview tokens, private search terms and session identifiers have no place in a search notification queue.

Host and test the verification key

Bing’s IndexNow setup guide describes ownership verification through a UTF-8 text file on the submitted host. A root-level key file provides straightforward scope for that host. If a non-root location is used, supply its location and respect the narrower URL scope described by the protocol. Generate a key for your own installation and serve its exact value as plain text. Do not copy an example key from a tutorial. Treat the hostname carefully: the bare domain and its www version are different hosts for configuration purposes.

Test the file through the public deployment, without authentication, and inspect the response body as well as the status. A single-page application can return an HTML fallback with a successful status at a missing text-file address. That is not a valid key response. Check that redirects, middleware and security rules do not substitute a login page or challenge. After a hostname migration, verify the new host’s key before enabling notifications there. Record which deployment owns the file so that a routine clean-up does not accidentally remove the verification asset.

Send a bounded batch after publication succeeds

Build the URL list from trusted publication records. Deduplicate it, reject addresses outside the configured origin and keep batches within the protocol’s ten-thousand-URL maximum. For most editorial sites, much smaller batches are easier to inspect and retry. Use a JSON POST for several URLs. The example below illustrates payload construction using deployment configuration and a changed-URL array supplied by your publishing workflow. The verification file must already be served at the configured root location. These variables represent real runtime inputs rather than a public form accepting arbitrary addresses.

Keep network notification outside the request that serves an article to a reader. A temporary endpoint failure should not prevent someone from opening an otherwise healthy page. A background job can record the pending event, perform the request with a timeout and store the response. Before sending a new-content event, confirm that the public URL shows the intended revision. For a removal event, confirm its intended status instead. The technical release checklist helps place these checks after deployment without confusing build success with published behaviour.

const origin = new URL(process.env.SITE_ORIGIN).origin;
const host = new URL(origin).hostname;
const key = process.env.INDEXNOW_KEY;
if (!key || !/^[A-Za-z0-9-]{8,128}$/.test(key)) throw new Error("Invalid key");
const urlList = [...new Set(changedUrls)];
if (!urlList.length || urlList.length > 10000) throw new Error("Invalid batch size");
for (const value of urlList) {
  const url = new URL(value);
  if (url.origin !== origin || url.hash || url.username || url.password) {
    throw new Error("Unexpected submitted URL");
  }
}
const response = await fetch("https://api.indexnow.org/indexnow", {
  method: "POST",
  headers: { "Content-Type": "application/json; charset=utf-8" },
  body: JSON.stringify({ host, key, keyLocation: `${origin}/${key}.txt`, urlList }),
  signal: AbortSignal.timeout(15000)
});
console.log({ status: response.status, submitted: urlList.length });

Interpret the response before deciding whether to retry

The protocol response table distinguishes successful receipt from pending key validation. A 200 response acknowledges submission; 202 indicates that key validation is pending. Neither is an index report. Invalid formats, failed key verification and invalid host or key scope have different responses, so preserve the status with the batch identifier. Do not label every non-200 result as a search-engine rejection of your content. At this stage, the problem may simply be a malformed request or a missing verification file. The response table below summarises the documented categories.

Choose retry behaviour according to the failure. A request with an invalid host will not improve after ten immediate retries; fix the configuration first. A rate-limit response needs a delay and lower submission pressure. For a timeout or transient server failure, retain the event and use a bounded retry schedule with increasing delays and a final alert. Record attempts separately from publication events so that operational retries do not appear as additional content updates. A small site can implement this with a simple persistent job table rather than a complicated message infrastructure.

Handle removals and redirects deliberately

A changed URL is not necessarily a page that now returns a successful article response. IndexNow supports notifications for removed and redirected URLs. Submit the affected old address when its state changes, rather than replacing every old address with the homepage in the notification list. If an article moves, the redirect itself explains the relationship when the old URL is fetched. If the content is genuinely gone without an equivalent replacement, return an appropriate removal response. The HTTP status guide explains the page-level decision; the notification simply announces that a change occurred.

For a fictional guide moved from an old category to a new permanent address, keep two review records: the old URL’s redirect and the destination’s published content. Confirm that internal links point to the intended destination and that the new page does not redirect back. Then notify the relevant changed addresses through the normal queue. Do not infer that a submission receipt means every search system has replaced the old URL. Use the migration checklist to track the wider move, including links and canonical signals that notification alone cannot repair.

Keep the queue focused on meaningful changes

Create a change fingerprint from substantive fields such as article body, important metadata and publication state. Exclude values that change on every build without changing the page’s information, such as a build identifier. Otherwise an automated deployment can manufacture a stream of apparent updates. For a frequently changing page, coalesce nearby events so the queued URL represents the latest public state. The FAQ advises spacing repeat notifications for the same page and focusing on meaningful changes. Your implementation should retain enough history to explain what actually changed.

If a content refresh fails validation and never reaches production, remove or hold its notification event rather than sending an address for an unpublished revision. If publication succeeds but notification fails, keep the page live and retry the notification independently. This separation makes the system easier to operate: editorial approval, deployment and external acknowledgement are three different states. Align that model with the content refresh workflow so editors can see whether an article is published without needing to interpret network logs.

Verify useful outcomes without promising indexing

Your minimum operational report should identify recent publication events, submitted batches, response categories and unresolved failures. Add sampled public fetches showing that the notified URLs expose the expected state. That demonstrates a functioning integration. To investigate indexing, use the relevant search engine’s inspection tools and account reports as separate evidence. The protocol is shared among participating engines, but participation does not make it a universal submission interface for every search or answer system. Check current support before making platform-specific claims to colleagues or clients.

When a notified page remains absent, investigate its actual eligibility and content rather than repeatedly increasing notification volume. The indexability guide separates permission to index from confirmed inclusion. Keep the same distinction in your reporting: publication time, notification time, observed crawl and observed inclusion are different milestones. If you cannot observe one, leave it unknown. A dependable IndexNow integration shortens the publisher’s path from a real change to a delivered notification. It cannot compel another system to crawl immediately, select the page or describe a brand in a particular way.

Sources and further reading

• IndexNow: protocol documentationHost key verification, key-location scope, batch limit and response-code meanings.
• IndexNow: implementation FAQExisting integrations, meaningful-change notifications, participating endpoints, redirects, removals and non-guaranteed indexing.
• Bing: IndexNow setupKey generation, public key hosting and single or bulk URL submission steps.