404ページは誰のためにあるか
404は単なる装飾画面ではありません。同じ応答でも、利用者、検索エンジン、運用担当者が受け取る情報は異なります。目的を分解すると、必要な要素と不要な演出が見えます。
利用者の復帰
ページが見つからない事実を簡潔に伝え、次に選べる経路を提示します。原因を利用者の入力ミスと決めつけません。
例:説明 + ホーム + 親カテゴリ
クローラーへの意味
本文がきれいでも、200を返せば「見つかったページ」と伝わります。存在しないURLにはHTTP 404または適切な別statusを返します。
例:HTTP/2 404
運用上の診断
どのURLで、どの参照元から、何回起きたかを安全に記録し、壊れた内部リンクと外部からの誤記を分けます。
例:path・referrer・timestamp
アクセシビリティ
見出しで状況を伝え、リンク先が文脈から分かる文言にします。色だけに依存せず、キーボードのフォーカスも見える状態にします。
例:「サーバー記事一覧へ戻る」
情報の保護
ファイルパス、スタックトレース、内部ホスト名を表示しません。入力されたURLを本文へ出す場合は必ずエスケープします。
例:内部例外は公開しない
改善の材料
404件数そのものではなく、利用者が実際に到達した上位URLと発生経路を見ます。修正後は同じ条件で再確認します。
例:上位URL × 内部参照元
HTTP statusはURLの事実で選ぶ
「SEOに良さそう」ではなく、リソースの現在の状態を表すstatusを選びます。RFC 9110では404は現在の表現が見つからないことを示し、恒久的か一時的かまでは断定しません。恒久的な削除だと分かっている場合は410を選べます。
200 OK
HTTP/2 200
要求されたページが正常に存在するときに返します。エラー文を表示するだけのページへ200を返すと、soft 404と判定される原因になります。
301・308
Location: /new-url/
同じ目的を満たす関連性の高い移転先へ恒久的に移した場合に使います。削除URLをすべてホームへ送る用途ではありません。
302・307
一時的な転送
元URLへ戻す予定があり、一時的に別の場所を案内するときに使います。恒久移転の代用として漫然と残しません。
404 Not Found
HTTP/2 404
要求されたURLに現在の表現がない、または存在を開示しない場合に使います。削除が恒久的か不明でも選べます。
410 Gone
HTTP/2 410
以前は存在したリソースが利用できなくなり、その状態が恒久的だと分かっている場合のstatusです。Googleは現在、410を404と同様に扱うと説明しています。
5xx
HTTP/2 503
アプリや依存先の障害で一時的に配信できない場合はサーバーエラーです。障害を404に置き換えると、存在しないURLと誤って伝わります。
401・403と404を混同しない
認証が必要なら401、権限がなければ403が基本です。セキュリティ上、リソースの存在を開示しないため404を選ぶ場合は、全体の認可方針として一貫させます。
リダイレクトするURL、404を返すURL
リダイレクトは404を隠す道具ではありません。旧URLの目的と新URLの目的が十分近いときだけ、利用者を直接移動させます。代替がなければ404または410を返すほうが事実に合います。
リダイレクトを検討する
- URLを変更し、同じ内容の新URLが存在する
- 統合先が旧ページの主要な目的を引き継いでいる
- よくあるURLの誤記に明確な正解がある
- 恒久移転なら301または308を選び、転送先を一対一で管理できる
404・410を返す
- 削除済みで、同じ目的を満たす代替ページがない
- 一度も存在しないランダムなURLや探索アクセスである
- 削除が恒久的か分からないため404が事実に合う
- 恒久削除だと明確に管理でき、410を使う方針がある
避ける実装：すべてをホームへ転送
関係のないホームやカテゴリへ一括転送すると、利用者は目的の情報が見つからず、検索エンジンからsoft 404として扱われる可能性があります。壊れた内部リンクは、転送規則を足す前にリンク元を修正します。
404ページの実装手順
テンプレート作成だけで完了にせず、ルーティング、status、関連データ、ログ、テストを同じ変更として扱います。
- 1
対象URLを分類する
移転、統合、恒久削除、存在しないURL、一時障害に分けます。アクセス数だけでなく、内部リンク、sitemap、外部参照元、代替ページの関連性を確認します。
- 2
catch-allで404本文を描画する
ルーターやWebサーバーの未一致処理から共通テンプレートを描画し、元の要求URLを維持したままstatus 404を返します。/404/へ転送して200を返す構成は避けます。
- 3
HEADとGETを一致させる
GETで本文と404を返し、HEADでも同じ404を返せることを確認します。CSS、フォント、画像など404本文が必要とするアセットは正常に配信します。
- 4
内部リンクとsitemapを直す
存在しないURLへの内部リンクを修正し、XML sitemapから削除します。リンク元を残したまま404ページの導線だけ改善しても、原因は解消しません。
- 5
安全なログを設計する
path、時刻、参照元、必要最小限のUser-Agentを記録し、検索語やトークンを含むqueryを不用意に保存しません。保持期間と閲覧権限も決めます。
- 6
キャッシュ方針を明示する
404応答はキャッシュされる場合があります。短期的な公開遅延があり得るURLと、恒久的な不存在URLで同じ設定を無条件に使わず、再検証可能な方針にします。
エラーテンプレート自身が失敗しないようにする
404画面がデータベースや外部APIへ強く依存すると、障害時にさらに5xxを起こします。主要文言と最低限の導線は、依存先がなくても描画できる構成にします。
statusと画面を検証する
見た目の確認だけではsoft 404を見逃し、statusだけの確認では利用者が戻れない画面を見逃します。URL、レスポンス、操作、監視を一つのチェックリストで確認します。
コマンドでstatusを確認
curl -I https://example.com/not-found または curl -s -o /dev/null -w '%{http_code}' URL で404を確認します。転送がある場合は各hopのstatusとLocationを記録します。
既知の正常URLと比較
正常ページは200、移転URLは想定した301・308、存在しないURLは404になることを同じ環境で確かめます。サーバー障害時は5xxを保持します。
ブラウザで操作
Chrome、Edge、Safariで主見出し、ホーム、親カテゴリ、戻る操作を確認します。390pxとデスクトップ幅で横スクロール、重なり、フォーカス消失がないか見ます。
キーボードと読み上げ順
Tabで全リンクへ到達でき、フォーカスが見え、見出しから説明、主要リンクの順に意味が通ることを確認します。リンク文言単独でも目的が推測できるようにします。
Search Consoleで確認
ページのインデックス登録レポートでNot foundとSoft 404を確認し、代表URLはURL検査で調べます。レポートは例示・集計であり、全URLの完全一覧とは限りません。
発生経路を監視
実利用者が到達した404を、URLと参照元で優先順位付けします。修正前後で内部参照元からの到達が減ったかを確認し、順位や売上への直接効果は断定しません。
公開前の停止条件
存在しないURLが200になる、正常URLまで404になる、404画面の主要アセットが404になる、主要リンクが動かない、モバイルで本文が横にはみ出す場合は公開を止めて修正します。
完成イメージ：情報を絞った404画面
次の例は、状況、主要な復帰先、関連する選択肢、実際のstatusを一画面で確認できる構成です。画面内の「404」表示だけでは不十分で、サーバー応答も404である必要があります。
根拠資料
仕様と検索エンジンの挙動は変更される可能性があります。実装時は一次資料の最新版も確認してください。
404エラーページのよくある質問
404エラーがあると検索順位が下がりますか？
存在すべきでないURLが正しく404を返すこと自体は、Googleの説明では通常、サイトのインデックス登録やランキングへ悪影響を与えません。修正すべきなのは、存在するはずのURLが404になる、内部リンクやsitemapが404を指す、エラー本文なのに200を返すといった不整合です。
404と410はどう使い分けますか？
現在の表現が見つからず、恒久的か不明なら404で構いません。以前存在したリソースが恒久的に利用できないと分かっているなら410を選べます。Googleは現在、410を404と同様に扱うと案内しています。
存在しないURLをすべてホームへ転送してよいですか？
推奨しません。旧URLと同じ目的を満たす転送先がある場合だけ301または308を検討します。関係のないホームへの一括転送は利用者を迷わせ、soft 404として扱われる可能性があります。
404ページにnoindexは必要ですか？
正しい404 statusが主なシグナルであり、200とnoindexを404の代用にしてはいけません。エラーテンプレートへnoindexを付ける運用より先に、未存在URLが確実に404を返すことを検証してください。
404ページに検索フォームを置くべきですか？
サイト内検索が実際に動き、適切な結果を返せる場合は選択肢になります。保守できない検索フォームより、ホームや親カテゴリなど確実に使えるリンクを優先します。
404 URLをrobots.txtでブロックすべきですか？
存在しないURLをrobots.txtで遮断すると、クローラーが404応答を確認できません。Googleも無効なURLはrobots.txtでブロックせず、適切な404を返すよう案内しています。
あわせて確認したい記事
404は失敗画面ではなく、URLの状態を正しく終える画面
まず移転先の有無と削除の性質を分類し、statusを決めます。その後に、状況説明、ホーム、親カテゴリなど少数の復帰導線を設計します。最後にコマンドと実ブラウザでstatusと操作を確認し、内部リンク、sitemap、ログまで整えると、見た目だけではない運用可能な404ページになります。
執筆・検証
Finite Field 編集部
Web運用、サーバー実装、構造化データ、アクセシビリティの観点から一次資料を確認し、公開ページのstatusと画面を再現可能な手順で検証しています。
Web運用の相談
404・リダイレクト・内部リンクをまとめて整理
URL移行や大量のリンク切れがある場合は、個別のエラー画面だけでなく、転送表、内部リンク、sitemap、監視まで一つの運用として設計します。
個別に相談するご相談内容を確認後、対応範囲と進め方をご案内します。