
canonicalの使い方|ECサイトの重複URLを整理する基本

目次
canonicalは、同じ内容または非常に似た内容を持つ複数URLの中から、検索エンジンに代表として扱ってほしいURLを示す仕組みです。ECサイトでは、計測パラメータ、並び替え、商品バリエーションなどで似たURLが増えるため、正規URLを一貫して伝えることが重要です。
ただし、canonicalは不要URLを削除する命令ではなく、指定どおりに必ず採用される保証もありません。内部リンク、サイトマップ、転送、ページ内容など、ほかの手掛かりとそろえて使います。
canonicalが必要になる場面
同じ商品ページに計測用パラメータ付きURLとパラメータなしURLがある場合、表示内容が同じならパラメータなしを正規URLとして示せます。大文字・小文字、末尾スラッシュ、HTTPとHTTPSなどの違いで同じ内容へアクセスできる場合も整理対象です。
色やサイズなど商品バリエーションは、各URLの内容と検索価値によって判断します。選択状態だけが異なるなら代表商品へまとめる方法があり、各バリエーションに固有の情報と需要があるなら自己参照canonicalを使う場合があります。
自己参照canonicalとは
検索対象にしたいページ自身をcanonicalに指定することを自己参照canonicalと呼びます。商品、カテゴリ、記事などの正規ページに設定すると、そのURLが代表であるという意図を明確にできます。
テンプレートで自動生成する場合は、実際に表示中の正規URLが出力されるかを確認します。すべてのページがトップページやカテゴリ1ページ目を指す事故が起きると、広い範囲に影響します。
canonicalはhead内へ記述する
HTMLではlink要素のrel属性にcanonicalを指定し、hrefに絶対URLを記述します。レスポンスヘッダーを使う方法もありますが、ECサイトのHTMLページではhead内へ一貫して出力するのが管理しやすい形です。
一つのページに複数の異なるcanonicalを出さないようにします。CMS、プラグイン、タグ管理、JavaScriptが別々に出力していないか、レンダリング後のHTMLまで確認します。
内部リンクとサイトマップをそろえる
canonicalでAを正規URLに指定しながら、カテゴリの商品カードはBへリンクし、サイトマップにはCを載せると、サイト側の手掛かりが矛盾します。主要な内部リンクとXMLサイトマップは正規URLへ統一します。
広告やメールの計測パラメータは必要でも、サイト内の通常リンクに引き継がないようにします。計測URLで訪問した後の関連商品リンクまでパラメータが付く設計は、URL増加の原因になります。
リダイレクトとの使い分け
旧URLを利用者にも見せる必要がなく、新URLへ完全に移したなら、サーバー側の恒久的なリダイレクトが適しています。canonicalは、利用者が両方のURLへアクセスできる必要がある重複・類似ページで使います。
廃止URLを表示し続けてcanonicalだけを新URLへ向けると、利用者は古いページを見続けます。移動、統合、重複のどれに当たるかを先に決めてください。
noindexとの使い分け
noindexはページを検索結果から除外し、canonicalは代表URLへ手掛かりをまとめる目的です。同じサイト内の重複整理で、正規化したいページへnoindexを使うことは一般に推奨されません。
検索結果へ出す価値がない操作用ページならnoindexを検討し、内容は必要だが代表URLをまとめたいならcanonicalを検討します。両方を一律に付けるのではなく、意図を分けます。
ページネーションを1ページ目へまとめない
カテゴリの2ページ目以降は、異なる商品リンクを含むページです。すべてを1ページ目へcanonical指定すると、後半の商品を発見する経路が弱くなる可能性があります。各ページに固有URLを持たせ、自己参照canonicalを設定するのが基本です。
並び替えURLのように商品集合が同じで順序だけが違う場合と、ページ送りで商品集合が変わる場合を区別します。
Googleが選んだcanonicalを確認する
Search ConsoleのURL検査では、ユーザーが指定したcanonicalとGoogleが選択したcanonicalを確認できます。異なるURLが選ばれた場合、タグの誤りだけでなく、内容の類似、内部リンク、転送、サイトマップの矛盾を調べます。
変更後すぐに判断せず、再クロールと処理に時間がかかることを考慮します。変更日と対象URL群を記録し、代表的なURLを継続確認します。
よくある間違い
- canonicalを削除や転送の代わりに使う
- すべてのページをトップやカテゴリ1ページ目へ向ける
- 複数の異なるcanonicalを出力する
- 内部リンクとサイトマップが非正規URLを示す
- 内容が大きく異なるページへ指定する
確認項目
- 正規URLの決定ルールがあるか
- 検索対象ページが自己参照canonicalを持つか
- canonical先が200で表示されるか
- 内部リンクとサイトマップが正規URLへそろっているか
- 転送、noindex、canonicalを目的別に使っているか
- Googleが選択したcanonicalを確認したか
商品バリエーションの設計例
一つの商品ページで色を切り替えるサイトでは、色パラメータ付きURLからも選択状態を再現できるようにし、代表商品へcanonicalをまとめる設計があります。この場合、内部リンクとサイトマップは基本URLを使い、パラメータは共有や広告の必要に応じて発行します。
色ごとに商品名、画像、型番、価格、在庫、検索需要が明確に異なるなら、各URLを独立した正規ページとして扱う選択もあります。各ページは自己参照canonicalを持ち、内容と構造化データもバリエーションに一致させます。
canonical変更を安全に公開する
変更前に、正規URL、非正規URL、ページネーション、商品バリエーション、販売終了のサンプルを用意します。各URLで期待するcanonical先を表にし、テンプレート改修後の出力を自動テストします。
一部カテゴリへ先行公開し、検索対象ページが別URLへまとめられていないかを確認します。問題がなければ対象を広げます。canonicalはhead内の短い記述でも、全ページへ適用されるため段階展開が安全です。
クロスドメインcanonicalの注意
別ドメインに同じ記事や商品情報を掲載する場合、クロスドメインcanonicalを使える場面があります。ただし、提携先やモール側が指定を維持するとは限らず、内容やビジネス上の権利関係も確認が必要です。
自社の複数店舗で同じ商品データを使う場合も、顧客、価格、配送、ブランドが異なるなら、単純な重複ではありません。どのサイトを検索の代表にしたいかを事業方針と合わせて判断します。
監査で見るべき矛盾
canonical先が404、転送、noindexになっていないかを確認します。正規URLがさらに別URLへcanonical指定する連鎖も避けます。最終的な200ページへ一貫して示します。
Search ConsoleでGoogleの選択が異なるURL群を集め、パラメータ、テンプレート、内容差の共通点を調べます。指定が無視されたと決めつけず、サイト側の複数の手掛かりを比較します。
ECサイトでの確認例
同じ商品へ「/product/123」と「/category/shoes/123」でアクセスできる場合、どちらを維持するかを決めます。商品所属が変わっても安定する前者を正規URLにするなら、カテゴリの商品カード、サイトマップ、構造化データも前者へ統一します。
後者には前者へのcanonicalを出せますが、利用者が後者を見る必要がなければ恒久転送のほうが明確です。CMS制約で両方を残す必要がある場合だけ、canonicalで整理します。
確認では、商品が別カテゴリにも所属した場合、カテゴリ名を変更した場合、新商品を追加した場合も同じ正規URLが出るかをテストします。既存ページだけ直っても、生成ルールが残れば重複は再発します。
まとめ
canonicalは、重複・類似URLの代表を検索エンジンへ伝える手掛かりです。ECサイトでは、パラメータ、商品バリエーション、URL表記の違いをページ種別ごとに整理します。
タグだけで完結させず、内部リンク、XMLサイトマップ、転送を正規URLへそろえてください。代表URLと利用者の遷移先を一致させると、運用時の混乱も減らせます。