ページネーションされたページがインデックスされない：Google向けの現代的なページネーション戦略
Googleはrel=prev/nextを廃止し、ページネーションされたコンテンツがインデックスから外れています。Googleの現在のインデックス動作で機能する現代的なページネーション戦略を学びましょう。
このガイドの内容
ページネーションはウェブのいたるところにあります。ブログアーカイブ、ECサイトのカテゴリーページ、検索結果リスト、フォーラムのスレッドインデックス、ニュースアーカイブ、画像ギャラリーはすべて、大量のコンテンツセットを管理可能なページに分割するためにページネーションを使用しています。長年、標準的なアプローチは、一連のページがページネーションされたシリーズを形成していることをGoogleに伝えるためにrel=prevとrel=nextタグを実装することでした。その後、Googleは関係を理解し、インデックスシグナルを適切に統合していました。
2019年3月、Googleはrel=prev/nextを長年インデックスシグナルとして使用していなかったことを確認しました。多くのサイトがページネーション戦略全体をこれらのタグを中心に構築していたため、この発表はSEO業界を不意打ちにしました。実用的な影響は即時でした。rel=prev/nextがなければ、Googleはページネーションされた各ページを接続されたシリーズの一部としてではなく、独立した単独のページとして扱います。
この変更は、ブログアーカイブの2ページ目がGoogleによって完全に自身のメリットに基づいて評価されることを意味します。2ページ目に、ユニークな紹介コンテンツがない、ユニークな見出しがない、ページが何についてかを説明する文脈がない状態でブログ記事の抜粋のリストが表示される場合、Googleはリサイクルされたコンテンツスニペットを持つ薄いページとしてそれを見ます。Googleがこれらのページのインデックスを頻繁に選択しないことは、驚くことではないでしょう。
結果はページネーションされたページ自体を超えて広がります。深いページネーションページにのみ表示されるコンテンツは、Googleが発見しにくくなります。商品やブログ記事がリストの1ページ目に取り上げられず、他のどこからもリンクされていない場合、それは事実上、Googleが決してクロールしない孤立になる可能性があります。これにより、ページネーションは単にリストページの問題ではなく、サイト全体のコンテンツ発見の問題になります。
本ガイドでは、Googleの現在のインデックス動作で機能する現代的なページネーション戦略を扱い、無限スクロールとLoad Moreパターンの具体的な課題に対処し、rel=prev/nextが機能しなくなったときに失われたコンテンツを回復するための具体的な修正を提供します。
Googleがrel=prev/nextを廃止したときに何が変わったか
ページネーションのインデックスの現状を理解するためには、rel=prev/nextが何をするはずだったか、そしてGoogleが実際に今何をしているかを知ることが役立ちます。
rel=prev/nextは、一連のページがページネーションされたシーケンスとして接続されていることをGoogleに伝えるHTMLのlink要素のセットでした。意図は、Googleがページを統合し、ページ1、ページ2、ページ3などが連続したセットを形成していることを理解することでした。理論的には、Googleはシリーズを単一の論理エンティティとして扱い、リンクエクイティを統合し、コンテンツが後続のページにわたって続いていることを理解しながら、検索結果には最初のページのみを表示する可能性がありました。
Googleがこれらのシグナルを長年使用していなかったことを明らかにしたとき、その含意は明確でした。Googleはページネーションを理解するために他のシグナルに依存していました。これらのシグナルには、URLパターン（Googleは?page=2や/page/2/のような一般的なページネーションパターンを検出できます）、内部リンク構造（ページ間のシーケンシャルリンクはページネーションを示唆します）、コンテンツ分析（類似のテンプレートと異なるコンテンツサブセットを持つページはページネーションされたリストを示唆します）が含まれます。
動作の実用的な変化は、Googleが現在、ページネーションされた各ページを独立して評価することです。ユニークな紹介段落、強力な内部リンク、20の注目商品を持つカテゴリーのページ1はインデックスされる可能性があります。次の20の商品をユニークなコンテンツなしで表示するページ2は、単独のページとして評価され、それ自体で十分なユニークな価値を提供しないためインデックスされない可能性があります。
この独立した評価は、ページ1を超えるページネーションされたページが、何らかのユニークな価値提案を持たない限り、めったにインデックスされないことを意味します。ページ2にリストされているアイテムはページ1とは異なりますが、テンプレート、ナビゲーション、メタ情報、全体的な構造は同一です。Googleの観点から、ページ2はページ1の薄いバリエーションです。
rel=prev/nextの統合の喪失は、リンクエクイティがページネーションされたページ全体で統合されなくなることも意味します。以前は、カテゴリーのページ3を指すバックリンクは、ページネーションされたシリーズ全体に恩恵をもたらした可能性があります。今、そのリンクエクイティはページ3のみに留まります。ページ3がインデックスされていない場合、リンクエクイティは事実上無駄になります。
ページネーションに対するGoogleの現在の推奨は、重要な個々のコンテンツページ（商品、記事、投稿）が、ページネーションを唯一の発見パスとして頼るのではなく、sitemapとサイト上の他のページから直接リンク可能であることを確認することです。ページネーションは現在、SEO機能というより、主にユーザーエクスペリエンス機能です。
無限スクロール：見えないコンテンツの問題
無限スクロールは、ユーザーが下にスクロールするにつれて新しいコンテンツが自動的にロードされるパターンで従来のページネーションを置き換えます。ユーザーはシームレスで終わりのないフィードを体験します。SEOの観点から、無限スクロールは最も問題のあるページネーションパターンの1つです。なぜならGoogleのクローラーはスクロールしないからです。
Googlebotが無限スクロールのページをロードするとき、初期HTMLと最初のロードで表示されるJavaScriptレンダリングコンテンツを処理します。スクロールイベントをトリガーしないため、ユーザーが特定のしきい値を超えてスクロールしたときにロードされるコンテンツは、Googleには完全に見えません。カテゴリーページが最初のロードで20の商品を表示し、残りの200の商品に無限スクロールを使用する場合、Googleは20の商品のみを見ます。
これはコンテンツ発見に深刻な影響を与えます。無限スクロールを介してのみ表示される商品や投稿は、カテゴリーページからのクロールパスがありません。他のページからリンクされていないか、sitemapに含まれていない場合、Googleはそれらを決して発見しない可能性があります。sitemapに含まれていても、カテゴリーページ自体がこれらのアイテムへの内部リンクを提供しないため、認識される重要性が弱まります。
推奨される修正は、従来のページネーションされたURLと一緒に無限スクロールを実装することです。このハイブリッドアプローチは、無限スクロールのスムーズなユーザーエクスペリエンスを提供しながら、実際のURLを持つクロール可能なページネーションされたページをGoogleに提供します。実装は次のように機能します。各無限スクロールセグメントと同じコンテンツセットを表示する従来のページネーションURL（/category/page/2/、/category/page/3/）を作成します。ユーザーがスクロールして新しいコンテンツがロードされるときに、History APIを使用してブラウザのURLを対応するページネーションURLに更新します。ユーザーがリフレッシュまたはURLを共有する場合、スクロールしていたコンテンツを含むページネーションバージョンが表示されます。
Googleは無限スクロールのためにこのpushStateアプローチを具体的に推奨しています。ページネーションされたURLは、Googleがクロールできるアンカーポイントとして機能し、無限スクロールは訪問者が期待するユーザーエクスペリエンスを提供します。基礎となるページネーションURLがないと、無限スクロールは最初の可視セットを超えるすべてのコンテンツをGoogleから完全に隠します。
小規模なコンテンツセットの代替アプローチは、ページネーションやスクロールベースのロードなしですべてのコンテンツを単一のページにロードすることです。カテゴリーに50以下の商品がある場合、それらすべてを単一のページにレンダリングすると、ページネーションの問題が完全になくなります。このアプローチは、パフォーマンスの制約により、数百または数千のアイテムを持つカテゴリーには実行できませんが、小規模なコレクションにはうまく機能します。
Load Moreボタン：無限スクロールより良いが、それでも問題あり
Load Moreボタンは、従来のページネーションと無限スクロールの中間です。ユーザーは初期のコンテンツセットを表示し、同じページに追加のコンテンツをロードするためにボタンをクリックします。ユーザーエクスペリエンスの観点から、Load Moreは同じページにユーザーを保ち、スクロール位置を維持するため、しばしば従来のページネーションよりも好まれます。
しかし、Load Moreボタンには、無限スクロールと同じ根本的なSEO問題があります。Googleはボタンをクリックしません。Load Moreボタンによってロードされるコンテンツは、クリックイベントによってトリガーされ、Googleのレンダラーはクリックインタラクションをシミュレートしません。特定の対策が取られない限り、Load Moreボタンの背後のコンテンツはGoogleには見えません。
修正は無限スクロールのソリューションを反映しています。Load More機能と一緒に従来のページネーションURLを実装してください。各Load Moreセグメントは、クロール可能なページネーションURLに対応する必要があります。Googleがそれらを発見してクロールできるよう、HTMLのどこかにこれらのページネーションURLへのリンクを含めてください（ビジュアルデザインからCSSを使用して非表示にすることができます）。一部の実装では、JavaScriptを実行しないクローラーが利用できるよう、ページネーションリンクをnoscriptタグに配置し、JavaScript対応ブラウザにはLoad Moreボタンが表示されます。
別のアプローチは、Load Moreコンテンツを初期HTMLレスポンスでレンダリングしますが、CSSで視覚的に非表示にすることです。ユーザーがLoad Moreをクリックすると、サーバーから取得するのではなく、JavaScriptが非表示のコンテンツを表示します。このアプローチは、ボタンとのインタラクションを必要とせずに、Googleが初期HTMLですべてのコンテンツを見ることを保証します。ただし、これは中程度の量の非表示コンテンツでのみ機能します（200の商品を非表示のHTMLでロードすると、ページの重量とロード時間が大幅に増加します）。
3つ目のアプローチは、ページネーションURLを段階的にロードするLoad Moreを実装することです。初期ページは最初のコンテンツセットとLoad Moreボタンとともにロードされます。ボタンをクリックすると、AJAXを使用して次のコンテンツセットを取得して表示し、同時にURLを次のページネーションページ（/page/2/）に更新します。各ページネーションURLは、特定のコンテンツセットをサーバー側でレンダリングするため、Googleはボタンをクリックすることなく/page/2/を直接クロールしてそのコンテンツを見ることができます。Load Moreボタンはユーザー向けのプログレッシブエンハンスメントであり、基礎となるページネーションURL構造はGoogle向けのクロール可能な基盤です。
ページネーションシリーズのcanonicalタグ戦略
ページネーションされたページのcanonicalタグは、技術的SEOで最も議論されているトピックの1つです。問題は、ページ2、ページ3、および後続のページがページ1を指すcanonicalタグを持つべきか、それとも各ページが自己参照canonicalを持つべきかです。
すべてのページネーションされたページをページ1にcanonicalとして指すことは、ページ1が決定的なバージョンであり、他のページは二次的であることをGoogleに伝えます。このアプローチは、深いページがインデックスされることを望まない、または必要としない場合、およびすべての個別のアイテムが他の手段（sitemap、直接リンク）を通じて発見可能な場合に適しています。利点はシンプルさです。Googleはページ1のみをインデックスし、深いページの薄いコンテンツの問題について心配する必要はありません。リスクは、深いページにのみ表示されるアイテムが、ページネーションされたリストからの内部リンクシグナルを失う可能性があることです。
各ページネーションされたページの自己参照canonicalは、各ページが独自の異なるエンティティであることをGoogleに伝えます。このアプローチは、各ページネーションされたページが異なるコンテンツをターゲットとしている場合、またはGoogleにシリーズ内のすべてのページをインデックスさせたい場合に適しています。利点は、各ページが独自のリンクエクイティを保持し、検索結果に表示される可能性があることです。リスクは、Googleが深いページを薄いコンテンツとして見て、それらをインデックスしないことを選択する可能性があることです。
ほとんどのサイトにとって実用的な推奨は、ハイブリッドアプローチです。ページ1は自己参照canonicalと最適化努力（ユニークな紹介コンテンツ、適切なメタタグ、注目アイテム）を取得します。ページ2〜5は自己参照canonicalを取得しますが、二次的に扱われます（最適化の優先度が低く、一部がインデックスされない可能性を受け入れる）。ページ6以降は、この深さのコンテンツは独自のメリットでインデックスされる可能性が低く、クロールバジェットは他の場所でより良く使われるため、ページ1を指すcanonicalタグを取得します。
canonical戦略に関係なく、すべての個別のアイテムページ（商品、投稿、記事）が直接URLでXML sitemapに含まれていることを確認してください。sitemapは、ページネーションに依存しない独立した発見パスを提供します。Googleがカテゴリーのページ7を決してインデックスしなくても、ページ7に表示される商品はsitemapを通じて発見されインデックスされる可能性があります。
深いページネーションのクロールバジェットへの影響
深いページネーションは、コンテンツリストが数十または数百のページにわたる場合、コンテンツの多いウェブサイトで最も重要なクロールバジェットのドレインの1つです。各ページネーションされたページは、Googleがクロール、評価し、潜在的にインデックスを試みる可能性のあるURLです。各カテゴリーに20ページのページネーションを持つ100のカテゴリーを持つサイトは、実際のコンテンツページURLに加えて、2,000のページネーションされたリストURLを生成します。
Googleのクロールスケジューラーは、これらすべてのURLにわたって限られたクロールリソースをどのように割り当てるかを決定する必要があります。ページネーションされたリストページが実際のコンテンツページよりも多い場合、Googleはコンテンツではなく、実際にインデックスしたいリストページにクロールバジェットの大部分を費やす可能性があります。これは、商品ページが収益を生み出すコンテンツであるが、Googleがカテゴリーリストのページネーションのクロールと再クロールに時間を費やしているECサイトに特に問題があります。
ページネーションによるクロールバジェットの浪費の診断シグナルは、Google Search Consoleのクロール統計にあります。クロールされたページの量が多いがインデックスされたページの割合が低い場合、ページネーションの肥大化が原因である可能性があります。Googleが最も頻繁にクロールするURLをエクスポートし、ページネーションされたリストURLと実際のコンテンツページの割合を確認してください。
いくつかの戦略により、深いページネーションのクロールバジェットへの影響を軽減できます。まず、クロール可能なページネーションの深さを制限します。robots.txtを使用して、特定の深さを超えるページネーションされたページのクロールをブロックします（たとえば、/page/6/以降をブロック）。または、深いページにnoindex,followタグを追加して、Googleがそれらをインデックスしないが個々のアイテムへのリンクをたどることができるようにします。次に、合計ページネーションの深さを減らすために、ページあたりのアイテム数を減らします。20の代わりに50のアイテムを表示すると、20ページのカテゴリーが8ページのカテゴリーになります。3つ目に、ページの重量が許す場合は、カテゴリーにView Allページを実装して、ページネーションを完全に排除します。
頻繁に変更される動的ページネーション（毎日追加される新製品、再シャッフルされるトレンドアイテム）の場合は、特定の日にページネーションされたリストにそれらのURLがどのように表示されるかに関係なく、Googleが独自のペースでクロールできるすべての個別コンテンツURLの完全なリストを提供するsitemapを主要な発見メカニズムとして保持してください。
もう1つの技術は、ページ1への内部リンクを強化し、深いページネーションへのリンクを弱めることで、各カテゴリーのページ1に向けてクロールバジェットを優先することです。サイトナビゲーションは各カテゴリーのページ1にリンクします。ブログ投稿および他のコンテンツからの内部リンクはページ1を指します。ホームページの注目商品または注目投稿セクションはページ1にリンクします。これらの強力な内部リンクは、ページ1が各カテゴリーで最も優先度の高いリストURLであることをGoogleにシグナルします。
ステップバイステップガイド
サイト全体の現在のページネーション実装を監査する
サイトをクロールし、すべてのページネーションURLパターンを特定します。一般的なパターンには、/page/2/、?page=2、/p2、?start=20があります。ページネーションされたリストURLの総数を、実際のコンテンツページURLと比較してカウントしてください。「site:」演算子とページネーションURLパターンを使用して、現在インデックスされているページネーションされたページを確認します。最も深いページネーションを持つカテゴリーまたはセクションを特定してください。ページネーションされたページの現在のcanonicalタグの動作、robots.txtルール、noindexステータスを文書化します。このベースライン監査は、ページネーションの問題の範囲を明らかにし、優先順位付けを導きます。
ページネーションを超えたコンテンツ発見パスを確認する
各個別のコンテンツページ（商品、記事、投稿）が、ページネーション以外の少なくとも1つのパスを通じて発見可能であることを確認します。すべてのコンテンツURLがXML sitemapにあることを確認してください。コンテンツページが他のコンテンツ（関連商品、関連投稿セクション）から内部リンクを受け取ることを確認してください。深いページネーションを通じてのみ発見可能で他の内部リンクを持たないコンテンツページを見つけるために、孤立ページ分析を実行してください。孤立したコンテンツについては、関連ページまたは注目セクションから内部リンクを追加して、代替の発見パスを作成してください。
無限スクロールまたはLoad Moreのためのクロール可能なURLを実装する
サイトが無限スクロールまたはLoad Moreボタンを使用している場合、各コンテンツセグメントに対応する基礎となるページネーションURLを実装します。History APIを使用して、ユーザーがスクロールまたはLoad MoreをクリックするにつれてブラウザのURLを更新してください。各ページネーションURLが、JavaScriptインタラクションを必要とせずにコンテンツをサーバー側でレンダリングすることを確認してください。ブラウザで/page/2/に直接アクセスし、正しいコンテンツセットが表示されることを確認することでテストしてください。Googleがそれらをディスカバーできるよう、これらのページネーションURLをHTML（フッターのページネーションリンクまたはnoscriptブロック内）に含めてください。
ページネーションされたページにcanonicalタグを設定する
選択したcanonical戦略を実装します。ほとんどのサイトでは、ページ1〜5に自己参照canonicalを使用し、ページ6以降にページ1を指すcanonicalを使用します。異なる深さでページネーションされたページのソースを表示することにより、canonicalタグを検証してください。canonical URLが正しいプロトコル（HTTPS）とドメイン形式（wwwまたは非www、推奨URL形式と一致）を使用していることを確認してください。CMSが自動的にcanonicalタグを生成する場合、ページネーションされたページの自動タグが正しいことを確認してください。一部のCMSプラットフォームは、深さに関係なくすべてのページネーションされたページを誤って自己参照します。
各ページネーションシリーズのページ1を最適化する
ページ1がインデックスされる可能性が最も高いページネーションページであるため、それを可能な限り強くするために投資してください。ページ1にのみ表示されるユニークな紹介コンテンツ（カテゴリーの説明、購入ガイド、トピック概要）を追加します。ページ1に独自のキーワード最適化されたタイトルタグとmeta descriptionがあることを確認してください。手動キュレーションまたはアルゴリズムソートを通じて、最も重要なアイテムをページ1に表示します。Googleがリスト形式を理解するのに役立つよう、ページ1に構造化データ（ItemList schema）を追加してください。ナビゲーション、パンくず、コンテンツページからページ1を指す内部リンクを強化してください。
深いページネーションに費やすクロールバジェットを制御する
深いページネーションのクロールバジェット制御を実装します。ページ5を超えるページネーションされたページ（または選択したしきい値）にnoindex,followタグを追加してください。これにより、Googleが深いページのリンクをたどって個々のコンテンツアイテムを発見できる一方、深いページ自体がインデックス枠を消費するのを防ぎます。非常に深いページネーション（20ページ以上）の場合は、その深さを超えるコンテンツ発見のためにsitemapに依存して、robots.txtのdisallowルールを追加してクロールを完全に防ぐことを検討してください。コントロールを実装した後、Search Consoleでクロール統計を監視して、クロールバジェットがリストページからコンテンツページにシフトしているかを確認してください。
主要なページネーションされたページと個別コンテンツをインデックスのために送信する
ページネーション修正を実装した後、各重要なカテゴリーまたはセクションのページ1をGoogle Search ConsoleのURL検査ツールを通じて送信してください。以前は深いページネーションを通じてのみ発見可能だった個別のコンテンツページについては、ページネーション位置に関係なくGoogleがそれらをインデックスすることを保証するためにIndexBoltを通じて送信してください。次の数週間にわたって、リストページと個別のコンテンツページの両方のインデックスを監視します。sitemapに含まれ直接内部リンクを持っているにもかかわらず、コンテンツページがインデックスされていない場合、ページネーションの文脈を超えて、ページ自体に品質または技術的な問題があるかどうかを調査してください。
よくある問題と解決方法
ページ1のアイテムはインデックスされているが、ページ2以降の商品／投稿がインデックスされない
原因： ページ1のアイテムは、カテゴリーページ（ナビゲーションからよくリンクされている）から強力な内部リンクシグナルを受け取ります。より深いページのアイテムは、それらが表示されるページネーションされたページに権威が少なくクロール頻度が低いため、より弱いシグナルを受け取ります。さらに、ページ1を超えるページネーションされたページがインデックスされていない場合、Googleはそれらのページ上のアイテムをページ1のアイテムよりも頻繁に発見しません。
解決方法： すべての個別のコンテンツページURLがXML sitemapにあることを確認し、ページネーションに依存しない発見パスを提供してください。重要なアイテムへの内部リンクを、ページネーションされていないコンテキストから追加します。関連商品セクション、ブログ投稿の言及、ホームページの注目アイテム、クロスセルウィジェットなどです。注目アイテムをローテーションして、異なる商品が時間の経過とともにページ1に表示されるようにすることを検討してください。深いページに固定されてオーガニックにインデックスされていない個別のアイテムURLを送信するためにIndexBoltを使用してください。
無限スクロールサイトで最初のバッチのアイテムのみがインデックスされる
原因： Googleはスクロールできないため、初期ページロードでレンダリングされたアイテムのみがGoogleに見えます。スクロールでトリガーされるJavaScriptリクエストによってロードされるアイテムは見えません。基礎となるページネーションURLがないと、Googleは最初の可視バッチを超えるコンテンツにアクセスする方法がありません。最初のスクロールロードを超えるアイテムは、Googleの観点から事実上存在しません。
解決方法： History APIのpushStateアプローチを使用して、無限スクロールと一緒にページネーションURLを実装します。各スクロールセグメントは、クロール可能なページネーションURLに対応する必要があります。Googleがたどることができるよう、ページネーションナビゲーションリンクをHTMLに含めてください。各ページネーションURLがコンテンツセットをサーバー側でレンダリングすることを確認してください。実装後、IndexBoltまたはSearch Consoleを通じてページネーションURLを送信し、Googleの新しいURL構造の発見を加速してください。
すべてのページネーションされたページがSearch Consoleで「重複、Googleが別の正規を選択」と表示される
原因： Googleはページネーションされたページを互いの重複として、またはページ1の重複として扱っています。これは、ページネーションされたページが同一のタイトルタグ、同一のmeta description、同一の紹介コンテンツを持ち、リストされているアイテムのみが異なる場合に発生します。Googleはそれらを別個のページではなく同じページのバリエーションと見なし、通常はページ1を正規として選択します。
解決方法： ページネーションされたページを独立してインデックスしたい場合は、それらを差別化してください。タイトルタグにページ番号を追加してください（「ランニングシューズ - 2ページ目 / 8ページ中」）。各ページネーションされたページに対してユニークなmeta descriptionを作成するか、ページ2以降からmeta descriptionを削除して、Googleがコンテンツから生成できるようにしてください。紹介コンテンツはページ1にのみ表示します。深いページのインデックスが必要ない場合は、ページ2以降にページ1を指すcanonicalタグを明示的に設定し、ページ1のみがインデックスされることを受け入れてください。
Load Moreボタンのコンテンツが時間とともにGoogleのインデックスから消える
原因： 以前は代替パス（古いsitemap、直接リンク）を通じてアクセス可能だったLoad Moreボタンの背後のコンテンツは、Googleがサイトを再評価するにつれてインデックスを失う可能性があります。Load MoreコンテンツがJavaScriptインタラクションなしにアクセス可能でなく、代替パスがもはや維持されていない場合、Googleはコンテンツにアクセスする現在の方法がなく、もはや存在を検証できない以前にインデックスされたアイテムをデインデックスする可能性があります。
解決方法： Googleが直接クロールできるサーバーレンダリングされたページネーションURLを実装します。これらのURLがsitemapにあり、リストページのHTMLからリンクされていることを確認してください。ページからJavaScriptを削除しても、ページネーションURLを通じてすべてのコンテンツにアクセスできることを検証してください。修正後、以前にデインデックスされたコンテンツのインデックスを復元するために、影響を受けたアイテムURLをIndexBoltを通じて送信してください。
プロのヒント
よくある質問
Googleはまだrel=prev/nextを全くサポートしていますか？+
いいえ。Googleは2019年3月に、数年間rel=prev/nextをランキングまたはインデックスシグナルとして使用していなかったことを確認しました。HTMLにこれらのタグを含めても害はありませんが、Googleに対する利点はありません。他の検索エンジン（Bing）はまだこれらのタグを使用する可能性があるため、それらを保持することは害になりませんが、Googleのインデックスのためにそれらに依存すべきではありません。Googleのためのページネーション戦略は、rel=prev/nextシグナルではなく、canonicalタグ、noindexディレクティブ、sitemapの含有、コンテンツ品質に基づく必要があります。
ページネーションを使う代わりに「View All」ページを作成すべきですか？+
すべてのアイテムを単一のページにリストするView Allページは、ページネーションを完全に排除するため、Googleにとって最もシンプルなソリューションです。Googleは、技術的に実現可能な場合、一般的にView Allページを好むと述べています。ただし、View Allページは小規模なコンテンツセット（100アイテム未満）でのみ実用的です。数百または数千のアイテムを持つカテゴリーの場合、View Allページはロードが遅すぎ、レンダリングにリソースが集中しすぎ、ユーザーには圧倒的すぎます。大規模なコンテンツセットの場合、従来のページネーションと包括的なXML sitemapを組み合わせたハイブリッドアプローチを使用してください。
Googleにページネーションをどのくらい深くクロールさせるべきですか？+
普遍的な答えはありませんが、実用的なガイドラインは、最初の3〜5ページのインデックスを許可し、深いページにはnoindex（followは許可）を許可することです。正確なしきい値は、ページネーションされたページの品質とサイトのクロールバジェットに依存します。サイトに強い権威があり、Googleが積極的にクロールしている場合、より深いインデックスを許可できます。サイトのクロールバジェットが限られている場合、ページ1のみにインデックスを制限し、コンテンツ発見にsitemapに依存してください。重要な指標は、より深いページネーションされたページが実際に検索表示回数を生成しているかどうかです。Search Consoleで、ページ5以上のURLが表示回数を受け取っているかどうかを確認してください。そうでない場合は、それらをnoindexにすることで、トラフィックへの影響なしにクロールバジェットを節約できます。
無限スクロールはAJAXを使用してコンテンツをロードします。GoogleはAJAXでロードされたコンテンツを認識できますか？+
Googleは、AJAXレスポンスを含むJavaScriptでロードされたコンテンツをレンダリングできますが、コンテンツのロードがユーザーインタラクション（スクロール、クリック）ではなく初期ページレンダリングによってトリガーされる場合のみです。ページロード時に自動的にロードされるAJAXコンテンツはGoogleに見えます。スクロールイベントに応答してロードされるAJAXコンテンツは、Googleのレンダラーがスクロールしないため、見えません。無限スクロールがスクロール位置に基づいてAJAXリクエストをトリガーする場合、そのコンテンツはGoogleには見えません。基礎としてサーバーレンダリングされたコンテンツを持つ基礎ページネーションURLを実装し、その上にユーザー用の無限スクロールAJAXエクスペリエンスをレイヤー化してください。
ページネーションのアイテムの順序はSEOに重要ですか？+
アイテムの順序は、ページ1のアイテムが深いページのアイテムよりも大幅に多くのクロールアテンションと内部リンク価値を得るため、主に重要です。Googleはページ10のコンテンツよりもページ1のコンテンツをクロールしてインデックスする可能性が高いです。インデックスして表示したい優先度の高いアイテムがある場合、手動キュレーション、ピン留め、または重要なアイテムを最初に表面化するソートアルゴリズムを通じて、それらがページ1に表示されることを確認してください。ECサイトの場合、ベストセラー、最高評価、最新でのソートは、しばしば自然に最も関連性の高い商品をページ1に表面化します。Googleが一貫性のないページコンテンツを評価するのが難しい場合があるため、ページロードごとに変わるランダムなソートは避けてください。
すべてのページネーションされたページにユニークなコンテンツを追加してインデックスに役立てるべきですか？+
すべてのページネーションされたページにユニークなコンテンツを追加することは、ほとんどのサイトにとって実用的でも必要でもありません。コンテンツ最適化の努力を、インデックスされる可能性が最も高く検索トラフィックにとって最も重要なページ1に集中させてください。ページ2〜5については、ページ番号付きの差別化されたタイトルタグで十分です。より深いページについては、それらをnoindexにし、ユニークなコンテンツについて心配しないでください。それらのページにリストされている個々のアイテムは、それぞれが独自のURLに独自のユニークなコンテンツを持つべきです。ページネーションされたリストページは、コンテンツの目的地ではなくナビゲーションメカニズムです。コンテンツ作成の努力をリストページではなく個々のアイテムに投資してください。