Tools

IndexNow key checker: is the file really served?

2 min readUpdated Sep 2026
The check requests /<key>.txt from your hostname over HTTPS, without following redirects and without rendering anything, and looks at what comes back. It is the same request an engine makes when it verifies a submission, made the same way, so the answer is the one that matters.

The four answers

Everything that can happen falls into one of these.

  • The file came back as plain text

    Your side is correct. Verification will read what you published, and if submissions are still failing the cause is elsewhere.

  • A redirect came back

    The request never reached the file. This is the most common cause that looks like a missing file: a rule canonicalising the domain or normalising paths catches the key file along with everything else, and a browser hides it by following along.

  • A page came back

    Something answered, and it was a document rather than the file. A framework serving its shell for unmatched paths or a decorated error page both produce this, and both look perfectly healthy to a person.

  • Nothing came back

    Either the file is genuinely absent, or something in front of the site refused the request. Access controls and rules aimed at unfamiliar automated clients apply to the fetching engine exactly as they apply to anything else.

ONE REQUEST, FOUR ANSWERS the request plain text came back your side is correct a redirect came back the request never reached the file a page came back a document answered, not the file nothing came back absent, or something refused the request
Only the top one is your side being correct. Each of the other three maps to a section of key not found, which covers what to do next.

Each of those maps to a section of key not found, which covers what to do next.

Why the browser is not this check

Two habits make the browser the wrong instrument here.

It follows redirects silently, so the second answer above looks like the first. And it renders what it receives, so the third looks like a page loading normally rather than like a key file that is missing. Both of those are helpful behaviour when browsing and unhelpful when the question is exactly what a server returns.

THE SAME RESPONSE, TWO READERS a redirect, or a page a browser: looks like it is working it follows the redirect, and renders the page this check: names which one it asks the way verification asks
The upper box is dashed not because the browser is broken, but because what it reports answers a different question than the one being asked.

This check makes the request the way verification makes it, which is the only version of the answer that predicts what an engine will see.

What it does not tell you

It reports on the key file and nothing else.

A correct key file does not mean a submission succeeded, and a successful submission does not mean a page was indexed. Those are separate steps with separate outcomes, and the last of them is the engine's decision rather than anything observable from here, as set out on how it works.

If the file is served by the layer delivering your traffic rather than placed by hand, most of the failures above stop being possible, which is what submitting from the edge describes.

FAQ

How do I check my IndexNow key file?

Request it from your own hostname the way an engine does: over HTTPS, at the exact path, without following redirects, and from outside your network. What matters is not whether it opens in a browser but whether that specific request returns the file as plain text.

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.