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/

← 技術ドキュメント一覧へ戻る