HTTPQUERY
日本語

404 Not Found

使い方

404 Not Found エラーが届いたとき、そのステータスはリソースが恒久的に利用できないのか、一時的に利用できないのか、あるいは一度も存在しなかったのかを示しません。このエラーは打ち間違えた URL に起因することが最も多く、まだ開発中の一連のリソースを扱う開発者が頻繁に目にします。

404 Not Found を返すアドレスへのリンクは、一般にデッドリンクまたはリンク切れと呼ばれます。このステータスは、サーバーがリソースの存在を認めたくない場合にも使われてきました。

指定されたアドレスにリソースがかつて存在したものの恒久的に削除されたとサーバーが把握している場合は、410 Gone ステータスのほうが情報量に富みます。

このエラーはエンドユーザーが非常に頻繁に目にするため、多くのサーバーは自サイトにとって説明的で適切なカスタムエラーページを使用しています。

注意

404 はクライアントがブロックされていることを意味しません。ブロックされている場合は 403 Forbidden が生成されます。一部のサーバーは、リソースの存在を隠すために 403 ではなく 404 を返します。404 は恒久性を示しません。そのリソースは後から現れるかもしれません。恒久的な削除の場合、サーバーは 410 Gone を返します。

SEO への影響

Google のような検索エンジンは、404 ステータスを返す URL をインデックスしません。以前にインデックスされていた URL がこのステータスコードを返すようになると、検索結果から削除されます。このコードを返すページはクロールバジェットを消費しません。Google は 404 と 410 をまったく同じように扱います。どちらも同じ速度でコンテンツをインデックスから削除します。Bingbot は 404 をコンテンツ削除のシグナルとして扱い、その後の再クロールでステータスを確認してからその URL のインデックスを解除します。適切な 404 ではなくエラーコンテンツを伴う 200 を返すとソフト 404 が生じ、クロールバジェットを浪費し、そのサイトのサーバーシグナルに対する信頼を損ないます。

例

クライアントがリソースを要求し、指定されたアドレスにそのリソースが存在しないため、サーバーは 404 Not Found で応答します。

リクエスト

GET /documents/secret-formula.pdf HTTP/1.1
Host: example.com

レスポンス

HTTP/1.1 404 Not Found
Content-Type: text/html
Content-Length: 216

<html>
  <head>
    <title>Resource Not Found</title>
  </head>
  <body>
    <p>The requested resource was not found.
    Check the spelling of the address.</p>
  </body>
</html>

対処方法

404 Not Found は、要求されたアドレスにリソースが存在しないことを意味します。

URL の綴りとパスを検証します。パス、ファイル名、クエリ文字列の打ち間違いが最も多い原因です。アドレスのすべてのセグメントを入念に確認します。手で入力するのではなく、元のリンクからパスを直接コピーします。

大文字小文字の区別を確認します。Linux ベースのサーバーは /Page と /page を異なるパスとして扱います。元の URL の大文字小文字に正確に合わせます。Windows ベースの IIS サーバーはデフォルトで大文字小文字を区別しないため、IIS 上の 404 は本当に存在しないリソースを指しています。

末尾のスラッシュの欠落に注意します。一部のサーバーは /path と /path/ を区別します。末尾のスラッシュを追加または削除して再試行します。nginx と Apache は、try_files や DirectorySlash の設定によって末尾のスラッシュの扱いが異なります。

リソースがサーバー上に存在することを確認します。ファイルまたはルートがデプロイされ、アクセス可能であることを検証します。SSH でサーバーにログインし、想定されるドキュメントルートのパスにファイルが存在することを確認します。nginx では、一致する location ブロック内の root または alias ディレクティブを確認します。Apache では、仮想ホスト内の DocumentRoot を確認します。

移動したコンテンツには 301 または 308 リダイレクトを設定します。リソースが新しいアドレスへ移動する際は、リンク切れを防ぐために古い URL をリダイレクトします。nginx では次のようにします。

location = /old-path {
    return 301 /new-path;
}

Apache の .htaccess では次のようにします。

Redirect 301 /old-path /new-path

サーバーのリライトルールを確認します。Apache の mod_rewrite ルール、または nginx の try_files と location ブロックを見直します。設定を誤ったリライトは、有効なパスへのリクエストを黙って落としてしまいます。ルールの評価を追跡するため、リライトのログ出力を有効にします。Apache では、一時的に LogLevel alert rewrite:trace3 を設定します。

IIS 上で MIME タイプとハンドラーマッピングを検証します。ファイル拡張子に登録された MIME タイプやハンドラーマッピングがない場合、IIS は 404.3 を返します。IIS マネージャーまたは web.config を通じて、不足している MIME タイプを追加します。

<staticContent>
  <mimeMap fileExtension=".json"
    mimeType="application/json" />
</staticContent>

DNS と仮想ホストの設定を確認します。ドメインが誤ったサーバーを指していたり、仮想ホストのエントリが欠落していたりすると、すべてのパスで 404 になります。DNS の A/CNAME レコードが正しいサーバー IP に解決されること、そしてサーバーに一致する server_name(nginx)または ServerName(Apache)ディレクティブがあることを検証します。

クローラーでリンク切れを監査します。サイトクローラーを実行して、サイト全体の 404 レスポンスをすべて検出します。壊れた内部リンクを修正し、移動したコンテンツの再インデックスを促進するため、更新した XML sitemap を検索エンジンへ送信します。リンク切れを見つけるツールには、Google Search Console(カバレッジレポート)、Screaming Frog、Ahrefs Site Audit、コマンドラインでの確認に使う wget —spider などがあります。

コードリファレンス

.NET

HttpStatusCode.NotFound

Rust

http::StatusCode::NOT_FOUND

Rails

:not_found

Go

http.StatusNotFound

Symfony

Response::HTTP_NOT_FOUND

Python3.5+

http.HTTPStatus.NOT_FOUND

Java

java.net.HttpURLConnection.HTTP_NOT_FOUND

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_NOT_FOUND

Angular

@angular/common/http/HttpStatusCode.NotFound