Publishing a post in Market4 sends two announcements, not one. An IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep together, and a separate call re-submits the sitemap to Search Console, because Google takes no part in IndexNow at all. They run in the same job, they are independent, and neither is allowed to suppress the other — which is the design decision this post is about.
The two announcements need different things from the customer, and that is the whole reason they cannot be merged. Re-submitting a sitemap to Search Console requires a verified Google property, which many sites do not have. An IndexNow request requires nothing but the customer's own domain and a key file published at its root. If the two were one call, an app with no Google connection would be announced nowhere, and the engines that need no credential would be silent because of a credential they never wanted.
So they are awaited in sequence and each swallows its own failure. A Search Console call that fails because the property was unverified this morning does not stop the IndexNow request. An IndexNow endpoint that refuses the key does not stop the sitemap re-submission. Both outcomes are recorded; neither is allowed to become the other's excuse.
| What happens on publish | Who hears it | What it needs | What success means |
|---|---|---|---|
| Sitemap re-submitted to Search Console | A verified Google property for the site | Google has been told where the sitemap is, not that it read it | |
| One IndexNow request | Bing, Yandex, Seznam, Naver and Yep | A key file answering at the site root | The endpoint received the URL list, and nothing more |
| Publish preflight | Nobody outside; it asks your own site | The site answering on its own host | The announced address really serves an indexable page |
A 200 or a 202 from IndexNow means the endpoint received the list. It does not mean anything was indexed, or crawled, or that it will be. Reporting an accepted submission as though the pages are now live in search is the mistake this distinction exists to prevent, and it is worth writing into whatever your own tooling says back to you.
A sitemap and an IndexNow submission answer the same question about a site. Building them from two pieces of code guarantees they will disagree. Here are the three rules both have to share, and the four places that read the shared list.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
The IndexNow key file is published at the site root rather than inside the blog path, and the reason is a scoping rule in the protocol: a key file covers its own directory. A key living under the blog path would not cover the blog index itself, which is the one address every publish re-announces. The file is public by design, because publishing it at an address you control is what proves the domain is yours.
That also makes the key file the part of the arrangement that can break silently. It is served by the customer's own reverse proxy, so a deploy that changes routing can remove it without anything on our side noticing, and the first symptom is an IndexNow endpoint refusing submissions weeks later. Checking that the file still answers is a separate act from sending the announcement.
The announcement job is debounced and coalesced, which means ten posts published in a few minutes produce one run rather than ten. That creates a problem worth naming: the job carries one post's identifier, so a naive implementation would announce one URL and quietly drop the other nine. Instead the blog service hands over the full current URL list with each URL's change date, and the IndexNow layer filters that list against the watermark of its last accepted submission.
The result is that the coalesced job announces every URL that changed since the last submission the endpoint accepted, which is what a person publishing a batch expects to happen. Deciding what to send on the far side of that boundary, rather than in the job, is what makes the answer independent of which post happened to trigger the run.
Both announcements tell a search engine about a URL. Neither asks the customer's own server whether that URL answers, and a reverse-proxy rule that stopped matching after a deploy is invisible from our side: the announcement succeeds, the page returns 404, and the post never appears anywhere. The preflight is the check that looks, and it runs after both announcements rather than before them.
The ordering is deliberate. A diagnosis must not be able to delay the announcements by being slow, and must not be able to stop them by failing. Putting the same check first would mean a temporarily unreachable site suppressed an announcement that would have been perfectly valid a minute later.
Bing, Yandex, Seznam, Naver and Yep, in a single request. Google does not participate in IndexNow, so its discovery still goes through your sitemap. The practical value beyond Bing's own users is that Bing's index is what ChatGPT's search reads, which makes an IndexNow submission an answer-engine action rather than only a search-engine one.
Not if publishing already does it. In Market4 a blog publish and unpublish announce themselves on the same coalesced job as the sitemap, so calling the submission tool for a blog URL duplicates work that already happened. That tool is for URLs the product did not author, such as a pricing page or a landing page that changed.
The IndexNow request still goes out, because the two are independent and each swallows its own failure. That matters most for a site with no verified Google property, where the sitemap half cannot run at all: the five IndexNow engines are still told. The failure is recorded rather than raised, so a publish is not blocked by an announcement that a search engine refused.
Because announcing and serving are different systems. The announcement tells an engine that an address changed; nothing in it asks your server whether that address answers. A proxy rule that stopped matching after a deploy leaves the announcement succeeding and the page returning 404, which is why a separate check fetches the announced URL from outside and reports what it actually got.
Reading what Yandex says about a site needs a Yandex Webmaster OAuth token, stored per app in the vault rather than in an environment variable, because a token answers only for the hosts it was issued for.
The submission itself can be undone. The saved address is the part that keeps acting on its own, because it is re-submitted every time you publish.
