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サイトづくりへ近づけます。