IndexNow Said 200. Two-Thirds of My Pages Were Never Sent

By Ugur Saritepe · September 5, 2026

A GitHub Action on my games site has submitted URLs to IndexNow on every content push since 1 May. Seventy-four runs, seventy-four green ticks, HTTP 200 from Bing each time. On 2 September an audit found that 105 of the site's 161 sitemap URLs had never been announced to Bing at all. The 200 was grading the envelope, not the pages inside it, and nothing in the protocol would ever have told me.

What a 200 from IndexNow means

IndexNow is a push protocol: your site tells Bing, Yandex, Naver, Seznam, Yep and Amazon that a URL was added, changed or removed, instead of waiting to be crawled. Google does not consume it. Bing's getting-started page states the limit plainly: using IndexNow ensures that search engines are aware of your website changes, and does not guarantee that web pages will be crawled or indexed. The response codes on that page are about the request. 200 is "URL submitted successfully", 403 is a key that did not validate, 422 is URLs that do not belong to the host, 429 is too many requests.

Three more facts from the protocol FAQ shape everything below. A request may carry up to 10,000 URLs. Ownership is proven by a key file the engines fetch from your domain. And nothing reports back: there is no endpoint that lists what a search engine received from you, and no warning when a URL you published was never in any request. So a 200 answers one question, "was this request well-formed and signed by the site?", and the question that matters, "were the right URLs in it?", is yours to keep answering.

The workflow that ran 70 times and sent the same 37 URLs

The automation went in on 1 May 2026, in a commit that mostly rewrote titles. It was a GitHub Actions workflow that fired on any push to main touching the list configs or the articles folder, and it did one thing:

# .github/workflows/indexnow.yml, 1 May – 2 September 2026
run: |
  curl -s -o /dev/null -w "%{http_code}" -X POST "https://api.indexnow.org/IndexNow" \
    -H "Content-Type: application/json; charset=utf-8" \
    -d '{ "host": "game-scout.app", "key": "...", "keyLocation": "...",
          "urlList": [ 33 /best lists and 4 articles, typed by hand ] }'

Every run printed the status code and nothing else. The log of the run on 12 August at 09:39 UTC, triggered by a new guide going live, ends with the payload and a single line: 200. Three runs fired that morning, at 09:14, 09:29 and 09:39, each re-announcing the same 37 URLs from May, none of them the guide that had just been published. By 1 September, seven of the 37 were permanent redirects to pages that had absorbed them, so every push was also asking Bing to recrawl seven URLs whose only content is a 308.

The site published 55 new lists and 44 new articles between 18 July and 28 August, most of them by a daily engine. The workflow fired 46 times in that window. Not one of those runs named a new page, and not one of them failed. A workflow that has only ever printed 200 is very easy to stop looking at.

The day Bing warned me

On 4 August, Bing Webmaster Tools showed a warning that new pages were not being submitted. I did not keep the wording. What I typed:

Check last published pages, it seems like they did not send to IndexNow and Bing is giving warning

44 URLs published since 18 July: 16 /best lists · 14 comparisons
6 game-tips guides · 3 articles · 3 /authors pages

HTTP 200

The diagnosis was right and the sentence before it was wrong. There was an automated ping in the repo; it had run 24 times by that morning. The assistant searched the public folder for the key file and the CLI for a Bing command and never opened the workflows folder, so it concluded from what it had looked at. The 44-URL backfill went out by curl from a scratch directory, was accepted, and left no record anywhere except the session transcript and a memory note. A script with a proper ledger had existed since 18 July; it was not used that day.

The same morning, a separate fix landed in that script. Its first real batch, on 23 July, had announced 19 URLs, ten of them articles at flat paths like /articles/god-of-war-vs-god-of-war-ragnarok. Those articles had moved under /articles/comparisons/ on 6 July, so Bing was told about ten URLs that redirect. Both were HTTP 200 batches. A status code cannot tell you that you sent the wrong address.

Sitemap minus ledger: 105 of 161

Four weeks later I asked the question properly, which meant asking for the difference between two lists rather than for a status:

ledger      12 runs · 44 distinct URLs via the script
workflow    36 URLs hardcoded in indexnow.yml
sitemap     161 URLs

ever announced       75   (19 of them at URLs no longer in the sitemap)
never announced     105   (65%)
Bing in index       632   (309 at the first script push, 18 July)

The fetch of the sitemap had to go through a browser, because the site's bot protection answers curl with a 429 and a challenge page, even with a known user agent. That is the same layer that makes audit tools report a 403 on a site that works, and it is worth knowing that it also blocks your own scripts from reading your own sitemap.

Then the fix, in the order it happened. A catch-up batch of 94 URLs, the 105 minus static and author pages, went out through the script and was accepted with HTTP 200. The workflow was rewritten to call the script's --changedmode, which maps the files in the push to the URLs they render and exits cleanly when nothing content-facing moved. And then the part that would have been invisible: before the first real push, the assistant cloned the repo bare, the way the CI runner does, and ran the workflow's command. It crashed on a database import before submitting anything. A content push that evening would have produced the first red run in four months, which is at least a visible failure, and the import was made lazy so the script needs no dependencies. The first post-fix run, on 2 September at 21:59 UTC, reads differently from the 70 before it:

Changed since c680acd…: 9 URL(s)
OK  HTTP 200 — OK — URLs received
9 URL(s). Logged to .indexnow-log.jsonl

# and two days later, on a push that touched only page templates:
No content URLs changed since 9b996d9…. Nothing to announce.

One caveat that survives the fix. The CI runner writes its ledger line to a filesystem that is thrown away when the job ends, so the ledger on my machine records manual runs only. The next audit should treat it as a lower bound and lean on the git diff for what CI announced. I would rather write that down than discover it in October.

What Bing's index did, and what I cannot claim

The script records Bing's crawl stats before each submission, so there is a dated series. Pages in Bing's index: 269 on 13 June, 309 on 18 July, 413 on 12 August, 632 on 2 September, 659 on 5 September. It would be easy to lay the submissions over that line and call it cause. It is not. The sitemap grew from 71 URLs in Google's 18 July fetch to 161 on 2 September, and Bing crawled the site throughout, with 107 pages fetched in the most recent window. IndexNow is a discovery signal; Bing was discovering the pages anyway, more slowly, by crawling links. What the pings buy is time, and I have no per-URL Bing data to measure how much, because Bing Webmaster's per-page endpoint returns one aggregate row for this site.

Two numbers for scale. In the 28 days to 3 September, Bing sent 215 clicks on 7,205 impressions at an average position of 5.3; Google sent 1,967 on 96,396 at 9.3. And the reason the script's own header gives for existing, that Bing's index feeds AI assistants, rests on one sentence from OpenAI's ChatGPT search announcement, which says the feature draws on "third-party search providers, as well as content provided directly by our partners". OpenAI does not name the providers. On 5 September, AI assistants referred 26 sessions to the site in 30 days, 21 of them from ChatGPT. That is a trickle, honestly labelled, and I would not build a pipeline for it alone. I would build one because announcing a page costs nothing and not announcing it costs the weeks it takes a crawler to find a link.

Our own post said we had a script

On 25 July this blog published a guide to being indexed on Bing but not Google, with a first-hand section that opened: "Every deploy of game-scout.app ends with a script that submits the changed URLs to Bing's IndexNow endpoints." On 25 July the script was seven days old and had been run twice. What ended every deploy was the workflow above, re-sending May's list. The 21 June batch that section cites as an example was a manual curl. The paragraph was written from what I believed the setup did, not from the run log, and it has been corrected today with a note saying so.

This site's own record is thinner. TrafficTriage got an IndexNow script on 6 August. It submits every URL in the live sitemap each time it runs, which is the opposite of Bing's guidance to publish only URLs that changed, and it keeps no ledger. It has run once, on 13 August, for 37 URLs, HTTP 200. Nothing published since has been announced. When this post deploys, its URL and the corrected guide's URL go to IndexNow through the tool described next, and the date goes in the pull request, which becomes the ledger this site did not have.

Find your own never-sent pages in one session

The audit above is three asks, and it only works when the assistant can read your sitemap, read your record of what you sent, and submit the difference. With your site connected to an assistant that has the submit_urls tool, they go like this.

1."Fetch my sitemap and list every URL in it." If your host challenges non-browser requests, say so; the assistant will need a browser or an allow-listed user agent, as mine did. 2."Which of these have we ever submitted to IndexNow, and when?" If the answer is a shrug, that is the finding: you have no ledger, and the difference is the whole sitemap. 3."Submit the ones we never sent, and log the date." The tool takes your own IndexNow key, and the key file has to be live at https://your-domain/<key>.txt first, or the engines drop the batch. It caps at 10,000 URLs per call, which is the protocol's limit, not ours.

Then stop. Do not judge the batch the next morning; check Bing Webmaster's crawl stats a week later and compare the in-index count to the one you wrote down. Do not resubmit the sitemap on a schedule. And do not trust the badge: the free report on this site reads your sitemap and tells you whether it is reachable and well-formed, and it has no idea what you submitted, because nothing outside your own record does. The sitemap check and the submission record are two different questions, and this post exists because I had answered only the first one. The rest of the assistant-side routine has the same shape: a number you can pull, a record you keep, and a date on which the two are compared.

FAQ

Does IndexNow guarantee that Bing will index my page?

No. Bing's own IndexNow page says submission ensures search engines are aware of your changes and does not guarantee that pages will be crawled or indexed. A 200 response means the request was well-formed and your key file checked out. Whether Bing fetches the page is a separate decision, and IndexNow never reports it back to you.

Why does IndexNow return 200 but Bing still has not indexed my page?

Check two things before blaming Bing. First, whether the URL was actually in the request: on my site a workflow returned 200 on 70 runs while re-sending the same 37 URLs, so 105 newer pages were never announced at all. Second, whether the URL you sent is the canonical one: ten of my early submissions pointed at old paths that redirect. Only after both are clean is the delay Bing's.

Should I submit my whole sitemap to IndexNow?

Not repeatedly. Bing's guidance is to publish only URLs that changed since you started using IndexNow, and the protocol FAQ asks you not to resubmit the same URL without a meaningful change. One catch-up batch of everything you have never announced is fine; the 94-URL batch on my site was accepted with HTTP 200. After that, announce each URL once when it is published or changed, and keep a dated record of what you sent.

In your AI assistant

Ask your AI about your own site

TrafficTriage plugs into Claude, Cursor, and ChatGPT. Your assistant runs the 8 checks, reads your Search Console data, and can even check your site every morning. Free account, no API key, nothing to install.

Sign up freeSee how it works