IndexNow troubleshooting: start from what you observed
In this section
The first question: was the submission rejected or accepted?
Everything downstream depends on this, and the two branches have almost nothing in common.
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 on how it works.
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.
When the key is the problem
Most rejections are about the key, and they split into two distinct situations that get confused with each other.
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.
Both are worth distinguishing before touching anything, because the checks that resolve one tell you nothing about the other.
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.
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 under a scheme other than the HTTPS one that was verified, 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.
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.
The useful thing to know is that the limit is not a punishment and does not reflect on your site. It exists because the mechanism is cheap to use, and anything cheap to use has to be bounded. Being limited today says nothing about tomorrow.
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 far more common cause than a site that genuinely publishes at that rate, and that usually leads back to how submissions are being sent, which is covered under setup.
When everything worked and nothing happened
This is the most frequent report of all, and it deserves the plainest possible answer: an accepted submission is an announcement received, not an agreement to index and certainly not one to rank.
The engine decides for itself whether an address is worth crawling, whether what it finds is worth keeping, and where it belongs among everything else. None of those decisions reports back, none of them is influenced by how the address was announced, and any of them can go the other way for reasons that have nothing to do with submission. A page that was announced correctly and never appears is an ordinary outcome, not evidence of a fault.
What submission changes is when an engine could learn that something changed. It is worth having for that alone. It is not worth troubleshooting for an outcome it never controlled.
When you are not sure anything was sent
A separate question from all of the above, and the one that most often comes first after switching submission on.
Before diagnosing a rejection or an absence, it is worth confirming that a submission happened at all. Change detection is what triggers automatic submission, so an edit that produced no detectable change produces no announcement, and a site whose addresses have not changed has nothing to send. An absence of submissions is sometimes exactly correct behaviour.
Establishing what was sent, and what came back, is the step that turns every other question on this page from speculation into diagnosis.
What this section covers
The symptoms are sorted above, organised by what you observed rather than by what an engine returned, because the symptom is what you have when you arrive. The commonest of them earns a page of its own — a key file that cannot be read, and the several ways a site can serve something other than the file itself.
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.
I submitted the page and it is still not indexed. What now?
Nothing, and that is the honest answer. 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.
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 more common cause than a site that genuinely publishes at that rate.
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.
Submission handled at the edge
IndexNow submission is part of Bridge CDN: the platform detects a change and announces the URL to the engines that take part. Automatic submission covers discovered and changed URLs only, enabling it imports no history, and full-site submission is manual.