# HTTPステータスコードとは？5分類と主要コードをわかりやすく解説

> **Canonical:** https://www.tsuyoshikashiwazaki.jp/blog/http-status-code/
> This Markdown is the AI-optimized parallel version of the canonical HTML page above. Authority, freshness, and canonicalness belong to the canonical page.

> **Schema.org/Article**
> - headline: HTTPステータスコードとは？5分類と主要コードをわかりやすく解説
> - author: 柏崎剛
> - datePublished: 2025-12-22T06:35:53+09:00
> - dateModified: 2025-12-22T06:35:31+09:00
> - inLanguage: ja
> - url: https://www.tsuyoshikashiwazaki.jp/blog/http-status-code/
>
> **Schema.org/BreadcrumbList**
> - 1: SEO対策研究室 (https://md.tsuyoshikashiwazaki.jp/)
> - 2: 柏崎剛のSEOブログアーカイブ (https://md.tsuyoshikashiwazaki.jp/blog/)
> - 3: HTTPステータスコードとは？5分類と主要コードをわかりやすく解説 (https://md.tsuyoshikashiwazaki.jp/blog/http-status-code/)

HTTPステータスコード、Web制作やSEOをやっていると避けては通れないテーマですよね。僕は14年以上この業界にいますが、リダイレクトの301と302を間違えて検索順位が落ちたとか、500エラーが出てるのに気づかずクローラーに嫌われてたとか、そういう相談を本当にたくさん受けてきました。この記事では、5つの分類と実務でよく使う主要コードをまとめています。「ステータスコードってなんとなく知ってるけど、ちゃんと整理したことないな」という方にはちょうどいい内容になっていると思います。

 目次閉じるもっと見る

## 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 レスポンスステータスコード - HTTP | MDNHTTP のレスポンスステータスコードは、特定の HTTP リクエストが正常に完了したどうかを示します。 レスポンスは 5 つに分類されています。外部リンク!\[HTTP レスポンスステータスコード - HTTP | MDN\](<https://developer.mozilla.org/favicon.ico>)](<https://developer.mozilla.org/ja/docs/Web/HTTP/Status>)

### ステータスコードの基本的な構造

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が見つからない状態であることがわかります。

  

> **出典: [HTTP Archive Web Almanac 2024 SEO Chapter](<https://almanac.httparchive.org/en/2024/seo>)**

404エラーが大量に発生しているサイトは、検索エンジンからの評価が下がる傾向があります。これはクローラーが効率的にサイトを巡回できず、サイト全体の品質が低いと判断されるためです。定期的にステータスコードを監視し、エラーを修正することがSEO対策の基本となります。

Googleのクローラーは4xxエラーを「コンテンツが存在しない」と判断し、検索結果から削除します。一方、5xxエラーが発生するとクローリングレートを低下させ、サーバーへの負荷を軽減します。429（Too Many Requests）はサーバー過負荷の信号として扱われます。

> [HTTP ステータス コードが Google のクローラーに及ぼす影響 | Google クロール インフラストラクチャ  |  Crawling infrastructure  |  Google for DevelopersHTTP ステータス コードが Google のクローラに及ぼす影響について説明します。Google for Developers外部リンク!\[HTTP ステータス コードが Google のクローラーに及ぼす影響 | Google クロール インフラストラクチャ  |  Crawling infrastructure  |  Google for Developers\](<https://www.gstatic.com/devrel-devsite/prod/v1b953b434e2033f0160fd97c99360ee5d4d0a613449c2a694360a72d378b9d8e/developers/images/opengraph/white.png>)](<https://developers.google.com/search/docs/crawling-indexing/http-network-errors>)

 

HTTPステータスコードの監視を自動化したい場合、WordPressではアクセスログを詳細記録するプラグインが有効です。IP・User-Agent・リファラー・URIに加えてHTTPステータスコードも記録し、時系列でのエラー発生傾向をチャート可視化できるため、500系エラーの急増や404の多発パターンを早期発見できます。

 

> [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-super-access-log: WordPress access log plugin with visitor tracking, bot filtering, CSV export/import, charts, and security features.WordPress access log plugin with visitor tracking, bot filtering, CSV export/import, charts, and security features. - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-super-access-logGitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-super-access-log: WordPress access log plugin with visitor tracking, bot filtering, CSV export/import, charts, and security features.\](<https://opengraph.githubassets.com/106af344fc5c8df60d77870c4c8a4706ce6164913fd746242a0d81f6edc78a8b/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-super-access-log>)](<https://github.com/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-super-access-log>)

 

## HTTPステータスコードの5つの分類を知る

HTTPステータスコードは、最初の数字によって5つのカテゴリに分類されています。それぞれのカテゴリには明確な役割があり、状況に応じて使い分けられています。ここでは各分類の概要を説明し、後のセクションで主要なカテゴリについて詳しく解説していきます。

分類範囲名称意味1xx100-199情報レスポンスリクエストを受け取り処理を継続中2xx200-299成功レスポンスリクエストが正常に処理された3xx300-399リダイレクション追加のアクションが必要4xx400-499クライアントエラーリクエストに問題がある5xx500-599サーバーエラーサーバー側で問題が発生

1xx番台は情報レスポンスと呼ばれ、リクエストを受け取り処理を継続していることを示します。一般的なWebブラウジングではあまり目にすることはありませんが、大きなファイルのアップロード時などに使用されることがあります。代表的なものとして、100 Continueや101 Switching Protocolsがあります。

2xx番台は成功レスポンスを表し、リクエストが正常に処理されたことを示します。200 OKが最も一般的で、Webページが問題なく表示される際に返されます。201 Createdや204 No Contentなど、成功の種類によって細かく分かれています。

3xx番台はリダイレクションを示し、リクエストを完了するために追加のアクションが必要であることを伝えます。ページの移転やURLの変更時に使用され、SEOにおいて非常に重要な役割を果たします。

4xx番台はクライアントエラーで、リクエストに問題があることを示します。URLの入力ミスや認証エラーなど、ユーザー側に起因する問題が該当します。5xx番台はサーバーエラーを表し、サーバー側で問題が発生していることを示します。

 ![5つのステータスコード分類を色分けして示した概念図](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/status-code-chart.jpg>)

### 各分類の使い分けの考え方

ステータスコードを正しく使い分けることは、Web開発において非常に重要です。たとえば、リソースが見つからない場合は404を返すべきですが、認証が必要なリソースに未認証でアクセスした場合は401を返すのが適切です。このような細かな使い分けによって、クライアント側は問題の原因を正確に把握し、適切な対応を取ることができます。

また、サーバー側の問題とクライアント側の問題を明確に区別することも重要です。ユーザーの入力ミスによるエラーに対して500番台を返してしまうと、実際にはサーバーに問題がないにもかかわらず、サーバー障害として認識されてしまいます。適切なステータスコードを返すことで、問題の切り分けが容易になります。

HTTPステータスコードは拡張可能な仕様です。クライアントはすべての登録済みステータスコードの意味を理解する必要はありませんが、最初の桁で示されるクラス（1xx〜5xx）は必ず理解しなければなりません。

> [RFC 9110: HTTP Semantics The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 外部リンク!\[RFC 9110: HTTP Semantics\](<https://www.google.com/s2/favicons?domain=www.rfc-editor.org&sz=128>)](<https://www.rfc-editor.org/rfc/rfc9110>)

## 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 OK201 Created用途データ取得・更新の成功新規リソース作成の成功代表的な操作GET、PUT、PATCHPOSTレスポンスボディ要求されたデータ作成されたリソース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の評価を維持し続けます。

 ![301と302リダイレクトでSEO評価がどのように引き継がれるかを示したフロー図](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/redirect-seo-flow.jpg>)

304 Not Modifiedは、キャッシュに関連するコードで、リクエストされたリソースが前回取得時から変更されていないことを示します。ブラウザはキャッシュされたコンテンツを使用できるため、データ転送量を削減し、ページ表示を高速化できます。

### 301と302の違いとSEOへの影響

301と302の違いは、Web開発者やSEO担当者にとって非常に重要な知識です。301は恒久的な移動を示すため、検索エンジンは新しいURLをインデックスし、古いURLへの評価を新しいURLに統合します。一方、302は一時的な移動なので、検索エンジンは古いURLをインデックスに残し続けます。

項目301 Moved Permanently302 Found移動の性質恒久的一時的SEO評価の引き継ぎ新URLに統合される元URLに維持されるインデックス対象新URL元URL推奨される使用場面ドメイン変更、URL構造変更メンテナンス、A/Bテストキャッシュブラウザがキャッシュ可能通常キャッシュされない

Apacheサーバーで301リダイレクトを設定する場合は、.htaccessファイルに以下のように記述します。

`Redirect 301 /old-page.html https://example.com/new-page.html`

サイト全体をHTTPSに強制リダイレクトする場合は、RewriteRuleを使用します。

```
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
```

誤って302を使用し続けると、本来は統合されるべきページ評価が分散してしまい、SEOに悪影響を及ぼすことがあります。サイト移転やURL構造の変更など、恒久的な変更には必ず**301リダイレクト**を使用しましょう。また、リダイレクトチェーンが長くなると、クローラーの巡回効率が低下するため、できるだけ直接的なリダイレクトを設定することが望ましいです。

Googleは最大10ホップまでリダイレクトを追跡します。301は「リダイレクト先を処理すべき」という強い信号として機能し、302は弱い信号として扱われます。307と308はそれぞれ302と301に相当しますが、HTTPメソッドを維持します。

SEO対策研究室[!\[柏崎剛\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2022/03/2021%E5%B9%B412%E6%9C%889%E6%97%A5_%E6%96%B0%E5%AE%BF%E3%82%B5%E3%82%B6%E3%83%B3%E3%83%86%E3%83%A9%E3%82%B9%E5%8F%A3%E3%81%AB%E3%81%A6.jpg>)](<https://md.tsuyoshikashiwazaki.jp/profile/>)[柏崎剛](<https://md.tsuyoshikashiwazaki.jp/profile/>)リダイレクト設定のミス、これがSEOトラブルの中でも本当に多いんですよ。サイトリニューアルのときに302で設定しちゃって、数か月後に「新サイトの順位が全然上がらないんですけど…」って相談が来るパターン。僕も何度対応したかわからないくらいです。リダイレクト設定したら、ステータスコードチェッカーでちゃんと301になってるか確認する。この一手間で防げるトラブルなので、ぜひやってみてください。 

XMLサイトマップに登録されたURLが実際に200を返すか、404や5xxエラーになっていないかを定期的に一括チェックできると、リダイレクト設定ミスや削除済みページの検出が自動化できます。cron対応で定期実行し、異常検出時にメール通知を受け取れます。

 

> [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-xml-vitalcheck: Batch check the health of multiple XML files (such as sitemaps and RSS feeds). Automate monitoring with scheduled runs and email notifications to keep essential SEO-related XML files under control.Batch check the health of multiple XML files (such as sitemaps and RSS feeds). Automate monitoring with scheduled runs and email notifications to keep essential SEO-related XML files under control. - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-xml-vitalcheckGitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-xml-vitalcheck: Batch check the health of multiple XML files (such as sitemaps and RSS feeds). Automate monitoring with scheduled runs and email notifications to keep essential SEO-related XML files under control.\](<https://opengraph.githubassets.com/9ed276f8bb15372492618f71fb9928fb5d99ae4ea8ef01d6c5146a7dc76cc012/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-xml-vitalcheck>)](<https://github.com/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-xml-vitalcheck>)

 

## 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ページを用意することで、離脱を防ぎ、サイト内の他のコンテンツへ誘導できます。

 

WordPressでは404エラーページのカスタマイズに専用プラグインを活用できます。単に「ページが見つかりません」と表示するだけでなく、類似URLからのリダイレクト候補提示や関連記事の自動表示機能を実装すれば、離脱率を大幅に下げられます。構造化マークアップによるSEO最適化も同時に実現できます。

 

> [GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-custom-404: Displays a custom error page on HTTP 404 errors, featuring redirect suggestions, related articles, and recent posts. Includes color theme selection, structured markup, footer functionality, and customizable redirect behavior.Displays a custom error page on HTTP 404 errors, featuring redirect suggestions, related articles, and recent posts. Includes color theme selection, structured markup, footer functionality, and customizable redirect behavior. - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-custom-404GitHub外部リンク!\[GitHub - TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-custom-404: Displays a custom error page on HTTP 404 errors, featuring redirect suggestions, related articles, and recent posts. Includes color theme selection, structured markup, footer functionality, and customizable redirect behavior.\](<https://opengraph.githubassets.com/12cb4e0320c0d214b8cb8f4606c4092ffabf21c0996d5b962c2e421402e36e44/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-custom-404>)](<https://github.com/TsuyoshiKashiwazaki/wp-plugin-kashiwazaki-seo-custom-404>)

 

422 Unprocessable Entityは、リクエストの形式は正しいが、内容に問題があり処理できないことを示します。バリデーションエラーなど、意味的に正しくないデータが送信された場合に使用されます。

### 401 Unauthorizedと403 Forbiddenの違い

401と403はどちらもアクセスが拒否されることを示しますが、その理由が異なります。401 Unauthorizedは認証が必要なリソースに対して、認証情報が提供されていない、または無効であることを示します。ログインが必要なページに未ログインでアクセスした場合がこれに該当します。401を受け取ったクライアントは、認証情報を提供することで再度アクセスを試みることができます。

403 Forbiddenは、認証の有無にかかわらず、そのリソースへのアクセスが禁止されていることを示します。ログイン済みであっても、管理者専用ページに一般ユーザーがアクセスしようとした場合などに返されます。403の場合、認証情報を変えてもアクセスできないため、そもそもアクセス権限がないことを意味します。

項目401 Unauthorized403 Forbidden意味認証が必要/無効アクセス権限なし原因ログインしていない、トークン期限切れ権限不足、IP制限解決策正しい認証情報を提供管理者に権限付与を依頼再試行認証後に可能権限変更なしでは不可

### 400と404の適切な使い分け

400と404もよく混同されがちですが、明確な違いがあります。404はリソースが存在しないことを示し、400はリクエスト自体に問題があることを示します。具体的には、正しいURL形式で存在しないページにアクセスした場合は404が適切ですが、そもそもURLの形式が不正な場合は400が適切です。

項目400 Bad Request404 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 Timeout504 Gateway Timeoutタイムアウトの発生場所クライアント→サーバー間サーバー→上流サーバー間原因クライアントの送信遅延上流サーバーの応答遅延解決策ネットワーク環境の確認サーバー側の設定・負荷確認分類4xx（クライアントエラー）5xx（サーバーエラー） ![408と504のタイムアウトが発生する場所の違いを示した通信フロー図](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/timeout-compare-1024x593.jpg>)SEO対策研究室[!\[柏崎剛\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2022/03/2021%E5%B9%B412%E6%9C%889%E6%97%A5_%E6%96%B0%E5%AE%BF%E3%82%B5%E3%82%B6%E3%83%B3%E3%83%86%E3%83%A9%E3%82%B9%E5%8F%A3%E3%81%AB%E3%81%A6.jpg>)](<https://md.tsuyoshikashiwazaki.jp/profile/>)[柏崎剛](<https://md.tsuyoshikashiwazaki.jp/profile/>)本番で**500エラー**が出ると、つい焦って原因調査に飛びつきたくなるんですけど、まずやるべきなのはユーザーにちゃんとしたエラーページを見せることなんですよね。エラーの詳細をそのまま画面に出しちゃうと、セキュリティ的にかなりまずい。実際、僕が対応したプロジェクトでも、本番環境でスタックトレースが丸見えになってたケースが何度かありました。環境変数でデバッグモードを切り替える仕組みは、最初に入れておくのが鉄則です。

## よくある疑問と混同しやすいコードの違い

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などのツールでクロールエラーを監視し、検索エンジンがアクセスできないページを把握することも重要です。

 ![Google Search Consoleでクロールエラーを確認している画面のイメージ](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/search-console-err.jpg>)

500エラーが発生した場合は、サーバーのエラーログを確認することから始めます。PHPであればerror_log、Pythonであればトレースバック、JavaScriptではコンソールログなど、使用している技術に応じた方法でエラーの詳細を確認します。本番環境で500エラーが発生した場合は、ユーザーに詳細なエラー情報を見せずに、一般的なエラーメッセージを表示することがセキュリティ上推奨されます。

ターミナルから特定URLのHTTPステータスコードを素早く確認したい場合は、以下のcurlコマンドが便利です。

`curl -I -s -o /dev/null -w "%{http_code}" https://example.com`

このコマンドは `-I` でHEADリクエストを送信し、`-s` でサイレントモード、`-o /dev/null` でボディを破棄、`-w "%{http_code}"` でステータスコードのみを出力します。複数URLを一括チェックする際にスクリプトに組み込むと効率的です。

JavaScriptでAPIを呼び出す際にステータスコードを確認してエラーハンドリングを行う場合は、以下のようにfetchのresponse.okプロパティとstatusを組み合わせます。

```
fetch(url)
  .then(response => {
    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }
    return response.json();
  })
  .catch(error => console.error('Fetch failed:', error));
```

200（成功）ステータスのコンテンツはGoogleの処理パイプラインに送信されますが、インデックス登録は保証されません。201（作成完了）や202（受理済み）のレスポンスは、Googleが一定時間待機してから処理を行います。

## よくある質問

❓HTTPステータスコードはどこで確認できますか？▼✅一番手軽なのは、ブラウザの開発者ツール（F12キー）を開いてネットワークタブを見る方法です。リクエストごとに200とか404とかのステータスコードが表示されるので、すぐに状況がわかります。サイト全体の傾向を把握したいなら、Google Search Consoleでクロールエラーをチェックするのがおすすめです。❓301リダイレクトを設定しないとどうなりますか？▼✅ページを別のURLに移したのに301を設定しないと、古いURLにアクセスした人は404エラーを見ることになります。それだけじゃなく、検索エンジンがこれまで積み上げてきたSEO評価を新しいURLに引き継げなくなるので、せっかくの順位が無駄になってしまう可能性があります。サイトリニューアル時にありがちなミスなので、気をつけたいところです。❓5xxエラーが頻発する場合の対処法は？▼✅まずはサーバーのエラーログを見て、何が起きているかを把握するのが先決です。サーバーリソースの不足だったり、プログラムのバグだったり、設定ミスだったり、原因はさまざまです。とりあえずサーバーを再起動すれば一時的に直ることもありますが、根本原因を放置するとまた再発するので、ログから原因を特定して対処するのが大事です。

## 関連する記事

[!\[『404 Not Found エラーの意味と解消法を解説！』と記載された文章と、その近くにいる男性。\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2022/08/404-Not-Found%E3%81%A8%E3%81%AF%EF%BC%9F%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%AE%E6%84%8F%E5%91%B3%E3%81%A8%E8%A7%A3%E6%B6%88%E6%B3%95-300x169.png>)](<https://md.tsuyoshikashiwazaki.jp/blog/http-status-code/what-is-404-not-found/>)[404 Not Found（404エラー）とは？原因・解決方法と効果的なエラーペ...](<https://md.tsuyoshikashiwazaki.jp/blog/http-status-code/what-is-404-not-found/>)404エラー「404 Not Found」とは、サーバーに存…[!\[502エラーの原因と解決策を紹介する記事のアイキャッチ画像 502エラーとは？原因と解決先を紹介！という文字とバツ印のポーズとグッドポーズの柏崎剛の画像が配置されている\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2023/12/%EF%BC%95%EF%BC%90%EF%BC%92%E3%82%A8%E3%83%A9%E3%83%BC%E3%81%A8%E3%81%AF%EF%BC%9F-300x169.jpg>)](<https://md.tsuyoshikashiwazaki.jp/blog/http-status-code/what-is-502-error/>)[502 Bad Gatewayとは？原因・リスク・解決策をわかりやすく徹底解説](<https://md.tsuyoshikashiwazaki.jp/blog/http-status-code/what-is-502-error/>)502 Bad Gatewayエラーの原因やリスク、解決策を…[!\[\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/smb-rich-result-300x169.jpg>)](<https://md.tsuyoshikashiwazaki.jp/blog/rich-result/>)[リッチリザルトとは？検索結果で目立つためのリッチリザルト徹底解説と導入方法まとめ](<https://md.tsuyoshikashiwazaki.jp/blog/rich-result/>)検索結果で目立つリッチリザルトの徹底解説と導入方法を紹介しま…[!\[被リンクとは？SEO効果を高める獲得方法と避けるべき注意点\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/01/thmb-backlink-seo-300x200.jpg>)](<https://md.tsuyoshikashiwazaki.jp/blog/backlink-seo/>)[被リンクとは？SEO効果を高める獲得方法と避けるべき注意点](<https://md.tsuyoshikashiwazaki.jp/blog/backlink-seo/>)被リンクとは、他サイトから自サイトへ貼られるリンクで、SEO…[!\[LSIキーワードを解説することを強調した画像 オレンジと黄色の背景と説明する男性が表示されている\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2022/02/lsi-keyword-mv-300x169.png>)](<https://md.tsuyoshikashiwazaki.jp/blog/what-is-lsi-in-seo/>)[LSIキーワードとは？SEO効果を高める調べ方と使い方](<https://md.tsuyoshikashiwazaki.jp/blog/what-is-lsi-in-seo/>)LSIキーワードとは、メインキーワードの意味的関連語を自然に…[!\[Googleアルゴリズムとは？仕組み・歴史・対策を徹底解説\](<https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/12/smb-google-algorithm-300x169.jpg>)](<https://md.tsuyoshikashiwazaki.jp/blog/google-algorithm/>)[Googleアルゴリズムとは？仕組み・歴史・対策を徹底解説](<https://md.tsuyoshikashiwazaki.jp/blog/google-algorithm/>)【2025年版】Googleアルゴリズムの仕組み・歴史・最新…‹›

## 記事が気に入ったらシェアをお願いします！

[](<https://www.addtoany.com/add_to/facebook?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/twitter?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/line?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/linkedin?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/email?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/pinterest?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)[](<https://www.addtoany.com/add_to/sms?linkurl=https%3A%2F%2Fwww.tsuyoshikashiwazaki.jp%2Fblog%2Fhttp-status-code%2F&linkname=HTTP%E3%82%B9%E3%83%86%E3%83%BC%E3%82%BF%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%81%A8%E3%81%AF%EF%BC%9F5%E5%88%86%E9%A1%9E%E3%81%A8%E4%B8%BB%E8%A6%81%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E3%82%8F%E3%81%8B%E3%82%8A%E3%82%84%E3%81%99%E3%81%8F%E8%A7%A3%E8%AA%AC>)記事は参考になりましたか？

（[ご意見・ご感想はこちら](<https://md.tsuyoshikashiwazaki.jp/mailform/>)）

はいいいえ

---

> **Schema.org/Person** (author)
> - name: 柏崎剛
> - url: https://www.tsuyoshikashiwazaki.jp/profile/
>
> **Schema.org/Organization** (site owner)
> - name: SEO対策研究室
> - url: https://www.tsuyoshikashiwazaki.jp/
> - logo: https://www.tsuyoshikashiwazaki.jp/wp-content/uploads/2025/07/cropped-20250722-114641-3bfe11f1.jpg
