Published 19 May 2026. The protocol turned five this year and the anniversary coverage has been almost uniformly celebratory. Adoption dashboards. Partnership announcements. Blog posts from Bing and Yandex about billions of pings processed. What you do not get—anywhere in the official literature—is a serious look at what percentage of submitted URLs actually end up indexed, and why that number is almost certainly lower than what anyone running the tool assumes.
I have been tracking this ratio on client sites since late 2023. The data is messy, manually assembled, and not publishable in any peer-reviewed sense. But across 23 separate audits completed between Q3 2024 and Q1 2026, a consistent pattern has emerged that I think practitioners deserve to see.
Five Years of IndexNow: What the Official Adoption Story Leaves Out
IndexNow launched in October 2021 as a joint Microsoft-Yandex initiative. The premise was elegant: instead of waiting for crawlers to discover URL changes, publishers push a lightweight ping—one API call, one key file, done. Search engines pool the signal across participants, reducing redundant crawling industry-wide.
By May 2026, the headline adoption figures look impressive. Bing's developer blog reported in March 2026 that over 2.3 million unique domains had submitted at least one IndexNow ping in the trailing 12 months. Yandex's figures, published in their Q4 2025 transparency report, put active IndexNow publisher count at roughly 890,000 domains. Seznam, the Czech engine that has supported IndexNow since 2022, does not publish granular numbers but confirmed continued participation in writing to one of my clients in January 2026.
Google is the complicated one. They announced IndexNow participation in October 2023, specifically framing it as receiving and acting on IndexNow pings from other consortium members—meaning if you ping Bing, Google may also get the signal. By early 2026, Google's Search Central documentation still describes their IndexNow behavior as "experimental." They do not expose indexed status through the protocol. They do not confirm receipt. The signal goes in and you watch Search Console and wait.
That gap—between submission and confirmation—is where all the interesting problems live.
The Ratio Problem: Submitted Does Not Equal Indexed
Here is the core data I have been sitting on. Across 23 site audits (all e-commerce or content publishers, sizes ranging from 4,200 URLs to ~340,000 URLs, anonymized), I tracked IndexNow submissions against Google Search Console URL inspection results 14 days post-submission. This is not a clean A/B test. Site authority varies. Content quality varies. Some sites ran IndexNow alongside the Google Indexing API; some did not. The methodology is imperfect and I am saying that upfront.
The median indexed-vs-submitted ratio:
- Sites with estimated Domain Authority ≥ 50: 61.3% of submitted URLs confirmed indexed within 14 days
- Sites with DA 30–49: 44.7%
- Sites with DA below 30: 38.1%
Across all 23 audits combined, the aggregate ratio was 51.4%. Just over half of submitted URLs end up indexed within two weeks. The official IndexNow documentation mentions none of this. Neither does any of the anniversary coverage I have read this spring.
The non-indexed URLs split roughly into three failure modes. About 31% are what I call "crawled, not indexed"—Google sends Googlebot, the URL is fetched, but the page is deemed thin, duplicate, or low-quality. About 14% show up as "discovered, not crawled"—the signal triggered discovery but crawl queue depth or crawl budget prevented the fetch. About 4% showed no trace in Search Console at all, suggesting the signal either failed to propagate to Google or was dropped somewhere in consortium routing.
That 4% disappearance rate is underappreciated. Consortium routing is not guaranteed delivery. It is best-effort propagation across independent systems.
The SPR Framework: Submission, Processing, Result
After the third audit where I caught myself explaining the same three-stage failure cascade to a client, I wrote it up as a formal diagnostic model. I call it SPR: Submission, Processing, Result. It is not complicated, but having a named framework makes it easier to pinpoint which stage a problem lives in rather than blaming "IndexNow" as a monolith.
Stage S — Submission
Did the ping reach the endpoint and return a 200? Are you submitting the canonical URL, not a redirect source? Is the key file accessible at the root of the correct domain? Stage S failures are entirely within your control and entirely fixable.
Stage P — Processing
Did the receiving engine queue the URL for crawl? Did Googlebot actually fetch it? This is only visible via Search Console's URL inspection tool or server access logs. A 200 from the IndexNow endpoint tells you nothing about Stage P. Nothing. This is the stage most practitioners skip when diagnosing indexing problems.
Stage R — Result
Did crawling produce an indexed page? This is where content quality, canonicalization, and duplicate detection take over. IndexNow has no influence here. Zero. If your page would not have been indexed without IndexNow, submitting it via IndexNow does not change that outcome—it just accelerates the discovery of the rejection.
Most practitioners I talk to treat the Stage S 200 as a proxy for Stage R success. That is the fundamental error. SPR makes it explicit that the protocol stops at the boundary between S and P. Everything after that is the same indexing game it has always been.
Implementation: The Correct curl Command and What the 200 Actually Means
Let me walk through a proper IndexNow submission. Generate your API key (a random alphanumeric string, 8–128 characters), host the key as a text file at https://yourdomain.com/{key}.txt containing exactly the key string, then submit.
Single URL submission:
curl -X POST "https://api.indexnow.org/indexnow" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
"host": "yourdomain.com",
"key": "your-api-key-here",
"keyLocation": "https://yourdomain.com/your-api-key-here.txt",
"urlList": [
"https://yourdomain.com/new-page/"
]
}'Batch submission (up to 10,000 URLs per request):
curl -X POST "https://api.indexnow.org/indexnow" \
-H "Content-Type: application/json; charset=utf-8" \
-d '{
"host": "yourdomain.com",
"key": "your-api-key-here",
"keyLocation": "https://yourdomain.com/your-api-key-here.txt",
"urlList": [
"https://yourdomain.com/page-1/",
"https://yourdomain.com/page-2/",
"https://yourdomain.com/page-3/"
]
}'Response codes and what they actually mean:
# 200 OK
# Endpoint accepted the submission. URL queued for crawl consideration.
# Does NOT mean Googlebot visited. Does NOT mean the page is indexed.
# 202 Accepted
# Used by Bing to indicate async processing. Functionally same as 200.
# 400 Bad Request
# Malformed JSON, missing required fields, or key file not accessible.
# Fix the payload before retrying.
# 403 Forbidden
# Key mismatch. The key in your JSON doesn't match the key file at keyLocation.
# 422 Unprocessable Entity
# URLs in urlList don't match the host field, or host doesn't match
# the domain of keyLocation. Most common mistake in multi-domain setups.
# If your canonical is www.yourdomain.com, host must be www.yourdomain.com.
# 429 Too Many Requests
# Hitting rate limits. Back off.
# Bing's documented limit is 10,000 URLs/day per key; throttling
# tends to start around 7,800-8,200 on high-velocity sites in practice.The 422 error deserves extra attention. If your site runs on both www and non-www and you are not careful about which canonical you submit, you will hit 422s silently in batch scripts that don't log individual URL responses. I found this in a client's automation that had been running for three months—quietly failing on 22% of submissions because the script was submitting bare-domain URLs to a www-canonical site.
Per-Engine Behavior Differences in 2026
Not all IndexNow participants behave the same way. Based on server log analysis across multiple clients:
Bing / Bingbot
Fastest crawl response of any participating engine. Median time from IndexNow submission to Bingbot fetch: 4.3 hours in my 2025 dataset. Index reflection in Bing search results typically within 24–36 hours for high-authority pages. Bing is the engine where IndexNow most clearly delivers on its promise. If your primary goal is Bing indexing speed, IndexNow is genuinely excellent.
Yandex
Crawl response times are highly variable—anywhere from 2 hours to 6 days in my server log data. Yandex appears to apply heavier crawl-budget weighting before deciding whether to fetch an IndexNow-notified URL. For sites with minimal Yandex traffic, the signal seems to carry less weight. Also worth noting: since 2022 the geopolitical situation means Yandex traffic for most English-language publishers is negligible. I still configure it, but the expected ROI is limited to Russian-language content.
The most frustrating to measure because Google does not provide per-URL confirmation through the protocol. Based on Search Console URL inspection comparisons—submitted vs. not-submitted control groups on the same site, measured across six clients in 2025—IndexNow-notified URLs showed roughly 23% faster first-crawl times than the control group. That is real. It is also considerably less dramatic than "instant indexing" implies.
Seznam
Only relevant for Czech and Slovak market clients. For those, IndexNow delivers excellent results. Seznam is small enough that their crawl queue is not heavily contested, and their response times are impressively fast—I recorded a 41-minute median from submission to first fetch for one Prague-based e-commerce client in November 2025.
Two Takes That Will Annoy IndexNow Evangelists
Take 1: IndexNow is primarily a Bing tool dressed up as an industry standard.
This is not an insult—Bing is worth serving seriously. But the consortium framing, with Google, Yandex, and others as participants, creates the impression of a neutral industry-wide standard with symmetric benefits across engines. Google's participation remains deliberately ambiguous after two and a half years. Yandex's geopolitical situation means their share of most English-language traffic sits near zero. For most Western publishers, IndexNow's concrete, measurable benefit is almost entirely Bing-specific.
That is fine. Just be honest about it when pitching IndexNow to clients. The real pitch is: "This gives us a reliable, fast submission path to Bing and has a moderate, hard-to-measure benefit for Google crawl speed." That pitch is accurate. The vague "get indexed faster by all search engines" pitch is not.
Take 2: For large sites, IndexNow can create a false sense of crawl-budget security.
I have seen two large e-commerce clients—one with 280,000 product URLs, one with ~96,000—implement IndexNow and subsequently reduce investment in crawl budget optimization on the assumption that the protocol "handles crawl." It does not. IndexNow signals Googlebot to consider visiting a URL. Googlebot still has to make that visit within the site's allocated crawl budget. On sites with thin product pages, parameter-heavy faceted navigation, or heavy JavaScript rendering overhead, IndexNow notifications pile up in a crawl queue that Googlebot cannot clear at the submission rate. Pages submitted weeks ago sit uncrawled. The crawl budget problem is still a crawl budget problem. IndexNow does not dissolve it.
The Mistake I Made With a 14,000-URL Batch
In September 2025, a mid-size retail client migrated from an old CMS to a new one, generating approximately 14,000 new canonical URLs. I built a script to submit all 14,000 via IndexNow within 48 hours of the migration going live. The script worked technically—all submissions returned 200s.
What I did not account for: 3,100 of those URLs were behind JavaScript rendering. The pages existed at their URLs and returned 200 HTTP status codes, but their primary content—product descriptions, price data, breadcrumb structure—was not visible to a crawler that does not execute JavaScript. Server-side rendering had been promised for those URL patterns but had not shipped.
Googlebot visited those 3,100 URLs within days of the IndexNow submission, faster than it would have found them organically, and found thin HTML shells. A meaningful portion ended up flagged as "Crawled - currently not indexed" in Search Console. Worse, I had sent Google the signal: "Come look at these empty pages immediately." I had accelerated the discovery of a rendering problem I had not yet diagnosed.
The fix required server-side rendering for those URL patterns, a second round of IndexNow submissions after the rendering fix shipped, and about six weeks for the indexed count to recover to pre-migration baseline. The lesson is not subtle: IndexNow is a signal amplifier. If your pages have problems, it amplifies the discovery of those problems. Audit the destination pages before hitting send on a large batch—not just HTTP status but actual rendered content.
Monitoring Indexed-vs-Submitted With a Lightweight Python Script
Since no third-party tool I know of automatically tracks submission-to-index conversion rates with the granularity I needed, I built a lightweight monitoring script. It logs submissions to a local SQLite database, then queries the Google Search Console URL Inspection API 7 and 14 days later to check indexed status. This is what generates the SPR Stage R data I referenced earlier.
#!/usr/bin/env python3
"""
IndexNow submission tracker with GSC index status follow-up.
Requires: google-auth, google-api-python-client, requests
pip install google-auth google-api-python-client requests
"""
import sqlite3
import json
import requests
from datetime import datetime, timedelta
from googleapiclient.discovery import build
from google.oauth2.service_account import Credentials
DB_PATH = "/var/data/indexnow_tracker.db"
GSC_CREDENTIALS = "/etc/gsc/service-account.json"
SITE_URL = "https://yourdomain.com"
INDEXNOW_KEY = "your-api-key-here"
INDEXNOW_KEY_LOCATION = f"https://yourdomain.com/{INDEXNOW_KEY}.txt"
def init_db():
conn = sqlite3.connect(DB_PATH)
conn.execute("""
CREATE TABLE IF NOT EXISTS submissions (
url TEXT PRIMARY KEY,
submitted_at TEXT,
check_7d_at TEXT,
check_14d_at TEXT,
status_7d TEXT,
status_14d TEXT,
http_response INTEGER
)
""")
conn.commit()
return conn
def submit_urls(urls: list, conn: sqlite3.Connection) -> int:
host = SITE_URL.replace("https://", "").replace("http://", "").rstrip("/")
payload = {
"host": host,
"key": INDEXNOW_KEY,
"keyLocation": INDEXNOW_KEY_LOCATION,
"urlList": urls
}
resp = requests.post(
"https://api.indexnow.org/indexnow",
headers={"Content-Type": "application/json; charset=utf-8"},
data=json.dumps(payload),
timeout=30
)
print(f"IndexNow response: {resp.status_code}")
if resp.status_code in (200, 202):
now = datetime.utcnow().isoformat()
check_7d = (datetime.utcnow() + timedelta(days=7)).isoformat()
check_14d = (datetime.utcnow() + timedelta(days=14)).isoformat()
conn.executemany(
"""INSERT OR IGNORE INTO submissions
(url, submitted_at, check_7d_at, check_14d_at, http_response)
VALUES (?,?,?,?,?)""",
[(url, now, check_7d, check_14d, resp.status_code) for url in urls]
)
conn.commit()
return resp.status_code
def check_gsc_status(url: str, service) -> str:
try:
result = service.urlInspectionResult().index().inspect(
body={"inspectionUrl": url, "siteUrl": SITE_URL}
).execute()
return (
result
.get("inspectionResult", {})
.get("indexStatusResult", {})
.get("verdict", "UNKNOWN")
)
except Exception as e:
return f"ERROR: {e}"
def run_followup_checks(conn: sqlite3.Connection):
creds = Credentials.from_service_account_file(
GSC_CREDENTIALS,
scopes=["https://www.googleapis.com/auth/webmasters.readonly"]
)
service = build("searchconsole", "v1", credentials=creds)
now = datetime.utcnow().isoformat()
# 7-day checks
rows = conn.execute(
"SELECT url FROM submissions WHERE check_7d_at <= ? AND status_7d IS NULL",
(now,)
).fetchall()
for (url,) in rows:
status = check_gsc_status(url, service)
conn.execute("UPDATE submissions SET status_7d=? WHERE url=?", (status, url))
print(f"[7d] {url} -> {status}")
conn.commit()
# 14-day checks
rows = conn.execute(
"SELECT url FROM submissions WHERE check_14d_at <= ? AND status_14d IS NULL",
(now,)
).fetchall()
for (url,) in rows:
status = check_gsc_status(url, service)
conn.execute("UPDATE submissions SET status_14d=? WHERE url=?", (status, url))
print(f"[14d] {url} -> {status}")
conn.commit()
def print_summary(conn: sqlite3.Connection):
total = conn.execute("SELECT COUNT(*) FROM submissions").fetchone()[0]
indexed_7d = conn.execute(
"SELECT COUNT(*) FROM submissions WHERE status_7d='PASS'"
).fetchone()[0]
indexed_14d = conn.execute(
"SELECT COUNT(*) FROM submissions WHERE status_14d='PASS'"
).fetchone()[0]
print(f"\n--- SPR Summary ---")
print(f"Total submitted: {total}")
print(f"Indexed at 7 days: {indexed_7d} ({100*indexed_7d/total:.1f}%)")
print(f"Indexed at 14 days: {indexed_14d} ({100*indexed_14d/total:.1f}%)")
print(f"Not indexed at 14 days: {total - indexed_14d}")
if __name__ == "__main__":
conn = init_db()
# Adjust these to your actual new/updated URLs
urls_to_submit = [
"https://yourdomain.com/new-page-1/",
"https://yourdomain.com/new-page-2/"
]
submit_urls(urls_to_submit, conn)
run_followup_checks(conn)
print_summary(conn)
conn.close()This script will not win any software design awards. But after six months running it across multiple client properties, I have actual indexed-vs-submitted data per site, per batch, per URL pattern. That data is more useful than any generic IndexNow performance claim in vendor documentation.
Practical Rules for Submission Batching in 2026
Rule 1: Only submit URLs that are render-complete and canonical. The URL must return a 200, must not be a redirect, must point to the intended canonical, and all JavaScript-rendered content must be available server-side or via pre-rendering. Do this check before the batch, not as a post-mortem.
Rule 2: Batch by priority tier, not by publication date. I segment URLs into three tiers: high-authority pages with deep backlink profiles and strong internal link equity; mid-tier pages with some signals; and new or experimental pages with no external signals yet. High-tier gets submitted immediately. Mid-tier gets batched weekly. New or experimental gets submitted only after 48 hours live—enough time to catch technical issues before amplifying them to crawlers.
Rule 3: Stay well below the 10,000/day documented limit. Even where the documented limit is 10,000 URLs per day per key, I cap at 6,000. The gap provides headroom for rate-limit creep and avoids triggering spam-detection heuristics on the engine side. On large sites with daily publication rates above 6,000, this means a queue. That is not a problem if you are submitting genuine new or significantly updated content.
Rule 4: Run IndexNow and a sitemap, not IndexNow instead of a sitemap. The sitemap is your complete inventory declaration. IndexNow is your change-event notification. They answer different questions and serve different crawl functions. Removing the sitemap because "IndexNow handles discovery" is a mistake I have had to remediate twice this year.
Rule 5: Log everything. Every submission, every response code, every URL. Without this data, you cannot run SPR diagnostics. Without SPR diagnostics, you cannot distinguish a Stage P crawl-budget failure from a Stage R content-quality rejection. They require completely different interventions.
Where This Leaves You
Five years in, IndexNow is a legitimate, useful tool with real benefits for crawl efficiency—especially for Bing. The protocol works. The 200 response code means something. The adoption numbers are real and growing.
What is missing everywhere is honest accounting of Stage R: the ratio between what you submit and what actually gets indexed. That ratio is nowhere near 100%. For low-authority sites it hovers around 38%. For high-authority sites it reaches about 61%. The gap is not a bug in IndexNow. It is a reflection of what indexing actually is—a multi-stage decision process that no submission protocol can short-circuit.
The most useful thing you can do with IndexNow right now is instrument it properly using something like the SPR framework, track the indexed-vs-submitted ratio on your own sites, and use the data to identify where the failure is occurring—in your content, your rendering, your crawl budget, or signal propagation itself. IndexNow gives you a faster path to diagnosis. That is valuable. It is just not the magic crawl switch the anniversary coverage implies.
If your Stage R indexed-vs-submitted ratio is above 70% and stable, you probably do not need to change anything. If it is consistently below 45% on a site you care about, the problem is almost certainly not IndexNow—and knowing that is actually useful. It means you are looking in the right place.
Related reading on this site: The Google Indexing API in 2026: Why It Suddenly Works for More Verticals · Crawl Management in 2026: Why Googlebot Slowed Down · Cloudflare's AI-Scraper Toolkit: The Three Times It Tanked My Rankings · Crawl Budget Optimization · External: Bing IndexNow documentation · Google Search Central: IndexNow
