W2 マルチブランド構成のドメインの分け方
W2で3ブランドを運営し、ブランドごとに別ドメインにしたものの、どのブランドも検索で弱い。1つにまとめるべきだったのか、という相談がよく寄せられます。
ブランドの独立性と、検索評価の集約は、トレードオフです。別ドメインにすれば各ブランドは独立しますが、評価は3つに分散します。1つのドメインのサブディレクトリにまとめれば、評価は集まります。その代わり、ブランドは「1社の商品ライン」として見えます。正解は、ブランドが本当に独立した存在として知られるべきかどうかで決まります。1つの企業の商品群として見られて構わないなら、まとめる側です。
この記事では、3つの構成を比べます。判断基準、共通商品の重複、Organizationの設計、ストアを追加するときの手順も整理します。
結論: ブランドが独立した認知を持つなら別ドメイン。持たないならサブディレクトリ。迷ったらサブドメイン
構成 | 評価の蓄積 | ブランドの独立性 | 運用負荷 | 向いている場合 |
|---|---|---|---|---|
別ドメイン | 分散 | 高 | 高(Search Console・サイトマップ・robots が各々) | ブランドが個別に認知され、相互に関連づけたくない |
サブドメイン | ほぼ分散(近年は同一サイト扱いの傾向) | 中 | 中 | ブランドの独立性を保ちつつ、企業としてのつながりも見せたい |
サブディレクトリ | 集約 | 低 | 低 | 1社の商品ラインとして扱われて構わない。評価の集約を優先 |
重要な考え方: ドメインは「検索エンジンにとっての会社の単位」です。分ければ別会社、まとめれば1社。ブランド戦略で決めたことを、ドメインで裏切らないようにします。
判断の基準
質問 | はい → | いいえ → |
|---|---|---|
ブランド名で検索されているか(指名検索がある) | 別ドメインまたはサブドメイン | サブディレクトリ |
ブランド間で顧客層が異なるか | 別ドメイン | サブディレクトリ |
各ブランドに専任の運用担当がいるか | 別ドメイン | サブディレクトリ |
共通商品が多いか | サブディレクトリ | 別ドメイン |
企業名での認知を高めたいか | サブディレクトリ | 別ドメイン |
「はい」が多いほど分ける側、「いいえ」が多いほどまとめる側です。
データポイント: 7.5万ブランドを分析したAhrefsの研究では、AI Overviewsへの露出と最も強い相関を示した信号は被リンク数(0.218)ではなくブランドのウェブ上の言及(0.664)でした。
共通商品が重複したときの対処
複数のストアで同じ商品を扱うと、同じ商品ページがストアの数だけできます。同じTシャツのページが、ブランドごとに並ぶ状態です。
構成 | 重複の扱い |
|---|---|
別ドメイン | 各ドメインが独立したページとして索引される。内容が同じなら、どちらかが重複として除外される可能性 |
サブドメイン・サブディレクトリ | 同一サイト内の重複。canonicalで1つに寄せる |
対処:
主となるストアを決め、他のストアの共通商品ページはcanonicalで主ストアに寄せる
または、ストアごとに商品説明を書き分け、重複でなくする(運用負荷は高い)
共通商品が大半なら、そもそもストアを分ける意味を再検討する
canonicalは、どのURLが正なのかを検索エンジンに伝える印です。W2のマルチストア機能で、共通商品のcanonicalがどう出力されるかは、仕様で確かめてください。あわせて、主となるストアをどれにするかを決めます。
Organization構造化データの設計
構成 | Organizationの置き方 |
|---|---|
別ドメイン | 各ドメインのトップに、それぞれのブランドをOrganizationとして。親会社との関係はparentOrganizationで |
サブドメイン | 各サブドメインのトップにブランドのOrganization。メインドメインのトップに企業のOrganization |
サブディレクトリ | メインドメインのトップに企業のOrganization。各ブランドはBrandとして商品に紐づける |
ブランドと企業の関係を構造化データで明示しておくと、AI検索が「このブランドはこの企業のもの」と理解できます。構造化データは、ページの内容を機械が読める形で書いておく記述です。企業への質問でブランドが、ブランドへの質問で企業が参照されやすくなります。企業トップのOrganizationに、各ブランドを紐づけます。
ストアを追加するときの手順
構成(別ドメイン/サブドメイン/サブディレクトリ)を既存のストアと揃える
Search Consoleのプロパティを追加(ドメインプロパティなら、サブドメイン・サブディレクトリは追加不要)
サイトマップを用意し、登録する
robots.txtを確認する(別ドメイン・サブドメインは独立、サブディレクトリは共通)
共通商品のcanonicalを設定する
Organization・Brandの構造化データを追加する
ストア間の内部リンク(企業トップから各ブランドへ、各ブランドから企業トップへ)を置く
構成を決めたあとの運用
複数ストアの運用では、1つのストアでの変更が他のストアと食い違うことが日常的に起きます。テンプレート更新、商品追加、canonicalの設定などです。ストアが増えるほど、「全ストアで同じ方針が守られているか」を確かめる手間が増えます。
Search OSは、W2などのマルチストア構成のサイトを支える層です。ストア横断で、canonical・構造化データ・サイトマップ・メタデータの整合を継続して確認します。共通商品の重複、Organizationの矛盾、ストアごとのボットの取得状況の差を、修正対象として整理します。構成を決める作業ではありません。決めた構成が全ストアで保たれているかを見続ける層です。
よくある質問
別ドメインからサブディレクトリに統合したい。可能ですか
可能です。ただ、サイト移転と同じ規模の作業になります。旧ドメインの全URLから新URLへのリダイレクト、Search Consoleでのアドレス変更、構造化データの作り直しが要ります。
サブドメインは本当に「ほぼ同一サイト」として扱われますか
Googleは近年、サブドメインとサブディレクトリを大きく区別しないとしています。ただ、はっきり約束された保証ではありません。確実に集約したいなら、サブディレクトリを選んでください。
ブランドごとにSearch Consoleを分けたい
別ドメインなら、自動的に分かれます。サブドメイン・サブディレクトリでも分けられます。URLプレフィックスプロパティを追加すれば、個別に見られます。
あわせて読みたい
参考資料
Google Search Central: Consolidate duplicate URLs
Google Search Central: Organization structured data
Google Search Central: Site moves with URL changes