How to set up IndexNow: four ways to send a submission

What every method has in common

Two things are true regardless of which route you choose, and both are worth settling before comparing them.

A key file has to be reachable over HTTPS at /<key>.txt on the hostname the submissions are about. That file is what lets an engine attribute a submission to whoever controls the hostname, which is covered on how it works. No method skips it, and a method that appears to skip it is placing the file somewhere on your behalf rather than doing without one.

The message itself is also identical whichever route sends it: an ordinary HTTPS request naming the address that changed. No route sends a richer message, and none can ask for different treatment, so choosing between them is a question about your own operations rather than about what an engine receives.

The scope is also the same in every case, stated exactly: automatic submission covers discovered and changed addresses only, enabling it imports no history, and submitting a full site is a manual action. No route changes those boundaries. If a method promises to announce everything you ever published, it is describing the manual action under a different name.

Sending by hand

The simplest route, and the right one less often than it is used.

Submitting manually means composing the message yourself, one address or a batch at a time. It needs nothing set up beyond the key file, and it is the only route available when the site is published in a way that has no publishing event to hook into: files copied to a server, a page edited directly, output generated by a process nobody wants to modify.

Its limitation is not effort but memory. Manual submission happens when somebody remembers, and the announcements that matter most are the ones made during a busy week when nobody was thinking about announcements. As a permanent arrangement it degrades quietly, because nothing about it fails visibly when it stops happening.

It is also the honest choice for a full-site submission, which is a manual action by definition rather than something to automate.

Sending from a content system

A class of solution rather than a specific one: the system you publish through sends the submission when you publish.

What it does is straightforward. The system already knows when a page was created or edited, so it announces the change at the moment it happens without anybody remembering to. That timing is the point, and it is a large improvement over the manual route for anybody publishing regularly.

What to expect of it needs one qualification. The submission is triggered by whatever that system considers a publishing event, and systems differ on this. Editing a draft, changing metadata, reordering a listing, or republishing without changing anything may or may not count. When submissions appear at unexpected moments or fail to appear at expected ones, the definition of that event is usually the explanation rather than anything about the protocol.

Sending from the delivery layer

The route that asks nothing of the site, because the layer in front of it already sees what changed.

A layer that serves your traffic is in an unusual position: it observes addresses being requested and content changing without needing to be told by the application. That makes it the one route where announcements happen without any code being written, any plugin being maintained, or any publishing event being defined by somebody else.

The trade is a matter of where the knowledge lives. A content system knows what you meant by publishing; a delivery layer knows what actually changed. For most sites, those coincide often enough that the difference is theoretical, and the absence of anything to maintain is worth more than the distinction.

Sending from your publish process

Integration in your own pipeline, which is the most precise route and the one that most rewards being done deliberately.

If you build and deploy through a process you control, that process knows exactly which addresses changed in this release. Announcing them at the end of a deploy is a few lines in a place you already maintain, sending the same HTTPS request any other route would send, and the accuracy is better than anything else can offer because nothing is being inferred.

There is one way to do this badly, and it is common enough to name. Sending submissions on a schedule, such as a nightly job that announces everything touched that day, reintroduces exactly the delay the mechanism exists to remove. Announce on the publishing event, not on a timer. A submission a few hours late is not much better than no submission at all, given that engines revisit on their own anyway.

Choosing between them

One question settles it in most cases: what already knows that something changed?

If your publish process knows, use it. If a content system knows, let it send. If neither has a usable event and the site changes often, the delivery layer is the route that needs no such event to exist. Manual submission is for the cases that fall outside all three, and for full-site submissions, which are manual by nature.

The methods are not additive. Two routes announcing the same change do not announce it twice as effectively; they produce duplicate messages that say the same thing, for the same reason that resubmitting an address achieves nothing: the message carries no priority and no count. Pick one route and let it be the only one.

What this section covers

The four routes are compared above, each by what makes it fire and what it leaves behind. One of them earns a page of its own — sending from the delivery layer, and why that route needs nothing from the site itself.

FAQ