IndexNow error codes: fixing 400, 403, 422 and 429

IndexNow returns a bare HTTP status and usually an empty body, which makes debugging opaque if you do not know what each code implies. Here is the full set.

200 — URLs received

Everything worked. Your key has been validated and the URLs were accepted.

202 — Accepted, key not yet validated

This is not an error. It means your submission was accepted but the engine has not yet fetched your key file to confirm ownership. It is normal on early submissions and typically becomes 200 once validation completes.

If you are still getting 202 on every submission weeks later, that suggests the engine cannot successfully fetch your key file — worth checking it loads from outside your network.

400 — Bad request

The request itself is malformed. Common causes:

• Invalid JSON — a trailing comma is the classic.
• Missing host, key or urlList.
• URLs that are not properly encoded per RFC 3986. Unencoded spaces and unescaped ampersands in query strings are the usual culprits.
• A key that breaks the character rules — only a–z, A–Z, 0–9 and hyphens are permitted, at 8 to 128 characters.
• Missing the Content-Type: application/json; charset=utf-8 header on a POST.

403 — Key not valid for this host

The engine fetched your key file and was not satisfied. In order of likelihood:

1. The file is not there. It was deleted in a redesign, or a deployment overwrote the document root without including it.
2. The contents do not match exactly. An editor added a BOM, a trailing newline is usually tolerated but leading whitespace is not, or the file contains the filename rather than the key.
3. It is not publicly readable. Behind basic auth, a staging password, or a firewall rule blocking unknown user agents.
4. It is on the wrong host. The file is at example.com but you are submitting www.example.com URLs. These are different hosts.

Test properly: fetch the URL from outside your network, not from a browser that may be cached or on an allowlisted IP.

curl -sS -D - https://example.com/yourkey.txt

You want a 200, content-type: text/plain, and a body containing only your key.

422 — Unprocessable entity

Two distinct causes share this code, which is unhelpful but manageable:

• URLs do not match the host. Every URL in urlList must be on the host named in host. One absolute URL pointing at a CDN, a subdomain or the opposite www variant rejects the entire batch. This is by far the most common cause, and it is why a sitemap that mixes hosts needs filtering before submission.
• More than 10,000 URLs in one request. Chunk below the limit.

429 — Too many requests

You are being rate limited. The engines do not publish exact thresholds and each sets its own.

What to do: check for a Retry-After header and honour it. If there is none, back off for at least ten minutes before retrying. Do not retry immediately in a loop.

What causes it: almost always resubmitting unchanged URLs. The usual pattern is a script that dumps the whole sitemap nightly, or a CMS plugin that fires on every autosave. The protocol asks for at least five minutes between updates to the same URL, and for submissions only when content meaningfully changed.

No response at all

If the request times out or the connection fails, that is your network or the endpoint, not your configuration. Retry with exponential backoff. Do not treat it as a permanent failure and stop submitting.

A debugging checklist

1. Fetch your key file with curl from outside your network. Confirm 200, plain text, exact contents.
2. Confirm the host in your payload matches the host of every URL, character for character.
3. Validate your JSON.
4. Confirm no batch exceeds 10,000 URLs.
5. Check whether you are resubmitting URLs that have not changed.
6. Check Bing Webmaster Tools' IndexNow section for its own view of what it received.