pushStateとSEO

Question 1

多くの人が、ハッシュバンではなくプッシュステートを使用すると言っています。

私が理解していないのは、ハッシュバンを使用せずに検索エンジンにどのように対応できるかということです。

おそらく、pushStateコンテンツはクライアント側のJavaScriptコードによって生成されます。

したがって、シナリオは次のようになります。

私は上にいexample.comます。ユーザーがリンクをクリックします：href="example.com/blog"

pushStateはクリックをキャプチャし、URLを更新し、どこかからJSONファイルを取得し、コンテンツ領域にブログ投稿のリストを作成します。

ハッシュバンを使用すると、Googleはescaped_fragmentURLにアクセスして静的コンテンツを取得することを認識しています。

pushStateを使用すると、JavaScriptコードを使用してJSONをロードし、続いてテンプレートを作成できないため、Googleは何も認識しません。

私が見ることができる唯一の方法は、サーバー側でテンプレートをレンダリングすることですが、それはアプリケーション層をクライアントにプッシュする利点を完全に打ち消します。

だから私はこれを正しく理解していますか、pushStateはクライアントサイドアプリケーションにとってSEOフレンドリーではありませんか？

Question 2

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のメタタグ）コンボが解決策のようです。

Question 3

である`pushState`あなたがあなたのコンテンツを読むために検索エンジン必要があれば悪いですか？

いいえ、話pushStateはハッシュバングと同じ一般的なプロセスを達成することを目的としていますが、見栄えの良いURLを使用しています。ハッシュバンを使用すると実際に何が起こるかを考えてください...

あなたは言う：

ハッシュバンを使用すると、Googleはescaped_fragmentURLにアクセスして静的コンテンツを取得することを認識しています。

つまり、言い換えれば、

Googleはへのリンクを見ています example.com/#!/blog
Googleのリクエスト example.com/?_escaped_fragment_=/blog
あなたは、ユーザーが見るべきコンテンツのスナップショットを返します

ご覧のとおり、すでにサーバーに依存しています。 サーバーからコンテンツのスナップショットを提供していない場合は、サイトのインデックスが適切に作成されていません。

では、GoogleはpushStateで何かをどのように見るのでしょうか？

pushStateを使用すると、javascriptを使用してjsonをロードし、その後テンプレートを作成できないため、googleは何も表示しません。

実際、Googleはで要求できるものは何でも見るでしょうsite.com/blog。URLは引き続きサーバー上のリソースを指し、クライアントは引き続きこの契約に従います。もちろん、最近のクライアントの場合、Javascriptは、ページを更新せずにコンテンツを取得して操作するための新しい可能性を開きましたが、契約は同じです。

したがって、意図されたエレガンスはpushState、古いものと新しいもの、JS対応であるかどうかにかかわらず、すべてのユーザーに同じコンテンツを提供することですが、新しいユーザーは拡張されたエクスペリエンスを取得します。

どのようにしてGoogleにあなたのコンテンツを見てもらうのですか？

Facebookのアプローチ—状態にsite.com/blogプッシュ/blogしたときにクライアントアプリが変換するのと同じコンテンツをURLで提供します。（FacebookはpushState私が知っていることをまだ使用していませんが、ハッシュバンでこれを行っています）
Twitterのアプローチ—すべての受信URLを同等のハッシュバンにリダイレクトします。言い換えれば、「/ blog」へのリンク/blogは状態にプッシュします。ただし、直接要求された場合、ブラウザはで終了し#!/blogます。（Googlebotの場合、これは_escaped_fragment_必要に応じてルーティングされます。他のクライアントの場合はpushState、きれいなURLに戻ることができます）。

それで、あなたは`_escaped_fragment_`能力を失い`pushState`ますか？

いくつかの異なるコメントで、あなたは言った

エスケープされたフラグメントは完全に異なります。純粋なテーマのないコンテンツ、キャッシュされたコンテンツを提供でき、通常のページのような負荷にさらされることはありません。

理想的な解決策は、GoogleがJavaScriptサイトを実行するか、プッシュステートサイト（robots.txt？）に対してもエスケープされたフラグメントURLがあることを知る何らかの方法を実装することです。

あなたが言及した利点は、に分離されていません_escaped_fragment_。書き換えを行い、特別な名前のGETパラメータを使用することは、実際には実装の詳細です。あなたは、標準のURLを行うことができなかったということについては本当に特別なものは何もありません-つまり、書き換え/blogに/?content=/blog使用して、独自にmod_rewriteをしたり、サーバの同等のものを。

サーバー側のコンテンツをまったく提供しない場合はどうなりますか？

URLを書き換えて、ある種のコンテンツを/blog（またはブラウザーにプッシュした状態で）提供できない場合、サーバーは実際にはHTTPコントラクトに準拠していません。

ページのリロード（何らかの理由で）はこのURLのコンテンツをプルするため、これは重要です。（https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Reviewを参照してください—「ビューソースとリロードはどちらも、プッシュされた場合、新しいURIでコンテンツをフェッチします。」）

クライアント側で一度ユーザーインターフェイスを描画し、JS APIを介してコンテンツを読み込むことが悪い目標であるというわけではありません。それは、HTTPとURLで実際に考慮されておらず、基本的に下位互換性がないということです。

現時点では、これはハッシュバンが意図されている正確なことです—サーバーではなくクライアント上でナビゲートされる個別のページ状態を表すためです。たとえば、リロードは同じリソースをロードし、ハッシュ値の読み取り、解析、処理を行うことができます。

たまたま、ページを更新せずに履歴をサーバー側の場所に変更するために（特にFacebookやTwitterで）使用されていることもあります。 人々がpushStateのハッシュバンを放棄することを推奨しているのはこれらのユースケースです。

すべてのコンテンツをクライアント側でレンダリングする場合pushStateは、ハッシュバンを使用する方法ではなく、より便利な履歴APIの一部として考える必要があります。

Question 4

pushStateとについての興味深い話はすべて#!、元の投稿者が尋ねているように、pushStateが＃！の目的をどのように置き換えるのかまだわかりません。

#!もちろん、99％のJavaScriptベースのAjaxサイト/アプリケーションをSEOableにするためのソリューションを使用しています。クライアントのレンダリングはHTML、JavaScript、PHPを介して行われるため、ページのランディングによって制御されるローダーで次のロジックを使用します。HTMLファイルはJavaScriptとPHPから完全に分離されています。これは、両方で同じHTMLが必要なためです（ほとんどの場合）。JavaScriptとPHPはほとんど同じことを行いますが、JavaScriptははるかに豊富なユーザーエクスペリエンスであるため、PHPコードはそれほど複雑ではありません。

JavaScriptはjQueryを使用して、必要なコンテンツをHTMLに挿入します。PHPはPHPQueryを使用して必要なコンテンツをHTMLに挿入します-「ほぼ」同じロジックを使用しますが、PHPバージョンはSEOableリンクを含むSEOableバージョンを表示するためにのみ使用され、JavaScriptバージョンのように操作されないためはるかに単純です。

ページを構成する3つのコンポーネント、page.htm、page.js、page.phpはすべて、エスケープされたフラグメントを使用してJavaScriptバージョンの代わりにPHPバージョンをロードするかどうかを知るために存在します。PHPバージョンは、SEO不可能なコンテンツ（ユーザーのログイン後にのみ表示されるページなど）には存在する必要はありません。すべてが簡単です。

一部のフロントエンド開発者が、サーバー側のテクノロジーをブラウザーのテクノロジーと組み合わせて使用せずに、優れたサイト（Googleドキュメントの豊富さを備えた）を開発する方法にまだ戸惑っています...もちろん、PHPが配置されていないと何も起こりません。

JavaScriptが有効になっている場合は、PHPで提供されるページにアクセスしてJavaScriptバージョンにリダイレクトするための適切なURLを設定できますが、ユーザーがより重要なオーディエンスであるため、ユーザーの観点からは適切ではありません。

ちなみに。JavaScriptなしで機能できる単純なウェブサイトを作成している場合、静的にレンダリングされた単純なコンテンツからより良いものにユーザーエクスペリエンスを段階的に強化したい場合は、pushStateが役立つことがわかりますが、ユーザーに外出先からの最高の体験... JavaScriptまたはGoogleドキュメントのようなもので書かれた最新のゲームを考えてみましょう。このソリューションでの使用はやや制限されています。サイトの。