Optional IndexNow engines: enable them or not

Why these are a choice and the others are not

The difference is whether there is anything to weigh.

Two engines receive the same HTTPS submission without any configuration, because there is no trade-off in doing so: a submission costs nothing, obliges nothing, and carries no risk, so no decision exists and none is asked for.

These three differ in exactly one respect. Their audiences are regional or specialised, so submitting to them is effort that produces something real for some sites and nothing whatsoever for others. That is a real decision, and defaults should not make real decisions on somebody's behalf.

Note carefully what the difference is not. It is not quality, not reliability, and not how they treat what they receive: the protocol works the same way for every participant, as described on how it works. Optional here means optional for you, not lesser in itself.

The only question that matters

Not which engines exist, but which of them your readers actually use.

If a meaningful share of your audience sits in a market one of these serves, enabling it costs the same near-nothing as the defaults do, and it does exactly the same thing: a change is announced rather than waited for. If none of your audience is there, enabling it announces your changes to an engine that nobody in your audience searches with, which produces nothing at all beyond a line in a configuration.

The honest default is therefore off, and turning one on should follow from knowing something specific about your readers rather than from a wish for completeness. There is no penalty anywhere for leaving them off, and no reward anywhere for switching on everything that is available.

How to actually know

Two ways, in order of reliability.

• Look at where your visitors already come from

  Your own analytics answer this directly, and nothing else does. A market with meaningful traffic today is a market where faster discovery is worth having; a market with none is a hypothesis, and treating a hypothesis as a reason is how configurations accumulate settings nobody can explain later.

• Consider deliberate expansion

  If you are publishing content aimed at a region you do not yet reach, the engine serving that region becomes relevant before any traffic from it does. That is the one case where switching on ahead of evidence makes sense, and it is worth naming as deliberate rather than drifting into it.

What does not answer the question at all is a list of engines ranked by size. Size tells you something about the world; the decision in front of you is about your own readers.

One practical note follows from that framing. Because the decision is about your audience rather than about the protocol, it is worth revisiting when your audience changes, and not otherwise. A yearly glance at where visitors come from answers it; nothing about the engines themselves needs watching.

What switching them on does not change

Three things, since this is where expectations drift.

• It does not affect the default engines

  Bing and Yandex behave exactly as they did before; adding participants adds destinations rather than changing anything about the existing ones.

• It does not reach Google

  No configuration of participants includes an engine that does not take part, which is set out under the Google page.

• It does not change what a submission claims

  The same short message goes to a longer list of recipients. Indexing decisions remain each engine's own, made on its own criteria and never reported back to you.

A word about completeness

The instinct to switch on everything available deserves a direct answer, because it is the reason most people end up here.

Enabling all of them is genuinely harmless. Nothing breaks, nothing costs more in any way you would ever notice, and no engine objects to being told about a site that nobody in its market happens to read. If completeness makes a configuration easier to reason about, that is a legitimate reason to choose it.

What it is not is an improvement. The submissions go somewhere and change nothing, and treating that as coverage misdescribes what happened. The difference matters only when somebody later reads the configuration and concludes that the site is reaching audiences it has never reached.

So the honest position is that either choice is perfectly defensible, and only one of the two is sometimes described dishonestly afterwards.

Turning them on later

Nothing about this decision is permanent in either direction, which lowers its stakes considerably.

Enabling an engine later announces changes from that point forward; it does not announce your existing pages retroactively, because automatic submission follows change detection rather than inventory. That is the same scope boundary that applies everywhere in this protocol, covered under setup.

Practically, that means switching one on when a market becomes relevant is a reasonable and entirely undramatic action, and switching it off again when it stops being relevant costs nothing either. Neither direction deserves a meeting.

FAQ