サブドメインでサイトをいくつまで作っていいかに、検索エンジンが決めた明確な上限はありません。
ただし実務では、何個まで作れるか より 何個から管理が崩れ始めるか の方が大事です。
Google公式でも、サブドメインはサブドメイン単位で扱われる場面があります。たとえばサイト名は「ドメインまたはサブドメイン」を1サイトとして扱い、robots.txt もそのホスト単位でしか効きません。
つまり、サブドメインを増やすほど、見え方も管理単位も分かれていきます。
この記事では、サブドメインでサイトを増やしすぎるデメリットと、どんなときに分けるべきかを整理します。
結論：固定の上限はないが、小さいチームほど増やしすぎない方がよい
先に結論を書くと、サブドメインの数に ここまで という公式上限はありません。
ただし、小規模チームや個人運用では、むやみに増やすと SEO より先に運用コストで苦しくなりやすいです。
目安としては、次のように考えると分かりやすいです。
| 状況 | 向いている分け方 |
|---|---|
| 同じ読者に向けた同じ文脈の内容 | サブディレクトリでまとめる方が管理しやすい |
| 別サービス、別機能、別担当で運用する | サブドメインで分ける意味がある |
| ヘルプセンター、管理画面、アプリ本体など役割が明確に違う | サブドメインを検討しやすい |
| 理由が「何となく分かれそう」だけ | 増やさない方が無難 |
サブドメインが向いている場面
サブドメインが悪いわけではありません。
次のように、役割の境目がはっきりしているなら合理的です。
- 本体サイトとアプリを分ける
例:www.example.comとapp.example.com - 公式サイトとヘルプセンターを分ける
例:www.example.comとhelp.example.com - API や開発者向けドキュメントを分ける
例:api.example.comdocs.example.com - 地域、ブランド、顧客向けポータルが実質別サイトになっている
- 技術スタックやデプロイ責任が明確に別
要するに、見た目が違うから ではなく、目的・読者・運用責任が違うから 分けるのが基本です。
作りすぎると何がまずいのか
問題は「検索エンジンに嫌われるから」より、ひとつのサイトとして育てにくくなること です。
1. Search Console や計測の管理単位が増える
Google Search Console では、URL-prefix プロパティは指定した接頭辞だけを対象にし、複数サブドメインを別々に見たいなら追加管理が必要になります。
一方、Domain property は全サブドメインを含められますが、それでも どのサブドメインで何が起きているか を切り分けて見る手間は残ります。
つまりサブドメインが増えるほど、
- Search Console の確認対象が増える
- サイトマップの出し分けが増える
- 分析画面で原因を切り分ける手間が増える
- チーム内で
どこを誰が見るかが曖昧になりやすい
という負担が増えます。
2. robots.txt やクロール制御がサブドメインごとになる
Google公式では、robots.txt のルールは その host / protocol / port にしか適用されません。
https://example.com/robots.txt の設定は https://shop.example.com/ には効きません。
これは地味ですがかなり重要です。
サブドメインを増やすと、
- robots.txt を置き忘れる
- 意図しないブロックを片方だけ入れる
- サイトマップ URL を片方にしか書かない
- 本番とテスト用サブドメインの制御がズレる
といった事故が起きやすくなります。
3. Google上の見え方が分かれやすい
Googleのサイト名の仕様でも、現在は ドメインまたはサブドメイン ごとに1つのサイト名を扱います。
つまり news.example.com は、example.com/news と違って、検索結果上でも独立したサイトっぽく見えやすいです。
これは悪いことではありません。
ただし、ブランドをひとつにまとめたいのか、別サイトとして育てたいのかを曖昧にしたまま増やすと、
- ユーザーが別サイトだと感じる
- 指名検索の受け皿が割れる
- ブランド名やサイト名の一貫性が崩れる
といった問題が出やすくなります。
4. 内部リンク設計が弱くなりやすい
サブドメインが違ってもリンクは張れます。
ただ、編集や導線設計の感覚としては、同一サイト内のサブディレクトリより 少し遠い場所 になりがちです。
その結果、
- 関連記事リンクが減る
- 回遊導線が弱くなる
- パンくずやカテゴリ設計が分断される
- 読者が
ここから先も同じサイトの続きと感じにくくなる
という形で、サイト全体の読みやすさが落ちやすくなります。
5. DNS・SSL・配信設定の管理コストが増える
サブドメインは見た目の分離だけでなく、技術的にも管理対象を増やします。
このあたりがサブドメインごとに増えるので、サイト数が増えるほど設定漏れや認識ズレが起きやすくなります。
とくに小さいチームでは、ここがいちばん現実的なデメリットです。
SEO上は「サブドメインだから即不利」とは言えない
ここは誤解されやすいところです。
Google公式の最近のドキュメントを見ても、サブドメインは何個まで や サブドメインはSEOで不利 という機械的な基準は出てきません。
むしろ実際に効いてくるのは、
- クロールさせたい URL が整理されているか
- サイトマップが正しく出ているか
- サイト同士の関係が分かりやすいか
- 内容の重複がないか
- ユーザーが迷わず移動できるか
です。
Googleの crawl budget ガイドでも、そもそも細かいクロール最適化が必要になるのは巨大かつ高頻度更新のサイトが中心で、普通の規模ならまずはサイトマップ更新とインデックス確認で十分とされています。
なので、小〜中規模サイトで本当に問題になりやすいのは、SEO理論上の損得 より 構造が散らかること です。
じゃあ何個までに抑えるべきか
絶対の数字はありませんが、実務では次の考え方が使いやすいです。
1. まずは親ドメイン配下に寄せる
同じ読者、同じブランド、同じ更新チームで動かすなら、まずはサブディレクトリで持てないかを考えます。
例:
example.com/blogexample.com/helpexample.com/case-studies
この形で困らないなら、無理に blog. help. case. と分けない方が運用は楽です。
2. 分けるなら理由を一文で言えるようにする
サブドメインを切るなら、なぜ別にするのか を一文で説明できる状態がよいです。
たとえば、
app.example.com はログイン後のアプリ本体だからhelp.example.com はサポートチームが独立運用するからstatus.example.com は障害告知のため可用性要件が違うから
のように言えるなら、分ける意味があります。
逆に なんとなく分けた方が整理されそう くらいなら、あとで戻したくなることが多いです。
3. 小規模運用なら数を絞る
個人サイトや小規模チームなら、サブドメインは本当に必要なものだけに絞るのが無難です。
たとえば次の2〜4個くらいに収まるなら、管理しやすさを保ちやすいです。
wwwapphelpstatus
もちろん例外はありますが、増やすたびに Search Console / robots.txt / sitemap / DNS / SSL / 導線 が増える前提で考えた方が安全です。
判断に迷ったときのチェックリスト
サブドメインを増やす前に、次のチェックをすると判断しやすくなります。
- 読者は本当に別か
- ブランド上、別サイトとして見えても問題ないか
- ナビゲーションや内部リンクを自然につなげられるか
- Search Console や計測を分けて追う必要があるか
- robots.txt、サイトマップ、DNS、SSL を別管理しても回るか
- 数か月後に
やっぱり統合したいとなりにくいか
このうち複数で迷うなら、分けない方がうまくいきやすいです。
結論
サブドメインでサイトをいくつまで作っていいかに、検索エンジンの明確な上限はありません。
ただし、増やしすぎると SEO の前に、管理単位・設定単位・ブランド単位が分かれすぎて、サイト全体を育てにくくなります。
基本方針としては、
- 同じ文脈ならサブディレクトリ
- 役割や責任が明確に違うならサブドメイン
- 小さいチームほど数を絞る
で考えるのが実務的です。
何個までOKか ではなく、増やしたあとも迷わず運用できるか で判断するのがいちばん失敗しにくいです。
この記事と一緒に読みたい
- robots.txtとは？検索エンジンとAIクローラーに何を伝えるファイルなのか
- DNSとは？ドメインとサーバーをつなぐ仕組みを初心者向けに整理
- プロジェクトのフォルダ名はサービス名にすべきか 用途名にすべきか
サブドメイン運用のよくある質問
Q. サブドメインとサブディレクトリ、どっちが SEO 上有利？
A. 一般に同等。ただし、サイト全体の権威性をまとめたい ならサブディレクトリ、完全に別サイトとして運用したい ならサブドメイン。Google 公式は どちらも適切に扱う としています。
Q. サブドメインは何個まで作れる？
A. 技術的にはほぼ無限。ただし 管理できる範囲 が現実的な上限。5-10個 までは一般的、20個以上 は専門チームがないと管理破綻。
Q. クロール予算は問題になる？
A. 通常は問題なし。数百ページ規模 のサブドメイン10個程度なら、Google も問題なくクロール。数万ページ規模 + 多数サブドメイン なら、クロール予算最適化が必要。
Q. SSL証明書はどうする？
A. Let’s Encrypt の ワイルドカード証明書(*.example.com) で全サブドメインを1つの証明書でカバーできます。商用なら ACM などのマネージド証明書も便利。
Q. SEO 上、メインサイトの順位への影響は？
A. 直接的な悪影響はないが、リソース分散 で意図せず競合する可能性。同じテーマのサブドメインは統合した方がいいことも。
Q. サブドメイン削除する手順は？
A. 1) 301 リダイレクトを統合先URLへ設定、2) Search Console から削除、3) DNS から削除、4) 数か月後にサブドメイン自体を解放。いきなり 404 だと SEO 影響大。
Q. 検証用、ステージング用サブドメインは？
A. 一般的に staging.example.com、dev.example.com、で運用。Basic 認証 + IP制限 + noindex を必ず設定。クロールされて検索結果に出ると問題に。
参考リンク
- Google Search Central: Site names in Google Search
- Google Crawling Infrastructure: Optimize your crawl budget
- Search Console Help: Add a website property to Search Console
- Google Crawling Infrastructure: How Google interprets the robots.txt specification