61

私は現在、angularjsを使用してWebアプリケーションを作成していますが、この質問は、クライアント側でルーティングを行うクライアント側のjavascriptフレームワークに当てはまると思います( angularが行うように)。

単一ページのアプリで、間違った URL を処理する正しい方法は何ですか?

いくつかの主要なサイトを見ると、https://mail.google.com/mail/の下にランダムな URL を入力すると、gmail が受信トレイにリダイレクトされることがわかります。これは、間違ったパスが # 文字の前後にあるかどうかに応じて、サーバー側 (http 300 コードを使用) またはクライアント側で発生します。一方、twitter は無効な URL に対して実際の HTTP 404 を表示します。3 番目のオプションは、純粋にクライアント側のエラー ページである「ソフト」404 を表示することです。

これらのソリューションは、さまざまな状況に適しているようです。Twitter は、Twitter ユーザーへのリンクとツイートが実際のリンクであることを望んでいるため、人々はそれらを共有したり、ニュース記事に投稿したりできます。そのため、無効なリンクがそのように認識されることが重要です (私のウェブサイトでは、単純なクロールでそれがわかります)。一方、gmail では、リンクを受信トレイに共有することは想定されていません。また、リンクが本当に永続的/永続的であるかどうかもわかりません。シングルページアプリ。ソフト エラーを与える 3 番目のアプローチは、gmail と同様の状況に適している可能性がありますが、合理的な「デフォルト」ページはありません。

この長い紹介の後、いくつかの具体的な質問があります。

  • 404 エラーの代わりに「ソフト」エラー ページを表示することは許容されますか? または、URL が無効な場合、単一ページのアプリは常に実際の 404 にリダイレクトする必要がありますか?
  • Gmail のコードには完全にバグがないかもしれませんが、受信トレイにリダイレクトされる無効なリンクにつながるバグがあった場合、エラー ページよりもユーザーを混乱させる可能性があります。gmail ほど十分にテストされていないほとんどの Web アプリでは、エラー ページを表示した方がよいでしょうか?
  • シングルページ アプリに実際の 404 を実装するには、サーバー側でルーティング ロジックを複製する必要があるようです。これを回避する方法はありますか？
  • 404 にリダイレクトする場合、ユーザーはエラーの原因となった URL をおそらく URL バーで確認できるはずです。html5 history api を使用すると、上記のサーバー側のルーティングと組み合わせて、現在のページのリロードを (間違った URL で) トリガーするだけでこれを達成できると思います。これをサポートしていないブラウザーや、ハッシュバン表記を使用している場合、これは不可能のようです。すべてのブラウザをサポートする最善の方法は何ですか?
4

2 に答える 2

8

SEO に関心がある場合、angular.io がこの問題を解決できた方法の 1 つ(少なくとも Google では) は、noindex メタ タグを使用して「ソフト 404 ステータスを示し、クローラーがコンテンツをクロールできないようにすることです。ページ"。どうやら JavaScript を介してドキュメントに追加できるようです。

または、JavaScript を使用して、実際の HTTP 404 ステータス コードで応答するページにリダイレクトできます。Google は JavaScript リダイレクトを問題なく認識します。元の/does-not-existページが にリダイレクトされると/404-error?from=does-not-exist、サーバーから返された 404 ステータス コードに関連付けられます。URL 構造は重要ではありません。ここで重要なのはステータス コードとリダイレクトだけです。

他のオプションは、SSR (Nuxt.js、Next.js、Angular Universal など) または事前レンダリング (prerender.io、puppeteer など) であり、Google は動的レンダリングと呼び、事前レンダリングされたバージョンで検索ボット リクエストに応答します。人間のユーザーは通常のクライアント側でレンダリングされたアプリを取得します。

于 2018-11-20T20:19:53.450 に答える
5

tl;dr: SEO に関心がある場合は、hashbang のサポートをやめて、 PJAXのような動作を選択してください。

アプリやウェブサイトを作成していますか? 404ウェブサイトの場合は、Google を混乱させないように戻る必要があります。ページが見つからないというメッセージを表示するだけでなく、実際に表示する必要があり404ます（つまり200、「ページが見つかりません」というメッセージは非常に悪いです）。また、どのブラウザをサポートしたいですか?

#!私の意見では、hashbang サーバー側のレンダリング全体 (つまり、厄介な Google SEOハック)は避けるべきです。pushstate をサポートしていない (ハッシュの変更ではない) ブラウザーの URL が変更された場合は、実際の pushstate を使用するか、ページ全体を再レンダリングします。

これが重要な理由は、 a が a#!を返してはならないという404ことです。これは意味がなく、サーバー側を模倣することは不可能であるため#!です。

したがって、SEO を本当に気にするのであれば、PJAX のようなことをして、ルーティングに真のプッシュステートのみを使用し、古い Web 1.0 に失敗するだけです。したがって、私があなたに共有することをお勧めするリンクは本当に持つ404べきではありません(ページの内容が大幅に変更されない限り、#!従来のリンクでも問題ありません)。#

最後に、これ404はほとんど問題ではなく、30X応答のリダイレクトです。これは、ブラウザがリダイレクトを自動的に処理するため、Javascript AJAX 呼び出しで a が表示されないため30Xです (代わりにリダイレクト応答が返されます...つまり 200)。応答を処理30Xするには、プッシュステート履歴を台無しにしないように、リダイレクトされた URL が何であるか (つまり、リダイレクトされたもの) を示すために、すべての要求に対してヘッダーを送り返す必要があります。

もちろん、Twitter のように hashbang をサポートする必要がある場合 (hashbang を無効にしたものでもあります)、Google サイトマップを利用しrel=nofollowて、悪い SEO を緩和することができます。

于 2013-02-09T15:57:16.357 に答える