101 Switching Protocols means the server accepts the client's Upgrade request header. Right after the empty line that ends the 101 response, both sides speak a different protocol on this connection. The response must contain an Upgrade header naming the new protocol.
Today this is almost always the WebSocket handshake. The browser sends a GET with Upgrade: websocket, Connection: Upgrade and a Sec-WebSocket-Key. The server answers 101 with the matching Sec-WebSocket-Accept, and from then on both sides exchange WebSocket frames. 101 was also used for the h2c upgrade from cleartext HTTP/1.1 to HTTP/2, which is now deprecated. Browsers negotiate HTTP/2 and HTTP/3 during the TLS handshake (ALPN) instead.
The Upgrade mechanism exists only in HTTP/1.1. HTTP/2 and HTTP/3 never send 101; WebSockets over those protocols use extended CONNECT (RFC 8441 and RFC 9220).
Example response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=SEO and redirect checking
A 101 is never the result of an ordinary page request. Browsers and crawlers only receive it when they explicitly ask to upgrade the connection, so it has no effect on indexing. A redirect checker sends plain GET, HEAD or POST requests and will not see 101. If a WebSocket endpoint is checked like a normal URL, it usually answers with a 4xx code such as 426 Upgrade Required or 400 Bad Request.
Common causes and use cases
- A browser opens a WebSocket (
new WebSocket('wss://...')) and the server accepts the handshake. - A client requests the deprecated
h2cupgrade to cleartext HTTP/2 and the server supports it. - WebSockets fail behind a reverse proxy because the proxy does not forward the
UpgradeandConnectionheaders. In nginx, setproxy_http_version 1.1and pass both headers to the backend.