The IndexNow aggregator: one endpoint, same engines

What it actually changes

One thing changes, and it is worth being precise about it, because the word itself invites considerably larger expectations.

Without it, announcing a change means sending the same message to each participating engine in turn, one connection after another, and handling whatever each of them answers. With it, the message goes to one place and is distributed from there. The engines receive the same announcement either way, and each of them still makes its own decision about what to do with it, on its own criteria and its own schedule.

So the change is in the number of outbound messages: not in reach, not in how any engine treats what it receives, and not in the speed of anything that happens afterwards. A submission is still an announcement that an address changed, exactly as described on how it works.

Why fewer destinations is worth something

Two practical reasons, both of them operational rather than strategic, and both modest.

• Fewer places to fail

  Every destination is an HTTPS connection that can be refused, time out, or return something unexpected. Sending to one instead of several reduces the number of ways a submission can partly succeed, which is the state hardest to reason about.

• Fewer things to observe

  When something is not working, the question "which engine did not receive it" is considerably harder to answer than "did the submission leave at all". One destination makes the first question rarer, which matters most when you are diagnosing rather than when everything works.

Neither reason involves reaching more engines than before, and any description implying otherwise is describing something other than this.

There is also a small reason to know it exists even if you never choose it. Descriptions of the protocol list endpoints, and a list containing something that is plainly not a search engine looks like an error in the documentation until you know what that entry actually is.

Neither route is the recommended one

Worth stating, because pages like this usually end with a preference.

The engines cannot tell how a submission reached them in any way that affects their decision, so the outcome is identical. What differs is what your side looks like: one connection to watch or several, one place where a delivery problem shows up or several. Teams that already monitor outbound requests carefully often prefer the direct route for exactly that reason, and teams that do not prefer having less to watch.

Choosing on that basis is entirely reasonable. Choosing on the basis of reach is choosing on something that does not vary between the two.

What it does not do

Three limits, and the first is the one the name suggests most strongly in the wrong direction.

• It does not add participants

  The engines reachable through api.indexnow.org are exactly the engines that take part in the protocol. Google is not among them, and no routing changes that, which is set out under the Google page.

• It does not guarantee delivery to each participant

  It accepts a submission and passes it on; what each engine then does about it remains that engine's business entirely. A submission accepted here is a message accepted, and nothing beyond that.

• It does not replace the direct route

  Sending to engines individually remains perfectly valid, and neither approach achieves more than the other in anything an engine ends up doing. The choice is about how many outbound connections you prefer to maintain and observe.

Where the confusion comes from

The word is doing most of the damage, and it is worth naming why.

In most contexts an aggregator collects things from many sources and presents them together, which implies breadth: more sources, more coverage, more than you had. Here it works in the opposite direction. It takes one thing from you and hands it to several, and the several were always reachable anyway.

That inversion in the direction of flow is why the same underlying question keeps being asked in several different forms: whether using it means reaching engines you otherwise would not, and whether not using it means missing some. Both answers are no, and both follow from the direction of flow rather than from anything about the implementation.

Seeing one endpoint is not a fault

Worth saying plainly, because this is the specific situation that brings most people to a page like this one in the first place.

If you expected several destinations in your configuration or in your logs and you see exactly one, nothing is wrong with the setup. That is the aggregator doing its job, and the participating engines are being told through it rather than by you directly. The number of endpoints is not a measure of coverage.

Where you do want to check something, the useful question is whether submissions are leaving at all, and what came back when they did. Both are sorted by symptom rather than by response code under troubleshooting, and neither becomes easier or harder because of which route you chose.

FAQ