IndexNow at the edge: submissions without site changes

Why edge submission 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.

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.

The route does not make submissions better; it makes them possible where the alternatives are not.

What edge submission sends

The same message every other route sends.

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 under what an accepted submission means.

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 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.

Which engines receive edge submissions

Bing and the shared endpoint without configuration, four more on request, and Google not at all.

Bing and the shared endpoint (api.indexnow.org) receive submissions by default. Seznam, Naver, Yep, and Yandex 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 edge submission does not do

Three limits apply, even with no setup work.

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 on edge submission

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.

Three submission modes

Once edge submission is on, a mode decides how one list of addresses is spread across the engines you have switched on. Fallback, the mode the product recommends, submits each address once and tries the next engine only on failure. Balance gives each address to one enabled engine, so no address is sent twice. All engines sends every address to every enabled engine, which is redundant by design. The pages announced are the same in all three; what differs is how much of each engine’s allowance the list spends. The three are compared side by side on the main page.

What the submission log records

Every submission is written down: the address, the engine it went to, the mode that decided that, the time, and whether the endpoint accepted it. A refusal is recorded the same way as an acceptance, and where Fallback retries on the next engine both lines stay. The record answers whether a submission left and where it went; it says nothing about indexing. An illustration of the record is on the main page.

FAQ