404エラーとは？閲覧者・運営者別の原因と対処法

404エラー（404 Not Found）は、リクエストした場所に現在のページが見つからない、またはサーバーがその存在を開示しないことを表します。閲覧者はURLと公式の入口を確認します。運営者は、そのページを復元すべきか、対応する移転先へ転送すべきか、削除したまま404または410で返すべきかを、ページの意図に合わせて判断します。

404をすべてトップページへ転送することや、見た目だけ正常なページに変えることは、適切な対応とは限りません。このページでは、閲覧者の確認、運営者の判断、修正後の検証を分けます。アクセス拒否の403とは意味が異なるため、表示がForbiddenの場合は403エラーの対処法を参照してください。

404・410・ソフト404の違い

RFC 9110の404の定義は、その状態が一時的か恒久的かまでは示しません。410 Goneは、資源が利用できなくなり、その状態が恒久的である可能性が高いと運営者が分かっている場合に使います。404という表示だけで「完全に削除された」とは断定できません。

Googleは、429以外の4xxを同じ扱いで処理します。404を410へ変えるだけで必ず早く検索から消える、という手順にはできません。ソフト404も単に「200でNot Foundと表示したページ」だけを意味せず、Google側の判定です。詳しくはGoogleのHTTPステータスとエラーの公式説明を確認します。

閲覧者が最初に確認すること

1. コピーしたURLが途中で切れていないか、全角記号や余計な文字が混ざっていないかを確認する。
2. サイトの公式トップ、ブログ一覧、サイト内検索から同じ内容を探す。
3. 古いブックマークや検索結果だけで失敗するのか、公式のリンクでも失敗するのかを記録する。
4. ログインが必要なページなら、指定された正規の入口とアカウントを確認する。
5. 見つからなければ、URL・発生日時・直前の操作を運営者へ伝える。

削除されたページを何度も再読み込みしても復元はできません。似た名前の別サイトへ個人情報を入力したり、共有URLの識別子を推測して変更したりしないでください。外部リンクから移動してエラーになった場合は、リンク元とリンク先のどちらに修正が必要か、閲覧者側では判断できないこともあります。

申し込みや決済の後に404になった場合、処理自体は完了している可能性があります。確認メールや履歴を調べ、結果が不明なら再送信の前に問い合わせます。完了画面が見つからないことと、申し込みが保存されていないことを同一視しません。

運営者は「残す・移す・削除する」を先に決める

同じ404でも、公開すべきページが設定ミスで消えた場合と、販売終了して代替ページもない場合では対応が異なります。記事の古さや検索流入の少なさだけで、転送先を決めないようにします。利用者がそのURLで何を期待したかを基準にします。

架空の例として、旧記事「分析の始め方」を同じ内容の新記事へ移したなら、旧URLから新URLへの恒久転送が候補です。一方、終了した個別キャンペーンに相当する内容がなければ、トップページへ送り続けるより、終了を伝える404ページと通常の案内リンクが適切な場合があります。

リダイレクトとcanonicalは同じ処置ではない

リダイレクトは閲覧者やクローラーを別URLへ送ります。canonicalは、類似・重複ページの代表URLを検索エンジンへ伝えるシグナルで、ブラウザを移動させるものではありません。404のページへcanonicalを足せば、消えた本文が復活するわけではありません。

恒久転送はGoogleにとって強い正規化のシグナルですが、順位や評価がすべて同じ状態で引き継がれると保証されるものではありません。手段の使い分けは301・302リダイレクトの違い、代表URLの整理はcanonicalタグの確認手順で確認します。

修正の優先順位を付けるために集める情報

まず公開を意図したURLと、削除・移転を意図したURLの台帳を分けます。次にサイト内リンク、サイトマップ、サーバーログ、Search Console等から、どこからそのURLへ到達しているかを調べます。ツールによって観測対象や更新時間が異なり、Search Consoleに行がないURLも存在し得ます。

• 現在公開する予定の重要な商品・申し込み・記事ページか。
• サイト内のメニューや本文からリンクされているか。
• 同じ誤URLをテンプレートや自動生成処理が大量に作っていないか。
• 外部リンクや検索表示があり、利用者が困っているか。
• 削除済みとして意図した応答か、誤公開・誤削除か。

優先するのは、公開するはずの重要ページの復旧と、現行の内部リンクの修正です。存在しないランダムなパスがログに少数出ることだけを理由に、すべてのURLを作る必要はありません。Google Analytics 4が通常の計測だけで全ページのHTTPステータスを自動収集するわけでもないため、ページタイトルだけで404件数を確定しません。

担当者へ渡す修正依頼の例

架空の依頼例は「記事一覧の2ページ目から、公開中の導入記事へ進むリンクが404になります。記事台帳では公開継続です。本文はCMSに残っています。期待する結果は元URLの200と本文表示で、別記事への転送ではありません」です。対象のURLだけでなく、どの入口で再現したかと公開の意図を添えると、ルーティング、公開状態、リンク生成のどこを調べるかが明確になります。

移転を依頼する場合は、旧URLと新URLを一対で書き、新ページが内容上の代替になっているかを編集担当が確認します。対応期限、実装担当、確認担当も分けて残します。実装が終わった後に担当者の端末で一度開けただけでは、公開状態や全体のリンク更新まで完了したとは言えません。変更した範囲に合わせて、必要な確認項目を依頼時にそろえておきます。

カスタム404ページは、見た目と応答を別々に確認する

利用者向けの404ページには、見つからないことの説明、トップや一覧へ戻るリンク、利用可能なサイト内検索、必要なら問い合わせ先を置きます。元のURLを勝手に別の目的へ置き換えるより、利用者が次の行動を選べる構成にします。サイトと同じデザインでも構いませんが、通常ページのように200を返していないかを確認します。

確認例は、公開中URL、削除済みURL、任意の存在しないURL、移転した旧URLの4種類です。ブラウザに見える文言だけでなく、管理者がレスポンスのHTTPステータス、最終到達先、本文を確認します。ログイン時だけ200になる等の差があるなら、公開範囲と実装の意図を見直します。

CMSやホスティングの設定で、すべての未知のURLがアプリの入口へ送られる場合があります。その構成自体を見て直ちに不具合と決めず、存在しない記事で実際に何を返すかを確認してください。ルーターの表示とサーバーの応答が食い違うと、利用者にも検索エンジンにも分かりにくくなります。

修正後は内部リンク・サイトマップ・検索状態を追う

記事を移転した場合は、サイト内リンクを旧URL経由のまま残さず、正しい新URLへ更新します。XMLサイトマップは公開を意図する正規URLにそろえます。作成・送信・個別確認の違いはサイトマップの作成と確認を参照してください。

Search Consoleの古い404表示は、修正後すぐに消えるとは限りません。対象URLの最終クロール日時と現在の応答を分けて確認します。削除を意図したページの404は、そのまま正しい状態として残る場合があります。エラー件数をゼロにすることより、公開意図と実際の応答・案内が一致していることが大切です。

修正記録には、対象URL、判断理由、転送先がある場合はそのURL、担当者、確認日、期待する応答、実際の結果を残します。復旧後のクリックや問い合わせを追う場合も、404対策だけが変化の原因だと断定せず、他の施策や季節性と分けて評価します。