Optional IndexNow engines: enable them or not
Four engines take part when you switch them on: Seznam, Naver, Yep, and Yandex. They are not on by default, and the reason is not that they matter less than the others. It is that for most sites they matter not at all, and that decision belongs to whoever knows where the readers actually are.
Why Seznam, Naver, Yep and Yandex are a choice
The difference is whether there is anything to weigh.
Bing and the shared endpoint 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 four 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 for others. That is a real decision, and defaults should not make real decisions on somebody's behalf.
The difference is not quality, reliability or treatment: the protocol works the same way for every participant, as described under the IndexNow sequence, end to end. Optional here means optional for you, not lesser in itself. Each of the four is listed with its endpoint in the protocol’s FAQ.
Do your readers use Seznam, Naver, Yep or Yandex?
Which of these engines your readers use decides it.
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 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 know whether your readers use them
Two sources answer it, 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
The default endpoints behave exactly as they did before; adding participants adds destinations rather than changing anything about the existing ones. The shared endpoint already passes submissions on to the engines taking part in the protocol, so switching one of these on adds a direct submission to it rather than being the only way a change could reach it.
- 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.
Should you enable all four engines?
Enabling all of them is 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.
Turning them on later
Nothing about this decision is permanent in either direction, so the stakes are low.
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, set out under what automatic submission covers.
Practically, that means switching one on when a market becomes relevant is a reasonable, undramatic action, and switching it off again when it stops being relevant costs nothing either.
Yep
Yep is a search engine listed among Ahrefs’ products on ahrefs.com, and it takes part in IndexNow. Its endpoint, https://indexnow.yep.com/indexnow, is listed in the protocol’s FAQ. Like every participant, it receives submissions sent to any other endpoint, because the protocol shares them across the engines that take part.
Switching Yep on is the same decision as for the others: worth it where some of your visitors already arrive from it, and harmless where none do. What it does with an announcement is decided on its side, and nothing about the request changes for it.
Yandex
Yandex receives a direct IndexNow submission when you switch it on; Bing and the shared endpoint remain the defaults. Its endpoint, https://yandex.com/indexnow, is listed in the protocol’s FAQ.
Whether it matters for your site is the same question as for the other three: whether a meaningful share of your visitors already arrives from Yandex, or whether you are publishing for a market it serves. Everything on your side is identical for every participant: the same request, the same key file, the same scope. How quickly the engine acts on an announcement, and whether it fetches the address at all, is decided on its side. Google is not part of this at any setting.
FAQ
Is Yandex enabled by default?
No. Bing and the shared endpoint are the defaults, and Yandex is one of four engines you switch on yourself, alongside Seznam, Naver, and Yep. It sits in the optional group because whether a direct submission to it produces anything depends on where your readers are, which is your call rather than ours.
Should I enable Seznam, Naver, Yep, and Yandex?
Only if a meaningful share of your audience uses one of them. They serve regional or specialised audiences, so the answer follows from where your readers are rather than from any property of the engines, and for most sites the honest answer is no.
Why are these not on by default?
Because enabling them is a real decision rather than a free one. The defaults cost nothing to include, so no choice exists; these four produce value only for some sites, and a default that decides that for you would be guessing about your audience.
Does enabling more engines improve anything on the others?
No. Adding participants adds destinations for the same HTTPS message and changes nothing at all about the engines already receiving submissions, nor about how any of them treats what it receives. Each one continues deciding for itself, on its own criteria, exactly as it did before.
Can I enable one later?
Yes, and it takes effect from that point onward. It does not announce pages that already exist and have not changed, because submission follows change detection, so a newly enabled engine learns about your site the ordinary way until something changes.