Blog · November 3, 2026 · 4 min read
IndexNow for deleted, moved and noindexed pages
IndexNow is not only for new content. How to report removals, redirects and noindex correctly, and how to avoid reporting a deploy hiccup as a deletion.
Most IndexNow setups only ever announce good news: a page was published, a page was updated. Removals are the forgotten half of the protocol. A deleted product keeps showing up in search results, a renamed docs page keeps sending visitors to a 404, and nobody told the engines.
The protocol covers this case explicitly. The IndexNow documentation defines the URL you submit as one "which has been added, updated, or deleted", and the FAQ answers the question directly: "You should submit redirected URLs and pages that return HTTP 404 or HTTP 410 status codes."
This post is about doing that well: which status to serve, what to submit, and how to avoid announcing a removal that never happened.
Serve the right status first
An IndexNow notification is a prompt to come and look. What the engine finds when it looks is what counts, so the page itself has to say what happened. HTTP gives you precise words for it (RFC 9110):
| Situation | Serve | What it tells a crawler |
|---|---|---|
| Removed for good | 410 Gone | Access "is no longer available at the origin server", and that is likely permanent |
| Removed, or never existed | 404 Not Found | Nothing is there now; no statement about permanence |
| Moved for good | 301 or 308 | The resource "has been assigned a new permanent URI" |
| Moved for now | 302 or 307 | Temporary; the old URL is still the one to keep |
| Still there, but keep it out of search | 200 with noindex | The page exists and asks not to be indexed |
Two details trip people up.
Soft 404s. A page that says "this product no longer exists" but answers 200 OK is, to a crawler, a normal page with thin content. Submitting it tells engines that a page changed, not that it is gone. If the content is gone, answer 404 or 410.
Temporary redirects for permanent moves. Many frameworks default to 302. If a URL has moved for good, use a permanent redirect, so the new URL is the one that should be kept.
Bing's own removal guidance lists the same building blocks: remove the page and return a 404, or add a noindex meta tag, or use the Block URLs tool in Bing Webmaster Tools.
Then submit the old URL
Once the status is right, submit the URL that changed, which is the old one:
- Deleted page: submit the URL that now answers
404or410. - Moved page: submit the old URL, which now redirects. If the destination is new or its content changed, submit it too. It is a new or updated page in its own right.
- Newly noindexed page: submit the URL; what changed is its indexability.
A site migration is the biggest version of this. Put the redirect map live first, check a sample of old URLs answers with the permanent redirect you expect, and only then submit the old URLs, in batches. The documentation allows up to 10,000 URLs per POST. Update your sitemap to list the new URLs only; a sitemap describes what exists, not what used to.
Do not announce a hiccup as a deletion
Here is the trap. During a deploy, a cache purge or a bad config push, perfectly healthy pages can answer 404, 500 or a redirect to a maintenance page for a few minutes. A naive monitor sees "status changed from 200 to 404" and submits a removal. A few minutes later the page is back, and the monitor submits it again as changed.
That is two false notifications for one non-event. The FAQ's warnings about submitting "the same URL many times a day unless there are meaningful content changes" exist because engines push back on exactly this pattern.
So treat a loss of indexability as a claim that needs to hold before you make it:
- Note the new state the first time you see it, but do not submit.
- Check again on the next run. If the page is back, forget the episode.
- Only when the state has held for long enough, submit once.
How long is "long enough" is a judgement call. We use 12 hours of consecutive checks: long enough to outlast deploys and short outages, short enough that a real deletion is reported the same day. A page that comes back after a confirmed removal is then news again, and gets submitted as returned.
Keep checking pages that left the sitemap
There is a second trap on the discovery side. Most monitoring starts from the sitemap, and when a page is deleted, it usually leaves the sitemap at the same moment. If your tool only checks what is in the sitemap, it never sees the 404 and never reports the removal.
The fix is to keep checking URLs for a while after they disappear from the sitemap. If they now answer 404, 410 or a permanent redirect, and the state holds, report them. AutoIndexNow keeps checking such URLs for at least a week for exactly this reason.
What a removal notification does not do
Submitting a deleted URL does not remove it from anyone's index on the spot. It tells participating engines to look again; they decide what to do and when. Bing Webmaster Tools also has a Content Removal tool for pages that are already gone but still show in results, and a Block URLs tool that hides a URL for 90 days. Google does not participate in IndexNow, so for Google the status code and an updated sitemap do the work.
Short version: serve the honest status code, wait until it has held, submit the old URL once, keep checking URLs that left the sitemap, and list only live URLs in the sitemap.
Sources
- IndexNow FAQ, checked October 19, 2026
- IndexNow documentation, checked October 19, 2026
- RFC 9110, HTTP Semantics: status codes, checked October 19, 2026
- Bing Webmaster Tools: how to permanently remove a URL or page, 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.