Which pages to submit to IndexNow, and which to skip

The first thing most people do after setting up IndexNow is submit their whole sitemap. It feels thorough. It is also the one thing the protocol asks you not to do.

The IndexNow FAQ is direct about it: the protocol "is intended for notifying search engines about recently added, updated, or deleted URLs" and "is not designed for submitting every URL on your site at once." Sitemaps remain the way to describe the whole site. IndexNow is the way to say this changed, just now.

That leaves a practical question: for any given page, should you send it? Here is the rule set we use.

Send: pages that were just added

A new product, a new article, a new docs page. This is the case IndexNow was built for. Send the URL as soon as the page is live and reachable, not when the draft is saved.

Two details matter:

Live means indexable. If the page is behind a login, blocked by robots.txt, or carries noindex, an engine that follows your notification finds nothing it can use. Submit when the page is public.
Canonical URLs only. If /shoes?color=red declares /shoes as canonical, submit /shoes. Submitting every parameter variant multiplies requests without adding anything.

Send: pages whose content really changed

"Updated" is where most noise comes from. A page re-rendered with a new timestamp in the footer is technically different. It is not updated in any sense a reader would care about.

The FAQ asks you to "avoid submitting the same URL many times a day unless there are meaningful content changes", and lists repeated submissions "without meaningful changes" as a cause of errors. A reasonable test for meaningful:

the title or meta description changed;
the main text changed: a paragraph, a price, a specification, an answer;
structured data changed, such as a product's price or availability;
links or images in the main content changed.

Things that should not count: "updated 3 minutes ago" lines, view counters, rotating testimonials, session tokens in links, A/B test wrappers and other markup that changes without the content changing. If your notification logic is "the HTML hash differs", all of these will trigger it.

This is the problem AutoIndexNow's change detection is built around: it renders each page, removes this kind of noise, and submits only when a second render confirms the change. The details are on how change detection works.

Send: pages that were removed or moved

This is the case people forget. The FAQ says: "You should submit redirected URLs and pages that return HTTP 404 or HTTP 410 status codes." Notifying a removal lets participating engines drop or update the URL instead of discovering the 404 on their own schedule.

Be careful with timing. A page that returns 404 for two minutes during a deploy has not been removed. Submitting it is wrong twice: once for the false removal, and once more when it comes back. Wait until the state has held for a while before you report it. We wait 12 hours of consecutive checks.

Skip: pages that already existed

When you first connect a site, every page is new to your IndexNow setup, but not to search engines. The FAQ says the protocol "is not intended for retroactive submission of older changes" and points to sitemaps with accurate lastmod values for that.

So the first scan of a site should be a silent baseline: record what is there, submit nothing, and start notifying from the next real change.

Skip: the same URL again, too soon

Even when a page does change often, there is a floor. The FAQ's guidance is to "wait at least 5 minutes between updates before resubmitting", and after a 429 response to "wait at least 10 minutes before resubmitting the same URL, unless it has changed significantly." Engines do not publish their exact rate limits, so treat these as minimums, not targets.

If your CMS publishes ten edits to one page in an afternoon, one submission after the last edit is the useful one.

Skip: URLs that are not yours to submit

The key file proves control of a host, and the documentation says a 422 comes back for "URLs which don't belong to the host." Each host, including each subdomain, needs its own key. www.example.com and example.com are different hosts, and help.example.com is a third.

A short checklist

Before a URL goes into a submission, it should pass all of these:

Check	Why
Public, `200`, indexable, canonical	Otherwise the notification points to nothing usable
Added, meaningfully changed, or removed (and the removal has held)	That is what the protocol is for
Not part of the initial baseline	Old pages belong in the sitemap
Not submitted in the last few minutes	Repeats without changes are what engines push back on
On the host the key belongs to	Otherwise the request is rejected

What a submission does and does not do

A 200 means the endpoint received the URL; the documentation says it "only indicates that the search engine has received your URL." The FAQ adds that submitting "does not guarantee immediate indexing" and that each engine "may choose not to index a URL based on its algorithms." Participating engines share submissions with each other, so one notification reaches all of them. Google does not participate.

Submitting less, and only what changed, is not a compromise. It is how the protocol is meant to be used, and it keeps your notifications credible when they matter.

Sources

IndexNow FAQ, checked October 19, 2026
IndexNow documentation, checked October 19, 2026

A 200 or 202 from an IndexNow endpoint means the request was accepted, not that the URL is indexed. Google does not participate in IndexNow.

All posts