ANSWER FIRST

結論

長い一覧は、画面の使いやすさだけで表示方式を決めず、続きの各まとまりに永続的なURLを用意し、通常のリンクでも順番にたどれる設計を土台にします。そのうえで、ページ番号、もっと見る、無限スクロールのどれが利用場面に合うかを選び、再読み込み、戻る操作、検索による取得、キーボード操作まで公開前後に確認します。

01

一覧を使う場面から表示方法を選ぶ

ニュース、商品、事例、採用情報が増えると、一覧を短く見せるために「もっと見る」や無限スクロールを使いたくなります。ただし、見た目がすっきりすることと、目的の情報を見つけやすいことは同じではありません。まず、利用者が新着を眺めるのか、条件を比較するのか、途中の位置へ戻るのかを確認します。総件数や現在位置を把握したい一覧ではページ番号が扱いやすく、少量ずつ読み進める一覧ではもっと見るが候補になります。流れを止めずに閲覧することが主目的なら無限スクロールも選べますが、終端やフッターへ到達しにくくならない配慮が必要です。

担当者は、一覧の種類、想定件数、更新頻度、主な端末、絞り込みの有無、再訪時に戻したい位置を一枚の判断表へまとめます。たとえば、過去の告知を年月から探す一覧と、関連事例を次々に眺める一覧では適する方式が異なります。全ページを一度に表示すると通信量や表示時間が増える場合もあるため、速さ、探しやすさ、再訪しやすさを同時に比較し、デザインだけで方式を決めません。

  • 一覧で行う主な作業
  • 総件数と増加ペース
  • 位置や条件を保って戻る必要
  • スマートフォンでの操作
  • 一覧の終端と次の導線
02

画面操作とは別に、続きへ到達できるURLとリンクを用意する

検索エンジンのクローラーは、利用者のように必ずボタンを押したり、画面の末尾までスクロールしたりするわけではありません。Google検索セントラルは、通常はa要素のhref属性にあるURLをたどり、ボタンのクリックや利用者の操作を必要とするJavaScriptを実行しない場合があると説明しています。そのため、もっと見るや無限スクロールを採用するときも、2ページ目、3ページ目に相当する内容へ通常のリンクで到達できる土台が必要です。

各ページには、たとえば?page=2のような永続的で固有のURLを割り当て、URLを直接開いても同じまとまりを表示します。「昨日からの続き」のように内容が日によって変わる相対的な条件は避けます。各ページから次のページと一覧の先頭へリンクし、JavaScriptが動かない状態でも主要な項目へ順番に到達できるかを確認します。画面ではもっと見るで滑らかに追加しつつ、裏側ではページ単位のURLとリンクを保つ設計が可能です。

  • 続きの各まとまりに固有URL
  • 直接開いても同じ内容
  • a要素のhrefで次ページへ接続
  • 先頭一覧へ戻るリンク
  • JavaScriptなしでも主要項目へ到達
ページ分割、もっと見る、無限スクロールの三つの表示方法を同じ安定した一覧設計へつなぐ比較イメージ
VISUAL GUIDE画面の見せ方が違っても、続きの内容へ到達できるURLとリンクを土台にします。
03

正規URLと絞り込みを一覧全体でそろえる

ページ分割した2ページ目以降をすべて1ページ目のcanonicalへ向けると、後続ページに並ぶ項目を独立した一覧として扱いにくくなります。Googleは、ページ分割した各ページに固有の正規URLを持たせるよう案内しています。ページ番号はURLの#以降だけで表さず、サーバーが内容を返せるURLにします。titleや説明文は一覧の主題と一致させ、内部リンク、パンくず、サイトマップ、構造化データで異なる正規URLを示さないようにします。

並び順、表示件数、色、価格帯などの条件をすべて検索対象にすると、ほぼ同じ一覧URLが大量に増えることがあります。必要な組み合わせだけを公開ページとして残し、検索対象にしない条件はnoindexやクロール方針を一覧の役割に合わせて決めます。ただし、robots.txtで取得を止めればnoindexの確認もできない場合があるため、設定を別々に足さず、どのURLを利用者と検索へ残すかを先に決めます。個別の記事・商品・事例ページへのリンクは、どの一覧ページからでも安定して同じURLを指すようにします。

  • 各ページの自己参照canonical
  • ページ番号を含む取得可能なURL
  • 不要な条件URLの公開方針
  • 内部リンクとサイトマップの一致
  • 個別詳細URLの一貫性
04

戻る操作、フォーカス、状態通知まで設計する

一覧で項目を開いて戻ったとき、先頭へ戻されると、利用者は見ていた場所を探し直すことになります。ページ番号なら同じURLと位置へ戻れるか、もっと見るなら追加済みの件数とスクロール位置を復元できるか、無限スクロールなら表示中のまとまりに合わせてURL履歴を更新できるかを確認します。Googleの遅延読み込み解説でも、各まとまりの固有URL、同じ内容の再現、連続したリンク、主要なまとまりが表示されたときのHistory APIによるURL更新が示されています。

キーボードで操作する人には、追加された項目へ突然フォーカスを飛ばさず、もっと見るボタンの次に新しい項目を読める順序を保ちます。読み込み中、追加件数、終端、エラーは、画面を見ている人だけに伝わる変化にしません。W3Cの解説を参考に、現在の作業を邪魔せず支援技術へ状態を通知します。スマートフォンでは、固定メニューや戻るボタンが一覧を隠さないか、終端にある問い合わせやフッターへ到達できるかも確認します。

  • 詳細から戻った位置の復元
  • URLの再読み込みと共有
  • キーボードで自然に続くフォーカス順
  • 読み込み・追加件数・終端の通知
  • フッターと次の行動への到達
05

公開前後を同じ一覧テスト表で確認する

公開前は、1ページ目から最終ページまでのURL、表示件数、重複と欠落、次・前・先頭のリンク、個別詳細へのリンクをテスト表へ記録します。JavaScriptを無効にした確認、レンダリング後HTMLの確認、PCとスマートフォンでの操作、キーボード操作、通信が遅い場合の表示も含めます。絞り込みや並べ替えがある場合は、条件変更後にページ番号が適切に戻るか、存在しないページへ移動しないか、ゼロ件から条件を解除できるかも確認します。

公開後は正式URLで同じ表を再実行し、検索エンジンのURL検査では後続ページの本文と個別リンクがレンダリング結果に含まれるかを確認します。アクセス解析ではページ番号や追加操作の回数だけを成功とせず、詳細閲覧、問い合わせ、購入など一覧の目的へ進めたかを見ます。項目数が増えたときにも最終ページが取得できるか、削除や非公開でページ数が減ったときに空ページが残らないかを定期確認へ加えます。

  • 全ページの件数・重複・欠落
  • リンクと直接URLの確認
  • JavaScriptなし・レンダリング後HTMLの確認
  • PC・スマートフォン・キーボード操作
  • 公開後の取得状況と目的到達
FAQ

よくある質問

無限スクロールを使うとSEOに不利ですか？

方式だけで不利と決まるものではありません。ただし、スクロールしないと現れない内容に固有URLや通常のリンクがなく、クローラーが続きへ到達できない実装は避けます。ページ単位のURLと連続リンクを用意し、レンダリング後のHTMLと正式URLで取得を確認してください。

2ページ目以降は1ページ目へcanonicalを設定すればよいですか？

一律には設定しません。ページ分割した各ページが別の項目を掲載する場合は、それぞれに固有URLと自己参照canonicalを持たせます。1ページ目だけを正規URLにすると、後続ページの項目を検索が見つける手掛かりを弱める可能性があります。

もっと見るボタンだけでも、サイトマップに詳細ページがあれば十分ですか？

サイトマップは発見を助けますが、一覧のリンク構造の代わりにはなりません。利用者とクローラーが一覧から関係をたどれるよう、続きの固有URLと通常リンクを用意し、個別詳細へのリンクもレンダリング後HTMLで確認します。

PRIMARY SOURCES

参考にした一次情報

外部仕様は変更される場合があります。最新情報は各公式ページをご確認ください。

PUBLISHER / UPDATE株式会社ファーストイノベーション

提供サービス：FIRST INNOVATION WEB