ページネーションとは？ — 複数ページに分割するUI設計
ページネーションの基本定義
ページネーション（Pagination）とは、大量のコンテンツやデータを複数ページに分割し、ユーザーがページ番号やナビゲーションで移動できるようにするUI設計です。Webサイトにおいてはごく一般的な仕組みですが、その実装方法によってSEOへの影響が大きく異なります。
日常的に目にする例は以下のとおりです。
・Google検索結果の「次へ」ボタン（現在は自動スクロール方式に変更）
・ECサイトの商品一覧ページ（「1 2 3 … 20 次へ」）
・ブログの記事一覧ページ
・ニュースサイトの記事アーカイブ
・求人検索サイトの求人一覧
なぜページネーションが必要なのか
|
理由 |
説明 |
|
ページ表示速度の維持 |
大量データを1ページに表示すると読み込みが遅くなる |
|
ユーザビリティ |
情報を整理し、目的の情報を見つけやすくする |
|
サーバー負荷の軽減 |
一度に全データを読み込まず、分散処理する |
|
SEO（クロール効率） |
クローラーが各ページを効率的に巡回できる |
|
コンテンツの構造化 |
情報を論理的なまとまりに分割して整理する |
|
モバイル体験の最適化 |
モバイルデバイスのメモリ消費を抑え、操作性を維持する |
つまり、ページネーションは「パフォーマンス・ユーザー体験・SEOを同時に最適化する」ための基本設計です。特に商品数やコンテンツ数が数百〜数万件規模のサイトでは、ページネーションの設計がサイト全体のSEOパフォーマンスに直結します。
ページネーションが使われる主な場面
|
場面 |
具体例 |
分割の目安 |
|
ECサイトの商品一覧 |
カテゴリ別商品リスト |
20〜40商品/ページ |
|
ブログ・メディアの記事一覧 |
カテゴリ別・タグ別の記事リスト |
10〜20記事/ページ |
|
検索結果ページ |
サイト内検索の結果表示 |
10〜20件/ページ |
|
フォーラム・コミュニティ |
スレッド・コメント一覧 |
20〜50件/ページ |
|
求人・不動産ポータル |
求人・物件の一覧表示 |
20〜30件/ページ |
|
長文記事の分割 |
1つの記事を複数ページに分割 |
SEO的には非推奨 |
ページネーションの種類と使い分け
主要なページネーション方式
|
方式 |
概要 |
メリット |
デメリット |
|
番号付きページネーション |
ページ番号を表示し、任意のページに移動可能 |
現在位置がわかりやすい |
ページ数が多いと煩雑 |
|
前へ/次へボタン |
「前のページ」「次のページ」のみ |
シンプルなUI |
特定ページに直接移動できない |
|
無限スクロール |
スクロールで自動的に次のコンテンツを読み込む |
シームレスな閲覧体験 |
SEOに課題あり |
|
「もっと見る」ボタン |
ボタンクリックで追加コンテンツを読み込む |
ユーザーが制御できる |
現在位置がわからない |
|
ハイブリッド型 |
番号付き + 前後ボタンの組み合わせ |
利便性が高い |
実装がやや複雑 |
なぜなら、ページネーション方式の選択はサイトの目的とコンテンツの性質に強く依存するからです。たとえばECサイトでは「特定のページに戻って商品を再確認したい」というユースケースが多く、番号付き方式が適しています。一方、SNSのフィードのように「新しい情報を次々と消費する」スタイルでは無限スクロールが自然です。
サイトタイプ別の推奨方式
|
サイトタイプ |
推奨方式 |
理由 |
|
ECサイト |
番号付き（ハイブリッド型） |
商品を見つけやすく、SEOにも有利 |
|
ブログ・メディア |
番号付きページネーション |
クローラーが全ページを発見できる |
|
SNS・フィード型 |
無限スクロール |
エンゲージメント重視のUI |
|
検索結果 |
番号付き + 「もっと見る」 |
柔軟なナビゲーション |
|
ニュースサイト |
番号付きページネーション |
アーカイブの閲覧性とSEO |
|
求人・不動産ポータル |
番号付き（ハイブリッド型） |
フィルタ条件との組み合わせが必要 |
ページネーションとSEOの関係 — クロール・インデックスへの影響
ページネーションがSEOに影響する4つのポイント
|
ポイント |
影響内容 |
重要度 |
|
クロール効率 |
各ページをクローラーが発見・巡回できるか |
★★★★★ |
|
インデックス |
分割された各ページが適切にインデックスされるか |
★★★★★ |
|
リンクジュースの分散 |
ページ分割により評価が分散しないか |
★★★★☆ |
|
重複コンテンツ |
類似コンテンツが重複として扱われないか |
★★★☆☆ |
ページネーションの実装方法を誤ると、サイト全体のSEO評価に影響が波及します。なぜなら、一覧ページはサイト内の個別コンテンツへの「入口」として機能しているからです。一覧ページの2ページ目以降がクロールされなければ、そこにリンクされている個別ページもクローラーに発見されにくくなります。
rel="next/prev"の廃止とその影響
2019年、Googleはrel="next"とrel="prev"のサポートを終了しました。
|
項目 |
内容 |
|
廃止の発表 |
2019年3月、GoogleのJohn Mueller氏がTwitterで公表 |
|
理由 |
Googleは以前からこのタグをほとんど使用していなかった |
|
影響 |
rel="next/prev"を設定してもGoogleはページネーション認識に使用しない |
|
現在の推奨 |
URL構造・内部リンク・サイトマップで対応 |
なぜなら、Googleのクローラーはrel="next/prev"に頼らなくてもリンク構造やURLパターンからページネーションを理解できるようになったからです。ただし、この廃止によって「正しいURL設計と内部リンク構造」の重要性はむしろ高まりました。
クロールバジェットへの影響
大規模サイトでは、ページネーションがクロールバジェットに影響を与えます。
・ページネーションページが大量にある場合、クローラーのリソースが消費される
・重要コンテンツページへのクロールが減少する可能性がある
・サイトマップでコンテンツページを優先的にクロールさせる工夫が有効
・ファセットナビゲーション（絞り込み検索）との組み合わせでURLが爆発的に増加するケースに特に注意が必要
テクニカルSEOの基礎をより体系的に学びたい方は 第3章 テクニカルSEO で網羅的に習得できます。
ページネーションのURL設計 — パラメータ型 vs パス型の比較と正規URL設定
パラメータ型とパス型の徹底比較
ページネーションのURL設計には大きく「パラメータ型」と「パス型（ディレクトリ型）」の2つのアプローチがあります。どちらを選ぶかはサイトのCMS・フレームワーク・SEO戦略に依存しますが、それぞれの特性を正確に理解しておくことが重要です。
|
比較項目 |
パラメータ型（?page=2） |
パス型（/page/2/） |
|
URL例 |
/products?page=2 |
/products/page/2/ |
|
Googleの認識 |
クロール可能（パラメータ処理が必要） |
クロール可能（静的URLとして認識） |
|
URLの読みやすさ |
やや読みにくい |
直感的でわかりやすい |
|
CDNキャッシュ |
パラメータ付きURLはキャッシュされにくい場合がある |
静的パスとしてキャッシュしやすい |
|
CMS対応 |
WordPress・Shopify等で標準的 |
WordPressではデフォルト対応 |
|
Search Console管理 |
URLパラメータツール（廃止済）で制御していた |
特別な設定不要 |
|
他パラメータとの共存 |
?page=2&sort=price のように連結可能 |
/page/2/?sort=price のように混在する |
|
推奨度 |
★★★★☆ |
★★★★★ |
つまり、SEOの観点ではパス型がやや有利です。なぜなら、パス型はGoogleがURLを一意の静的ページとして認識しやすく、CDNキャッシュとの相性も良いからです。ただし、パラメータ型でもSEO上の致命的な問題はなく、既存サイトをわざわざ移行する必要はありません。
フラグメント型が非推奨の理由
フラグメント（#page2）方式は絶対に使用すべきではありません。
× https://example.com/products#page2
× https://example.com/products#page3
GoogleのクローラーはURL中の # 以降を完全に無視します。つまり、上記の2つのURLは /products という単一のURLとして扱われます。結果としてページネーションは機能せず、2ページ目以降のコンテンツがインデックスされることはありません。
正規URL（canonical）の設定パターン
ページネーションにおけるcanonical設定は間違いやすいポイントです。以下のパターンで正しい設定を確認してください。
|
ページ |
canonical設定 |
正誤 |
理由 |
|
/blog/（1ページ目） |
/blog/ |
○ 正しい |
自分自身を指す |
|
/blog/page/2/ |
/blog/page/2/ |
○ 正しい |
自分自身を指す |
|
/blog/page/2/ |
/blog/ |
× 誤り |
2ページ目がインデックスされなくなる |
|
/blog/?page=1 |
/blog/ |
○ 正しい |
1ページ目のパラメータ付きURLを正規化 |
|
/blog/page/2/?sort=date |
/blog/page/2/ |
○ 正しい |
ソートパラメータを除外して正規化 |
|
/blog/page/2/?sort=price |
/blog/page/2/ |
○ 正しい |
同一ページのバリエーションを統合 |
重要: 各ページネーションページには自身のURLをcanonicalとして設定してください。全ページを1ページ目に正規化すると、2ページ目以降がインデックスされなくなります。ソートやフィルタのパラメータが付くバリエーションについては、パラメータなしのURLに正規化するのが正しいアプローチです。
ページネーションの正しい実装方法 — rel="next/prev"廃止後のベストプラクティス
基本原則
1. 各ページネーションページに固有のURLを付与する
2. すべてのページがクローラーにアクセス可能であること
3. canonicalタグは自分自身のURLを指定する（1ページ目に向けない）
4. 内部リンクで各ページが適切にリンクされていること
5. JavaScriptだけでなくHTMLレベルでリンクが存在すること
内部リンク構造のベストプラクティス
[1] [2] [3] … [10] [次へ→]
・前後のページへのリンク — 「前へ」「次へ」ボタン
・ページ番号へのリンク — 直接ジャンプ可能
・最初と最後のページへのリンク — 全体の範囲を把握しやすい
・aタグによるリンク — JavaScript のみの遷移はクローラーが辿れない可能性あり
ページネーションのリンク構造において最も重要なのは「クロール深度」の管理です。たとえばページ数が100ある場合、1ページ目から100ページ目に到達するまでに何クリック必要かを意識してください。「1, 2, 3, … 10, 次へ」という構造であれば、10ページ目まではワンクリックで到達できますが、100ページ目に到達するには多くのクリックが必要です。このような場合は「1, 2, 3 … 10 … 50 … 100」のように中間ページへのジャンプリンクを設けることで、クロール深度を浅く保つことができます。
noindex設定は必要か？
|
ケース |
noindexすべきか |
理由 |
|
ECサイトの商品一覧（2ページ目以降） |
基本的にNo |
各ページのコンテンツは異なる |
|
ブログ記事一覧（2ページ目以降） |
場合による |
2ページ目以降の価値が低い場合はYes |
|
検索結果ページ |
Yes（推奨） |
動的生成でコンテンツの価値が低い |
|
ファセットナビゲーションの組み合わせ |
Yes（推奨） |
URL爆発を防ぐためにインデックス制御が必要 |
ECサイト・メディアサイト別のページネーション実装パターン
サイトの種類によって、ページネーションの最適な実装方法は異なります。なぜなら、ECサイトとメディアサイトではコンテンツの性質やユーザーの行動パターンが根本的に違うからです。以下のテーブルで、サイトタイプ別の推奨実装パターンを整理します。
サイトタイプ別の実装パターン比較
|
項目 |
ECサイト |
メディア・ブログ |
求人・不動産ポータル |
|
1ページあたりの表示件数 |
24〜40件 |
10〜20件 |
20〜30件 |
|
推奨URL方式 |
パス型（/category/page/2/） |
パス型（/blog/page/2/） |
パラメータ型（?page=2）も可 |
|
canonical設定 |
自分自身 + ソートパラメータは正規化 |
自分自身 |
自分自身 + フィルタパラメータは正規化 |
|
noindex |
不要（各ページに異なる商品） |
場合により2ページ目以降にnoindex |
フィルタ組み合わせのみnoindex |
|
サイトマップへの掲載 |
商品ページを優先、一覧は任意 |
一覧ページもサイトマップに含める |
一覧ページもサイトマップに含める |
|
画像の遅延読み込み |
必須（商品画像が多い） |
推奨（サムネイル画像） |
推奨 |
|
ファセットナビとの連携 |
重要（カラー・サイズ等のフィルタ） |
不要なことが多い |
重要（エリア・条件等のフィルタ） |
|
ページ読み込み目標 |
2秒以内 |
1.5秒以内 |
2秒以内 |
ECサイト特有の注意点
ECサイトでは、ページネーションにソート（並び替え）やフィルタ（絞り込み）が組み合わさることが一般的です。たとえば /shoes/page/2/?sort=price&color=red のようなURLが生成されます。このとき、ソートやフィルタのバリエーションごとに別ページとしてインデックスされると、重複コンテンツやクロールバジェットの浪費につながります。
対策として、以下のアプローチが有効です。
・canonicalタグでソート・フィルタパラメータを除外した正規URLを指定する
・robots.txtまたはmetaタグでフィルタ付きURLのクロールを制御する
・重要なフィルタ（カテゴリなど）のみ静的URLとしてインデックス対象にする
メディアサイト特有の注意点
メディアサイトでは、記事一覧の2ページ目以降が検索結果に表示される価値が低い場合があります。その場合、2ページ目以降にnoindexを設定するかどうかは慎重に判断してください。noindexを設定するとクローラーの巡回頻度が下がり、そこからリンクされている個別記事ページの発見が遅れる可能性があります。
ページネーション vs 無限スクロール vs もっと見るボタン
3方式の詳細比較
|
比較項目 |
ページネーション |
無限スクロール |
もっと見るボタン |
|
ユーザー体験 |
構造的・予測可能 |
シームレス・没入感 |
ユーザー主導 |
|
SEOフレンドリー |
★★★★★ |
★★☆☆☆ |
★★★☆☆ |
|
クロール容易性 |
高い |
低い（JS依存） |
中程度 |
|
ページ読み込み速度 |
各ページが軽い |
初期は速い→重くなる |
中程度 |
|
フッターへのアクセス |
容易 |
困難 |
中程度 |
|
ブックマーク・共有 |
URL共有可能 |
困難 |
困難 |
|
アクセシビリティ |
高い |
低い |
中程度 |
|
「戻る」ボタンの動作 |
正常に動作 |
位置がリセットされる |
リセットされる可能性 |
|
メモリ消費 |
一定（ページごとに固定） |
増加し続ける |
増加し続ける |
無限スクロールのSEO対策
無限スクロールでもSEOに配慮した実装は可能です。Googleが推奨する方法は以下のとおりです。
1. ページネーションURLを並行して用意 — /page/1/, /page/2/ というURLを別途用意
2. History APIでURLを更新 — スクロール位置に応じてブラウザのURLを更新
3. クローラー向けにHTMLリンクを提供 — JavaScript実行なしでもリンクを辿れるようにする
4. <noscript> タグ内にページネーションリンクを設置 — JS無効環境でもナビゲーション可能にする
つまり、「ユーザーには無限スクロール、クローラーにはページネーション」という二重構造が理想です。この実装は工数がかかりますが、UXとSEOの両立を実現する唯一の方法です。
ページネーションとCore Web Vitalsの関係 — CLSへの影響と対策
ページネーションの実装は、Core Web Vitals——特にCLS（Cumulative Layout Shift）に影響を与えることがあります。なぜなら、ページネーション付きの一覧ページでは画像やコンテンツの動的な読み込みが発生しやすく、レイアウトのズレが生じやすいからです。
ページネーションが各CWV指標に与える影響
|
CWV指標 |
ページネーションとの関係 |
影響度 |
|
LCP（Largest Contentful Paint） |
1ページあたりの表示件数が多いと画像読み込みが遅延しLCPが悪化 |
★★★★☆ |
|
INP（Interaction to Next Paint） |
ページネーションボタンのクリック後の応答速度に影響 |
★★★☆☆ |
|
CLS（Cumulative Layout Shift） |
画像の遅延読み込みやコンテンツの動的挿入でレイアウトがズレる |
★★★★★ |
CLSを悪化させるページネーション実装パターン
|
問題パターン |
CLSへの影響 |
対策 |
|
画像のwidth/height未指定 |
画像読み込み時にレイアウトがズレる |
width と height 属性を必ず指定する |
|
遅延読み込み画像の領域未確保 |
画像表示エリアが後から確保されてズレる |
CSSで aspect-ratio またはプレースホルダーを設定 |
|
広告の動的挿入 |
一覧の途中に広告が挿入されてコンテンツが押し下げられる |
広告枠のサイズを事前にCSSで確保する |
|
ページネーションUI自体の遅延表示 |
ページ下部のナビゲーションが後から表示されてフッターがズレる |
SSRまたは初期HTMLにページネーションUIを含める |
|
フォントの遅延読み込み |
Webフォント読み込み完了時にテキストサイズが変わる |
font-display: swap と size-adjust の設定 |
ページネーションページのCWV最適化チェックリスト
ページネーション付きの一覧ページでCore Web Vitalsを良好に保つためには、以下の対策を実施してください。
・画像には必ず width と height を指定する — これだけでCLSの大部分を防げる
・ファーストビュー外の画像には loading="lazy" を設定する — LCPの改善に寄与する
・ファーストビュー内の画像には loading="lazy" を使わない — LCPの遅延を防ぐ
・ページネーションUIはサーバーサイドでレンダリングする — クライアントサイドで後から描画するとCLSの原因になる
・1ページあたりの表示件数を適切に保つ — 多すぎるとLCPが悪化、少なすぎるとページ数増加でクロールバジェットを浪費
つまり、ページネーションの設計はSEOだけでなくCWVにも影響を与える設計判断であり、表示件数・画像処理・レンダリング方式を総合的に検討する必要があります。
ページネーション実装時のよくある失敗と対策
失敗パターンと対策一覧
|
失敗パターン |
問題 |
対策 |
|
JavaScriptのみでページ遷移 |
クローラーがリンクを辿れない |
aタグのhref属性でリンクを設定 |
|
全ページを1ページ目にcanonical |
2ページ目以降がインデックスされない |
各ページは自分自身をcanonical |
|
パラメータURLがクロールブロック |
robots.txtでブロックされている |
クロール可能な状態にする |
|
1ページあたりの表示件数が少なすぎる |
ページ数が増えクロールバジェットを浪費 |
適切な件数（10〜40件）に設定 |
|
ページネーションリンクが画像のみ |
クローラーがリンクテキストを認識しにくい |
テキストリンクを使用 |
|
1つの記事を複数ページに分割 |
ユーザー体験の低下・SEO評価の分散 |
1記事1ページに統合推奨 |
|
フィルタとページネーションの組み合わせでURL爆発 |
クロールバジェットの大量浪費 |
canonical・noindex・robots.txtで制御 |
1記事を複数ページに分割するのは非推奨
一部のメディアではPV数を増やすために1記事を複数ページに分割するケースがあります。しかし、SEO上のデメリットが多い手法です。
|
デメリット |
説明 |
|
ユーザー体験の低下 |
ページ遷移のたびに読み込みが発生し、離脱率が上がる |
|
SEO評価の分散 |
1つのコンテンツの評価が複数ページに分かれてしまう |
|
Core Web Vitalsへの悪影響 |
ページ遷移ごとにLCP・INP等の指標に影響 |
|
SNSシェアの分散 |
各ページ別にシェアされ、バイラル効果が弱まる |
Googleも「可能であれば、記事は1ページにまとめることを推奨する」と述べています。
【実践事例】scale-basics.comでのページネーション改善
課題の発見
scale-basics.comでは、教育記事の一覧ページにおけるページネーション実装に問題がありました。Search Consoleのカバレッジレポートで問題を特定しました。
課題:
・ブログ一覧ページの2ページ目以降がインデックスされていなかった
・JavaScriptのみでページ遷移を実装していた——クローラーがリンクを辿れなかった
・すべてのページネーションページのcanonicalが1ページ目を指していた
実施した改善:
1. ページネーションリンクをaタグのhref属性で実装（JavaScript依存から脱却）
2. URL構造を /blog/page/2/ のディレクトリ方式に変更
3. canonicalタグを各ページが自分自身を指すように修正
4. XMLサイトマップにページネーションの各URLを追加
5. 画像に width / height 属性を追加し、CLSを改善
結果:
|
指標 |
改善前 |
改善後 |
変化 |
|
一覧ページのインデックス数 |
1ページ（1ページ目のみ） |
8ページ（全ページ） |
+700% |
|
一覧ページ経由のオーガニック流入 |
月間約50セッション |
月間約180セッション |
+260% |
|
一覧ページに掲載された記事のクロール頻度 |
週1〜2回 |
週4〜5回 |
+150% |
|
新規記事のインデックス速度 |
平均5日 |
平均2日 |
-60% |
|
一覧ページのCLS |
0.18（不良） |
0.04（良好） |
-78% |
つまり、ページネーションの技術的実装を正しく修正するだけで、一覧ページと個別記事ページの両方のSEOパフォーマンスが大幅に改善しました。加えて、CWVの改善によってモバイルユーザーの離脱率も低下しています。
ページネーションに関するよくある質問
Q1: ページネーションの2ページ目以降にnoindexを設定すべきですか？
一般的にはnoindexは不要です。なぜなら、2ページ目以降にも固有のコンテンツ（異なる記事や商品）が含まれるためです。ただし、内容が1ページ目と大きく重複する場合や、サイト内検索の結果ページなどはnoindexを検討してもよいでしょう。noindexを設定する場合は、そのページからリンクされている個別ページの発見性に影響がないかも合わせて確認してください。
Q2: rel="next/prev"はもう完全に不要ですか？
Googleはサポートしていません。ただし、Bing等の他の検索エンジンでは参考にしている可能性があります。設定しても害はないため、他の検索エンジンへの配慮として残すのも選択肢です。実装コストが低いCMSを使っている場合は、残しておいても問題ありません。
Q3: 1ページあたり何件表示するのが最適ですか？
サイトの種類やコンテンツによりますが、一般的な目安は以下のとおりです。
・ブログ記事一覧: 10〜20件
・ECサイト商品一覧: 20〜40件
・検索結果: 10〜20件
・求人・不動産ポータル: 20〜30件
表示件数が多すぎるとページが重くなりLCPが悪化し、少なすぎるとページ数が増えすぎてクロールバジェットを浪費します。実際のページ読み込み速度を計測しながら最適値を見つけるのが理想です。
Q4: 無限スクロールはSEOに悪いのですか？
適切に実装すれば問題ありません。ただし、クローラー向けにページネーションURLを並行して用意する必要があります。JavaScriptのみで動作する無限スクロールは、クローラーがコンテンツを発見できない原因になります。工数に余裕がない場合は、従来型のページネーションを採用するほうが安全です。
Q5: ページネーションページをサイトマップに含めるべきですか？
はい、含めることを推奨します。2ページ目以降がインデックスされにくい場合、サイトマップに含めることでクロールを促進できます。ただし、サイトマップに含めるだけでインデックスが保証されるわけではなく、URL設計やcanonical設定が正しいことが前提です。
Q6: ページネーションのURL設計を途中で変更しても大丈夫ですか？
可能ですが、必ず301リダイレクトを設定してください。たとえばパラメータ型（?page=2）からパス型（/page/2/）に変更する場合、旧URLから新URLへの301リダイレクトがないと、Googleが2つの別ページとして認識し、一時的にインデックスが混乱する可能性があります。Search Consoleで旧URLのインデックス状況を監視しながら段階的に移行するのが安全です。
Q7: ページネーションとAjaxを組み合わせる場合の注意点は？
Ajaxでコンテンツを動的に読み込む場合でも、各ページに対応する静的なURLが存在することが重要です。History APIを使ってURLを更新し、そのURLに直接アクセスした場合にもサーバーサイドで正しいコンテンツが返されるようにしてください。つまり、「Ajax動作時もURL直接アクセス時も同じコンテンツが表示される」状態が理想です。クローラーはJavaScriptを実行できる場合もありますが、確実にコンテンツを発見させるにはサーバーサイドレンダリング（SSR）との併用が推奨されます。
まとめ — ページネーションはUXとSEOを両立させる重要な設計要素
ページネーションは、大量コンテンツを持つWebサイトにおいて、ユーザー体験とSEOの両方を最適化するための基本設計です。
本記事のポイント:
・ページネーションは大量コンテンツを複数ページに分割するUI設計手法
・番号付きページネーション（ハイブリッド型）がSEOに最適
・URL設計はパス型（/page/2/）が推奨。パラメータ型でも致命的な問題はない
・rel="next/prev"はGoogleで廃止済み。URL構造と内部リンクで対応
・canonicalは各ページが自分自身を指す。1ページ目への正規化は誤り
・ECサイト・メディアサイトで実装パターンが異なる。サイトタイプに合った設計を
・ページネーションはCLS等のCore Web Vitalsにも影響する。画像のサイズ指定とSSRが重要
・無限スクロールはSEOに不利だが、ページネーションURLの併用で対策可能
・JavaScriptのみの実装ではなく、aタグのhrefでクローラーが辿れるようにする
・1記事を複数ページに分割するのはSEO的に非推奨
正しいページネーション実装は、クロール効率・インデックス率・ユーザー体験・Core Web Vitalsのすべてを向上させます。
参考リンク:
・Google公式: 大規模サイトや無限スクロールサイトの検索対応
・Google公式: ページネーションに関するベストプラクティス