価格順・新着順のURLはインデックスさせる？並び替えページのSEO設計
目次
価格が安い順、新着順、レビュー順などの並び替えは、同じ商品集合を見やすい順序に変える機能です。多くの場合、並び順が違うだけのURLを個別に検索結果へ出す必要はありません。
並び替えページのSEOでは、元のカテゴリを正規の入口にし、順序違いのURLが大量にクロール、インデックスされないようにします。ただし、サイトの仕様や検索意図によって例外もあるため、URLとページ内容を確認して判断します。
並び替えと絞り込みの違い
絞り込みは表示する商品集合を変えます。並び替えは通常、同じ商品を別の順序で見せます。「黒い靴」に絞ると商品数が減りますが、「価格が安い順」にしても対象商品は変わりません。
URL設計ではこの違いを明確にします。filter、color、sizeなど商品集合を変えるパラメータと、sort、orderなど順序だけ変えるパラメータを分けると、管理しやすくなります。
なぜ重複が起きるのか
並び替えごとにURLがあると、「おすすめ順」「価格昇順」「価格降順」「新着順」でほぼ同じ内容のページが生まれます。カテゴリ数が多いサイトでは、URL数が数倍に増えます。
さらに表示件数、表示形式、セッション情報が組み合わさると、同じカテゴリのURLが多数できます。検索エンジンがそれらをクロールすることで、サーバー資源や重要ページの発見に影響する可能性があります。
基本は元カテゴリを正規ページにする
並び替えが利用者の操作にすぎない場合は、元カテゴリURLを正規の検索着地ページとします。title、h1、説明文、内部リンク、XMLサイトマップは元URLを中心にそろえます。
並び替えURLには、元カテゴリへのcanonical、noindex、リンクの制御などを検討します。ただし、canonicalだけでクロールを止められるわけではありません。サイト内で大量の並び替えURLを生成しないことも重要です。
URLを変えない実装の注意点
JavaScriptで画面上の順序だけ変え、URLを変えない方法もあります。共有や戻る操作で並び順を保持する必要があるか、アクセシビリティ、計測、キャッシュとの関係も考えます。
SEOだけを理由にURLをなくすのではなく、利用者が並び替え状態を保存、共有したいかを確認します。URLを持たせる場合でも、検索対象にすることとは別問題です。
「新着商品」や「人気商品」は別ページにできるか
単なる並び替えではなく、編集方針や更新頻度、固有の説明を持つ「新着商品一覧」「売れ筋ランキング」であれば、独立ページとして価値を持つ場合があります。
その場合は、選定基準、対象期間、更新日、掲載商品の範囲を明確にします。通常カテゴリのsort=newだけをそのままインデックスさせるのではなく、管理された特集やランキングページとして設計します。「人気」と名付けるなら根拠と更新運用が必要です。
ページネーションとの組み合わせ
並び替えとページ番号が組み合わさると、URL数はさらに増えます。「価格順の2ページ目」「新着順の3ページ目」などがすべてリンクされる状態です。
元の並び順で2ページ目以降の商品へクロール可能な経路を用意し、代替ソートのページ番号を検索対象にする必要があるか検討します。内部リンクとサイトマップには、検索対象にしたいURLだけを含めます。
ECサイトでの具体例
「ワイヤレスイヤホン」カテゴリに、おすすめ順、価格が安い順、価格が高い順、新着順、レビュー件数順があるとします。商品集合が同じなら、基本URLを「/wireless-earphones/」とし、各並び替えは操作用のパラメータとして扱います。
サイトマップとパンくずリストは基本URLへ向け、並び替えURLごとのtitleやdescriptionを量産しません。新商品を継続的に紹介する必要があるなら、「新着オーディオ」ページを別途作り、掲載期間や更新方法を決めます。
並び替え後のURLを外部へ共有できる仕様は維持しつつ、検索対象としての正規URLは基本カテゴリにまとめる考え方です。
初期表示の並び順を決める
基本カテゴリの初期表示は、人気、在庫、カテゴリの代表性、価格帯のバランスなど、利用者が候補を見つけやすい基準で決めます。広告費や利益率だけで並べる場合は、利用者の期待とずれていないか確認します。
おすすめ順のロジックを変更したら、同じ商品が先頭へ偏る、在庫切れが上位に残る、新商品が全く見えないといった問題がないかをテストします。並び順はSEOのためだけでなく、商品発見と売上に直接関わります。
パラメータの初期値を統一する
「?sort=recommend」が初期表示と同じなら、パラメータなしURLへ統一します。ロゴ、メニュー、パンくずリストから初期値付きURLへリンクしないようにします。
ユーザーが並び替えを解除したときも、基本URLへ戻るようにします。Cookieやローカル保存で前回の並び順を再現する場合、URLとcanonicalが不意に変わらないか確認します。
構造化データや価格表示との関係
カテゴリ一覧の価格がセール、会員価格、最安バリエーションなど複数ある場合、「価格が安い順」の基準を明確にします。商品カードの表示価格と並び順の計算に使う価格が違うと、利用者は不具合と感じます。
構造化データを使う商品ページの価格や在庫とも整合を確認します。並び替えページ自体に商品詳細向けマークアップを大量に付けることより、商品ページの表示内容とデータを正確に保つことを優先します。
キャッシュと計測の注意
CDNやページキャッシュが並び替えパラメータを無視すると、選んだ順序と違うページが返る場合があります。逆にすべてのパラメータを別キャッシュにすると、キャッシュ数が急増します。検索対象方針と配信設定を合わせます。
アクセス解析では、基本カテゴリと並び替え操作を分けて計測します。URL別のページビューだけでなく、どの順序が使われ、商品詳細への移動や購入にどうつながったかを見ます。
既存サイトでの調査方法
各並び替えを操作し、URL、title、h1、canonical、robots meta、HTTPステータスを記録します。パラメータ順や初期値の有無で別URLができないか確認します。
Search Consoleでsort、orderなどの文字列を含むURLが検出、インデックス、表示されているかを見ます。アクセスログではGooglebotのクロール状況を確認できます。検索流入があるURLを整理する場合は、クエリと着地後の内容を確認してから変更します。
よくある間違い
一つ目は、並び替えごとにキーワードを変えたtitleを自動生成することです。ページ内容が順序以外ほぼ同じなら、独立した価値は生まれません。
二つ目は、robots.txtでブロックしたURLにnoindexを設定し、両方が機能すると考えることです。クロールできなければnoindexを読み取れません。既存インデックスを整理する手順は慎重に決めます。
三つ目は、おすすめ順のアルゴリズムが頻繁に変わるのに、固定の説明やランキング名称を使うことです。表示根拠と名称を一致させます。
確認項目
- 並び替えで商品集合が変わるか、順序だけ変わるか
- 基本となるカテゴリURLを決めているか
- sortやorder付きURLがサイトマップに入っていないか
- 並び替えリンクが不要URLを大量に生んでいないか
- canonical、noindex、robots.txtの整合が取れているか
- ランキングや新着ページに固有の価値と更新ルールがあるか
- ページネーションとの組み合わせを確認したか
並び替え機能を改修するときの手順
最初に、カテゴリごとの初期順、選択できる並び順、生成されるURL、canonical、内部リンクの有無を一覧にします。パソコンとモバイルで実装が異なることもあるため、両方の画面で確認します。ログイン状態や在庫地域によって順序が変わる場合は、その条件も記録します。
次に、利用者の操作として必要な機能と、検索着地ページとして残したいURLを分けます。価格順やレビュー順は操作として必要でも、独立した検索需要があるとは限りません。新着特集などを残す場合は、更新頻度、対象期間、在庫切れ後の扱い、リンク元を決めます。
実装後は、元カテゴリと各並び替えURLのソースを確認し、canonicalが意図したURLを示すか、サイトマップに操作用URLが混ざっていないかを検証します。並び順を変えたあとにページ送りをしても条件が保持されるか、元へ戻したときに不要な初期値パラメータが残らないかも確認してください。
パーソナライズされた並び順の注意
閲覧履歴や地域によって商品順を変える場合、同じURLでも利用者ごとに一覧が異なります。検索エンジン向けだけに別の内容を返すのではなく、基本となる商品集合とリンクを安定して提供したうえで、利用者向けの並び替えを追加します。重要商品の発見を個人設定だけに依存させない設計が必要です。
まとめ
価格順や新着順が同じ商品集合の順序を変えるだけなら、元カテゴリを正規の検索着地ページとして扱うのが基本です。並び替えURLを無制限に増やさず、内部リンク、サイトマップ、canonical、インデックス方針をそろえます。
まず主要カテゴリで全並び替えを操作し、生成URLと検索対象の状態を表にしてください。単なる操作用URLと、独立した企画ページとして価値を持つものを分けることで、使いやすさを保ちながらURLを整理できます。
