見つからない公開文書には明確な説明を表示し、通常は404などの適切なHTTPステータスを返す必要があります。MacではChromeで両方を確認し、不一致を特定して、公開システムに具体的な修正を依頼できます。

この手順は、ガイド、参考資料、簡単な説明書など、一般公開されている文書ページを管理する人向けです。目的は、要求されたアドレス、サーバーのレスポンス、表示されるメッセージを一致させることです。以下の例のパスはすべて架空のものです。

文書が見つからない場合、どのレスポンスを返すべきですか？

まず、その文書のアドレスでどう対応するかを決めます。移転したページと、存在しなくなったページでは、必要な処理が異なります。見つからないページの設計を変更する前に、この判断表を使ってください。

文書の状態 意図するレスポンス 読者に表示する内容
要求されたアドレスに存在する 200 OK 文書の全内容
明確な恒久的な移転先がある 301リダイレクト 新しいアドレスにある移転先の文書
見つからず、同等の移転先もない 404 Not Found 文書が見つからないことを伝える有用な説明
意図的に削除され、その状態が恒久的である可能性が高い 410 Goneが適切 削除を明確に伝える説明と役立つナビゲーション

HTTPでは404を定義していますが、見つからない状態が一時的か恒久的かは示しません。利用できない状態が恒久的である可能性が高いリソースには410を定義しています。恒久的かどうか不明な場合は404を使います。これらの意味については、RFC 9110の15.5.5節と15.5.11節を参照してください。

Googleは、文書が移転した場合や、明確な移転先がある場合には恒久的なリダイレクトを推奨しています。同様の移転先がないまま削除された場合には、Googleは404または410を推奨しています。Googleによるコンテンツが見つからない場合のレスポンスへの対処方法を参照してください。

たとえば、/documents/paper-folding-notesの実質的に同等の手順が/documents/paper-folding-guideに移ったとします。この場合は恒久的なリダイレクトが適しています。代わりの文書がないままノートが削除されたのであれば、古いアドレスでは文書が見つからないというレスポンスを返します。そのページには、文書一覧へのリンクを載せてもかまいません。

見栄えのよい見つからないページだけでは不十分な理由

ページに文書が見つかりませんと表示されていても、サーバーが200を返す場合があります。Googleはこのような不一致をソフト404と呼びます。空のページやメインコンテンツがないページも、同じ判定を受けることがあります。Googleによるソフト404エラーの説明を参照してください。

ステータスはHTTPレスポンスの一部であり、説明文とは別のものです。そのため、見出しを変更したり、大きく404と表示したりしても、レスポンスコードは設定できません。問題が解決したと判断する前に、実際の文書リクエストを確認してください。RFC 9110ではレスポンスステータスコードの役割が説明されています。

Macで文書のレスポンスを確認するには？

この確認にはChromeの組み込みツールを使います。同じ公開サイトにある、正常に動作する文書のアドレスと、意図的に存在しないパスを1つずつ用意してください。たとえば、見つからないパスとして/documents/missing-paper-example-731を使えます。公開済みの文書が存在しないとわかっているアドレスを選んでください。

  1. Chromeで公開ページを開きます。
  2. Command + Option + Iを押してDevToolsを開きます。
  3. Networkパネルを選択します。
  4. DevToolsを開いたまま、アドレスバーにテスト用アドレスを入力して読み込みます。

ChromeでのMac用ショートカットについては、Chrome DevToolsを開くを参照してください。DevToolsが開いている間はネットワークの動作が記録されます。詳しくはNetworkパネルの概要を参照してください。

  1. この確認でブラウザーのキャッシュ済みレスポンスを使わないよう、Disable cacheを選択します。
  2. リダイレクトをたどる必要がある場合は、Preserve logを有効にします。
  3. テスト用アドレスを再読み込みします。
  4. メインの文書リクエストを選択し、Headersを開きます。Generalの下にあるリクエストアドレスとステータスコードを確認します。

これらの操作とステータス情報の場所については、Chromeのネットワーク機能リファレンスに記載されています。

文書リクエストを注意深く確認してください。ログにはスクリプト、スタイルシート、その他のリソースに対するリクエストも含まれます。補助ファイルが見つからないだけでは、文書そのものが404を返したことにはなりません。Chromeのリクエスト一覧では、HTTPコードはStatus、リソースの種類はTypeで確認できます。ネットワーク動作を検査するを参照してください。

次に、最初に要求したアドレス、その文書のレスポンスコード、読み込み後に表示されるページの3つを照らし合わせます。3つをセットで記録してください。ページ遷移でアドレスが変わる場合は、最終ページだけを記録せず、最初のリクエストと移転先の両方を確認します。

確認結果を修正依頼にまとめるには？

次の診断表は、HTTPの意味とGoogleのトラブルシューティングのガイダンスを実用的にまとめたものです。判断の目安であり、測定結果ではありません。

確認された結果 調べる箇所 意図する修正
200で、文書が見つからないというメッセージが表示される 見つからないパスを処理するハンドラーまたはフォールバック 説明を表示したうえで404を返す
404で、期待した文書が表示される 既存のルートに割り当てられたレスポンス 200でその文書を正常に配信する
広範な文書一覧にリダイレクトされる 同等の移転先が存在するかどうか 同等の文書へリダイレクトするか、見つからないページを表示する
200で、文書が空または不完全 コンテンツの読み込みと表示 文書が引き続き存在する場合は、意図した内容を復元する
404で、役立つ見つからないページのメッセージが表示される そのアドレスに本当に文書がないかどうか 文書がない状態を意図しているなら、その動作を維持する

Googleのトラブルシューティング資料では、利用できない文書、移転した文書、まだ存在するが正しく読み込まれない文書を明確に区別しています。この違いを踏まえれば、不完全な稼働中のページを意図的に削除されたものとして扱わずに済みます。Google検索のクロールエラーを解決するを参照してください。

具体的な依頼文は次のように書けます。「架空の見つからないパス/documents/missing-paper-example-731では、そのアドレスでカスタムの文書未検出ページを表示し、404を返してください。既存の文書パスは正常に機能する状態にしてください。同等の移転先が確認できた場合に限り、恒久的なリダイレクトを適用してください。」確認時に観察したステータスと表示メッセージも加えます。

この依頼では、公開システムのメニュー名を推測せずに、必要な動作を説明できます。実装は、レスポンスを生成するホスティング設定、アプリケーションのルート、または公開システムで行います。HTTPステータスコードはホスティングサーバーが生成するとGoogleのHTTPステータスコードのドキュメントで説明されています。

エディターでページ内容しか変更できない場合は？

テキストや文書のメタデータを変更するエディターでは、HTTPレスポンスを制御できないことがあります。WHATWG HTML Standardでは、http-equivを使うmetaディレクティブに特定の動作が定義されていますが、HTTPレスポンスのステータス設定はその対象に含まれていません。そのため、http-equiv="status"を追加して404を作成することは、サポートされた方法ではありません。HTML Standard: Pragmaディレクティブを参照してください。

エディターでレスポンスを制御できない場合は、ホスティング層またはアプリケーション層に用意された、文書が見つからない場合の処理機能を使ってください。要求された見つからないアドレスに対して、カスタム内容を404とともに配信できるか確認します。エラーページのレイアウトを選べるだけの設定では、この点は確認できません。ブラウザーでの手順に従って、結果を検証してください。

Netlifyの静的ページに関する、ドキュメントに記載された例

Netlify上の既存の静的サイトでは、ドキュメントに記載された方法として404.htmlというファイルが使えます。静的ファイルに解決されないパスが失敗した場合、Netlifyは自動的にこのファイルを使います。これは、完成済みのサイト出力にアクセスでき、既存の静的ページビルドがあることを前提とする、プロバイダー固有の例です。Netlifyのカスタム404処理の説明を参照してください。

  1. サイトの既存のページテンプレートを使って、文書が見つからない場合のページを作成します。
  2. 完成した出力に、公開ディレクトリのルートにある404.htmlが含まれていることを確認します。
  3. 不明なアドレスを別のページへ送るルーティングルールが、先に適用されないことを確認します。
  4. 修正後の出力が公開アドレスで利用可能になったら、見つからないパスと正常に表示される文書の両方を調べます。

Netlifyでは、静的ファイルと最後の見つからないページの処理に到達する前に、ルーティングが行われるため、この確認が重要です。先に処理されたリクエストは、最後のハンドラーには到達しません。リクエストチェーンのドキュメントで順序を確認できます。この例は修正手順を説明するものであり、実際のサイトが変更されたことを示すものではありません。

ブラウザーでルーティングするアプリケーションの制約

アプリケーションによっては、JavaScriptが実行された後で初めて文書が存在しないことを検出します。Googleは、クライアント側ルーティングでは意味のあるステータスコードを返すことが実用的でない場合があると認めています。Googleが示す代替策は、サーバーが404を返すアドレスへのJavaScriptリダイレクト、またはエラーページへのnoindexメタデータの追加です。GoogleのJavaScript SEOガイダンスを参照してください。

これらの代替策では結果が異なります。リダイレクトでは、新しいアドレスに移動し、そこで実際の見つからないページのレスポンスが返されます。メタデータを使う方法はインデックス登録に対処するもので、元のHTTPステータスは変わりません。元の文書アドレスを維持したまま、そこで404を返す必要がある場合は、ホスティングまたはアプリケーション側のレスポンスがその動作に対応している必要があります。

文書が見つからないページには何を表示すべきですか？

この文書は見つかりませんでした。のように、短く具体的なメッセージを使います。その後に、文書一覧など、確認済みの有用な移動先へのリンクを1つ示します。サイトでおなじみのナビゲーションと見た目を維持してください。Googleはカスタムの見つからないページについて、わかりやすい文言、一貫したデザイン、役立つリンクを推奨しています。

架空の紙折り文書の例では、次のような文面が適しています。この紙折り文書は見つかりませんでした。文書一覧から別のガイドをお選びください。恒久的に削除されたとわかっている場合に限り、そのように説明してください。見つからないアドレスをすべてすぐ別の場所へ移動させず、説明が画面に表示されるようにします。

レスポンスとページが一致していることを確認するには？

少数の比較用アドレスで確認を繰り返します。以下の期待される結果は参考となる受け入れ基準であり、実際のテスト結果ではありません。

テストケース 期待されるレスポンスとページ
正常に表示されることがわかっている文書 200で、文書の全内容が表示される
意図的に存在しないパス 404で、文書が見つからないことを説明する
移転先がないまま削除された文書 404、または適切な場合は410で、正確な説明が表示される
同等の移転先がある移転済みの文書 恒久的なリダイレクトの後、移転先から正常なレスポンスが返される

各アドレスを直接入力して再読み込みし、ページ内のリンクから移動するのが通常の文書も含めて再テストします。これにより、新たな文書リクエストに対して返されるレスポンスを確認できます。移動先が正常に表示されても、ナビゲーションの途中に誤ったレスポンスが隠れないよう、アドレス、コード、表示結果をセットで記録してください。

古い結果が残る場合は、ブラウザーのキャッシュとそれ以外のキャッシュを区別します。Chromeのキャッシュを無効にすれば、ブラウザーのキャッシュには対処できます。HTTPキャッシュには404などの否定的なレスポンスも保存される場合があるため、古い「見つからない」レスポンスが残るときは、公開システムに記載されたキャッシュの動作を確認する必要があります。RFC 9111ではキャッシュ可能な否定的レスポンスについて説明されています。

Google検索では、本当に見つからない場合に想定される影響があります。Googleは404または410を返すURLをインデックス登録せず、これらのレスポンスが処理されると、以前にインデックス登録されたURLも削除します。また、200が正常に返されても、インデックス登録されるとは限りません。HTTPステータスコードがGoogleのクローラーに与える影響を参照してください。

テストした各アドレスの挙動に一貫性があれば完了です。利用可能な文書は正常に読み込まれ、移転した文書は移転先へ案内され、存在しない文書は役立つナビゲーションを伴う適切な見つからないレスポンスを返します。これにより、Macで具体的かつ再現可能な公開チェックを行えます。

参照資料