404 Not Foundエラーとは？意味と対処方法

このエラーの意味と見分け方

• 同じサイトの他のページは表示されるのに、ページに404、Not Found、またはカスタムのページ未検出メッセージが表示される。
• ホスト名とサーバーには到達できるにもかかわらず、APIリクエストが404を返す。
• デプロイ、移行、パーマリンクの変更、アプリケーションの更新後に、以前は動作していたURLが404を返し始める。
• 検索結果、ブックマーク、内部リンクから、利用できなくなったコンテンツに誘導される。
• Webサーバー、リバースプロキシ、またはリライト設定の変更後に、関連のない複数のパスが失敗する。

可能性の高い順の主な原因

考えられる原因（一般的なものから順に）：

1. URLの入力ミスまたは不完全なURL： スペルミス、パスセグメントの欠落、大文字と小文字の違いにより、存在しないリソースを指している。
2. 削除または移動されたコンテンツ： ページやファイルが、関連するリダイレクトなしに削除、名前変更、移動されている。
3. 壊れた内部リンクまたは外部リンク： 特に移行やURL構造の変更後も、リンクが古いURLを参照している。
4. アプリケーションルートの欠落： デプロイされたアプリケーションに、要求されたページやAPIエンドポイントの定義がない。または、パスで誤ったAPIバージョンやプレフィックスを使用している。
5. 誤ったリライトまたはパーマリンクルール： Apache、Nginx、フレームワークのルーター、CMS設定が、有効なパスを意図したハンドラーに渡せていない。
6. デプロイまたはドキュメントルートの問題： ファイル、ルート、ビルド出力がデプロイされていない。または、サーバーが想定とは異なるディレクトリを配信している。
7. リバースプロキシの不一致： プロキシまたはゲートウェイがリクエストを誤ったアプリケーションやバックエンドに送り、そのパスが認識されていない。
8. 大文字と小文字が区別されるパスの違い： ある環境では動作するURLでも、大文字と小文字の表記がルートやファイル名と一致しない場合、ケースセンシティブなファイルシステムやサーバーでは失敗することがある。

修正方法

サイトを訪問している場合

1. スペル、大文字と小文字、ハイフン、ファイル拡張子、すべてのパスセグメントを含め、アドレスを再確認します。
2. 最後のパスセグメントに問題がありそうな場合は削除するか、サイトのトップページと組み込み検索から移動して現在のページを探します。
3. ブックマークや検索結果からページにアクセスした場合は、同じURLを繰り返し再読み込みするのではなく、コンテンツの新しいバージョンを探します。
4. 信頼できるリンクが壊れている場合は、正確なURLと、そのリンクを見つけたページを添えてサイト所有者に報告します。

サイトを管理している場合

1. 失敗するリクエストを確認します。 正確なパス、HTTPメソッド、ホスト、クエリ文字列、障害発生時刻を記録します。問題が1つのURL、1つのルート群、サイト全体のいずれに影響しているかを確認します。
2. リソースが存在すべきか判断します。 コンテンツレコード、デプロイ済みファイル、アプリケーションのルート定義を確認します。意図的に削除したリソースは、本当に関連性のある置き換え先がない限り、通常は404のままにします。
3. 失敗するパスと動作するパスを比較します。 大文字と小文字、末尾のスラッシュ、ファイル拡張子、ロケールプレフィックス、APIバージョン、ルートプレフィックス、クエリ処理の違いを確認します。
4. ルーティングとリライト設定を調べます。 アプリケーションルーター、CMSのパーマリンク、Webサーバーのルール、ドキュメントルート、リバースプロキシのマッピングを確認します。設定変更は、適切な権限を持ち、現在の設定を保存し、他のルートへの影響を検討したうえで行います。
5. デプロイを確認します。 期待されるファイル、ビルド出力、ルート、静的アセットがデプロイ済みリリースに含まれていることと、稼働中のサーバーが意図したリリースを使用していることを確認します。
6. ログを確認します。 Webサーバー、プロキシ、アプリケーションのログを使い、どのコンポーネントが404を生成したか、リクエストが想定したバックエンドに到達したかを判断します。ログを共有する前に、認証情報、トークン、個人データを削除またはサニタイズします。
7. リンクまたはリダイレクトを修正します。 内部リンクを現在のパスに更新します。コンテンツが恒久的に移動した場合は、権限を得たうえで、最も近い同等の移動先への恒久リダイレクトを設定します。関連のない未検出URLをトップページへリダイレクトしないでください。
8. エラーレスポンスを確認します。 元の未検出URLにリクエストし、HTTPステータス404を返すことを確認します。カスタムエラーページは有用ですが、存在しないリソースを誤解を招く成功レスポンス200に変えてはいけません。
9. 影響を受けたパスを再テストします。 変更後、元のURL、存在する場合は置き換え先URL、代表的な正常ルート、関連するAPIメソッドを確認します。その後も404ログを監視し、残っている壊れたリンクを特定します。

予防と修正確認

• 移行、リニューアル、URL構造の変更の前後に、リンク切れのチェックを実行します。
• 重要なコンテンツを恒久的に移動する場合は、文書化したリダイレクトを維持します。
• 各デプロイの一環として、代表的なページ、アセット、APIルートをテストします。
• パスの大文字と小文字、末尾のスラッシュ、ロケールプレフィックス、APIバージョンを明示的なルーティング上の判断として扱います。
• Webサーバー、リバースプロキシ、アプリケーションのルーティング設定を変更管理下に置きます。
• 頻繁にリクエストされる404パスを監視し、壊れた内部リンク、古い連携、繰り返し発生するユーザーリクエストを特定します。
• 継続的な提供やインデックス登録を意図するコンテンツには、安定したURLを維持します。
• カスタムエラーテンプレートが正しいHTTPステータスを保持するようにします。

よくある質問