ページネーションとは？SEOに強い実装と無限スクロール比較【2026年最新】

ページネーションとは？ — 複数ページに分割するUI設計

ページネーションの基本定義

ページネーション（Pagination）とは、大量のコンテンツやデータを複数ページに分割し、ユーザーがページ番号やナビゲーションで移動できるようにするUI設計です。Webサイトではごく一般的な仕組みですが、その実装方法によってSEOへの影響が大きく異なります。日常的に目にする例は次のとおりです。

• Google検索結果の「次へ」ボタン（現在は自動スクロール方式に変更）
• ECサイトの商品一覧ページ（「1 2 3 … 20 次へ」）
• ブログ・メディアの記事一覧ページ
• ニュースサイトの記事アーカイブ
• 求人・不動産ポータルの一覧表示

なぜページネーションが必要なのか

ページネーションが果たす6つの役割

理由	説明
ページ表示速度の維持	大量データを1ページに表示すると読み込みが遅くなる
ユーザビリティ	情報を整理し、目的の情報を見つけやすくする
サーバー負荷の軽減	一度に全データを読み込まず、分散して処理する
SEO（クロール効率）	クローラーが各ページを効率的に巡回・発見できる
コンテンツの構造化	情報を論理的なまとまりに分割して整理する
モバイル体験の最適化	モバイル端末のメモリ消費を抑え、操作性を維持する

つまりページネーションは、パフォーマンス・ユーザー体験・SEOを同時に最適化するための基本設計です。特に商品数やコンテンツ数が数百〜数万件規模のサイトでは、ページネーションの設計がサイト全体のSEOパフォーマンスに直結します。AI OverviewsやAI Modeが個別記事を参照する場面が増えた現在、一覧ページ経由でクローラーが個別ページを発見できる構造の重要性はむしろ高まっています。

ページネーションが使われる主な場面

サイトタイプ別の分割目安

場面	具体例	分割の目安
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に与える影響

ポイント	影響内容	重要度
クロール効率	各ページをクローラーが発見・巡回できるか	★★★★★
インデックス	分割された各ページが適切にインデックスされるか	★★★★★
リンク評価の分散	ページ分割により評価が過度に分散しないか	★★★★☆
重複コンテンツ	類似コンテンツが重複として扱われないか	★★★☆☆

ページネーションの実装を誤ると、サイト全体のSEO評価に影響が波及します。一覧ページはサイト内の個別コンテンツへの「入口」として機能しているため、一覧の2ページ目以降がクロールされなければ、そこにリンクされた個別ページもクローラーに発見されにくくなるからです。この一覧ページから個別ページへ評価を流す設計の考え方は、SEO内部リンク戦略の設計と実装もあわせて確認してください。

rel="next/prev"の廃止とその影響

2019年、Googleはrel="next"とrel="prev"のサポート終了を明らかにしました。この事実は2026年現在も変わっていないため、いまだにこのタグをページネーション対策の中心に据える解説には注意が必要です。

rel="next/prev"廃止の要点

項目	内容
廃止の公表	2019年3月、GoogleのJohn Mueller氏がTwitter（現X）で公表
理由	Googleは以前からこのタグをインデックスにほとんど使用していなかった
影響	rel="next/prev"を設定してもGoogleはページネーション認識に使用しない
現在の推奨	URL構造・内部リンク・サイトマップで対応する

Googleのクローラーはrel="next/prev"に頼らなくても、リンク構造やURLパターンからページネーションを理解できます。ただしこの廃止によって、「正しいURL設計と内部リンク構造」の重要性はむしろ高まりました。実装の主役はメタ情報ではなく、クローラーが辿れる実際のリンクだと理解してください。

クロールバジェットへの影響

大規模サイトでは、ページネーションがクロールバジェットに影響します。ページネーションページが大量にあるとクローラーのリソースが消費され、重要なコンテンツページへのクロールが後回しになる可能性があるためです。特にファセットナビゲーション（絞り込み検索）と組み合わさってURLが爆発的に増えるケースには注意が必要です。

クロールの前提として、Googlebotが1ページあたりに処理するデータ量にも上限があります。Googleは2026年3月、Googlebotが取得するHTMLは2MB（HTTPヘッダー含む）までで、それを超えた部分は処理されないと公式に解説しました。詳細は「Googlebotの「2MBの壁」をGoogleが解説」を参照してください。一覧ページに大量のサムネイルやインラインスクリプトを詰め込みすぎると、この上限やクロール効率に響きます。クロールバジェットとインデックス制御の全体像はテクニカルSEO完全ガイドで体系的に確認できます。

ページネーションのURL設計 — パラメータ型 vs パス型の比較と正規URL

パラメータ型とパス型の比較

ページネーションのURL設計には、大きく「パラメータ型」と「パス型（ディレクトリ型）」の2つのアプローチがあります。どちらを選ぶかはサイトのCMS・フレームワーク・SEO戦略に依存しますが、それぞれの特性を正確に理解しておくことが重要です。

パラメータ型とパス型のURL設計比較

比較項目	パラメータ型（?page=2）	パス型（/page/2/）
URL例	/products?page=2	/products/page/2/
Googleの認識	クロール可能（パラメータ処理が必要）	クロール可能（静的URLとして認識）
URLの読みやすさ	やや読みにくい	直感的でわかりやすい
CDNキャッシュ	パラメータ付きはキャッシュされにくい場合がある	静的パスとしてキャッシュしやすい
CMS対応	WordPress・Shopify等で標準的	WordPressではデフォルト対応
Search Console管理	URLパラメータツール（廃止済）で制御していた	特別な設定不要
他パラメータとの共存	?page=2&sort=price のように連結できる	/page/2/?sort=price のように混在する
推奨度	★★★★☆	★★★★★

SEOの観点ではパス型がやや有利です。Googleがパス型URLを一意の静的ページとして認識しやすく、CDNキャッシュとの相性も良いためです。ただしパラメータ型でもSEO上の致命的な問題はなく、既存サイトをわざわざ移行する必要はありません。かつてSearch Consoleにあったパラメータ制御用の「URLパラメータツール」は廃止されているため、パラメータ型を使う場合はcanonicalとリンク構造で制御する前提で設計します。

フラグメント型が非推奨の理由

フラグメント（#page2）方式は使用すべきではありません。GoogleのクローラーはURL中の # 以降を完全に無視するため、次の2つのURLは同一URLとして扱われ、2ページ目以降のコンテンツはインデックスされません。

NG（フラグメント型）: # 以降は無視され、すべて同一URL扱いになる
https://example.com/products#page2
https://example.com/products#page3

OK（パス型）: 各ページが一意の静的URLになる
https://example.com/products/page/2/
https://example.com/products/page/3/

上のNG例では2つのURLがどちらも /products として扱われ、ページネーションが機能しません。必ず # を使わず、パスまたはパラメータで一意のURLを与えてください。

正規URL（canonical）の設定パターン

ページネーションにおけるcanonical設定は間違いやすいポイントです。原則は「各ページネーションページが自分自身のURLをcanonicalとして指す」ことです。全ページを1ページ目に正規化すると、2ページ目以降がインデックスされなくなります。

<!-- /category/seo/page/2/ のhead内：自分自身を正規URLに指定する（正しい） -->
<link rel="canonical" href="https://example.com/category/seo/page/2/">

<!-- NG：2ページ目なのに1ページ目へ正規化すると、2ページ目以降がインデックスされない -->
<!-- <link rel="canonical" href="https://example.com/category/seo/"> -->

ページネーションのcanonical設定パターン

ページ	canonical設定	正誤	理由
/category/seo/（1ページ目）	/category/seo/	○ 正しい	自分自身を指す
/category/seo/page/2/	/category/seo/page/2/	○ 正しい	自分自身を指す
/category/seo/page/2/	/category/seo/	× 誤り	2ページ目がインデックスされなくなる
/category/seo/?page=1	/category/seo/	○ 正しい	1ページ目のパラメータ付きURLを正規化
/category/seo/page/2/?sort=date	/category/seo/page/2/	○ 正しい	ソートパラメータを除外して正規化
/category/seo/page/2/?sort=price	/category/seo/page/2/	○ 正しい	同一ページのバリエーションを統合

ソートやフィルタのパラメータが付くバリエーションは、パラメータなしのページURLに正規化するのが正しいアプローチです。canonicalの動作原理や重複コンテンツ全般の扱いはcanonicalタグとは？URL正規化の正しい設定方法で詳しく解説しています。

ページネーションの正しい実装方法 — rel="next/prev"廃止後のベストプラクティス

基本原則

1. 各ページネーションページに固有のURLを付与する
2. すべてのページがクローラーにアクセス可能であること
3. canonicalタグは自分自身のURLを指定する（1ページ目に向けない）
4. 内部リンクで各ページが適切にリンクされていること
5. JavaScriptだけでなくHTMLレベルでリンクが存在すること

内部リンク構造のベストプラクティス

ページネーションの実体は「一覧ページ同士をつなぐ内部リンク」です。番号リンク・前後リンク・最初/最後へのリンクを、必ずaタグのhref属性で提供します。次はパス型URLを使った番号付きページネーションのHTML例です。

<nav class="pagination" aria-label="ページ送り">
  <a href="https://example.com/category/seo/page/1/" rel="prev">前へ</a>
  <a href="https://example.com/category/seo/page/1/">1</a>
  <span aria-current="page">2</span>
  <a href="https://example.com/category/seo/page/3/">3</a>
  <a href="https://example.com/category/seo/page/10/">10</a>
  <a href="https://example.com/category/seo/page/3/" rel="next">次へ</a>
</nav>

ここで最も重要なのは「クロール深度」の管理です。ページ数が100あるとき、1ページ目から100ページ目まで何クリックで到達できるかを意識してください。「1, 2, 3 … 10, 次へ」だけの構造では末尾ページが深くなります。「1, 2, 3 … 10 … 50 … 100」のように中間ページへのジャンプリンクを設けると、クロール深度を浅く保てます。現在ページはリンクにせず aria-current="page" で示すと、アクセシビリティとクローラー双方に現在地が伝わります。

JavaScript依存を避ける — Before / After

ありがちな失敗は、ページ遷移をJavaScriptのクリックイベントだけで実装し、href属性を持たないケースです。クローラーはこのリンクを辿れず、2ページ目以降が発見されません。

<!-- NG：onclickだけで遷移。href属性がなくクローラーが辿れない -->
<span class="next" onclick="loadPage(3)">次へ</span>

<!-- OK：aタグのhrefで各ページの実URLを指定。JS無効でもクロールできる -->
<a href="https://example.com/category/seo/page/3/" rel="next">次へ</a>

Ajaxで滑らかに切り替えたい場合でも、土台はhref付きのaタグにし、JavaScriptでその挙動を拡張（プログレッシブエンハンスメント）する形にします。こうすればクローラーは実URLを辿れ、ユーザーには滑らかな体験を提供できます。

noindex設定は必要か？

ページネーションページのnoindex判断

ケース	noindexすべきか	理由
ECサイトの商品一覧（2ページ目以降）	基本的にNo	各ページのコンテンツ（商品）が異なる
ブログ記事一覧（2ページ目以降）	場合による	2ページ目以降の価値が低い場合はYes
サイト内検索の結果ページ	Yes（推奨）	動的生成でコンテンツの価値が低い
ファセットナビゲーションの組み合わせ	Yes（推奨）	URL爆発を防ぐためインデックス制御が必要

なお、価値の低い一覧ページは、noindexを設定しなくてもGoogleが「クロール済み – 現在インデックス未登録」として結果的にインデックスを見送ることがあります。GoogleのMueller氏は、このステータスがサイト品質のサインになり得ると解説しています（「クロール済み-未インデックスとサイト品質の関係」）。一覧ページが薄い内容の場合は、noindexの前にページそのものの価値を見直す視点も持ってください。

ECサイト・メディアサイト別のページネーション実装パターン

サイトの種類によって最適な実装は異なります。ECサイトとメディアサイトでは、コンテンツの性質とユーザーの行動パターンが根本的に違うためです。

サイトタイプ別の実装パターン比較

サイトタイプ別のページネーション実装パターン

項目	ECサイト	メディア・ブログ	求人・不動産ポータル
1ページあたりの表示件数	24〜40件	10〜20件	20〜30件
推奨URL方式	パス型（/category/page/2/）	パス型（/category/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のクロールを制御する（robots.txtの書き方完全ガイド）
• 重要なフィルタ（カテゴリなど）のみ静的URLとしてインデックス対象にする

メディアサイト特有の注意点

メディアサイトでは、記事一覧の2ページ目以降が検索結果に表示される価値が低い場合があります。noindexを設定するかどうかは慎重に判断してください。noindexを付けるとクローラーの巡回頻度が下がり、そこからリンクされている個別記事ページの発見が遅れる可能性があるためです。

ページネーション vs 無限スクロール vs もっと見るボタン

3方式の詳細比較

ページネーション・無限スクロール・もっと見るボタンの比較

比較項目	ページネーション	無限スクロール	もっと見るボタン
ユーザー体験	構造的・予測可能	シームレス・没入感	ユーザー主導
SEOフレンドリー	★★★★★	★★☆☆☆	★★★☆☆
クロール容易性	高い	低い（JS依存）	中程度
ページ読み込み速度	各ページが軽い	初期は速い→重くなる	中程度
フッターへのアクセス	容易	困難	中程度
ブックマーク・共有	URL共有可能	困難	困難
アクセシビリティ	高い	低い	中程度
「戻る」ボタンの動作	正常に動作	位置がリセットされる	リセットされる可能性
メモリ消費	一定（ページごとに固定）	増加し続ける	増加し続ける

無限スクロールのSEO対策

無限スクロールでもSEOに配慮した実装は可能です。Googleが推奨するのは、ユーザーには無限スクロールを見せつつ、クローラーには実URLのページ送りを並行して提供する二重構造です。

1. ページネーションURLを並行して用意する（/page/1/, /page/2/ という実URL）
2. History APIでスクロール位置に応じてブラウザのURLを更新する
3. クローラー向けにHTMLレベルのリンクを提供する（JS実行なしでも辿れる）
4. <noscript> タグ内にページネーションリンクを設置し、JS無効環境でもナビゲーションできるようにする

<!-- ユーザーには無限スクロール、クローラーには実URLのページ送りを提供 -->
<div id="feed" data-next="https://example.com/list/page/2/">
  <!-- 記事カードをJavaScriptで追記していく -->
</div>

<noscript>
  <nav aria-label="ページ送り">
    <a href="https://example.com/list/page/2/">次のページ</a>
  </nav>
</noscript>

この実装は工数がかかりますが、UXとSEOを両立させる現実的な方法です。工数に余裕がない場合は、無理に無限スクロールを採用せず、従来型のページネーションを選ぶほうが安全です。

ページネーションとCore Web Vitalsの関係 — CLSへの影響と対策

ページネーションの実装は、Core Web Vitals——特にCLS（Cumulative Layout Shift）に影響します。一覧ページでは画像やコンテンツの動的な読み込みが発生しやすく、レイアウトのズレが生じやすいためです。なお、かつての応答性指標だったFIDは2024年3月にINP（Interaction to Next Paint）へ正式に置き換えられており、現在の評価対象はINPです。

ページネーションが各CWV指標に与える影響

ページネーションとCore Web Vitalsの関係

CWV指標	ページネーションとの関係	影響度
LCP（Largest Contentful Paint）	1ページの表示件数が多いと画像読み込みが遅延しLCPが悪化	★★★★☆
INP（Interaction to Next Paint）	ページ送りボタンのクリック後の応答速度に影響	★★★☆☆
CLS（Cumulative Layout Shift）	画像の遅延読み込みやコンテンツの動的挿入でレイアウトがズレる	★★★★★

CLSを悪化させる実装パターンと対策

CLSを悪化させるページネーション実装と対策

問題パターン	CLSへの影響	対策
画像のwidth/height未指定	画像読み込み時にレイアウトがズレる	width と height 属性を必ず指定する
遅延読み込み画像の領域未確保	画像表示エリアが後から確保されてズレる	CSSで aspect-ratio またはプレースホルダーを設定
広告の動的挿入	一覧の途中に広告が挿入されコンテンツが押し下げられる	広告枠のサイズを事前にCSSで確保する
ページネーションUI自体の遅延表示	ページ下部のナビが後から表示されフッターがズレる	SSRまたは初期HTMLにページネーションUIを含める
フォントの遅延読み込み	Webフォント読み込み完了時にテキストサイズが変わる	font-display: swap と size-adjust を設定

CLS対策の要は「画像の寸法をあらかじめ確保する」ことです。一覧のサムネイルには width / height を必ず指定し、ファーストビュー外の画像だけ loading="lazy" を付けます。ファーストビュー内の主要画像に lazy を付けるとLCPが遅延するため避けてください。

<!-- ファーストビュー外のサムネイル：寸法指定でCLSを防ぎ、lazyで初期読み込みを軽くする -->
<img src="/img/thumb-01.webp" width="320" height="180" loading="lazy" alt="記事のサムネイル">

加えて、ページネーションUIはサーバーサイドでレンダリングして初期HTMLに含め、1ページあたりの表示件数を適切に保つことがLCPとクロールバジェットのバランスにつながります。表示件数が多すぎるとLCPが悪化し、少なすぎるとページ数が増えてクロールバジェットを浪費します。実測に基づく画像・CSS最適化の詳細はSEOに強いコーディング（実測データ付き）で解説しています。

ページネーション実装でよくある失敗と対策

失敗パターンと対策一覧

ページネーションのよくある失敗と対策

失敗パターン	問題	対策
JavaScriptのみでページ遷移	クローラーがリンクを辿れない	aタグのhref属性でリンクを設定する
全ページを1ページ目にcanonical	2ページ目以降がインデックスされない	各ページは自分自身をcanonicalに指定
パラメータURLがrobots.txtでブロック	クロールできず発見されない	クロール可能な状態にする
1ページあたりの表示件数が少なすぎる	ページ数が増えクロールバジェットを浪費	適切な件数（10〜40件）に設定
ページ送りリンクが画像のみ	クローラーがリンクの意味を認識しにくい	テキストリンクを使用する
1つの記事を複数ページに分割	ユーザー体験の低下・評価の分散	1記事1ページに統合する
フィルタ×ページネーションでURL爆発	クロールバジェットの大量浪費	canonical・noindex・robots.txtで制御

1記事を複数ページに分割するのは非推奨

一部のメディアではPVを増やすために1記事を複数ページに分割することがありますが、SEO上のデメリットが多い手法です。

1記事を複数ページ分割するデメリット

デメリット	説明
ユーザー体験の低下	ページ遷移のたびに読み込みが発生し、離脱率が上がる
SEO評価の分散	1つのコンテンツの評価が複数ページに分かれてしまう
Core Web Vitalsへの悪影響	ページ遷移ごとにLCP・INP等の指標に影響
SNSシェアの分散	各ページ別にシェアされ、拡散効果が弱まる

Googleも「可能であれば、記事は1ページにまとめることを推奨する」としています。読み物系のコンテンツは、無理な分割をせず1ページに統合するのが基本です。

運営者の視点：ページネーション実装で最初に確認する3点

当サイト（scale-basics.com）を運用するなかで、一覧ページのページネーションを点検するときにまず確認しているのは次の3点です。数値目標よりも、この3点が担保されているかどうかが実装品質を大きく左右します。

1. ページ送りがaタグのhrefになっているか — ブラウザのJavaScriptを無効にした状態でも「次へ」「2」「3」を辿れるかを確認します。辿れなければクローラーも辿れません。
2. 2ページ目以降のcanonicalが自分自身を指しているか — ページのソースを開き、2ページ目の rel="canonical" が1ページ目に向いていないかを目視でチェックします。
3. Search Consoleのインデックス作成レポートで一覧URLの扱いを確認する — 「クロール済み-未インデックス」に一覧ページが並んでいないか、意図どおりのページがインデックスされているかを見ます。

なお当サイトは2026年7月にNext.js（SSG）からWordPressへ移行しましたが、その際 /blog/xxx/ から /xxx/ への301リダイレクトで旧URLを引き継ぎ、インデックス上の大きな問題は起きませんでした。ページネーションのURL設計を後から変更する場合も、この301の考え方が土台になります（移行時の実測・実装の詳細はSEOに強いコーディングを参照）。

ページネーションに関するよくある質問

Q1: ページネーションの2ページ目以降にnoindexを設定すべきですか？

一般的にnoindexは不要です。2ページ目以降にも固有のコンテンツ（異なる記事や商品）が含まれるためです。ただし、内容が1ページ目と大きく重複する場合や、サイト内検索の結果ページなどはnoindexを検討してもよいでしょう。設定する場合は、そのページからリンクされている個別ページの発見性に影響しないかも合わせて確認してください。

Q2: rel="next/prev"はもう完全に不要ですか？

Googleはインデックスに使用していません。ただしBing等の他の検索エンジンでは参考にしている可能性があり、設定しても害はありません。実装コストが低いCMSを使っている場合は、他の検索エンジンへの配慮として残すのも選択肢です。いずれにせよ、Google向けの主役はURL構造と内部リンクである点は変わりません。

Q3: 1ページあたり何件表示するのが最適ですか？

サイトの種類やコンテンツによりますが、一般的な目安はブログ記事一覧が10〜20件、EC商品一覧が20〜40件、検索結果が10〜20件、求人・不動産ポータルが20〜30件です。表示件数が多すぎるとページが重くなりLCPが悪化し、少なすぎるとページ数が増えてクロールバジェットを浪費します。実際のページ読み込み速度を計測しながら最適値を見つけるのが理想です。

Q4: 無限スクロールはSEOに悪いのですか？

適切に実装すれば問題ありません。ただし、クローラー向けにページネーションURLを並行して用意する必要があります。JavaScriptのみで動作する無限スクロールは、クローラーがコンテンツを発見できない原因になります。工数に余裕がない場合は、従来型のページネーションを採用するほうが安全です。

Q5: ページネーションページをサイトマップに含めるべきですか？

含めることを推奨します。2ページ目以降がインデックスされにくい場合、サイトマップに含めることでクロールを促進できます。ただし、サイトマップに含めるだけでインデックスが保証されるわけではなく、URL設計やcanonical設定が正しいことが前提です。サイトマップの作り方や役割はサイトマップとは？XMLとHTMLの違い・作成方法で解説しています。

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/）が推奨。パラメータ型でも致命的な問題はない。フラグメント型（#page2）は不可
• rel="next/prev"はGoogleで廃止済み。URL構造と内部リンクで対応する
• canonicalは各ページが自分自身を指す。1ページ目への正規化は誤り
• ECサイト・メディアサイトで実装パターンが異なる。サイトタイプに合った設計を選ぶ
• ページネーションはCLS等のCore Web Vitalsにも影響する。画像の寸法指定とSSRが重要
• 無限スクロールはSEOに不利だが、ページネーションURLの併用で対策できる
• JavaScriptのみの実装ではなく、aタグのhrefでクローラーが辿れるようにする
• 1記事を複数ページに分割するのはSEO的に非推奨

正しいページネーション実装は、クロール効率・インデックス率・ユーザー体験・Core Web Vitalsのすべてを底上げします。まずは自サイトの一覧ページで「aタグのhrefになっているか」「2ページ目のcanonicalが自分自身か」の2点から点検してみてください。Google公式の考え方はページネーションとインクリメンタルなページ読み込みのベストプラクティスが一次情報として最適です。

執筆根拠: 本記事は2026年7月時点の情報に基づき、Google検索セントラルの公式ドキュメント（ページネーションのベストプラクティス、大規模サイトのクロール対応）、Google関係者の公開発言（2019年のrel=next/prevサポート終了、クロール済み-未インデックスとサイト品質の関係）、およびGoogleが公式に定義するCore Web Vitals（INPは2024年3月にFIDを正式置換）をもとに執筆しています。当サイトの運営実体験（2026年7月のNext.js→WordPress移行時に /blog/xxx/→/xxx/ を301リダイレクトで引き継ぎ、インデックスの問題なく移行。詳細はSEOに強いコーディング参照）を併記しました。数値は上記の出典と一般に確立された公式仕様値に基づくもののみを記載し、出典不明の効果指標は使用していません。