404ページとは？表示される原因・設定方法とデザインの考え方

404ページは、単に「ページが見つかりません」と案内する画面ではありません。問い合わせや資料請求への導線、配信中の広告・メール、グローバルナビゲーションのリンク先で発生すると、見込み顧客が必要な情報に進めなくなる可能性があります。

大切なのは、表示画面だけを直すのではなく、対象URLが実際にどのHTTP応答を返しているかを確認することです。この記事を読めば、404を正しく判定し、URLごとに適切な対応を選べるようになります。設定時の依頼先、公開後の検収、更新規模に応じた点検方法まで、実務で使える順番で整理します。

404対応は、案内画面の表示確認からではなく、HTTP応答とURLの役割を確認してから判断します。

01Section404ページとは？404 Not Foundの意味と確認方法

まず、404というHTTPステータスと、訪問者に見せる404ページを区別します。この違いを押さえると、デザインやリンク修正に進む前に、権限・サーバー障害・公開設定の問題を切り分けられます。

404ステータスコードと404ページは別物

HTTPの標準仕様（RFC 9110）では、404 Not Foundは、要求されたリソースをサーバーが見つけられないことを示すHTTPステータスとして定義されています。

つまり、画面に「404」「Not Found」と書かれているかだけでは判断できません。存在しないURLで案内画面を出す場合も、対象URLのDocumentリクエストが404を返すことを確認します。

403・500・503と混同しないための見分け方

同じように「ページを表示できない」状態でも、初動が異なることがあります。画面のメッセージではなく、HTTP応答を確認したうえで、確認先を分けましょう。

各ステータスの一般的な意味は、MDNのHTTPレスポンスステータス一覧でも確認できます。403や5xxであれば、404ページの設定を変更する前に、権限・アプリケーション・インフラの担当者へ調査を依頼するのが先です。

画面表示ではなくStatus Codeを確認する

Chrome DevToolsを使う場合は、次の最小手順で確認できます。画面名や操作位置はブラウザ更新で変わることがあるため、必要に応じてChrome DevToolsのNetwork機能リファレンスも確認してください。

1. 1対象URLをシークレットウィンドウなどで開き、表示条件を記録します。
2. 2開発者ツールのNetworkパネルを開き、ページを再読み込みします。
3. 3DocまたはDocument型の対象リクエストを選びます。
4. 4StatusまたはStatus Codeが404かを確認します。

404であれば、リンク元、URL変更履歴、後継ページの有無を確認します。404ではない場合は、表示画面の改善ではなく、その応答に対応する技術的な確認へ切り替えてください。

02Section404ページが表示される主な原因

404の原因は多岐に見えても、実務では「URLそのものが変わった・なくなった」「リンク元が古い」「公開や配信の設定が想定どおりでない」の3つに整理できます。対象URLが本来どうあるべきかを確認しながら調べると、対応方針を決めやすくなります。

URL変更・ページ削除で旧URLが残る

ページのURLを変更したり、コンテンツを削除したりすると、以前のURLへアクセスした訪問者は404に到達します。サイト改修やコンテンツ統合の後は、検索結果、外部サイト、保存済みのブックマークなどに旧URLが残ることがあります。

削除したページに内容が近い後継ページがあるなら、後継先との関連性を確認してリダイレクトを検討します。一方、同等の情報を提供できるページがない恒久的な廃止URLでは、404または410を返すことが適切な場合があります。

サイト内リンクや配信施策の更新漏れ

自社で更新できるリンク元は、404を見つけたら優先的に確認したい対象です。特に次のリンク元は、訪問者への影響を確認しやすく、修正できる可能性があります。

• サイト内本文や関連記事、バナーなどの内部リンク
• グローバルナビゲーション、フッター、主要カテゴリのリンク
• 配信中の広告やメールの遷移先
• 営業資料、PDF、QRコードに掲載したURL
• URLを手入力・コピーする際の誤記を招きやすい表記

リンク元のURLが誤っている場合、404ページを整えるだけでは根本解決になりません。まずリンク元を正しいURLへ更新し、公開後の遷移を確認します。

公開設定・ルーティング・配信設定の不整合

本来は存在するページが404になる場合は、ページを作り直したり別URLへ転送したりする前に、技術的な原因を確認します。たとえば、公開状態の変更、ルーティングの変更、静的ファイルの出力漏れ、配信ルールやキャッシュの反映差異などで、意図せず404になることがあります。

直近の公開・改修内容、発生する環境、ログイン状態や端末による差異を記録し、開発・インフラ・運用担当へ渡せる状態にしてください。CDNやキャッシュが関わるサイトでは、確認するタイミングや経路によって見え方が異なることもあります。

03Section404を放置するとどうなる？優先順位と対応の選び方

404があること自体を、すべて急いで解消すべき問題と考える必要はありません。存在しないURLに404を返すことは適切な場合があります。一方で、主要な情報探索やコンバージョンへの経路にある404は、訪問者の行動を止めるため、優先して判断する必要があります。

Google Search Console ヘルプの404エラーに関する案内でも、削除済みで同等の代替ページがないURLでは404または410を返す考え方や、存在しないURLを無関係なページへ転送しない考え方が示されています。

404の存在自体と、重要な404を放置する影響は分けて考える

優先度は、404件数だけでは決められません。少数でも、問い合わせ・資料請求・商談予約に近い導線、配信中の広告・メール、グローバルナビゲーションから404へ到達するなら、関係者へ速やかに共有し、優先対応を判断する対象です。

反対に、代替先のない廃止URLや単発の入力誤りは、404を維持しながら再探索を支援し、繰り返し発生するかを監視する対応が考えられます。検索や事業への影響を404の件数だけで断定せず、流入元、URLの目的、後継ページの有無、到達後の行動を合わせて見ます。

リンク修正・リダイレクト・404維持・原因調査を選ぶ

404を検知したら、件数だけでなくリンク元と後継ページの関連性を確認し、URLごとに対応を選びます。

URLごとの対応は、次の順番で決めます。

1. 1HTTP応答を確認する：Documentリクエストが404かを確認します。403・5xx、認証、障害が疑われる場合は、技術的な原因調査へ進みます。
2. 2流入元と重要度を確認する：内部リンク、広告、メール、資料、ナビゲーションなど、修正できるリンク元かを確認します。CV導線や配信中施策に関係する場合は優先度を上げます。
3. 3後継ページの関連性を確認する：利用者が求めていた内容を満たす移転先・統合先・同等ページがあるかを確認します。
4. 4本来存在するURLかを確認する：本来公開されるべきページなら、公開設定、ルーティング、配信・キャッシュの不整合を調査します。

リンク元の誤りは修正し、関連性の高い後継ページがある場合はリダイレクトを検討します。代替先のない廃止URLは404を維持し、本来存在するURLや404以外の応答は原因を調査します。

URL変更に伴うリダイレクトは、旧URLと新URLの対応関係や内部リンク更新も含めて設計する必要があります。詳しくは301リダイレクトとは？302との違いとサイト移行時の設定・確認方法を参照してください。URL変更時の対応表作成や移行後の確認は、Google Search Centralのサイト移転ガイドも参考になります。

重要度に応じて初動と共有先を決める

優先対応の開始時点は、固定の期限ではなく、自社のSLA、承認経路、配信停止権限、担当体制に合わせて決めます。そのうえで、次の3つは優先的に共有・確認するとよいでしょう。

• 配信中の広告・メールのリンク先が404になっている
• 問い合わせ、資料請求、商談予約などの主要CV導線が404になっている
• グローバルナビゲーションや主要カテゴリから404へ遷移する

重要度が高い場合も、いきなり無関係なURLへ転送するのではなく、リンク元の修正可否と後継ページの関連性を確認してから方針を選びます。

04Sectionカスタム404ページの設定方法と公開後の検証

カスタム404ページでは、「案内画面を編集する場所」と「HTTP応答を決める場所」が別レイヤーになっていることがあります。CMSで画面を更新できても、ルーティング、Webサーバー、CDN、キャッシュの設定は別担当が管理している場合があるため、表示確認だけで完了にしないことが重要です。

設定前に確認すること：画面の編集箇所とHTTP応答の制御箇所

設定箇所は、CMS、静的サイトの出力、アプリケーションのルーティング、Webサーバー、CDN・キャッシュなど、サイト構成によって異なります。Webサーバーでカスタムエラー応答を扱う設定レイヤーがあることは、Apache HTTP Serverの公式ドキュメントからも確認できます。ただし、具体的な操作や応答の扱いは利用環境によって異なります。

構成を問わない設定・確認の5ステップ

カスタム404ページは、案内画面を作るだけでなく、非存在URLがHTTP 404を返すことまで確認して完了です。

CMS、静的出力、アプリケーション、サーバー、CDNのどれを使っていても、確認の順番は共通化できます。個別の設定方法は、利用環境の公式ドキュメントと担当者に確認してください。

HTTP 404、通常URL、旧URL、導線を分けて検収する

検収では、1つの画面が表示されたかではなく、URLごとに期待する結果が得られたかを確認します。非存在のテストURLではDocumentリクエストが404であること、通常URLでは本来のページと応答が維持されることを確認してください。

旧URLにリダイレクトを設定する場合は、旧URLの最初の応答、最終到達先URL、到達先ページの内容と応答を別々に記録します。これにより、意図しない転送や到達先の404を見逃しにくくなります。

CDN、ブラウザ、アプリケーションのキャッシュが関与する場合は、所定の反映後にも同じ確認を行います。地域、端末、ログイン状態で応答が変わり得るサイトでは、確認条件を分ける必要があります。

05Section404ページのデザインは「再探索できるか」で考える

404ページのデザインで優先するのは、見た目の独自性ではなく、訪問者が現在の状況を理解し、次の行動を選べることです。特定の機能をすべて載せるのではなく、サイトの構成と訪問者の目的に合う導線を選びます。

最初に伝えるべき3つの情報

画面の上部では、次の3点を平易な言葉で伝えます。

• ページが見つからないこと
• URLの変更・削除・入力違いなどの可能性があること
• 次にできる操作があること

「404 Not Found」という技術用語を使う場合も、先に利用者向けの説明を置きます。原因を一つに断定せず、「リンク先が変更された可能性があります」など、再探索につながる案内にします。

サイト構成に応じて再探索導線を選ぶ

404ページでは、問い合わせ導線だけでなく、訪問者が目的の情報を探し直せる経路を用意します。

必要なのは、訪問者が目的の情報へ戻るための経路です。導線を固定要件にせず、サイト構成に応じて、次の候補から少数を選びます。

• トップページまたは主要カテゴリ
• サービス一覧、製品一覧などの比較・検討の入口
• よく見られる情報や重要なコンテンツ
• サイト内検索
• 問い合わせや資料請求などの相談導線

BtoBサイトでは、すぐに問い合わせたい人だけでなく、サービス内容や導入条件を調べ直したい人もいます。CV導線だけを強調するのではなく、情報収集段階の訪問者が戻れる経路も用意すると、目的に応じた再探索を支援しやすくなります。

アクセシビリティと行動データで見直す

404ページも通常ページと同じように操作できる必要があります。WCAG 2.2を確認観点として、少なくとも次を見ます。

• キーボードだけでリンクや検索を操作できるか
• フォーカス位置が見え、移動順が理解しやすいか
• リンク文言から移動先の目的を判断できるか
• 色だけに依存せず、スマートフォンでも操作しやすいか

改善判断では、404到達数だけで結論を出しません。404到達が増えたならリンク元やURL移転方針を、再探索導線の利用が少ないなら案内文・リンクの順序や配置を確認します。404到達や導線クリックを識別する計測が未整備なら、主要な流入経路から404ページを開き、目的のページへ移動できるかを操作テストで確認する方法が現実的です。

06Section404を繰り返さないための点検・運用方法

404を完全にゼロにすることよりも、重要な404を早く見つけ、原因に応じて処理できる運用を作ることが重要です。検知手段には得意分野があるため、利用できるものを目的別に組み合わせます。

検知手段は目的別に使い分ける

Search Consoleは、Googleが把握したクロールやインデックスの観点を確認する用途です。アクセス解析は訪問者の到達元や404後の行動、クロールはサイト内リンク切れ、サーバーログは実リクエストの詳細、手動テストは重要な導線の操作確認に向いています。

Google Search Console ヘルプのページ確認ガイドでは、大きな変更時または月次で重要ページを確認し、個別URLはURL Inspectionで確認する使い分けが案内されています。Search Consoleの画面名、レポート分類、利用可能な機能は変更され得るため、運用開始時と公開時点で公式ヘルプを確認してください。

更新時・定期点検・大規模改修で確認範囲を分ける

すべての確認を毎回行う必要はありません。更新頻度、ページ数、流入規模、広告施策、自動化の可否、担当体制に応じて、点検範囲を分けます。

URL変更や移行を伴う場合は、旧URLと新URLの対応、内部リンクの更新、想定外のクロールエラーの監視をまとめて確認します。継続的なサイト点検の体制や役割分担は、Webサイト運用とは？業務内容・体制・改善の進め方も参考にしてください。

URLごとの記録を再発防止につなげる

404を検知したら、対応の完了だけでなく、次回の優先順位付けに使える情報を残します。管理方法はスプレッドシートなどでも構いませんが、少なくとも次の5項目を記録すると判断を引き継ぎやすくなります。

• 対象URLと確認したHTTP応答
• 流入元と影響区分
• 発生原因または調査状況
• リンク修正・転送・404維持・原因調査の対応方針
• 確認結果と再発防止の対応

同じリンク元や同じ改修手順で404が繰り返されるなら、個別URLの修正だけで終わらせず、URL変更時の対応表、公開前確認、配信URLの確認手順を見直します。

404対応では、案内画面の見た目だけでなく、HTTP応答、流入元、後継ページの関連性を確認することが重要です。存在しないURLに404を返すべき場面と、リンク修正やリダイレクトを検討すべき場面を分ければ、不要な一律転送を避けながら、重要導線の損失を抑えられます。

カスタム404ページを設定した後は、非存在URLのDocumentリクエストが404か、通常URLと旧URLが期待どおりか、再探索導線を操作できるかまで確認し、更新規模に応じた点検へつなげてください。

07Section設定後に確認するポイント