EC事業者・担当者が「今日・明日で改善できるSEO施策」をまとめた超実務寄りのEC SEO専門メディア

似た一覧URLを正規化して整理する設計を解説します。ECサイト向け解説記事のアイキャッチ

カテゴリページの重複を防ぐcanonical設計|似た一覧URLの整理方法

似た一覧URLを正規化して整理する設計を解説します。記事の結論と3つの要点をまとめた図
目次
  1. カテゴリページで重複が生まれる原因
  2. 正規URLを決める基準
  3. 自己参照canonical
  4. ページネーションを1ページ目へまとめない
  5. canonicalと転送を使い分ける
  6. canonicalとnoindexを混同しない
  7. 内部リンクとサイトマップを正規URLへ統一する
  8. ECサイトでの具体例
  9. カテゴリ統合時のcanonical
  10. クロスドメインcanonicalの注意
  11. JavaScriptでcanonicalを出す場合
  12. 一覧全体を定期監査する
  13. 確認方法
  14. よくある間違い
  15. 確認項目
  16. canonical変更後の確認期間
  17. まとめ
  18. 次に読みたい関連記事

ECサイトでは、同じ商品一覧が複数のURLで表示されることがあります。末尾スラッシュ、パラメータ、カテゴリ経路、並び替え、表示件数などが原因です。重複を放置すると、検索結果に出したいURLが分かりにくくなり、クロールも増えます。

canonicalは、重複または非常に似たページの中で正規URLの候補を伝える仕組みです。ただし、タグを付けるだけでURL設計の問題がすべて解決するわけではありません。内部リンク、転送、サイトマップ、ページ内容と同じ正規URLを示します。

カテゴリページで重複が生まれる原因

代表的なのは、並び替え、追跡パラメータ、表示件数、セッションID、同じ商品を複数階層から表示するURLです。「/chairs/」と「/furniture/chairs/」が同じ一覧を返す場合もあります。

HTTPSとHTTP、wwwの有無、大文字と小文字、末尾スラッシュの違いも確認します。サーバーがすべて200で返すと、同じ内容のURLが複数存在します。

正規URLを決める基準

正規URLは、利用者に見せたい安定したURLで、内部リンクに使い、サイトマップへ掲載できるものを選びます。不要な追跡情報や表示設定を含めず、カテゴリの内容を継続して表せるURLにします。

検索流入、外部リンク、運用実績がある既存URLを無視して新しいURLへ変えると、移行作業が増えます。URLを見た目だけで選ばず、現状の評価と変更コストも確認します。

自己参照canonical

検索対象にするカテゴリページには、自分自身を指すcanonicalを設定します。HTMLのhead内で、完全な絶対URLを使います。httpとhttps、ホスト名、末尾スラッシュまで正規URLと一致させます。

自己参照canonicalがあれば、追跡パラメータ付きでアクセスされた場合の基準も明確になります。ただし、パラメータURL側にも正しいcanonicalを出力できるか確認します。

ページネーションを1ページ目へまとめない

2ページ目以降は異なる商品を掲載しているため、すべてを1ページ目へcanonical指定するのは適切でない場合があります。インデックス可能な各ページは、原則として自身へcanonicalを向けます。

一方、価格順など商品集合が同じで順序だけ異なるURLは、元カテゴリへcanonicalを向ける候補です。ページ番号と並び替えを同じルールで扱わず、内容の違いを確認します。

canonicalと転送を使い分ける

不要URLへ利用者がアクセスする必要がなく、恒久的に正規URLへ統合できるなら、サーバー側の転送が分かりやすい方法です。canonicalは、ページを表示し続ける必要がある重複URLで使います。

旧カテゴリを廃止したのに200で表示し、canonicalだけ新カテゴリへ向けるより、関連性が高いなら恒久転送を検討します。転送、canonical、内部リンクが別々のURLを示さないようにします。

canonicalとnoindexを混同しない

canonicalは正規URLを示す手掛かりで、noindexは検索結果へ掲載しない指示です。重複URLに両方を付けると意図が分かりにくくなります。正規化したいのか、検索結果から除外したいのかを先に決めます。

robots.txtでクロールを禁止したページでは、canonicalやnoindexを確認できない場合があります。不要URLを整理する施策は、既存のインデックス状態と実装順序を含めて設計します。

内部リンクとサイトマップを正規URLへ統一する

canonicalでAを指定しながら、メニュー、パンくずリスト、商品ページからBへリンクしていると、矛盾した手掛かりを送ります。サイト内のリンクはできるだけ正規URLへ直接向けます。

XMLサイトマップにも正規URLだけを含めます。Googleはサイトマップに掲載されたURLを正規URLの手掛かりとして利用しますが、サイトマップだけで強制できるわけではありません。

ECサイトでの具体例

「ダイニングチェア」カテゴリが、「/chairs/dining/」「/furniture/dining-chair/」「/chairs/dining/?sort=price」の三種類で表示されるとします。まず正式なナビゲーションで使う「/chairs/dining/」を正規URLに決めます。

古い「/furniture/dining-chair/」を今後使わないなら正規URLへ転送します。価格順URLは利用者の操作用に表示を続け、元カテゴリへcanonicalを向けます。ページ2は別の商品を持つため「/chairs/dining/?page=2」自身へcanonicalを設定します。

メニュー、パンくずリスト、サイトマップ、記事からのリンクは正規URLへ更新します。タグ一つではなく、サイト全体で同じURLを選ぶ形です。

カテゴリ統合時のcanonical

二つのカテゴリを統合するとき、旧ページを表示し続ける必要がなければ、新ページへの恒久転送を検討します。旧ページを残してcanonicalだけ向ける方法は、利用者が古い商品集合を見る必要がある場合に限定します。

統合前に、両URLの流入、外部リンク、商品差、検索クエリを確認します。名称が似ていても検索意図が異なるなら、無理に一つへまとめないでください。

クロスドメインcanonicalの注意

同じ商品一覧を本店と別ドメインのブランドサイトで掲載する場合、クロスドメインcanonicalを検討することがあります。ただし、どちらのサイトを検索結果へ出したいか、運営目的、商品購入導線を明確にします。

片方だけを正規にすると、もう一方が検索結果へ表示されにくくなる可能性があります。単なるコピー回避の作業ではなく、ドメイン戦略として判断します。内部リンクやサイトマップも各サイトの方針に合わせます。

JavaScriptでcanonicalを出す場合

可能なら初期HTMLにcanonicalを出力します。JavaScriptで追加、変更する場合は、初期HTMLとレンダリング後で異なるURLを示さないようにします。

フィルタ操作のたびにcanonicalが不安定に切り替わる、相対URLの解決先が変わるといった不具合をテストします。URL検査とソース確認の両方を使います。

一覧全体を定期監査する

カテゴリURL、canonical先、HTTPステータス、インデックス可否を一覧化し、canonical先が存在しない、別言語へ向く、循環するといった異常を抽出します。

新しいフィルタやCMS改修で重複URLが再発するため、サイト移行時だけでなく定期的に確認します。主要テンプレートの自動テストと、Search Consoleでの実際の正規URL確認を組み合わせます。

確認方法

URLの候補ごとに、HTTPステータス、最終URL、canonical、robots meta、title、h1、商品集合を記録します。ソースHTMLとレンダリング後のDOMの両方でcanonicalを確認します。

Search ConsoleのURL検査では、ユーザーが指定した正規URLとGoogleが選択した正規URLを確認できます。Googleが別URLを選んでいる場合は、重複内容だけでなく内部リンクや転送の矛盾を調べます。

よくある間違い

一つ目は、存在しないURLや転送先URLをcanonicalへ指定することです。最終的に200で表示される正規ページへ直接向けます。

二つ目は、カテゴリテンプレートのcanonicalがすべてトップページや1ページ目に固定されることです。ページ番号、フィルタ、サイト移行時に起こりやすい不具合です。

三つ目は、canonicalを設定したから内部リンクを直さなくてよいと考えることです。正規URLをサイト内の標準として使います。

確認項目

  • 同じ商品集合を返すURLを洗い出したか
  • 正規URLが安定し内部リンクに使えるか
  • 検索対象ページが自己参照canonicalを持つか
  • ページネーションと並び替えを分けているか
  • 転送、canonical、サイトマップが同じURLを示すか
  • canonical先が200で表示されるか
  • Googleが選択した正規URLを確認したか

canonical変更後の確認期間

canonicalを修正しても、検索結果の正規URLがすぐに切り替わるとは限りません。変更日、対象URL群、旧設定、新設定を記録し、Googleが選択した正規URLを一定期間確認します。アクセス状況やクロールの頻度によって反映の時間は異なるため、短期間の変化だけで設定を何度も戻さないことが大切です。

意図したURLが選ばれない場合は、canonicalタグだけでなく、内部リンク、サイトマップ、転送、ページ内容、URLの安定性を見直します。正規URLに指定したページが一時的に404になる、在庫条件で内容が空になる、別URLへ転送されるといった矛盾があれば、canonicalの手掛かりは弱くなります。

大規模な修正は、一つのカテゴリ群でテストしてから広げます。テンプレートの一行を直すだけでも、ページネーションやブランド一覧など意図しないページへ影響する可能性があります。対象外のURLサンプルも同時に確認し、正規URLの分布が想定どおりかを見てください。

まとめ

カテゴリページのcanonical設計では、似た一覧URLの中から安定した正規URLを決め、タグ、転送、内部リンク、サイトマップをそろえます。ページネーションのように商品集合が異なるURLまで一律に1ページ目へまとめないことが重要です。

主要カテゴリでURLの変化をすべて操作し、一覧表を作ってください。どのURLを残し、どれを転送し、どれを操作用としてcanonicalでまとめるかを決めると、サイト全体へ同じルールを展開できます。

次に読みたい関連記事