Keep a small notification ledger
Use one row per changed URL, with a shared request batch reference when several URLs travel together. The following fields are a proposed working record; they are not extra IndexNow request parameters.
| Field | Minimum value to retain |
|---|---|
| Submitted URL | Full original URL, including the actual host and path |
| Change type | added, updated, or deleted; describe the buyer answer that changed |
| Submitted at | Timestamp with an explicit UTC offset, such as 2026-10-04T14:30:00+08:00 |
| Request batch | A local reference linking this URL to its saved request |
| Request context | Endpoint, host, URL list and key-file reference |
| Response | HTTP code, response body and response headers |
| Page check | Actual page response and check time, especially for deletion |
The timestamp is illustrative and uses Beijing time (+08:00), a recordkeeping choice rather than a protocol requirement. The batch reference identifies the notification request. Keep the request and receipt so errors remain traceable.
The protocol accepts the URL that was added, updated, or deleted. For a deletion, keep the original page URL in the notification; a replacement page is a different URL. IndexNow protocol documentation
Read the six protocol responses literally
The Reason column below preserves the documentation’s wording. The final column proposes the next inspection; it does not expand what the response confirms. IndexNow response format
| HTTP code | Protocol reason | Next inspection |
|---|---|---|
| 200 | URL submitted successfully | Retain the successful receipt; leave later outcomes unconfirmed. |
| 202 | URL received. IndexNow key validation pending. | Inspect the key file; keep validation marked pending. |
| 400 | Invalid format | Inspect request syntax, parameters and URL encoding. |
| 403 | In case of key not valid (e.g. key not found, file found but key not in the file) | Check the key file location and its exact contents. |
| 422 | In case of URLs which don’t belong to the host or the key is not matching the schema in the protocol | Check each URL against the host and check the key format. |
| 429 | Too Many Requests (potential Spam) | Inspect request frequency and the response headers. |
Check the changed URL before notifying
Make the content change observable before considering a notification. A saved CMS edit and a public page response can differ, so check the URL a reader would visit.
- Confirm a real added, updated or deleted event. For an updated buyer answer, name the changed claim, instruction or evidence. Refer to From Google Rankings to ChatGPT Answers for a method of identifying the question an existing page should answer and confirming the supporting facts before writing.
- Inspect the exact public URL. Request the exact URL you will submit, as a reader would reach it, and record the status and content you see.
- Compare the saved request with the intended host and URLs. Check encoding, required parameters and the key-file reference before diagnosing a rejected response.
For deleted content, the FAQ explicitly covers pages returning “HTTP 404 or HTTP 410 status codes.” Check the original URL and retain the status actually returned, with its check time. If it still serves the old answer with 200, investigate the page removal before treating the notification as evidence of a completed deletion. IndexNow FAQ
For a manual setup, check that the hosted UTF-8 key file contains the submitted key. If the file is outside the root, include its location through keyLocation and check that its location covers the submitted URLs. These are ownership checks for the notification protocol. IndexNow protocol documentation
Route errors to evidence, not repeated sends
Start with the failed request and its receipt; the code suggests a check, not a complete diagnosis.
- For 400, compare the request with the documented format. Look for missing or misspelled parameters, broken encoding and malformed JSON if a URL list was used.
- For 403, retrieve the key file referenced by the request and compare its contents with the submitted key. Record whether the file was found and whether the key matched.
- For 422, inspect each submitted host and the key’s allowed format. A mixed-host URL list needs scrutiny; do not replace this check with guesses about page content.
- For 429, pause submissions and follow the Retry-After header when supplied; reduce submission frequency or batch size. The FAQ says exact limits are not publicly disclosed and participating engines set their own thresholds. Do not invent a universal daily limit or a fixed retry timetable. IndexNow FAQ Examine the recent notification pattern and keep the response headers with the receipt before preparing another attempt.
After fixing a defect, preserve the earlier error beside the corrected request so the reason for the correction remains clear.
Separate receipt from downstream evidence
A protocol acknowledgment answers whether the notification reached its stated stage. It cannot establish a later page fetch, search result or Copilot citation.
Submitting a URL does not guarantee immediate indexing.
IndexNow FAQ
The FAQ says the search engine evaluates whether to crawl after submission. Its decision uses crawl quota, scheduling logic and quality signals; the receipt itself is not a record of a fetch. It also says IndexNow does not guarantee indexing. IndexNow FAQ
A downstream claim needs direct evidence of that outcome. Do not close a search or AI visibility question with an HTTP receipt alone. Content readiness for answers is a separate concern covered in getting cited by ChatGPT; no request response promises inclusion, citation or ranking.
Want to see how AI engines describe your brand today?
Get a free growth audit