How to get new pages indexed with IndexNow

I ping IndexNow when I ship pages on leej.uk, and I built the IndexNow Submitter and the Indexing Submission Tracker so I could see what was sent, and what was only assumed. The routine below is how that ping sits next to the rest of indexing, not in place of it.

Indexing is a queue, not a button

Search engines discover URLs, crawl the ones they choose, then decide whether to store them and whether to show them for a query. You can make discovery easier. You cannot skip the later decisions.

The parts you control are ordinary and unfashionable:

• The URL is indexable: 200, canonical, no noindex, allowed in robots.txt, with a real first response. The Indexability Checker is the starting point for that test.
• The page is worth storing: it has a clear job, it is not a duplicate or a soft 404, and it is linked from the site.
• A sitemap lists it, as in the XML sitemap guide.
• When the URL is new or has meaningfully changed, you can notify engines that offer a submission path.

IndexNow is one of those notification paths. Google Search Console’s URL Inspection tool and a sitemap ping are others, for Google. None of them override quality, canonicals or noindex. Treating a green API response as “we are indexed” is how teams stop looking at the actual queue.

The mindset is the same one I use in the App Store launch process: submitting the build is required, and it is not the same as being on the store.

What IndexNow is, and who it talks to

IndexNow is an open protocol. You host a key file that proves you control the host, then you submit one or more URLs to a participating endpoint. Participating engines may share those submissions with one another. Each engine still decides whether to crawl or index.

The list of participants is published by the protocol and it changes. At the time of writing, in November 2026, the list at indexnow.org/searchengines and the machine-readable file at indexnow.org/searchengines.json include engines such as Microsoft Bing, Yandex, Seznam, Naver and Yep, along with other consuming services named in that file. I am not going to paste a list here as if it were permanent. Check the official file when you implement this, and again if a submission starts failing in a way that looks like a policy change.

Google Search is not in that list, and a submission does not notify Google. For Google, use a sitemap, Search Console, and, where it applies, URL Inspection. Google also has a separate Indexing API, but that API is limited to specific page types, such as job postings and certain livestream events, and it is not a general “index my blog” interface. Confirm the current scope in Google’s Indexing API documentation if you think you need it.

IndexNow is still useful if you care about Bing and the other participating engines, and it is cheap to run correctly. It is not a substitute for Google’s own tools, and it is not a ranking system.

The key file and a correct submission

You prove control of the host with a key.

1. Generate a key that meets the current protocol rules (IndexNow describes a string of 8 to 128 hexadecimal characters). Treat it like a shared secret you are willing to publish at a known URL, not like a private API token for a third-party service.
2. Serve it as a file on the same host as the URLs you will submit, for example https://example.com/{key}.txt, with the key as the body and a plain-text content type. The official IndexNow documentation also allows a keyLocation if the file lives at a different path on that host. Follow the current document rather than a blog screenshot.
3. Confirm the file yourself: curl -sSI should show 200 over HTTPS, and the body should be exactly the key, with no HTML wrapper and no login wall.
4. Submit a URL, or a small batch, to a participating endpoint. A GET with url and key is enough for a single URL. A POST with JSON is the usual way to send a list.

A single-URL GET looks like this, using Bing’s endpoint as an example:

https://www.bing.com/indexnow?url=https://example.com/articles/new-guide&key=YOUR_KEY

A batch POST to the shared endpoint looks like this:

POST /indexnow HTTP/1.1
Host: api.indexnow.org
Content-Type: application/json; charset=utf-8

{
  "host": "example.com",
  "key": "YOUR_KEY",
  "keyLocation": "https://example.com/YOUR_KEY.txt",
  "urlList": [
    "https://example.com/articles/new-guide",
    "https://example.com/tools/new-tool"
  ]
}

Rules that are easy to miss:

• Every URL in the list must belong to the host you declared, on the same scheme you use publicly, usually HTTPS.
• Submit the canonical URLs, not a www twin, a preview host, or a tracking-parameter variant.
• Include only URLs that should be crawled. Do not ping a noindex page, a redirect, or a staging path and then wonder why nothing useful happens.
• Keep the key file up for as long as you submit. If you rotate the key, update the file first, then the submitter.

The IndexNow Submitter will shape a request. You still have to host the key and read the response code yourself.

Sitemaps, Search Console and IndexNow together

These tools overlap, and you want that overlap.

• The sitemap is the durable list of indexable URLs, rebuilt when the site changes. It is how Google and others discover and revisit the set as a whole. IndexNow does not replace it.
• Google Search Console is how you watch Google’s queue: sitemaps submitted, pages indexed, pages excluded, and a manual inspect when a new URL matters. The Search Console Indexing Report Analyser helps you read a coverage export. Bing Webmaster Tools is the equivalent place to watch Bing.
• IndexNow is the change notification for participating engines, sent when a URL is added, updated or removed.

A sensible launch or release habit, which also belongs in a technical SEO launch checklist, is:

1. Ship the page, indexable, with internal links.
2. Rebuild and, if needed, resubmit the sitemap.
3. Ping IndexNow for the new or changed URLs.
4. For Google, use URL Inspection on a handful of important new URLs if you need a faster first look, and then let the sitemap and ordinary crawling do the rest.

Removing a URL is a change too. If you delete or merge a page, redirect it, drop it from the sitemap, and submit the old URL (and the new one) so participating engines can be told it moved or went away. IndexNow is not a magic delete, but it is a valid reason to ping.

What a 200 from the API does not mean

Response codes tell you about the notification, not about search results. The protocol documents codes such as:

• 200 — the URL was submitted.
• 202 — accepted; the key may still be in the process of being validated.
• 400 — the request was invalid.
• 403 — the key was not valid for that host.
• 422 — the URLs do not match the host, or the key location failed a check.
• 429 — you have submitted too much, too often.

Read the current documentation for the exact meanings when you implement retries. Then remember the gap: a 200 does not mean “crawled”, “indexed”, or “ranking”. The engine may wait, may crawl and reject the page, or may already have a copy it considers fresh enough.

I log the payload, the endpoint, the status and the time in the Indexing Submission Tracker, and I treat that log as a record of pings, not as an index. If a page is still missing later, I start with indexability and the sitemap, not with “the ping must have failed”.

A routine for new and updated pages

On this site, a content release does the following, in the same spirit as maintaining an iOS app after launch: the notification travels with the release, not as a forgotten manual step the next morning.

• Rebuild the sitemap from the live URL list, with honest lastmod values.
• Collect the URLs whose content actually changed, not every URL in the deployment.
• Ping IndexNow once for that set.
• Leave Google to the sitemap and Search Console, plus a manual inspect only for a small number of important URLs.
• Keep the key file in the same release as the site, on the canonical host, without a JavaScript wall.

For a one-off page, the IndexNow Submitter is enough. For a batch, automate the same steps so they cannot be skipped.

Do not ping on every typo fix that you would not bother to mention in a changelog, and do not ping the same unchanged URL every hour. The protocol is a change feed. Spamming it does not make Google notice, and it can earn you a 429 from engines that do listen.

When a page still does not appear

If a URL is not in the results days or weeks later, work through causes in this order:

1. It is not indexable. noindex, a canonical to another URL, a robots disallow, a login, a challenge page, or a soft 404. Fix the page. The soft 404 guide covers one of the more confusing cases: a 200 that is not a real page.
2. It is not in the sitemap, or the sitemap is stale. Add it, or fix leftovers that are wasting attention.
3. It has no internal links. Discovery is slower, and the page looks detached.
4. The IndexNow key or host was wrong, so participating engines never received a valid ping. Check the key file and the tracker log.
5. The engine crawled it and chose not to index it, or has not got to it yet. Thin, duplicated or unhelpful pages often sit in “crawled — currently not indexed” in Search Console. A second ping will not fix that. The page has to deserve a place, which is the same bar I set in the iOS app MVP checklist: do not expect a listing for work that is not yet a complete product.
6. You are looking in the wrong engine. An IndexNow 200 will not make the URL appear in Google.

Be patient with brand-new hosts. A domain with no history can take longer to be trusted, and no honest guide should promise a number of hours.

Automation that is safe to rerun

A good submitter is idempotent and boring:

• It can be run twice on the same release without flooding the endpoint. Deduplicate the URL list, and do not retry a 200 just because the pipeline ran again.
• It retries 429 and network failures with a delay, and it does not retry a 400 or 403 in a tight loop. Those need a human fix to the payload or the key.
• It records what it sent. A silent cron that “must have run” is not a tracker.
• It only ever sends production canonical URLs. Preview hosts, and the contents of a local build directory, should be impossible to submit.
• It fails the release, or at least raises a visible error, if the key file is missing on the live host.

You can write that in a few dozen lines, or use the tools on this site for the manual and bookkeeping parts. The important property is that a rerun is safe, because release pipelines do rerun.

Key takeaways

• IndexNow is a change notification for participating search engines. A successful ping is not a guarantee of a crawl or of indexing.
• As of November 2026, Google does not take part. Confirm the current participants at indexnow.org, and keep using a sitemap and Search Console for Google Search.
• Host a valid key file on the same host, submit only canonical, indexable URLs, and log the response codes for what they actually mean.
• Use IndexNow alongside an accurate sitemap, not instead of one, and ping when URLs are added, updated or removed.
• If a page does not appear, debug indexability, the sitemap and the content before you assume the ping failed.

If you want a second pair of eyes on an indexing routine that is all pings and no results, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.