pushStateが分析のために利用できないときに無限スクロールページのURLを変更するように見えるための回避策
私はウェブサイトを構築していますが、彼らは無限スクロールの単一ページデザインであり、できるだけSEOに優しいものにしたいと考えています。
例を挙げます。
URL構造の例を次に示します。
com
com＃something
com＃something1
com＃something2
しかし、個々のページに分解された場合、URL構造は次のようになります。
com
com/something
com/something1
com/something2
それで、私はここで何をすることになっていますか？
以前にjQueryのpushState機能を使用しました。これにより、スクロールページをさまざまなページのようなセクションに分割できます。これらのセクションは、一意のURLとメタデータを使用してSERPで識別できます。
ここではpushStateを使用できません。これは非常に大きなページであり、取得可能な分析が必要だからです。
回避策はありますか？
まず、視差は視覚効果です。あなたが求めているのは、単一の「無限に」スクロールするページ、または単一ページのアプリケーションです。
私が正しく理解していれば、pushStateを使用したくありません。分析データが失われると思うからです。 GoogleアナリティクスではSPAのセットアップについて説明しています と考えている理由がわかりません。
そうは言っても、それが「本当に大きなページ」であり、SEOと分析が非常に重要な場合、SPAが最善のアプローチであるかどうか疑問に思います。エンジニアリングの問題は別として、Google以外の検索エンジンはAJAXおよび同様の構成のクロールに苦労しています。あなたがそれを気にする程度は、もちろんあなたが働いている市場の検索エンジンの市場シェアに依存します。
SPAのhighly説得力のある、ユーザーの経験に基づいた議論がない限り、なぜ問題に直面するのでしょうか？
ブラウザーの戻るボタンと進むボタンを使用できるようにするだけでなく、検索エンジンのユーザーが各記事に個別にアクセスできるようにするために、ページに相当するURLをクライアントの閲覧履歴にプッシュできます。
ただし、Googleのような検索エンジンは重複コンテンツにも関心があります。同じコンテンツを複数のページに（複数のURLを介して）表示する場合、どのページが先頭（正規）であるかを宣言する必要があります。
同じメインページに複数の記事のコンテンツを表示すると、それが難しいことがわかります。
その場合は、無限スクロールの概念をアクセス可能かつSEOフレンドリーにするためのソリューションを検討することをお勧めします。それらは、表示されたサブページを閲覧履歴にプッシュします。