複数ドメインを1つにまとめるべき？ブランド・SEO・メールの判断順

複数のWebサイト資料とメール関連資料を並べ、ドメイン統合の方針を比較している編集的な机上構成

複数のドメインを一つにまとめるかは、SEO評価を集められそうかだけで決める問題ではありません。先に確認したいのは、各サイトを分けている理由、統合後に名乗るブランド、顧客がたどる相談先、メールの扱い、ドメインやサーバーの管理者であり、統合目的が明確になったときだけURL対応表を作って、転送・テスト・監視を段階的に進めます。

同じ会社が複数サイトを運営していても、すべてを一つへ寄せる必要はありません。同じブランドと顧客導線を重複して持っているなら統合候補ですが、独立したブランド、事業上の責任範囲、利用者層、問い合わせ先を守る必要があるなら、分けたままのほうが説明しやすいでしょう。選択肢は完全統合か現状維持かの二つではなく、企業サイトを共通の入口にしてブランドサイトを残す「共通入口」も含めた三つです。

複数ドメインは「SEO評価を集めるため」だけで統合しない

Googleのサイト移転ガイドは、ドメイン名の変更だけでなく、複数ドメインやホスト名の統合もURL変更を伴う移転として扱っていますが、移転中は再クロールと再インデックスにより検索順位が一時的に変動し得ます。統合した瞬間に検索流入が増えると考えず、重複情報の整理、旧URLと新URLの対応、公開後の監視までを検索面の評価に含めてください。（Google Search Central「Site Moves and Migrations」）

最初の問いは「何個あるか」ではなく、「なぜ分かれているか」。創業時のサイト、後から始めたサービス、期間限定のキャンペーン、買収した事業、地域や言語の違いなど、増えた経緯が異なる以上、理由を確かめず数だけ減らせば、顧客が覚えていた名称や問い合わせ経路を失い、運用負担を別の場所へ移しかねません。

統合の目的を、たとえば「会社の説明を一つにそろえる」「同じ顧客が複数サイトを行き来しなくて済む」「更新担当を一本化する」のように、事業と顧客の変化として書けるでしょうか。「SEOに良さそう」「管理画面を減らしたい」だけでは統合後に何を残すか決まらず、技術的に一つへ移せることと、一つのブランドとして説明できることを混同してしまいます。

最初に決めるのは、統合後に誰が迷わなくなるか

統合案を比べるときは、ブランド、顧客導線、運用、移行負荷の四つを同じ表に置きます。一つの軸だけが強くても、ほかの三つが分離を求めているなら統合を急ぐ理由にはならず、特に中小企業で先にそろえるべきなのは、サイトの見た目ではなく、誰が説明し、誰が問い合わせを受け、誰が更新するかという運用の骨格です。

ブランドを一つの名前と約束で説明できるか

同じ社名の下で似たサービスを案内し、顧客への約束も共通なら、統合によって説明は分かりやすくなります。一方、名称だけでなく価格体系、契約主体、サポート方針、販売方法まで異なるブランドを一つへ押し込めば、ページを移しても内容の境界が曖昧になり、サイト内で境界を引き直さなければなりません。ブランドを残す理由を顧客にも社内にも説明できるなら、独立サイトを維持する根拠は十分です。

顧客が問い合わせ先を選び直さなくてよいか

統合後のサイトでは、初めて訪れた人が自分向けの情報と相談先を迷わず選べるかを確かめます。現在の複数サイトが同じ顧客に同じ内容を見せ、最終的に同じ窓口へ送っているなら入口をまとめる意味がありますが、法人と個人、採用とサービス、国内と海外のように目的と担当が明確に分かれる場合は、ドメインを残して相互の関係だけ整えるほうが自然です。

見るべきは問い合わせ件数だけではなく、どのページを読んだ人が、どのフォームや電話番号を選び、その後どの担当へ渡るかという一連の流れ。窓口を一つにしても受信後の振り分けが変わらなければ表面だけの統合にとどまるため、サイト構造と社内の対応手順を同じ図に置き、減る迷いと新たに増える判断を見分けてください。

更新担当と契約名義を一緒にできるか

各ドメインについて、登録者、管理会社、レジストラのアカウント、DNS、サーバー、CMS、アクセス解析、広告アカウントの管理者を一列に並べ、契約名義、支払い方法、二要素認証の受け手、退職者のアカウントまで確認し、移行時に止まりやすい箇所を可視化します。所有権が不明なドメインでは、移転設計より先の管理権限確保が前提です。

残す・統合する・入口だけまとめるを選び分ける

判断を二択にせず、複数サイトを一つへ移す「統合」、役割の違いを保つ「分離」、共通情報だけを企業サイトへ集めて個別サイトを残す「共通入口」の三つを比べれば、事業上の理由と移行負荷を同じ土俵で見られます。

選択	向いている状態	得られる整理	注意する点
統合	同じブランド・顧客・問い合わせ先で、情報の重複が多い	説明と更新先を一つにできる	URL、メール、外部リンクをまとめて移す必要がある
分離	ブランド、契約主体、利用者、担当組織を分ける理由が明確	各事業の説明と責任範囲を保てる	更新ルールと共通情報の整合を別途管理する
共通入口	会社情報は共通だが、商品・サービスの体験は独立させたい	企業の全体像と個別ブランドの両方を示せる	どの情報を共通側に置くか、リンクの役割を決める

成功条件は、サイト数の少なさではなく、統合後に顧客の選択が簡単になり、説明の重複が減り、担当者が責任を持って更新できること。反対に一つのサイト内で複数ブランドが競合し、問い合わせの行き先が増えるなら、URLが一つでも整理されたとはいえません。

SEOだけでなく、メールと外部掲載を別工程にする

WebサイトのURLとメールアドレスは同じドメインを使うことが多いものの、移行作業は別です。Webページを新しいドメインへ転送しても、メールの受信先、送信元、共有アドレス、メーリングリスト、各種サービスへのログイン名までは自動でそろわないため、サイトの統合方針が決まった段階でWeb、メール、外部掲載を別の担当表に分けてください。

たとえばGoogle Workspaceで主ドメインを変更する手順には、利用者とグループのアドレス変更、請求通知先、ドメインエイリアス、Marketplaceや独自アプリ、利用者への案内などの確認が含まれます。これは特定サービスの例にすぎませんが、メール基盤を変えるときはアドレスだけでなく認証・通知・連携先まで点検し、実際の手順と制約を現在利用しているメール事業者の案内で確かめてください。（Google Workspace Admin Help「Change your primary domain for Google Workspace」）

メールは、新しいアドレスから送れるかだけで判断せず、旧アドレス宛ての受信、新旧双方への返信、問い合わせフォームの通知、自動返信、共有アドレス、スマートフォンやメールソフト、迷惑メール判定、取引先からの返信まで試します。旧アドレスを一定期間エイリアスとして残すのか、送信元にも使うのか、いつ案内を止めるのかを先に決めておけば、公開後の例外対応は減らせるでしょう。

外部掲載には、名刺、会社案内、見積書・請求書、契約書ひな型、求人媒体、広告、SNSプロフィール、地図サービス、業界団体の名簿、取引先のリンク、QRコードなどがあります。全部を公開日に変えられない場合は、顧客への影響が大きい順に更新して旧URLと旧メールの受け皿を残し、Webの公開日とメール切替日を同じ日にするかどうかも、作業しやすさではなく利用者が迷わない順序で決めてください。

統合前の棚卸しは、ページ一覧ではなく対応表にする

統合対象が決まったら作るのは、各サイトのURL一覧ではなく、旧URLごとに新しい行き先と「残す」「内容をまとめる」「役目を終える」という処理を対応させた表です。画像やPDFなど直接参照されるファイルも対象に含め、アクセス数が少なくても、問い合わせ後に案内している資料や取引先から参照されるページは単純に削除できません。

Googleも、旧URLの一覧を作り、新URLへの対応を決めたうえで、内部リンク、canonical、サイトマップを新しいURLへ更新する流れを案内しています。また、多数の旧URLを関連のない新サイトのトップページへ一括転送すると、利用者を混乱させ、soft 404として扱われる可能性があるため、内容に対応する最終URLへ直接つなぐ設計が必要です。（Google Search Central「Site Moves and Migrations」）

対応表には、旧URL、新URL、処理区分、移す内容、ページ担当、問い合わせ先、主な流入元、公開確認者を入れ、さらに転送を止める条件ではなく、公開を止めて戻す条件を一行で書き添えます。フォーム通知が届かない、重要ページが広範囲に404になる、メール受信が止まるといった状態は、様子を見る場面ではなく切り戻しを検討する合図です。

ドメインとサイトの目的、主な読者、問い合わせ先
残す・統合する・削除するページと、対応する新URL
フォーム、計測タグ、広告先、外部リンク、ダウンロード資料
ドメイン、DNS、サーバー、CMS、メールの契約名義と管理者
公開判定、監視担当、切り戻し条件、旧環境を残す期間

統合すると決めたら、URL対応表から段階移行する

段階移行とは、未完成の新旧サイトを長期間混在させることではなく、事業判断、URL対応、事前テスト、公開、監視を分け、工程ごとに完了条件を置くこと。サイトの規模や構造によってURLを一斉に切り替えるか一部から試すかは変わりますが、ドメイン変更、CMS変更、大幅なデザイン変更を同時に重ねると、問題の原因を特定しにくくなります。

Googleは、状況に応じて移転を小さな単位で試すこと、そしてドメイン、CMS、レイアウトなどの大きな変更を一度に重ねず、一つずつ進めることを勧めています。小規模・中規模サイトでは全URLを同時に移す案も示されているため、「段階」は準備と検証の粒度を指し、公開単位はサイトの規模に合わせて選ぶと捉えてください。（Google Search Central「Site Moves and Migrations」）

転送は、旧URLから対応する最終URLへサーバー側の恒久的リダイレクトを設定し、可能なら301または308を使います。旧URLから中間URL、さらに新URLへと転送を重ねず、最終の行き先へ直接つなぐのが原則で、公開前には転送だけでなく、内部リンク、canonical、robots設定、サイトマップ、計測、フォームを同じURL対応表で検査してください。（Google Search Central「Site Moves and Migrations」）

戻し方はいつ決めるべきか。公開前にDNSやサーバー設定の変更前データ、転送設定の版、CMSとデータベースのバックアップ、旧環境の停止日を記録し、誰が復旧判断を出すかまで定めておきます。ただし検索エンジン側の処理を瞬時に元へ戻せるわけではないため、切り戻しは技術設定と顧客対応を安定させる手段として用い、検索順位を元通りにする保証として扱ってはいけません。

公開後は新サイトだけでなく、旧ドメインも監視する

公開直後に見るのは、新サイトの表示だけでなく、旧URLの転送先、エラーが起きるURL、フォームとメールの到達状況。Googleも、旧サイトと新サイトの双方について、Search Console、アクセス解析、サーバーのアクセスログとエラーログを監視するよう案内しているため、検索表示、クロールエラー、主要ページの流入、問い合わせの動作を一つの確認表にまとめ、SEOと業務上の不具合を分けて追ってください。（Google Search Central「Site Moves and Migrations」）

旧ドメインは、転送を設定したからといってすぐ解約できるわけではありません。Googleは転送をできるだけ長く、一般に少なくとも1年間維持するよう案内しており、利用者向けにはさらに長く残すことも検討対象としているため、旧URLを印刷物や取引先が使い続ける期間、旧メールを受ける期間、外部リンクの更新状況を見ながら管理期間を決めます。（Google Search Central「Site Moves and Migrations」）

見落としやすいのが、ドメインの更新担当と支払い方法。ICANNは、ドメインに関連するWebサイトやメールなどのサービスを維持するには有効期限前に更新するよう案内しており、旧ドメインでメールや転送を続けている間に期限が切れれば、サイト移転とは別の障害になります。自動更新、決済情報、管理連絡先を確認し、廃止の承認が出るまでは契約を維持してください。（ICANN「Renewing Domain Names」）

判断を進めるための1枚の整理表

会議を移転方式から始めると技術の話に引っ張られるため、最初に作るのは、現行ドメインの目的、ブランド、主な顧客、問い合わせ、重要ページ、メール利用、契約名義、更新担当を書き出し、各ドメインへ「統合」「残す」「共通入口からつなぐ」「保留」の印を付けた一枚の整理表です。これによって、決めるべき事業条件と確認すべき技術条件を分けられます。

自社で決めること	制作・保守担当へ確認すること
統合後に名乗るブランドと、顧客を案内する入口	旧URLから新URLへの対応表と、転送を実装できる範囲
残すサービス、まとめる情報、廃止する内容	内部リンク、canonical、サイトマップ、計測の更新方法
新旧メールを使う期間と、取引先への案内順	DNS、メール、フォーム通知、外部サービス連携の影響
契約名義、更新費用、公開・停止の承認者	バックアップ、旧環境の保持、監視方法、切り戻し手順

この整理表で「統合すると誰が何をしやすくなるか」を説明できなければ、まだ移行へ進む段階ではありません。逆に、重複している説明と問い合わせ先が明確で、ブランドと運用担当を一本化できるならURL対応表とテスト計画へ進められ、判断を保留する場合も、所有権と更新期限だけは先に整えておけば将来の選択肢を失わずに済むでしょう。