ウェブサイトの一覧ページで、無限スクロールや「もっと見る」ボタンを採用している場合、SEOの観点からインデックス漏れが発生しやすいことをご存知でしょうか？
これらの読み込み方式はユーザー体験を向上させますが、Googleのクローラーがコンテンツを正しく認識できないリスクがあります。
本記事では、「無限スクロール SEO」「load more SEO」「ページネーション SEO」「インクリメンタル ロード Google」などのキーワードで検索される開発者・SEO担当・メディア運営者向けに、Google推奨の実装方法を比較・解説します。
インデックスを確実にし、ロングテールキーワードからの早期流入を目指しましょう。
ページネーションの仕組みと最適化ポイントに関してはこちらをご覧ください。
- なぜボタン型・無限スクロールはインデックス漏れを招くのか
- Google推奨の実装モデル
- lazy-load画像／カードの注意点（可視域トリガ・LCP画像はeager）
- 検証手順：URL検査・レンダリングテスト・ログでbot命中確認
- よくある失敗例と修正パターン
なぜボタン型・無限スクロールはインデックス漏れを招くのか
Googleのクローラー（Googlebot）は、ウェブページを巡回する際、主に<a>要素のhref属性に記載されたリンクを基に新しいURLを発見します。 これは、HTMLの静的なリンクがクロールの基本であるためです。
一方、無限スクロールや「もっと見る」ボタンは、JavaScript（JS）を使ってコンテンツを動的に読み込むことが多く、ボタンのクリックやスクロールなどのユーザーアクションを前提としています。
これにより、問題が発生します。Googlebotはユーザーアクションをシミュレートせず、JS依存のコンテンツを即座に認識できない場合があります。
特に、初期HTMLにコンテンツがほとんどなく、JS実行後に表示される「app shellモデル」の場合、クロール時にコンテンツが欠落し、インデックス漏れや内部リンクの不全を招くのです。結果として、一覧ページの後半コンテンツが検索エンジンに拾われにくくなり、トラフィックの損失につながります。
たとえば、無限スクロールを実装したeコマースサイトの商品一覧では、スクロールで追加される商品がクロールされず、検索結果に表示されないケースが報告されています。 このような失敗を避けるため、Googleは静的なリンクを活用した実装を推奨しています。
Google推奨の実装モデル
Google for Developersのガイドラインに基づき、無限スクロールや「もっと見る」のSEO最適化には、ページ分割（pagination）やインクリメンタルロードを組み合わせたアプローチが有効です。
以下に、具体的なモデルを解説します。
コンポーネントURLを用意（/list?p=2 など）・自立した<title>とH1を付与
無限スクロールを検索フレンドリーにするためには、コンテンツをコンポーネントページに分割し、各ページに固有のURLを割り当てます。
例: /category?page=1, /category?page=2 など。
これにより、JSなしでも各ページにアクセス可能になり、Googlebotが<a href>で次ページをクロールできます。
各ページには、一意の<title>タグとH1見出しを付与しましょう。
たとえば、ページ1のタイトルを「楽しいアイテム一覧 - ページ1」、ページ2を「楽しいアイテム一覧 - ページ2」とする。
これで、各ページが独立したエンティティとしてインデックスされ、重複コンテンツを避けられます。
また、パンくずリストや前・次リンクを明示的に追加し、内部リンクを強化します。
パンくずリストとページネーションの最適化に関してはこちらをご覧ください。
パンくずリストのSEO効果と構造化データに関してはこちらをご覧ください。
「もっと見る」でも裏でaリンクを用意し、プログレッシブエンハンスでJS読み込み
「もっと見る」ボタンを実装する場合、裏側で<a href>リンクを準備し、プログレッシブエンハンスメントを適用します。
つまり、JSが無効でも静的なリンクで次ページに遷移可能にし、JS有効時はボタンクリックでコンテンツをインクリメンタルにロードする形です。これにより、UXを損なわずSEOを確保できます。
シングルページアプリケーション（SPA）では、History API（pushState）を使ってURLを動的に更新し、クリーンなURL構造を維持しましょう。 URLフラグメント（#）は避け、クエリパラメータを活用してください。
rel=prev/nextは不要
かつて、ページネーションでrel="prev"とrel="next"属性が推奨されていましたが、現在はGoogleがこれをサポートしていません。 歴史的にこれらはページ関係を示すために使われましたが、現代のクローラーはURL構造や内部リンクから関係性を理解するため、不要となっています。
代わりに、明確な<a href>リンクに焦点を当ててください。
lazy-load画像／カードの注意点（可視域トリガ・LCP画像はeager）
一覧ページの画像やカード要素でlazy-loadを適用する場合、注意が必要です。
lazy-loadはオフスクリーンリソースの読み込みを遅延させ、帯域を節約しますが、Largest Contentful Paint（LCP）に悪影響を及ぼす可能性があります。
- LCP候補の画像（ビューポート内最初に表示される大きな画像）は、loading="eager"とfetchpriority="high"を指定して即時読み込みにします。
- 折り返し下の画像はloading="lazy"で遅延ロード。
- width/height属性を指定してレイアウトシフトを防ぎましょう。
SEO面では、lazy-loadがクロールを妨げないよう、ブラウザレベル（loading属性）で実装することをおすすめします。
JS依存のlazy-loadは、Googleのレンダリング時に画像がロードされないリスクがあります。
関連記事
INP時代のページUX最適化：コアウェブバイタル対応
検証手順：URL検査・レンダリングテスト・ログでbot命中確認
実装後、Google Search Console（GSC）のURL検査ツールで各ページのインデックス状況を確認しましょう。
レンダリングテストでは、JS実行後のHTMLが正しく表示されるかをチェック。サーバーログでGooglebotのアクセスを確認し、クロール頻度を監視します。
また、Rich Results Testで構造化データを検証してください。
チェックリスト（公開前確認項目）
- 各ページに固有URLと<a href>リンクを設置。
- 一意の<title>、H1、パンくずリストを付与。
- LCP画像にloading="eager" fetchpriority="high"を設定。
- JS無効時でもコンテンツにアクセス可能かテスト。
- Sitemapに全ページを登録。
- robots.txtで重要なリソースをブロックしていないか確認。
関連記事
よくある失敗例と修正パターン
- 失敗例: 無限スクロールでコンテンツ重複が発生し、インデックスが乱れる。
修正: ページ間でコンテンツを重複させず、バッファリングを最小限に。 - 失敗例: 「もっと見る」ボタンがJSのみで、クローラーが次コンテンツを見つけられない。
修正: 裏側に静的リンクを追加し、プログレッシブエンハンス。 - 失敗例: lazy-loadでLCP画像が遅延し、パフォーマンス低下。
修正: eagerロードに切り替え。
これらの実装で、無限スクロールのSEO課題を解消し、検索流入を最大化しましょう。参考文献として、Googleの公式ガイドを活用してください。
