The IndexNow aggregator: one endpoint, same engines

What the shared endpoint changes

Sending to api.indexnow.org changes one thing: your side makes one request instead of one per engine.

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. The protocol’s own FAQ describes this sharing: a submission to one participant reaches the others.

So the change is in the number of outbound messages, not in reach, treatment or speed. A submission is still an announcement that an address changed, exactly as described under what a submission claims.

Why fewer destinations is worth something

One destination instead of several has two modest, operational benefits.

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.

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.

Shared endpoint or direct: neither is recommended

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 reasonable. Reach does not vary between the two, so it is not a basis for choosing.

What the shared endpoint does not do

The shared endpoint has three limits, and the first runs against what the name suggests.

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.

Why the word aggregator misleads

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

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