IndexNow troubleshooting: start from what you observed
Most trouble with submissions falls into a handful of shapes, and telling them apart takes one question rather than a search through logs. The complication is that the single most common complaint is not a malfunction at all, so the first thing worth establishing is whether anything is actually broken.
The first question: was the submission rejected or accepted?
First check whether the IndexNow endpoint rejected the submission (a 4xx code) or accepted it (200 or 202).
A rejected submission means the engine declined to take it. Something about the message or the key did not check out, the cause is on your side, and it is fixable. These are real faults with real remedies.
An accepted submission means the message was well formed and the key verified. That is all it means. If the complaint is that a page has not appeared anywhere, and the submission was accepted, then nothing in the submission chain is broken and no amount of adjusting it will change the outcome, for reasons set out under what an accepted submission means.
Sorting the symptom into one of those two branches saves more time than any other diagnostic step, because the second branch has no fix in it at all. For the first, the parts you control can be checked directly, as set out under IndexNow checks you can run yourself.
When the IndexNow key is the problem
Most rejections are about the key, and they split into two distinct situations that get confused with each other. An endpoint reports a key it could not validate, a key file it could not find, or a file that did not contain the key, with HTTP 403.
- The key file cannot be read
The engine went to fetch
/<key>.txtoverHTTPSfrom your hostname and did not get it. The usual causes are not exotic: the file is not where it is expected, the request is redirected somewhere else, or what comes back is anHTMLpage rather than the plain text that was asked for. A friendly error page returned instead of the file is a particularly common version, because to a human it looks like the site is working.- The key file was read but not accepted
The file exists and was fetched, and its contents did not match what the submission claimed. This is a different problem with different causes, and treating it as the first one leads to a lot of pointless checking of paths that were correct all along. Its causes are set out under key read but not accepted.
When the address is the problem
A submission names an address, and an address that does not belong to the hostname being verified cannot be accepted. The endpoint answers such a submission with HTTP 422.
This sounds like an unlikely mistake and is not. It appears whenever submissions are generated from a list that outgrew its assumptions: addresses on a subdomain that has its own /<key>.txt, addresses on the www form of a hostname sent for the bare one or the other way round, or addresses copied from a staging environment that survived into production. The pattern is always the same, which is that the sending side believes it is speaking for a hostname it has not proven control of.
The remedy is structural rather than per-address. What sends submissions should derive addresses from the same place the key belongs to, so the two cannot drift apart. What each refusal code means is set out under IndexNow response codes.
When submissions are too frequent
Engines limit how much they will accept, and the response to that limit is where sites make things worse. The protocol’s own FAQ says each engine sets its own daily thresholds per site and does not publish the figures. An endpoint refusing for this reason answers HTTP 429; how the allowance is counted is set out on the main page.
What not to do is retry immediately, and then retry again. Repetition carries no additional information for an engine to act on, so a resubmitted address communicates exactly what it communicated the first time while consuming the allowance that would have carried a genuinely new change. If you are hitting a limit regularly, the question to ask is what is generating so many submissions: a route announcing changes that are not really changes is a common cause, and one to rule out before concluding that the site publishes at that rate, and that usually leads back to how submissions are being sent, which is covered under setup.
When the submission was accepted and nothing happened
An accepted submission is an announcement received, not an agreement to index or to rank.
Which checks settle your side, and what is left to the engine, is set out under submitted but not indexed.
When you are not sure anything was sent
Whether a submission was sent at all is a separate question from all of the above.
Confirm that before diagnosing anything else. An edit that produced no detectable change sends nothing, and every submission that was sent is recorded with the answer it got; how to read that record is set out under checking that a submission was sent.
FAQ
My IndexNow submission failed. Where do I start?
Establish whether it was rejected or accepted. A rejection is a real fault with a cause on your side, usually the key file or the address being submitted. An acceptance followed by nothing visible is not a fault at all, and treating it as one leads to hours of adjusting something that already worked.
Why does the engine say my key file cannot be read?
Because the fetch did not return the file. The usual causes are that it is not at the expected location, that the request is redirected elsewhere, or that a formatted page comes back instead of plain text. The last one hides well, since a friendly error page looks perfectly healthy to a person. More under key not found.
I submitted the page and it is still not indexed. What now?
Nothing in the submission chain needs fixing. Acceptance means the message was valid and the key verified; crawling, indexing, and ranking are separate decisions the engine makes on its own criteria. A correctly announced page that never appears is an ordinary outcome rather than a malfunction to fix. More under submitted but not indexed.
What should I do when submissions are rate limited?
Not retry. Repetition adds no information and spends the allowance a real change would have used. Look instead at what is generating the volume, since a route announcing things that are not really changes is a common cause to rule out before concluding that the site publishes at that rate. More under IndexNow response codes.
How do I know a submission was sent at all?
Confirm that before diagnosing anything else, because every other question here assumes it. Automatic submission follows change detection, so an edit that changed nothing detectable produces no announcement at all, and an absence of announcements is sometimes the correct behaviour rather than a fault worth investigating further. More under checking that a submission was sent.