HTTP 402 Payment Required
HTTP 402 Payment Required is defined by RFC 9110 as reserved for future use, with no standardised semantics across the web. Some payment platforms and APIs repurpose it to signal that a request cannot proceed until payment is made, but there is no interoperable contract behind it. For crawlers it is a 4xx client error, so a page behind a 402 is generally not indexed.
What 402 means
RFC 9110 lists 402 Payment Required as reserved for future use; it has never been given a single agreed meaning for the open web. In the absence of a standard, individual platforms have adopted it for billing and metering — for example, an API responding 402 when an account is out of credit, or a service indicating a paid tier is required.
Because those meanings are platform-specific, you cannot assume any two services use 402 the same way. Always read the responding system's documentation rather than inferring intent from the code alone.
Why it matters for crawling
A 402 is in the 4xx client-error range, so search crawlers treat it as a failed request and will generally not index the URL. If public content sits behind a billing gate that returns 402, it disappears from search just like a 403 would.
If you intend content to be both paywalled and discoverable, the common pattern is structured data for paywalled content plus a normal 200 for the snippet a crawler is allowed to see — not a blanket 402. Use 402 only inside controlled API contexts where the client understands it.
- 402 is a 4xx error: crawlers will not index the URL
- No standard meaning — read the platform's own docs
- For discoverable paywalls, use 200 plus paywall structured data
How it appears in analytics and logs
A 402 returned to a crawler means the server treated the request as needing payment. Because it is a client error, the URL will typically not be indexed. Seeing it on public content usually points to a misconfigured paywall or billing gate.
Diagnostic use case
Recognise 402 in API or paywall logs as a non-standard, platform-specific signal, and avoid relying on it for content you want indexed.
What WebmasterID can help detect
WebmasterID can surface 4xx codes crawlers receive, helping you catch pages unexpectedly returning 402 where you intended them to be publicly crawlable.
Common mistakes
- Assuming 402 has a universal meaning — it is reserved and platform-defined.
- Returning 402 on public pages you want indexed, hiding them from search.
- Treating a 402 from one API the same as 402 from another.
Privacy and accuracy notes
A 402 is a request-level status with no personal data. WebmasterID records the status a crawler received and never links it to a visitor's payment or identity details.
Frequently asked questions
- Is 402 a standard payment status?
- No. RFC 9110 reserves 402 for future use without standard semantics. Payment platforms repurpose it, but the meaning is specific to each service, so check that service's documentation.
Related pages
- HTTP 403 Forbidden and blocked crawlers
403 Forbidden means the server understood the request but refuses to authorize it, and authenticating will not help. For crawlers, a 403 often signals over-blocking — a WAF, bot-management rule, or IP filter rejecting legitimate crawlers and quietly removing pages from being indexed.
- HTTP 401 Unauthorized and crawling
401 Unauthorized means the request lacks valid authentication credentials for the resource. Crawlers do not log in, so a page behind a 401 cannot be fetched or indexed. Seeing 401s for content you intended to be public usually means an auth layer is misconfigured or applied too broadly.
- HTTP 407 Proxy Authentication Required
HTTP 407 Proxy Authentication Required is like 401, but the authentication is demanded by a proxy between the client and the server rather than by the origin. The proxy returns a Proxy-Authenticate header describing the challenge, and the client must resend with Proxy-Authorization. It almost never originates from your own web server, so seeing it usually points at network or proxy configuration rather than your site.
- Website observability
Spot pages returning unexpected client errors to crawlers, recorded server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.