ECサイトの重複コンテンツとは？発生原因とURLの整理方法
目次
ECサイトの重複コンテンツとは、同じ内容または非常に似た内容が複数のURLで公開されている状態です。重複があるだけで直ちにペナルティになると考える必要はありませんが、検索エンジンが代表URLを選びにくくなり、不要なクロールや管理負荷を増やす原因になります。
対応では、文章を無理に書き換える前に、なぜ複数URLが生まれているかを確認します。URLを一つに統合できるのか、利用者のために複数ページが必要なのかで、転送、canonical、個別ページ改善を使い分けます。
ECサイトで重複が生まれやすい理由
色・サイズ・容量などの商品バリエーション、カテゴリの所属違い、絞り込み、並び替え、表示件数、計測パラメータから複数URLが生成されます。HTTPとHTTPS、wwwあり・なし、末尾スラッシュなど表記の違いもあります。
商品説明の面では、メーカー提供文を複数ショップが使用することがあります。同一サイト内でも、似た商品の説明をテンプレートから複製すると、ページ固有の違いが伝わりにくくなります。
技術的なURL重複を先に見つける
一つの商品を、カテゴリ経由、サイト内検索、広告URLから開き、アドレスの違いを記録します。各URLのHTTP応答、canonical、内部リンク、サイトマップ掲載を確認します。
画面が同じでもURLが変わる場合は、サイト全体で何通り生成されるかを推定します。個別URLを修正するより、ルーティングやリンク生成のルールを直すほうが効果的です。
統合できるURLは転送する
旧商品URLから新商品URLへ完全に移動した、URL表記を一つへ統一したなど、利用者が旧URLを見る必要がない場合は恒久的なリダイレクトを使います。旧URLと新URLの対応表を作り、最も近い内容へ一対一で転送します。
大量の旧商品を関係のないトップページへ転送すると、利用者の意図を引き継げず、soft 404として扱われる可能性があります。代替先がない場合は、404や410を返すほうが適切なこともあります。
複数URLが必要ならcanonicalを使う
計測パラメータなど、利用者がアクセスするURLは残しつつ代表URLを示したい場合にcanonicalを使います。正規URLは内部リンクとXMLサイトマップにも使用します。
canonical先と内容が大きく異なる場合は、指定が採用されないことがあります。単に検索対象から外したいだけならnoindex、ページを移したなら転送というように、目的を先に整理します。
商品バリエーションの判断
色だけが変わり、商品名、説明、価格、用途がほぼ同じなら、代表商品ページへまとめる設計があります。一方、型番、画像、在庫、価格、検索需要が異なるなら、各バリエーションに固有URLと情報を持たせる選択があります。
どちらの場合も、選択した色やサイズへ直接アクセスでき、カートへ正しい商品を追加できる状態が必要です。URLと構造化データの商品識別子もそろえます。
カテゴリ所属によるURL重複
商品URLへカテゴリ階層を含めるCMSでは、同じ商品が複数カテゴリに属すると複数URLができることがあります。可能なら商品IDを基準に一つのURLへし、カテゴリはパンくずや内部リンクで表現します。
複数URLが避けられない場合は、代表カテゴリの決定ルールを作り、canonicalと内部リンクを正規URLへ統一します。商品の所属変更で正規URLが頻繁に変わらないようにします。
本文の重複を改善する
メーカー仕様は正確性を優先し、無理に言い換える必要はありません。その上で、自社の配送条件、保証、サイズの測り方、スタッフが確認した使い方、よくある質問など、購入判断に必要な事実を加えます。
似た商品を量産的な表現で差別化するのではなく、違いを比較できる項目を用意します。色、素材、対応機器、使用環境など、実際に異なる情報をページへ反映します。
サイト内検索とフィルタURL
自由入力の検索結果やフィルタの任意組み合わせは、既存カテゴリと同じ商品集合を返しやすい領域です。検索対象にする条件を限定し、それ以外はURL生成、内部リンク、noindex、robots.txtなどを組み合わせて管理します。
需要がある組み合わせは、自動URLをそのまま残すのではなく、安定した固定URL、固有の案内、正規URL、更新ルールを持つ着地ページへ整えます。
重複を確認する方法
Search ConsoleのURL検査で、Googleが選択したcanonicalを確認します。クロールツールやログでは、同じtitleやcanonical先を持つURL群、パラメータの種類、内部リンク数を調べます。
件数だけで削除せず、URL例を目視して、本当に同じ内容か、利用者の意図が異なるかを判断します。テンプレート共通部分が多いことと、ページ全体が重複していることは分けて考えます。
よくある間違い
- 重複があるだけでペナルティと断定する
- 文章の言い換えだけでURL重複を解決しようとする
- 非正規URLへ内部リンクし続ける
- 関係のないページへ一括転送する
- 商品バリエーションを一律に統合または分割する
確認項目
- 同じ内容へ何通りのURLでアクセスできるか
- 正規URLのルールが一貫しているか
- 転送、canonical、noindexを目的別に選んでいるか
- 内部リンクとサイトマップが正規URLを使うか
- 商品固有の購入判断情報があるか
重複URLの対応表を作る
URLパターン、発生機能、内容差、内部リンク元、検索流入、希望する正規URL、対応方法を一覧にします。パラメータを一つずつ見るのではなく、色と並び順、ページ番号と表示件数のような組み合わせも含めます。
対応方法は、生成停止、恒久転送、canonical、noindex、個別ページとして維持のいずれかに分類します。robots.txtはクロール管理であり、正規化そのものではないため別列にします。
商品データの共通部分と固有部分を分ける
大量商品では、配送、返品、支払いなど店舗共通の説明をテンプレートで持つことが合理的です。共通文があること自体を重複問題と捉えず、商品固有の情報がどこにあるかを確認します。
商品名、型番、仕様、対応条件、サイズ、素材、在庫、画像、選び方が商品マスタから正しく出るようにします。同じテンプレートでも、事実が異なれば利用者にとって役立つ比較ができます。
海外・複数店舗での重複
言語や国が異なるページは、同じ商品でも価格、通貨、配送、言語が異なり、単純な重複とは限りません。hreflangと各言語のcanonicalを正しく設定し、利用者の地域に合うページを示します。
ブランド別店舗や卸向け店舗では、対象顧客と取引条件が異なるかを整理します。内容が本当に同じなら統合も検討し、別サイトとして運営するなら固有の価値と正規URLを持たせます。
改善後の測定
非正規URLへの内部リンク数、クロール数、Googleが選択したcanonical、サイトマップURL数を確認します。検索流入だけでは、整理が正しく伝わったかを判断しにくいため、技術指標を先に見ます。
URL削減後に重要商品のクロールや登録がどう変わったかを追います。ただし、canonical整理だけで順位や売上が必ず改善すると断定せず、内容、需要、競合、在庫も含めて評価します。
優先順位の付け方
まず、正規URLが検索結果に出ず非正規URLが入れ替わる、サイトマップと内部リンクが別URLを示すなど、重要ページの代表選択に影響する問題を優先します。次に、大量のパラメータやセッションURLを整理します。
少数商品の説明が似ている問題は、利用者が比較しにくいページから改善します。商品数、流入、売上だけでなく、返品や問い合わせが多い商品は、固有情報を補う事業上の価値があります。
対応後は、正規URLの安定、不要URLへのリンク減少、商品比較のしやすさを確認します。単にインデックス総数を減らすことを目標にせず、必要ページが残っているかを同時に見ます。
まとめ
ECサイトの重複コンテンツは、URL生成と商品情報の両面から発生します。まずURLの発生原因を調べ、統合できるものは転送し、複数URLが必要なものはcanonicalなどで代表を明確にします。
文章は不自然に言い換えるのではなく、商品ごとの事実と購入判断に必要な情報を補ってください。技術ルールと編集ルールをそろえることで、商品数が増えても重複を管理しやすくなります。
