技術(非IT系)

ステータスコードとは?意味や仕組みは?(HTTP:レスポンス:リクエスト:分類:一覧など)

ステータスコードの意味と基本構造
当サイトでは記事内に広告を含みます

Webサイトを閲覧したとき、画面の裏側ではブラウザとサーバーがHTTPを使って情報をやり取りしています。

その通信が成功したのか、転送先が変わったのか、あるいは問題が発生したのかを数字で知らせる仕組みがステータスコードです。

SEO対策、サイト運営、Web制作、API開発では、HTTPステータスコードの意味を正しく理解することが欠かせません。

この記事では代表的な分類や一覧、レスポンスとリクエストの関係、確認方法、トラブル時の考え方まで詳しく紹介します。

ステータスコードの意味と基本構造

ステータスコードの意味と基本構造

それではまずステータスコードの意味と基本構造について解説していきます。

HTTP通信における役割

ステータスコードとは、HTTPリクエストに対してWebサーバーが返す処理結果を、原則として3桁の数字で表したものです。

ユーザーがURLを開く、検索エンジンのクローラーがページを巡回する、アプリがAPIへデータを送るといった操作では、最初にリクエストが送信されます。

サーバーは受け取った内容を処理し、HTML、画像、JSONなどのデータとともにHTTPレスポンスを返します。

このレスポンスの先頭部分に含まれる数値がステータスコードです。

たとえば200は正常に処理されたこと、404は対象ページが見つからないこと、500はサーバー内部でエラーが起きたことを示します。

表示される画面だけでは原因を判断できない場面でも、ステータスコードを確認すると通信上の状態を整理しやすくなります。

リクエストとレスポンスの流れ

HTTP通信は、要求を送る側と結果を返す側のやり取りで成り立っています。

ブラウザや検索エンジン、外部サービスなどがクライアントとなり、Webサーバーへリクエストを送ります。

リクエストには、取得したいページのURL、利用するHTTPメソッド、Cookie、言語設定などが含まれる場合があります。

サーバーはリクエストを確認して処理を実行し、レスポンスヘッダーと本文を返します。

ステータスコードはレスポンスヘッダーに含まれる情報であり、コンテンツ本文そのものではありません。

通信の流れは、ブラウザがページを要求し、サーバーが処理結果を返し、その結果をステータスコードで伝えるという順序です。

ページが存在していても権限不足なら403、別URLへ移動していれば301や302など、状況ごとに返される数字が変わります。

数字の先頭が示す分類

3桁のうち最初の数字は、レスポンスの大まかな種類を表します。

1から5までの分類を把握しておけば、初めて見るコードでも問題の方向性を推測できるでしょう。

分類 主な意味 代表例
1xx 処理継続中の情報 100 Continue
2xx リクエストの成功 200 OK
3xx リダイレクトなどの追加処理 301 Moved Permanently
4xx リクエスト側に関係するエラー 404 Not Found
5xx サーバー側に関係するエラー 500 Internal Server Error

ただし、4xxは必ず利用者だけのミス、5xxは必ずサーバー管理者だけの責任という単純な分類ではありません。

設定変更、アクセス制限、プログラム連携など、発生条件を確認することが重要です。

HTTPステータスコードの分類一覧

続いてはHTTPステータスコードの分類一覧を確認していきます。

成功を表す二百番台

2xxは、サーバーがリクエストを受け取り、基本的に問題なく処理できた状態を示します。

もっとも有名なのは200 OKで、ページ表示や通常のデータ取得が成功したときに返されます。

201 Createdは新しいデータやリソースが作成された場合によく使われ、フォーム送信やAPIでの登録処理に見られます。

204 No Contentは処理自体は成功したものの、返す本文がない場合のコードです。

たとえば削除処理が完了し、画面側で追加のデータを受け取る必要がないケースが該当します。

SEOで通常期待されるページの応答は200であり、意図せず別のコードになっていないか定期的に確認したいところです。

転送を表す三百番台

3xxは、リダイレクトやキャッシュ利用など、クライアントに追加の対応を求めるレスポンスです。

サイト移転やURL変更では301 Moved Permanentlyがよく利用されます。

301は恒久的な移動を示すため、旧URLの評価やシグナルを新URLへ引き継ぐ施策として重要です。

一時的な移動には302 Found、または用途によって307 Temporary Redirectが使われます。

リダイレクト先がさらに別のURLへ転送される状態はリダイレクトチェーンと呼ばれ、表示速度やクローラーの巡回に影響する可能性があります。

URLを恒久的に変更した場合は、旧ページから新ページへ301リダイレクトを設定し、内部リンク、サイトマップ、canonicalタグも新URLに合わせて更新することが大切です。

エラーを表す四百番台と五百番台

4xxは、URLの誤り、権限不足、認証不足、アクセス制限など、リクエストに関係する問題を表します。

404 Not Foundはページが存在しない場合に返される代表的なエラーです。

401 Unauthorizedは認証が必要な状態、403 Forbiddenはアクセスが禁止されている状態を示します。

一方の5xxは、Webサーバー、プログラム、データベース、外部APIなど、サーバー側で処理が完了できない場合に返されます。

500 Internal Server Errorは原因を特定できない内部エラー、502 Bad Gatewayは上流サーバーから不正な応答を受けた状態、503 Service Unavailableは一時的にサービスを利用できない状態です。

表示不良が起きたときは、4xxか5xxかを最初に切り分けるだけでも、確認すべき範囲を絞り込めます。

代表的なステータスコードの用途

続いては代表的なステータスコードの用途を確認していきます。

二百と二百一の使い分け

200 OKは、ページの閲覧、検索結果の取得、既存データの更新など、一般的な成功レスポンスに適しています。

一方で201 Createdは、リクエストによって新規リソースが生成されたことを明確に伝えたい場合に便利です。

API設計では、ユーザー登録、注文作成、記事投稿などで201を返すと、呼び出し側が処理結果を理解しやすくなります。

成功しているからといってすべて200に統一するより、処理内容に合ったコードを返す設計のほうが保守性を高められるでしょう。

例として、商品一覧の取得成功は200、新商品の登録完了は201、削除成功で返却データが不要なら204という整理ができます。

三百一と三百二の判断

301は恒久的なURL変更、302は一時的な転送という違いがあります。

ドメイン移転、パーマリンク変更、統合により不要になったページの移動では301を検討します。

キャンペーン期間中だけ別ページへ案内する、ログイン前後で一時的に遷移先を変えるといったケースでは302が候補になります。

ただし、ブラウザや検索エンジンは複数の情報を踏まえてページを判断します。

リダイレクトコードだけに頼らず、リンク先、ページ内容、canonicalタグ、サイトマップとの整合性も保つことが必要です。

転送設定はユーザー体験とSEOの両方に影響する技術要素として扱いましょう。

四百四と四百十の扱い

404 Not Foundは、指定されたリソースが見つからないことを示します。

URLの打ち間違い、公開終了した記事、リンク切れ、削除済みの画像などで発生します。

410 Goneは、対象リソースが意図的に削除され、今後も戻らない可能性が高いことを表すコードです。

代替となる内容がある場合は、関連性の高いURLへ301リダイレクトする方法が考えられます。

しかし、無関係なトップページへ大量に転送すると、利用者にとって分かりにくく、検索エンジンにも適切な対応と見なされない場合があります。

存在しないURLはすべて転送すればよいわけではありません。

代替ページがあるか、削除が恒久的か、外部リンクや検索流入が残っているかを確認して対応を選びます。

SEOにおけるレスポンスコードの重要性

続いてはSEOにおけるレスポンスコードの重要性を確認していきます。

クロールとインデックスへの影響

検索エンジンのクローラーはURLへアクセスし、HTTPレスポンスをもとにページの取得可否を判断します。

重要なページが200を返していれば、内容を取得して評価対象にしやすくなります。

404や410が継続して返るページは、通常は存在しないURLとして扱われます。

503は一時的な停止を示すため、メンテナンス中などに適切に使うことで、恒久的な削除とは異なる意図を伝えやすくなります。

ただし503が長期間続けば、サイト全体のクロールや検索流入に悪影響が出るおそれがあります。

インデックスさせたいページが意図どおり200を返すことは、SEOの土台といえるでしょう。

ソフト四百四の注意点

HTTP上は200を返しているのに、本文にはページが見つからないという案内だけが表示される状態は、ソフト404と呼ばれることがあります。

削除済み記事をトップページへ自動転送した場合や、検索結果がないページに極端に少ない内容しかない場合も、意図しない評価につながる可能性があります。

本当に存在しないページなら、適切な404または410を返すほうが状況を明確にできます。

独自の404ページを用意する場合は、サイト内検索、主要カテゴリ、問い合わせ先などを掲載すると、離脱を減らしやすくなります。

ただし、エラーであることを曖昧にせず、HTTPヘッダーでも404を返す設定が必要です。

内部リンクとサイト移行の管理

内部リンク切れは、利用者の回遊を妨げるだけでなく、クローラーが不要な404へ到達する原因にもなります。

記事の更新やカテゴリ変更、画像の差し替えを行った際は、リンク先URLも見直しましょう。

サイト移行では、旧URLと新URLの対応表を作成し、重要ページから順に301リダイレクトを設定する方法が有効です。

確認項目 確認する内容 主な目的
主要ページ 200が返るか インデックス対象の維持
旧URL 適切な新URLへ301か 移行後の評価と導線の継続
削除ページ 404または410か 存在しないページの明示
エラーページ 5xxが継続していないか サーバー障害の早期発見

URL変更の前後でステータスコードを確認する習慣が、移行トラブルの予防につながります。

ステータスコードの確認方法と対処

続いてはステータスコードの確認方法と対処を確認していきます。

ブラウザの開発者ツール

Google Chromeなどのブラウザでは、開発者ツールのネットワーク機能を利用してレスポンスコードを確認できます。

対象ページを開いた状態でネットワーク一覧を表示すると、HTML、CSS、JavaScript、画像、API通信など、それぞれのステータスが確認可能です。

画面は正常に見えても、一部の画像が404になっていたり、外部連携が500になっていたりする場合があります。

特定の操作でだけ問題が起こる場合は、該当する通信を選び、リクエストURL、レスポンスヘッダー、本文を確認すると原因に近づけます。

コマンドとオンライン診断

サーバー管理や開発に慣れている場合は、curlなどのコマンドでHTTPヘッダーを取得する方法があります。

curlのヘッダー取得機能を使うと、ページ本文を細かく確認しなくても、200、301、404、500などのレスポンスコードとLocationヘッダーを確認できます。

リダイレクトを追跡する設定を加えれば、最終到達URLや転送回数の確認にも役立ちます。

技術的な操作が難しい場合は、HTTPステータスコードを確認できるオンラインツールも選択肢になります。

ただし、認証が必要な管理画面や社内サイトは、外部ツールから確認できないことがあります。

公開サイトを診断するときも、個人情報を含むURLや非公開情報を不用意に送信しないよう注意が必要です。

エラー発生時の確認順序

404が出たときは、URLのスペル、リンク先、ファイルや投稿の公開状態、パーマリンク設定を確認します。

403なら、アクセス権限、Basic認証、WAF、robots.txt、サーバー設定などが候補になります。

500の場合は、サーバーのエラーログ、PHPなどのプログラムエラー、プラグインやテーマの競合、容量不足、データベース接続を確認する流れが一般的です。

502や504では、CDN、リバースプロキシ、外部API、上流サーバーとの接続状況も調べる必要があります。

エラー対応では、発生したURL、時刻、操作内容、返されたステータスコードを記録してください。

再現条件が分かると、制作会社やサーバー会社へ相談する際にも状況を正確に共有できます。

見た目だけで判断せず、通信結果の数字を確認する姿勢が、迅速な復旧につながります。

APIとWeb開発における設計ポイント

続いてはAPIとWeb開発における設計ポイントを確認していきます。

HTTPメソッドとの関係

APIでは、GET、POST、PUT、PATCH、DELETEなどのHTTPメソッドとステータスコードを組み合わせて、処理結果を分かりやすく伝えます。

GETによる取得成功では200、POSTによる新規作成では201、DELETEで本文を返さない成功では204が使われることがあります。

入力値に問題がある場合は400 Bad Request、認証情報が不足している場合は401、権限がない場合は403というように、失敗の種類を分ける設計が重要です。

呼び出す側はコードに応じてエラー画面を出す、再試行する、ログインを促すといった処理を行えます。

利用者に伝わるエラー設計

ステータスコードはシステム間の通信ルールですが、利用者への案内も同じくらい重要です。

404ページには、ページが移動または削除された可能性、URL確認の案内、トップページやカテゴリへのリンクを掲載すると親切です。

500エラーでは、専門的な原因をそのまま表示するより、一時的な問題が起きていること、時間を置いて再試行すること、問い合わせ方法を示すほうが安全でしょう。

データベース名、ファイルパス、詳細な例外メッセージなどを公開画面に出すと、セキュリティ上のリスクになる場合があります。

技術情報とユーザー向けメッセージを分けて管理することが、使いやすさと安全性の両立につながります。

監視とログの活用

大量の404、急増した500、特定URLへの繰り返しアクセスは、早期に把握したい変化です。

アクセス解析、サーバーログ、監視サービス、Search Consoleなどを組み合わせると、問題の兆候を見つけやすくなります。

特にECサイトや予約サイトでは、購入や申し込みの直前に5xxエラーが出ると機会損失につながるため、重要なURLを優先して監視することが求められます。

定期的な監視では、単にエラー件数を見るだけでなく、いつから増えたか、どの流入元で発生したか、特定の端末や地域に偏りがあるかも確認しましょう。

このような記録を残しておくと、更新作業やサーバー設定変更との関連も追いやすくなります。

ステータスコードの理解と運用のまとめ

ステータスコードは、HTTPリクエストに対するサーバーの処理結果を3桁の数字で示す仕組みです。

200は成功、301や302は転送、404や403はリクエストに関係する問題、500や503はサーバー側の問題という大枠を押さえると、通信の状態を読み取りやすくなります。

SEOでは、公開したいページが200を返していること、URL変更時に適切な301を設定すること、不要な404やリダイレクトチェーンを放置しないことが重要です。

また、Webサイトの表示不良やAPI連携の障害では、ステータスコードが原因調査の出発点になります。

ブラウザの開発者ツール、サーバーログ、監視ツールを活用し、数字の意味と実際の画面表示をあわせて確認しましょう。

HTTPレスポンスを正しく運用できれば、ユーザーにとって使いやすく、検索エンジンにも理解されやすいWebサイトづくりへ近づけます。