本記事の構成および論理分析にはAI(人工知能)を使用しています。情報の正確性は、システム管理者(UNIXユーザー)による手動検証済みです。
HTTPステータスコードとは?200・301・403・404・500の意味をやさしく解説

Webサイトを見ているとき、ブラウザの裏側では「このページをください」というリクエストがサーバーへ送られています。サーバーはそれに対して、「はい、表示できます」「別の場所に移動しました」「見る権限がありません」「ページが見つかりません」といった返事を返します。
この返事を数字で表したものが、HTTPステータスコードです。
普段はブラウザが自動で処理してくれるため、ステータスコードを意識する機会はあまりありません。しかし、サイトの不具合調査、リダイレクト設定、リンク切れ確認、WordPressのトラブル対応では、ステータスコードを読めると原因を切り分けやすくなります。
HTTPステータスコードとは?
ブラウザとサーバーの「短い返事」
HTTPステータスコードは、ブラウザやcurlなどのクライアントから送られたリクエストに対して、サーバーが返す3桁の数字です。
たとえば、ページが正常に表示できる場合は 200、ページが見つからない場合は 404、サーバー側でエラーが起きた場合は 500 が返されます。
つまり、ステータスコードはサーバーからの短い返事です。本文を読む前に、まず「リクエストがどう扱われたのか」を数字で教えてくれます。
「このページをください」に対してサーバーが数字で返事をする
ブラウザでURLを開くと、ブラウザはサーバーへ「このURLのページをください」と問い合わせます。サーバーは、そのリクエストに対してステータスコードを返します。
正常にページを返せるなら 200 OK。古いURLから新しいURLへ案内するなら 301 Moved Permanently。アクセスを許可しないなら 403 Forbidden。ページが存在しないなら 404 Not Found。サーバー内部で処理に失敗したなら 500 Internal Server Error です。
このように、ステータスコードを見るだけで、サイト側で何が起きているのかを大まかに判断できます。
ステータスコードを見ると、サイトで何が起きているか分かる
ブラウザにページが表示されているときでも、裏側ではリダイレクトが発生していることがあります。反対に、画面上では「ページがありません」と表示されていても、実際には権限やサーバー設定の問題が関係していることもあります。
そのようなとき、ステータスコードを確認すると、見た目だけでは分からないサーバーの反応を確認できます。
まずは全体像|ステータスコードは大きく5つに分かれる
HTTPステータスコードは、先頭の数字によって大きく5つのグループに分かれます。細かいコードをすべて覚える必要はありません。まずは、100番台から500番台までの大まかな意味を押さえておくと理解しやすくなります。
100番台|処理中を表すコード
100番台は、リクエストの処理が続いていることを表すコードです。ブラウザでWebサイトを見ているだけなら、普段あまり意識することはありません。
200番台|成功を表すコード
200番台は、リクエストが成功したことを表します。Webページが正常に表示されたときによく返ってくるのが 200 OK です。
300番台|転送を表すコード
300番台は、別のURLへ転送する必要があることを表します。URLを変更したときや、HTTPからHTTPSへ転送するときに使われます。代表的なコードは 301 Moved Permanently です。
400番台|リクエスト側の問題を表すコード
400番台は、リクエスト側に問題があることを表します。URLが間違っている、ページが存在しない、アクセス権限がない、といった場合に返されます。代表的なものに 403 Forbidden と 404 Not Found があります。
500番台|サーバー側の問題を表すコード
500番台は、サーバー側で問題が起きていることを表します。リクエストされたページ自体は存在していても、サーバー内部の処理に失敗して表示できない場合があります。代表的なコードは 500 Internal Server Error です。
ブログ運営で特によく見るのは200・301・403・404・500
ブログ運営やWordPressのトラブル対応では、すべてのステータスコードを暗記する必要はありません。まずは 200、301、403、404、500 の5つを理解しておくと、多くの場面で役立ちます。
200 OK|ページが正常に表示された
200 OK は、リクエストが正常に処理され、ページやファイルが問題なく返されたことを表します。
普段のページ表示でよく返ってくるコード
ブラウザで記事を開いて、ページが普通に表示されている場合、多くは 200 OK が返っています。画像、CSS、JavaScriptなどのファイルも、正常に取得できていれば同じように200番台のコードが返ります。
サーバーが「問題なく渡せました」と返している状態
200は、サーバーが「リクエストされたものを問題なく返しました」と答えている状態です。Webサイトの通常運転を表すコードだと考えると分かりやすいです。
アクセスログでは正常なアクセスとして記録される
サーバーのアクセスログを見ると、各アクセスに対してステータスコードが記録されています。200 が並んでいれば、そのリクエストは正常に処理されたと判断できます。
ブログ運営では「基本的に問題なし」と考えてよい
記事ページやトップページで 200 OK が返っているなら、基本的には問題ありません。ただし、ログに大量のアクセスがある場合や、意図しないURLで200が返っている場合は、別の観点で確認が必要になることもあります。
301 Moved Permanently|ページの場所が恒久的に変わった
301 Moved Permanently は、リクエストされたURLが別のURLへ恒久的に移動したことを表します。
古いURLから新しいURLへ案内するコード
たとえば、古い記事URLにアクセスしたとき、新しい記事URLへ自動的に転送したい場合に 301 を使います。ユーザーは古いURLを開いても、新しいURLへ案内されます。
一時的な転送ではなく、正式な引っ越しを意味する
301は「このページは今後こちらのURLです」という意味を持ちます。一時的な移動ではなく、正式な引っ越しを表すコードです。
一時的な転送には 302 Found などが使われます。ブログのURLを恒久的に変更する場合は、301を使う場面が多くなります。
ブログのURL変更、スラッグ変更、常時SSL化で使われる
ブログでは、記事のスラッグを変更したとき、カテゴリー構造を変えたとき、HTTPからHTTPSへ統一するときなどに301リダイレクトを使います。
適切に設定しておくと、古いリンクから来た読者を新しいページへ案内できます。検索エンジンに対しても、URLが変わったことを伝えやすくなります。
見かけたら新しいURLへ正しく転送されているか確認する
301が返っている場合は、転送されること自体よりも、転送先が正しいかを確認することが大切です。古いURLから関係のないページへ飛んでいないか、リダイレクトが何度も連続していないかを確認します。
403 Forbidden|存在するけれど見ることができない
403 Forbidden は、サーバーがリクエストを理解したものの、アクセスを許可しない場合に返されます。
サーバーはリクエストを理解しているが、アクセスを許可していない
403は、URLの意味が分からないという状態ではありません。サーバーはリクエストを理解しています。しかし、そのリソースを表示する権限がないため、アクセスを拒否しています。
ファイル権限、アクセス制限、WAF設定で発生することがある
403は、ファイルやディレクトリの権限設定、Webサーバーのアクセス制限、セキュリティプラグイン、WAFなどが原因で発生することがあります。
WordPressでは、管理画面や特定のファイルへのアクセス制限、セキュリティ系プラグインの設定によって403が出る場合もあります。
「あるけれど見せない」という状態
403は「そこにあるかもしれないが、あなたには見せられません」という返事に近いコードです。ページやファイルの存在そのものよりも、アクセス許可の問題に注目します。
見かけたら権限設定やアクセス制限を確認する
403が出た場合は、ファイル権限、ディレクトリ権限、.htaccess、Webサーバーの設定、セキュリティプラグイン、WAFのブロック履歴などを確認します。
404 Not Found|ページが見つからない
404 Not Found は、リクエストされたURLに対応するページやファイルが見つからない場合に返されます。
URLの入力ミスやリンク切れで発生する
URLを間違えて入力した場合や、古いリンクをクリックした場合、リンク先のページが存在しなければ404になります。
ブログでは、記事のURLを変更したあとに古いリンクが残っている場合や、外部サイトから古いURLへリンクされている場合にも発生します。
記事の削除やスラッグ変更でも起こる
記事を削除した場合、そのURLへアクセスすると404になります。また、記事のスラッグを変更したあとにリダイレクトを設定していない場合も、古いURLでは404が返ります。
「探したけれど見つからない」という状態
404は、サーバーが指定されたURLに対応するものを見つけられなかった状態です。403が「見せない」なのに対して、404は「見つからない」と考えると違いが分かりやすくなります。
ブログ運営では放置せず、リンク修正やリダイレクトを検討する
404が少数であれば大きな問題にならないこともありますが、重要な記事や内部リンクで404が発生している場合は修正した方がよいです。
削除した記事に代わるページがあるなら301リダイレクトを設定し、単純なリンクミスであればリンク元を修正します。
403と404の違い|「見せない」と「見つからない」
403 と 404 はどちらもページが表示されない場面で見かけますが、意味は違います。
403は存在するがアクセスが拒否されている
403は、サーバーがリクエストを理解したうえで、アクセスを拒否している状態です。原因を調べるときは、権限、認証、アクセス制限、セキュリティ設定を確認します。
404は指定された場所にページが見つからない
404は、指定されたURLに対応するページやファイルが見つからない状態です。原因を調べるときは、URLの入力ミス、リンク切れ、記事の削除、スラッグ変更などを確認します。
セキュリティ上の理由で、存在を隠すために404を返す場合もある
実際の運用では、存在を知られたくないリソースに対して、あえて404を返す設計もあります。そのため、404だから必ず「物理的に存在しない」とは限りません。
ただし、ブログ運営で通常見る404の多くは、URLの間違い、リンク切れ、削除済み記事などが原因です。
ブログ運営ではリンク切れなのか、権限や制限の問題なのかを切り分ける
ページが表示されないときは、まずステータスコードを確認します。403ならアクセス制限の問題、404ならURLやリンクの問題を疑う、というように切り分けると調査しやすくなります。
500 Internal Server Error|サーバー側で何かが失敗した
500 Internal Server Error は、サーバー内部でエラーが発生し、リクエストを正常に処理できなかったことを表します。
サーバー内部で処理に失敗した状態
500は、クライアント側のURL入力ミスというより、サーバー側の処理が途中で失敗している状態です。プログラムのエラー、設定ミス、権限の問題、サーバー環境の問題など、原因はいくつか考えられます。
404とは違い、ページがないのではなく処理が止まっている
404は「ページが見つからない」状態ですが、500は「サーバー側の処理がうまくいかなかった」状態です。
つまり、URLが正しくても500になることがあります。ページの存在確認だけでなく、サーバーのログやアプリケーションのエラー内容を確認する必要があります。
WordPressではプラグインやテーマの不具合で起こることがある
WordPressでは、プラグインの不具合、テーマのPHPエラー、PHPバージョンの不一致、.htaccess の記述ミスなどで500が出ることがあります。
直前にプラグインを更新した、テーマを編集した、PHPの設定を変更した、といった場合は、その変更が原因になっていないか確認します。
見かけたら直前に変更した設定、プラグイン、テーマ、PHPエラーを確認する
500が出た場合は、まず直前の変更を思い出すことが大切です。そのうえで、サーバーのエラーログ、WordPressのデバッグログ、プラグインやテーマの状態を確認します。
500は原因が画面に表示されないことも多いため、ログを確認する習慣が役立ちます。
200・301・403・404・500の違いを表で整理する
ここまで紹介した5つのステータスコードを、意味、よくある場面、確認ポイントで整理すると次のようになります。
| コード | 意味 | よくある場面 | 確認ポイント |
|---|---|---|---|
| 200 | 正常に成功 | ページが普通に表示される | 基本的には問題なし |
| 301 | 恒久的な転送 | URL変更、HTTPS化、スラッグ変更 | 転送先が正しいか確認 |
| 403 | アクセス拒否 | 権限不足、アクセス制限、WAF | 権限や制限設定を確認 |
| 404 | 見つからない | リンク切れ、削除済み記事、URLミス | リンク修正・リダイレクト |
| 500 | サーバー内部エラー | PHPエラー、プラグイン不具合、設定ミス | ログや直前の変更を確認 |
正常・転送・拒否・未発見・サーバーエラーの違い
ざっくり言えば、200 は成功、301 は転送、403 は拒否、404 は未発見、500 はサーバーエラーです。
細かい意味を忘れてしまったときも、この5つの分類を思い出せば、どこから調べればよいか判断しやすくなります。
それぞれの意味、よくある場面、確認ポイントを並べる
ステータスコードは、数字そのものを暗記するよりも「どんな場面で出るのか」と一緒に覚える方が実用的です。
ブログ運営では、404を見たらリンク切れ、500を見たらサーバー側のエラー、301を見たら転送先、というように考えると調査の入り口が見えてきます。
ブログ運営でどのコードを優先して対応すべきか整理する
すべてのステータスコードに同じ優先度で対応する必要はありません。たとえば、通常の200は対応不要です。一方で、重要なページの404や500は早めに確認した方がよいです。
301は設定内容が正しければ問題ありませんが、転送先が間違っていると読者を迷わせてしまいます。403は意図した制限なのか、設定ミスなのかを確認します。
curlでステータスコードを確認してみる
ステータスコードは、ブラウザの開発者ツールでも確認できますが、ターミナルでは curl を使って手軽に確認できます。
curl -Iでヘッダー情報を確認する
curl -I を使うと、レスポンス本文ではなくヘッダー情報を確認できます。
curl -I https://example.com/実行すると、次のように先頭付近にステータスコードが表示されます。
HTTP/2 200ここに 200、301、403、404、500 などの数字が表示されます。
ステータスコードだけを表示する方法
ステータスコードだけを見たい場合は、次のように実行できます。
curl -o /dev/null -s -w "%{http_code}\n" https://example.com/このコマンドでは、ページ本文を表示せず、ステータスコードだけを出力します。
200複数のURLを確認したいときや、スクリプトでチェックしたいときにも使いやすい形です。
リダイレクト先まで追いかけて確認する方法
リダイレクトを追いかけたい場合は、-L オプションを使います。
curl -I -L https://example.com/301 や 302 が返ったあと、最終的にどのURLへ到達し、どのステータスコードになるのかを確認できます。
URL変更やHTTPS化を確認するときは、リダイレクト先まで見ることが大切です。
ブラウザでは見えないサーバーの返事をターミナルで確認する
ブラウザでは、リダイレクトが自動で処理されるため、途中でどのステータスコードが返っているのか分かりにくいことがあります。
curl を使うと、サーバーの返事を直接確認できます。サイトの状態を調べるときは、ブラウザの表示だけでなく、ステータスコードも一緒に見ると判断しやすくなります。
ブログ運営でステータスコードを見かけたときの考え方
ステータスコードは、エラーの有無だけでなく、次に何を確認すればよいかを教えてくれます。
200は正常なので基本的に対応不要
200 は正常に表示できている状態です。通常は対応不要です。ただし、意図しないURLで200が返っている場合は、重複ページや不要な公開状態になっていないか確認してもよいでしょう。
301は転送先が正しいか確認する
301 は転送のコードです。古いURLから新しいURLへ正しく移動できているか、転送が何度も連続していないかを確認します。
403は権限やアクセス制限を確認する
403 はアクセス拒否です。意図した制限であれば問題ありませんが、本来見せたいページで403が出ている場合は、権限設定やセキュリティ設定を確認します。
404はリンク切れや削除済み記事を確認する
404 はページが見つからない状態です。内部リンク、外部からのリンク、削除済み記事、スラッグ変更などを確認します。必要に応じてリンク修正や301リダイレクトを設定します。
500はサーバー側のエラーとしてログや直前の変更を確認する
500 はサーバー側のエラーです。WordPressであれば、直前に更新したプラグインやテーマ、PHPエラー、.htaccess、サーバーのエラーログを確認します。
500は画面だけでは原因が分かりにくいため、ログを見ることが重要です。
まとめ|ステータスコードはサーバーからの短い返事
HTTPステータスコードは、ブラウザやcurlからのリクエストに対して、サーバーが返す短い返事です。
200 は成功、301 は転送、403 は拒否、404 は未発見、500 はサーバーエラーを表します。
数字だけを見ると難しそうに感じますが、それぞれの意味を「サーバーからの返事」として考えると理解しやすくなります。
Webサイトやブログを運営していると、リンク切れ、リダイレクト、アクセス制限、サーバーエラーに出会うことがあります。そのときにステータスコードを確認できると、何が起きているのかを冷静に切り分けられます。
まずは、よく使う5つのコードから覚えておきましょう。そして、必要なときには curl を使って、ブラウザでは見えにくいサーバーの返事を確認してみてください。









