サブドメインの実用設計 ― blog./api./www. をどう分けるか

サブドメイン設計は，事業が育つほど効いてくる地味だが重要なテーマ．本記事では blog. api. www. をどう分けるかの実用判断軸を整理する．

この記事では，個人開発者・スモールチーム・学生エンジニアの方を主な読み手として書いています．10分で読み終わって，明日から動ける具体的な行動が1つ見つかる状態を目指しています．

なぜサブドメイン設計が後から効いてくるのか

サブドメイン設計は，サービス基盤の住所を決める作業．後から変えると外部リンク・SEO・SSL証明書・Cookieまで全部影響する．

最初に決めるだけで，「事業が育っても破綻しない」構造にできる．逆に最初に雑に決めると，2年後に大規模リファクタが必要になる．

選択肢は blog.example.com か example.com/blog の2択．SEO的にはサブディレクトリ(/blog)が有利と言われている．ドメイン全体の評価が記事に乗るため．

逆に，技術スタックを完全に分けたい(本体は静的，ブログはWP)場合はサブドメイン．本体の障害がブログに波及しないメリットがある．

APIは api.example.com として必ず分ける．Cookie / Origin / レート制限 / CORS の管理が圧倒的にラク．

パス方式(/api)で運用すると，本体のCDNキャッシュとAPI応答が混ざる事故が起きやすい．独立したサブドメインなら独自のCDN設定が組める．

近年のトレンドは www なし(apex / naked ドメイン)．短く，モダン．ただし apex には CNAME が貼れない制約があるため，DNS事業者の対応を要確認．

決めたら301リダイレクトでもう一方を強制統一．SEO観点で必須．これを怠ると評価が2つに分散する．

大規模になると static.example.com や cdn.example.com を切る．画像・CSS・JSをここに置くと，Cookieが付かず軽い．

個人開発の初期は不要．アクセスが月10万PVを超えたあたりで検討．早すぎる最適化は無意味．

dev. staging. preview. のいずれかで統一．Basic認証 + IP制限で外部から見えなくする．robots.txt で Disallow: / も忘れずに．

ステージングが Google にインデックスされると本番との重複コンテンツ判定を食らう．最初のSSL証明書発行と同時にrobots設定する習慣を．

サブドメインは無料で無限に切れます．つまり1つのドメインで複数事業を運営できる．これがSNSでは絶対にできない独自ドメインの強みです．

これからドメインを取るなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ ならサブドメインのDNS設定もGUIで完結．wildcard レコードにも対応しているので，将来サブドメインを大量に切る運用にも耐える．

サブドメインを実際にホストするレンタルサーバーは，ロリポップ！がコスト・操作性ともに個人開発者向き．1契約でサブドメイン無制限，各々に独立のドキュメントルートを切れる．

SSL証明書管理が煩雑に．ワイルドカード証明書で一括取得すれば解決．

domain=.example.comと設定すれば共有可．認証セッションをまとめたい場合に使う．

Googleの基本見解は「別サイト扱い」．評価を1つに集約したいならサブディレクトリが有利．

大事なのは，「正解を完璧に押さえる」ことではなく「動き始める」ことです．今日，自分のドメインの構造を紙に書き出してみる．そこからの設計が後で資産になります．