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.
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. Google does not take part.
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
Co-created IndexNow. Receives submissions by default, with nothing to configure.
-
On by default
api.indexnow.org
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.
-
When enabled
Seznam.cz
National search engine in the Czech Republic and Central Europe. Takes part in IndexNow; its endpoint is listed in the protocol’s FAQ.
-
When enabled
Naver
Search and portal service in South Korea. Takes part in IndexNow; submissions are handled through Naver Search Advisor.
-
When enabled
Yep (Ahrefs)
Privacy-focused search engine created by Ahrefs. Takes part in IndexNow; its endpoint is listed in the protocol’s FAQ.
-
When enabled
Yandex
Co-created IndexNow with Bing. Takes part in the protocol through its own endpoint, documented in Yandex Webmaster help.
IndexNow submission modes
Three ways to send the same list
The three modes differ in how one list of addresses is spread across the engines you have switched on, which 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 allowance is counted per engine, not per site or 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
- Waiting for a crawl
- Engine’s own schedule
With Bridge IndexNow
Edge change detection
Submitted once a change is detected
Bridge CDN detects changed URLs at the edge and submits payloads to endpoints.
- Edge push
- Active notification
- Change announced
- 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 and the shared endpoint by default, and the engines you switch on.
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 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
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.
Three clauses
What automatic submission covers
Each clause below 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 matter. 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. Where the file has to live is set out in the key file, explained; to see what an engine gets back, fetch it the way an engine does. When an engine cannot read the file, the four reasons it fails are set out separately.
-
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 Sender
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.
Said plainly
Google does not participate
No setting, plan or provider changes that.
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. The longer answer is on the page about Google and IndexNow.
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 among the reasons a submitted address can stay 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. Bing receives submissions by default here; Yandex is one you switch on.
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. What to check when a page still does not appear is set out under submitted but not indexed.
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. How a sitemap and a submission divide the work, and when each of the three applies.
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. What submitting from the edge involves.
-
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 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.
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?
Not necessarily. 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.
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.