404ページの設計: ユーザーを次の動線に流す
サイトを公開してしばらく経つと、URL の変更や記事の統廃合で、リンク切れがどうしても発生します。デフォルトの 404 ページは「Not Found」と書かれているだけのことが多く、訪問者は「ページが無い」と分かってもサイトを離脱するしかありません。せっかく訪問してくれた人を別の役立つページへ案内できるように、404 ページを設計し直したときの記録です。結論を先に書くと、柔らかいエラーメッセージ・主要ページへのリンク・サブドメイン横断ナビ、の3要素を備える構成に落ち着きました。
デフォルト 404 のままだとなぜ良くないか
Cloudflare Pages や他の静的ホスティングを使うと、デフォルトの 404 ページが用意されていることが多いです。シンプルでミニマルな見た目ですが、サイトのデザインから浮く、サイトのナビが消えるので訪問者が次に行く場所がない、検索バーやサイトマップへの導線がない、といった点が気になります。
訪問者が 404 にたどり着く経路はいくつかあります。古い URL を共有された、検索結果に表示された URL が古くなっていた、内部リンクが壊れていた、URL の打ち間違い、などです。どの経路でも、訪問者は「目的のページを見たかった」状態なので、近い情報を提示できれば離脱を減らせます。
404 ページに載せる3要素
私のサイトの 404 ページに載せている主要要素は次の通りです。
第一に、エラーメッセージを柔らかい言い方にしています。「ページが見つかりませんでした」という事実を伝えつつ、「URL を打ち間違えたかもしれません」「ページが移動した可能性があります」など、訪問者側に立った文言にしています。冷たく感じさせない書き方ができるといいなと思っています。
第二に、主要ページへのリンクを並べます。本サイトのトップ・制作記・運営者情報・お問い合わせなどを、シンプルなリスト形式で表示します。404 だからといって、訪問者の次の行き先が消える理由はありません。サイト全体に検索機能を持っていなくても、目立つ場所へのリンクが揃っていれば次の動線になります。
第三に、サブドメインを跨いで運用しているサイトでは、他サブドメインへのリンクも置いています。私のサイトでは、ホテル検索・スマホ料金比較・お金診断・キッズ集・楽天最安値検索・○×トラッカー・TODO といったサブサイトへのリンクを 404 ページにも並べています。トップサイトの 404 から各サブサイトに直接移動できるようにしておくと、訪問者がサイト構造を把握しやすくなります。
HTTP ステータスコードは 404 のままに
404 ページの作りに集中していると、ついうっかり HTTP ステータスを 200 で返してしまうことがあります。静的サイトジェネレーターによっては、404.html を作るだけだとレスポンス自体は 200 を返してしまうケースもあるので、ホスティング側の設定で 404 ステータスが返るように確認するのが大事です。
Cloudflare Pages では、要求されたファイルが見つからない場合に表示するカスタム 404 ページとして、404.html を用意できます。ビルド後の出力に 404.html が含まれているか、実際に存在しない URL へアクセスしてステータスコードが 404 になっているかを確認します。Workers でルーティングを書いているサイトでは、return new Response(html, { status: 404 }) のように明示的にステータスを設定しないと、200 を返してしまいます。
検索エンジンは、404 ステータスのページを「インデックスから外していい」と判断するそうなので、404 を 200 で返してしまうと、リンク切れページがいつまでもインデックスに残る原因になります。存在しない URL をトップページへリダイレクトしたり、200 でエラーページを返したりすると、Google に「ソフト404」として扱われることがあるとも聞きます。見た目だけでなく、HTTP ステータスコードまで確認しておくと安心だなと感じました。
デザインはサイトと統一
404 ページのデザインは、サイト全体のデザインに合わせるのが自然だなと感じます。ヘッダー・フッター・ナビゲーション・配色・タイポグラフィを通常のページと同じにしておくと、訪問者は「自分が訪れたサイト内にいる」感覚を維持できます。
404 ページにも、トップへ戻るための最小限の道しるべ（パンくず）だけは置いています。ただ、サイドバーや凝ったナビまでは出さず、「ここはどこでもないページですよ、入口はこちら」と伝えるだけのシンプルな作りにしています。
イラストや遊び心のあるグラフィックを入れるサイトもあり、訪問者の気持ちを和らげる効果があります。私のサイトでは控えめに、シンプルなテキスト中心の見た目にしていますが、サイトのトーンに合わせて選べばよいと思います。
ログとモニタリング
404 ページの設置と並行して、どの URL が 404 になっているかを把握できる仕組みもあると便利です。私の場合は、Cloudflare の Web Analytics と Search Console のページのインデックス登録関連レポートを併用しています。サイトによっては、自前で送る簡易ログ（404 ページの JS で 1px gif を fetch するなど）を組み合わせる例もあるようです。
これから 404 が多発する URL が出てきたら、対応の優先度を決めていく予定です。多い順に並べて、本来あるはずのページなら復元する、移転先があるならリダイレクトを設定する、純粋なタイポなら無視する、という判断軸で進めるつもりです。
特に Search Console で「リダイレクトのエラー」「クロール済み – インデックス未登録」などの項目が増えてきたら、サイト構造の見直し時期だなと考えています。
リダイレクト設計と組み合わせる
ページの URL を変更したり、コンテンツを統合したりする場合は、404 にする前にリダイレクト（301 Moved Permanently）を設定しておくと安心です。Cloudflare Pages では _redirects ファイル、Workers なら Response.redirect() で対応できます。URL 変更や統合で移転先が明確な場合は、404 にせず _redirects で 301 リダイレクトを設定するようにしています。一方、対応する移転先がない古い URL やタイポ URL は、無理にトップへ飛ばさず 404 で受けるようにしています。
ただし、リダイレクトが無限に増えると管理が大変になるので、サイトの規模が大きくなってきたら「ある程度古い URL のリダイレクトはやめて 404 で受ける」というラインを引くつもりでいます。リダイレクトチェーン（複数段のリダイレクト）が深くなると、検索エンジンにも訪問者にも不親切になるので、できるだけ1段で済むように設計したいと思っています。
404 ページの設計は、訪問者を引き止める「保険」のような役割です。基本的にはリダイレクトと内部リンクの整備で 404 自体を減らすほうが本筋ですが、それでもゼロにはならないので、最後の受け皿として丁寧に作っておく価値があると感じています。
ページ数が増えるほど 404 にたどり着く訪問者の絶対数も増えるので、初期に整えておくほど長期的なリターンが得られる作業だなと思います。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ