HTTPステータスコード：すべてのレスポンスコードを解説

HTTPレスポンスはすべて3桁の数字から始まります。この数字は、あなたのリクエストに何が起きたのかを、サーバーが可能なかぎり短く伝えたものです。普段はまず目にしません。ページが読み込まれ、ブラウザは次へ進むだけです。この数字が見えてくるのは何かがうまくいかなかったときだけ、つまり、その意味を知る必要がある、まさにそのときです。

とはいえステータスコードは診断情報にとどまらず、指示でもあります。301は検索エンジンにインデックスの項目を恒久的に移すよう伝え、429はクライアントにどう速度を落とすかを正確に示し、503はクローラーにページを落とす代わりに後で来るよう伝えます。誤ったコードを返すことは、トラフィックを失う最も静かな方法の一つです。見た目には何も壊れないからです。本ガイドでは各クラス、実務で本当に出会うコード、そしてURLが実際に何を返しているかを確認する方法を見ていきます。

ステータスコードが重要な理由

あなたのステータスコードを読む相手は4種類あり、それぞれ違う行動をとります。

• ブラウザ。リダイレクトに従うか、キャッシュのコピーを再利用するか、フォームの本文を再送するかを判断します。
• 検索エンジン。コードによって、URLがインデックスされるか、別のURLに統合されるか、後で再試行されるか、捨てられるかが決まります。丁寧な「見つかりません」ページを200で返すのが典型的な失敗です。クローラーはページが存在すると伝えられ、インデックスに残し続けます。
• APIクライアント。よく書かれたクライアントはコードで分岐します。429や503は再試行の価値がありますが、400は決してそうではありません。不正なリクエストを再送しても同じエラーになるだけです。
• 自分自身の監視。エラー率やアラートはほぼ必ずステータスコードの上に構築されるため、エラーを本文に入れて200を返すサービスは、自分のダッシュボードから見えなくなります。

5つのクラス

最初の桁は、責任がどちらにあり次に何をすべきかを示します。他に何も覚えられないとしても、この表だけは覚えてください。

実務でもっとも重要なのは4xxと5xxの区別です。障害対応で唯一意味のある問い、つまり「これは自分が直すのか、相手が直すのか」に答えてくれるからです。

実務で本当に出会うコード

登録されたコードは数十ありますが、一日の仕事で関わるのは十五ほどです。成功系はもっとも単純です。200 OKは普通の応答。201 Createdは何かを作成したPOSTへの正しい応答で、新しいリソースを指すLocationヘッダーを添えるべきです。204 No Contentはリクエストが成功し、意図的に返すものがないことを示し、DELETEへの正しい答えになります。206 Partial Contentは、動画のシークや再開可能なダウンロードを成立させているコードです。

リダイレクト：301、302、307、308

リダイレクトは他のどのクラスよりもSEOに害を与えます。原因はほぼ常に、恒久的な形と一時的な形が入れ替わっていることです。

• 301 Moved Permanently：URLが恒久的に変わった。検索エンジンは評価のシグナルを新しいアドレスへ移し、やがてインデックス内の旧URLを置き換えます。ドメイン移行、HTTPからHTTPSへの移行、wwwの追加や削除で使います。
• 302 Found：一時的。戻ってくると宣言したことになるため、旧URLはインデックスに残ります。A/Bテスト、短いメンテナンス時間、後で戻す予定の地域別ルーティングで使います。
• 307 Temporary Redirect：302と同様ですが、メソッドと本文の保持が保証されます。307でリダイレクトされたPOSTはPOSTとして届きます。かつては一部のクライアントがリダイレクトされたPOSTをGETに変えていました。
• 308 Permanent Redirect：307の恒久版です。キャッシュの扱いは301と同じで、メソッドは保持されます。
• 304 Not Modified：厳密にはリダイレクトではありません。条件付きリクエストへの応答で「キャッシュのコピーはまだ有効」という意味です。だからこそ、よく設定されたサイトはページ容量から想像されるよりはるかに少ないデータしか転送しません。

原則は二つ。1回で足りるところでリダイレクトを連鎖させないこと。各ホップは遅延とクロール予算を消費します。そして、存在しないページをすべてトップページへ送らないこと。後者は整然として見えますが、利用者にもクローラーにも事実と違うことを伝えてしまいます。

クライアントエラー：400、401、403、404、429

4xx系はリクエスト自体が問題だったことを示します。クライアントはそれぞれで異なる振る舞いをするため、区別を正しく使うことに意味があります。

• 400 Bad Request：構文が不正。壊れたJSON、必須項目の欠落、解釈できないパラメータなど。そのままでは再試行しても無意味です。
• 401 Unauthorized：名前が誤解を招きますが、意味は未認証です。資格情報がない、またはサーバーが検証できなかった場合に使い、WWW-Authenticateヘッダーを含めるべきです。
• 403 Forbidden：サーバーはあなたが誰かを知っていて、それでも許可しません。再認証しても解決しません。
• 404 Not Found：このURLには何も存在しません。かつて存在したかどうかには触れません。
• 405 Method Not Allowed：URLは存在しますが、このメソッドでは使えません。使えるメソッドを並べたAllowヘッダーを添えます。
• 409 Conflict：リクエストが現在の状態と衝突しています。キーの重複や古いバージョンなどです。
• 410 Gone：リソースは存在したが意図的に削除されました。検索エンジンは404より410を早く手放すため、意図して公開を終えた場合はこちらが適切です。
• 422 Unprocessable Content：構文は解析できたが、値が検証に通りません。「読めない」と「読んだが内容が誤っている」を分けたいときに有用です。
• 429 Too Many Requests：レート制限を超えました。必ずRetry-Afterヘッダーを添えてください。無いとクライアントは即座に再試行し、過負荷を悪化させます。

サーバーエラー：500、502、503、504

5xxは、リクエストは妥当だったのにサーバーが失敗したという意味です。よく使われる4つは別々の層を指しており、障害対応で実際に役立ちます。

• 500 Internal Server Error：アプリケーション内の未処理の例外。汎用の受け皿であり、まずログを探すべき対象です。
• 502 Bad Gateway：プロキシやロードバランサーが上流から不正または空の応答を受け取った状態。多くはプロキシの背後のアプリが落ちている、または待ち受けていません。
• 503 Service Unavailable：サーバーが過負荷か、メンテナンス中です。この系統で唯一意図的に返すべきコードで、計画停止の際はRetry-Afterヘッダーとともに返します。クローラーはページを保持して戻ってきます。
• 504 Gateway Timeout：プロキシが上流を待ったうえで諦めた状態。クラッシュではなく、遅い依存先を指しています。

障害の最中、502と504の違いは、アプリが死んだのか単に遅くなったのかを教えてくれます。多くの場合、これがもっとも早く得られる手がかりです。

ステータスコードとSEO

検索エンジンはステータスコードをURLに関する最終的な宣言として扱い、ページ本文の内容より信頼します。そこから4つの帰結が生まれます。

1. ソフト404はクロール予算を浪費する。「ページが見つかりません」というメッセージを200で返すと、死んだURLがインデックスに残り、本物のページと競合します。本物の404または410を返してください。
2. 恒久的な移動には301を使う。本当の移動に302を使うと旧URLがインデックスに残り、シグナルが2つのアドレスに分散します。
3. リダイレクトの連鎖は短く保つ。ホップごとに遅延が増え、クローラーは限られた回数しか追いません。旧URLは最終的な宛先へ直接向けます。
4. メンテナンス中は503を返す。 Retry-After付きの503はクローラーに再訪を促します。タイムアウトや500は壊れたサイトに見えます。

リダイレクトはHTTPSとも関係します。http://からhttps://へのリダイレクトを設定していても証明書が無効または期限切れなら、リダイレクトが効く前に訪問者はブラウザの警告を見ます。SSL証明書チェッカーで証明書も同時に確認しておくとよいでしょう。

ステータスコードの確認方法

読み込みが成功するとブラウザはコードを隠すため、明示的に尋ねる必要があります。確実な方法は3つです。

1. ブラウザのネットワークパネル。開発者ツールを開いて再読み込みし、ステータス列を見ます。単なる数字では分からないリダイレクトの連鎖全体が見えます。
2. curl -I https://example.com。 HEADリクエストは本文を取得せずにステータス行とヘッダーを表示します。-Lを加えるとリダイレクトを追い、各ホップを確認できます。
3. 検索できるリファレンス。数字が分かっていて、意味・果たすべき義務・典型的な原因が必要なときは、HTTPステータスコードのリファレンスが各コードと対処法を一覧にしています。

数字以外に確認すべきことが2つあります。1つは、利用者が実際にアクセスするURLそのものを、末尾のスラッシュを含めて試すこと。両者はしばしば別に解決されます。もう1つは、応答が429ならRetry-Afterの値を読み、クライアントの待機処理が本当にそれを守っているか確かめることです。レート制限計算ツールは制限値を具体的な間隔に変換します。

よくある間違い

• 本文にエラーを入れて200を返す。監視、キャッシュ、クローラー、クライアントはいずれもコードを読み、あなたのJSONは読みません。この一覧で最も影響の大きい間違いです。
• 恒久的な移動に302を使う。評価のシグナルは旧URLに残り、時には数か月そのままです。
• すべての404をトップページへ飛ばす。壊れたリンクが自分から見えなくなり、クローラーにはソフト404を生みます。
• 401を使うべき場面での403。 403を受け取ったクライアントは認証を試みません。403は認証が問題ではないと言っているからです。
• Retry-Afterのない429。クライアントは推測するしかなく、普通は「すぐに」と推測します。これはまさに制限が防ぐべき振る舞いです。
• メンテナンスでタイムアウトを返す。インデックスの項目を保つため、Retry-After付きの503を返してください。
• 移行後に長いリダイレクト連鎖を残す。移行ごとにホップが増えます。次にルールを触るときに1つへまとめましょう。

自分のステータスコードを確認する

ステータスコードはウェブで最も安価な診断手段です。数字が1つ、認証は不要、そしてURLが動いているのか、移動したのか、失敗したのかについて曖昧さのない答えが得られます。まず重要なページが何を返しているかを確認し、リダイレクトが恒久的であるべき場所で恒久的に、一時的であるべき場所で一時的になっていることを確かめ、どのエラー経路も実際に起きたことに合うコードを返すようにしてください。

関連ツールとガイド：

• HTTPステータスコード — すべてのレスポンスコードを検索できるリファレンス。
• レート制限計算ツール — 制限値を安全な間隔とRetry-Afterに変換。
• DNSルックアップ — 応答のデバッグ前にドメインが解決するか確認。
• SSL証明書チェッカー — HTTPSリダイレクトの先にある証明書を検証。
• 301と302リダイレクト：使い分けとSEOへの影響 - どちらのリダイレクトを使うべきか、それぞれが検索順位に与える影響。
• 404と410：削除したページについてGoogleに何を伝えるか - 削除したページについて、各コードが Google に何を伝えるか。

よくある質問