Who Participates in IndexNow in 2026? A Live Registry Audit

What the live registry listed

The registry identifies protocol participants and points to their current metadata. It should not be converted into a marketing list of “search engines that will index you.” Amazonbot’s presence, for example, identifies participation in the protocol; it does not make Amazonbot a general web-search destination for publishers.

Listed is not the same as receiving real-time pushes

The participant metadata includes an optional unsubscribe field. IndexNow says the default is false; when it is true, the participant is not interested in receiving real-time push-style notifications of verified URLs. The Internet Archive metadata returned that opt-out during this capture.

A participant that opts out can still remain in the registry. That is why a useful audit needs two layers: the well-known registry file and each linked meta.json. Reporting only the seven IDs would hide an operational distinction that the protocol deliberately exposes.

The files can change. IndexNow requires participants to poll the registry at least every 24 hours, and metadata changes may take hours to propagate. Any published count needs a capture date and should be rechecked before a new conclusion is drawn.

How URL sharing is supposed to work

IndexNow’s publisher documentation says submitted URLs are shared with participating search engines. Its search-engine documentation adds the operational rule: after a receiving engine verifies a notifier’s authority over URLs, it must notify other participants that have not opted out, normally within ten seconds of verification.

The protocol supports one URL by GET or up to 10,000 URLs in a JSON POST. Publishers prove control using a key file on the submitted host. A 200 response means the endpoint received the submission; 202 can mean key validation is pending, while 400, 403, 422, and 429 describe different failure states.

Run a reproducible registry audit

1. Save https://www.indexnow.org/searchengines.json with an ISO timestamp.
2. Fetch every linked metadata URL and record the response status.
3. Capture the participant ID, API endpoint, host, homepage, and unsubscribe state.
4. Flag mismatched IDs, unreachable metadata, invalid JSON, or duplicate endpoints.
5. Publish the capture date and preserve the raw files.
6. Repeat on a schedule and report additions, removals, or state changes rather than overwriting history.

This method is more reliable than copying a participant list from an old tutorial. It also creates an evidence trail for a future change: a reader can see whether the difference came from the official registry or from an interpretation.

What publishers should monitor

Record submission time, endpoint, response code, key-validation state, submitted URL, and later crawl observations by engine where server logs allow it. Do not collapse those rows into one “indexed” field. The visibility measurement crosswalk uses the same principle: different systems expose different layers of evidence.

IndexNow is useful for notifying participating services about additions, updates, and deletions. It is not a substitute for crawlable internal links, accurate sitemaps, canonical consistency, useful content, or engine-specific webmaster diagnostics.

Primary data and documentation

• IndexNow live participant registry
• IndexNow documentation for search engines
• IndexNow publisher documentation