Submit a small changed-URL batch
Validate and explicitly send same-host URLs to IndexNow after publishing, updating, or removing pages.
IndexNow Submitter
Send a page change signal to IndexNow on an explicit click. Google does not use IndexNow, and a received submission never guarantees crawling or indexing.
1. Create and publish an IndexNow key
- Generate or enter a key.
- Publish a plain-text file containing only that key (a final newline is fine) at
https://your-site.example/your-key.txt. - Enter URLs below. This tool checks that root key file before it sends anything to IndexNow.
The key is kept in this form only until your explicit submission; it is not saved by this site.
2. Choose what changed
Use after publishing or materially updating one page.
One protocol request contains up to 10,000 same-host URLs. Larger lists are split into visible, paced requests; duplicates and fragments are removed before submission.
Optional: import a sitemap
Sitemap XML pasted or uploaded here is parsed only in this browser. Remote sitemap indexes run in explicit, request-budgeted passes; use Continue if child sitemaps remain.
3. Submit deliberately
All submitted URLs must be absolute HTTP(S) URLs on one exact host. Deleted URLs should already return 404 or 410; IndexNow is only a discovery signal, not a removal guarantee.
Checks run from our server; we fetch the URL you enter and don't keep the results. On Submit only, the Worker checks your public root key file and sends the URL list plus key to IndexNow. It does not store the key or URLs. This browser may retain a small recent-attempt summary containing only host, URL count, workflow, time, and response status. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.
Site passport Local context for this saved site
Local data
Saved targets, named lists, and recent check summaries remain only in this browser.
Rate this tool
Sample report
A successful example reports the verified host, number of accepted URLs, upstream response status, and whether another batch remains. A rejected example names the failed key, host, URL, or rate-limit condition without claiming that any URL was submitted.
How it works
- Normalize absolute HTTP(S) URLs and require one exact host per submission.
- Verify that the public root key file contains the supplied key.
- Send bounded batches only after the explicit submit action.
- Stop on an unknown delivery state or upstream rejection so a retry cannot silently duplicate later batches.
Frequently asked questions
Does an accepted IndexNow submission guarantee indexing?
No. IndexNowIndexNow is an open push protocol that lets you instantly tell participating search engines (Bing, Yandex, Naver, Seznam, and Yep) which URLs you've added, changed, or removed via a simple HTTP request — and one submission is shared across all of them. Google does not use it. acceptance confirms receipt of a change signal only. Participating search engines still decide whether and when to crawl and index each URL.
Does Google use IndexNow?
No. Use Google Search Console, sitemaps, and eligible Google indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. APIs for Google-specific discovery workflows.
Where is my IndexNow key stored?
The key stays in this form until an explicit submission. The site does not store the key or submitted URLs; the browser may retain only the bounded recent-attempt summary described below.
Where this tool helps
Common use cases
Preflight host and key requirements
Catch mixed hosts, malformed URLs, or key-location problems before making a submission request.
Record the submission response
Review the endpoint result and keep submission separate from any claim that a participating engine crawled or indexed the URLs.
Avoid using the wrong protocol
Confirm that the workflow is for IndexNow participants and not for Google, which does not use IndexNow.
Watch the full workflow
IndexNow Submitter walkthrough
Read the transcript
IndexNow Submitter
IndexNow can notify participating search engines about changed or deleted U-R-Ls, but receipt is never an indexing promise and Google does not use it. I’ll show you how to create and publish the key, choose single, batch, deleted, or sitemap inputs, run preflight checks, submit explicitly, read responses and retry boundaries, understand privacy and limits, and verify next steps.
Step 1
Use this tool after publishing, materially updating, or deleting U-R-Ls on a site you control. IndexNow is used by participating search engines, not Google. A successful response confirms receipt of a signal only.
Step 2
Generate or enter an eight-to-one-hundred-twenty-eight-character key, then publish a plain-text file containing only that key at the displayed root path. The tool verifies that public file before any submission.
Step 3
Use Single for one changed page, Batch for a list, and Deleted only after those U-R-Ls genuinely return four-oh-four or four-ten. Every submitted U-R-L must be absolute and use one exact host.
Step 4
This walkthrough fills a fictional example dot com key and changed U-R-L but never clicks Submit or contacts IndexNow. In a real workflow, publish the key file first, enter only changed U-R-Ls, and use preflight before the deliberate submission click.
Step 5
Batch input removes duplicates and fragments, enforces protocol and length limits, and rejects mixed hosts. One protocol request contains at most ten thousand U-R-Ls; larger lists become visible paced batches.
Step 6
Load a public sitemap, upload local X-M-L, or paste it in the browser. Remote sitemap indexes use explicit request-budgeted passes and a Continue step when children remain. Review imported U-R-Ls before submission.
Step 7
Preflight verifies the root key file and checks robots context without sending the IndexNow payload. Resolve a missing or mismatched key, wrong host, invalid U-R-L, or access problem before clicking Submit.
Step 8
The Worker sends the key and normalized U-R-L list only when you click Submit. This fictional outcome shows H-T-T-P two-oh-two for one U-R-L; it is illustrative and means receipt, not crawling, indexing, or ranking.
Step 9
The workflow stops on an unknown delivery state or upstream rejection so a retry cannot silently duplicate later batches. Honor Retry-After and recent-attempt warnings, and deliberately confirm any intended retry.
Step 10
The site does not store the key or submitted U-R-Ls. This browser may retain only a bounded summary containing host, count, workflow, time, and response status. That summary is not IndexNow history or proof of persistence.
Step 11
IndexNow does not guarantee crawl or index inclusion, does not remove deleted content by itself, and does not cover Google. Accurate status codes, crawlable internal links, canonical signals, and maintained sitemaps still matter.
Step 12
Record the submitted batch and response, monitor participating webmaster tools and logs, and confirm changed pages remain accessible. For deletions, verify four-oh-four or four-ten. Use Search Console and Google-eligible discovery workflows separately.
Signal the change—then verify discovery and indexing.
Confirm the accepted batch and keep the public key file stable, then monitor participating search-engine tools and server logs. Maintain accurate sitemaps and internal links, verify deleted U-R-Ls return four-oh-four or four-ten, and use Search Console workflows for Google without treating an IndexNow response as a crawl or index guarantee.
Common issues & how to fix them
- Error Published IndexNow key does not match Fix: Publish the exact submitted IndexNow key at the declared key-location URL, then verify the public file contents match byte for byte.
- Error Submitted URL host differs from key host Fix: Submit each host separately with the key published on that same host.