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
- Seznam
- Naver
- Yep
- Yandex
- IndexNowapi.indexnow.org, the shared endpoint
Bing and the shared endpoint by default; Seznam, Naver, Yep, and Yandex when you switch them on.
Who receives
Which engines take part
Bing and the shared endpoint are on by default; Seznam, Naver, Yep, and Yandex take part when you enable them.
-
On by default
Microsoft Bing
Founding co-creator of IndexNow. Receives edge announcements automatically and syncs directly with Bing Webmaster Tools.
-
On by default
api.indexnow.org
The shared central protocol endpoint. Dispatches submissions simultaneously to all participating search engines.
-
When enabled
Seznam.cz
National search engine in the Czech Republic and Central Europe. Connects changed URLs directly to SeznamBot crawlers via IndexNow.
-
When enabled
Naver
Leading search and portal provider in South Korea. Submissions route to Naver Search Advisor for fast regional IndexNow discovery.
-
When enabled
Yep (Ahrefs)
Privacy-focused search engine created by Ahrefs. Integrates IndexNow via YepBot crawler and Ahrefs Site Audit.
-
When enabled
Yandex
Leading search engine in Eastern Europe and Central Asia. Co-creator of IndexNow with native Webmaster indexing support.
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.
Where you are now
You published. Then you waited
Publishing new catalog pages, articles, or product updates does not mean search engines notice immediately. Sitemaps are passive, and crawlers revisit on their own unannounced schedule.
Without IndexNow
Catalog & page updates
Waiting for next crawl
Pages updated in catalog or CMS. Crawlers receive no push signal to revisit.
- No push signal
- Passive sitemap
- Blind crawl wait
- Stale search results
With Bridge IndexNow
Edge change detection
Submitted within seconds
Bridge CDN detects changed URLs at the edge and submits payloads to endpoints.
- Instant edge push
- Active notification
- Fresh index signal
- Exact audit logs
Automatic submission covers discovered/changed URLs only; enabling it imports no history; full-site submission is manual. Google does not participate in IndexNow; submissions notify Bing, Seznam, Naver, Yep, and Yandex.
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
Repetitive browser forms and per-engine daily limits.
- 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
Custom backend scripts, endpoint logic and maintenance.
- 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: Fully automated
One submission, from one place, automatic at the edge.
- 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.
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.
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 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.
Recent submissions
Illustration, replayed — not live data
| Time | Address | Event | Engine | Mode | Outcome |
|---|---|---|---|---|---|
| 09:14:02 | /pricing/ | changed | Bing | Fallback | accepted |
| 09:14:02 | /pricing/ | changed | Yandex | Fallback | not tried — already accepted |
| 09:14:03 | /blog/edge-cache/ | changed | Bing | Fallback | refused, HTTP 429 |
| 09:14:03 | /blog/edge-cache/ | changed | Yandex | Fallback | accepted on retry |
| 09:16:18 | /blog/tail-latency/ | discovered | Bing | Fallback | accepted |
| 09:16:18 | /blog/tail-latency/ | discovered | Yandex | Fallback | not tried — already accepted |
| 09:20:41 | /docs/keys/ | changed | Seznam | Balance | accepted |
| 09:20:41 | /changelog/ | changed | Naver | Balance | accepted |
| 09:22:07 | /docs/keys/rotation/ | discovered | Yep | Balance | accepted |
| 09:24:55 | /docs/api/submit/ | changed | Bing | All | accepted |
| 09:24:55 | /docs/api/submit/ | changed | Yandex | All | accepted |
| 09:24:56 | /docs/api/submit/ | changed | Seznam | All | accepted, HTTP 202 — key pending |
| 09:24:56 | /docs/api/submit/ | changed | Naver | All | accepted |
| 09:27:30 | /pricing/plans/ | changed | Bing | Fallback | accepted |
| 09:31:12 | /blog/ttfb-notes/ | discovered | Bing | Fallback | refused, HTTP 429 |
| 09:31:12 | /blog/ttfb-notes/ | discovered | Yandex | Fallback | accepted on retry |
| 09:35:44 | /docs/keys/ | changed | Bing | Balance | not tried — allowance spent |
| 09:38:09 | /support/status/ | changed | Yandex | Balance | accepted |
| 09:41:26 | /blog/cache-keys/ | discovered | Naver | Balance | no answer, retry queued |
| 09:42:26 | /blog/cache-keys/ | discovered | Naver | Balance | accepted on retry |
| 09:47:51 | /docs/api/errors/ | changed | Yep | 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.
The rules that decide are the ordinary ones
Announcing a change does not argue the page’s case. Whether it is kept is settled on the criteria any page on the web is settled on, and those criteria are published by the engines rather than described here. The protocol’s own FAQ states the limit without hedging: submitting a URL does not guarantee immediate indexing.
-
1
Quality decides before anything else does
That FAQ names low-quality, thin and duplicate content as the reason a submitted address stays out. A page written to fill a slot is not helped by being announced sooner. It is found sooner, which is a different thing.
-
2
A page the crawler cannot use is not a candidate
The same FAQ names the states that keep an address out whatever is announced about it: a 404 response, a block in robots.txt, a noindex tag. Announcing such an address tells the engine where to find the obstacle sooner.
-
3
The requirements are published, and by the engines
Read them at the source rather than in anyone’s summary of it. Bing publishes webmaster guidelines; Yandex publishes site recommendations. Those two receive submissions by default here.
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, and it is decided on the page rather than on the message about it.
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, 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.
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.
After you switch it on
Switch it on, then switch the others off
A submission is one request, and the same request does not count twice. If IndexNow already goes out from somewhere else on this site, the second sender is not a backup: it spends a second allowance announcing an address that was already announced.
-
1
Switch it on at the edge
Submission runs in the layer already serving the traffic, so there is nothing to install and nothing to keep running.
-
2
Leave one sender and switch the rest off
A plugin in your content system, a script of your own, a step in your build, another delivery layer — if any of them is already submitting, turn it off. Two senders announcing the same address spend two allowances, and the allowance is counted per engine.
-
3
Then read the log rather than the settings
Submission follows change detection, so a discovered or changed address goes out without you. What went where is written down line by line, and that record is the thing worth checking afterwards.
If you are choosing which sender to keep, the difference is not correctness. It is what makes each one fire, and what it leaves you able to read afterwards.
| 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 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 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 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.
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.