Bridge IndexNow · part of Bridge CDN
Announcing a change is one button. Three ways to send, and a log that says it went.
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.
Bridge CDN submits to
- Bing
- Yandex
- Seznam
- Naver
- Yep
- IndexNowapi.indexnow.org, the shared endpoint
Bing, Yandex and the shared endpoint by default; the other three when you switch them on.
Where you are now
You published. Then you waited
The gap between changing a page and seeing the change in results is the part nobody designed. It just happens to you.
Waiting to be revisited
Announcing the change
What the engine does with that is still its own decision. This changes when it learns, not what it decides.
-
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.
How to submit URLs to IndexNow
Doing it yourself, counted
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 hexadecimal characters
- 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
Here
- One submission, from one place
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.
IndexNow submission modes
Three ways to send the same list
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.
IndexNow submission limits
The allowance is counted per engine
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.
Scope, stated exactly
What automatic submission covers
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.
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.
Announcing the whole site at once stays a manual action
-
1
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.
-
2
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.
-
3
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.
Who receives
Which engines take part
Two engines and the shared endpoint are on by default; three more engines are available by choice.
-
On by default
Bing, Yandex, and
api.indexnow.orgreceive submissions by default, with nothing to configure. The shared endpoint passes a submission on to the same participating engines and adds none.
-
Off by default
Seznam, Naver, and Yep
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.
Proof of control
The key file
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.
-
1
Engine Your hostname
GET /<key>.txt
-
2
Your hostname Engine
200 — the key, served from the edge
-
3
Engine Engine
Compares it with the key in the submission
-
4
Engine You
Match: the submitter controls the site. No match: refused.
IndexNow submission log
How you know it left
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 rows below are an illustration of the form, not a client’s record.
| Time | Address | Engine | Mode | Outcome |
|---|---|---|---|---|
| 09:14:02 | /pricing/ | Bing | Fallback | accepted |
| 09:14:02 | /pricing/ | Yandex | Fallback | not tried — already accepted |
| 09:14:03 | /blog/edge-cache/ | Bing | Fallback | refused, HTTP 429 |
| 09:14:03 | /blog/edge-cache/ | Yandex | Fallback | accepted on retry |
| 09:20:41 | /docs/keys/ | Seznam | Balance | accepted |
| 09:20:41 | /changelog/ | Naver | Balance | accepted |
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.
Before anything else
Google does not participate
Stated before anything is offered, 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.
Who decides what
Submission is not indexing
Four different things are involved here, and conflating them is the source of most disappointment with this protocol.
Handled at the edge
-
1
Submission
is what this does: telling an engine that a URL changed.
The engine decides
-
2
Discovery
is the engine deciding to look at it. Submission makes discovery possible sooner; it does not compel it.
-
3
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.
-
4
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.
Is this you
Whether this is worth switching on
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, Yandex, Seznam, Naver or Yep. 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.
Alongside, not instead
Next to what you already publish
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.
How it gets sent
Four ways it gets sent
A submission is one request. What differs is who makes it, and how much of your attention that costs. None of these is more correct than the others, and more than one can be in use at the same time.
-
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.
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.
| Route | Fires | Leaves behind |
|---|---|---|
| By hand | because you pressed something | whatever the engine’s own console shows |
| From a content system | on publish | whatever the plugin chose to record |
| From a layer that infers from a cache miss | on a guess about what changed | not something you picked or can read back line by line |
| From the layer already serving the traffic | on a detected change, or on your button | a log of what went where |
Sections
Where to read further
Each section below answers a different question, and none of them requires you to be a customer to be useful.
-
Engines
covers who receives submissions by default, who takes part when you enable them, and who takes part in none of it.
-
How IndexNow works
follows the sequence from a page changing to a submission being accepted, and explains what the key proves.
-
Setup
sets out the four ways a submission can be sent and what each one asks of you.
-
Tools
checks the key file and a single submission, one question at a time.
-
Troubleshooting
starts from the symptom, including the most common complaint, which is not a failure at all.
-
Comparisons
puts submission next to the sitemaps and links you already publish, and says what each one actually does.
Questions
What people ask first
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 Yandex 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 the point before anything else 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 Yandex by default, with nothing to configure. Seznam, Naver, and Yep 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.
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.
Where this lives
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.