Every week, someone opens a Rank Math or Yoast SEO support ticket because their IndexNow history shows 202 instead of 200. They assume the submission failed. It didn’t.

202 means the API received your request but is verifying your key file asynchronously. This always happens on your first submission after generating or changing a key. Once the search engine has verified the key once, subsequent submissions return 200.

The only time 202 becomes a problem is if you’re still seeing it after several days on the same key. That usually means the key file verification is failing silently — which puts you in 403 territory even though the response code says 202. Check your key file manually before assuming everything is fine.

A 400 error means your request reached the API successfully but had structural problems. This is distinct from a 422 (which is about the data inside a well-formed request). A 400 is a format issue, not a logic issue.

The Three Most Common Causes

1. Missing or malformed URL parameter. For GET requests, the url parameter must include the full protocol. yourdomain.com/page fails; https://yourdomain.com/page is required. URLs with spaces or special characters must be percent-encoded.

2. Invalid JSON body on POST requests. The bulk submission format requires Content-Type: application/json header and valid JSON. A trailing comma in your array, an unescaped quote in a URL, or a missing closing bracket all trigger 400.

3. Missing the key parameter. Both GET and POST formats require an explicit key value. Some implementations that auto-generate this parameter occasionally produce an empty string if the key hasn’t been saved properly.

{
  "host": "yourdomain.com",
  "key": "YOUR_API_KEY",
  "keyLocation": "https://yourdomain.com/YOUR_API_KEY.txt",
  "urlList": [
    "https://yourdomain.com/page-1/",
    "https://yourdomain.com/page-2/"
  ]
}

How to Debug a 400

1. Test with a raw curl command rather than through a plugin, so you can see exactly what’s being sent.
2. Validate your JSON at jsonlint.com if doing bulk POST submissions.
3. Check that every URL in your array starts with https:// (not just http:// and not a relative path).
4. Verify the Content-Type: application/json header is present on POST requests.

The 403 is the error that most sites are getting silently, right now, without realizing it. Your SEO plugin says it’s configured. The Bing Webmaster Tools dashboard looks quiet. But every submission is returning 403 and being discarded.

The official definition: “In case of key not valid — key not found, file found but key not in the file.” That sentence contains two distinct failure modes, and they have different fixes.

Failure Mode 1: The Key File Isn’t Accessible at All

The API can’t find yourdomain.com/{key}.txt. This happens when:

• →The plugin created the key file in the wrong directory (common on multisite WordPress setups)
• →A Cloudflare firewall rule or Page Rule is blocking external access to .txt files at root
• →The file was created successfully but a CDN is serving a cached 404 from before the file existed
• →Your .htaccess has a rule that denies access to files matching /*.txt for security reasons

Test this in under 30 seconds: open your browser and navigate directly to https://yourdomain.com/YOURKEY.txt. If you see your key string as plain text: the file is accessible. If you see a 404 or a login redirect or a blank page — that’s your 403 source, regardless of what the plugin UI shows.

Failure Mode 2: File Exists, But Key Content Doesn’t Match

This is more subtle. The file is there, the API can read it — but the key string inside the file doesn’t match the key in your API request. The most common ways this happens:

1. BOM character. If the key file was created on Windows (or by certain text editors) with UTF-8 BOM encoding, there are three invisible bytes at the start of the file. The API reads those bytes as part of the key string. Your key is abc123 but the file contains [BOM]abc123. They don’t match → 403. Open the file in VS Code and check the bottom-right status bar. It should say “UTF-8” not “UTF-8 with BOM.”
2. Trailing newline or whitespace. Some editors automatically append a newline character. The key string must be the complete, exact, only content in the file.
3. Key was regenerated in the plugin but the old key file is still on disk. Regenerating a key in Rank Math or Yoast updates the database value and the submission request, but if the automatic file replacement failed (permissions issue), the old file still sits at the root with the old key. Every submission uses the new key, every verification check finds the old key → 403.

Fix Sequence for 403

1. Navigate directly to your key file URL in a browser. Confirm it returns the key string as plain text.
2. If the file is inaccessible: create it manually via FTP or cPanel and upload it to your site root (/public_html/ or equivalent). Name it {YOURKEY}.txt, contents = the key string only, saved as UTF-8 without BOM.
3. If the file is accessible but you’re still getting 403: compare the key string in the file character by character against what your plugin is submitting. Check for BOM, trailing spaces, or a line break.
4. If you changed your key recently: delete the old key file from the root directory, create a new one with the new key, clear any CDN cache for that path.
5. Resubmit a single URL manually and check Bing Webmaster Tools → URL Submission within 15 minutes. If the URL appears → fixed.

The 422 error trips people up because the request format is valid — it would pass a 400 check — but the content is semantically wrong. The most common version: your key is registered for yourdomain.com, but you’re submitting URLs from subdomain.yourdomain.com.

The IndexNow specification treats each subdomain as a completely separate host. A key file at yourdomain.com/key.txt does not authorize submissions from blog.yourdomain.com. You need a separate key file at blog.yourdomain.com/key.txt (using the same or a different key), and each subdomain must submit its own URLs independently.

Other Causes of 422

• →HTTP/HTTPS mismatch. Your key file is at https://yourdomain.com/key.txt but submitted URLs include http:// versions. The protocol is part of the host check.
• →Submitting URLs from an external domain. Some automation setups accidentally include URLs scraped from internal links that point to third-party resources. Those fail 422 every time.
• →The host field in bulk POST doesn’t match the submitted URLs. In a bulk JSON submission, the host parameter must match the domain of every URL in the urlList array exactly.
• →URL-encoded characters that change the apparent host. Malformed URL encoding can produce a URL that appears to be from a different domain when parsed.

Fix Sequence for 422

1. Identify which specific URLs are triggering the 422. The IndexNow History tab in your plugin will show you.
2. Check whether those URLs come from a different subdomain than your key is registered for.
3. For subdomain mismatches: create a separate key file at the subdomain’s root and configure each subdomain independently.
4. For protocol mismatches: ensure all submitted URLs use https://. If your site has mixed content or redirects, fix canonical URLs first.
5. For bulk POST submissions: verify the host field exactly matches the domain (no https:// prefix — just yourdomain.com).

The official IndexNow specification allows up to 10,000 URLs in a single bulk POST request. What isn’t in the documentation is that the rate limit is applied per IP address, not per domain or API key.

On a VPS or dedicated server, this distinction doesn’t matter much — you’re the only one using that IP. On shared hosting, you share an IP with potentially dozens of other websites. If those sites also use IndexNow (or any of the SEO plugins that enable it by default), their submissions count against the same rate limit you’re hitting.

Why Auto-Submit Modes Cause 429 at Scale

Most WordPress IndexNow plugins offer an “auto-submit on publish/update” mode. This sounds ideal, and for small sites with occasional publishing cadences, it is. For sites that update frequently — news, e-commerce product feeds, sites that modify metadata in bulk — this mode generates a burst of sequential API calls that triggers rate limiting almost immediately.

The pattern that creates the worst 429 problems: a site runs a bulk SEO title update across 800 posts. The plugin treats every post save as a new publish event. 800 API calls fire within 60 seconds. 429 fires on roughly request number 50, and then every remaining submission is dropped. You’ve now missed 750 URL notifications, but the plugin UI shows the jobs as “completed.”

Fix Sequence for 429

1. Stop automatic submissions immediately. Disable auto-submit in your plugin settings (Rank Math: Settings → Auto-Submit Post Types → deselect all).
2. Check the Retry-After header in the 429 response — it tells you exactly how many seconds to wait before resubmitting. Most implementations ignore this header entirely.
3. Wait the specified interval before any new submissions. On shared hosting, this might be several hours if other sites have also hit the limit.
4. Implement a submission queue instead of immediate auto-submit: buffer changed URLs and submit in batches 2–4 times per day using the bulk POST endpoint (up to 10,000 per batch).
5. If 429 persists despite low submission volume: contact your host and ask whether other sites on your shared IP are hitting IndexNow rate limits. This is a legitimate hosting complaint, not a configuration problem on your side.
6. For sites that generate high volumes of URL changes legitimately (news, e-commerce): consider moving to a VPS or dedicated environment where your IP is isolated.