Submitting changed URLs to IndexNow

What IndexNow is for#

IndexNow is a small protocol for telling participating search engines that a URL changed, instead of waiting for the next crawl. One POST of JSON carries up to 10,000 URLs; submitting to one participating engine shares the notification with the others. Version 1.0 is what this site implements.

Its value rests entirely on the feed being trusted. A publisher that submits URLs which 404, redirect, or have not actually changed teaches the receiving engine to weight the feed less — which costs more than the delay it was meant to avoid.

The three rules the tool enforces#

Only changed URLs

The set comes from comparing generated output between two commits, not from the sitemap. Submitting the whole site on every deploy is the fastest way to be ignored.

Never a non-public URL

Every submitted URL must sit under a public prefix and must appear in the published sitemap. A URL that is not in the sitemap is not something to advertise.

Nothing without a verifiable key

The key must be configured and its key file must be reachable at the site root. If either is missing the run refuses and says so, because a submission with an unverifiable key is answered 403 and achieves nothing.

One submission, stage by stage#

1. Trigger — a documentation deploy has completed and the live pages have passed verification.
2. User event — somebody runs the submission, with a dry run available to see the set first.
3. Authentication and workspace resolution — none in Connect. The credential here is the IndexNow key, which authenticates the site to the receiving engine, not a person to Connect.
4. Ingest — the changed set is computed by comparing generated output between two commits.
5. Canonical record — the set is filtered against the published sitemap; anything not in it is dropped before the request is built.
6. Classification — removals are not submitted. This feed is for changed URLs that resolve.
7. Rules — the key file must be reachable at the site root, or the run stops before sending anything.
8. Approval — the dry run. It prints exactly what would be sent, which is the moment to notice that a refactor touched two hundred pages.
9. Action — one JSON POST to a participating endpoint, up to 10,000 URLs.
10. Result — a response code, interpreted below rather than treated as success or failure.
11. Timeline — the submission is logged: when, how many URLs, and what came back.
12. Audit — the log is the record. A later question about whether a page was advertised is answered from it rather than from memory.

Reading the response#

The key file itself is a short hex string served at the site root, between 8 and 128 characters. It is not a secret in the sense a credential is — it is public by design, since the whole verification method is that the site serves it — but it is still specific to this site and is not printed in this manual.

Where this sits in the release#

1. Publish and deploy the change.

   Result The generated tree is already committed, so the deploy is a copy rather than a build.

2. Run the verification pass against the live site.

   Result This is what proves the URLs you are about to advertise resolve and carry real content.

3. Run the submission as a dry run and read the set.

   Result An unexpectedly large set is a signal that something regenerated wholesale, and that is worth understanding before it is announced.

4. Submit, and keep the log.

   Result The record of what was advertised, when, is the only way to answer that question later.

Submission is not a substitute for a sitemap and it is not a ranking mechanism. It shortens the gap between a change being live and an engine knowing about it, and nothing more than that.

Questions#

Related#

• Publishing a documentation change
• Verifying published documentation
• A search crawler fetching a page
• Protocol reference
• Treating documentation as a build artefact
• The machine-readable documentation