# Bridge IndexNow — full text

Every published page of bridge-indexnow.com, in build order. Generated from the same sources as the site.

--- https://bridge-indexnow.com/ ---

# IndexNow explained: faster discovery on Bing and Yandex

IndexNow lets a site announce that a page changed, instead of waiting for
an engine to come back and notice. Bridge CDN detects the change at the
edge and submits the URL automatically. When you would rather send a batch
yourself, that is the button, and the log afterwards shows what left, for
which engine, in which mode. What all of it covers is specific, and the
specifics are the whole point of this page.

## You published. Then you waited {#wait}

The gap between changing a page and seeing the change in results is the part
nobody designed. It just happens to you.

**You resubmitted the sitemap.** It lists what exists, which the engine
already had. Nothing in that list says anything changed, so resubmitting it
carries no news.

**You checked the address by hand.** One URL, one form, one answer, and the
answer was that it is known but not reflected yet. Then the next address, and
the one after that.

**You installed something that promised speed.** No tool outside an engine
decides what that engine indexes, whatever it says on the box, and the wait
went on anyway.

So the page sits in an interval with no signal in it. Not broken, not
finished, and not answerable when somebody asks you when it will be live.

Waiting is the default for exactly one reason: nothing has told the engine.
That is the part this fixes, and it is worth being precise about how far
the fix goes.

## Doing it yourself, counted {#by-hand}

The protocol is open, and any site can send to it directly. So the question is not
whether you could run it by hand. It is what running it by hand costs, and
that is easier to judge counted than described.

**Through each engine's own console.** Open an account at the engine's webmaster console, Bing Webmaster Tools first. Prove the domain is yours, by whatever proof that console asks for. Find where it takes addresses by hand. Paste the addresses. Stop when the daily allowance the engine sets for your site runs out; the figure is its own and unpublished. Open
Yandex Webmaster and do all of it again. Do it once more for Seznam, and
again for Naver.

**Or write the protocol yourself.** Generate a key of 8 to 128 characters:
letters, digits and dashes. Serve it as a text file from the site root. Build the request
out of the host, the key and the list of addresses. Keep each batch to ten thousand addresses at most. Schedule it to fire when a page actually changed
rather than on a timer. Decide what happens to a submission that fails.

Seven steps on one route and six on the other, neither of them difficult,
both of them repeated for every engine that joins later. And whatever each
console shows afterwards, it shows only its own.

## Three ways to send the same list {#modes}

The choice is not about speed, and not about which engines take part. It is
about how one list of addresses is spread across the engines you have
switched on, and the three answers differ in a way that is easier to see
than to describe.

**Fallback.** The mode the product recommends. Submit each URL once; retry
the next engine only on failure. Five addresses, five submissions, and a sixth
only where the first attempt was refused.

**Balance.** Spread URLs across your enabled engines, one engine per URL.
Five addresses, five submissions, five different destinations, and no
address sent twice.

**All engines.** Submit every URL to every enabled engine, which is
redundant by design rather than by accident. Five addresses, twenty-five
submissions, the same five pages announced.

Same list, three shapes. Nothing about the pages changes between them, and
nothing about which engines participate. What changes is how much of your
allowance each choice spends to cover the same ground.

## The allowance is counted per engine {#capacity}

There is a ceiling on how much can be submitted, and the useful thing to
know about it is not the figure. It is where the figure applies: the
allowance is counted per engine, not per site and not per batch. What a
mode decides is how many addresses that allowance turns into.

**Fallback spends one allowance per address.** Each address goes to one
engine, so the addresses you can cover come out at roughly one engine's
worth, and a second submission is spent only where the first was refused.

**Balance spends across all of them.** Each address goes to a different
engine, so the addresses covered grow with the number of engines you have
switched on rather than staying at one engine's worth.

**All engines spends every allowance on every address.** The same address
is counted once against each engine, so the ground covered stays at one
engine's worth while the number of submissions multiplies.

That is the whole shape of it, and it is the reason the product recommends
Fallback rather than the mode that sends the most. The figures that apply
to a given plan are published where signup is, at Bridge CDN.

## What automatic submission covers {#scope}

The scope, stated exactly: automatic submission covers discovered and
changed URLs only, enabling it imports no history, and full-site submission
is manual.

Put next to a site of any size, that is a small proportion on most days.
Nothing announces a page that did not change, which is the whole reason the
announcements are worth attending to at all.

Each of those three clauses answers a question people ask after switching
it on, and each answer is the one that disappoints if discovered later.

**Discovered and changed URLs only.** Submission follows change detection.
A page that has not changed is not resubmitted, because there would be
nothing to announce.

**No history is imported.** Enabling submission does not reach back over
pages that already existed. It begins working from the point it is enabled,
forward.

**Full-site submission is manual.** Announcing everything at once is a
deliberate action rather than something that happens on its own, which is
the correct default: an automatic full-site announcement would be noise
every time it ran.

Submission happens automatically at a short interval after a change is
detected, rather than at the instant of the change itself.

## Which engines take part {#engines}

Bing and the shared endpoint are on by default; Seznam, Naver, Yep, and
Yandex take part when you enable them.

**`api.indexnow.org`, on by default.** The shared protocol endpoint. It
passes a submission on to the engines taking part in IndexNow; switching an
engine on below adds a direct submission to it.

**Seznam, Naver, Yep, and Yandex** take part when you enable them. They stay
off because relevance depends entirely on where your audience is, and
submitting to engines nobody reads is effort without return.

## The key file {#key}

IndexNow requires proof that whoever submits a URL controls the site, and
the proof is a file.

A key is generated for your hostname and served at `/<key>.txt` on that
hostname, from the edge. An engine receiving a submission fetches the file
and compares what it finds against the key in the submission. Matching
means the submitter controls the site; not matching means the submission is
refused.

Two details are worth being precise about. The file is served from your own
hostname rather than held on ours, which is what makes it proof of control
at all. And what the engine does with it is a plain comparison against the key in the submission: match or no match, with nothing else read into either answer.

## How you know it left {#log}

Every submission is written down. Not as a promise about what the engine
will do next, which nothing can promise, but as a record of what left this
side: the address, the engine it went to, the mode that decided that, the
time, and whether the endpoint accepted it. The panel below replays a
stretch of such a record, one line at a time; it is an illustration of the
form, not a client’s log.

A failure is written down the same way. In Fallback the next engine is
tried and both lines stay, so the record shows the retry rather than
hiding it. In Balance a second engine is not tried at all, because the
address was allocated to one. Reading the difference between two runs is
the point of keeping the record at all.

Reading a log is not the same as being indexed, and this one does not
pretend otherwise. It answers the question that comes first and usually
goes unanswered: did the thing you asked for actually happen, and where
did it go.

## Google does not participate {#google}

Stated plainly, because it is the assumption that costs people the most
time.

Google is not part of IndexNow and does not receive submissions from it.
No configuration changes that, on this platform or any other. If your
question is how to get pages into Google faster, IndexNow is not the answer
to it, and any product suggesting otherwise is describing something that
does not happen.

What IndexNow does reach are the engines that chose to take part. For sites
where those engines matter, the difference between announcing a change and
waiting to be revisited is real. For sites where only Google matters, this
is not the mechanism you are looking for.

## Submission is not indexing {#not-indexing}

Four different things are involved here, and conflating them is the source
of most disappointment with this protocol.

**Submission** is what this does: telling an engine that a URL changed.

**Discovery** is the engine deciding to look at it. Submission makes
discovery possible sooner; it does not compel it.

**Indexing** is the engine deciding the page belongs in its index. That
decision is the engine's, based on its own criteria, and no signal from
outside makes it.

**Ranking** is where the page appears once indexed, which is a separate
question again and unaffected by how the engine learned of the page.

So the honest description of the benefit is narrow and real: an engine
learns about your change sooner than it otherwise would have. Everything
after that remains entirely the engine's decision.

## Whether this is worth switching on {#fit}

The honest answer depends on who reads you, not on what you run.

**Worth switching on.** You publish or revise pages often, and a real
share of your readers arrives from Bing, Seznam, Naver, Yep or Yandex.
News, catalogues, listings and documentation all change faster than an
engine's own revisit schedule assumes.

**Not the mechanism you need.** Your audience is almost entirely Google,
and the participating engines round to nothing in your analytics.
Announcing a change to engines nobody reads you on is effort spent
without a reader at the other end.

**Worth switching on quietly.** The pages change, the participating
engines are a small share today, and announcing a change you have already
made asks almost nothing of you. That is a judgement about your own
numbers rather than a claim about the protocol.


## Next to what you already publish {#compare}

Three mechanisms, three different questions, and not one of them replaces
another.

**A sitemap answers what exists.** A list of addresses you maintain, read on
the engine's own schedule. It is inventory, and inventory carries no news
that something changed.

**Links answer what leads where.** Discovery through links is how most of the
web gets found, and it works without you doing anything. It is also indirect,
and it says nothing about when.

**A submission answers this changed just now.** One address, named at the
moment it changed. It is the only one of the three that carries timing, and
the only one that does nothing at all for pages that did not change.

Keep the sitemap. Keep the links. Submission is the part that was missing,
not a replacement for the parts that were not.

## Four ways it gets sent {#routes}

A submission is one request. What differs is who makes it, and how much of
your attention that costs.

**By hand.** One address at a time. Useful once, for seeing the whole chain
work before any of it is automated.

**From your content system.** Whatever publishes the change already knows a
change happened, which makes it a natural place to announce one.

**From the delivery layer.** The edge sees the change as it is served, which
is where Bridge CDN does it, with nothing for you to run or keep running.

**From your publish process.** A build or deploy step announces what it just
shipped, which suits sites that publish by deploying.

None of these is more correct than the others, and more than one can be in
use at the same time.

What separates them is not correctness but two other things: what makes each
one fire, and what it leaves behind afterwards. Submitting by hand fires
because you pressed something, and leaves whatever the engine's own console
shows. A content system fires on publish, and leaves whatever the plugin
chose to record. A delivery layer that infers from a cache miss fires on a
guess about what changed, and what it sent is not something you picked or
can read back line by line. Explicit submission from the layer already
serving the traffic fires on a detected change or on your button, and
leaves a log of what went where.

## Where to read further {#learn}

Each section below answers a different question, and none of them requires
you to be a customer to be useful.

- **[How IndexNow works](/how-it-works/)** follows the sequence from a page
  changing to a submission being accepted, and explains what the key proves.
- **[Engines](/engines/)** covers who receives submissions by default, who
  takes part when you enable them, and who takes part in none of it.
- **[Setup](/setup/)** sets out the four ways a submission can be sent and
  what each one asks of you.
- **[Troubleshooting](/troubleshooting/)** starts from the symptom, including
  the most common complaint, which is not a failure at all.
- **[Comparisons](/vs/)** puts submission next to the sitemaps and links you
  already publish, and says what each one actually does.
- **[Tools](/tools/)** checks the key file and a single submission, one
  question at a time.

## Where this lives {#start}

IndexNow submission is part of Bridge CDN rather than a separate product,
so it is configured where the rest of delivery is. Daily submission volume
depends on the plan, and the current terms live where signup does, at
[Bridge CDN](https://bridge-cdn.com/).

## FAQ

**Do I need to configure anything?**
Very little. The key file is generated the first time you save with
submission enabled, and it is served from your own hostname rather than
ours. Bing and the shared endpoint receive submissions by default. The one
choice that remains is the submission mode, and the mode the product
recommends is the one already selected.

**How do I know a submission was sent?**
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 a mode retries
on the next engine both lines stay, so the record shows the retry rather
than hiding it.

**Does IndexNow submit my pages to Google?**
No. Google does not participate in IndexNow and receives nothing from it,
and no setting changes that. Submissions reach the engines that chose to
take part, which is why this page states it in its opening lines rather than
leaving it to be discovered afterwards.

**What does automatic submission actually cover?**
Discovered and changed URLs only. Enabling it imports no history, so pages
that already existed are not announced retroactively, and full-site
submission remains a manual action. Submission follows change detection, so
a page that has not changed is not resubmitted.

**Which search engines receive submissions?**
Bing and the shared endpoint (api.indexnow.org) by default, with nothing to
configure. Seznam, Naver, Yep, and Yandex participate when you enable them,
because whether they are worth submitting to depends entirely on where your
readers are rather than on anything technical about your site.

**What does IndexNow submission cost?**
It is part of Bridge CDN rather than a separately priced product, so there
is nothing to buy on its own. Daily submission volume depends on the plan,
and the current terms are published where signup is, at
[Bridge CDN](https://bridge-cdn.com/).

**Where is my key file stored?**
On your own hostname, served at `/<key>.txt` from the edge. It is not held
on our domain or fetched from your origin, and that placement is exactly
what makes it proof of control: only somebody who controls the hostname can
cause that file to be served from it.

**Will my pages be indexed faster?**
Submission makes an engine aware of a change sooner. Whether it then
crawls, indexes, or ranks the page remains its own decision, made on its
own criteria. Anyone promising indexing within a stated time is describing
something no submission protocol is able to deliver.

**Can I submit my whole site at once?**
Manually, yes. It is deliberately not automatic, because an automatic
full-site announcement would repeat the same claim about every page each
time it ran, which is noise rather than a signal and gets treated
accordingly by the engines receiving it.


--- https://bridge-indexnow.com/engines/ ---

# IndexNow engines: who takes part, and who does not

Bing and the shared endpoint receive submissions without any configuration,
four more engines when you switch them on, and one very large one takes part
in none of it. That last fact shapes expectations more than the rest of this
page combined, which is why it comes first.

## Google does not participate

Google is not part of IndexNow. It does not receive submissions, no setting
enables it, and no provider can arrange otherwise.

This is worth stating flatly because the assumption runs the other way.
Anybody arriving at a page about faster discovery is usually thinking about
one engine in particular, and a page that lets them read to the end without
finding out has failed them. If your entire interest is reaching Google
sooner, this protocol is not the mechanism, and knowing that now is worth
more than any amount of detail about the mechanism itself.

What remains true is that the engines which do take part are meaningful for
plenty of sites, and that the cost of participating is close to nothing once
configured. Whether that trade is worth your attention depends entirely on
where your readers search.

There is also no substitute to point you toward, which is worth saying
rather than implying. Google discovers changes its own way, on its own
schedule, and the tools it offers for asking are its own. Nothing in this
protocol supplements them, and treating the two as alternatives to weigh
against each other misreads what either is doing.

## Who receives submissions by default

Bing and the shared aggregator endpoint, with nothing to configure and nothing to switch on.

Bing and api.indexnow.org are the defaults; Seznam, Naver, Yep, and Yandex
are switched on by you, engine by engine, when they match where your readers
are. For a site with any meaningful audience reached through either,
submission does what it says: a change is announced rather than waited for.
What each of the engines asks of you, and how to tell whether it matters to
your readers, is set out under [Bing](/engines/bing/), [the
aggregator](/engines/aggregator/), and [Yandex](/engines/yandex/).

Both accept the same submission over `HTTPS` and verify it the same way,
against the `/<key>.txt` file published on your own hostname. From your side
there is nothing engine-specific to configure and no second key to place,
which is the other reason these two are simply on rather than offered as a
choice.

The reason this is the default rather than an option is that there is no
downside to weigh. A submission carries no cost to you, no obligation, and
no risk of being penalised for sending one. There is nothing to decide, so
nothing is asked.

## Who takes part when you enable them

Four more, deliberately not switched on for everybody.

Seznam, Naver, Yep, and Yandex participate when you choose to include them.
They stay off by default for one reason: relevance is regional or
specialised, and for most sites submitting to an engine nobody in their
audience uses is effort producing nothing.

The decision is therefore about your readers rather than about the engines.
If a meaningful share of your audience is in a market one of them serves,
enabling it is the same near-zero effort as the defaults. If not, leaving it
off is not a missed opportunity; it is an accurate reflection of where your
readers are.

## The aggregator

One endpoint accepts a submission and passes it to participants, which
changes the arithmetic of sending.

Rather than delivering the same announcement separately to each engine, a
submission can go to a shared endpoint that distributes it, which is set out
under [the aggregator](/engines/aggregator/). What this
changes is the number of outbound messages rather than what any engine
receives: each participant ends up with the same announcement either way.

Its practical value is in reducing the moving parts. Fewer destinations means
fewer places for a delivery to fail and fewer things to observe when
something does. It does not add participants and does not reach anybody who
was not already taking part.

Whether submissions go direct or through it is an implementation choice
rather than something that changes your outcome. It is worth knowing about
mainly so that seeing one endpoint where you expected several is not
mistaken for a fault.

## What this changes for a publisher

Less than the enthusiasm around it suggests, and more than nothing.

The honest description is narrow: for participating engines, a change can
be learned about sooner than it would have been by ordinary revisiting.
That is a real improvement for sites publishing frequently, and it is close
to irrelevant for a site that changes twice a year.

What it does not change is anything about whether a page is worth
indexing, how it ranks, or how it is treated once discovered. Those are the
engine's decisions, made on its own criteria, and no announcement
influences them. That separation is set out on
[how it works](/how-it-works/).

The reasonable expectation, then, is a modest improvement in timing on some
engines and none on the largest, in exchange for a configuration you set up
once. Whether that is worth doing is an easy question at that price and an
impossible one if the price is believed to be higher than it is.

## How this list is kept current

Read from the protocol's own record, and dated.

Which engines take part is decided by the protocol, not by this page. The
protocol's own site, [indexnow.org](https://www.indexnow.org/), publishes the
list of participants and a [submission endpoint for each](https://www.indexnow.org/faq);
that list is the source for this section, and it was last read against these
pages on 3 September 2026. Whether a participant is on by default, offered as
an option, or not offered at all is a decision of the platform rather than a
fact about the protocol, and the two are kept apart here on purpose.

When the list changes, this section changes with it, and the date above
moves. A statement here is as current as that date and no more.

## What this section covers

The pages in this section take each participant separately: Bing, which
receives submissions by default, and what it does with them; the question of
Google and what to do instead; the four engines available on request, Yandex
among them, and how to judge whether any of them matches your audience; and
the shared endpoint, also on by default, that distributes a submission
rather than adding anybody new.

## FAQ

**Does IndexNow submit to Google?**
No. Google does not participate in IndexNow, receives nothing from it, and
no configuration anywhere changes that. If reaching Google sooner is your
only objective, this is simply not the mechanism for it, and no provider can
arrange otherwise on your behalf whatever they imply.

**Which engines receive submissions automatically?**
Bing and the shared endpoint (api.indexnow.org), with nothing to configure.
They are the defaults because there is no trade-off to consider: a
submission costs you nothing, carries no obligation, and creates no risk, so
there is no decision to put in front of anybody.

**Should I enable the optional engines?**
That depends entirely on where your readers are. Seznam, Naver, Yep, and
Yandex serve regional or specialised audiences, so enabling one is
worthwhile when a meaningful share of your visitors uses it, and leaving it
off otherwise is accurate rather than a missed opportunity.

**What does the aggregator endpoint do?**
It accepts a submission and passes it to participating engines, so one
message reaches several destinations. It changes how many outbound messages
you send rather than who receives them, and it adds no participants that
were not already taking part.

**Is IndexNow worth using if I only care about Google?**
No, and that is the honest answer rather than a hedged one. Nothing here
reaches Google at all. The value on offer is timing on the engines that do
participate, so where none of them matters to your audience, the
configuration is effort without any corresponding return.


--- https://bridge-indexnow.com/how-it-works/ ---

# How IndexNow works: from a change to a submission sent

A page changes, the change is noticed, and a short message goes out saying
that this address is worth revisiting. That is the entire mechanism. What
deserves understanding is everything around it: why a key is involved, and
why acceptance is a smaller event than it sounds.

## The sequence, end to end

Five steps, in order, and each one is a place where expectations tend to
run ahead of what happens.

**A page changes.** Something you publish or edit becomes different from
what was there before.

**The change is detected.** Automatic submission follows change detection,
which is why it covers discovered and changed addresses and nothing else.
A page nobody touched has nothing to announce.

**A submission is composed.** It names the address that changed and includes
the key that establishes you are entitled to speak for that hostname. The
message travels as an ordinary `HTTPS` request, which is why no account or
prior relationship is needed anywhere in this sequence.

**An engine receives it and verifies the key** by fetching the key file
from the hostname in the submission. If what it finds matches, the
submission is attributable to whoever controls that hostname.

**The engine decides what to do about it.** This is the step people
misread, and the rest of this page is mostly about it.

## Why a key exists at all

Without one, anybody could submit anybody's addresses, which would make the
signal worthless within a week.

The key is not a secret in the way a password is. It is published, at a
known location, on the very hostname it speaks for. Its purpose is not
confidentiality but attribution: the only party who can cause a particular
file to be served from a particular hostname is the party who controls that
hostname, so a submission that matches proves control without needing any
account, registration, or prior relationship.

That framing explains the details that otherwise look strange. It is fine
that the key is visible to everybody. It is fine that it is a plain file.
Neither weakens anything, because what is being demonstrated is the ability
to place it, not knowledge of its contents.

## Where the key file lives

At a known path on your own hostname, published as `/<key>.txt`, and this is
the part worth being precise about.

The file is served from the address a search engine is asking about, by the
edge, on your hostname. It is not held on somebody else's domain and does
not need to be fetched from your origin. That placement is not an
implementation convenience: it is the entire proof. A key served from
anywhere else would demonstrate control of somewhere else.

The practical consequence is that a key file is per hostname. Several
hostnames means several key files, each served from its own, and a
submission naming one hostname is verified against that hostname alone.

## What a submission claims

Very little, deliberately.

It says that a particular address changed and that whoever sent the message
controls the hostname. It does not describe what changed, argue that the
page is important, or request any particular treatment. There is nothing in
the mechanism to exaggerate with, which is a large part of why engines are
willing to accept it.

It is also worth knowing what the scope of automatic submission is, stated
exactly: it covers discovered and changed addresses only, enabling it
imports no history, and submitting an entire site is a manual action rather
than something that happens on its own.

## What an accepted submission means

That the message was well formed and the key checked out. Nothing further.
The codes an endpoint can return, and what each one means, are set out in the
protocol's own [documentation](https://www.indexnow.org/documentation).

Acceptance is a statement about the submission, not about the page. The
engine has not agreed to crawl the address, has not agreed to index it, and
has certainly not agreed to rank it. Each of those is a separate decision
made on its own criteria, and none of them reports back.

This is the single most useful thing to carry away from this section. A
submission that succeeded and a page that never appears in results are
entirely compatible outcomes, and neither indicates a fault. What
submission changes is when an engine could learn about the change, and that
is genuinely valuable and genuinely narrow.

## Why resubmitting achieves nothing

The instinct after nothing happens is to send it again, and it is worth
explaining why that does not help.

The message carries no urgency, no priority, and no count. Sending it twice
communicates exactly what sending it once communicated, because the content
is identical and the receiving side has already recorded it. Repetition
adds no information for an engine to act on.

Where the page genuinely has not been revisited, the reasons live entirely
on the engine's side and are not addressable from yours. Where the page has
been revisited and simply is not appearing, the question is about the page
rather than about its announcement.

## What this section covers

The sections above walk the sequence end to end: what a submission claims,
what acceptance means, and why resubmitting achieves nothing. One part earns
a page of its own — [the key and its file](/how-it-works/key/), including
why it is published rather than hidden and what an engine does when it
fetches it.

## FAQ

**How does IndexNow actually work?**
A page changes, the change is detected, and a short message naming that
address is sent to participating engines along with a key. The engine
fetches the key file from your hostname to confirm the submission is
attributable to you, and then decides for itself what to do.

**Why does IndexNow need a key?**
So that submissions can be attributed. Without one, anybody could announce
anybody's addresses. The key is published rather than kept secret, because
what it demonstrates is the ability to place a file on a hostname, not
knowledge of a value.

**Is my key file confidential?**
No, and it does not need to be. It is served publicly from your own
hostname, which is exactly what makes it proof: only somebody controlling
that hostname can cause that file to be served there. Visibility weakens
nothing about the arrangement.

**Does an accepted submission mean my page will be indexed?**
No. Acceptance means the message was well formed and the key verified.
Crawling, indexing, and ranking are separate decisions made by the engine
on its own criteria, and a successful submission alongside a page that
never appears is a perfectly ordinary outcome.

**Should I submit the same URL repeatedly?**
No. The message carries no priority or count, so sending it twice says what
sending it once said. If a page is not being revisited, the reasons are on
the engine's side; if it is being revisited and not appearing, the question
concerns the page itself.


--- https://bridge-indexnow.com/setup/ ---

# How to set up IndexNow: four ways to send a submission

The mechanism is the same in every case: a short message naming an address
that changed. What differs is who sends it and when. That second question
decides how much the arrangement is worth, because the entire value of a
submission is that it arrives sooner than an engine would have looked.

## What every method has in common

Two things are true regardless of which route you choose, and both are worth
settling before comparing them.

A key file has to be reachable over `HTTPS` at `/<key>.txt` on the hostname
the submissions are about. That file is what lets an engine attribute a
submission to whoever controls the hostname, which is covered on
[how it works](/how-it-works/). No method skips it, and a method that
appears to skip it is placing the file somewhere on your behalf rather than
doing without one.

The message itself is also identical whichever route sends it: an ordinary
`HTTPS` request naming the address that changed. No route sends a richer
message, and none can ask for different treatment, so choosing between them
is a question about your own operations rather than about what an engine
receives.

The scope is also the same in every case, stated exactly: automatic
submission covers discovered and changed addresses only, enabling it imports
no history, and submitting a full site is a manual action. No route changes
those boundaries. If a method promises to announce everything you ever
published, it is describing the manual action under a different name.

## Sending by hand

The simplest route, and the right one less often than it is used.

Submitting manually means composing the message yourself, one address or a
batch at a time. It needs nothing set up beyond the key file, and it is the
only route available when the site is published in a way that has no
publishing event to hook into: files copied to a server, a page edited
directly, output generated by a process nobody wants to modify.

Its limitation is not effort but memory. Manual submission happens when
somebody remembers, and the announcements that matter most are the ones made
during a busy week when nobody was thinking about announcements. As a
permanent arrangement it degrades quietly, because nothing about it fails
visibly when it stops happening.

It is also the honest choice for a full-site submission, which is a manual
action by definition rather than something to automate.

## Sending from a content system

A class of solution rather than a specific one: the system you publish
through sends the submission when you publish.

What it does is straightforward. The system already knows when a page was
created or edited, so it announces the change at the moment it happens
without anybody remembering to. That timing is the point, and it is a large
improvement over the manual route for anybody publishing regularly.

What to expect of it needs one qualification. The submission is triggered by
whatever that system considers a publishing event, and systems differ on
this. Editing a draft, changing metadata, reordering a listing, or
republishing without changing anything may or may not count. When
submissions appear at unexpected moments or fail to appear at expected ones,
the definition of that event is usually the explanation rather than anything
about the protocol.

## Sending from the delivery layer

The route that asks nothing of the site, because the layer in front of it
already sees what changed.

A layer that serves your traffic is in an unusual position: it observes
addresses being requested and content changing without needing to be told by
the application. That makes it the one route where announcements happen
without any code being written, any plugin being maintained, or any
publishing event being defined by somebody else.

The trade is a matter of where the knowledge lives. A content system knows
what you meant by publishing; a delivery layer knows what actually changed.
For most sites, those coincide often enough that the difference is
theoretical, and the absence of anything to maintain is worth more than the
distinction.

## Sending from your publish process

Integration in your own pipeline, which is the most precise route and the
one that most rewards being done deliberately.

If you build and deploy through a process you control, that process knows
exactly which addresses changed in this release. Announcing them at the end
of a deploy is a few lines in a place you already maintain, sending the same
`HTTPS` request any other route would send, and the accuracy is better than
anything else can offer because nothing is being inferred.

There is one way to do this badly, and it is common enough to name. Sending
submissions on a schedule, such as a nightly job that announces everything
touched that day, reintroduces exactly the delay the mechanism exists to
remove. Announce on the publishing event, not on a timer. A submission a
few hours late is not much better than no submission at all, given that
engines revisit on their own anyway.

## Choosing between them

One question settles it in most cases: what already knows that something
changed?

If your publish process knows, use it. If a content system knows, let it
send. If neither has a usable event and the site changes often, the delivery
layer is the route that needs no such event to exist. Manual submission is
for the cases that fall outside all three, and for full-site submissions,
which are manual by nature.

The methods are not additive. Two routes announcing the same change do not
announce it twice as effectively; they produce duplicate messages that say
the same thing, for the same reason that
[resubmitting an address](/how-it-works/) achieves nothing: the message
carries no priority and no count. Pick one route and let it be the only one.

## What this section covers

The four routes are compared above, each by what makes it fire and what it
leaves behind. One of them earns a page of its own — [sending from the
delivery layer](/setup/edge/), and why that route needs nothing from the
site itself.

## FAQ

**How do I set up IndexNow?**
Publish a key file on the hostname you are announcing for, then choose how
submissions are sent: by hand, by your content system, by the layer
delivering your traffic, or by your own publish process. The routes differ
in who does the work and when, not in what the engine receives.

**Which setup method is best?**
Whichever component already knows that something changed. A publish process
knows precisely; a content system knows at publishing time; a delivery layer
knows without being told. Manual submission covers what is left, including
full-site submissions, which are a manual action rather than an automated
one.

**Does IndexNow submit my whole site automatically?**
No. Automatic submission covers discovered and changed addresses only,
enabling it imports no history, and a full-site submission is a manual
action. Any description promising to announce everything you have ever
published is describing that manual action under a more comfortable name.

**Can I use more than one method at once?**
You can, but there is no benefit. Two routes announcing the same change
produce two identical messages rather than a stronger signal, and they make
diagnosing an unexpected submission harder because two things could have
sent it. Choose one route and keep it as the only one.

**Should I submit on a schedule?**
No. A timed job announcing the day's changes reintroduces the delay the
mechanism exists to remove, which leaves you with the configuration effort
and very little of the benefit. Announce on the publishing event, whatever
that event is in your setup.


--- https://bridge-indexnow.com/tools/ ---

# IndexNow tools: key checks and a submission test

Three checks, and all of them are about the same thing: whether the parts
you control are in the state the protocol expects. None of them tells you
anything about indexing, because nothing can, and a page offering that would
be selling you a guess.

## What gets checked

**The key and its file name.** The key and the file name that serves it have
to agree exactly, and a mismatch between them is invisible until an engine
tries to read the file — a common way to spend an afternoon. Generating the
pair together, rather than typing either by hand, prevents the disagreement
outright.

**What the hostname returns.** Fetching the key file from your hostname the
way an engine would shows what actually comes back: the file, a redirect, or
a page rather than plain text. Those are exactly the failure shapes on [key
not found](/troubleshooting/key-not-found/), and the check has a page of its
own.

**What the engine answers.** A single address, submitted and read back,
separates a submission problem from everything else you might be
investigating. What an accepted submission does and does not mean is set out
on [how it works](/how-it-works/), and it is less than most people assume.

## What none of them can tell you

One boundary, and it applies to all three.

No check here reports whether a page was indexed, when it will be, or
whether an engine intends to. Submission is an announcement that an address changed, and the decisions
that follow it are the engine's, made on its own criteria and never reported
back. A check claiming otherwise would be inventing an answer.

What these do instead is confirm the half you control: that the key is
correct and reachable, and that a submission is accepted rather than
rejected. When something is wrong, that half is where it almost always is,
and [troubleshooting](/troubleshooting/) sorts the rest by symptom rather
than by response code.

That division is worth keeping in mind while using them. A clean result from
all three means your side is correct, not that anything has happened at the
engine, and those are different kinds of good news. What the key itself
proves, and why it is public by design, is set out under
[the key file](/how-it-works/key/).

## FAQ

**Do these checks need an account?**
No. Everything they look at is public by design: the key file is served
openly from your hostname, and a submission is answered by the engine's own
endpoint. Checking either involves only what is already served publicly,
which is the same thing an engine reads.


--- https://bridge-indexnow.com/troubleshooting/ ---

# IndexNow troubleshooting: start from what you observed

Most trouble with submissions falls into a handful of shapes, and telling
them apart takes one question rather than a search through logs. The
complication is that the single most common complaint is not a malfunction
at all, so the first thing worth establishing is whether anything is
actually broken.

## The first question: was the submission rejected or accepted?

Everything downstream depends on this, and the two branches have almost
nothing in common.

A **rejected** submission means the engine declined to take it. Something
about the message or the key did not check out, the cause is on your side,
and it is fixable. These are real faults with real remedies.

An **accepted** submission means the message was well formed and the key
verified. That is all it means. If the complaint is that a page has not
appeared anywhere, and the submission was accepted, then nothing in the
submission chain is broken and no amount of adjusting it will change the
outcome, for reasons set out on [how it works](/how-it-works/).

Sorting the symptom into one of those two branches saves more time than any
other diagnostic step, because the second branch has no fix in it at all.

## When the key is the problem

Most rejections are about the key, and they split into two distinct
situations that get confused with each other.

**The key file cannot be read.** The engine went to fetch `/<key>.txt` over
`HTTPS` from your hostname and did not get it. The usual causes are not
exotic: the file is not where it is expected, the request is redirected
somewhere else, or what comes back is an `HTML` page rather than the plain
text that was asked for. A friendly error page returned instead of the file
is a particularly common version, because to a human it looks like the site
is working.

**The key file was read but not accepted.** The file exists and was
fetched, and its contents did not match what the submission claimed. This
is a different problem with different causes, and treating it as the first
one leads to a lot of pointless checking of paths that were correct all
along.

Both are worth distinguishing before touching anything, because the checks
that resolve one tell you nothing about the other.

## When the address is the problem

A submission names an address, and an address that does not belong to the
hostname being verified cannot be accepted.

This sounds like an unlikely mistake and is not. It appears whenever
submissions are generated from a list that outgrew its assumptions:
addresses on a subdomain that has its own `/<key>.txt`, addresses under a
scheme other than the `HTTPS` one that was verified, or addresses copied
from a staging environment that survived into production. The pattern is
always the same, which is that the sending side believes it is speaking for
a hostname it has not proven control of.

The remedy is structural rather than per-address. What sends submissions
should derive addresses from the same place the key belongs to, so the two
cannot drift apart.

## When submissions are too frequent

Engines limit how much they will accept, and the response to that limit is
where sites make things worse.
The protocol's [own FAQ](https://www.indexnow.org/faq) says each engine sets its
own daily thresholds per site and does not publish the figures.

The useful thing to know is that the limit is not a punishment and does not
reflect on your site. It exists because the mechanism is cheap to use, and
anything cheap to use has to be bounded. Being limited today says nothing
about tomorrow.

What not to do is retry immediately, and then retry again. Repetition
carries no additional information for an engine to act on, so a resubmitted
address communicates exactly what it communicated the first time while
consuming the allowance that would have carried a genuinely new change. If
you are hitting a limit regularly, the question to ask is what is generating
so many submissions: a route announcing changes that are not really changes
is a far more common cause than a site that genuinely publishes at that
rate, and that usually leads back to how submissions are being sent, which
is covered under [setup](/setup/).

## When everything worked and nothing happened

This is the most frequent report of all, and it deserves the plainest
possible answer: an accepted submission is an announcement received, not an agreement to index and certainly not one to rank.

The engine decides for itself whether an address is worth crawling, whether
what it finds is worth keeping, and where it belongs among everything else.
None of those decisions reports back, none of them is influenced by how the
address was announced, and any of them can go the other way for reasons that
have nothing to do with submission. A page that was announced correctly and
never appears is an ordinary outcome, not evidence of a fault.

What submission changes is when an engine could learn that something
changed. It is worth having for that alone. It is not worth troubleshooting
for an outcome it never controlled.

## When you are not sure anything was sent

A separate question from all of the above, and the one that most often comes
first after switching submission on.

Before diagnosing a rejection or an absence, it is worth confirming that a
submission happened at all. Change detection is what triggers automatic
submission, so an edit that produced no detectable change produces no
announcement, and a site whose addresses have not changed has nothing to
send. An absence of submissions is sometimes exactly correct behaviour.

Establishing what was sent, and what came back, is the step that turns every
other question on this page from speculation into diagnosis.

## What this section covers

The symptoms are sorted above, organised by what you observed rather than by
what an engine returned, because the symptom is what you have when you
arrive. The commonest of them earns a page of its own — [a key file that
cannot be read](/troubleshooting/key-not-found/), and the several ways a
site can serve something other than the file itself.

## FAQ

**My IndexNow submission failed. Where do I start?**
Establish whether it was rejected or accepted. A rejection is a real fault
with a cause on your side, usually the key file or the address being
submitted. An acceptance followed by nothing visible is not a fault at all,
and treating it as one leads to hours of adjusting something that already
worked.

**Why does the engine say my key file cannot be read?**
Because the fetch did not return the file. The usual causes are that it is
not at the expected location, that the request is redirected elsewhere, or
that a formatted page comes back instead of plain text. The last one hides
well, since a friendly error page looks perfectly healthy to a person.

**I submitted the page and it is still not indexed. What now?**
Nothing, and that is the honest answer. Acceptance means the message was
valid and the key verified; crawling, indexing, and ranking are separate
decisions the engine makes on its own criteria. A correctly announced page
that never appears is an ordinary outcome rather than a malfunction to fix.

**What should I do when submissions are rate limited?**
Not retry. Repetition adds no information and spends the allowance a real
change would have used. Look instead at what is generating the volume, since
a route announcing things that are not really changes is a more common cause
than a site that genuinely publishes at that rate.

**How do I know a submission was sent at all?**
Confirm that before diagnosing anything else, because every other question
here assumes it. Automatic submission follows change detection, so an edit
that changed nothing detectable produces no announcement at all, and an
absence of announcements is sometimes the correct behaviour rather than a
fault worth investigating further.


--- https://bridge-indexnow.com/vs/ ---

# IndexNow vs the ways you already announce pages

A sitemap, an internal link and a submission all tell an engine that a page
exists, and they are routinely discussed as alternatives to one another.
They are not: each answers a different question, and a site that publishes
regularly usually wants more than one of them working at once.

## Three different questions

The confusion dissolves once you see what each mechanism is actually
answering.

**A sitemap answers "what exists".** It is an `XML` list of addresses you
consider worth knowing about, published at a fixed place for anybody who
reads such lists. It says nothing about when a page changed and asks for
nothing in particular; it is inventory, and inventory ages quietly.

**Links answer "what leads where".** Discovery through links is how most of
the web gets found: a crawler arrives at a page it already knows and follows
what it sees there. This is the oldest of the three mechanisms and the only
one that also carries a signal about how the pages relate to each other,
which is information the other two cannot express at all.

**A submission answers "this changed just now".** It names one address over
an ordinary `HTTPS` request and says the content behind it differs from
before. It carries no inventory, no relationships, and no request for
treatment. Its only contribution is timing, which is also its only claim.

Read that way, the categories stop competing. A list of everything, a map of
how things connect, and a notification that something moved are three
different kinds of information, and no one of them contains the others. The
question "which should I use" turns out to be several questions wearing one
coat, and each has its own answer.

## Why a sitemap is not replaced

This is the comparison people actually mean when they ask, and it deserves a
direct answer rather than a diplomatic one.

A sitemap remains useful for exactly the cases a submission cannot cover:
pages that exist but have not changed, pages nothing links to, and the
initial discovery of a site nothing knows about yet. None of those produce
an event, and submission only works from events. It is also read on the engine's schedule rather than on
yours, which is a weakness when timing matters and a strength when
completeness does.

A submission is the opposite: precise about one page at one moment, silent
about everything else. Turning it off does not make your sitemap worse, and
turning it on does not make your sitemap unnecessary. They fail differently
too. A stale sitemap misleads about what exists, while a missed submission
simply means the change is found the way it would have been found anyway.

The pairing that works is simply both, with each doing what it is good at
and neither asked to do the other's job. Where
they conflict, they do not: an engine reading your sitemap and receiving
your submissions is receiving inventory and timing rather than two versions
of the same claim. The comparison is taken apart in full under
[IndexNow vs sitemap](/vs/sitemap/).

## Where Google fits, and does not

Worth saying here because the comparison is incomplete without it.

Google does not participate in IndexNow at all, so for that engine
submission is not one of the options being compared. It has its own means of
discovery and its own interface for site owners who want to ask about a
specific address, and describing how that interface behaves accurately
requires citing its documentation rather than paraphrasing it, which is why
this section names it rather than explaining it.

What that means practically is on [the Google page](/engines/google/), which
answers the question directly rather than leaving it implied. The short
version: for that engine, none of this section's comparisons apply, because
submission is not among the mechanisms available at all.

## What none of them do

One boundary shared by all three, and it is the one most often blurred.

None of these mechanisms causes indexing. A sitemap lists, a link points,
and a submission announces, and in every one of those cases what happens
next is the engine's own decision, made on its own criteria and never
reported back to you. That separation
holds identically for all three, and it is set out under
[how it works](/how-it-works/).

Which means the choice between them is never about which one gets you
indexed. It is about which kinds of information about your site you want an
engine to have, and for most sites the answer is more than one of them.

It also means a disappointing outcome is rarely evidence that you picked the
wrong mechanism. A page that was listed, linked and announced and still does
not appear has passed through all three successfully; what remains is a
judgement none of them influences.

## What this section covers

The comparison that gets asked most — [sitemaps against
submission](/vs/sitemap/), in detail and with the cases each covers alone —
has a page of its own. How submission relates to the interface Google
provides for its own engine is answered under [the Google
page](/engines/google/). Both are written the same way as this page, by
separating what each mechanism is for rather than by scoring them against
each other.

## FAQ

**Does IndexNow replace my sitemap?**
No. A sitemap is inventory of what exists, and a submission is notice that
one thing changed. Sitemaps still cover pages that have not changed, pages
nothing links to, and the discovery of a site nothing knows about yet, none
of which a submission addresses.

**Should I use both a sitemap and IndexNow?**
Usually yes, because they carry different information rather than competing
versions of the same claim. The sitemap tells an engine what your site
contains and is read on the engine's schedule; submission tells it that one
thing changed, at the moment it changed. Neither weakens the other.

**Is IndexNow better than waiting for a crawler?**
It can reach the engines that participate sooner, and it changes nothing else
about them. Crawling still happens, discovery through links still works, and
whether a page is worth keeping is still decided the same way it always was.
The speed of the notification is the entire difference, and it applies only
where the engine takes part.

**Does any of this guarantee indexing?**
No, and no mechanism anywhere does. Listing, linking and announcing all end
at the same point: the engine decides, on criteria of its own, and none of
the three receives any answer about what it chose. Anything sold as a
guarantee here is selling a decision that is not the seller's to make.


--- https://bridge-indexnow.com/engines/aggregator/ ---

# The IndexNow aggregator: one endpoint, same engines

A shared endpoint that accepts a submission over `HTTPS` and passes it on to
participating engines, instead of each engine being told separately. It
changes how many messages leave your side, and it does not change who ends
up receiving them or what they do next.

## What it actually changes

One thing changes, and it is worth being precise about it, because the word
itself invites considerably larger expectations.

Without it, announcing a change means sending the same message to each
participating engine in turn, one connection after another, and handling
whatever each of them answers. With it, the message goes to one place and is
distributed from there. The engines receive the same announcement either way, and each of them still
makes its own decision about what to do with it, on its own criteria and its
own schedule.

So the change is in the number of outbound messages: not in reach, not in
how any engine treats what it receives, and not in the speed of anything
that happens afterwards. A
submission is still an announcement that an address changed, exactly as described on
[how it works](/how-it-works/).

## Why fewer destinations is worth something

Two practical reasons, both of them operational rather than strategic, and
both modest.

**Fewer places to fail.** Every destination is an `HTTPS` connection that
can be refused, time out, or return something unexpected. Sending to one instead of
several reduces the number of ways a submission can partly succeed, which is
the state hardest to reason about.

**Fewer things to observe.** When something is not working, the question
"which engine did not receive it" is considerably harder to answer than "did
the submission leave at all". One destination makes the first question rarer, which matters most
when you are diagnosing rather than when everything works.

Neither reason involves reaching more engines than before, and any
description implying otherwise is describing something other than this.

There is also a small reason to know it exists even if you never choose it.
Descriptions of the protocol list endpoints, and a list containing something
that is plainly not a search engine looks like an error in the documentation
until you know what that entry actually is.

## Neither route is the recommended one

Worth stating, because pages like this usually end with a preference.

The engines cannot tell how a submission reached them in any way that
affects their decision, so the outcome is identical. What differs is what
your side looks like: one connection to watch or several, one place where a
delivery problem shows up or several. Teams that already monitor outbound
requests carefully often prefer the direct route for exactly that reason,
and teams that do not prefer having less to watch.

Choosing on that basis is entirely reasonable. Choosing on the basis of
reach is choosing on something that does not vary between the two.

## What it does not do

Three limits, and the first is the one the name suggests most strongly in
the wrong direction.

**It does not add participants.** The engines reachable through
`api.indexnow.org` are exactly the engines that take part in the protocol. Google is not among them, and no
routing changes that, which is set out under
[the Google page](/engines/google/).

**It does not guarantee delivery to each participant.** It accepts a
submission and passes it on; what each engine then does about it remains
that engine's business entirely. A submission accepted here is a message accepted, and
nothing beyond that.

**It does not replace the direct route.** Sending to engines individually
remains perfectly valid, and neither approach achieves more than the other
in anything an engine ends up doing. The choice is about how many outbound connections you
prefer to maintain and observe.

## Where the confusion comes from

The word is doing most of the damage, and it is worth naming why.

In most contexts an aggregator collects things from many sources and
presents them together, which implies breadth: more sources, more coverage,
more than you had. Here it works in the opposite direction. It takes one
thing from you and hands it to several, and the several were always
reachable anyway.

That inversion in the direction of flow is why the same underlying question
keeps being asked in several different forms: whether using it means reaching engines you otherwise would not, and
whether not using it means missing some. Both answers are no, and both
follow from the direction of flow rather than from anything about the
implementation.

## Seeing one endpoint is not a fault

Worth saying plainly, because this is the specific situation that brings
most people to a page like this one in the first place.

If you expected several destinations in your configuration or in your logs
and you see exactly one, nothing is wrong with the setup. That is the aggregator doing its job, and the
participating engines are being told through it rather than by you directly.
The number of endpoints is not a measure of coverage.

Where you do want to check something, the useful question is whether
submissions are leaving at all, and what came back when they did. Both are
sorted by symptom rather than by response code under
[troubleshooting](/troubleshooting/), and neither becomes easier or harder
because of which route you chose.

## FAQ

**What is the IndexNow aggregator for?**
It accepts a submission and passes it on to participating engines, so one
message leaves your side instead of several separate ones. The engines
receive the same announcement either way; what changes is only the number of
outbound connections you have to make and keep an eye on.

**Does using it reach more search engines?**
No. It reaches the engines that participate in the protocol, which is the
same set you would reach by sending to each of them directly. Nothing about
routing turns a non-participant into a participant, and Google does not take
part through this route or any other.

**Should I submit directly or through it?**
Either works, and the difference is operational rather than strategic.
Direct submission means more connections to maintain and observe; the shared
endpoint means fewer of them, with the same engines receiving the same
message and reaching their own conclusions in both cases.

**Why do I only see one endpoint configured?**
Because that is exactly how the aggregator appears: one destination standing
in for several. Seeing a single endpoint where you expected a list is the
expected result rather than a sign that some engines are being missed, and
nothing needs correcting.


--- https://bridge-indexnow.com/engines/bing/ ---

# IndexNow and Bing: on by default, and what it does

Bing receives IndexNow submissions by default, with nothing for you to switch
on and no engine-specific setup to do. What that buys is announcement rather
than indexing, and the difference decides whether the arrangement looks like
it is working or looks broken. This page is about that difference.

## What is switched on

Bing is the one engine that receives submissions without being asked.

In practice that means fewer moving parts than people expect. There is no
second key to place for it, no separate credential to hold, and no per-engine
account to connect. Submissions travel as an ordinary `HTTPS` request, and
verification happens against the same `/<key>.txt` file published on your own
hostname that every participant checks, so the setup that covers one
participant covers this one too.

The scope is narrower than the word "automatic" usually implies, and it is
worth having in the exact words: automatic submission covers
discovered and changed URLs only; enabling it imports no history; full-site
submission is manual. Turning it on is not a backfill, and a site enabling it
today does not thereby announce everything it published last year.

The other default is the shared endpoint, api.indexnow.org, which passes a
submission on to the engines taking part in the protocol. Which of the
engines you enable yourself matters to you is a question about your readers,
and it is covered on [the engines overview](/engines/).

## What a submission asks for

An announcement, not a request, and the distinction is the whole subject.

A submission says that an address changed. It does not say the page is worth
indexing, does not ask for it to be indexed, and carries no argument about
where it should appear. Whether to fetch it, whether to index what it finds,
and how to treat the result afterwards are three separate decisions the
engine makes on its own criteria and its own schedule, exactly as it would
have made them without any announcement at all.

The name the industry has settled on works against this. "Instant indexing"
is how the technique is usually searched for, and every word of that phrase
overstates what happens: nothing is instant, and nothing here indexes
anything. What genuinely changes is that the engine can learn about a change
sooner than by revisiting the page on its own rhythm. The mechanics of that
are set out on [how it works](/how-it-works/).

## The check that misleads people

Almost everybody checks the same way, and that way answers a different
question than the one being asked.

The instinct is to search for the page and see whether it is there. That
result folds together three decisions, only the first of which involves your
site at all: whether the submission was delivered, whether the engine chose
to fetch the address, and whether it chose to index what it found and show
it for that query. An absence does not tell you which of the three failed.

The check that answers something is about delivery. Was the submission
accepted, and is the key file reachable at your own hostname from outside
your network? Both are questions with definite answers, they are the only
part of the chain you control, and when they are both fine, the rest is the
engine's decision rather than a fault to hunt for. The failure modes worth
knowing are gathered under
[troubleshooting](/troubleshooting/).

## Where the engine's own tools sit

Bing offers its own tooling for site owners, and it is separate from this.

Those tools belong to the engine, are documented by it, and change when it
decides they change, so describing their behaviour here would mean going
stale without notice. What can be said accurately is the relationship: the
protocol does not replace them, using one does not require the other, and
neither is a substitute for the other's purpose. A site can reasonably use
both, or either, without the two interfering.

Worth saying plainly for the same reason: Google is not part of any of this,
and no arrangement involving Bing changes that. That question has
[a page of its own](/engines/google/), because it is asked more than every
other question about this protocol combined.

## What makes a submission produce nothing

Four cases, and all four are on your side of the exchange rather than the
engine's.

**An address that does not resolve or redirects elsewhere.** Announcing a
change at an address that answers with something other than the page is a
contradiction, and it resolves the way you would expect: the announcement
produces nothing.

**A page excluded by your own configuration.** If `robots.txt` or a
directive on the page itself tells crawlers not to fetch an address, the
announcement does not override that. The two instructions are read as what
they are, and the exclusion stands.

**A page that has not actually changed.** Repeated submission of unchanged
addresses is outside what the scope above describes and does nothing useful
in any case.

**A key file that stopped being served.** Verification is checked at the time
of submission rather than once at setup, so a hostname change or a rule that
starts intercepting the path removes verification quietly, while everything
else about your site keeps working normally.

## What to expect

A narrow, real improvement, and no figure attached to it.

For a site publishing frequently, changes can be learned about sooner than
ordinary revisiting would manage. For a site changing twice a year, this is
close to irrelevant, and that is worth knowing before configuring anything.
For every site, it leaves ranking untouched, because nothing in an
announcement addresses it.

No number belongs here. How quickly any engine acts on an announcement is its
own scheduling decision, made across everything else it is doing, and a
provider quoting you a figure for it is describing a schedule it does not
control. The honest shape of the promise is timing, not volume and not
placement.

## FAQ

**Do I need to configure anything for Bing?**
No. It receives submissions by default, together with the shared endpoint,
verified against the same key file on your own hostname that every
participant checks. There is no separate key, credential, or account for it,
which is why enabling submission at all is the entire configuration step.

**Will submitting to Bing get my page indexed?**
No, and no submission to any engine does that. An announcement says an
address changed; whether to fetch it, index it, and show it are separate
decisions made on the engine's own criteria. The improvement on offer is in
when a change can be learned about, not in what is decided afterwards.

**Does enabling this submit my whole site?**
No. Automatic submission covers discovered and changed `URLs` only, enabling
it imports no history, and full-site submission is manual. A site switching
it on today announces what changes from that point onward, rather than
everything it has ever published, and an existing archive stays exactly as
discoverable as it already was.

**I submitted and the page is still not in results. What is wrong?**
Possibly nothing. Searching for the page tests delivery, fetching, indexing,
and query matching all at once, so an absence identifies none of them. Check
the two things you control: that the submission was accepted and that the key
file is reachable from outside your network.

**Does this replace Bing's own webmaster tools?**
No, and it is not intended to. Those are the engine's own, serve their own
purposes, and are documented by it. The protocol adds a way to announce
changes; it does not remove a reason to use anything else, and the two do not
interfere with each other.


--- https://bridge-indexnow.com/engines/google/ ---

# Does IndexNow submit to Google? No, and here is why

Google does not participate in IndexNow. It receives no submissions from the
protocol, no setting anywhere enables it, and no provider can arrange
otherwise. This page exists because the question is asked constantly, is
usually answered evasively, and deserves a page that answers it in the first
sentence instead.

## The plain answer

No part of IndexNow reaches Google.

> **Google does not take part in IndexNow.** It receives nothing from a
> submission, on this platform or any other, and no setting changes that.

Submissions travel as an ordinary `HTTPS` request to the engines that take
part in the protocol. Google is not among them, so a submission is neither
delivered to it, nor queued for it, nor partially honoured by it. There is no
mode, plan, or configuration in which that changes, and a provider claiming
otherwise is describing something else under this protocol's name.

This is worth stating without hedging because the hedged version is
actively harmful. A page saying that submission "notifies major search
engines" lets a reader conclude the opposite of the truth while remaining
technically defensible, and the reader finds out weeks later, having spent
that time believing a change was announced when it was not.

## Why it is structured this way

Participation is each engine's decision, not a technical limitation.

The protocol is open: any engine can accept submissions, and the ones that
do have chosen to. Google has not, and the reasons are its own to state
rather than ours to guess. What can be said accurately is that the absence
is a policy position rather than an incompatibility, so nothing about your
site, your configuration, or your provider is the cause.

That distinction matters more than it looks. An incompatibility is something
somebody could fix, which is why the assumption that one exists sends people
looking for the fix. A decision by another party is not a fault in anything
you control, and treating it as one is how an afternoon disappears into
comparing settings that were all correct.

That also means there is no workaround, and the phrase is worth being blunt
about. Sending the same submission through a different route, enabling more
participants, or using the shared `api.indexnow.org` endpoint: none of those
makes a non-participant into a participant.

It is also why the question keeps returning in a particular form. People ask
whether a specific provider or plugin can do it, on the reasonable
assumption that a limitation of one implementation might not be a limitation
of another. Here it is neither: the boundary sits at the protocol, above
every implementation of it, so the answer is the same for all of them.

## What this means in practice

Two consequences, and they point in different directions.

**If Google is your only concern, this protocol is not your mechanism.**
That is the honest answer, and knowing it now is worth more than any amount
of detail about how submission works. Nothing on this site will change that
conclusion, and a page that led you around it before admitting so would have
wasted your time.

The corollary is worth stating too, because it saves a second round of
investigation: there is nothing further to evaluate here. Comparing
providers, reading their documentation, or asking support about it produces
the same answer each time, since the boundary is not theirs to move.

**If other engines matter to your audience, the calculation is separate.**
Participation costs almost nothing once configured, and the value is timing
on the engines that do take part. Whether that is worth having depends on
where your readers search, which is set out under
[which engines take part](/engines/). The mechanics of what a submission
does and does not claim are on [how it works](/how-it-works/).

Those two are not in tension, though they are often read as if they were. A
site can reasonably conclude that IndexNow is worth enabling and that it does
nothing at all for the engine it cares about most, both at once and without
contradiction.

## What affects discovery on Google instead

Here the honest answer is narrow, and this page will not pad it out to look
more generous than it is.

Google discovers changes its own way, on its own schedule, using its own
signals, and it provides its own tools for site owners who want to ask about
a specific address. Those belong to Google's documentation rather than to
ours, and pointing at them accurately means pointing at them by name rather
than paraphrasing behaviour that changes without notice.

What can be said generally, and holds regardless of engine, is that
discovery follows from being reachable and being linked. A page that is
served reliably, is not excluded by your own configuration, and is
referenced from somewhere already known is in the best position anybody can
put it in. That is not a trick, and it is not specific to any engine, which
is exactly why it survives changes in engine behaviour.

There is no additional lever, and any product claiming one is claiming
influence over decisions that are not for sale. Where a page changed and you
want it looked at sooner, the tools the engine provides for that purpose are
its own, and using them is the whole of what is available.

## FAQ

**Does IndexNow notify Google?**
No. Google does not participate in the protocol, so no submission reaches
it through any route, provider, or configuration. Anything described as
sending IndexNow submissions to Google is either mistaken or describing a
different mechanism entirely under a name that carries more recognition.

**Is there a workaround to reach Google through IndexNow?**
No, and the question is worth retiring rather than researching further.
Participation is a decision each engine makes, so no amount of routing,
aggregating, or reconfiguring turns a non-participant into one. A provider
offering such a workaround is describing something other than this
protocol, whatever it happens to call it.

**Should I still enable IndexNow if I care mainly about Google?**
Only if the participating engines matter to some part of your audience. The
cost is close to zero once it is set up, so the real question is whether any
of those engines reaches your readers at all. Where none of them does, the
honest answer is that enabling it earns you nothing worth the attention.

**Might Google join later?**
Nobody outside Google can answer that, and this page will not speculate
about it. Treat the present state as the state. If it ever changes, the
change will be announced by the engine itself rather than inferred from a
provider's marketing page, and this site will follow that announcement
rather than anticipate it.


--- https://bridge-indexnow.com/engines/opt-in/ ---

# 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 these are a choice and the others are not

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 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](/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.** 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](/engines/google/).

**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](/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

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


--- https://bridge-indexnow.com/engines/yandex/ ---

# IndexNow and Yandex: when to switch it on

Yandex receives a direct IndexNow submission when you switch it on. Bing and
the shared endpoint are the defaults, and Yandex sits with Seznam, Naver,
and Yep among the engines you enable yourself. The question this page
answers is not how that works but whether to switch it on, because it is the
one thing about this participant people actually stop to think about.

## Why it is an option rather than a default

Four participants are offered as choices, and this is one of them.

Bing and the shared endpoint are on without any configuration. Seznam,
Naver, Yep, and Yandex are off until you enable them, when they match your
audience. The line between the two groups is not popularity in the abstract
but whether there is a decision worth putting in front of somebody, and for
Yandex there is one.

That is worth unpacking, because "optional" is easy to read as "less
important". Here it means something narrower. Whether a direct submission to
this engine produces anything depends on whether your readers use it, and
only your own data shows that. When the branches of a decision lead to
different outcomes, the honest default is to ask rather than to pick, as
[the optional engines](/engines/opt-in/) sets out for all four.

## Whether it matters for your site

The honest answer is that your own data has it and this page does not.

Any claim about where an engine is used, by whom, and in what share is a
claim with a date on it, and a page that made one would be quietly wrong
within a year of being written. What does not go stale is the method: look at
where your existing visitors arrive from, and at which search sources already
send you anybody at all. If this engine appears there, it matters to you. If
it does not, it does not, and no general statement about markets changes
either answer.

That check is worth doing once rather than reasoning about repeatedly. It
takes minutes, it uses data you already have, and it settles a question that
otherwise gets re-argued every time somebody new looks at the configuration.

There is a second case the data will not show you, and it is worth naming:
publishing in a language or for a market you are trying to enter rather than
one you already reach. Existing traffic cannot tell you about an audience you
do not have yet. That is a judgement about intent rather than a measurement,
and it is the one situation where the answer comes from your plans instead of
your analytics.

## What switching it on costs

Nothing that shows up anywhere, which is why the choice can rest on your
readers alone.

Submission happens as part of announcing a change you were making anyway. One
additional destination does not add a step to your publishing, does not
require anything on the page, and does not change what visitors receive.
There is no per-engine setup to maintain, because verification uses the same
`/<key>.txt` file on your own hostname that every participant checks.

The mirror of that is also true and less often said: switching it on buys
you nothing if nobody in your audience searches there. Submissions to an
engine your readers do not use produce nothing, and enabling one for
completeness leaves a setting that later reads as a claim about an audience
the site does not have. A setting that differs from the default should carry
a reason somebody can still state in six months.

## What is identical, and what is not

From your side, nothing here is engine-specific.

The same `HTTPS` submission, the same verification against the same file,
the same scope: automatic submission covers discovered and changed `URLs` only,
enabling it imports no history, and full-site submission is manual. Anything
you set up for one participant is already in place for the others, which is
why this section is short.

What differs between engines lives on their side and is not visible from
yours. How quickly a participant acts on an announcement, whether it fetches
the address at all, and what it does with what it finds are its own decisions
on its own schedule. Those differences are real, but they are not settings,
not observable from your configuration, and not something a provider can
adjust on your behalf. The boundary between the announcement and the
engine's decision is set out on [how it works](/how-it-works/).

| What is involved | Where it is decided |
|---|---|
| The submission request and its format | Your side, identical for every participant |
| Verification against the key file | Your side, one file for every participant |
| Scope: discovered and changed `URLs` only | Your side, identical for every participant |
| How quickly an announcement is acted on | The engine's side, not a setting |
| Whether the address is fetched at all | The engine's side, not a setting |
| What is done with what is found | The engine's side, not a setting |

The practical consequence is that troubleshooting is never engine-specific
either. A submission that fails, fails for a reason on your side, and the
same checks apply whichever participant was involved. Those are covered on
[the Bing page](/engines/bing/), which describes them once for all of them.

## What to expect

Timing on discovery, on the engines that participate, and nothing else.

For a site publishing frequently and reaching readers who use this engine,
changes can be learned about sooner than by ordinary revisiting. For a site
whose audience is elsewhere, the accurate expectation is no observable
difference, which is why the setting starts off and waits for a reason.

What it does not touch is ranking, which is decided on the engine's criteria
and unaffected by any announcement. And Google is not part of this at any
setting, a fact worth repeating here because the assumption survives being
told once.

## 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 switch it on if my audience is not there?**
There is nothing to gain by doing so. Submissions to an engine your readers
do not use produce nothing, so enabling it changes nothing except leaving
you with a setting that reads as a claim about an audience you do not have.
The exception is a market you are deliberately entering.

**How do I know whether this engine matters to me?**
Look at where your existing visitors already come from rather than at any
general claim about markets, including one on this page. If a search source
sends you traffic today, it matters; if it does not appear at all, it does
not. The exception is a market you are entering rather than already serving.

**What does switching it on add?**
A direct submission to Yandex for each change, in addition to the defaults.
The shared endpoint already passes submissions on to the engines taking part
in the protocol; the direct route is one more destination you can watch on
its own. It uses the same key file and the same scope as every other
participant.

**Does this affect how my pages rank?**
No. An announcement says an address changed and makes no argument about where
it should appear. Fetching, indexing, and ranking are separate decisions made
on the engine's own criteria, exactly as they would have been made without
any announcement at all.


--- https://bridge-indexnow.com/how-it-works/key/ ---

# The IndexNow key file: proof of control, not a secret

The key file answers one question: does whoever sent this submission control
the hostname the submission is about. It does that by being served from that
hostname, which is something only somebody controlling it can arrange. It is
not a password, and treating it as one leads to the wrong decisions about
almost everything else on this page.

## What the key proves, and what it does not

One property, and it is narrower than people assume.

Serving a file at a known address on your hostname demonstrates control of
that hostname. That is the whole of the mechanism. It says nothing about who
you are, grants no permissions, and carries no authority beyond the host it
sits on.

It follows that the key is not confidential. Anybody can fetch it, exactly as
any participating engine must be able to, and it is published on purpose. A
key found by somebody else is not a leak, and finding one on a site you do not
control is not a discovery worth reporting to anybody.

The reason that is safe rather than merely tolerable is what a stolen key
would let somebody do: announce that pages on **your** hostname changed. They
cannot announce changes for a hostname whose file they cannot serve, and
announcing yours does nothing to you beyond what you can already do yourself.
The mechanism is deliberately built so that the thing it protects is not worth
stealing.

## Where the file has to be served

At the root of the hostname the submission concerns, under a name matching the
key itself, in the form `/<key>.txt`.

The word doing the work there is **hostname**. The proof binds a key to the
host that serves it, so a key that answers on one hostname says nothing about
another. Sites with several hostnames, a bare domain and a prefixed one, or
separate hosts for separate markets, each need their own proof, and treating
them as one site is the commonest structural mistake here.

On this platform the file is served by the edge at your own hostname, which is
the arrangement that keeps the proof honest: the file appears where the proof
has to appear, on the host you control, rather than anywhere else. Setting
that up is covered under [setup](/setup/).

The content of the file matters less than people expect, and its
**reachability** matters far more. Almost every failure below is a file that
exists somewhere and cannot be fetched from outside. A file present on the
server and unreachable over the network is, from the point of view of the
proof, a file that does not exist, and the two look identical from a text
editor and completely different from an `HTTPS` request.

## Four ways it quietly stops working

None of these announces itself, and the site keeps working perfectly for
visitors in all four.

**A hostname changed and the proof did not follow.** A new market gets a new
host, a migration moves traffic to a different name, and submissions for the
new hostname now have no proof behind them. The old host still verifies
correctly, which makes the failure look partial and random.

**Something started intercepting the path.** A rule added for another purpose,
a redirect applied to everything, an authentication layer placed in front of
the site during a redesign: any of these can absorb the request for the key
file while leaving the rest of the site untouched. Verification is checked at
the time of submission rather than once at setup, so this breaks quietly long
after anybody thought about it.

**The file answers on one form of the address only.** Served on the prefixed
form and not the bare one, or over one scheme and not the other, while
submissions are made for the form that does not answer. Checking the form you
happen to have bookmarked reports success.

**The key was regenerated and the file was not.** Two halves of one change,
and doing only the first leaves a valid-looking configuration that verifies
against nothing. This one usually arrives with a rebuild or a migration
between environments, where the value is generated fresh and nobody connects
that to a file somebody placed months ago.

The check for all four is the same, and it takes seconds: request the file
from outside your own network, on every form of the hostname you submit for.
The four answers that request can return, and what each of them means, are
set out under [key checker](/tools/key-checker/).
What to do when it fails is set out under
[key not found](/troubleshooting/key-not-found/).

## Changing the key

Rarely necessary, and not an emergency when it is.

Because the key is not a secret, rotating it is not a security response. The
legitimate reasons are ordinary: a rebuild that generates a new one, a
consolidation of several keys into one, a host that changed hands. None of
those is urgent, which means the change can be made in the safe order rather
than the fast one.

The safe order is to serve the new file before submitting with the new key,
and to keep the old file in place until nothing uses it. Doing it the other
way round produces a window in which submissions carry a key nothing can
verify, and that window lasts exactly as long as it takes somebody to notice,
which is usually longer than the change itself.

## FAQ

**Is the IndexNow key a secret?**
No. It is published deliberately at a known address so that participating
engines can fetch it, and its whole purpose is to be readable by anybody. It
proves control of a hostname rather than identity, so it grants nothing to
somebody who copies it.

**What happens if somebody else uses my key?**
They can announce that pages on your hostname changed, which is something you
can already do and which harms you in no way. They cannot use it for any other
hostname, because the proof is bound to the host serving the file rather than
to the key on its own.

**Do I need a separate key for each subdomain?**
Each hostname needs its own proof, since a file served on one host says
nothing about another. Whether that means separate keys or the same key served
on each host is an implementation choice; what matters is that every hostname
you submit for answers with a valid file.

**Why did verification start failing when nothing changed?**
Something almost certainly changed, just not in the part you were looking at.
Verification happens at submission time, so a redirect rule, an added
authentication layer, or a hostname migration can break it weeks after the
change that caused it.

**Where exactly should the file be?**
At the root of the hostname, named after the key, in the form `/<key>.txt`.
The important test is not where you placed it but whether it can be fetched
from outside your network on every form of the address you actually submit
for.


--- https://bridge-indexnow.com/setup/edge/ ---

# IndexNow at the edge: submissions without site changes

The layer delivering your traffic already knows which addresses were served
and which content changed. That makes it the one route where announcements
happen without a publishing hook, a plugin, or a change to your build, and
the trade behind that convenience is worth understanding.

## 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](/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

Bing and the shared endpoint without configuration, four more on request,
and one large one 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](/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](/setup/) 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](https://bridge-cdn.com/), which is where the product and
its documentation live.

## FAQ

**Do I need to install anything to submit from the edge?**
No. The layer serving your traffic already observes which addresses change,
so no plugin, publishing hook, or pipeline change is required on the site.
That is the specific advantage of this route, and it is the reason it exists
for sites with no publishing event to attach to.

**Where is the IndexNow key file hosted on this route?**
At `/<key>.txt` on your own hostname, served by the edge. That placement is
what proves control of the hostname to an engine, and nothing needs to be
deployed to your origin for it. A key served from anywhere else would
demonstrate control of somewhere else.

**Does edge submission send my whole site?**
No. Automatic submission covers discovered and changed addresses only, it
imports no history when enabled, and a full-site submission remains a manual
action. The route changes where submissions are sent from rather than what
is in scope to send, and no route anywhere widens that scope.

**Does this notify Google?**
No. Google does not participate in IndexNow at all, so no route reaches it,
including this one. Submissions go to the participating engines only, which
means Bing and the shared endpoint by default and the optional participants
(including Yandex, Seznam, Naver, and Yep) if you enable them.


--- https://bridge-indexnow.com/tools/key-checker/ ---

# IndexNow key checker: is the file really served?

To run the check, request `/<key>.txt` from your hostname over `HTTPS`,
without following redirects and without rendering anything, and look at what
comes back: `curl -si https://example.com/<key>.txt` does exactly that. It
is the same request an engine makes when it verifies a submission, made the
same way, so the answer is the one that matters.

## The four answers

Everything that can happen falls into one of these.

**The file came back as plain text.** Your side is correct. Verification
will read what you published, and if submissions are still failing the cause
is elsewhere.

**A redirect came back.** The request never reached the file. This is the
most common cause that looks like a missing file: a rule canonicalising the
domain or normalising paths catches the key file along with everything else,
and a browser hides it by following along.

**A page came back.** Something answered, and it was a document rather than
the file. A framework serving its shell for unmatched paths or a decorated
error page both produce this, and both look perfectly healthy to a person.

**Nothing came back.** Either the file is genuinely absent, or something in
front of the site refused the request. Access controls and rules aimed at
unfamiliar automated clients apply to the fetching engine exactly as they
apply to anything else.

Each of those maps to a section of
[key not found](/troubleshooting/key-not-found/), which covers what to do
next.

## Why the browser is not this check

Two habits make the browser the wrong instrument here.

It follows redirects silently, so the second answer above looks like the
first. And it renders what it receives, so the third looks like a page
loading normally rather than like a key file that is missing. Both of those
are helpful behaviour when browsing and unhelpful when the question is
exactly what a server returns.

Made without following redirects, the request is the one verification makes,
which is the only version of the answer that predicts what an engine will
see.

## What it does not tell you

It reports on the key file and nothing else.

A correct key file does not mean a submission succeeded, and a successful
submission does not mean a page was indexed. Those are separate steps with
separate outcomes, and the last of them is the engine's decision rather than
anything observable from here, as set out on
[how it works](/how-it-works/).

If the file is served by the layer delivering your traffic rather than
placed by hand, most of the failures above stop being possible, which is
what [submitting from the edge](/setup/edge/) describes.

## FAQ

**How do I check my IndexNow key file?**
Request it from your own hostname the way an engine does: over `HTTPS`, at
the exact path, without following redirects, and from outside your network.
What matters is not whether it opens in a browser but whether that specific
request returns the file as plain text.


--- https://bridge-indexnow.com/troubleshooting/key-not-found/ ---

# IndexNow key file not found: why the fetch really fails

The engine went to read your key file and did not get it. Almost always the
file exists and the site is working; something between the request and the
file is answering instead. Four causes cover nearly every case, and telling
them apart takes one request.

## What the engine asked for

A single plain-text file, at a fixed path, on the hostname named in the
submission.

The request is for `/<key>.txt` over `HTTPS` on your own hostname, and what
should come back is the file itself: plain text, nothing else, at that
address. The reason this placement is not negotiable is that it is the whole
proof. Only somebody controlling the hostname can cause a particular file to
be served from it, which is what makes a submission attributable, as set out
on [how it works](/how-it-works/).

Everything on this page follows from that. The engine is not checking
whether your site is healthy, whether the page looks right, or whether a
human would consider the response reasonable. It is checking whether that
exact request returns that exact file. What the file proves, and why it is
public by design, is set out under [the key file](/how-it-works/key/).

## Cause one: the file is not where it is being looked for

The commonest and the least interesting.

The path is derived from the key, so the file name and the key have to
correspond, and the file has to sit at the root of the hostname rather than
in a subdirectory. A file placed one level down, named with a different
case, or given an extra extension by an editor is not at the address being
requested, and nothing about the site will indicate a problem.

Multiple hostnames multiply this. Each hostname is verified separately
against a file served from itself, so a key file present on one and absent
from another produces exactly this failure for the second, while the first
works perfectly and reassures you that everything is set up.

## Cause two: the request is redirected

The file exists at the address, and the request never arrives there.

Redirects are the most common cause that looks like the file is missing when
it is not. A rule that sends every request to a canonical form of the
domain, forces a prefix, or normalises paths will happily redirect a request
for the key file along with everything else. From a browser you will not
notice, because a browser follows redirects and shows you the file.

The general shape to look for is any rule that acts on all paths. If your
site canonicalises the domain, adds or removes a prefix, or rewrites
addresses in bulk, the key file is inside the scope of that rule unless
something excludes it.

## Cause three: a page is returned instead of the file

The response arrives, and it is not the file.

This is the cause that hides best, because to a person the site looks
healthy. A framework that answers every unmatched path with a rendered page,
a friendly error page that returns a decorated document, or a single-page
application that serves its shell for anything it does not recognise will
all produce a perfectly good response containing no key.

The tell is that the response is a document rather than plain text. A site
that returns its own styled page for an address nobody has published is
behaving normally in every respect except this one, which is why this cause
survives so many rounds of checking by eye.

## Cause four: the file is not reachable from outside

Everything is correct, and the request cannot get through.

Access controls applied to the whole site catch the key file too: a staging
password, an allowlist restricted to office addresses, a rule that requires
a session, or a firewall rule that filters unfamiliar clients. From inside
your network or your browser session everything works, which is precisely
what makes this one persist.

The same applies to anything that treats an unrecognised client as
suspicious. The engine fetching your key file is an ordinary client with no
history on your site, and rules aimed at unwanted automation do not
distinguish it from anything else automated.

## Telling them apart in one request

The whole diagnosis is a single fetch, made the way the engine makes it.

Request the key file over `HTTPS` on the exact hostname in the submission,
without following redirects, and look at three things: whether you were
redirected, whether the body is plain text or a document, and whether you
were let through at all. Each of the four causes above shows up
distinctively in that one answer.

| What the one request shows | Which cause it points to |
|---|---|
| Nothing served at that address | The file is not where it is being looked for |
| A redirect, wherever it leads | The request is redirected |
| A document rather than plain text | A page is returned instead of the file |
| A refusal, a challenge, or no answer | The file is not reachable from outside |

Two conditions matter for the test to mean anything. Make the request from
outside your own network, because access controls are invisible from inside
it. And do not use a browser to judge the result, since a browser follows
redirects and renders whatever it receives, which hides the two causes
hardest to spot. How to make the request the way verification makes it is set out under [key
checker](/tools/key-checker/).

If the file comes back as plain text at that address with no redirection,
this page is not your problem. A key that is read but rejected is a
different situation with different causes, and the [troubleshooting overview](/troubleshooting/) takes it apart under its own heading.

## Where this stops being your problem

One arrangement removes the whole category.

When the layer that serves your traffic also serves the key file, it is
returned from your hostname without being placed anywhere by hand, which is
what [submitting from the edge](/setup/edge/) describes. Every cause on this
page comes from something between the request and a file somebody deployed,
and a file nobody deployed has nothing in front of it.

## FAQ

**Why does the engine say my IndexNow key file is not found?**
Because the request for it did not return the file. Usually the file exists
and something else answers: a redirect rule, a framework returning a page
for unmatched paths, or an access control. The file being genuinely absent
is the least common of the four causes.

**My key file opens fine in a browser. Why does verification fail?**
Because a browser hides the two most common causes. It follows redirects
silently and renders whatever comes back, so a redirected request and a
returned error page both look like success. Fetch it without following
redirects, from outside your own network, and compare what you actually get.

**Does the key file have to be at the root of the site?**
Yes, at the fixed path on the hostname the submissions name. That placement
is the proof of control, so a file in a subdirectory does not satisfy it. A
site serving several hostnames needs the file served from each one it
submits for, since each is verified separately.

**Can a firewall block the verification fetch?**
Yes, and it is a frequently missed cause. The engine fetching your key file
is an unfamiliar automated client, so rules aimed at unwanted automation,
staging passwords, and address allowlists all apply to it exactly as they
apply to anything else.


--- https://bridge-indexnow.com/vs/sitemap/ ---

# IndexNow vs sitemap: inventory against timing

A sitemap is a list of what exists. A submission is a notice that one thing
just changed. The comparison feels like a choice because both are ways of
telling an engine about pages, but they carry different information, and
neither one covers the cases the other exists for.

Both are worth having, and the rest of this page is about why that is the
normal answer rather than a hedge.

## Side by side

| | `XML` sitemap | `HTTPS` submission |
|---|---|---|
| Answers | What exists on this site | This address changed just now |
| Scope | Everything you list | One address at a time |
| Read when | On the engine's schedule | Sent at the moment of change |
| Covers pages that did not change | Yes | No |
| Covers pages nothing links to | Yes | Only if something noticed a change |
| Useful for a brand new site | Yes | Not on its own |
| Carries timing | No | Yes, and that is all it carries |
| Fails by | Going stale without saying so | Simply not being sent |

The last three rows are the argument. One mechanism is complete and slow, the
other is immediate and narrow, and a site publishing anything regularly
needs both properties rather than a preference between them. Read the table
as a description of coverage rather than as a scorecard: there is no column
that wins.

## What only a sitemap covers

Three cases, and a submission cannot reach any of them, however it is
configured. These are the cases that settle the argument, because they are
not preferences but gaps.

**Pages that exist and have not changed.** Nothing produces an event for
them, so nothing announces them, and they remain perfectly worth knowing
about. They are exactly what a list is for, and on most sites they are the
overwhelming majority of pages.

**Pages nothing links to.** An address with no inbound link may never be
discovered by crawling at all, and if it also never changes, no submission
is ever generated for it. An `XML` list is then the only mechanism that
mentions the address anywhere.

**A brand new site.** Before anything is known about a site, there is no
history against which a change can be detected, and few links pointing at it
from anywhere. A list published at a known location is the way in, and it is
the only one of the three mechanisms that works from a standing start.

Those three are why the sitemap does not become optional when submission is
switched on. Each of them is a page an engine would otherwise have no reason
to know about, and none of them will ever produce a notice.

## What only submission covers

There is exactly one case here, and it is the one people install submission
for in the first place.

**A change that matters now.** A price, a correction, an availability
status, a published article: something that was one way and is now another,
where the value of an engine knowing is highest immediately and decays from
there. The `HTTPS` request carrying that notice is small, and its whole
worth is in when it arrives rather than in what it says. A sitemap can carry the address, but it is read when the engine
chooses to read it, which may be after the moment has passed.

That is the entire contribution, and it is worth being precise about how
narrow that is, because the narrowness is what makes the claim believable. Submission does not make a page more likely to be kept, does not affect how
it is treated once found, and does not reach engines that do not participate
at all, as set out under [engines](/engines/).

## Why they do not conflict

An engine receiving both is not receiving two versions of the same claim,
which is the worry that makes people ask whether to pick one.

The list says what your site contains. The notice says that one item
changed. Those are complementary rather than contradictory, and an engine
has no reason to prefer one over the other, because they are answers to
different questions rather than competing answers to one.
Nothing about publishing a sitemap weakens a submission, and nothing about
submitting weakens a sitemap.

The one genuine interaction between them is that both depend on the same
underlying truth: the address has to be reachable and worth serving in the
first place. A submission for an address your site does not serve properly is a notice
about a problem rather than about a page, and a sitemap listing addresses
that fail is a list of problems presented as an inventory. Fixing what is
served is upstream of both, and neither mechanism will tell you that this is
what went wrong. Neither
mechanism improves what it points at, and neither compensates for a page
that is not worth keeping, which is covered under
[how it works](/how-it-works/).

## The practical arrangement

Both, with each doing its own job and neither one maintained by hand. The
maintenance question decides more here than the comparison does: a mechanism
that depends on somebody remembering is a mechanism that stops working the
week it matters most.

A sitemap generated from your site stays accurate without anybody
remembering to update it, and submission attached to whatever already knows
about changes happens without anybody remembering that either. Both fail the same way when they depend on a person: quietly, during the
busy week when the pages being published matter most. Where that second one is attached matters more than it
sounds, because it decides which changes ever become events at all, and it
is covered under [setup](/setup/).

What is worth checking occasionally is that the sitemap still reflects the
site. A stale list actively misleads about what exists, while a missed
submission only means a change is discovered the ordinary way, a little
later. The failure modes are not symmetrical, and the list is the one that
goes wrong quietly enough to stay wrong for months.

## FAQ

**Does IndexNow replace a sitemap?**
No, and the two are not interchangeable in either direction. A sitemap
includes pages that have not changed, pages nothing links to, and a site
nothing knows about yet, none of which ever generate a submission.
Submission covers the one case a sitemap handles poorly, which is timing.

**Do I need a sitemap if I use IndexNow?**
Yes, for the three cases above. Submission only exists where a change was
detected, so anything static, unlinked, or newly published on a site nothing
knows about has nothing to announce, and would be invisible to an engine if
the list were removed.

**Which one gets my page indexed faster?**
Submission notifies participating engines sooner, and that is exactly where
its advantage ends. Whether a page is then crawled, kept, or shown is
decided separately in both cases, on criteria that neither mechanism
influences at all and that neither receives an answer about.

**Should the same addresses be in both?**
Yes, and that is not duplication in any sense that matters. The list states
that an address exists; the submission states that its content has changed.
An engine reading both receives inventory and timing rather than the same
claim made twice, and has no reason to weigh one against the other.