82

多くの人が、hashbang ではなく pushState を使用すると言っています。

私が理解できないのは、hashbang を使用せずに検索エンジン フレンドリーにするにはどうすればよいかということです。

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

したがって、シナリオは次のとおりです。

私はオンexample.comです。ユーザーがリンクをクリックします:href="example.com/blog"

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

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

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

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

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

4

3 に答える 3

98

pushStateコンテンツを読むために検索エンジンが必要だとしたら、それは悪いことですか?

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

あなたは言う：

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

言い換えれば、

  1. Google は次へのリンクを認識しますexample.com/#!/blog
  2. Google リクエストexample.com/?_escaped_fragment_=/blog
  3. ユーザーに表示するコンテンツのスナップショットを返す

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

では、Google は pushState で何かをどのように認識するのでしょうか?

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

実際には、Google は でリクエストできるものを確認しsite.com/blogます。URL は引き続きサーバー上のリソースを指し、クライアントは引き続きこのコントラクトに従います。もちろん、最新のクライアントにとって、Javascript は、ページを更新せずにコンテンツを取得して対話する新しい可能性を切り開きましたが、コントラクトは同じです。

したがって、 の意図する優雅さはpushState、新旧、JS 対応、非対応のすべてのユーザーに同じコンテンツを提供することですが、新しいユーザーは強化されたエクスペリエンスを得ることができます。

Google にコンテンツを表示するにはどうすればよいですか?

  1. Facebook のアプローチ —状態site.com/blogにプッシュしたときにクライアント アプリが変換される URL で同じコンテンツを提供します/blog。(Facebook はpushState私が知っていることをまだ使用していませんが、ハッシュバングでこれを行います)

  2. Twitter のアプローチ — すべての着信 URL を同等の hashbang にリダイレクトします。つまり、「/blog」へのリンクが/blog状態にプッシュされます。しかし、直接リクエストされた場合、ブラウザは#!/blog. (Googlebot の場合、これは必要に応じてルーティングさ_escaped_fragment_れます。他のクライアントの場合はpushState、きれいな URL に戻ることができます)。

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

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

エスケープされたフラグメントは完全に異なります。テーマのない純粋なコンテンツやキャッシュされたコンテンツを提供でき、通常のページのような負荷をかけずに済みます。

理想的な解決策は、Google が JavaScript サイトを作成するか、pushstate サイト (robots.txt?) でもエスケープされたフラグメント URL があることを認識する何らかの方法を実装することです。

あなたが言及した利点は、に限定されていません_escaped_fragment_。それがあなたのために書き換えを行い、特別な名前のGETパラメーターを使用することは、実際には実装の詳細です。標準の 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 で実際に説明されておらず、基本的に下位互換性がないというだけです。

現時点では、これがまさにハッシュバングの目的です。つまり、サーバーではなくクライアントでナビゲートされる個別のページ状態を表すことです。たとえば、リロードは同じリソースをロードし、ハッシュ値の読み取り、解析、および処理を行うことができます。

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

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

于 2011-05-31T22:49:05.070 に答える
17

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 を書き換えますが、これが完全に保証され、将来的に保証されるかどうかはわかりません。Google がこの種の行為に対して人々に罰を与える可能性もあるかもしれませんが、私はそれを十分に調査していません. したがって、(pushstate + Google のメタ タグ) の組み合わせが解決策のようです。

于 2012-09-06T02:51:24.990 に答える
2

pushState と に関するすべての興味深い話です#!が、元のポスターが要求するように、 pushState が #! の目的をどのように置き換えるかはまだわかりません。

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

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

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

一部のフロントエンド開発者が、サーバー側の技術をブラウザーの技術と組み合わせて使用​​せずに (Google Docs の豊富な機能を備えた) 優れたサイトを開発する方法をどうやって切り抜けているのか、いまだに困惑しています... JavaScript が有効になっていない場合でも、私たちの 99% JavaScript ソリューションもちろん、PHP がなければ何もしません。

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

余談ですが。JavaScript なしで機能する単純な Web サイトを作成している場合、単純な静的にレンダリングされたコンテンツからより良いものへとユーザー エクスペリエンスを段階的に強化したい場合、pushState が役立つことがわかります。外出先から最高の体験を得る... JavaScript や Google Docs のようなもので書かれた最新のゲームを考えてみましょう。このソリューションの使用は多少制限されます。これは、適切にフォールバックできるのは、ユーザー エクスペリエンスがビジョンと比較して苦痛になる前に限られるためです。サイトの。

于 2016-05-31T08:05:25.990 に答える