A sitemap and an IndexNow submission answer the same question — which URLs on this site are live right now — so they should be produced by one function rather than two. In this product that function is buildBlogSitemapUrls, and it applies three rules: a post is listed only when it is not marked noindex, only when its published date has already arrived, and it reports the date the words last changed rather than the date any field on the record moved. The sitemap renders that list as XML. The IndexNow announcement submits the same URLs directly.
Two lists built by two pieces of code drift, and the drift is invisible until a search engine acts on it. A sitemap generator and an IndexNow announcer that each carry their own copy of the rule "a post counts as live when…" will agree on the day they are written and disagree six weeks later, when one of them is corrected for a bug the other one also has. The failure is quiet: nothing throws, nothing is logged, and the symptom is a search engine being told about a post that does not exist yet, or never being told about one that changed.
Each of those three rules is a decision with a reason behind it, and each is the kind of rule that gets fixed in one place and forgotten in the other. Holding all three in one function is not tidiness. It is what makes the two announcements wrong in the same way at the same time, which is a bug someone can find, rather than wrong in two different ways, which is a bug nobody looks for.
| Aspect | Sitemap | IndexNow |
|---|---|---|
| What is sent | A document listing the live URLs | The changed URLs themselves |
| Who reads it | Any engine that fetches the file, Google included | Bing, Yandex, Seznam, Naver and Yep |
| When it is read | When the engine chooses to fetch it | On receipt of the request |
| Ceiling | 50,000 URLs and 50 MB per file | 10,000 URLs per submission |
| What acceptance means | The file was retrieved | The list was received |
| Google participation | Yes, and it is the supported route | None; Google does not take part |
Publishing a post sends two independent announcements. One IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep. Google takes no part in IndexNow, so it is told by re-submitting the sitemap.
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 difference that matters most for planning is the last row. Google does not participate in IndexNow, so a site announcing only through IndexNow has no discovery route to Google at all, and a site announcing only through a sitemap waits on each engine's own fetch schedule. The two are complements, which is exactly why they must not be allowed to describe different sets of pages.
In this product the shared URL builder has four consumers, and the count is the argument for extracting it. One consumer is a function. Two is a convention somebody can talk themselves out of. Four is a rule that would otherwise live in four places with four sets of edge cases:
Drift between a sitemap and an IndexNow list produces one of two symptoms, and both are slow. The first is a URL announced before it exists: an engine fetches it, gets a 404, and learns that this feed is unreliable. The second is a page that changed and was never announced, so it sits at whatever the crawler last saw. Neither symptom raises an error in the code that caused it, and neither is visible in a dashboard on the day it starts, which is why the repair is structural rather than a monitor.
No. IndexNow reaches Bing, Yandex, Seznam, Naver and Yep, and Google does not take part in it, so a site relying on IndexNow alone has no discovery route to Google. The sitemap is the supported route there. Run both from the same URL list, and treat IndexNow as the fast lane for the engines that read it rather than as a substitute for the file.
Not until their published date has arrived. A post scheduled for next week answers 404 today, and a file full of URLs that are not there yet teaches a crawler to fetch that file less often. The same filter has to apply to the IndexNow submission, for the same reason: an announcement is a claim that the page is live now, not a claim that it will be.
The date the content last changed, not the date the database record was last written. Records move for reasons that have nothing to do with the words on the page: an email marked as sent, a tag corrected, a counter incremented. A lastmod that moves every time internal bookkeeping runs is a lastmod crawlers stop reading, and that costs the field its meaning for the pages that genuinely did change.
That the endpoint received the URL list. IndexNow's documentation states that an HTTP 200 indicates the search engine has received the submission. It does not mean the pages were crawled, indexed, or that they will be. Report it in those words, because a queued request confirmed as queued is not the work being done, and calling it indexed is how a report starts misleading the person reading it.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
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.
