シングルページアプリで、間違ったURL（404エラー）を処理する正しい方法は何ですか？
現在、angularjsを使用してWebアプリケーションを作成していますが、この質問は、クライアント側でルーティングを行うクライアント側のjavascriptフレームワークにも当てはまると思います（ as angularはあります ）。
シングルページアプリで、間違ったURLを処理する正しい方法は何ですか？
いくつかの主要なサイトを見ると、下にランダムなURLを入力すると、Gmailが受信トレイにリダイレクトされることがわかります https://mail.google.com/mail/ 。これは、間違ったパスが＃文字の前か後かに応じて、サーバー側（http 300コードを使用）またはクライアント側で発生します。一方、Twitterは無効なURLに対して実際のHTTP 404を表示します。 3番目のオプションは、純粋なクライアント側のエラーページである「ソフト」404を表示することです。
これらのソリューションは、さまざまな状況に適しているようです。 Twitterは、Twitterユーザーへのリンクとツイートを実際のリンクにしたいので、人々はそれらを共有したり、ニュース記事に投稿したりできるため、無効なリンクがそのように認識されることが重要です（ツイートへのリンクが壊れている場合）私のウェブサイト、簡単なクロールでそれがわかります）。一方、Gmailでは、リンクを受信トレイに共有することは期待されていません。リンクが本当に永続的であるかどうかもわかりません。URLの更新は、ほとんどの場合、ブラウザ内の履歴ナビゲーションの目的に役立つようですシングルページアプリ。ソフトエラーを表示する3番目のアプローチは、Gmailと同様の状況に適している可能性がありますが、合理的な「デフォルト」ページがありません。
この長い紹介の後、いくつかの具体的な質問を次に示します。
- 404エラーの代わりに「ソフト」エラーページを表示することは許容されますか、またはURLが無効な場合、単一ページのアプリは常に実際の404にリダイレクトする必要がありますか？
- Gmailのコードには完全にバグがない可能性がありますが、無効なリンクが原因で受信トレイにリダイレクトされるバグがあった場合、エラーページよりもユーザーを混乱させる可能性があります。 GmailほどテストされていないほとんどのWebアプリケーションについて、エラーページを表示する方が良いでしょうか？
- シングルページアプリに実際の404を実装するには、サーバー側でルーティングロジックを複製する必要があるようです。これを回避する方法はありますか？
- 404にリダイレクトすると、ユーザーはエラーの原因となったURLをおそらくURLバーに表示できるはずです。 html5履歴APIを使用すると、現在のページ（間違ったURLで）のリロードをトリガーし、上記のサーバー側ルーティングと組み合わせるだけでこれを実現できると思います。これをサポートしていないブラウザーの場合、またはハッシュバング表記を使用している場合、これは可能ではないようです。すべてのブラウザをサポートする最良の方法は何ですか？
tl; dr：ハッシュバングのサポートを削除して [〜＃〜] pjax [〜＃〜] を選択しますSEOを気にしています。
アプリまたはウェブサイトを作成していますか？ウェブサイトの場合は、Googleを混乱させないように404を返す必要があります。これは、ページが見つからないというメッセージを表示するだけでなく、実際の404である必要があります（つまり、「ページが見つかりません」というメッセージのある200は非常に悪いです）。また、どのブラウザをサポートしますか？
私の意見では、hashbangサーバー側のレンダリング全体を回避する必要があります（つまり、厄介なGoogle SEO #!ハック）。実際のpushstateを使用するか、pushstateをサポートしないブラウザーのURLが変更された場合（ハッシュの変更ではない）、ページ全体を再レンダリングします。
これが重要な理由は、#!が意味のない404を返すことは決してないためであり、サーバーがJavaScriptを実行せずに#!の後に何も取得しないため、サーバー側を模倣することは不可能です。
したがって、本当にSEOに関心がある場合は、PJAXのようなことを行い、ルーティングに真のpushstateのみを使用し、古いWeb 1.0に失敗します。したがって、本当に404になる可能性のある共有することをお勧めするリンクには、#!を含めないでください（ページのコンテンツが大幅に変更されない限り、従来の#で問題ありません）。
最後に、404はほとんど問題ではなく、30X、つまりリダイレクト応答です。これは、ブラウザーがリダイレクトを自動的に処理するため、JavaScript AJAX=呼び出しには30Xが表示されないためです（代わりにリダイレクト応答が返されます...つまり200）。30X応答を処理するには、次のようにする必要があります。すべてのリクエストに対してヘッダーを送り返して、リダイレクトされたURLが何であるか（つまり、リダイレクトされたか）を示し、Pushstateの履歴を台無しにしないようにします。
もちろん、Twitterのようにハッシュバングをサポートする必要がある場合（ そしてそれらはハッシュバングを殺したものでもあります ）、Googleサイトマップと rel=nofollow を活用して軽減しようとすることができます悪いSEO。
SEOに関心がある場合、 angular.ioがこの問題を解決する方法の1つ （少なくともGoogleで）、 noindexメタタグ 「クローラーがページのコンテンツをクロールできないようにするsoft-404ステータスを示します」。どうやらそれはJavaScript経由でドキュメントに追加することができます。
他のオプションは、SSR（Nuxt.js、Next.js、Angular Universalなど）またはGoogleが呼び出す事前レンダリング（prerender.io、puppeteerなど）です 動的レンダリング 人間のユーザーが通常のクライアント側レンダリングアプリを取得している間に、事前にレンダリングされたバージョンで検索ボットリクエストに応答します。