How IndexNow works: from a change to a submission sent

The sequence, end to end

Five steps, in order, and each one is a place where expectations tend to run ahead of what happens.

• A page changes

  Something you publish or edit becomes different from what was there before.

• The change is detected

  Automatic submission follows change detection, which is why it covers discovered and changed addresses and nothing else. A page nobody touched has nothing to announce.

• A submission is composed

  It names the address that changed and includes the key that establishes you are entitled to speak for that hostname. The message travels as an ordinary HTTPS request, which is why no account or prior relationship is needed anywhere in this sequence.

• An engine receives it and verifies the key

  It does this by fetching the key file from the hostname in the submission. If what it finds matches, the submission is attributable to whoever controls that hostname.

• The engine decides what to do about it

  This is the step people misread, and the rest of this page is mostly about it.

Why a key exists at all

Without one, anybody could submit anybody's addresses, which would make the signal worthless within a week.

The key is not a secret in the way a password is. It is published, at a known location, on the very hostname it speaks for. Its purpose is not confidentiality but attribution: the only party who can cause a particular file to be served from a particular hostname is the party who controls that hostname, so a submission that matches proves control without needing any account, registration, or prior relationship.

That framing explains the details that otherwise look strange. It is fine that the key is visible to everybody. It is fine that it is a plain file. Neither weakens anything, because what is being demonstrated is the ability to place it, not knowledge of its contents.

Where the key file lives

At a known path on your own hostname, published as /<key>.txt, and this is the part worth being precise about.

The file is served from the address a search engine is asking about, by the edge, on your hostname. It is not held on somebody else's domain and does not need to be fetched from your origin. That placement is not an implementation convenience: it is the entire proof. A key served from anywhere else would demonstrate control of somewhere else.

The practical consequence is that a key file is per hostname. Several hostnames means several key files, each served from its own, and a submission naming one hostname is verified against that hostname alone.

What a submission claims

Very little, deliberately.

It says that a particular address changed and that whoever sent the message controls the hostname. It does not describe what changed, argue that the page is important, or request any particular treatment. There is nothing in the mechanism to exaggerate with, which is a large part of why engines are willing to accept it.

It is also worth knowing what the scope of automatic submission is, stated exactly: it covers discovered and changed addresses only, enabling it imports no history, and submitting an entire site is a manual action rather than something that happens on its own.

What an accepted submission means

That the message was well formed and the key checked out. Nothing further. The codes an endpoint can return, and what each one means, are set out in the protocol’s own documentation.

Acceptance is a statement about the submission, not about the page. The engine has not agreed to crawl the address, has not agreed to index it, and has certainly not agreed to rank it. Each of those is a separate decision made on its own criteria, and none of them reports back.

This is the single most useful thing to carry away from this section. A submission that succeeded and a page that never appears in results are entirely compatible outcomes, and neither indicates a fault. What submission changes is when an engine could learn about the change, and that is genuinely valuable and genuinely narrow.

Why resubmitting achieves nothing

The instinct after nothing happens is to send it again, and it is worth explaining why that does not help.

The message carries no urgency, no priority, and no count. Sending it twice communicates exactly what sending it once communicated, because the content is identical and the receiving side has already recorded it. Repetition adds no information for an engine to act on.

Where the page genuinely has not been revisited, the reasons live entirely on the engine's side and are not addressable from yours. Where the page has been revisited and simply is not appearing, the question is about the page rather than about its announcement.

What this section covers

The sections above walk the sequence end to end: what a submission claims, what acceptance means, and why resubmitting achieves nothing. One part earns a page of its own — the key and its file, including why it is published rather than hidden and what an engine does when it fetches it.

FAQ