IndexNow response codes: what each answer means and what to do
An IndexNow endpoint answers every submission with one HTTP code, and there are six of them. Two mean the submission was received; four mean it was refused, each for a different reason on your side. This page sets out what each code means, what to do about it, and what no code can tell you.
The six answers an IndexNow endpoint gives
The codes and their meanings come from the protocol's own documentation. What to do about each is set out in the sections below.
| Code | What it means | What to do |
|---|---|---|
| 200 | Received | Nothing; the announcement arrived |
| 202 | Received; the key is still being checked | Nothing yet; keep the key file reachable |
| 400 | The request was malformed | Check the request against the protocol's format |
| 403 | The key was not valid: its file was not found, or the file did not contain the key | Check the key file from outside your network |
| 422 | An address does not belong to the host, or the key does not follow the protocol's format | Check the host of each address, and the key's format |
| 429 | Too many requests | Stop resending; find what is generating the volume |
200 and 202: the submission was received
A 200 means the endpoint received the submission. A 202 also means it was received, with one step outstanding: the key is still being validated, so the engine has yet to fetch the key file and compare it with the key in the submission. Nothing needs doing for either, except keeping the key file reachable at /<key>.txt on the hostname until that check is complete.
Received is all either code says. An accepted submission is an announcement that arrived, not an agreement to crawl, index or rank the page; what happens after that is set out under submitted but not indexed.
400: the request was malformed
A 400 means the endpoint could not read the request as an IndexNow submission. The cause is in the message itself rather than in your site. A request is built from the host, the key, the key's location when it is not at the root, and the list of addresses; compare what was sent with the format in the protocol's documentation. When submission is sent from the edge, the request is built by the platform rather than by hand.
403: the key was not valid, or its file was not found
A 403 means the endpoint could not verify the key: the key in the submission was not valid, the key file could not be found where the submission said it would be, or the file was found but did not contain the key. The file is expected at /<key>.txt on the hostname the submission concerns, unless the submission names another location on the same host.
Most of the time the file exists and something else answers in its place: a redirect rule, a framework returning a page for unmatched paths, or an access control that lets visitors through but not an unfamiliar client. The four causes, and the single request that tells them apart, are set out under key not found. When the file is read but does not hold the key in the submission, the causes are set out under key read but not accepted. Why the key exists at all is explained under the IndexNow key file.
422: an address does not belong to the host
A 422 means the submission named an address that does not belong to the hostname being verified, or that the key does not follow the protocol's format: 8 to 128 letters, digits and dashes. An address on a subdomain with its own key file, an address on www.example.com sent with the host example.com or the other way round, or an address copied from a staging environment all produce it. The scheme is not one of the causes: the protocol allows http and https addresses in the same request.
The remedy is structural rather than per-address: whatever sends submissions should derive addresses from the same place the key belongs to, so the two cannot drift apart. The case is described under when the address is the problem.
429: too many requests
A 429 means the engine has limited how much it will accept from your site. Each engine sets its own daily threshold for your site and does not publish it, so there is no number to stay under. The protocol's documentation describes the code as too many requests, potential spam; being limited today says nothing about tomorrow.
What not to do is retry immediately. A resubmitted address says exactly what it said the first time while spending the allowance a real change would have used. If the limit is reached regularly, look at what is generating so many submissions: a route announcing changes that are not really changes is a common cause. How the allowance is counted, separately for each engine, is set out on the main page.
Where the answers are recorded
Every submission is written down in the submission log together with the answer the endpoint gave; how to read that record is set out under checking that a submission was sent.
That record is the place to read a code before acting on it. A refusal with a 403 or a 422 points at a fault on your side that will repeat until it is fixed: the key or its file for a 403, the host of an address or the key's format for a 422; a 429 points at volume; a 200 or 202 points at nothing to fix.
What no code tells you
No response code reports whether a page was crawled, indexed or ranked. The endpoint answers about the submission and nothing else, and the engine's later decisions are made on its own criteria and never reported back. A clean run of 200s and a page that never appears in results are compatible outcomes, which is why the codes are a diagnostic for the submission chain rather than for search visibility. The code says what happened to the message; the page is judged separately.
FAQ
What does a 202 from an IndexNow endpoint mean?
The submission was received and the key is still being validated: the engine has yet to fetch the key file and compare it with the key in the submission. Nothing needs doing beyond keeping the key file reachable at /<key>.txt on the hostname until that check is complete.
Why does IndexNow return 403?
Because the endpoint could not verify the key: the key was not valid, the key file was not found where the submission said it would be, or the file did not contain the key. Usually the file exists and a redirect, a rendered page or an access control answers instead; one request made from outside your network tells which.
What should I do after a 429?
Stop resending. Each engine sets its own daily threshold for your site and does not publish it, and a repeated address spends allowance without adding information. If the limit keeps being reached, look at what is generating the volume, since announcements of changes that are not really changes are a common cause.
Does a 200 mean my page will be indexed?
No. A 200 means the endpoint received the submission. Whether the engine then crawls, indexes or ranks the page is a separate decision made on its own criteria, and no code reports it; what to check when a page stays missing is set out under submitted but not indexed.