HTTPステータスコード総覧ガイド
401 vs 403を推測で済ませない—各ファミリーを実例とアンチパターンつきで解説し、SEOで本当に効くコードを整理します。
なぜ重要か
バックエンドが200 OKと返しボディが{"error": "Unauthorized"}。ステータスが200なのでフロントの汎用エラーハンドラは成功扱いになり、ログインフォームがループします。この程度のコード選定ミスは工数を食い、さらにSEOクロールやリンク切れレポートまで歪めます。いつどのコードを返すかは仕事の一部です。
実際の3つのシーン
トークンなし？401。トークンはあるが権限なし？403。リソースが存在しないだけ？404。
クライアント挙動が予測可能
301はPageRank継続。302は一時でありランク移転のシグナルではない。意図して選ぶ。
恒久的301でランキング移転
Retry-Afterヘッダ付き503はクローラーに「また来い」と伝え、インデックス削除より再訪問を促します。
検索エンジンが再試行
5つのファミリー早見表
| 範囲 | ファミリー | よく見るコード |
|---|---|---|
| 1xx | Informational（情報） | 100 Continue、101 Switching Protocols |
| 2xx | Success（成功） | 200 OK、201 Created、204 No Content |
| 3xx | Redirection（リダイレクト） | 301、302、304 Not Modified、308 |
| 4xx | Client Error（クライアント側エラー） | 400、401、403、404、422、429 |
| 5xx | Server Error（サーバー側エラー） | 500、502、503、504 |
手順 — ステータスリファレンスの使い方
HTTPステータスリファレンスを開きます。
コードまたは説明で検索
「401」「unauthorized」「rate limit」のように入力。マッチしたコードが上へ浮きます。
正準の意味を読む
各項目はcurlの出力だけでなく仕様上の意味を説明します。
現場での用法を確認
注記ではGitHub、Stripe、AWSなど人気APIの微妙な逸脱も触れています。
SEO影響を把握
各コードに検索エンジン扱い（インデックス可／不可、順位継承の有無）のタグがあります。
一文をコピー
APIドキュメントやコードコメントにそのまま落とします。
シナリオ
POST /admin/users
(No Authorization header)推奨レスポンス
401 Unauthorized
WWW-Authenticate: Bearer realm="admin"シナリオ
POST /admin/users
Authorization: Bearer eyJ... (valid token, viewer scope)推奨レスポンス
403 Forbidden
{"error": "scope_admin_required"}
実践テクノ
- 論理的には正しいが意味的に無効な入力には422（例：フィールド型が合わないJSON）。400は形式不良です。
- DELETEは204 No Contentの方が、空ボディの200より丁寧—意図的にペイロード無しですと伝わります。
- **429 と 503 には必ず
Retry-After。**賢いクライアントに再試行タイミングを明示します。 - ボディに
errorを載せつつ全部200は避ける。ステータスの目的を潰し、モニタリングも混乱します。
よくある落とし穴
よくある誤り
アクセス権の問題なのに404を返す
曖昧な404は「存在しない」ことを隠します—それが狙いならあり（プライベートリポなど）ですが、通常の認証APIなら403の方が認証・権限が問題だと伝わります。
よくある誤り
302を恒久キャッシュさせる
302は仕様上一時ですが中間キャッシュが強く効くことがあります。**恒久なら301（メソッド維持なら308）**へ。
よくある誤り
クライアントのミスに500を返す
500はサーバーエラーです。入力が悪いなら4xx。相手側のミスなのに自前のバグアラートが鳴るのを防ぎます。
向いていない用途
- 新規プロトコル設計—HTTPステータスはHTTP意味論にひも付き、gRPCやWebSocketsは別の状態表現があります。
- アプリ内エラー詳細—HTTPコードに加えボディにアプリケーション固有コードを載せます。
- 運用監視—APMは自動分類が役割。ここでのリファレンスは実装前の設計判断向きです。
FAQ
301 と 308 の違いは？
どちらも恒久的リダイレクト。308はHTTPメソッド維持を保証しますが、歴史的に301ではクライアントがPOST→GETへ切り替えることが許容されていました。
418 I'm a teapot は本物？
はい。RFC 2324（1998年エイプリルフール）、RFC 7168で再確認。ジョーク応答であり本番APIでは使いません。
419や440などフレームワーク固有コードを出すべき？
避けられるなら標準以外は出さず、IANA登録セットに寄せると汎用クライアントが理解しやすいです。
次のステップ
- 挙動のデバッグにはURLパーサーでレスポンス周りも確認します。
- トリアージで叩くGitやLinuxコマンドはGitコマンドとLinuxコマンドリファレンスへ。
- 502／504など上流問題のときはIPルックアップツールでサーバ側IP/ASNを確認します。