IndexNow and Bing Copilot.
IndexNow is an open protocol that instantly notifies search engines when a page changes, and it is supported by Bing and the Yandex family.
The classic discovery model rests on waiting: the page is published, the crawler’s visit is awaited, then it enters the index. That wait can run from days to weeks. IndexNow inverts it — the moment a page is published, a notification goes to the engine and the crawler is summoned.
The protocol is simple: a key is generated, a text file containing that key is placed at the site root, and changed URLs are reported to an endpoint. The engine verifies that the notification really came from the site owner by reading the key file. The key is not a secret — by the protocol’s design it sits publicly at the root.
Why it matters to answer engines
The direct link runs through Bing: Microsoft’s answer product feeds on the Bing index. Being indexed quickly in Bing therefore directly affects the chance of appearing in that product. That makes IndexNow meaningful not only for classic search but for the answer engine layer.
There is also a coverage dimension: Yandex holds a notable usage share in Türkiye, and it supports the protocol too. A single notification feeds two separate ecosystems at once.
Google does not support the protocol and has said so explicitly; discovery there stays tied to its own mechanisms — the sitemap, internal links, crawl budget. IndexNow is a complement; it does not replace the sitemap.
The setup on this site
On this site the protocol is installed and wired to a tool. The key lives in a data file, the key file at the root comes out of the generator, and the notification tool reads the URLs from the sitemap and reports them to the engine.
There is one critical operating rule: the tool must run AFTER deploy. The reason is the verification mechanism — when the engine receives the notification, it reads the key file from the LIVE site. If the file has not yet reached production, verification fails and the notification is rejected.
The tool checks this itself: if it cannot verify the key file on the live site, it stops honestly and sends nothing. That is better than an integration that fails silently — a tool that says it failed is always worth more than a tool that pretends to work.
- Generate the key and keep it — once, and it does not change.
- Put the key file at the root — let it come from the generator, not from memory.
- Notify after deploy — reverse the order and verification fails.
- Report only what really changed — reporting every URL on every build devalues the signal.
- Watch the result — the engine’s webmaster panel shows the notification records.
The common mistake: reporting everything
The protocol’s value lies in the notification carrying a SIGNAL: “this page really changed.” A setup that reports every URL on every deployment turns that signal into noise, and after a while the engine values the notifications less than it should.
A correct setup requires a mechanism that knows which page actually changed. This site already has that mechanism: every page’s output is fingerprinted and kept in a ledger; the stamp advances only when the content really changes. The same ledger can also say which URLs to report.
The distinction looks small but decides the long run. A source that signals inconsistently stops being taken into account — and that holds the same way for date stamps as for notifications.
A signal that reports everything becomes a signal that reports nothing.
Finally, the measure of expectation: IndexNow does not GUARANTEE indexing; it only accelerates discovery. A page crawled and found poor still does not enter the index. The protocol is not a fix for a content problem; it is a tool that shortens the discovery delay for a site whose content is already good.
The key file and security
The part of the protocol that raises the most questions is the key sitting exposed at the root. That is not a vulnerability; it is the design itself: the key serves to verify that the notification came from the site owner, and verification is only possible while the file is public. Someone who knows the key can send notifications in your name — but the only thing they can send is “this page changed,” and that carries no abuse value.
Still, one point deserves care: if the key file disappears in a deployment, notifications silently start being rejected. Having the file come from the generator, with its presence checked by a test, prevents that silent loss.
There is also a scope rule: the reported URLs must belong to the domain where the key file lives. Notifications cannot be sent for another domain — the protocol blocks it through verification.
When it is worth it, and when it is not
IndexNow’s return varies sharply by site type, and not every site needs it. For a frequently updated publication, a news site, or a blog producing regular content, shortening the discovery delay is a real gain — on current topics especially, a few days of delay can be enough to miss the traffic entirely.
By contrast, on a corporate brochure site updated a few times a year the practical benefit is small; the sitemap and normal crawling already work at sufficient speed. Since the setup cost is low it does no harm, but it should not sit at the top of the priority list.
The reason it was installed on this site was not tempo but discipline: every step of the publishing flow should have a tool and a record. The protocol is also one of the topics the site writes about — a working installation is stronger evidence than an article about one.
A final note on the protocol’s limit: IndexNow accelerates discovery; it does not guarantee indexing. A page crawled quickly and found poor still stays out of the index — the protocol only knocks on the door early; it does not get you inside. The distinction matters for using the tool with the right expectation: for a site with an indexing problem the fix is not IndexNow but content quality, and that must be closed first.
A closing frame: this protocol is a small part of the principle that every step of the site’s publishing flow should have a tool and a record. On its own it is not a large gain; but once installed, the path a published piece of content takes to discovery becomes documented and measurable. The value of a documented flow is independent of any single step’s return — the day something breaks, it shows where.