サブディレクトリとサブドメインの違いと選び方の判断ポイント

これから自社メディアを立ち上げるなら、まず example.com/media/ のようなサブディレクトリを第一候補にしてください。サブドメイン（media.example.com）を選ぶ理由は、運用する会社・使うシステム・見せたいブランドのどれかが本体サイトと別になるときに限られます。

「サブドメインはSEOで不利」という話をよく見かけますが、Googleがそう公式に言っている事実はありません。判断すべきなのは順位ではなく、計測・保守・証明書・ブランドという運用コストの側です。この記事は、オウンドメディアやブログの置き場所をこれから決める広報・マーケ担当の方に向けて、その決め方を手順で解説します。

なお、すでに公開しているサイトを引っ越す話（301リダイレクトや評価の引き継ぎ）はここでは扱いません。既存サイトの移転はサイトリニューアルのSEO引き継ぎ手順で、wwwありなしやhttpsの統一はURL正規化の統一手順で解説しています。

この記事は「まだ何も置いていない状態から、どちらを選ぶか」に絞ります。

Contents / 目次

1. 迷ったらサブディレクトリ。サブドメインにする条件は3つだけ
2. サブドメインのSEO評価はどこまで言えるのか。公式で確認できる事実だけ整理する
3. 置き場所を決める5ステップ。判定シートと公開前チェックまで
4. オウンドメディアをサブドメインにするかどうか。ケース別の答え
5. この判断で何が変わるか。やり直しにかかる時間と手間
6. よくある失敗4つ。サブドメインを立てたときに起きること
7. 現場で見えた妥協点。理屈どおりに決められない場面
8. よくある質問
9. 今日の最初の一歩

迷ったらサブディレクトリ。サブドメインにする条件は3つだけ

結論から書きます。自社メディアの置き場所は、次の3つのうちどれか1つでも当てはまるならサブドメイン、1つも当てはまらないならサブディレクトリです。

• 運用主体が別：本体サイトと別の部署・別の制作会社が更新する。CMSの管理画面を分けないと権限がぶつかる
• システムが別：本体はWordPress、メディアは別のCMSやSaaS、といったように動かす仕組みが違う。同じサーバーに同居させられない
• ブランドが別：本体事業とは違う名前・違う客層で立ち上げる。将来、独立した会社やサービスとして切り出す可能性がある

逆に言えば、「自社の事業について自社の担当者が書く記事メディア」は、ほぼ全部サブディレクトリで問題ありません。弊社が中小企業のオウンドメディアを見てきた限りでも、この形に当てはまるケースがほとんどです。

ポイント。決め手は検索順位ではなく運用です。順位で選ぼうとすると根拠のない話に振り回されますが、「誰が更新するか」「どのシステムで動かすか」は社内で確認できる事実なので、判断が最後までぶれません。

両者の違いを、実務で差が出るところだけ並べます。Search Consoleの行はこのあとの章で挙げるSearch Console ヘルプのプロパティ追加ページ、robots.txtの行はGoogle公式のrobots.txtドキュメントが根拠です。

比べる項目	サブディレクトリ（example.com/media/）	サブドメイン（media.example.com）
URLの形	本体ドメインの下の階層	本体ドメインの前に名前を足した別ホスト
DNSの設定	不要（既存のホストのまま）	必要（Aレコードなどを1件追加）
SSL証明書	本体の証明書がそのまま使える	ワイルドカード証明書（*.example.com）を使っていれば追加発行は不要。ホストごとに発行する形式なら、新しいホスト名分の発行・更新が必要
robots.txt	本体と共通（1ファイル）	そのホスト専用に別途1ファイル必要
Search Console	本体プロパティで一緒に見られる	プロパティの種類によって対象範囲が変わるため、ヘルプで確認して登録する
GA4	そのまま同一サイトとして計測	別ホストになるため、計測タグの設定をヘルプで確認して揃える
CMS・サーバー	同居が前提（分けるならリバースプロキシが要る）	別サーバー・別CMSにしやすい
内部リンク	本体とメディアを普通に行き来できる	行き来はできるが、設計しないと分断されやすい
向いているケース	本体事業と地続きの記事メディア、事例集、コラム	採用サイト、ヘルプセンター、別ブランド、別ベンダー運用

この章の結論として、「本体と地続きの内容を、自社の同じ担当者が更新する」ならサブディレクトリで決めてしまって構いません。3条件のどれかに当たった人だけ、次の章から先を読み込んでください。

サブドメインのSEO評価はどこまで言えるのか。公式で確認できる事実だけ整理する

「サブドメインだと評価が分散する」「サブディレクトリの方がドメインの力を引き継げる」という説明は、Googleの公式ドキュメントには書かれていません。断定している解説記事は多いのですが、一次情報にあたると根拠が見つからないというのが実際のところです。

一方で、Googleが公式にはっきり書いていることもあります。それは「順位が有利か不利か」ではなく、サブドメインは技術的に別のホストとして扱われる場面があるという事実です。この違いが、そのまま作業の増減になります。

robots.txtはホスト単位。サブドメインには専用のファイルが要る

robots.txtとは、検索エンジンのクローラー（サイトを巡回するプログラム）に「ここは見に来ていい・来ないで」と伝えるテキストファイルのことです。これはホストごとに1つ必要です。

Google公式のrobots.txt ファイルの書き方と送信方法には、robots.txt に書いたルールは、そのファイルが置かれているホスト・プロトコル・ポート番号にだけ適用される、と説明されています。

つまり example.com/robots.txt を整えても、media.example.com には一切効きません。サブドメインを立てたら、そのホストのルート直下にもう1つ robots.txt を用意します。ここを見落とすと、テスト環境の設定が残ったままメディア全体がクロール拒否になっている、という事故が起きます。

Search Consoleは、プロパティの種類で見え方が変わる

Search Consoleには2種類のプロパティ（計測の単位）があります。ドメインプロパティとURLプレフィックスプロパティで、それぞれ何が集計対象になるかが違います。Search Console ヘルプのプロパティ追加ページで、登録方法と対象範囲を確認してください。

ここが実務で効いてきます。URLプレフィックスで https://example.com/ だけを登録している会社がサブドメインを立てると、そのメディアの検索データはどこにも出てきません。数字が「ゼロ」ではなく「存在しない」状態になるので、気づくのが遅れます。Search Console自体の見方はサーチコンソールの使い方で解説しています。

サブドメイン間の引っ越しは「別の場所への移転」として扱われる

Google公式のURL変更を伴うサイト移転のドキュメントでは、301リダイレクトは可能な限り長く、一般的には最低1年は維持することが案内されています。

後から media.example.com を example.com/media/ に変えるのは、この「移転」に該当します。設定を1行変えて終わり、という話ではありません。

この章の結論はこうです。サブドメインを選ぶこと自体にSEOのペナルティはありませんが、robots.txt・Search Console・移転コストという3つの手間は確実に増えます。「順位が下がるらしいから」ではなく「この手間を払う理由があるか」で判断してください。

置き場所を決める5ステップ。判定シートと公開前チェックまで

ここからは実際の決め方です。上から順にやれば、その日のうちに結論を出せます。

ステップ1. 判定シートの6問に答える

まず、次の6問に「はい・いいえ」で答えてください。紙でもスプレッドシートでも構いません。

#	質問	「はい」なら
1	記事の内容は、本体サイトで売っている商品・サービスの周辺の話ですか	サブディレクトリ +1
2	更新するのは、本体サイトも触っている社内の人ですか	サブディレクトリ +1
3	本体サイトと同じCMS・同じサーバーで動かせますか	サブディレクトリ +1
4	メディア専用の名前やロゴを新しく作りますか	サブドメイン +1
5	本体サイトとは別の制作会社・別の事業部が運用しますか	サブドメイン +1
6	3年以内に、このメディアを別サービスとして切り出す可能性がありますか	サブドメイン +1

点数の多い方が答えです。同点になったらサブディレクトリを選んでください。判断がつかない状態は、たいてい「まだ運用体制が決まっていない」だけなので、後から分ける方が安全だからです。

ステップ2. 誰が更新し続けるのかを、名前で確認する

判定シートの2問目と5問目は、想像で答えると外します。実際に「来月の記事を誰が公開ボタンを押すのか」を名前で確認してください。

制作会社に発注する場合は、次の文面をそのまま送って確認するのが早いです。ここが曖昧なまま構成だけ決めると、公開直前に「うちの管理サーバーに置くのでサブドメインでお願いします」と言われて設計が崩れます。

お世話になっております。
新しく立ち上げるメディアの置き場所を決めるにあたり、
下記4点についてご確認をお願いします。

1. 記事の更新作業は、弊社側で行う想定でしょうか。
   それとも御社側で対応いただく形でしょうか。
2. 本体サイトと同じサーバー・同じCMS上に構築できますか。
   別々になる場合は、その理由も教えてください。
3. サブドメインで構築する場合、SSL証明書の発行と更新は
   どちらが担当し、費用はどこに含まれますか。
4. 契約終了時に、記事データとURL構成を弊社側へ
   引き継ぐことは可能でしょうか。

お手数をおかけしますが、よろしくお願いいたします。

4番目は特に大事です。サブドメインの中身が制作会社のサーバーにある場合、解約すると記事ごと消えることがあります。

ステップ3. サブドメインを選ぶなら、DNSと証明書を先に確認する

サブドメインに決まったら、公開前にDNS（ドメイン名とサーバーを結びつける仕組み）と証明書を確認します。ターミナルで次のコマンドを実行すると、その場で分かります。

# 前提：Mac または Linux のターミナルで実行します。
# Windowsの場合は WSL か Git Bash を使ってください。
# ［media.example.com］の部分を、自社で使うホスト名に書き換えます。

# 1) 新しいサブドメインが、正しくサーバーを指しているか確認する
dig +short media.example.com

# → IPアドレスが表示されればOK。何も出ない場合はDNSレコードが未設定です。

# 2) SSL証明書が、そのホスト名をカバーしているか確認する
openssl s_client -connect media.example.com:443 -servername media.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -ext subjectAltName -dates

# → subjectAltName の行に media.example.com が含まれていればOK。
#   含まれていない場合、ブラウザに警告が出て誰も読めないサイトになります。
#   notAfter の日付が証明書の有効期限です。自動更新の対象か必ず確認してください。
#   -ext オプションでエラーが出る場合は openssl version でバージョンを確認し、
#   -ext subjectAltName を -text に置き換えて実行してください。

コマンドが不安な方は、ブラウザでそのURLを開いて鍵マークが出るかを見るだけでも構いません。ただし証明書の有効期限と自動更新の対象かどうかは、ブラウザでは分かりにくいので、サーバー会社の管理画面で確認してください。

ステップ4. robots.txtとサイトマップを、ホストごとに用意する

サブドメインを立てたら、そのホストのルート直下に robots.txt を置きます。media.example.com/robots.txt でアクセスできる場所です。example.com/media/robots.txt のような階層下に置いても読まれません。

中身は、最初はこれで足ります。

# media.example.com/robots.txt として保存します
# ［media.example.com］は自社のホスト名に書き換えてください

User-agent: *
Allow: /

# サイトマップは必ず絶対URLで書きます。
# 本体側（example.com）のサイトマップURLを書いてはいけません。
Sitemap: https://media.example.com/sitemap.xml

弊社が構築時に確認する中でも、サイトマップのURLを本体のものからコピペしたままの例は珍しくありません。ホスト名の部分を必ず見直してください。あわせて、Search Consoleにそのサブドメイン用のプロパティを追加します。どのプロパティ種別で登録するかは、前章のヘルプページで対象範囲を確認したうえで決めてください。

ステップ5. 公開前に7点チェックする

公開の直前に確認するのは次の7点です。ここまでやって初めて「置き場所を決めた」と言えます。

1. 本体サイトからメディアへの導線が、グローバルナビかフッターにあるか
2. メディアから本体のサービスページ・問い合わせへの導線があるか
3. robots.txt がホストのルート直下にあり、意図しない Disallow が残っていないか
4. Search Console に、そのホストを含むプロパティが登録され、サイトマップを送信済みか
5. GA4 のデータストリームが登録済みで、テスト閲覧が計測できているか
6. httpsで開いたときにブラウザの警告が出ないか（証明書の対象ホスト名を確認）
7. 本体側とメディア側で、同じ内容のページが二重に公開されていないか

この章の結論として、判定シートで方向を決め、DNSと証明書で技術的に成立するかを確かめ、7点チェックで公開する、という順番を守れば、置き場所の判断で迷う余地はなくなります。

オウンドメディアをサブドメインにするかどうか。ケース別の答え

「オウンドメディア サブドメイン」で検索する方が一番知りたいのは、自社のケースがどちらなのかという点だと思います。よくある6パターンについて、実際にどちらを選ぶことが多いかを整理します。

作るもの	おすすめ	理由
自社サービスの周辺知識を書く記事メディア	サブディレクトリ	本体と内容が地続きで、更新も社内。分ける手間に見合う理由がない
導入事例・お客さまの声	サブディレクトリ	営業資料としてサービスページとセットで読まれる。分断させたくない
採用サイト	どちらもあり	人事部が別のツールで運用するならサブドメイン。会社案内の延長ならサブディレクトリ
ヘルプセンター・FAQ（SaaS等）	サブドメイン	専用のSaaSを使うことが多く、本体サーバーに同居させられない
別ブランドの新サービス	サブドメイン、または独立ドメイン	将来切り出す可能性がある。本体と客層も名前も違う
キャンペーン用の単発LP	サブディレクトリ	終了後にページを消すか残すかを本体側でまとめて管理できる

他社の構成を参考にするときは、URLの形だけを真似ても意味がありません。サブドメインに分かれているサイトは、運用主体が事業ごとに分かれている結果としてそうなっていることが多いからです。見るべきはURLではなく、その会社の運用体制の方です。

note や外部のブログサービスに記事を置くのは、サブドメイン以上に切り離れた選択です。記事が自社ドメインの資産にならず、サービス終了や規約変更のリスクも背負います。集客のために書くなら、自社ドメインの中に置いてください。

この章の結論として、迷ったら「これを運用する人が本体サイトも触るか」で切ってください。触るならサブディレクトリ、触らないならサブドメインです。

この判断で何が変わるか。やり直しにかかる時間と手間

置き場所を最初に決める価値は、「後から変えたときのコスト」を見ると分かります。ここは感覚ではなく、Google公式の記述で確認できます。

Google公式のサイト移転ドキュメントでは、301リダイレクトは可能な限り長く、一般的には最低1年は維持することが案内されています。

つまり、media.example.com で1年運用してからサブディレクトリに移すと、次のような負担が発生します。

• URL対応表の作成：旧URLと新URLを1対1で並べた一覧が必要。記事100本なら100行
• リダイレクト設定と検証：設定して終わりではなく、全URLが正しく飛ぶかの確認が要る
• 1年以上のリダイレクト維持：旧ホストのサーバーと証明書を、その間ずっと生かしておく
• Search Console側の手続きの確認：移転の内容によって使えるツールや必要な操作が変わるため、Search Console ヘルプで自社の移転パターンが対象になるかを確認する
• 再クロール・再インデックスの待ち時間：移転後すぐに全ページが入れ替わるわけではない。この期間に広告や営業の予定を重ねると、原因の切り分けが難しくなる

逆に、最初に正しく決めておけば、これは丸ごと発生しません。置き場所を決める作業そのものは短時間で終わるのに、やり直しには長期の維持作業がついてくると考えてください。

もう一つ、日々の運用で効いてくるのが管理画面の数です。サブドメインを1つ増やすと、次の管理対象がそれぞれ1つずつ増えます。

• SSL証明書：新しいホスト名分の発行・更新の対象が増える
• Search Console：そのホストを見るプロパティが増える
• GA4：データストリームが増える
• サーバー：死活監視やバックアップの対象が増える

1人で運用している会社では、この見る場所が増えること自体が負担になります。

この章の結論として、後から変えるには再インデックスの待ち時間と1年以上のリダイレクト維持が必要になります。だからこそ、判定シートの6問に今日答えてしまう価値があります。

よくある失敗4つ。サブドメインを立てたときに起きること

ここからは、実際に置き場所の判断でつまずくポイントです。どれも設定の話なので、知っていれば防げます。

失敗1. サブドメインを立てたのに、Search Consoleに数字が出てこない

本体サイトをURLプレフィックスプロパティ（https://example.com/）だけで登録している状態でサブドメインを立てると、そのメディアの検索データはどのプロパティにも入りません。「まだ評価されていないのかな」と待ってしまい、半年後に登録漏れだったと気づくパターンです。

防ぎ方はシンプルで、サブドメインを作った日にプロパティを追加します。追加後は、そのホストのデータが実際に画面に出てくるかまで確認してください。

失敗2. GA4で参照元が自社サイトだらけになる

本体サイトからサブドメインへ移動したアクセスが、外部からの流入として二重に記録されることがあります。本体とサブドメインは別ホストなので、計測タグの設定が揃っていないと起こります。

こうなると、レポートの参照元に自社サイトが並び、検索から来た人なのか本体から回ってきた人なのかが分からなくなります。サブドメインを立てたら、本体からメディアへ実際に移動してみて、参照元に自社ドメインが記録されていないかを必ずテストしてください。設定方法は、使っている計測タグの種類に合わせてGA4のヘルプで確認します。

失敗3. 証明書がワイルドカードでなく、公開当日に警告が出る

本体サイトの証明書が example.com と www.example.com だけを対象にしている場合、media.example.com でhttpsアクセスすると、ブラウザが「安全ではない」と警告を出します。この状態では読者は先へ進みません。

公開日にこれが起きると、DNSの反映待ちと区別がつかず、原因の切り分けに時間を取られます。ステップ3のコマンドか、サーバー会社の管理画面で、新しいホスト名が証明書の対象に入っているかを事前に確認してください。ワイルドカード証明書（*.example.com）を使っているか、ホストごとに発行するかで作業量が変わります。

失敗4. サブディレクトリ化のためにリバースプロキシを組んで、障害対応で詰まる

「別のCMSを使いたいけれどURLはサブディレクトリにしたい」という場合、リバースプロキシ（本体サーバーが受けたリクエストを裏側の別サーバーに転送する仕組み）を組めば実現できます。技術的には可能です。

問題は公開後です。メディアが表示されなくなったとき、原因が本体サーバーなのか、転送設定なのか、裏側のCMSなのかを切り分けられる人が社内にいないと、復旧が止まります。制作会社に任せる場合は、その会社が転送設定まで面倒を見るのか、契約が切れた後は誰が触るのかを先に決めておいてください。

この章の結論として、失敗の中身はSEOの理屈ではなく、Search Console・GA4・証明書・サーバー構成という4か所の設定漏れです。公開前チェックの7点を通せば、4つとも防げます。

現場で見えた妥協点。理屈どおりに決められない場面

ここまで判断軸を書いてきましたが、実際の現場では理屈だけで決まらないことがあります。率直に書きます。

制作会社が「サブドメインで」と言うときの理由

提案書でサブドメインが指定されているとき、その理由が技術的な必然とは限りません。自社の管理サーバーに置きたい、自社の使い慣れたCMSで作りたい、というのが実情のこともあります。それ自体は悪いことではありませんが、発注側は「本体サイトと同居できない理由は何か」を一度聞くべきです。

納得できる理由（本体がSaaS型のサイトビルダーで追加できない、セキュリティ要件で分離が必要、など）が返ってくれば問題ありません。理由が曖昧なら、サブディレクトリで組めないかを検討する余地があります。

「あとで分ける」と「あとでまとめる」では、必要な作業が違う

サブディレクトリで始めて後からサブドメインに切り出すのも、サブドメインで始めて後からまとめるのも、どちらも移転作業です。ただし、事前に決めておく項目の数が違います。

切り出すときは「その部分だけを別ホストに移す」話で済みますが、まとめるときは本体側のURL設計との衝突（同じパスを本体がすでに使っている、記事のカテゴリ構造が噛み合わない）を先に解く必要があります。迷ったらサブディレクトリ、と書いているのは、こちら側の道が後で選びやすいからです。

サブディレクトリでも、記事が本体と噛み合わなければ意味がない

サブディレクトリにすれば自動的にうまくいく、という話ではありません。本体のサービスページと記事が内容的につながっていなければ、URLが同じドメインにあってもそれぞれ孤立します。

現場でよく見るのは、メディアだけが増え続けて、記事から本体のサービスページへ1本もリンクが張られていない状態です。置き場所を決めたら、記事からサービスページへ、サービスページから関連記事へという行き来を設計してください。リンクの張り方は内部リンクの貼り方とアンカーテキスト最適化の5ステップで解説しています。

生成AIの検索結果に出ることを狙うなら、まとめる方が説明しやすい

ChatGPTやGoogleのAI検索が情報源を選ぶとき、サブドメインを別サイトとして扱うか同じ会社の一部として扱うかは、外からは確認できません。断定できる材料がないので、ここを根拠に構成を決めるのはおすすめしません。

確実に言えるのは、会社の情報が1つのドメインにまとまっていた方が、読み手にとっても機械にとっても「どこの誰が書いたか」がたどりやすいということです。判断に迷ったときの、もう一押しの材料くらいに考えてください。

この章の結論として、置き場所の判断で本当に見るべきは「その構成を、3年後に誰が保守するか」です。今日いちばん作りやすい構成ではなく、担当者が変わっても回る構成を選んでください。

よくある質問

今日の最初の一歩

まずは判定シートの6問に答えてみてください。5分で終わりますし、ここで「更新するのは誰か」が社内で決まっていないことに気づくケースがかなりあります。そこがはっきりすれば、置き場所は自動的に決まります。

置き場所が決まったあと、記事を書いても問い合わせにつながらないという段階に進んだら、ホームページで集客できない原因と改善手順を読んでみてください。

ここまで読んで、社内だけで構成を決めきるのは不安だと感じた方は、コレットラボのホームページ制作・運用支援にご相談ください。サイトの置き場所やURL設計から、公開後に検索とAI検索で見つかる形に整えるところまで一緒に設計します。

まずは現状を整理するだけの打ち合わせでも構いません。ホームページ制作・運用の詳細はこちらから、お気軽にお声がけください。