新しいサービスの担当部門が「専用サイトを作りたい」と言い、デザイン案やドメイン候補から検討が始まることがあります。しかし既存サイトには同じ相手に向けた案内や問い合わせフォームがあり、分けることで訪問者が会社との関係を探し直す場合があります。反対に、対象者も申し込み方も違うサービスを一つの一覧へ押し込むと、説明が長くなり選べません。サイトの数を先に決めず、誰が何を判断し、誰が公開後に更新するかを比べる必要があります。
この記事は、複数サービスを扱う事業責任者とWeb担当者向けです。既存サイト内のサービスページ、同じ事業者が運営する別のまとまり、独立したドメインの三案を、読者・ブランド・機能・管理体制で比較します。ここでいう「サブサイト」は独立したナビゲーションや更新体制を持つサービスのまとまりであり、URLがサブドメインになる場合と既存ドメイン内の区画になる場合があります。技術的な設置場所と、利用者にとって独立した案内かどうかは分けて判断します。
みやあじよのサービス整理のホームページ制作は、サービスの違い、選ぶ条件、相談先を整理する支援を案内しています。この記事はそこから一歩進めて、一つのサイト内に置くか、専用のまとまりを作るか、ドメインまで分けるかを決める比較表を示します。既存のサービス一覧、問い合わせ先、更新担当、利用中の機能を持ち寄って読める構成です。
分ける理由を四つに整理する
最初に「見た目を変えたい」「検索に強くしたい」「部門ごとに管理したい」といった要望を、そのまま設置方法へ結び付けないようにします。見た目は同一サイト内の専用ページでも変えられます。検索で見つけてもらうには、ドメインやURLの違いよりも、そのサービスを探す人の疑問に答える内容と導線が必要です。部門ごとの編集権限は、既存の管理画面でも設定できるかもしれません。要望を、読者、ブランド、機能、管理体制のどれに関わるか整理します。
読者については、既存サービスと同じ人が同じ場面で比較するかを確かめます。一人の担当者が二つのサービスを組み合わせて相談するなら、別サイトを行き来する負担があります。対象者がまったく異なり、説明する言葉や判断材料が共通しないなら、専用の入口に意味があります。ブランドについては、運営会社名を前面に出すか、サービス名自体が選ばれる理由になるか、問い合わせ時に会社との関係をどう示すかを考えます。
機能には、見積相談、予約、会員ログイン、決済、資料請求などがあります。表示だけを分けたいのか、データや運用上の権限まで分けたいのかで必要な構成は変わります。管理体制では、原稿の承認者、問い合わせの受け手、セキュリティ更新、障害時の連絡先、費用を負担する部門を確認します。専用サイトを作るなら、公開後もこれらを別々に維持する必要があります。専用の編集者がいない状態でサイトだけ増やすと、料金や担当者の説明がサイト間で食い違いやすくなります。
既存のサブドメインとサブディレクトリの解説はURLの形と基本的な違いを紹介しています。ここでの判断材料はURLの名称そのものではなく、誰がサービスを選び、運営会社との関係を理解し、最後にどの窓口へ進むかです。「サブドメインにすれば必ず検索で有利」「同一ドメインなら必ず評価を共有できる」といった一律の期待を設計理由にはしません。
三つの設置先を同じ条件で比べる

以下は編集用の比較表です。実際のCMSや契約、情報管理の条件は事業者ごとに異なります。設置先の名称だけで決めず、自社のサービス資料と現行サイトを見ながら各行を埋めます。空欄が多い案は、費用見積りや制作範囲も確定できません。
表は左右にスクロールして確認できます。
| 比較する条件 | 同一サイト内のページ | 専用のサブサイト | 独立したドメイン |
|---|---|---|---|
| 読者の関係 | 既存サービスと同じ人が比較・併用する | 同じ会社の別領域を独立して探す | 対象者や購入行動が大きく異なる |
| ブランドの見せ方 | 会社名と共通の信頼情報を使う | 専用名を出しつつ運営会社へ戻れる | ブランド自体の説明と運営主体を用意する |
| 受付と機能 | 共通の相談窓口や管理画面で扱える | 専用導線や一部の権限を分けたい | 契約、会員、決済等を独立運用する必要がある |
| 更新責任 | 共通の承認・保守体制で更新する | 部門担当と共通管理者の分担を決める | 別の保守、権限、障害対応を持てる |
| 移行の量 | 既存URLを生かせるか確認 | 既存ページの移設範囲を確認 | URL、リンク、計測、資料の移行を確認 |
表は「独立ドメインが最上位」という順位表ではありません。同一サイト内のページでも、適切な見出し、事例、料金、FAQ、相談の入口を持てます。サブサイトという呼び方も、サブドメインを必須にするものではありません。特に外部システムを使う場合、利用者からは一つのサービスに見えても、予約や決済だけ別のホストへ移ることがあります。その移動時に運営主体と手続の状態が分かるかを、設置先と別に確認します。
比較表の各行には、現在の画面や運用資料を根拠として添えます。「対象者が違う」という意見なら、実際に使う言葉、必要な資料、相談時の質問がどこで違うかを並べます。「管理を分けたい」なら、承認者と更新権限の違いを書きます。意見だけで、現在の画面や運用資料では確かめられない行は、代表ページを一つ作って確かめる課題として残します。
一案を選ぶときは、四条件のうち何が決め手だったかを短い文にします。たとえば「既存顧客が二つのサービスを続けて比較するため、同じナビゲーションと相談窓口を維持する」「編集権限と会員機能が独立しており、サービス名でも指名されるため別サイトを運営する」といった理由です。社内の好みだけではなく、利用者の進み方と公開後の担当を同時に説明できる案を選びます。
同じサイトで一覧と詳細を結ぶ
既存サイト内に置く判断をした場合も、サービス一覧に項目を追加するだけでは足りません。初めての人が探す仕事や困りごとから一覧へ入り、二つのサービスの違いを比較し、詳細で対象・範囲・料金の考え方を確かめられるようにします。会社紹介にすべての情報を詰め込まず、共通の信頼情報は会社ページに、選ぶための短い違いは一覧に、契約前の条件は詳細に分けて載せます。サービス名だけでは分からないものは、「誰のどんな依頼に応えるか」を一行で添えます。
同じ顧客が関連サービスを併用するなら、詳細ページ間の移動にも理由を示します。「こちらもおすすめ」ではなく、「導入後の保守はこちら」「既製品で対応できない仕様の相談はこちら」のように、次の判断が分かるリンクにします。相談フォームは各ページから来た目的を引き継ぎ、どのサービスについての相談か再入力させない設計にします。一つの窓口で受けるとしても、受信後に部門へどう振り分けるかを決めておきます。
サービスごとにデザインの色や写真を変えることは可能です。ただしヘッダー、会社名、問い合わせ先、プライバシーの案内まで別物にすると、同じ会社の提供だと気付きにくくなります。共通にする要素と変える要素を見本画面で確認します。部門別のキャンペーンを作る場合も、期間が終わったらどのページを更新するかを決め、古い案内がサービス詳細へ残らないようにします。まず代表的な二つのサービスで一覧から相談までの経路を実際にたどり、サイトの構成を分ける必要があるのか、説明を補えばよいのかを確かめます。
専用サイトの運営分担を決める

サブサイトや独立ドメインの案では、サービスのトップページを新設するだけでなく、運営会社、提供範囲、問い合わせ、利用条件、更新履歴、障害時の連絡先をどこに置くか決めます。親サイトから移るリンクにサービス名と移動先を示し、戻る経路も用意します。訪問者が別のドメインに移ったとき、同じ会社なのか、提携先なのかを自分で調べ直す構成は避けます。ロゴや色を変える場合ほど、その関係を明示します。
管理面では、ドメイン契約者、サーバーやCMSの権限、フォームの受信先、解析の閲覧権限、バックアップと更新の担当を表にします。別サイトには独立した運用費と確認の手間が生じます。二つのサイトで同じ料金表やFAQを載せるなら、原本はどちらか、変更を誰が両方に反映するかを決めます。単純な複製を増やすと、古い情報が残り、相談先で説明の差が生じます。サービス専用サイトを運営するには、画面を分ける理由と、公開後も管理を続けられる体制の両方が必要です。
分けた後の計測も、二つのサイトの総アクセス数を足すだけでは判断できません。親サイトから専用サイトへ進んだ人がサービス内容を理解できたか、相談フォームへ着いたか、逆に会社情報へ戻ったかを見ます。部門が違う場合は、どの窓口が問い合わせを受け、どの段階で引き継ぐかを決めます。各サイトが同じ電話番号を示していても、受付がサービス名を聞き直す運用なら、どのサイト・ページから相談に来たかを、受付へ伝えられるか考えます。公開前には、親サイトのサービス一覧から専用サイトの詳細、相談完了まで利用者と同じ順序で操作し、案内の途切れを確認します。
Google検索セントラルのSEOスターターガイドは、サブドメインとサブディレクトリについて、事業に合う管理の仕方で選ぶ考え方を示しています。検索のためだけにドメインを増やす判断はせず、内容、案内、運用上の必要を先に確認します。Googleのサイト名に関する技術文書では、検索結果のサイト名の扱いがドメイン・サブドメイン単位で、サブディレクトリは独自のサイト名設定の対象ではないと説明されています。ブランド名を検索上も別に見せたい場合は、この表示上の違いを設計者と確認します。ただし希望した表示名が必ず採用されるわけではありません。
移行するURLと資料を洗い出す
既存ページを別の場所へ移す場合は、見た目の制作とURLの移行を別の作業として見積もります。サービス一覧、詳細、事例、記事、PDF、画像、フォームの完了画面など、対象URLを集め、「残す・移す・統合する・廃止する」を決めます。旧ページと新ページの対応表を作り、内部リンク、正規URL、サイトマップ、計測、広告のリンク先も確認します。印刷物やメール署名に載るURLの変更も、担当者が把握する必要があります。既存のアクセスや問い合わせの経路を見ずに、すべてを新サイトのトップページへ転送する設計は避けます。
移行表には、旧URL、新URL、移す内容、転送の有無、ページ責任者、公開後の確認結果を一行ずつ置きます。旧ページにしか載っていない資料や、ほかのサービスへつながる説明を新サイトでどう扱うかも決めます。旧URLを廃止する場合は、単に削除するのか、関連する案内を残すのか、利用者にとって代替先があるかを確認します。問い合わせの完了画面やダウンロード用資料は一覧に漏れやすいため、公開されたページだけでなく、実際の相談経路をたどって収集します。移行後の点検担当と期間も制作依頼の範囲に含めます。
Googleのサイト移転ガイドは、URLを変更する場合に旧URLと新URLの対応、恒久的な転送、公開後の監視を案内しています。ドメインやサブドメインを変える場合の手続と、同じドメイン内でパスだけを変える場合の手続には違いもあります。順位や流入が変わらない保証はなく、移行後に検索エンジンが新URLを認識する時間も必要です。制作範囲には、公開時の転送設定だけでなく、対応漏れやリンク切れの確認まで入れます。
参考資料
- Google検索セントラル「SEOスターターガイド」(サブドメインとサブディレクトリの選択を確認)
- Google検索セントラル「検索結果のサイト名」(ドメイン・サブドメインとサブディレクトリの表示上の違いを確認)
- Google検索セントラル「サイトを移転する」(URL変更時の対応表、転送、監視を確認)


