IndexNow: What It Does, and What It Cannot Do for Google

Many teams submit a URL through IndexNow and then wait for Google to crawl it. That is the wrong expectation: Google does not participate in IndexNow, so an IndexNow submission is not a Google indexing request. IndexNow is a URL-change notification protocol for participating search engines, principally Bing, Yandex and Naver.

That distinction matters when a new product page, migration or urgent correction needs to appear in Google. IndexNow can reduce the delay before some other engines learn about a change, but it cannot force Google to crawl, index or rank the URL. Treat it as a targeted discovery signal, not as a universal indexing button.

What IndexNow actually does

IndexNow lets a website notify participating search engines that a URL has been added, updated or deleted. The notification normally contains the URL and a verification key proving that the submitting site controls the host. The engine can then decide whether to fetch the URL and reassess its content.

The protocol is useful because it replaces passive discovery with an explicit change notification. Without it, an engine may discover a changed URL through links, XML sitemaps, feeds, browser activity or its own crawl schedule. With IndexNow, the site can say, in effect, “this URL changed; please consider fetching it.”

That request is not the same as a crawl command. A participating engine may ignore, delay or deprioritise a notification. It can still evaluate the URL for accessibility, duplication, spam, quality, canonicalisation, robots directives and other eligibility signals.

IndexNow is most relevant for sites with frequent, meaningful changes, such as:

• Inventory-led ecommerce sites where product availability and prices change regularly.
• News, listings, jobs, events or travel sites that publish and remove pages continuously.
• Large sites where important changes can otherwise wait behind a substantial crawl queue.
• Sites that need deleted or redirected URLs to be discovered promptly by participating engines.

It is less valuable when a site changes only a few pages per month and already has strong internal linking, clean XML sitemaps and reliable crawl access. It is also not a replacement for fixing weak content, blocked resources, slow servers or poor information architecture.

Google does not participate in IndexNow

The central point is simple: Google does not accept IndexNow notifications. Submitting a URL through an IndexNow integration therefore does nothing directly for Google Search. It does not place the URL in Google’s crawl queue, bypass Google Search Console, accelerate Google indexing or improve the URL’s ranking signals.

This is where popular advice is often wrong. “Install IndexNow to get your new pages indexed faster in Google” is inaccurate. The correct claim is narrower: install IndexNow to notify participating search engines of URL changes. Google must be handled through Google-compatible discovery and indexing methods.

Search engine	Does it accept IndexNow?	Alternative way to notify or support discovery
Bing	Yes	IndexNow submission, XML sitemap, internal links and Bing Webmaster Tools diagnostics
Yandex	Yes	IndexNow submission, XML sitemap, internal links and Yandex Webmaster tools
Naver	Yes	IndexNow submission where supported, XML sitemap, internal links and Naver webmaster tools
Google	No	XML sitemap, internal links, Google Search Console URL Inspection for individual eligible requests and technically accessible pages
Other search engines	Check current vendor documentation	Use the engine’s own webmaster tools, sitemap process or supported submission API

The table describes notification support, not an indexing guarantee. Participation means an engine can receive and process the signal. It does not mean every submitted URL will be crawled or displayed in search results.

What IndexNow cannot do for Google

IndexNow cannot perform any of the following Google-specific jobs:

• It cannot request a Google crawl.
• It cannot submit a URL to Google Search Console.
• It cannot guarantee that Google discovers a newly published page.
• It cannot make a noindex page eligible for indexing.
• It cannot override robots.txt restrictions, server errors or authentication.
• It cannot resolve a canonical tag that points to another URL.
• It cannot make duplicate, thin or low-value content rank.
• It cannot replace structured data validation, internal links or an XML sitemap.

For Google, use the discovery methods that Google supports. Keep important URLs in a current XML sitemap, link them from crawlable pages, return the correct HTTP status and ensure that Googlebot can fetch the content and its important resources. For a small number of urgent pages, Google Search Console’s URL Inspection workflow may allow an individual indexing request, subject to Google’s own limits and decisions.

Do not build a process that sends every product URL to IndexNow and assumes Google will respond. That can create a misleading reporting loop: the integration reports a successful notification, the SEO dashboard reports “submitted”, and the team concludes that Google has been alerted. None of those events proves Google received the request, because Google did not participate.

How to set up the IndexNow key file

IndexNow requires a key file that verifies control of the submitting host. The key is usually a random string, commonly generated by the platform or integration. The exact key format and submission method can vary, so follow the current instructions for the implementation you choose.

1. Generate one key. Store the exact character sequence, including capital letters, lower-case letters and numbers. Do not manually retype it in multiple systems if copying is available.
2. Create the verification file. The file name normally follows the key, for example abc123key.txt. The file content must contain the key in the form required by the implementation.
3. Place it at the web root. The file should be publicly reachable at the root of the exact host being submitted, such as https://www.example.com/abc123key.txt.
4. Test the file anonymously. Open the URL in a private browser window or request it without an authenticated session. Confirm an HTTP 200 response and verify that the body contains the expected key.
5. Submit changed URLs. Use your CMS, server-side integration or the relevant IndexNow endpoint. Send only URLs that were actually added, updated or deleted.
6. Monitor responses. Record the timestamp, host, URL, HTTP response and integration errors. A successful API response confirms receipt of the request, not indexing.

The host relationship is critical. A key file at https://example.com/key.txt does not automatically verify https://www.example.com/, https://shop.example.com/ or http://example.com/. Treat each hostname and protocol as a separate technical property unless the current implementation explicitly supports the relationship.

Common implementation errors

The key file is in the wrong directory

A frequent mistake is placing the file in a CMS upload folder, a subdirectory or a staging path. If the submitted URL belongs to https://www.example.com/products/item-a, the key file normally needs to be discoverable from the root of www.example.com, not from /products/ or /uploads/.

The submitted host does not match the verified host

Submitting a www URL while the key file exists only on the non-www host is a classic failure. The same issue occurs with regional subdomains, mobile subdomains and separate commerce platforms. Test the key URL on the exact host used in the submission payload.

Redirects, WAF rules or authentication block the key

A redirect from the key file to a login page, a CDN challenge or an unexpected hostname can prevent verification. A browser session may appear to work while a crawler receives a 403, 404 or challenge page. Check the response without cookies and from more than one network when security infrastructure is involved.

The key content is altered

Some deployment pipelines add formatting, a file extension, a byte-order mark or extra text. Compare the served response with the original key. Whitespace is not always harmless, especially when an integration expects the file body to equal the key exactly.

Every URL is submitted repeatedly

IndexNow is for changes, not a substitute for a daily bulk crawl request. A practical operating rule is to submit a URL when its meaningful state changes and to avoid repeated submissions for identical content. For high-volume sites, define a queue, deduplicate URLs and set an operational review threshold, such as investigating batches with more than 5% failed submissions. That threshold is a monitoring choice, not an IndexNow requirement.

IndexNow versus Google’s discovery workflow

For Google, begin with technical eligibility. The URL should return a successful response, normally HTTP 200 for an indexable page, and should not be blocked by robots.txt, a noindex directive or access controls. The page should have a self-consistent canonical strategy and should be reachable through internal links.

Maintain an XML sitemap that contains canonical, indexable URLs rather than every URL the database happens to generate. Remove redirected, blocked and permanently deleted pages from the sitemap. A sitemap is a discovery hint, not an indexing guarantee, but it gives Google a structured list of URLs to consider.

Use Google Search Console’s URL Inspection process selectively for urgent individual pages. Do not confuse the visible “request indexing” action with a guaranteed publication date. Google can take hours, days or longer to crawl and evaluate a URL, and some pages may remain excluded after crawling.

For deletions, use the correct mechanism for the situation. A 404 or 410 can communicate permanent removal, while a relevant 301 redirect can consolidate signals to a replacement. A temporary removal tool is not a substitute for fixing the underlying status, canonical or content problem.

IndexNow can run alongside this Google workflow. Send meaningful changes to Bing, Yandex and Naver through IndexNow, while continuing to manage Google through sitemaps, links, Search Console and sound technical SEO. The two processes complement each other; one does not activate the other.

How to measure whether IndexNow is worth using

Measure IndexNow against the engines it can reach, not against Google impressions. Track at least four fields for each event: URL, change type, submission result and the time between submission and the engine’s observed crawl or search visibility. Separate new URLs, updates and deletions because their business impact differs.

Review the data over a meaningful period, such as 30 to 90 days, rather than judging the system from one urgent page. Look for operational outcomes: fewer stale product pages in participating engines, faster discovery of availability changes, cleaner removal of expired listings and fewer manual submissions.

Do not report “IndexNow increased Google traffic” unless a controlled analysis supports that conclusion through another causal explanation. Google does not receive the IndexNow signal, so any Google change must be investigated through Google’s own crawl, content, link, technical and algorithmic factors.

For a small site, implementation may take less than a day if the CMS or hosting stack has built-in support. For a complex international site, allow several engineering days for host mapping, queues, logging, deployment controls and testing. The financial value depends on the cost of stale URLs and the number of participating-engine visitors; do not buy a tool solely because its dashboard labels a URL “submitted”.

The accurate summary is narrow but useful: IndexNow tells participating search engines that a URL changed. It does not tell Google. Set up the key at the exact host root, submit only genuine changes, verify responses independently and keep Google’s sitemap, internal-linking and Search Console workflows separate.

Related reading

• Our services — scope, method and what we measure.
• Technical SEO
• Website Change Monitoring: Catching Silent SEO Regressions
• Competitive Intelligence: Reading a Rival Site Properly