IndexNow key file not found: why the fetch really fails

What the engine asked for

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 on how it works.

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.

Cause one: the file is not where it is being looked for

The commonest and the least interesting.

The path is derived from the key, so the file name and the key have to correspond, and the file has to sit at the root of the hostname rather than in a subdirectory. A file placed one level down, 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.

Cause two: the request is redirected

The file exists at the address, and the request never arrives there.

Redirects are the most common cause that looks like the file is missing 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.

Cause three: a page is returned instead of the file

The response arrives, and it is not the 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.

Cause four: the file is not reachable from outside

Everything is correct, and the request cannot get through.

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 them apart in one request

The whole diagnosis is a single fetch, made the way the engine makes it.

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.

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 the troubleshooting overview takes it apart under its own heading.

Where this stops being your problem

One arrangement removes the whole category.

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