HTTPステータスコードとは何か
Webサイトを閲覧したり、アプリを使ったりする際、私たちが意識することはあまりありませんが、ブラウザとサーバーの間では常に「会話」が行われています。HTTPステータスコードとは、この会話の中でサーバーがブラウザに返す3桁の数字のことです。この数字によって、リクエストが成功したのか、エラーが発生したのか、別の場所に移動する必要があるのかといった情報が伝達されます。
たとえば、あなたがWebサイトのURLを入力してアクセスしたとき、ページが正常に表示されれば「200」というコードがサーバーから返されています。逆に「ページが見つかりません」というエラー画面が表示された場合は「404」というコードが返されているのです。このように、HTTPステータスコードはWeb上のあらゆる通信において、処理結果を明確に伝える役割を担っています。
[画像: ブラウザがサーバーにリクエストを送り、ステータスコード付きのレスポンスが返される流れを示した図解 | ファイル名: http-request-flow]
HTTPはHyperText Transfer Protocolの略で、Webにおける通信のルールを定めたものです。ステータスコードはこのルールの一部として標準化されており、世界中のどのサーバーでも同じ意味を持つように設計されています。そのため、Web開発者やSEO担当者にとって、HTTPステータスコードを理解することは基本中の基本といえるでしょう。
HTTPステータスコードは5つのクラスに分類されます。1xx（情報）、2xx（成功）、3xx（リダイレクト）、4xx（クライアントエラー）、5xx（サーバーエラー）があり、各クラスの最初の桁でレスポンスの種類を識別できます。
ステータスコードの基本的な構造
HTTPステータスコードは3桁の数字で構成されており、最初の1桁目がレスポンスの大まかな種類を表しています。1から5までの数字で始まり、それぞれ異なる意味を持ちます。100番台は処理が継続中であることを示し、200番台は成功、300番台はリダイレクト、400番台はクライアント側のエラー、500番台はサーバー側のエラーを意味します。
この仕組みにより、詳細なコードを覚えていなくても、最初の数字を見るだけでおおよその状況を把握できるようになっています。たとえば「503」というコードを初めて見たとしても、5で始まっているためサーバー側に何らかの問題があることがすぐにわかります。この直感的な設計がHTTPステータスコードの優れた点です。
HTTPステータスコードが重要である理由
HTTPステータスコードを理解することは、Webサイトの運営において非常に重要です。特にSEOの観点では、検索エンジンのクローラーがサイトを巡回する際にステータスコードを参照して、ページの状態を判断しています。適切なステータスコードを返さないと、検索エンジンがページを正しくインデックスできず、検索順位に悪影響を及ぼす可能性があります。
また、ユーザー体験の面でも重要です。エラーが発生した際に適切なステータスコードとともにわかりやすいエラーページを表示することで、ユーザーは何が起きたのかを理解し、次にどうすればよいかを判断できます。反対に、不適切なステータスコードを返すと、ユーザーは混乱し、サイトへの信頼を失ってしまうかもしれません。
Web開発の現場では、APIの設計やデバッグにおいてもステータスコードが活用されます。サーバーとクライアントの間で明確なコミュニケーションを取るために、状況に応じた適切なコードを返すことが求められます。これにより、問題が発生した際の原因特定が容易になり、開発効率の向上につながります。
SEOとクローラーへの影響
検索エンジンのクローラーは、Webサイトを巡回する際にHTTPステータスコードを重要な判断材料として使用しています。たとえば、ページが恒久的に移動した場合は301リダイレクトを設定することで、検索エンジンに新しいURLへの評価を引き継ぐよう伝えることができます。一方、一時的な移動であれば302を使用し、元のURLの評価を維持したまま一時的に別のページへ誘導します。
HTTP Archive Web Almanac 2024の調査によると、Webサイトのrobots.txtファイルへのアクセス時に返されるステータスコードは、モバイルサイトで200が83.9%、404が14.1%、403が0.3%、5xx系エラーが0.1%という分布になっています。このデータからも、大多数のサイトが正常にレスポンスを返している一方で、約14%のサイトでrobots.txtが見つからない状態であることがわかります。
404エラーが大量に発生しているサイトは、検索エンジンからの評価が下がる傾向があります。これはクローラーが効率的にサイトを巡回できず、サイト全体の品質が低いと判断されるためです。定期的にステータスコードを監視し、エラーを修正することがSEO対策の基本となります。
Googleのクローラーは4xxエラーを「コンテンツが存在しない」と判断し、検索結果から削除します。一方、5xxエラーが発生するとクローリングレートを低下させ、サーバーへの負荷を軽減します。429（Too Many Requests）はサーバー過負荷の信号として扱われます。
HTTPステータスコードの5つの分類を知る
HTTPステータスコードは、最初の数字によって5つのカテゴリに分類されています。それぞれのカテゴリには明確な役割があり、状況に応じて使い分けられています。ここでは各分類の概要を説明し、後のセクションで主要なカテゴリについて詳しく解説していきます。
| 分類 | 範囲 | 名称 | 意味 |
|---|---|---|---|
| 1xx | 100-199 | 情報レスポンス | リクエストを受け取り処理を継続中 |
| 2xx | 200-299 | 成功レスポンス | リクエストが正常に処理された |
| 3xx | 300-399 | リダイレクション | 追加のアクションが必要 |
| 4xx | 400-499 | クライアントエラー | リクエストに問題がある |
| 5xx | 500-599 | サーバーエラー | サーバー側で問題が発生 |
1xx番台は情報レスポンスと呼ばれ、リクエストを受け取り処理を継続していることを示します。一般的なWebブラウジングではあまり目にすることはありませんが、大きなファイルのアップロード時などに使用されることがあります。代表的なものとして、100 Continueや101 Switching Protocolsがあります。
2xx番台は成功レスポンスを表し、リクエストが正常に処理されたことを示します。200 OKが最も一般的で、Webページが問題なく表示される際に返されます。201 Createdや204 No Contentなど、成功の種類によって細かく分かれています。
3xx番台はリダイレクションを示し、リクエストを完了するために追加のアクションが必要であることを伝えます。ページの移転やURLの変更時に使用され、SEOにおいて非常に重要な役割を果たします。
4xx番台はクライアントエラーで、リクエストに問題があることを示します。URLの入力ミスや認証エラーなど、ユーザー側に起因する問題が該当します。5xx番台はサーバーエラーを表し、サーバー側で問題が発生していることを示します。
各分類の使い分けの考え方
ステータスコードを正しく使い分けることは、Web開発において非常に重要です。たとえば、リソースが見つからない場合は404を返すべきですが、認証が必要なリソースに未認証でアクセスした場合は401を返すのが適切です。このような細かな使い分けによって、クライアント側は問題の原因を正確に把握し、適切な対応を取ることができます。
また、サーバー側の問題とクライアント側の問題を明確に区別することも重要です。ユーザーの入力ミスによるエラーに対して500番台を返してしまうと、実際にはサーバーに問題がないにもかかわらず、サーバー障害として認識されてしまいます。適切なステータスコードを返すことで、問題の切り分けが容易になります。
HTTPステータスコードは拡張可能な仕様です。クライアントはすべての登録済みステータスコードの意味を理解する必要はありませんが、最初の桁で示されるクラス（1xx〜5xx）は必ず理解しなければなりません。
200番台の成功レスポンスを理解する
200番台のステータスコードは、クライアントからのリクエストがサーバーによって正常に受け取られ、理解され、処理されたことを示します。Webサイトを閲覧する際、ほとんどの場合はこの200番台のコードが返されており、私たちが意識することなくページが表示されています。
主な200番台ステータスコードには以下のものがあります。
- 200 OK：リクエストが成功し、要求されたデータが返される最も基本的な成功コード
- 201 Created：リクエストが成功し、新しいリソースが作成されたことを示す
- 204 No Content：リクエストは成功したがレスポンスとして返すコンテンツがない
- 206 Partial Content：範囲リクエストが成功し、部分的なコンテンツが返される
200 OKは最も基本的な成功コードで、リクエストが成功し、レスポンスとして要求されたデータが返されることを意味します。通常のWebページの表示やAPIからのデータ取得など、あらゆる成功レスポンスの基本となるコードです。
201 Createdは、リクエストが成功し、新しいリソースが作成されたことを示します。フォームの送信やAPIを通じた新規データの登録など、何かを「作成」する操作が成功した際に返されます。レスポンスには通常、作成されたリソースの場所を示すLocationヘッダーが含まれます。
204 No Contentは、リクエストは成功したがレスポンスとして返すコンテンツがないことを示します。削除操作が成功した場合や、保存ボタンを押して設定が更新された場合など、特に返すデータがない状況で使用されます。
200 OKと201 Createdの使い分け
200と201はどちらも成功を示すコードですが、その意味合いは異なります。200は主にデータの取得や更新が成功した際に使用され、201は新しいリソースが作成された際に使用されます。この区別はRESTful APIの設計において特に重要で、クライアント側が操作の結果を正確に把握するために必要です。
| 項目 | 200 OK | 201 Created |
|---|---|---|
| 用途 | データ取得・更新の成功 | 新規リソース作成の成功 |
| 代表的な操作 | GET、PUT、PATCH | POST |
| レスポンスボディ | 要求されたデータ | 作成されたリソース |
| Locationヘッダー | 通常なし | 作成されたリソースのURL |
たとえば、ユーザー登録のAPIを考えてみましょう。新規ユーザーが登録された場合は201を返し、既存ユーザーの情報を更新した場合は200を返すのが適切です。この使い分けにより、APIを利用する開発者は、レスポンスのステータスコードを見るだけで何が行われたかを判断できます。
300番台のリダイレクト処理を把握する
300番台のステータスコードはリダイレクションを示し、要求されたリソースが別の場所に移動したことをクライアントに伝えます。Webサイトのリニューアルや URL構造の変更、httpからhttpsへの移行など、さまざまな場面で使用される重要なコードです。
301 Moved Permanentlyは、リソースが恒久的に新しいURLに移動したことを示します。検索エンジンは301リダイレクトを検出すると、古いURLの評価を新しいURLに引き継ぎます。サイトのリニューアルやドメイン変更の際には、必ず301リダイレクトを設定することがSEOの観点から推奨されます。
302 Foundは、リソースが一時的に別のURLに移動していることを示します。メンテナンス中の一時的な迂回や、A/Bテストでの一時的なページ切り替えなど、元のURLに戻る予定がある場合に使用します。302では検索エンジンは元のURLの評価を維持し続けます。
304 Not Modifiedは、キャッシュに関連するコードで、リクエストされたリソースが前回取得時から変更されていないことを示します。ブラウザはキャッシュされたコンテンツを使用できるため、データ転送量を削減し、ページ表示を高速化できます。
301と302の違いとSEOへの影響
301と302の違いは、Web開発者やSEO担当者にとって非常に重要な知識です。301は恒久的な移動を示すため、検索エンジンは新しいURLをインデックスし、古いURLへの評価を新しいURLに統合します。一方、302は一時的な移動なので、検索エンジンは古いURLをインデックスに残し続けます。
| 項目 | 301 Moved Permanently | 302 Found |
|---|---|---|
| 移動の性質 | 恒久的 | 一時的 |
| SEO評価の引き継ぎ | 新URLに統合される | 元URLに維持される |
| インデックス対象 | 新URL | 元URL |
| 推奨される使用場面 | ドメイン変更、URL構造変更 | メンテナンス、A/Bテスト |
| キャッシュ | ブラウザがキャッシュ可能 | 通常キャッシュされない |
誤って302を使用し続けると、本来は統合されるべきページ評価が分散してしまい、SEOに悪影響を及ぼすことがあります。サイト移転やURL構造の変更など、恒久的な変更には必ず301リダイレクトを使用しましょう。また、リダイレクトチェーンが長くなると、クローラーの巡回効率が低下するため、できるだけ直接的なリダイレクトを設定することが望ましいです。
Googleは最大10ホップまでリダイレクトを追跡します。301は「リダイレクト先を処理すべき」という強い信号として機能し、302は弱い信号として扱われます。307と308はそれぞれ302と301に相当しますが、HTTPメソッドを維持します。
400番台のクライアントエラーに対処する
400番台のステータスコードは、クライアント側のリクエストに問題があることを示します。URLの入力ミス、認証情報の不備、アクセス権限の問題など、ユーザーやクライアントアプリケーション側に原因がある場合に返されます。
主な400番台ステータスコードは以下の通りです。
- 400 Bad Request：リクエストの構文が不正、または必要なパラメータが欠けている
- 401 Unauthorized：認証が必要なリソースに認証情報なしでアクセス
- 403 Forbidden：認証の有無にかかわらずアクセスが禁止されている
- 404 Not Found：要求されたリソースがサーバー上に存在しない
- 422 Unprocessable Entity：リクエスト形式は正しいが内容に問題がある
400 Bad Requestは、サーバーがリクエストを理解できないことを示します。リクエストの構文が不正であったり、必要なパラメータが欠けていたりする場合に返されます。フォームの入力値が不正な場合や、APIへのリクエスト形式が間違っている場合などが該当します。
404 Not Foundは最もよく目にするエラーコードで、要求されたリソースがサーバー上に存在しないことを示します。URLの入力ミス、削除されたページへのアクセス、リンク切れなどが原因で発生します。ユーザーフレンドリーな404ページを用意することで、離脱を防ぎ、サイト内の他のコンテンツへ誘導できます。
422 Unprocessable Entityは、リクエストの形式は正しいが、内容に問題があり処理できないことを示します。バリデーションエラーなど、意味的に正しくないデータが送信された場合に使用されます。
401 Unauthorizedと403 Forbiddenの違い
401と403はどちらもアクセスが拒否されることを示しますが、その理由が異なります。401 Unauthorizedは認証が必要なリソースに対して、認証情報が提供されていない、または無効であることを示します。ログインが必要なページに未ログインでアクセスした場合がこれに該当します。401を受け取ったクライアントは、認証情報を提供することで再度アクセスを試みることができます。
403 Forbiddenは、認証の有無にかかわらず、そのリソースへのアクセスが禁止されていることを示します。ログイン済みであっても、管理者専用ページに一般ユーザーがアクセスしようとした場合などに返されます。403の場合、認証情報を変えてもアクセスできないため、そもそもアクセス権限がないことを意味します。
| 項目 | 401 Unauthorized | 403 Forbidden |
|---|---|---|
| 意味 | 認証が必要/無効 | アクセス権限なし |
| 原因 | ログインしていない、トークン期限切れ | 権限不足、IP制限 |
| 解決策 | 正しい認証情報を提供 | 管理者に権限付与を依頼 |
| 再試行 | 認証後に可能 | 権限変更なしでは不可 |
400と404の適切な使い分け
400と404もよく混同されがちですが、明確な違いがあります。404はリソースが存在しないことを示し、400はリクエスト自体に問題があることを示します。具体的には、正しいURL形式で存在しないページにアクセスした場合は404が適切ですが、そもそもURLの形式が不正な場合は400が適切です。
| 項目 | 400 Bad Request | 404 Not Found |
|---|---|---|
| 問題の所在 | リクエストの形式・内容 | リソースの存在 |
| 例 | 必須パラメータの欠落、不正なJSON | 存在しないURL、削除済みページ |
| クライアントの対応 | リクエストを修正して再送信 | 正しいURLを確認 |
APIの設計においては、存在しないIDのリソースを要求された場合は404を返し、必須パラメータが欠けているリクエストには400を返すのが一般的です。この区別により、クライアント側は問題がURLにあるのか、リクエストの内容にあるのかを判断できます。
500番台のサーバーエラーを解決する
500番台のステータスコードは、サーバー側で問題が発生し、リクエストを処理できなかったことを示します。これらのエラーはユーザー側では解決できず、サーバー管理者やWeb開発者が対処する必要があります。
主な500番台ステータスコードには以下があります。
- 500 Internal Server Error：サーバー内部で予期せぬエラーが発生
- 502 Bad Gateway：上流サーバーから無効なレスポンスを受信
- 503 Service Unavailable：サーバーが一時的にリクエストを処理できない
- 504 Gateway Timeout：上流サーバーからの応答がタイムアウト
500 Internal Server Errorは、サーバー内部で予期せぬエラーが発生したことを示す汎用的なエラーコードです。プログラムのバグ、設定ミス、リソース不足など、さまざまな原因で発生します。エラーログを確認し、具体的な原因を特定することが解決の第一歩です。
502 Bad Gatewayは、サーバーがゲートウェイやプロキシとして動作している際に、上流のサーバーから無効なレスポンスを受け取ったことを示します。ロードバランサーの背後にあるアプリケーションサーバーがダウンしている場合などに発生します。
503 Service Unavailableは、サーバーが一時的にリクエストを処理できない状態にあることを示します。メンテナンス中や過負荷状態の際に返されます。Retry-Afterヘッダーを含めることで、クライアントに再試行のタイミングを伝えることができます。
504 Gateway Timeoutは、ゲートウェイやプロキシサーバーが上流サーバーからの応答を待っている間にタイムアウトしたことを示します。処理に時間がかかりすぎた場合や、上流サーバーとの通信に問題がある場合に発生します。
Googleは5xxエラーが発生すると、そのサイトへのクローリングレートを自動的に低下させます。既にインデックスされているコンテンツは一時的に保持されますが、エラーが継続すると最終的には検索結果から削除されます。
408 Request Timeoutと504 Gateway Timeoutの違い
408と504はどちらもタイムアウトに関連するコードですが、発生する場所が異なります。408 Request Timeoutは、サーバーがクライアントからのリクエストを待っている間にタイムアウトしたことを示します。クライアントがリクエストの送信に時間がかかりすぎた場合に発生します。
一方、504 Gateway Timeoutは、サーバー間の通信でタイムアウトが発生した場合に返されます。プロキシやゲートウェイが上流サーバーからの応答を受け取れなかった場合です。408はクライアントとサーバー間の問題、504はサーバー間の問題という点で区別できます。
| 項目 | 408 Request Timeout | 504 Gateway Timeout |
|---|---|---|
| タイムアウトの発生場所 | クライアント→サーバー間 | サーバー→上流サーバー間 |
| 原因 | クライアントの送信遅延 | 上流サーバーの応答遅延 |
| 解決策 | ネットワーク環境の確認 | サーバー側の設定・負荷確認 |
| 分類 | 4xx（クライアントエラー） | 5xx（サーバーエラー） |
よくある疑問と混同しやすいコードの違い
HTTPステータスコードを学び始めると、似たようなコード同士の違いがわかりにくいと感じることがあります。ここでは、よくある疑問と混同しやすいコードについて整理しておきましょう。
まず、ステータスコード0について触れておきます。正式なHTTPステータスコードには0は存在しませんが、ブラウザやクライアントライブラリで0が返されることがあります。これは通常、リクエストが完了する前にキャンセルされた場合や、CORS（Cross-Origin Resource Sharing）ポリシーによってリクエストがブロックされた場合に発生します。ネットワーク接続の問題やファイアウォールによるブロックも原因となることがあります。
また、リダイレクトに関して、307 Temporary Redirectと308 Permanent Redirectという比較的新しいコードもあります。これらは302と301に似ていますが、リダイレクト時にHTTPメソッドを変更しないという点で異なります。POSTリクエストをリダイレクトする際に、メソッドを維持したい場合に使用されます。
実務でよく遭遇するエラーへの対処法
実務においてよく遭遇するのは、404エラーと500エラーです。404エラーが多発している場合は、サイト内のリンク切れをチェックするツールを使用して、問題のあるリンクを修正することが有効です。また、Google Search Consoleなどのツールでクロールエラーを監視し、検索エンジンがアクセスできないページを把握することも重要です。
500エラーが発生した場合は、サーバーのエラーログを確認することから始めます。PHPであればerror_log、Pythonであればトレースバック、JavaScriptではコンソールログなど、使用している技術に応じた方法でエラーの詳細を確認します。本番環境で500エラーが発生した場合は、ユーザーに詳細なエラー情報を見せずに、一般的なエラーメッセージを表示することがセキュリティ上推奨されます。
200（成功）ステータスのコンテンツはGoogleの処理パイプラインに送信されますが、インデックス登録は保証されません。201（作成完了）や202（受理済み）のレスポンスは、Googleが一定時間待機してから処理を行います。
よくある質問
SEO対策研究室の室長、株式会社コンテンシャルの代表取締役を務める。長年WEB業界に携わった経験をもとに、SEO対策とAI活用を具体的かつ実践的に解説。SEOの技術的な部分だけでなく、コンテンツ戦略、内部設計、ページ速度の改善など、広く現場で活用できるノウハウを提供。実際の検証データや豊富な成功事例・失敗談も交えながら、すぐに役立つ施策をお伝えします。
関連する記事
