IndexNow Response Codes Explained

Response codes are the fastest way to know whether IndexNow trusts your setup. A 200 or 202 means acceptance, while 400, 403, 422 and 429 each point to a specific fix in key hosting, JSON shape, URL quality or send rate. Many teams log submissions but never inspect codes, so they repeat the same failure for months. This guide explains every common IndexNow response code with causes, examples, debugging steps and retry logic you can copy. You will learn to distinguish malformed requests from auth problems, invalid URL lists from throttling, and acceptance from actual indexing. This indexnow response codes guide provides practical checklists that shorten debugging from days to minutes while respecting quotas and validation discipline.

Key takeaways

200 and 202 mean accepted for processing, not guaranteed indexing or ranking.
400 points to JSON or host errors, 403 to key problems, 422 to invalid URLs, 429 to throttling.
Validate key file, host consistency and URL quality before retrying failed batches.
Log codes over time to spot systemic issues and guide content and linking fixes.

How IndexNow responses work at a glance
200 OK versus 202 Accepted what success looks like
400 Bad Request malformed JSON and host mismatch
403 Forbidden key problems and auth failures
422 Unprocessable invalid URLs in the list
429 Too Many Requests throttling and Retry After
Debugging workflow logs reproduction validation checklist
Code patterns for handling each code with retries
Preventing repeat errors with preflight validation
When success response still means no crawl
Monitoring indexnow response codes over time
FAQ
Sources
Further reading

IndexNow response codes dashboard showing success and error handling flow

How IndexNow responses work at a glance

Every IndexNow submission returns an HTTP status code that tells you whether engines accepted your notification and, if not, which part to fix. Success codes in the 200 range mean the request was well formed and queued for processing. Client error codes in the 400 range mean your request, key, host mapping or URL list needs correction before resending. Rate limiting at 429 means you sent too much too fast and should slow down. These codes describe acceptance of the notification, not a promise that listed pages will be crawled or indexed. Quality, crawlability and linking still decide outcomes after acceptance. A mature workflow logs every code per batch, alerts on rising error shares and pairs code trends with content fixes. This section frames the mental model you will use for the rest of the guide. Read codes as routing instructions for your next action, not as grades on your site. See also the IndexNow complete guide for background that pairs with this step.

IndexNow is an open protocol co-developed by Microsoft Bing and Yandex. Current supporters include Bing, Yandex, Naver, Seznam and other engines listed on the official IndexNow site, with DuckDuckGo routing through Bing for discovery. Always confirm the live list on the official documentation during planning, since partnerships evolve and no blog post should present a stale list as exhaustive. Google does not support IndexNow. Google relies on sitemaps, Search Console URL Inspection and Request Indexing, plus the Google Indexing API for JobPosting and BroadcastEvent pages only. Never claim an IndexNow ping reaches Google. Track IndexNow outcomes in Bing and Yandex portals and Google outcomes separately in Search Console. IndexNow complements sitemaps, internal linking, canonical tags, robots.txt and crawl budget work. It does not replace them.

Submit canonical https URLs only, without tracking parameters or variants.
Deduplicate edits so one page updated five times pings once per cycle.
Space batches minutes apart and watch for 429 throttling signals.
Validate status, canonical and robots before every batch.
Keep sitemap lastmod accurate so pings and sitemap tell the same story.

Bulk discipline protects signal quality. IndexNow allows up to 10,000 URLs per POST, but practical use favors small batches of changed canonical URLs spaced minutes apart. Queue pending URLs, deduplicate repeats, throttle to a gentle pace, use exponential backoff on HTTP 429, honor any Retry After hint, and log request IDs with timestamps and response codes. Never hammer endpoints with parallel loops or resubmit unchanged URLs daily. Engines learn which senders provide fresh meaningful changes and which send noise. A clean queue with prioritization, validation and logging keeps acceptance high and makes debugging straightforward when a batch returns 400, 403, 422 or 429.

Measurement closes the loop between submission and outcome. Record every submitted URL with change type, submit time and response code, then check first crawl timestamps in Bing and Yandex Webmaster Tools and index status after seven days. Compare against your pre IndexNow baseline for similar launches. If discovery shortens from days to hours while quality and linking stay constant, the workflow is helping. If pings return success but crawls never arrive, look at content depth, internal link depth, canonical consistency, sitemap lastmod accuracy, server response times and robots rules before increasing volume. Keep Google metrics separate, since those engines follow independent scheduling and quality evaluation.

200 OK versus 202 Accepted what success looks like

A 200 OK response means the endpoint processed your request synchronously and accepted the URLs for consideration. A 202 Accepted means the request was valid and queued for asynchronous processing, which is common for bulk POST payloads. Both count as success for submission health, and both require the same follow up. Log timestamp, batch size and code, then watch for first crawls in Bing and Yandex Webmaster Tools over the next hours and days. Do not resubmit success batches, do not assume indexing is guaranteed and do not treat 202 as a lesser result. Differences between 200 and 202 reflect server handling, not URL priority. If success codes arrive but crawls never follow, shift investigation to page quality, internal link depth, canonical clarity, sitemap accuracy and server performance. Success codes confirm your key, host and JSON are correct, which narrows future debugging to content and crawl factors.

Check	What to confirm	How to verify
Host consistency	All URLs share one host per request	Normalize domain and split markets
Key accessibility	Key file returns exact string	Fetch key URL in browser and API client
Canonical form	Submit preferred URL only	Inspect canonical tag and status
Crawlability	Page returns 200 with content	Fetch as bot and review robots
Change reality	Content actually changed	Compare lastmod and page diff

Indexnow response codes troubleshooting diagram showing 400 403 422 handling flow

400 Bad Request malformed JSON and host mismatch

A 400 response means the server could not parse or trust the request shape. Typical triggers include invalid JSON with trailing commas or bad escaping, missing required fields such as host, key, keyLocation or urlList, host values that include protocol or paths instead of bare domain, keyLocation that does not match the key, and urlList entries that mix hosts or protocols. To fix, validate JSON with a linter, confirm host is lowercase bare domain, confirm keyLocation is an absolute https URL at the root that returns the exact key string, and confirm every listed URL shares the declared host and uses absolute https form. Test with a single URL GET before resending bulk POST. Log the exact payload hash for the failing batch so you can diff against the corrected version. Repeated 400s without payload changes waste time, so quarantine failing batches and require validation to pass before any retry.

Submit canonical https URLs only, without tracking parameters or variants.
Deduplicate edits so one page updated five times pings once per cycle.
Space batches minutes apart and watch for 429 throttling signals.
Validate status, canonical and robots before every batch.
Keep sitemap lastmod accurate so pings and sitemap tell the same story.

403 Forbidden key problems and auth failures

A 403 response means authentication failed even though the request shape was readable. Common causes are a key file that returns 404, redirects, wrong content type or extra whitespace, a key value in the payload that does not match the file content, keyLocation pointing to the wrong host or path, and submitting URLs for a host you have not verified. Fixes start at the key URL itself. Fetch it anonymously in a browser and with curl, confirm HTTP 200, exact key string with no HTML wrapper, and stable access over time. Then confirm payload key equals file content character for character, confirm keyLocation uses https and the same host as urlList entries, and confirm DNS and redirects do not alter the path. Rotate keys carefully by hosting old and new files during transition and updating submitters in one coordinated change. Never retry 403 in a tight loop, since the problem is ownership proof, not rate.

Generate a random key string with letters, numbers and dashes.
Host the key text file at the root of your verified host with exact content.
Fetch the key URL anonymously to confirm public access and correct content type.
Submit one canonical URL and confirm a 200 or 202 response.
Log URL, timestamp and response code before scaling to small batches.

422 Unprocessable invalid URLs in the list

A 422 response means the request was well formed and authenticated, but one or more URLs failed semantic validation. Frequent offenders are relative paths instead of absolute https URLs, tracking parameters and session IDs that create duplicates, non canonical variants that point elsewhere via canonical tags, pages that return 404, 500 or soft 404, blocked resources via robots, and noindex pages that should never be submitted. The fix is preflight validation. For each candidate, check absolute https form, single host consistency, 200 status with useful content, self referencing or correct canonical, robots allowed and no noindex in meta or headers. Remove offenders, log reasons and resubmit only clean entries. Keep allow lists for product, article and category templates and deny lists for cart, checkout, account, search and faceted routes. Over time, 422 rate becomes a quality metric for your feed hygiene. A falling 422 share means upstream filtering is improving.

Submit canonical https URLs only, without tracking parameters or variants.
Deduplicate edits so one page updated five times pings once per cycle.
Space batches minutes apart and watch for 429 throttling signals.
Validate status, canonical and robots before every batch.
Keep sitemap lastmod accurate so pings and sitemap tell the same story.

429 Too Many Requests throttling and Retry After

A 429 response means you exceeded a practical rate or volume threshold and should slow down. It can follow large back to back bulk batches, parallel workers hitting the same host, resubmission loops or sudden spikes after migrations. The correct handling is to stop sending, read any Retry After hint, wait at least that long plus jitter, then resume with smaller batches and longer gaps. Implement exponential backoff where each consecutive 429 doubles the delay up to a cap, and reduce batch size from hundreds to dozens until success stabilizes. Never retry immediately in a tight loop, never add more parallel workers to catch up and never treat 429 as an auth error that needs key changes. Track 429 frequency per day as a signal of queue health. Occasional 429 during major refreshes is normal, while daily 429 on routine volumes means your pacing, deduplication or prioritization needs redesign.

Generate a random key string with letters, numbers and dashes.
Host the key text file at the root of your verified host with exact content.
Fetch the key URL anonymously to confirm public access and correct content type.
Submit one canonical URL and confirm a 200 or 202 response.
Log URL, timestamp and response code before scaling to small batches.

Debugging workflow logs reproduction validation checklist

A repeatable debugging workflow turns code confusion into quick resolution. Start by capturing the failing batch ID, timestamp, payload hash, response code and response body snippet from logs. Reproduce with a single URL from the batch using GET to isolate host and key issues from list quality issues. Then run a validation checklist. Fetch the key URL anonymously, confirm host consistency across payload and list, lint JSON, check each URL for absolute form, status, canonical, robots and noindex, and confirm you are not mixing staging and production hosts. Fix one layer at a time and retest with a minimal batch before resending full volume. Document symptom, code, likely cause and exact check in a one page runbook so any teammate can follow the same path. Good debugging is boring and sequential, which is why it works faster than guessing and resubmitting. See also the troubleshooting checklist for background that pairs with this step.

Check	What to confirm	How to verify
Host consistency	All URLs share one host per request	Normalize domain and split markets
Key accessibility	Key file returns exact string	Fetch key URL in browser and API client
Canonical form	Submit preferred URL only	Inspect canonical tag and status
Crawlability	Page returns 200 with content	Fetch as bot and review robots
Change reality	Content actually changed	Compare lastmod and page diff

indexnow response codes diagram: 200 ok versus 202, 403 forbidden key problems, 429 too many requests

Code patterns for handling each code with retries

Consistent code handling prevents one off scripts from drifting out of spec. Centralize submission in one function that returns structured results per batch. Treat 200 and 202 as success and record time to first crawl follow up. Treat 400 as a validation bug that quarantines the batch without retry. Treat 403 as an auth bug that pages the site owner to check key hosting. Treat 422 as a data quality signal that logs offending URLs with reasons and resubmits only clean entries. Treat 429 as a pacing signal that triggers exponential backoff with jitter and batch size reduction. Set timeouts, use a descriptive User Agent, avoid logging secret keys and version your submitter so logs show which code version sent each batch. Keep retry limits explicit, such as three attempts for 429 then park until the next window, to avoid infinite loops that look like abuse.

Generate a random key string with letters, numbers and dashes.
Host the key text file at the root of your verified host with exact content.
Fetch the key URL anonymously to confirm public access and correct content type.
Submit one canonical URL and confirm a 200 or 202 response.
Log URL, timestamp and response code before scaling to small batches.

import requests, time
def submit(payload):
    r = requests.post("https://api.indexnow.org/indexnow", json=payload, timeout=20)
    if r.status_code in (200, 202):
        return True
    if r.status_code == 429:
        time.sleep(60)
        return False
    print(r.status_code, r.text[:500])
    return False

curl -i "https://api.indexnow.org/indexnow?host=www.example.com&url=https://www.example.com/new-page&key=abc123def456&keyLocation=https://www.example.com/abc123def456.txt"

Preventing repeat errors with preflight validation

Preflight checks move failures left, where they are cheap to fix. Before building JSON, run every candidate through host normalization, https enforcement, tracking parameter stripping, canonical resolution, status fetching, robots evaluation and noindex detection. Reject early and log reasons with counts by template so content teams can fix sources rather than filters. Validate JSON schema for required fields and types, enforce urlList size caps well below 10,000 for routine jobs, and split by host before send. Add contract tests that submit a single known good URL to a staging harness after every code change. Monitor preflight reject rate as a leading indicator. A sudden spike often precedes a 422 wave and points to a template deploy, feed regression or sitemap error. Prevention costs minutes per day and saves hours of post send debugging.

Submit canonical https URLs only, without tracking parameters or variants.
Deduplicate edits so one page updated five times pings once per cycle.
Space batches minutes apart and watch for 429 throttling signals.
Validate status, canonical and robots before every batch.
Keep sitemap lastmod accurate so pings and sitemap tell the same story.

When success response still means no crawl

Acceptance and crawling are separate stages with different gatekeepers. Acceptance checks key, host, JSON and basic URL validity. Crawling checks server availability, robots, crawl budget, internal link importance, sitemap signals, content uniqueness and site reputation. A 200 or 202 followed by silence usually points to thin or duplicate content, orphaned pages with no internal links, canonicals that consolidate elsewhere, slow or error prone servers, or low priority for new sections. Diagnose by comparing submitted URLs that were crawled quickly against those ignored, looking for patterns in depth, template, word count, image uniqueness and linking. Fix one variable at a time, improve internal links from collections or hubs, ensure sitemap lastmod matches reality and resubmit once after material improvement. Repeated pings without content change do not create priority and can reduce trust in your signals.

Check	What to confirm	How to verify
Host consistency	All URLs share one host per request	Normalize domain and split markets
Key accessibility	Key file returns exact string	Fetch key URL in browser and API client
Canonical form	Submit preferred URL only	Inspect canonical tag and status
Crawlability	Page returns 200 with content	Fetch as bot and review robots
Change reality	Content actually changed	Compare lastmod and page diff

Monitoring indexnow response codes over time

Trend analysis turns individual codes into operational insight. Build a daily view with total batches, success share for 200 plus 202, and error shares for 400, 403, 422 and 429. Add median batch size, median submit to crawl latency from Webmaster Tools and quarantine depth for invalid URLs. Alert on sustained 403, which suggests key hosting drift, on rising 422, which suggests feed or template regressions, and on frequent 429, which suggests pacing problems. Review weekly with content and engineering owners, tying code trends to deploys, migrations and catalog imports. Retain raw logs for 90 days and aggregated trends for a year to support seasonality comparisons. Teams that watch codes as product metrics fix systemic issues early, keep acceptance high and spend bulk capacity on pages that can actually benefit from faster discovery.

Submit canonical https URLs only, without tracking parameters or variants.
Deduplicate edits so one page updated five times pings once per cycle.
Space batches minutes apart and watch for 429 throttling signals.
Validate status, canonical and robots before every batch.
Keep sitemap lastmod accurate so pings and sitemap tell the same story.

Reading each indexnow status code quickly saves hours of guessing. An indexnow 400 error usually means malformed JSON or host mismatch, so lint the payload and confirm bare domain form. For success, remember the indexnow 202 meaning is queued asynchronous acceptance, while a plain indexnow ok response with 200 means synchronous acceptance. Both count as success, so log either and follow up with crawl checks instead of resubmitting the same batch again and again. Log response codes, join to crawl data and keep sitemaps accurate so pings and inventory tell the same story.

Solid indexnow error handling starts with preflight checks that prevent repeat failures. Confirm you do not send with an indexnow invalid key by fetching the key URL anonymously and matching payload key character for character. Keep an indexnow debug checklist for DNS, redirects and content type, and treat a burst of indexnow too many requests as a pacing signal. Honor Retry After, reduce batch size and pause parallel workers until success share recovers and stays stable. Log response codes, join to crawl data and keep sitemaps accurate so pings and inventory tell the same story.

FAQ

Is 202 worse than 200 for IndexNow?

No. Both indicate acceptance, with 202 meaning queued asynchronous processing that is common for bulk POST payloads. Log either as success, avoid resubmitting and follow up by checking first crawls in Bing and Yandex Webmaster Tools. If crawls lag despite consistent 200 and 202 responses, investigate content depth, internal linking, canonicals, sitemaps and server health rather than chasing a different success code. Treat each indexnow status code as routing help and remember the indexnow 202 meaning is queued acceptance, not lower priority.

How do I fix repeated 403 errors?

Fetch your key URL anonymously and confirm HTTP 200 with the exact key string and no HTML wrapper. Confirm payload key matches file content, keyLocation uses https on the same host as listed URLs, and no redirects alter the path. Check DNS, hosting and content type, then test with a single URL GET before resending bulk batches. Coordinate key rotation by hosting old and new files during the switch and updating all submitters together. Repeated indexnow 403 often means an indexnow invalid key, so fetch the file anonymously and match values exactly before retrying.

What should I do about 422 on large batches?

Quarantine the batch, inspect response details and validate each URL for absolute https form, host consistency, 200 status, correct canonical, robots allowed and no noindex. Remove or fix offenders, log reasons by template and resubmit only clean entries. Add preflight validation to filter non canonical and blocked URLs before they reach the endpoint, which steadily reduces 422 share over time. An indexnow 400 error points to JSON or host issues, so add indexnow error handling with linting and host checks before resend.

How long should I wait after a 429?

Honor any Retry After header as the minimum, add jitter and double the delay after consecutive 429s up to a reasonable cap. Reduce batch size and pause parallel workers during recovery. For routine volumes, hourly or daily flushes are usually enough. Frequent 429 on normal volumes signals a pacing or deduplication problem that needs queue redesign rather than faster retries. Frequent indexnow 429 means indexnow too many requests, so honor Retry After, add jitter and slow the queue until recovery.

Do response codes tell me about Google indexing?

No. IndexNow codes reflect processing by participating engines such as Bing, Yandex, Naver and Seznam. Google does not support IndexNow, so Google outcomes must be tracked separately through sitemaps, Search Console inspection and quality improvements. Report IndexNow and Google funnels independently to avoid misattribution and to set correct expectations with stakeholders. Use an indexnow debug checklist that logs each indexnow status code with timestamps so Google separate tracking stays clean and honest.

Which code should I alert on first?

Alert on sustained 403 because it blocks all submissions until key hosting is fixed, then on rising 422 which indicates feed or template regressions, then on frequent 429 which indicates pacing issues. Track success share of 200 plus 202 as the headline health metric and review trends weekly with owners who can fix templates, feeds and queue settings quickly. An indexnow ok response and steady 200 share signal health, while rising indexnow 429 or indexnow 403 needs immediate queue or key fixes.

IndexNow Response Codes Explained: 200, 202, 400, 403, 422