ECサイトのURL構造をSEO視点で設計する方法
目次
ECサイトのURL構造は、商品やカテゴリの場所を安定して示し、利用者と検索エンジンがページを識別しやすくするための基盤です。短いURLにすることだけが目的ではなく、同じ内容の代替URLを増やさず、将来の商品入れ替えにも耐えられる設計が求められます。
既存サイトでは、分かりやすさのためだけにURLを一括変更すると移行負荷が生じます。新規設計と既存URLの改善を分け、変更する場合は転送と対応表を用意します。
良いURL構造の条件
ページごとに一意で、長期的に維持でき、意味のないパラメータやセッション情報を含まないことが基本です。可能なら人が内容を推測できる語を使い、階層を必要以上に深くしません。
日本語URLを使うか英数字へするかは、CMSや運用環境も含めて決めます。どちらでも、表記ルールを統一し、担当者ごとに異なる形式を作らないことが重要です。
商品URLはカテゴリ変更に引きずられないようにする
商品URLへカテゴリ階層を含めると、商品の所属変更でURLも変わる場合があります。同じ商品を複数カテゴリへ置くと、複数URLが生まれる設計もあります。
商品IDや安定したスラッグを基準に一つのURLを用意し、カテゴリとの関係はパンくずリストや内部リンクで示すと管理しやすくなります。既存CMSの制約がある場合は、代表URLとcanonicalのルールを決めます。
カテゴリURLは役割を反映する
カテゴリの親子関係をURLパスへ反映する方法は分かりやすい一方、階層変更でURLが変わりやすくなります。頻繁に再編する分類なら、URLと表示上の階層を完全に連動させない設計も検討します。
「sale」「new」のように意味が変わる語を固定URLへ使う場合は、ページの役割が将来も維持できるかを確認します。期間限定企画を同じURLで別内容へ使い回すと、過去のリンクや検索意図とずれることがあります。
パラメータはkey=value形式で安定させる
絞り込みやページ番号にパラメータを使う場合は、何を表すか分かるkey=value形式にします。同じ条件のパラメータ順を統一し、初期値だけが付いたURLや同じキーの重複を避けます。
セッションID、現在時刻、個人ごとの位置情報など短期間で変わる値を内部リンクへ含めないようにします。同じページへ無数のURLが生まれる原因になります。
フラグメントで主要内容を切り替えない
URLの#以降は、同じページ内の位置を示す用途があります。商品やカテゴリなど別ページとして検索させたい主要内容を、フラグメントだけで切り替える設計は避けます。
JavaScriptアプリで画面ごとに内容が異なるなら、History APIなどを使って各画面に固有URLを持たせ、直接アクセス時にも同じ内容を返せるようにします。
大文字・小文字と末尾スラッシュを統一する
サーバーによっては大文字と小文字、末尾スラッシュの有無を別URLとして扱います。同じ内容を返すなら、内部リンクを一形式へ統一し、必要に応じて正規形式へ転送します。
canonicalだけを置いて代替URLを生成し続けるより、入口で一つへそろえるほうが利用者とログ分析にも分かりやすくなります。
商品バリエーションのURL
色やサイズへ直接アクセスする必要がある場合は、パスまたはクエリでバリエーションを識別できるURLを用意します。アクセスしたときに正しい画像、価格、在庫、選択状態が表示され、カートへ正しい商品を入れられることが必要です。
代表商品へcanonicalをまとめるか、各バリエーションを正規ページにするかは、固有情報と検索需要によって決めます。URL、canonical、構造化データの商品IDを一貫させます。
URL変更は必要性を見極める
意味の分かりにくいID型URLでも、安定してインデックスされ流入があるなら、見た目だけを理由に変更する必要はありません。変更には転送、内部リンク、サイトマップ、広告、商品フィードなど広い更新が伴います。
重複が解消できる、CMS移行が必要、分類設計を根本から直すといった明確な目的がある場合に、URL対応表とテスト計画を作ります。
公開前のテスト
商品、カテゴリ、バリエーション、検索、絞り込み、ページ送りのURL例を一覧にします。同じ操作を繰り返してURLが変わらないか、直接開いて同じ状態を再現できるかを確認します。
不正なパラメータ、存在しない商品ID、範囲外ページ番号へ適切なHTTP応答を返すかもテストします。すべて200で空画面を返す設計はsoft 404や不要URLの原因になります。
よくある間違い
- 短さだけを優先して意味や安定性を失う
- 商品カテゴリ変更のたびにURLを変える
- セッションIDや計測値を内部リンクへ引き継ぐ
- 同じ条件で複数のパラメータ順を作る
- 既存URLを理由なく一括変更する
確認項目
- 各ページに安定した一意URLがあるか
- 同じ内容の代替URLを増やしていないか
- パラメータの意味と順序が統一されているか
- 商品バリエーションを直接再現できるか
- 内部リンク、canonical、サイトマップが同じ形式か
- URL変更時の転送表があるか
URL設計を商品マスタと合わせる
商品コードをURLに使う場合、コードが再利用されないか、将来変更されないかを確認します。仕入先コードや表示用型番は変わることがあるため、内部の不変IDと公開用スラッグを分ける設計もあります。
スラッグを商品名から自動生成すると、名称変更のたびにURLを変えたくなることがあります。公開後はURLを維持し、titleやh1だけ更新する運用にすると、不要な移行を減らせます。
多言語・複数国サイトのURL
言語や国をサブディレクトリ、サブドメイン、別ドメインのどこで分けるかを決めます。どの方式でも、各ページへ固有URLを持たせ、言語をCookieやブラウザ設定だけで切り替えないことが重要です。
通貨や配送先だけをパラメータで変える場合も、その状態を検索対象にするかを明確にします。ユーザーごとの現在地や時刻をURLへ入れると、安定しないURLが増えます。
計測パラメータを正規URLへ持ち込まない
広告やメールでutmなどの計測パラメータを使うことはありますが、ページ内リンクへ引き継がないようにします。訪問後のすべての商品URLへパラメータが付くと、ログやクロールのURL種類が増えます。
計測はアクセス解析側で行い、canonicalはパラメータなしのURLを示します。サイトマップと通常の内部リンクにもパラメータなしを使います。
URLポリシーを文書化する
商品、カテゴリ、記事、画像、パラメータの形式、文字種、末尾スラッシュ、正規ホスト、変更時の承認を一つの文書にします。開発担当だけでなく、商品登録やキャンペーン作成の担当者も参照できる内容にします。
新機能を追加するときは、生成されるURL例、最大数、検索対象、canonical、サイトマップ、エラー応答をレビューします。公開後にURL増加を発見するのではなく、設計段階で確認します。
ECサイトでの設計例
商品URLを「/products/不変ID-短い商品名」とし、カテゴリURLを「/categories/カテゴリ名」とする方法があります。商品名や所属カテゴリが変わっても不変IDで同一商品を識別し、公開後はURLをむやみに変えません。
色バリエーションは「?color=black」のようにkey=valueで再現し、代表商品へまとめるなら基本URLをcanonicalにします。独立ページとして扱う場合は、各URLへ自己参照canonicalと固有情報を用意します。
設計時には、存在しない商品ID、削除済みカテゴリ、無効な色、ページ番号の上限も決めます。空テンプレートを200で返さず、適切な4xxまたは正規URLへの転送を返すことで、無限URLの発生を防げます。
まとめ
ECサイトのURL構造では、一意性、安定性、再現性を優先します。商品やカテゴリの役割を識別でき、不要なパラメータや表記違いで代替URLが増えないようにします。
新規設計では将来の分類変更を見越し、既存サイトでは変更の効果と移行負荷を比較してください。URLを変える場合は、一対一の転送と内部リンクの更新まで含めて計画します。
