IndexNow is a protocol through which a site itself notifies search engines about new and changed pages: it sends a list of URLs and receives a response. A single submission is shared among all protocol participants, including Bing. Google does not use IndexNow, so for Google none of this works at all — more on that separately below.
On 2 August 2026 we added a script to the project that submits our site’s pages via IndexNow. On 3 September 2026 it turned out that in all that time it had not submitted a single page. And every submission looked successful.
What exactly the script submitted
The script did a simple thing: it opened /sitemap.xml, picked all the URLs from the <loc> tags and sent them to IndexNow.
The problem is that our /sitemap.xml is not a map of pages but a sitemap index. Inside it are not page URLs but links to other files: sitemap-pages.xml, sitemap-services.xml and four more. So on every run six URLs went to Bing, and all six were URLs of XML files.
The second half of the mistake: /sitemap.xml describes only the Ukrainian version of the site. The English and Russian versions have their own indexes, /en/sitemap.xml and /ru/sitemap.xml, and all three are declared on separate Sitemap: lines in robots.txt. The script knew only about the first one.
Why nobody noticed
Because IndexNow responded to every submission with a 200 code.
The protocol documentation on indexnow.org describes 200 as “URL submitted successfully” and separately clarifies: this code only means that the search engine received your URLs. The protocol returns an error in specific cases: 400 for an invalid request format, 403 for an invalid key, 422 for URLs from another domain or a key that does not match the scheme, 429 for submitting too often. There is also 202: URLs received, the key is still being validated.
None of these codes checks whether a submitted URL is a page. A sitemap XML file is a perfectly valid URL on our domain, the key is valid, the format is correct. Hence, 200. The script saw 200, logged “submitted”, and there was no reason to look deeper.
This is not a quirk of IndexNow. Any intake endpoint that validates the form of a request rather than its content behaves this way: it says “request accepted”, and we read “everything was done right”.
How many URLs there should have been
When we fixed the script on 3 September 2026, it counted for the first time what was actually on the site. Here is the breakdown for that day:
| Source | URLs |
|---|---|
/sitemap.xml (6 child sitemaps) |
355 |
/en/sitemap.xml |
256 |
/ru/sitemap.xml |
256 |
| Total unique | 867 |
The 355 URLs of the Ukrainian index consisted of 11 main pages, 6 service pages, 15 portfolio projects, 19 blog articles, 257 service network pages and 47 tool pages.
This shows that there were two separate mistakes. Had the script learned to expand the index but still read only /sitemap.xml, it would have submitted 355 URLs out of 867, that is, a little over a third of the site. The English and Russian versions would have remained outside the submission. In practice, there was not even that: only six files were submitted.
How many times the script ran between 2 August and 3 September, we did not count. For the conclusion it does not matter: every run produced the same result.
How to check your site in 15 minutes
If you have an IndexNow module or plugin for OpenCart, WordPress or another platform installed, we do not know whether it has the same mistake: we have not tested any module. But you can check this without access to the code.
1. Find all the sitemaps you declare.
curl -s https://your-site.com.ua/robots.txt | grep -i '^sitemap:'
There may be several lines. We have three, and the script knew about one.
2. For each sitemap, look at the root tag.
curl -s https://your-site.com.ua/sitemap.xml | grep -o -m1 '<sitemapindex\|<urlset'
<urlset> means a regular sitemap of pages. <sitemapindex> means an index: the URLs in it lead to other XML files, not to pages. Go by the tag, not by the file name: the name can be anything.
3. Count the actual number of pages. For an index, you need to open each child sitemap:
for s in $(curl -s https://your-site.com.ua/robots.txt | grep -i '^sitemap:' | awk '{print $2}' | tr -d '\r'); do
curl -s "$s" | grep -o '<loc>[^<]*' | sed 's/<loc>//'
done | sort -u > level1.txt
grep '\.xml$' level1.txt | while read child; do
curl -s "$child" | grep -o '<loc>[^<]*' | sed 's/<loc>//'
done | sort -u > pages.txt
grep -vc '\.xml$' level1.txt; wc -l < pages.txt
The first number is the pages that sat directly in the top-level sitemaps, the second is the pages from the child sitemaps. If the child sitemaps are themselves indexes, repeat the step once more for them.
4. Compare with what the module submits. Open the module’s log or the submission statistics in the IndexNow section of Bing Webmaster Tools. If among the submitted URLs there are ones ending in .xml, that is exactly our mistake. If noticeably fewer were submitted than in step 3, the module probably does not see some of the sitemaps, most often the language ones.
5. Do not look for this in Google. Search Console will show nothing about IndexNow submissions, because Google does not use the protocol. For Google, sitemaps are submitted there separately.
If the sitemaps themselves raise doubts — duplicates, an empty file, one language instead of two — there is a separate breakdown of sitemaps. You can check robots.txt and a sitemap online with our free tool.
What we changed
The script now distinguishes an index from a regular sitemap by the root tag <sitemapindex> and expands indexes recursively, no deeper than three levels, so that a circular link between sitemaps does not loop the crawl. There are now three sources: the Ukrainian, English and Russian sitemaps.
After the fix on 3 September 2026, the script submitted 867 URLs out of 867. Submission goes in batches of 500 URLs, so there were two batches, and both received 200. This time 200 meant what we wanted, but we know that not from the response code but from having listed, before submitting, exactly which URLs were in it.
The same day we switched to an IndexNow key issued by Bing Webmaster Tools itself, so that the submission statistics in the Bing dashboard would be tied specifically to it. We left the previous key, generated by us, on the site: Bing could still be verifying submissions made earlier that day for some time, and without the key file they would have failed the ownership check.
What this did not fix
Submitting via IndexNow does not mean indexing. The protocol only notifies the search engine that a URL exists or has changed, and whether to take it into the index is up to the search engine itself.
We did not measure the effect of the fix. We have no Bing Webmaster Tools data from before and after, so we cannot claim that pages got into Bing faster after 3 September 2026.
It had no effect on Google whatsoever. For Google, indexing a large site means sitemaps in Search Console, internal links and what the crawler spends its crawl on. We wrote about the latter in the breakdown of where a site’s crawl goes, and for catalogs with thousands of items there is a dedicated service for indexing a large catalog.
The main thing we took away: an “accepted” response from any intake endpoint checks the form of the request, not what is in it. To know what was submitted, you have to look at the list of URLs itself.
