docs.example.comのような、親ドメインの下にあるホスト名です。技術面やコンテンツ面で独立した役割を担えるため、サイト全体の構造の一部として計画する必要があります。
判断と境界
サブドメインとは、別のドメイン名の下にあるホスト名です。たとえば、example.comの下のdocs.example.comです。技術的には、独自のアプリケーション、ルーティング、Cookie、DNS設定、検索での存在感を持てます。この柔軟性は、情報設計の問いの答えにはなりません。サブドメインとサブディレクトリのどちらにするかは、運用上の所有範囲、プロダクトの境界、ローカライズやプラットフォーム上の必要性、ユーザーの導線にもとづいて決めます。SEO上のボーナスを期待して決めるものではありません。
確認するポイント
すべてのホスト名について、目的、所有者、正規のホスト、TLSの状態、robotsの規則、サイトマップ、アナリティクスの識別子、内部リンクの経路を洗い出します。境界をまたぐ代表的なページをクロールし、リンクが意図した正規のルートを直接指していることを確認します。移行時には、URL単位の対応表を保持し、ホスト全体のルーティングで十分だと決めつけず、リンク先ごとにテストします。
実装の進め方
サブドメインを使うのは、ドキュメント、アプリ、地域別に分かれたプラットフォームなど、安定していて理解しやすい境界ができるときです。独自の明確なナビゲーションとインデックス登録の方針を持たせつつ、親のサイトへの文脈内のリンクも残します。ホスト名の間でコンテンツを移すときは、適切な場合に直接の恒久的なリダイレクトを設定し、canonicalとサイトマップの参照を更新し、両側でレンダリングとトラッキングを検証します。
よくある誤りと計測の限界
危ない近道は、SEOの作業を切り離すためだけ、あるいはコンテンツを複製するためだけに、サブドメインを作ることです。所有範囲が分断され、サイト全体の修正が難しくなることがあります。サブドメインが権威性を自動的に引き継ぐ、あるいは失うと断言してはいけません。実際のリンク、コンテンツ、アクセシビリティ、移行の実装を評価します。
構成の具体例 ある企業が、製品のドキュメントをdocs.example.comに置くとします。別のドキュメントのプラットフォームとチームが所有しているためです。顧客向けのアプリケーションは、app.example.comにあります。ナビゲーション、アカウントに対する期待、検索の方針、所有範囲が明確なら、これは筋の通った境界になりえます。マーケティングのフォルダーを、テンプレートが違うだけの理由でサブドメインに移すのは、はるかに弱い理由です。ホスト名を選ぶ前に、ホストをまたぐユーザーの導線を文書にまとめます。
チェックの基準 ホストの一覧を維持します。項目は、目的、主な所有者、公開する正規のホスト、サイトマップ、robotsの方針、TLSの対応範囲、アナリティクスの範囲、主な入口のルートです。親からサブドメインへ、そして戻る方向の代表的なページをクロールし、直接の内部リンク、リダイレクトの動作、フッターやナビゲーションの経路を確認します。移行では、ホスト名のルートだけでなく、新旧のURLのペアをテストします。Cookie、ログイン、アプリへの引き継ぎが関わる場合は、ブラウザーとモバイルでの導線も確認します。
よくある誤り ルートのホストとサブドメインに、同じコンテンツを、canonicalや移行の明確な判断なしに複製しないでください。検索システムが、すべてのホスト名を1つのサイトとして扱う、あるいは完全に無関係なものとして扱うと決めつけず、実際のリンクとURLの構造を確認します。ホスト名の変更は、SEOだけでなく、運用、アナリティクス、ユーザーの信頼にも影響します。そのため、ルート単位の切り戻し計画が必要です。