HOME > 技術ドキュメント > HTTPステータスコード実務ガイド
HTTPステータスコード実務ガイド（200・301・302・404・410・5xx）
執筆：株式会社エスロジカル（Webシステム受託開発・インフラ構築・運用改善）
HTTPステータスコードは、リンク切れ調査・リダイレクト設計・障害切り分け・SEO 改善の共通言語です。
意味を取り違えると、404 にすべき場所を 200 で返してしまったり、301 にすべき場所を 302 にしてしまって SEO 評価を取り損ねたりします。
本記事では実務で頻出するコードに絞って、意味・使い分け・誤用例を整理します。
1. ステータスコードの 5 分類
| 分類 | 意味 | 主な実例 |
|---|---|---|
| 1xx | 情報（処理継続） | 100 Continue / 101 Switching Protocols（WebSocket） |
| 2xx | 成功 | 200 OK / 204 No Content / 206 Partial Content |
| 3xx | リダイレクト | 301 Moved Permanently / 302 Found / 304 Not Modified / 307 / 308 |
| 4xx | クライアントエラー | 401 / 403 / 404 / 410 / 429 |
| 5xx | サーバーエラー | 500 / 502 / 503 / 504 |
2. 2xx — 200 / 204 / 206 の使い分け
- 200 OK：レスポンスボディがある通常の成功。Web ページの典型。
- 204 No Content：処理は成功したがボディは無い。フォーム送信後の Ajax レスポンスや、PUT/DELETE の成功通知でよく使う。
- 206 Partial Content：Range ヘッダーによる部分取得への応答。動画・大きなファイルのダウンロード再開に使われる。
誤用が多い例：削除済みページに対して「ごめんなさい、この記事は削除されました」というメッセージを表示しつつ 200 を返してしまうパターン。 これは「ソフト 404」と呼ばれ、検索エンジンに削除されたことが伝わらないため、SEO 評価とクロールバジェットを浪費します。404 または 410 を返すのが原則です。
3. 3xx — 301 / 302 / 303 / 307 / 308 の違い
| コード | 名称 | 永続性 | メソッド変換 | 典型用途 |
|---|---|---|---|---|
| 301 | Moved Permanently | 永続 | 多くは GET に変換 | URL の恒久的な変更・HTTPS 化 |
| 302 | Found | 一時 | 多くは GET に変換 | ログイン後の一時遷移など |
| 303 | See Other | 一時 | GET に変換 | POST → GET の PRG パターン |
| 304 | Not Modified | ― | 変換しない | If-Modified-Since・ETag によるキャッシュ応答 |
| 307 | Temporary Redirect | 一時 | 維持 | POST のまま別 URL へ転送したいとき |
| 308 | Permanent Redirect | 永続 | 維持 | API の URL 恒久変更（メソッドを維持したい） |
SEO 観点：恒久的な変更は必ず 301（または 308）で返す。302 のままだと検索エンジンは「いずれ元 URL に戻る」と判断する可能性があり、ランクが新 URL に集約されません。 詳しい設計は 301/302 リダイレクト設計のベストプラクティス を参照してください。
4. 4xx — 「Not Found」と「Gone」の使い分け
| コード | 名称 | 使う場面 |
|---|---|---|
| 400 | Bad Request | リクエストの構文・必須パラメータ不正 |
| 401 | Unauthorized | 未認証（ログインしていない）。実態は「Unauthenticated」 |
| 403 | Forbidden | 認証済みだが権限が無い |
| 404 | Not Found | リソースが見つからない（一時的・恒久的の区別なし） |
| 410 | Gone | 恒久的に削除した（「もう戻ってきません」と明示） |
| 429 | Too Many Requests | レート制限超過。Retry-After ヘッダー併用が望ましい |
404 vs 410：「いずれ復活するかも」「URL を間違えただけかも」というニュアンスなら 404、「この記事はサービス終了で完全に削除した」「商品の取り扱いを終了した」など意図的な削除は 410 を選びます。 410 は検索エンジンに「この URL は二度と存在しません」と伝わり、インデックス除外が速いという実務メリットがあります。
5. 5xx — 切り分けの定石
| コード | 名称 | 原因と最初に見るべき場所 |
|---|---|---|
| 500 | Internal Server Error | アプリ側の未捕捉例外。アプリログ → スタックトレースを確認 |
| 502 | Bad Gateway | 上流（PHP-FPM・アプリプロセス）が落ちている or レスポンスが壊れている。systemctl status・nginx error.log の upstream エラーを確認 |
| 503 | Service Unavailable | 意図的な停止（メンテ）または過負荷。スケーリング・接続数上限を確認 |
| 504 | Gateway Timeout | 上流の応答が遅すぎる。DB スロークエリ・外部 API の遅延・タイムアウト値を確認 |
nginx → PHP-FPM 構成の典型障害：502 が頻発する場合は PHP-FPM のプロセス数上限（pm.max_children）に達している可能性が高い。
アクセスログ・error.log・ログ設計記事もあわせて参照してください。
6. リンク切れ検出ツールが見ているステータス
外部・内部の自動巡回ツールは、概ね次のようにステータスを扱います。
- 200・3xx（追跡後 200）：OK と判定。
- 301/308（追跡後 200）：リンクは生きているが、リンク元の URL を最終 URL に張り替えることを推奨。
- 404・410：リンク切れと判定。410 のほうが「意図的削除」のシグナルとして強い。
- 5xx・タイムアウト：一時障害かもしれないため、複数回リトライしてから判定するのが定石。
- 429：巡回側がリクエストを送りすぎ。間隔・同時実行数を下げる。
弊社運営の リンク切れチェック（dead-link-checker.com） は、これらのステータスを区別して結果に表示します。 実際の運用フロー設計は Webサイトのリンク切れ調査と運用フロー入門 を参照してください。
確認用 curl コマンド早見表
|
# ステータスコードだけ取得 curl -o /dev/null -s -w "%{http_code}\n" https://example.com/ # ヘッダー表示（HEAD） curl -I https://example.com/ # リダイレクト追跡（チェーン全体の表示） curl -ILs https://example.com/ # 応答時間も表示 curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com/ |
dead-link-checker.com は、4xx/5xx・タイムアウトを自動巡回検知する SaaS サービスです。
関連：リンク切れ調査と運用フロー入門 / 301/302 リダイレクト設計のベストプラクティス / SSL証明書