Cloudflare Pagesで存在しないURLが200になる原因とAstroの404ページ

存在しないURLを開いたときに専用画面が見えても、その応答が404とは限らない。ホスティング側のフォールバックやアプリケーションのルーティング次第では、存在しないパスへトップページなどを200 OKで返すことがある。利用者にはページが見え、URLだけでは気付きにくいため、リンク切れの扱いを判断するには画面とHTTPステータスを分けて確認する必要がある。

このリポジトリではコミット0f52fb4でsrc/pages/404.astroを追加した。コンポーネントは「ページが見つかりません」という見出しと、トップ・記事一覧へ戻るリンクを持つ。404を技術的な空白画面にせず、次に進める選択肢を示すための実装である。

静的サイトで確認する対象

Astroのsrc/pages/404.astroは、ビルド対象となる404ページを定義する。静的生成が成功しても、実際にどのステータスで配信されるかは公開環境で別途見る。今回の公開確認では、存在しないパスへのリクエストがHTTP 404になることを確認した。この確認はCloudflare Pages一般の全構成を示すものではなく、このサイトの公開構成に限る。

<!-- src/pages/404.astro -->
<h1>ページが見つかりません</h1>
<a href="/">トップページへ</a>

画面をブラウザで開くだけでは、HTTP 200と404の区別はできない。開発者ツールのNetwork表示、またはステータスを表示できるHTTPクライアントで、存在しないURLの最終応答を確認する。リダイレクトがある場合は途中の応答だけで判断せず、最終URLと最終ステータスを記録する。

失敗しやすい点と判断

404画面を通常ページと同じ見た目にしても、ステータスが200なら検索エンジンや監視ツールには存在するページとして扱われ得る。反対に、ステータスだけを確認して戻り先がない画面を放置すると、閲覧者はサイトを離れやすい。今回の判断では、Astro側で専用画面を用意し、公開環境でHTTP 404を確認する二段階を採った。

記事追加後にはnpm run buildで404ページを含む生成物を確認し、本番反映後は意図的に存在しないパスを一つ選んで確認する。実在する記事URLを確認用に使うと、誤って正常ページのキャッシュや計測を見てしまうため避ける。

リンク修正の完了確認でも同じ考え方を使える。リンク元を直しただけで終えず、旧URLが意図どおり404になり、新しいURLが200で表示されることを別々に確認する。404をトップへ自動転送すると、閲覧者には理由が分からず、HTTPの意味も曖昧になる。このサイトでは存在しないページであることを明示し、利用者が自分で次のページを選べる画面にした。

404ページにも通常ページと同じ共通レイアウトを使っているため、ヘッダーや基本的なメタデータの扱いは他の固定ページとそろう。ただし、広告や存在しない記事への誘導を追加していない。エラー状態で必要なのは、問題の説明と有効な戻り先であり、通常コンテンツと同じ情報量を増やすことではない。

公式資料と関連記事

• Astro公式: Pages — src/pagesを基準とするルーティングと404ページの生成方法を確認できる。
• Cloudflare公式: Pages routing — Pages上のルーティングを設定する際の確認先。
• Astroブログの公開前チェック：生成HTML・リンク・メタタグを確認する手順 — 生成物を公開前に見る手順を扱う。