ページネーションと段階的なページ読み込み ── rel="next"廃止後の考え方を確認する13項目（2026年9月時点）

01 何が起きたか — rel="next"/"prev"は「もう使っていない」と明記された

Googleは、かつての推奨方法を廃止したと明言している

Google Search Centralの「ページネーションと段階的なページ読み込み」というページには、記事一覧や検索結果一覧のような長いコンテンツを複数ページに分ける際の考え方がまとめられている。この分野で長年語り継がれてきたのがrel="next"・rel="prev"というリンク属性で、ページ同士の前後関係をGoogleに伝える目的で広く使われてきた。だが公式ドキュメントは、この方法についてこう明記している。

"Google no longer uses these tags, although these links may still be used by other search engines."

（訳: Googleはこれらのタグをもう使用していない。ただし他の検索エンジンでは、これらのリンクが今も使われている可能性がある。）

(前掲のPagination and incremental page loading)　rel="next"/"prev"を設置している既存の実装を、慌てて削除する必要はない。他の検索エンジンが参照している可能性がある以上、残すこと自体に害はない。だが「これを設置しておけば、Googleにページの並び順が正しく伝わる」という前提は、もはや成立しないと理解しておく必要がある。

3つのUIパターンが、優劣ではなく並記されている

公式ドキュメントは、長いコンテンツを分けて表示する方法として、ページネーション（番号付きのページ送り）・もっと見る（クリックで追加読み込み）・無限スクロール（スクロールで自動読み込み）の3つを挙げている。重要なのは、この3つに優劣が付けられているわけではないという点である。コンテンツの量やユーザーの利用シーンに応じて選ぶものとして並記されており、「今の標準はこれ」という単一の正解を示すのではなく、選択肢の使い分けを示す構成になっている。この記事では、3つのパターンそれぞれをGoogleがクロールできる状態に保つための条件を整理する。

なぜこの内容が、ECサイトの文脈で公開されているか

この公式ドキュメントは、Google Search Centralの中でも「eコマース」というカテゴリの配下に置かれている。商品一覧・カテゴリ一覧のような、件数が多く定期的に更新されるコンテンツを持つサイトで、ページ分割の設計が特に問題になりやすいためだと考えられる。ただしガイドライン自体の内容は、eコマースに限定されたものではない。記事一覧・検索結果一覧・お知らせ一覧など、同じ構造を持つコンテンツであれば、業種を問わず同じ基準がそのまま当てはまる。

02 なぜ・背景 — クローラーは、ユーザーのように操作しない

無限スクロールとクローラーの相性が悪い、根本の理由

無限スクロールや「もっと見る」ボタンは、いずれもJavaScriptによって、ユーザーの操作をきっかけにコンテンツを後から読み込む実装である。ここで問題になるのが、Googleのクローラーはスクロールもクリックもしないという前提である。Googleの遅延読み込みに関する公式ドキュメントは、この点をはっきりと述べている。

"...don't rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page."

（訳: スクロールやクリックといったユーザーの操作に依存してコンテンツを読み込む実装にしてはならない。Google検索はページを操作しないため、これは重要である。）

(前掲のLazy-loading best practices)　つまり、ユーザーがスクロールして初めて読み込まれるコンテンツは、そのスクロール動作が発生しない限り、Googleには最初から存在しないのと同じ扱いになる。これは無限スクロールという実装方式そのものを否定しているのではなく、「操作なしでは中身にたどり着けない」設計になっていないかを確認せよ、という指摘である。

Intersection Observerが推奨される理由

公式ドキュメントは、コンテンツをビューポートに入った時点で読み込む方法として、ブラウザ標準の遅延読み込み機能とIntersectionObserver APIを挙げている。この2つに共通するのは、要素が画面内に入ったことを検知して自動的に発火する仕組みであり、ユーザーの明示的な操作（スクロールイベントの発火を待つ、クリックを待つ）を前提にしていない点である。無限スクロールを実装する場合、この仕組みを使ってコンテンツを読み込むこと自体は問題にならない。問題になるのは、次章で述べるURLの更新が伴っていない場合である。

URLが更新されないと、何を失うか

コンテンツ自体はIntersectionObserverで正しく画面に表示されていても、URLが更新されなければ、その塊は「アドレスを持たないコンテンツ」になる。これは、リンクの形式を扱った回で述べた「評価の受け渡し」という信号が届かなくなることと同じ構造の問題である。あるページから無限スクロールの奥深くにある特定のコンテンツへ直接リンクを張ろうとしても、固有URLが存在しなければリンクの張りようがなく、被リンクによる評価も、内部リンクによる評価の受け渡しも、その塊には届かない。

03 この記事で出てくる用語

「持続する固有URL」という条件

公式ドキュメントは、無限スクロールで表示される各コンテンツの塊について、persistent, unique URL（持続する固有のURL）を持たせることを求めている。さらに、URLのパラメータには?page=12のような絶対的なページ番号を使うことが望ましく、?date=yesterdayのような相対的な指定は避けるべきだとも述べている。相対指定は、翌日には同じURLが別の内容を指すことになり、そのURLがブックマークされたり検索結果に載ったりした場合に、想定と異なる内容が表示される原因になるためである。

「昨日」と「12ページ目」は、URLとして意味が違う

相対的な指定が避けられるべき理由を、もう少し具体的に考える。?date=yesterdayというURLパラメータは、それを見た人間には分かりやすいが、今日アクセスした場合と明日アクセスした場合とで、指し示す実際の日付が変わってしまう。検索結果に一度インデックスされたURLが、後日まったく別の内容を表示するようになると、検索してそのページにたどり着いたユーザーは、期待した内容と異なるものを目にすることになる。?page=12のような絶対的な番号であれば、いつアクセスしても同じ12番目のコンテンツの塊を指し続けるため、この食い違いが起きない。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どの実装を選ぶか

3つのUIパターンは、コンテンツの性質によって向き不向きが分かれる。ページネーションは、途中のページに直接アクセスしたいニーズがある場合（商品一覧の2ページ目だけをブックマークしたい、など）に向く。もっと見るは、ある程度の件数までは1画面で完結させたいが、無限にコンテンツが増え続けるわけではない場合に向く。無限スクロールは、SNSのタイムラインのように、次々と新しいコンテンツを消費し続けるような利用シーンに向くが、ページ下部のフッターやコンテンツ全体を一望する導線が失われやすいという弱点も持つ。この記事のチェックリストは、3つのどれを選んでいても共通して確認すべき「クロール可能なURLの有無」を中心に構成している。

🅱 この記事が測っていないこと

この記事は、ページ分割の実装がGoogleにクロールされる状態になっているかという観点だけを扱っている。どのUIパターンがコンバージョン率や滞在時間などのユーザー行動指標に対して優れているかという論点、ページ分割された記事全体としての評価がどう算出されるかという論点、無限スクロールの実装がページの表示速度に与える影響については、この記事の範囲外である。それらは別の観点からの確認が必要になる。

🅲 手順 — 4段階で確認する

確認は、現状の把握・URL構造の確認・クロール経路の確認・実装方式の見直しの4段階で進めるとやりやすい。まず自分のサイトのどのページが複数ページに分割されているかを洗い出し、それぞれがどのUIパターンで実装されているかを確認する（現状の把握）。次に、各ページの塊が個別のURLを持っているか、そのURLが?page=のような絶対的な番号方式になっているかを確認する（URL構造の確認）。続いて、あるページから次のページへ、<a href>タグによる実際のリンクがあるかどうかを確認する（クロール経路の確認）。最後に、無限スクロールやもっと見るボタンで、URL更新やクロール可能なリンクが欠けている場合は、実装方式そのものの見直しを検討する（実装方式の見直し）。

05 明日、自分のサイトで確認できることチェックリスト

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、現状把握、URL構造の検証、リンクの検証、無限スクロール固有の確認、の4つに分かれる。

• 複数ページに分割されている一覧ページを3つ選び、それぞれがページネーション・もっと見る・無限スクロールのどれで実装されているか書き出す
• ページネーションの場合、2ページ目・3ページ目のURLがそれぞれ固有のものになっているか、ブラウザのアドレスバーで確認する
• URLに含まれるパラメータが、絶対的なページ番号（page=2など）になっているか、相対的な指定（昨日、今週などの表現）になっていないか確認する
• 1ページ目のHTMLソースを開き、2ページ目へのリンクが<a href>タグで実装されているか確認する
• もっと見るボタンがある場合、ボタンのHTMLソースを確認し、href属性を伴わずonclickだけで追加コンテンツを読み込んでいないか確認する
• 無限スクロールがある場合、スクロールして新しいコンテンツが表示された瞬間に、ブラウザのアドレスバーのURLが変化するか確認する
• 無限スクロールで表示された個々のコンテンツの塊について、そのURLに直接アクセスした場合に同じ内容が表示されるか確認する
• rel="next"・rel="prev"が設置されている場合、それらを削除する必要はないと理解した上で、クロール可能な<a href>リンクが別途存在するかを優先して確認する
• 各分割ページから、シリーズの最初のページへ戻るリンクが設置されているか確認する
• 分割後の各URLがsitemap.xmlに含まれているか、またはmerchant feedなど他の発見経路が用意されているか確認する
• Google Search ConsoleのURL検査ツールで、2ページ目以降のURLを検査し、インデックス登録の状況を個別に確認する
• スマートフォン表示でも同じ実装方式になっているか、PC版と別のUIパターンを使っていないか確認する
• 今日確認した内容を1ヶ月後に同じ手順で再確認する予定を、カレンダーに入れる

13項目の内訳と、かかる時間の目安

13項目は4つの観点に対応している。それぞれの観点にどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1サイトあたり40〜50分程度である（Search Consoleでの個別確認を含める場合は、データ反映を待つ時間が別途必要になる）。まずは代表的な一覧ページを1つ選んで確認するところから始めるとよい。

見落としやすい2つのポイント

チェックリストを実施する際に見落としやすい点が2つある。1つ目は、「もっと見る」ボタンを押した後に表示された領域だけを確認し、押す前の初期表示部分の確認を省いてしまうケースである。初期表示部分と追加読み込み部分の両方を、同じ基準で確認する必要がある。2つ目は、ページネーションの見た目を持ちながら、実装の中身はJavaScriptによる無限スクロールになっている「ハイブリッド型」の存在である。ページ番号のリンクが表示されていても、実際にクリックした際の挙動をHTMLソースまで確認しないと、どちらの型かは判断できない。見た目のページ番号が実は<button>要素で、クリック後にJavaScriptがコンテンツだけを差し替えてURLを更新しない実装は、このハイブリッド型の典型的な失敗パターンである。ページ番号らしき表示に安心せず、そのページ番号がリンクとして機能しているのか、単なる見た目の飾りなのかを、HTMLソースを開いて区別する習慣を付けておくとよい。

06 代替・他の選択肢（表で）

3つのUIパターンの、できることとできないこと

公式ドキュメントが挙げる3つのUIパターンについて、それぞれの強みと限界を整理した表である。

History APIを使う実装と、使わない実装の違い

無限スクロールの実装方法にも幅がある。以下は、URLの扱い方に注目した比較である。

モバイルとPCで実装が分かれている場合の注意

レスポンシブ対応が不十分なサイトでは、PC版はページネーション、スマートフォン版は無限スクロールというように、デバイスごとに異なるUIパターンを採用しているケースがある。この場合、確認作業もデバイスごとに個別に行う必要がある。片方のデバイスで固有URLとクロール可能なリンクが確認できても、もう片方でも同じ条件が満たされているとは限らない。Googleのクロールはモバイル版のコンテンツを基準に行われるため、モバイル版の実装を優先して確認する価値がある。

07 自社サイトで確認したこと — 自社のページネーションを実際に確認した

rel="next"は残っていたが、実害はなかった

この記事を書くにあたり、当サイトのSEO関連記事一覧ページの実装を確認した。一覧ページは<a href="/seo_article/index/page:2">のように、番号付きの固有URLを持つページネーション方式で実装されており、各ページへのリンクは正しく<a href>タグとして出力されていた。一方で、次ページへのリンクにはrel="next"属性も付与されていることが分かった。01章で確認したとおり、この属性自体はGoogleがもう参照していないため、付いていることによる悪影響はないが、積極的に効果を発揮しているわけでもない、という状態だった。

この確認でも分からないこと

今回確認できたのは、ページネーションの実装がクロール可能な形式になっているかという点までである。実際にGoogleが各ページを個別にクロール・インデックスしているかどうかは、Search Consoleのデータを時間をかけて観察しないと判断できない。クロール可能な形式で実装されていることと、実際にクロールされ評価されることは、別の段階の話であり、後者を確認するには05章のチェックリストに含めたURL検査ツールでの個別確認を、継続的に行う必要がある。

08 このテーマの、これまで

クロールの待ち行列を、実際の数字で確認した回

02章で触れた「クローラーは操作しない」という前提は、クロールの実行タイミングそのものにも関わってくる。無限スクロールで発見が遅れがちなコンテンツが、実際にはどれくらいの待ち時間でクロールされるのかを考える際、当サイトが実際に数えたクロール待ち行列の記録が参考になる(archives/108)。ページ分割の設計次第では、この待ち時間がさらに積み重なる可能性がある。

sitemap・URL構造の整合性を確認した回

05章のチェックリストで触れたsitemapへの掲載についても、当サイトでは以前に整合性を機械的に確認する方法を扱っている。sitemap・canonical・内部リンク・末尾スラッシュの4つをcurlコマンド3行で揃える方法(archives/39)と、sitemapに書いたURLがGoogleから実際にどう見えていたかを確認した回(archives/38)は、いずれもページ分割されたURL群の管理にもそのまま応用できる。

リンクの形式そのものを確認した回

ページ分割の各URLへ正しくリンクが張られているかという点は、リンクの形式一般を扱った回とも重なる。href属性を持つ<a>要素だけがクロール可能なリンクとして扱われるという基準を、実例とともに整理した回がある(リンクをクロール可能にする)。ページ分割の実装でも、次のページへのリンクがこの基準を満たしているかを、あわせて確認しておきたい。