SEO・GEO教科書 · Lesson 08
ドメイン構造：サブドメインとサブディレクトリ、ホスト名の統一
コンテンツをどのドメインに置くかを決めるレッスンです。サブドメインとサブディレクトリで運用の単位がどう変わるか、www有無やhttpsで分かれたホストをどう1本に寄せるか、中古ドメインの何が禁止されているかを整理します。
新しいコンテンツをサブドメインとサブディレクトリのどちらに置くかを理由つきで決め、サイトのホスト名を1つに統一できるようになる。
このレッスンで扱うこと
- ドメイン・サブドメイン・サブディレクトリで、何が別の単位になるのか
- ブログやヘルプを分けるかどうかの判断基準
- www有無・http/httpsなど、同じ内容が複数のホストで見える状態の畳み方
- 検証環境やプレビューURLが検索結果に出ないようにする
- 中古ドメイン（期限切れドメイン）とサブディレクトリの貸し出しで禁止されていること
どこで単位が分かれるのか
前のレッスンではサイトの内側の構造を扱いました。ここでは1つ外側、どのドメインにコンテンツを置くかを決めます。まず押さえるのは「サブドメインにすると、何が別々になるのか」です。
Figure
3つの分け方と、分けたときに増えるもの
別ドメイン（example.net）
完全に別サイト
運営主体やサービスが別。設定・計測・内部リンクのすべてが独立する。
サブドメイン（blog.example.com）
ホストが別
robots.txt・サイトマップ・URLプレフィックスのプロパティが、そのホスト用に別途必要になる。
サブディレクトリ（example.com/blog/）
同じホスト
robots.txtもサイトマップもSearch Consoleのプロパティも、既存のものをそのまま使える。
上に行くほど独立性が上がり、同時に管理する対象が増える。増える手間に見合う理由があるかで選ぶ。
robots.txtは、ホストの直下に置いたものだけが、そのホストに適用されます。example.com/robots.txt は blog.example.com には効かないため、 サブドメインを作ったらそこにもrobots.txtを用意します。用意しなければ、そのサブドメインには クロールの制限が何も無い状態になります。[出典: robots.txt の書き方、設定と送信]
サイトマップも同じで、原則として同じホストのURLだけを載せます。 サブドメインを増やすと、サイトマップも増え、送信と更新の管理対象も増えます。[出典: サイトマップの作成と送信]
Search Consoleでは、URLプレフィックスプロパティがホストごとに分かれます。サブドメインをまとめて見たい場合は ドメインプロパティを使いますが、これにはDNSレコードでの所有権確認が必要です（レッスン02で登録した形式を確認してください）。
なお、Googleがサブドメインを常に別サイトとして扱うと明言しているわけではありません。 ここで挙げたのは、仕様として確実に分かれる運用上の単位です。順位がどう変わるかではなく、管理する対象がいくつになるかで判断するのが、確認できる範囲での判断基準になります。
サブドメインとサブディレクトリの選び方
迷ったらサブディレクトリです。分けるのは、分けないと運用できない事情があるときだけにします。
Figure
どちらを選ぶか
サブディレクトリにまとめる
example.com/blog/
- 同じサイトのテーマとして、内部リンクで自然につながる
- robots.txt・サイトマップ・プロパティが1組で済む
- オウンドメディア、事例集、ヘルプ、導入事例など、本体と読者が重なるもの
- 後からサブドメインへ移すのは、URLの変更を伴う移転になる
サブドメインに分ける
blog.example.com
- 技術的に同居できない（別のCMS・別のホスティング・別の基盤）
- 運営チームも読者も別で、内部リンクでつながる必然性が無い
- 言語や国ごとにサイトを丸ごと分ける
- ユーザー投稿など、本体と同じ責任範囲で扱いたくないコンテンツ
| 置きたいもの | 推奨 | 理由 |
|---|---|---|
| オウンドメディア・ブログ | サブディレクトリ | 本体と読者が重なり、内部リンクで相互に送客できるため |
| ヘルプ・ドキュメント | サブディレクトリ | 製品ページからの導線が自然につながり、設定も1組で済むため |
| 別基盤のサービス（アプリ・管理画面） | サブドメイン | 同じホストに同居させられず、検索に出す必要も無いことが多いため |
| 言語・地域ごとの別サイト | どちらでも可（統一する） | 分けること自体より、選んだ方式をサイト全体で揃えることのほうが効くため |
| ユーザー投稿・外部提供のコンテンツ | サブドメイン、または責任範囲を明示 | 本体の評価と切り離して扱うため。詳細は後述のスパムポリシー |
どちらを選んでも、後から変えるとURLの変更を伴う移転になります。 移転には旧URLと新URLの対応表と301リダイレクトが必要で、対応漏れがそのまま流入の損失になります。 手順はレッスン12で扱いますが、最も安全なのは最初に決めて動かさないことです。[出典: URL の変更を伴うサイト移転]
ホスト名を1つに決める
www有無、httpとhttps、末尾スラッシュの有無は、それぞれ別のURLです。何もしなければ、同じ内容が複数のURLで見える状態になります。使うホスト名を1つ決め、他はそこへ寄せます。
| 分かれ方 | 起きること | 対処 |
|---|---|---|
| http と https | 同じページが2つのURLで見える | httpからhttpsへ301リダイレクトし、サイト内のリンクもhttpsで書く |
| www あり と www なし | 同じページが2つのホストで見える | 使うほうを決め、もう一方から301リダイレクトする |
| 末尾スラッシュのあり・なし | 同じページが2つのURLで見える | どちらかに統一し、もう一方は301で寄せる |
| ホスティング事業者の初期ドメイン | 独自ドメインと初期ドメインの両方で同じ内容が見える | 初期ドメインから独自ドメインへリダイレクトするか、canonicalを独自ドメインに固定する |
実装の要点は、canonicalやOGP、サイトマップが参照するサイトURLを、コードの1か所で持つことです。 ページごとにホスト名を書くと、追加したページだけ古いホスト名のまま、という状態が起きます。 1か所にまとめておけば、ドメインを変えるときに直す場所も1つで済みます。[出典: SEO スターター ガイド]
検証環境を検索結果に出さない
本番と同じ内容が、検証用の別ホストでも公開されている状態は、意図しない重複です。デプロイのたびに新しいプレビューURLが増える構成では特に起きやすくなります。
Figure
検証環境の扱い
やること
- Basic認証などでアクセス自体を制限する（最も確実）
- 公開したまま止めるなら、meta robots の noindex を返す
- canonicalは、プレビュー環境でも本番のホスト名を指すようにする
- 本番公開の直後に、robots.txt と meta robots を実機で確認する
やらなくていいこと
- robots.txt のDisallowだけでインデックス済みのURLを消そうとする
- 検証環境用のnoindexを本番へそのまま持ち込む
- プレビューURLを、そのままSNSや資料に貼る
- 検証環境のサイトマップを送信したままにする
noindexを使う場合、そのページはクロールできる必要があります。robots.txtでブロックすると、 noindexの指定自体が読まれません。ブロックと除外は別の手段だと理解して使い分けます （レッスン05）。
中古ドメインと貸しディレクトリ
ドメインの扱いには、スパムポリシーで明示的に禁止されている使い方があります。順位を狙って 「評価のあるドメイン」を借りる・買うという発想が、そのまま該当します。[出典: ウェブ検索のスパムに関するポリシー]
| 禁止されている行為 | どういう使い方か | 実務で起きやすい形 |
|---|---|---|
| 期限切れドメインの不正使用 | 期限切れのドメインを、過去の評価を利用する目的で取得し、以前のサイトとほぼ無関係な内容を載せる | 中古ドメイン販売業者から「被リンクが付いている」ドメインを買い、別ジャンルのサイトを立てる |
| サイトの評判の不正使用 | 第三者のコンテンツを、そのサイトの評価を利用する目的で、運営者の監督がほとんど無いまま掲載する | 自社ドメインのサブディレクトリを外部業者に貸し、そこにアフィリエイト記事を置いてもらう |
判断の分かれ目は、置き場所がサブドメインかサブディレクトリかではなく、そのコンテンツを誰が作り、誰が責任を持っているかです。 自社で企画し、自社で編集し、自社の名前で出しているなら、外部ライターが書いていても問題になりません。 逆に、枠だけ貸して中身に関与していないなら、置き場所を変えても同じ判定の対象になります。
中古ドメインについても、ドメインを買うこと自体が禁止されているわけではありません。 事業の継続や社名変更で引き継ぐのは通常の運用です。問題になるのは、過去の評価を引き継ぐこと自体を目的に、 無関係な内容を載せる場合です。
実例：このサイトのドメイン構成
このサイトは、単一ホストにすべてを置く構成です。ここまでの判断をどう実装しているかを、そのまま挙げます。
| 決めたこと | どうしているか | 理由 |
|---|---|---|
| ホストを分けない | 記事・教科書・ツールをすべて同じホストのサブディレクトリに置く | 別の基盤を使う必要が無く、内部リンクで相互に送客できるため |
| サイトURLを1か所で持つ | 環境変数を1つ読む定数を用意し、canonical・OGP・サイトマップ・JSON-LDのすべてがそれを参照する | ドメインを変えるときに直す場所を1つにするため |
| プレビュー環境のURL | プレビューでも本番のホスト名を返すようにし、canonicalが本番を指すようにする | デプロイのたびに増えるプレビューURLが、本番と重複しないようにするため |
| カテゴリの旧URL | /category/seo などから /seo へ308リダイレクト | URLを変えた分は、旧URLを残さず新URLへ寄せるため |
| robots.txtとサイトマップ | 同じホストの直下に1組だけ置き、サイトマップのURLをrobots.txtに書く | ホストが1つなので、管理する組も1つで済むため |
この構成の利点は、確認する場所が少ないことです。robots.txtは1つ、サイトマップは1つ、 Search Consoleのプロパティも1つで、どこかだけ設定が古いという状態が起きません。 サブドメインを増やすなら、この一式をサブドメインの数だけ用意して維持できるかを先に考えます。
次のレッスンでは、ここまでで整えたサイトを、生成AIに引用される状態にするための設定を扱います。 AIクローラーの許可・拒否もrobots.txtで書くため、ホストを分けた分だけ、その設定も増えます。
到達チェックリスト
次の項目を自分のサイトで確認できたら、このレッスンは終わりです。1つでも「まだ」がある場合は、次のレッスンに進む前にそこを埋めてください。
- サイトのホスト名を1つ（www有無・httpsの有無を含めて）に決め、他は301でそこへ寄せてある
- canonicalが常に本番のホスト名を指している（プレビュー環境でも本番URLになる）
- サブドメインを使っている場合、そのサブドメインにもrobots.txtとサイトマップを置いてある
- サブドメインごとにSearch Consoleで数値を確認できる状態にした（ドメインプロパティ、または個別プロパティ）
- 新しいコンテンツをサブディレクトリに置くか、サブドメインに分けるかの基準を決めた
- 検証環境・ステージング環境が、認証かnoindexで検索結果に出ないようにしてある
よくある質問
サブドメインとサブディレクトリでは、どちらがSEOに有利ですか
どちらが有利かをGoogleが公式に示している説明はありません。実務で確実に違うのは、運用の単位です。robots.txtはホストごとに置く必要があり、サイトマップは原則として同じホストのURLだけを載せます。Search Consoleも、URLプレフィックスプロパティではホストごとに分かれます。分けた数だけ設定と確認の手間が増えるため、分ける理由が無ければサブディレクトリにまとめるほうが運用は軽くなります。
wwwありとwwwなしは、どちらにすべきですか
どちらでも構いません。重要なのは片方に統一することです。www有無、httpとhttps、末尾スラッシュの有無は、それぞれ別のURLとして見えるため、同じ内容が複数のURLで表示される状態になります。使うほうを1つ決め、もう一方からは301リダイレクトし、canonicalも統一したURLを指すようにします。
中古ドメイン（期限切れドメイン）を買ってサイトを始めてもよいですか
Googleはウェブ検索のスパムに関するポリシーで「期限切れドメインの不正使用」を挙げており、過去のドメインの評価を利用する目的で、以前のサイトとほぼ関係のないコンテンツを載せる使い方を禁止しています。ドメインを買うこと自体が禁止されているわけではありませんが、評価を引き継ぐ手段として買うのであれば、ポリシー違反の側に入ります。
自社サイトのサブディレクトリを外部の業者に貸すのは問題ありますか
スパムポリシーの「サイトの評判の不正使用」に該当し得ます。第三者のコンテンツを、そのサイトの評価を利用する目的で、運営者の監督がほとんど無いまま掲載する形が対象です。サブディレクトリかサブドメインかという置き場所ではなく、誰が作り、誰が責任を持つコンテンツなのかで判断されます。
開発中のプレビューURLが検索結果に出てしまいました
検証環境が本番と同じ内容で公開されていると、別ホストに同じ内容がある状態になります。対処は、Basic認証などでアクセス自体を制限するのが確実です。公開したまま止める場合はnoindexを使います。robots.txtでのブロックは、クロールを止めるだけでインデックス済みのURLを消す手段ではありません。あわせて、canonicalが常に本番のホスト名を指すようにしておきます。
Sources · 一次情報
- SEO スターター ガイド（Google 検索セントラル）
- Google 検索の基本事項（Google 検索セントラル）
- 重複した URL を統合する（Google 検索セントラル）
- robots.txt の書き方、設定と送信（Google 検索セントラル）
- noindex でコンテンツをインデックスから除外する（Google 検索セントラル）
- サイトマップの作成と送信（Google 検索セントラル）
- Google ウェブ検索のスパムに関するポリシー（Google 検索セントラル）
- URL の変更を伴うサイト移転（Google 検索セントラル）