pushStateおよびSEO
多くの人は、ハッシュバングではなくpushStateを使用すると言っています。
私が理解していないのは、hashbangを使用せずにどのように検索エンジンに優しいのですか？
おそらく、pushStateコンテンツはクライアント側のJavaScriptコードによって生成されます。
したがって、シナリオは次のとおりです。
私は〜に乗っています example.com。ユーザーがリンクをクリックします：href="example.com/blog"
pushStateはクリックをキャプチャし、URLを更新し、どこかからJSONファイルを取得し、コンテンツ領域にブログ投稿のリストを作成します。
Hashbangsを使用すると、Googleはescaped_fragment URLにアクセスして静的コンテンツを取得することを認識しています。
PushStateを使用すると、JavaScriptコードを使用してJSONをロードしてからテンプレートを作成できないため、Googleは何も表示しません。
私が見ることができる唯一の方法は、サーバー側でテンプレートをレンダリングすることですが、それはアプリケーション層をクライアントにプッシュする利点を完全に無効にします。
私はこれを正しく理解していますか？pushStateはクライアント側のアプリケーションにとってSEOフレンドリーではありませんか？
ハッシュタグをURLに含めたくない人のためにGoogleが提案するメタタグの使用についてはどうですか：<meta name="fragment" content="!">
詳細については、こちらをご覧ください： https://developers.google.com/webmasters/ajax-crawling/docs/getting-started
残念ながら、ニコールは、OPが抱えていると思っていた問題を明確にしたとは思わない。問題は、ハッシュバンを使用しないと、コンテンツの提供先がわからないということです。 Pushstateはこれを解決しません。エンドユーザーに、フォーマットされていないJSONを吐き出すURLにナビゲートするように検索エンジンに伝えたくありません。代わりに、AJAX=を介してデータを取得し、希望する方法でユーザーに提示するURL（他のURLへの他の呼び出しをトリガーする）を作成します。ユーザーが人間でない場合は、代替手段としてhtmlスナップショットを提供できるため、検索エンジンは、要求されたデータを（見やすい方法で）見つけると予想されるURLに人間のユーザーを適切に誘導することができます。ユーザーのタイプですか？はい、.htaccessまたは何かを使用して、検出した検索エンジンボットのURLを書き換えることができますが、これがどの程度完全で将来の保証であるかはわかりません。ある種のことですが、私は完全に調査していませんので、（pushstate + googleのメタタグ）コンボが解決策のようです。
コンテンツを読むために検索エンジンが必要な場合、pushStateは悪いですか？
いいえ、pushStateについての話は、hashbangsと同じ一般的なプロセスを達成することを目的としていますが、見栄えの良いURLを使用しています。ハッシュバンを使用すると実際に何が起こるか考えてください...
あなたは言う：
Hashbangsを使用すると、Googleはescaped_fragment URLにアクセスして静的コンテンツを取得することを認識しています。
言い換えれば、
- Googleには
example.com/#!/blogへのリンクが表示されます - Googleは
example.com/?_escaped_fragment_=/blogをリクエストします - あなたユーザーに表示されるコンテンツのスナップショットを返す
ご覧のとおり、すでにサーバーに依存しています。 サーバーからコンテンツのスナップショットを提供していない場合、サイトは適切にインデックス付けされていません。
それでは、pushStateでGoogleはどのように見えるのでしょうか？
PushStateでは、JavaScriptを使用してJSONをロードし、その後テンプレートを作成できないため、Googleは何も表示しません。
実際、Googleはsite.com/blogでリクエストできるものをすべて表示します。 URLは引き続きサーバー上のリソースを指し、クライアントは依然としてこの契約に従います。もちろん、最新のクライアントの場合、Javascriptはpage更新なしでコンテンツを取得および操作するための新しい可能性を開きましたが、契約は同じです。
したがって、pushStateの意図的な優雅さは、同じコンテンツをすべてのユーザー（古いものと新しいもの、JS対応とそうではない）に提供することですが、新しいユーザー 拡張エクスペリエンスを得る です。
Googleにコンテンツを表示するにはどうすればよいですか？
Facebookのアプローチ—
site.com/blogを状態にプッシュしたときにクライアントアプリが変換するURL/blogで同じコンテンツを提供します。 （Facebookは私が知っているpushStateをまだ使用していませんが、ハッシュバンでこれを行います）Twitterのアプローチ—すべての着信URLを同等のハッシュバングにリダイレクトします。つまり、「/ blog」へのリンクは
/blogを州にプッシュします。ただし、直接要求された場合、ブラウザは#!/blogになります。 （Googlebotの場合、これは必要に応じて_escaped_fragment_にルーティングされます。他のクライアントの場合、pushStateをプリティURLに戻すことができます）。
pushStateで_escaped_fragment_機能を失いますか？
いくつかの異なるコメントで、あなたは言った
エスケープされたフラグメントは完全に異なります。テーマのない純粋なコンテンツ、キャッシュされたコンテンツを提供でき、通常のページの負荷にさらされることはありません。
Googleにとって理想的なソリューションは、JavaScriptサイトを実行するか、pushstateサイト（robots.txt？）であってもエスケープされたフラグメントURLがあることを知る何らかの方法を実装することです。
あなたが言及した利点は、_escaped_fragment_に限定されていません。書き換えを行い、特別な名前のGET paramを使用することは、実際の実装の詳細です。標準のURLではできなかった特別なことは何もありません。つまり、 mod_rewrite またはサーバーの同等のものを使用して、自分で/blogを/?content=/blogに書き換えます。
サーバー側のコンテンツをまったく提供しない場合はどうなりますか？
URLを書き換えて/blogで何らかのコンテンツ（またはブラウザにプッシュした状態）を提供できない場合、サーバーは実際にはHTTPコントラクトに準拠していません。
（何らかの理由で）ページをリロードすると、このURLのコンテンツが取得されるため、これは重要です。 （ https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review —「view-sourceおよびreloadは、プッシュされた場合、新しいURIでコンテンツをフェッチします。」を参照）
クライアントサイドでユーザーインターフェイスを一度描画し、JS APIを介してコンテンツをロードすることは悪い目標ではありません。HTTPとURLで実際に考慮されておらず、基本的に下位互換性はありません。
現時点では、これはhashbangが意図している正確なものです。サーバーではなくクライアントでナビゲートされる個別のページ状態を表すためです。たとえば、リロードはsameリソースをロードし、ハッシュ値の読み取り、解析、処理が可能になります。
たまたま、ページを更新せずに履歴をサーバー側の場所に変更するためにまた使用されている（特にFacebookとTwitterで）を使用していることがあります。 これらのユースケースでは、人々はpushStateのハッシュバンを放棄することを推奨しています。
すべてのコンテンツをクライアント側でレンダリングする場合、pushStateは、より便利な履歴APIの一部であり、ハッシュバンを使用する方法ではないと考える必要があります。
PushStateと#!についてのおもしろい話はすべてありますが、元のポスターが求めるように、pushStateが＃！の目的をどのように置き換えるかはまだわかりません。
もちろん、99％JavaScriptベースのAjaxサイト/アプリケーションをSEO可能にするためのソリューションは、#!を使用しています。クライアントレンダリングはHTML、JavaScript、およびPHPを介して行われるため、ページランディングによって制御されるローダーで次のロジックを使用します。HTMLファイルはJavaScriptおよびPHP両方に同じHTMLが必要なため（ほとんどの場合）。JavaScriptとPHPはほとんど同じことを行いますが、PHP JavaScriptははるかにリッチなユーザーエクスペリエンスであるため、複雑さは軽減されます。
JavaScriptはjQueryを使用して、必要なコンテンツをHTMLに注入します。 PHPはPHPQueryを使用して、必要なコンテンツをHTMLに挿入します。「ほぼ」同じロジックを使用しますが、PHPバージョンSEOableリンクを含むSEOableバージョンを表示し、JavaScriptバージョンのように対話しないようにします。
すべてのページを構成する3つのコンポーネント、page.htm、page.js、page.phpは、エスケープされたフラグメントを使用してPHPバージョンの代わりにJavaScriptバージョン。PHPバージョンは、SEO不可能なコンテンツ（ユーザーのログイン後にのみ表示できるページなど）に存在する必要はありません。すべては簡単です。
フロントエンドのデベロッパーが、ブラウザ側とサーバー側のテクノロジーを併用せずに（Google Docsの豊富な）すばらしいサイトを開発するのを逃れる方法についてはまだ疑問です。JavaScriptが有効になっていない場合、99％のJavaScriptソリューションもちろん、PHPがなければ、何もしません。
JavaScriptが有効になっている場合は、PHP提供ページに移動し、JavaScriptバージョンにリダイレクトするNice URLを持つことができますが、ユーザーの観点から見ると、Niceではありません。聴衆。
サイドノートに。 JavaScriptを使用せずに機能する単純なWebサイトを作成している場合、単純に静的にレンダリングされたコンテンツからユーザーエクスペリエンスを次第に向上させたい場合、しかしユーザーに外出先からの最高の体験... JavaScriptやGoogle Docsなどで書かれた最新のゲームを考えてみましょう。このソリューションでの使用は、ユーザーエクスペリエンスがビジョンと比較して痛みを伴う前にしかうまく行かないため、ある程度制限されますサイトの。