IndexNow Submission Audit: Stop Waiting for Search Engi...

You publish a page. You wait. Maybe Bing picks it up in a few hours. Maybe Yandex finds it next week. Maybe Seznam never notices at all.

IndexNow was supposed to fix this. Instead of waiting for crawlers to discover changes on their own schedule, you push a notification: "Hey, this URL changed." Bing, Yandex, Seznam, and Naver all accept IndexNow pings. Google does not participate (they run their own crawl infrastructure and haven't adopted the protocol).

The idea is simple. The execution trips people up more than you'd expect.

The key-file problem

IndexNow works on a trust model. You prove you own a domain by hosting a key file at the root. The file name is the key itself, with a .txt extension. The file content must be the same key string, nothing else.

So if your key is abc123def456, you host a file at https://example.com/abc123def456.txt, and inside that file the only content is abc123def456.

This is where things break. The most common failures I see:

Filename and content don't match. Someone regenerates a key, updates the file content, but forgets to rename the file (or vice versa). The file exists. It returns 200. But the parity check fails silently and submissions get ignored.

The key isn't a valid hex string. IndexNow keys should be 32-character hexadecimal strings (the spec says 8+ alphanumeric characters, but most implementations generate 32-char hex). Keys with special characters or wrong lengths get rejected.

The file returns HTML instead of plain text. Your web server or CDN catches the .txt request and serves a custom 404 page or redirect. The HTTP status is 200, but the body is an HTML document, not your key.

Trailing whitespace or newlines. Your CMS or editor appends a newline. The key file should contain exactly the key string and nothing else. Extra bytes cause mismatches.

What the audit actually checks

The IndexNow Submission Audit runs through the full readiness chain:

HTTPS verification. IndexNow requires HTTPS. No exceptions.
Homepage reachability. Confirms the domain resolves and returns a response.
Robots.txt check. Looks for a valid robots.txt, checks for Sitemap directives, and scans for any IndexNow key hints.
Sitemap.xml check. Confirms a sitemap exists (IndexNow submissions reference sitemap URLs).
Key file discovery. Probes multiple sources: meta tags, link elements in the HTML head, common hex-named .txt files at root, and robots.txt hints.
Key validation. Checks format (length, character set) and fetches the key file to verify filename-content parity.
Search engine readiness. Reports which engines accept IndexNow (Bing, Yandex, Seznam, Naver) and provides the submission endpoint URLs.
CMS detection. Identifies WordPress installations where IndexNow plugins handle submission automatically.

The whole scan runs browser-side through the site's proxy. No data leaves your session.

Why sitemap and robots.txt are prerequisites

IndexNow submissions include an optional urlList and sitemapLocation parameter. When you submit a batch of URLs along with your sitemap URL, the receiving search engine can verify that the submitted URLs actually appear in your sitemap. If your sitemap is missing or broken, you lose that verification layer.

Robots.txt matters because if you're blocking the search engine's crawler via robots.txt, the IndexNow ping tells them about a URL they aren't allowed to fetch. The submission goes through but the page never gets indexed.

Both of these are things you'd catch in five seconds if you checked. Most people don't check.

Which search engines actually use IndexNow

As of early 2026, four major search engines consume IndexNow submissions:

Bing (Microsoft) was the co-creator of the protocol alongside Yandex. Submissions go to api.indexnow.org or www.bing.com/indexnow.
Yandex co-created the protocol. Accepts submissions at yandex.com/indexnow.
Seznam (Czech Republic's dominant search engine). Accepts at search.seznam.cz/indexnow.
Naver (South Korea's largest search engine). Accepts at searchadvisor.naver.com/indexnow.

You only need to submit to one endpoint. The protocol specifies that participating engines share submissions with each other (though the actual propagation timing varies).

Google has not joined IndexNow. They acknowledged it publicly but have not implemented support. If you need fast Google indexing, you still need the Google Indexing API (limited to job posting and livestream pages) or a fresh sitemap ping.

When this matters most

IndexNow shines in specific scenarios: large sites that publish or update dozens of pages daily, e-commerce sites where product availability changes frequently, news sites where timeliness is the whole point, and anyone doing a site migration where hundreds of URLs change at once.

For a five-page brochure site that updates once a quarter, IndexNow is nice to have but not critical. For a 10,000-page catalog site? The difference between waiting for a crawl cycle and pushing a notification is measured in revenue.

If you're building sites for clients or launching your own properties, this is the kind of infrastructure detail that separates amateur deployments from professional ones. I wrote about this and similar infrastructure patterns in The $97 Launch for anyone building their first web properties from scratch.

Run the audit

The IndexNow Submission Audit takes one URL and walks through every check listed above. It runs entirely in your browser. If something is broken, it tells you exactly what failed and generates an AI fix prompt you can hand to your dev or paste into Claude.

Fact-check notes and sources

IndexNow protocol specification and participating search engines: indexnow.org
Bing IndexNow documentation: Bing Webmaster Tools - IndexNow
Google's position on IndexNow (acknowledged but not adopted): Google Search Central Blog, 2022
Key file requirements (8+ alphanumeric characters, filename-content parity): IndexNow Protocol Documentation

IndexNow Submission Audit: Stop Waiting for Search Engines to Find Your Pages