IndexNow key file not found: why the fetch really fails
The engine went to read your key file and did not get it. Almost always the file exists and the site is working; something between the request and the file is answering instead. Four causes cover nearly every case, and telling them apart takes one request.
What an engine requests to check the key
A single plain-text file, at a fixed path, on the hostname named in the submission.
The request is for /<key>.txt over HTTPS on your own hostname, and what should come back is the file itself: plain text, nothing else, at that address. The reason this placement is not negotiable is that it is the whole proof. Only somebody controlling the hostname can cause a particular file to be served from it, which is what makes a submission attributable, as set out under why a key exists at all.
Everything on this page follows from that. The engine is not checking whether your site is healthy, whether the page looks right, or whether a human would consider the response reasonable. It is checking whether that exact request returns that exact file. What the file proves, and why it is public by design, is set out under the key file.
Key file not at the requested path
The most common cause is a key file that is not at the address being requested.
The path is derived from the key, so the file name and the key have to correspond, and the file has to be where the submission expects it: at the root of the hostname, unless the submission names another location on the same host (keyLocation). A file placed one level down without that, named with a different case, or given an extra extension by an editor is not at the address being requested, and nothing about the site will indicate a problem.
Multiple hostnames multiply this. Each hostname is verified separately against a file served from itself, so a key file present on one and absent from another produces exactly this failure for the second, while the first works perfectly and reassures you that everything is set up.
Key file request redirected
The key file exists at the address, and a redirect sends the request somewhere else before it arrives.
A redirect is a frequent cause that looks like a missing file when it is not. A rule that sends every request to a canonical form of the domain, forces a prefix, or normalises paths will happily redirect a request for the key file along with everything else. From a browser you will not notice, because a browser follows redirects and shows you the file.
The general shape to look for is any rule that acts on all paths. If your site canonicalises the domain, adds or removes a prefix, or rewrites addresses in bulk, the key file is inside the scope of that rule unless something excludes it.
A page returned instead of the key file
The response arrives, and it is a rendered page rather than the key file.
This is the cause that hides best, because to a person the site looks healthy. A framework that answers every unmatched path with a rendered page, a friendly error page that returns a decorated document, or a single-page application that serves its shell for anything it does not recognise will all produce a perfectly good response containing no key.
The tell is that the response is a document rather than plain text. A site that returns its own styled page for an address nobody has published is behaving normally in every respect except this one, which is why this cause survives so many rounds of checking by eye.
Key file blocked from outside your network
The key file is in place and correct, and an access control turns the engine's request away.
Access controls applied to the whole site catch the key file too: a staging password, an allowlist restricted to office addresses, a rule that requires a session, or a firewall rule that filters unfamiliar clients. From inside your network or your browser session everything works, which is precisely what makes this one persist.
The same applies to anything that treats an unrecognised client as suspicious. The engine fetching your key file is an ordinary client with no history on your site, and rules aimed at unwanted automation do not distinguish it from anything else automated.
Telling the four causes apart in one request
One fetch of the key file, made the way the engine makes it, tells the four causes apart.
Request the key file over HTTPS on the exact hostname in the submission, without following redirects, and look at three things: whether you were redirected, whether the body is plain text or a document, and whether you were let through at all. Each of the four causes above shows up distinctively in that one answer.
| What the one request shows | Which cause it points to |
|---|---|
| Nothing served at that address | Key file not at the requested path |
| A redirect, wherever it leads | Key file request redirected |
| A document rather than plain text | A page returned instead of the key file |
| A refusal, a challenge, or no answer | Key file blocked from outside your network |
Two conditions matter for the test to mean anything. Make the request from outside your own network, because access controls are invisible from inside it. And do not use a browser to judge the result, since a browser follows redirects and renders whatever it receives, which hides the two causes hardest to spot. How to make the request the way verification makes it is set out under key checker.
If the file comes back as plain text at that address with no redirection, this page is not your problem. A key that is read but rejected is a different situation with different causes, and it has a page of its own: key read but not accepted.
When the edge serves the key file
A key file served by the delivery layer removes all four causes.
When the layer that serves your traffic also serves the key file, it is returned from your hostname without being placed anywhere by hand, which is what submitting from the edge describes. Every cause on this page comes from something between the request and a file somebody deployed, and a file nobody deployed has nothing in front of it.
FAQ
Why does the engine say my IndexNow key file is not found?
Because the request for it did not return the file. Usually the file exists and something else answers: a redirect rule, a framework returning a page for unmatched paths, or an access control. The file being absent is only one of the four causes.
My key file opens fine in a browser. Why does verification fail?
Because a browser hides two of the causes. It follows redirects silently and renders whatever comes back, so a redirected request and a returned error page both look like success. Fetch it without following redirects, from outside your own network, and compare what you actually get.
Does the key file have to be at the root of the site?
Not strictly. The root is the default; the protocol also accepts another location on the same hostname when the submission names it, and the file then has to be exactly there. That placement is the proof of control, so a file on a different hostname never satisfies it. A site serving several hostnames needs the file served from each one it submits for, since each is verified separately.
Can a firewall block the verification fetch?
Yes. The engine fetching your key file is an unfamiliar automated client, so rules aimed at unwanted automation, staging passwords, and address allowlists all apply to it exactly as they apply to anything else.