高速検索できるHTTPステータスコード一覧
ブラウザ、モバイルアプリ、検索エンジンのクローラーなどがWebサーバーにリクエストを送信するたびに、サーバーは3桁の数字で応答します。これらのHTTPステータスコードは、リクエストの成功や失敗、認証の必要性、別の場所へのリダイレクトなど、処理の結果をクライアントに正確に伝えます。
このツールは、公式のRFC仕様に基づく、標準的なHTTPレスポンスコードを網羅した検索リファレンスです。リスト全体をブラウザに読み込んでローカルでフィルタリングするため、検索は瞬時に行われます。301と302の違いを調べたり、422エラーの意味を確認したりする際に、ページの再読み込みを待つ必要はありません。
HTTPステータスコードの5つのクラス
HTTPステータスコードは、最初の数字によって5つのクラスに分類されます。これらのカテゴリを理解することが、Web通信のトラブルを診断する一番の近道です。
1xx（情報）
サーバーがリクエストを受け取り、処理を継続していることを示します。これは一時的なレスポンスであり、クライアントは最終的なレスポンスを待つ必要があります。例えば、100 Continue は、クライアントにリクエストボディの送信を続けてよいことを伝えます。
2xx（成功）
クライアントのリクエストが正常に受信、理解、受理されたことを意味します。最も一般的なのは 200 OK で、HTTPリクエスト成功時の標準的なレスポンスです。API経由で新しいレコードを作成した場合には、201 Created が返されることがあります。
3xx（リダイレクト）
リクエストを完了するために追加の処理が必要であることをクライアントに伝えます。通常、リクエストされたリソースが移動したことを意味します。301 Moved Permanently は検索エンジンにリンクの更新を促し、302 Found は一時的な移動を示します。
4xx（クライアントエラー）
4xx系のエラーコードは、クライアント側に問題があることを意味します。リクエストの構文エラー、認証の欠如、または存在しないリソースへのアクセス要求などが原因です。ユーザーがURLを打ち間違えたり、API連携で不正なフォーマットのデータを送信したりした場合によく発生します。
5xx（サーバーエラー）
有効なリクエストに対して、サーバーが処理を完了できなかったことを意味します。クライアント側の処理は正しいものの、サーバー内部で問題が発生したか、クラッシュしたか、または現在過負荷状態にあることを示します。
知っておくべき代表的なHTTPエラーコード
HTTPステータスコードは数十種類ありますが、開発者やWebマスターが遭遇するエラーの大部分は以下の代表的なものに限られます。
404ステータスコード (Not Found)
インターネット上で最も有名なエラーと言えます。サーバーがリクエストされたリソースを見つけられなかったことを意味します。リンク切れはユーザーの利便性を損ない、クロールバジェットを無駄にするため、Webサイト管理者にとって404エラーの監視はSEO対策において非常に重要です。
400 Bad Request
リクエストの構文エラーや無効なルーティングなど、クライアント側のエラーが原因でサーバーが処理できない状態です。APIでは、必須パラメータが不足している場合によく返されます。
401 Unauthorized & 403 Forbidden
どちらもアクセス権限に関するエラーです。401 Unauthorized は、リクエストの処理に認証が必要であること（例：APIキーの不足）を意味します。一方、403 Forbidden は、クライアントの身元は特定されているものの、そのリソースへのアクセス権限がないことを示します。
500 Internal Server Error
サーバー側で発生したエラー全般を指す一般的なステータスコードです。サーバーが予期せぬ事態に遭遇し、リクエストを処理できなかったことを意味します。500エラーが発生した場合は、通常、サーバーのアプリケーションログを確認して根本原因を特定する必要があります。
502 Bad Gateway & 503 Service Unavailable502 Bad Gateway は、プロキシとして機能するサーバー（Nginxやロードバランサなど）が、バックエンドサーバーから無効なレスポンスを受け取った場合に発生します。503 Service Unavailable は、アクセス集中による過負荷やメンテナンス中などの理由で、サーバーが一時的にリクエストを処理できない状態を意味します。
API開発のベストプラクティス
REST APIを構築する際、適切なHTTPステータスコードを返すことは、優れた開発者体験のために不可欠です。エラーが発生しているにもかかわらず 200 OK を返してしまうと（いわゆるエラーの「握りつぶし」）、クライアント側でレスポンスボディを解析してリクエストの成否を判断しなければならなくなります。
意味的に最も適切なコードを選ぶために、このリファレンスをご活用ください。例えば、ユーザーがレート制限に達した場合は 429 Too Many Requests を、JSONの形式は正しいもののビジネスロジックのバリデーションに失敗した場合は 422 Unprocessable Content を使用します。
サーバーのルーティング問題を調査する際は、ドメインのレコードを確認できるDNSルックアップツールや、サーバーへのリクエスト元クライアントを判別するユーザーエージェント解析ツールも役立ちます。404エラーを防ぐために検索エンジンのクロールを制御したい場合は、robots.txtジェネレーターをお試しください。