HTTP 426 Upgrade Required
HTTP 426 Upgrade Required (RFC 9110) is returned when a server refuses to process a request on the current protocol and requires the client to upgrade. The response must include an Upgrade header naming the required protocol and a Connection: Upgrade header. A common use is insisting clients move to a newer protocol or to TLS before the request can proceed.
What this means
426 Upgrade Required, defined in RFC 9110, lets a server tell a client that the current protocol is unacceptable for the request and that it must upgrade to one the server specifies. The response is required to carry an Upgrade header listing the acceptable protocol(s) and a Connection header indicating the upgrade.
The HTTP Upgrade mechanism is how a connection switches protocols mid-stream — for example to WebSocket, or historically to a different HTTP version. A 426 is the server's way of insisting on that switch before it will respond with the resource.
Common causes and fixes
Servers may issue 426 to require a more capable protocol for an endpoint, such as demanding WebSocket for a real-time path, or to enforce a security policy. A client that does not understand or perform the named upgrade simply cannot use the endpoint.
For crawl diagnostics, a 426 on a content URL is unusual: most search and AI crawlers fetch plain HTTP/HTTPS and will not perform arbitrary protocol upgrades, so they will treat the resource as unavailable. If you want such a URL crawled, serve it over a protocol crawlers already use rather than requiring an upgrade.
- Server requires a protocol upgrade before responding
- Response must include Upgrade and Connection headers
- Crawlers that cannot upgrade treat the URL as unavailable
How it appears in analytics and logs
A 426 means the server will only serve the request over a different protocol it names in the Upgrade header. It indicates a protocol-policy mismatch, not a missing or broken resource.
Diagnostic use case
Diagnose why a client request is rejected with 426: the server demands a protocol upgrade (named in the Upgrade header) the client did not perform.
What WebmasterID can help detect
WebmasterID records the status returned to crawler fetches, so 426s reveal endpoints that demand a protocol upgrade some clients or crawlers may not perform, separate from human analytics.
Common mistakes
- Returning 426 without the required Upgrade header naming the protocol.
- Requiring a protocol upgrade on content URLs you want crawlers to index.
- Confusing 426 with 301-to-HTTPS — 426 is a protocol upgrade, not a redirect.
Privacy and accuracy notes
A 426 is a protocol-negotiation response with no visitor identity attached. WebmasterID records crawler fetch statuses without linking them to a person.
Related pages
- HTTP 425 Too Early
HTTP 425 Too Early comes from RFC 8470, which governs using early data in HTTP. TLS 1.3 0-RTT early data lets a client send request data before the handshake completes, but such data can be replayed by an attacker. A server returns 425 to indicate it is unwilling to process a request that arrived in early data and asks the client to retry once the handshake is complete.
- HTTP vs HTTPS canonicalization
https://example.com and http://example.com are different URLs, so serving content on both creates duplication and mixed signals. The standard fix is to force HTTPS: 301-redirect HTTP to HTTPS, reference only HTTPS in links, sitemaps, and canonicals, and use HSTS so clients default to the secure scheme.
- HTTP status code cheat sheet for crawlers
This cheat sheet maps the five HTTP status classes to what they mean for crawlers and indexing. It is a quick reference for reading server logs and Search Console crawl data: which codes index normally, which redirect, which signal client errors, and which are server failures crawlers will retry. The aim is to interpret status codes through a crawl-and-index lens rather than a generic one.
- Website observability
Spot endpoints that demand a protocol upgrade and return 426 to crawlers.
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.