新しいオウンドメディアやサービスサイトを立ち上げるとき、「既存サイトのサブディレクトリに置くか、サブドメインとして分けるか」で迷う企業は少なくありません。SEOへの影響が気になり、決めきれないこともあるでしょう。
結論からいうと、SEOだけを理由にどちらかを選ぶ必要はありません。Googleは、インデックスやランキングの観点ではサブフォルダとサブドメインのどちらかを優先していないと説明しています。判断の軸になるのは、既存サイトとの一体性、CMS、更新権限、計測、ブランドの独立性や検索結果上での見せ方、将来の移行しやすさといった運用面の条件です。
この記事では、まず両者の違いを整理し、そのうえで運用面の判断軸、ケース別の選び方、迷ったときのチェックリストを順に紹介します。読み終えるころには、自社の新しいサイト領域をどちらに置くかを、条件を挙げて説明できるようになります。
サブディレクトリとサブドメインはURLのどこが違うのか
サブディレクトリとサブドメインは、どちらも既存ドメインを活用してWebコンテンツを公開する方法ですが、URL上の位置づけが異なります。この節では、その構造上の違いを押さえます。
たとえば、基準となるドメインが「example.com」の場合、次の表のように表せます。
| 方式 | URL例 | 基本的な考え方 |
|---|---|---|
| サブディレクトリ | example.com/media/ | 既存サイトの配下に新しい領域を追加する |
| サブドメイン | media.example.com | 既存ドメインを使いながら別のホストとして領域を分ける |

図のとおり、サブディレクトリは既存サイトの配下に追加する構成で、サブドメインは同じドメイン系列の別ホストとして分ける構成です。
サブディレクトリは、既存サイトの中に「media」などの階層を作る方式です。企業サイトの一部としてオウンドメディアやサービス情報を増やしたい場合に使いやすい構成です。
一方、サブドメインは「media.example.com」のように、ドメイン名の前に文字列を追加します。DNSやサーバー、CMSなどを本体サイトと分けて設計しやすく、独立性を持たせたい場合に向いています。
ただし、「サブディレクトリなら必ず同じCMS」「サブドメインなら必ず別CMS」という意味ではありません。実際のシステム構成によっては、サブディレクトリ配下に別システムを組み込むこともできます。
SEOではサブディレクトリとサブドメインのどちらかが有利になるのか
先に、SEOの面から確認します。Googleは、サブフォルダとサブドメインについて、インデックスやランキングの観点ではどちらかを優先していないと案内しています。Google Search CentralのSEO Starter Guideでも、事業上管理しやすい方法を選ぶよう説明されています。
そのため、「サブディレクトリならSEO評価を必ず引き継げる」「サブドメインにするとSEO評価が必ず分散する」といった単純なルールだけで決めるのは適切ではありません。
見るべきなのは、URL形式そのものではなく、公開するコンテンツの品質、内部リンク、クロールしやすい構造、検索意図との一致、サイト全体の運用状態などです。
一方で、Google検索上でもサブドメインとサブディレクトリが完全に同じ単位で扱われるわけではありません。たとえばGoogleのサイト名はドメインまたはサブドメイン単位で設定できますが、サブディレクトリ単位ではサポートされていません。ファビコンについても、Googleはホスト名単位でサイトを扱っています。
つまり、ランキング上の単純な優劣ではなく、「検索結果上でどこまで独立したサイトとして見せたいか」という設計判断には違いがあります。この判断を運用面の条件とあわせて決めるために、次の節から判断の手順を見ていきます。
まず既存サイトと一体運用するか、独立運用するかを決める
サブディレクトリとサブドメインを選ぶ際に最初に確認したいのは、新しい領域を既存サイトの一部として運用するのか、それとも独立性を持たせるのかです。
次の表は、判断項目ごとに、どちらの方式を検討しやすいかをまとめたものです。
| 判断項目 | サブディレクトリを検討しやすい | サブドメインを検討しやすい |
|---|---|---|
| 事業・テーマ | 既存事業と近い | 既存事業と距離がある |
| ブランド | 同じ企業・ブランドとして見せたい | 独自ブランドとして見せたい |
| CMS | 既存CMSで運用できる | 別CMS・別システムが必要 |
| 更新担当 | 同じ部署・同じ運用体制 | 別部署・別会社が担当 |
| 権限 | 同じ管理画面で問題ない | 管理範囲を明確に分けたい |
| 計測 | 一体で分析したい | 別単位で管理・評価したい |
| 将来 | 本体サイトの一部として継続 | 将来の独立・切り離しを想定 |

最初の分岐はSEOではなく、既存サイトと一体で運用するか、CMSや管理体制まで分けるかです。
既存サービスと同じブランド、同じ顧客、同じ運用チームで管理するオウンドメディアなら、サブディレクトリは自然な候補です。
反対に、新規事業や別ブランドのサイトで、CMSや管理者まで分けたい場合は、サブドメインのほうが設計しやすいことがあります。それぞれの場合に何が決め手になるかを、次の2つの節で順に確認します。
サブディレクトリが向くのは既存サイトとの一体性を重視する場合
サブディレクトリは、新しい領域を既存サイトの延長として扱いたい場合に向いています。この節では、向いている場面を確認します。
同じ事業やブランドの情報を増やす場合
コーポレートサイト内に「お役立ち情報」「導入事例」「採用コンテンツ」などを追加する場合は、既存サイトとの関係が明確です。
ユーザーから見ても同じ企業の情報として理解しやすく、グローバルナビゲーションやパンくずリスト、内部リンクなども一体で設計しやすくなります。
検索流入だけでなく、記事からサービスページ、事例、問い合わせへ移動してもらう導線も同一サイト内で作りやすい点が利点です。
同じCMSと運用チームで管理できる場合
既存サイトと同じCMSを使い、同じWeb担当者が更新するのであれば、サブディレクトリは管理を一本化しやすい方式です。
アカウント管理、テンプレート更新、プラグイン管理、セキュリティ対応などを共通化できれば、運用負荷を抑えやすくなります。
ただし、現在のCMSやサーバー構成によっては、サブディレクトリだけ別のシステムを導入するためにリバースプロキシなどの技術対応が必要になることがあります。「URL上はサブディレクトリにしたい」という要望だけで決めず、実装できるかどうかを事前に確認してください。
ユーザー行動を一体で見たい場合
記事を読んだ人がそのままサービスページや問い合わせページへ移動するサイトでは、一連の行動を同じサイトとして設計しやすいこともサブディレクトリの利点です。
ただし、計測のしやすさはURL形式だけで決まるわけではありません。Google Analytics 4のプロパティやデータストリーム、タグの設計が不適切であれば、同じドメイン内でも分析しにくくなります。
URL構造と計測設計は、分けて確認しましょう。
サブドメインが向くのは運用・システム・ブランドを分けたい場合
サブドメインは、既存ドメインとの関係を保ちながら、新しいサイト領域に独立性を持たせたい場合に向いています。この節では、向いている場面を確認します。
CMSやシステムを分離したい場合
本体サイトと新しい領域で必要な機能が大きく異なる場合、別CMSや別システムを使うほうが合理的なことがあります。
たとえば、コーポレートサイトは一般的なCMSで管理し、会員サイト、採用システム、ヘルプセンター、ECなどは別のシステムで運用するケースです。
サブドメインならDNSやサーバーを分けやすいため、システムの独立性を確保しやすくなります。
管理者や権限を明確に分けたい場合
本体サイトは広報部、新しいメディアはマーケティング部、採用サイトは人事部というように、担当部署が異なる場合は権限の設計が欠かせません。
同じCMS内で細かく権限管理できる場合もありますが、運用責任を完全に分けたいなら、サブドメインとして管理環境そのものを分離する選択肢があります。
制作会社や外部パートナーへ管理を委託する場合も、どこまで権限を渡すかを整理したうえで判断します。
検索結果上でも独立したブランドとして見せたい場合
SEOの節で触れたとおり、Google検索のサイト名はドメインまたはサブドメイン単位でサポートされており、サブディレクトリ単位では独立したサイト名を設定できません。
そのため、既存サイトとは異なるメディア名やサービス名を育て、検索結果上でも独立したサイトとして認識してもらいたい場合は、サブドメインが候補になります。
ただし、サブドメインにすれば自動的にブランドが確立するわけではありません。サイト名、コンテンツ、ナビゲーション、外部からの認知などを一貫して設計する必要があります。
CMS・権限・計測・ブランド・移行の5軸で比較する
ここまでの内容を実際のサイト設計に使うには、SEOだけでなく5つの軸で比較すると判断しやすくなります。前の表が「最初の分岐」だったのに対し、この節では、各軸を自社の条件に当てはめて確認する方法を示します。

図のように、構成判断ではSEOだけでなくCMS、権限、計測、ブランド、将来の移行まで同時に確認します。以下では、この順に見ていきます。
1.CMSを共通化できるか
最初に確認したいのは、現在のCMSで新しい領域を問題なく運用できるかです。
既存CMSで必要なページ、権限、承認フロー、テンプレートを実現できるなら、サブディレクトリでまとめるメリットがあります。
一方、既存CMSでは要件を満たせない場合や、SaaS型の別システムを使う必要がある場合は、サブドメインのほうが実装しやすい可能性があります。
2.運用権限をどこまで分けるか
次に、新しい領域の更新担当、承認者、システム管理者を確認します。
同じ担当者が一体運用するならサブディレクトリでも問題になりにくい一方、別部署や別会社が管理する場合は、権限の分離がしやすい構成を選ぶ必要があります。
確認したいのは「誰が記事を書くか」だけではありません。「誰がユーザーを追加できるか」「誰がテンプレートやタグを変更できるか」まで含めて整理します。
3.計測(アクセス解析)をどう管理するか
新しい領域を立ち上げる前に、何を同じ指標で評価し、何を分けて評価するかを決めます。
Google Analytics 4では、関連するWeb上のユーザー行動を一つのデータストリームで測定する考え方があります。複数ドメインをまたぐ場合にはクロスドメイン測定が用意されており、サブドメイン間でもタグやCookieの設定次第で自己参照などの問題が起こる可能性があります。
したがって、「サブドメインだから計測できない」「サブディレクトリだから設定不要」と決めつけず、実際のタグ、Cookie、プロパティの設計を確認してください。
4.ブランドを同じ単位で見せるか
同じ企業・同じサービスの一部として認識してほしいなら、サブディレクトリが自然です。
一方、メディア名やサービス名を独立して育てる場合は、サブドメインを含めた独立構成を検討できます。
ここで気をつけたいのは、社内の組織都合だけで決めないことです。ユーザーから見て「同じサイトの一部なのか」「別のサービスなのか」が自然に理解できる構成になっているかを確認します。
5.将来の移行や切り離しを想定するか
サイト構造は公開後に変更できますが、URL変更にはリダイレクト、内部リンク、サイトマップ、計測、外部リンクなどの調整が伴います。
そのため、数年以内に事業売却、ブランド分離、システム刷新などが想定される場合は、将来の切り離しやすさも判断材料になります。
ただし、将来変更する可能性があるからといって、現在の要件を無視してサブドメインを選ぶ必要はありません。移行の可能性と現在の運用効率を比較し、総合的に決めます。
ケース別に見るサブディレクトリとサブドメインの選び方
5つの軸を、代表的なケースに当てはめると、判断基準を実務へ落とし込みやすくなります。次の表は、ケースごとの第一候補と、その判断理由をまとめたものです。
| ケース | 第一候補 | 判断理由 |
|---|---|---|
| 既存サービスのオウンドメディア | サブディレクトリ | 同じブランド・同じ顧客・同じ導線で運用しやすい |
| コーポレートサイト内のお役立ち情報 | サブディレクトリ | 既存サイトの情報拡充として自然 |
| 独立ブランドの新規メディア | サブドメインも検討 | 独立したサイト名や運用環境を持たせやすい |
| 本体と異なるCMSを使う採用サイト | 要件次第でサブドメイン | システム分離と権限分離が必要になりやすい |
| ヘルプセンター・会員システム | サブドメインも検討 | SaaSや専用システムを使うケースが多い |
| 同一事業のサービスページ追加 | サブディレクトリ | 既存サイト内の情報として統合しやすい |
ただし、この表は絶対的なルールではありません。たとえば、別CMSを使っていてもリバースプロキシなどを利用してサブディレクトリで公開できる場合があります。反対に、同じCMSを使えてもブランドや運用責任を分けるためにサブドメインを選ぶこともあります。
ケース名だけで決めず、自社の実際の制約まで確認してください。
迷ったときは7項目のチェックリストで判断する
ここまでの内容を踏まえ、最終判断では次の7項目を確認してください。
- 新しい領域は既存サイトと同じ事業・ブランドか
- 同じCMSで必要な機能を実現できるか
- 更新担当者・承認者・管理者を共通化できるか
- アクセス解析や成果指標を同じ単位で見たいか
- 検索結果上でも同じサイトとして見せたいか
- 将来、別サービスとして切り離す可能性が高いか
- 構成変更による将来の移行コストを許容できるか
読み方は次のとおりです。最初の5項目で、既存サイトと「同じ」にできると答えられるものが多い場合は、サブディレクトリを検討しやすくなります。一方、CMS、管理者、ブランドで「分けたい」が多い場合は、サブドメインを検討する余地が大きくなります。
6項目目で切り離しの可能性が高い場合も、サブドメインを検討する材料になります。7項目目は、将来の移行コストをどこまで許容できるかを確認するための項目です。SEOの印象論で決めるのではなく、現在と将来の運用条件を文章で説明できる状態にしてから決定しましょう。
すでに公開しているサイトの構成を変えるときは何を確認するか
すでに公開中のサイトをサブディレクトリからサブドメインへ、またはその逆へ変更する場合は、新規立ち上げより慎重な対応が必要です。
URLが変わる場合、検索エンジンとユーザーの双方が新しいページへ到達できるよう、旧URLと新URLの対応を整理する必要があります。
また、確認対象はリダイレクトだけではありません。

構成を変更する場合は、旧URLと新URLの対応だけでなく、内部リンク、計測、CMS、フォームなど周辺の仕組みも確認が必要です。具体的には、次の項目を洗い出します。
- 内部リンク
- canonical
- XMLサイトマップ
- Google Search Console
- Google Analytics 4
- 広告・計測タグ
- CMS
- フォーム
- Cookie
- 外部サービス連携
- 外部から参照されているURL
これらを事前に洗い出しておくと、移行後の計測漏れや導線切れを減らせます。
具体的な301リダイレクトやサイト移行の手順は、サブディレクトリとサブドメインの「選択判断」とは別の実務です。構成を変更すると決めた後は、サイト移行の専用手順に沿って進めてください。
サイト構造の変更を、クロール・正規化・サイトマップなど他の技術要件とあわせて確認したい場合は、テクニカルSEOの全体像も確認してください。
まとめ
サブディレクトリとサブドメインは、SEO評価だけで決めるものではありません。Googleは、インデックスやランキングの観点でどちらかを一律に優先していないと説明しています。
既存サイトと同じ事業・ブランド・CMS・運用チームで一体管理するなら、サブディレクトリが候補になります。反対に、CMS、権限、ブランド、運用責任を分けたい場合や、将来の独立性を持たせたい場合はサブドメインを検討できます。
公開後にURL構成を変えるより、立ち上げ前に判断基準を揃えておくほうが、運用や移行の手戻りを抑えやすくなります。最初の一歩として、7項目のチェックリストに自社の条件を一つずつ当てはめてください。SEOだけでなく、CMS、権限、計測、ブランド、将来の移行まで確認してから決定します。
サイト構造を設計するときは、URLだけでなく、クロール、内部リンク、計測、運用までまとめて確認することが重要です。実務で確認すべき項目を整理した資料も活用しながら、自社の条件を確認してください。
参考文献・データ元
この記事で参照した情報を確認できます。
-
SEO Starter Guide: The Basics
発表元:Google Search Central
URL:https://developers.google.com/search/docs/fundamentals/seo-starter-guide
使用内容:サブドメインとサブディレクトリは、事業上管理しやすい方法を選ぶというGoogleの基本見解。 -
FAQ: Google Search Crawling And Indexing
発表元:Google Search Central
URL:https://developers.google.com/search/help/crawling-index-faq
使用内容:インデックスとランキングの観点では、サブフォルダとサブドメインのどちらかをGoogleが優先しているわけではないという説明。 -
Site Names in Google Search
発表元:Google Search Central
URL:https://developers.google.com/search/docs/appearance/site-names
使用内容:Google検索のサイト名はドメイン・サブドメイン単位でサポートされ、サブディレクトリ単位ではサポートされない点。 -
Define Website Favicon for Search Results
発表元:Google Search Central
URL:https://developers.google.com/search/docs/appearance/favicon-in-search
使用内容:Google検索におけるサイトの単位がホスト名で扱われる例。 -
Set up cross-domain measurement
発表元:Google Analytics Help
URL:https://support.google.com/analytics/answer/10071811
使用内容:複数ドメイン・サブドメインをまたぐ計測時の設定、Cookie、自己参照に関する注意。
‹ 親記事: テクニカルSEOとは?クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト
関連記事
- › INDEX削除(インデックス削除)とは?検索結果から消える仕組みと対処法
- › Core Web Vitals改善ガイド|LCP・INP・CLSの原因特定と優先順位付け
- › SEO内部リンクの確認方法|孤立ページ・深度・アンカー偏りを改善
- › ページがインデックスされない原因は?Search Consoleで未登録・除外・重複URLを確認
- › JavaScript SEOの確認方法|表示・内部リンク・登録状況
- › クロールバジェットの確認方法|無駄なクロールと改善優先度
- › 構造化データの確認方法|エラー・本文との不一致・重複を検証
- › 多言語ページの言語・地域指定を確認|相互参照・正規URLをチェック
- › 絞り込み検索のSEO確認方法|URL増加・クロール・重複を防ぐ
- › SEOリダイレクトの確認方法|多段転送・ループ・誤転送を検出
- › robots設定のSEO確認方法|クロール許可と登録制御の矛盾を確認
- › ページネーションのSEO確認方法|正規URL・内部リンク・クロール
- › サイト移行後のSEO確認方法|転送・正規URL・順位変動を確認
- › 404・soft 404のSEO確認|リンク切れ・消失URLを修正
- › SEOリリース前チェックの作り方|noindex・canonical・robots・リダイレクトの事故を防ぐ
- › 画像SEOの確認方法|alt・画像URL・遅延読み込みを確認
- › 求人ページの構造化データを確認|給与・勤務地・期限の不一致
- › サイト内検索ページのSEO確認|noindex・クロール・重複URL
- › サイトリニューアルでSEO評価を落とさない移行方法|URL・301・計測・公開手順
- › サービス終了ページは削除すべき?301・404/410・残す場合のSEO判断基準
- › SEOに強いURL・ディレクトリ設計|階層・命名・変更時の注意点
- › リッチリザルトとは?種類・構造化データ・表示確認方法を解説
- › Google Search Consoleとは?登録方法と最初に見る4つの指標




