IndexNow at the edge: submissions without site changes

Why this route needs nothing from the site

Every other way of sending a submission depends on something inside your site telling it that a page changed.

A content system announces because it has a publishing event. A build pipeline announces because it knows what it just deployed. Both are perfectly good, and both require that such a moment exists and that somebody wires into it. Plenty of sites have no such moment: content is edited in place, generated by a process nobody wants to touch, or produced by several systems that do not agree on what publishing means.

The delivery layer has no such dependency. It sits in front of everything, sees requests and responses for every address on the hostname, and can observe that what it now serves for an address differs from what it served before. No instrumentation is added to the site, because nothing about the site has to change for the observation to be possible.

That difference is worth stating precisely, because it is easy to hear as a claim about quality. Every route sends the same message and reaches the same engines. What varies between them is only what has to exist inside your site before a submission can happen at all, and on this route the answer is nothing.

That is the entire argument for this route, and it is a narrow one. It does not make submissions better. It makes them available where the alternatives are not.

What is actually sent

The same thing every other route sends, which is worth saying plainly because the convenience invites larger assumptions.

Automatic submission covers discovered and changed addresses only. Enabling it imports no history, and submitting a full site remains a manual action. The edge is a place from which to send, not a mechanism with a different scope, and no route anywhere announces pages that have not changed.

The message itself is unchanged too: an ordinary HTTPS request naming an address, verified against the key file for that hostname. What each engine does with it is its own decision, described on how it works.

The key file comes from the same place

One practical consequence of this route is that key hosting stops being a separate task.

The key file has to be served at /<key>.txt on the hostname the submissions are about, because that placement is what proves control of the hostname. When the edge both sends the submissions and serves your traffic, it serves that file as well, on your hostname, without anything being deployed to your origin.

This matters more than it sounds for sites where publishing a single static file at a fixed path is awkward: managed platforms with fixed routing, applications that answer every path themselves, and setups where the origin is not directly writable. On this route the file is not something you place; it is something already served from where it needs to be.

It also removes a failure that is otherwise common. A key file placed by hand can be moved by a deploy, shadowed by a catch-all route, or returned as a formatted page by an error handler that treats it as a missing document, and each of those breaks verification while looking perfectly healthy from a browser.

Where the submissions go

Two engines without configuration, three more on request, and one large one not at all.

Bing and Yandex receive submissions by default. Seznam, Naver, and Yep participate when you enable them, which is a decision about where your readers are rather than about the engines themselves. Google does not participate in IndexNow, receives nothing from this or any other route, and no setting anywhere changes that. Which engines take part, and what that means for a publisher, is set out under engines.

What this route does not do

Three limits, stated because the absence of setup work invites the assumption that there are none.

• It does not decide what is worth announcing better than you do

  The layer observes changes; it does not know which of them you consider meaningful. A site that rewrites a timestamp on every response is changing addresses in a sense nobody intended, and that kind of noise is worth looking for before concluding that a submission volume is normal.

• It does not affect crawling, indexing, or ranking

  Submission is an announcement, and an accepted announcement is a statement about the message rather than about the page. That separation holds identically here.

• It does not replace the other routes for their own strengths

  A publish process knows exactly what a release contains, which is more precise than observation. Where that precision matters and the pipeline already exists, setting up there is a reasonable choice.

Turning it on

This is a Bridge CDN feature, and the submission side is configuration rather than integration.

For a site already served through the platform, there is nothing to install and nothing to add to the site: the layer that serves your traffic is the one that sends the submissions and serves the key file. Sites are onboarded at bridge-cdn.com, which is where the product and its documentation live.

FAQ