The IndexNow key file: proof of control, not a secret
What the key proves, and what it does not
One property, and it is narrower than people assume.
Serving a file at a known address on your hostname demonstrates control of that hostname. That is the whole of the mechanism. It says nothing about who you are, grants no permissions, and carries no authority beyond the host it sits on.
It follows that the key is not confidential. Anybody can fetch it, exactly as any participating engine must be able to, and it is published on purpose. A key found by somebody else is not a leak, and finding one on a site you do not control is not a discovery worth reporting to anybody.
The reason that is safe rather than merely tolerable is what a stolen key would let somebody do: announce that pages on your hostname changed. They cannot announce changes for a hostname whose file they cannot serve, and announcing yours does nothing to you beyond what you can already do yourself. The mechanism is deliberately built so that the thing it protects is not worth stealing.
Where the file has to be served
At the root of the hostname the submission concerns, under a name matching the key itself, in the form /<key>.txt.
The word doing the work there is hostname. The proof binds a key to the host that serves it, so a key that answers on one hostname says nothing about another. Sites with several hostnames, a bare domain and a prefixed one, or separate hosts for separate markets, each need their own proof, and treating them as one site is the commonest structural mistake here.
On this platform the file is served by the edge at your own hostname, which is the arrangement that keeps the proof honest: the file appears where the proof has to appear, on the host you control, rather than anywhere else. Setting that up is covered under setup.
The content of the file matters less than people expect, and its reachability matters far more. Almost every failure below is a file that exists somewhere and cannot be fetched from outside. A file present on the server and unreachable over the network is, from the point of view of the proof, a file that does not exist, and the two look identical from a text editor and completely different from an HTTPS request.
Four ways it quietly stops working
None of these announces itself, and the site keeps working perfectly for visitors in all four.
A hostname changed and the proof did not follow
A new market gets a new host, a migration moves traffic to a different name, and submissions for the new hostname now have no proof behind them. The old host still verifies correctly, which makes the failure look partial and random.
Something started intercepting the path
A rule added for another purpose, a redirect applied to everything, an authentication layer placed in front of the site during a redesign: any of these can absorb the request for the key file while leaving the rest of the site untouched. Verification is checked at the time of submission rather than once at setup, so this breaks quietly long after anybody thought about it.
The file answers on one form of the address only
Served on the prefixed form and not the bare one, or over one scheme and not the other, while submissions are made for the form that does not answer. Checking the form you happen to have bookmarked reports success.
The key was regenerated and the file was not
Two halves of one change, and doing only the first leaves a valid-looking configuration that verifies against nothing. This one usually arrives with a rebuild or a migration between environments, where the value is generated fresh and nobody connects that to a file somebody placed months ago.
The check for all four is the same, and it takes seconds: request the file from outside your own network, on every form of the hostname you submit for. The four answers that request can return, and what each of them means, are set out under key checker. What to do when it fails is set out under key not found.
Changing the key
Rarely necessary, and not an emergency when it is.
Because the key is not a secret, rotating it is not a security response. The legitimate reasons are ordinary: a rebuild that generates a new one, a consolidation of several keys into one, a host that changed hands. None of those is urgent, which means the change can be made in the safe order rather than the fast one.
The safe order is to serve the new file before submitting with the new key, and to keep the old file in place until nothing uses it. Doing it the other way round produces a window in which submissions carry a key nothing can verify, and that window lasts exactly as long as it takes somebody to notice, which is usually longer than the change itself.
FAQ
Is the IndexNow key a secret?
No. It is published deliberately at a known address so that participating engines can fetch it, and its whole purpose is to be readable by anybody. It proves control of a hostname rather than identity, so it grants nothing to somebody who copies it.
What happens if somebody else uses my key?
They can announce that pages on your hostname changed, which is something you can already do and which harms you in no way. They cannot use it for any other hostname, because the proof is bound to the host serving the file rather than to the key on its own.
Do I need a separate key for each subdomain?
Each hostname needs its own proof, since a file served on one host says nothing about another. Whether that means separate keys or the same key served on each host is an implementation choice; what matters is that every hostname you submit for answers with a valid file.
Why did verification start failing when nothing changed?
Something almost certainly changed, just not in the part you were looking at. Verification happens at submission time, so a redirect rule, an added authentication layer, or a hostname migration can break it weeks after the change that caused it.
Where exactly should the file be?
At the root of the hostname, named after the key, in the form /<key>.txt. The important test is not where you placed it but whether it can be fetched from outside your network on every form of the address you actually submit for.
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.