202 Accepted: received now, processed later

202 Accepted means the server has received the request and queued it, but hasn’t finished the work, and may never complete it. It’s the standard response for asynchronous jobs: “got it, check back later.”

Definition

RFC 9110, section 15.3.3 calls 202 “intentionally noncommittal.” The request has been accepted for processing, the outcome is unknown, and HTTP has no built-in way to report back later. So the response should describe the current state and, ideally, link to a status resource the client can poll:

HTTP/1.1 202 Accepted
Location: /api/v1/jobs/7731
Content-Type: application/json

{"job":7731,"state":"queued","status_url":"/api/v1/jobs/7731"}

Where you’ll see it

• Batch work: exports, imports, video encoding, bulk email sends.
• Webhooks and event APIs that acknowledge receipt at once and process later.
• IndexNow: a 202 means the URLs were received but the key is still being validated; once your key file is confirmed, submissions normally get 200.
• Long-running requests behind proxies: instead of timing out with 504 or Cloudflare’s 524, return 202 and finish the job in the background.

SEO impact

Google’s documentation treats 202 like 201: Googlebot waits for content for a limited time, then passes on whatever it received. A public page that answers 202 with a “processing…” placeholder risks being indexed as that placeholder or flagged as a soft 404. Some bot-protection layers also answer suspicious clients with a 202 and a challenge page instead of the content; if that catches crawlers, your real pages never reach the index. Public pages should return 200 with the full content.

How to check

Paste URLs into the HTTP status checker to make sure your pages return 200, not 202. For IndexNow, the IndexNow submitter lets you verify that your key file is reachable on your site, which is what IndexNow validates, before you submit URLs.

Frequently asked questions