こんにちは。バナナデスクです。
会社サイトにブログを追加するとき、「example.com/blog/」と「blog.example.com」のどちらがSEOに強いのか、迷うことがあります。
ただ、その問いだけでURLを決めると、記事を更新するたびに制作会社へ依頼が必要になったり、保守する人が決まらない別サイトが増えたりします。先に確かめたいのは、誰が、どのCMSで、どこまで管理するかです。
GoogleはクロールとインデックスのFAQで、サブフォルダとサブドメインについて、整理・管理しやすい方を選ぶよう説明し、インデックスやランキングの観点で一方を好むとはしていません。この記事では、その前提で事業ブログの運用条件から選びます。
サブディレクトリとサブドメインの違い
example.com/blog/のようにホスト名の後ろのパスで区切るのがサブディレクトリです。blog.example.comのようにドメイン名の前へ別のホスト名を置くのがサブドメインです。どちらも、読者が記事へたどり着き、内容を理解できるように設計する必要があります。
サブディレクトリだから必ず同じCMS、サブドメインだから必ず別会社のサイトになるわけではありません。ただし、小規模サイトでは同じCMSのブログ機能を同じドメイン配下で使う方が、更新や内部リンクを一元管理しやすい場合があります。技術的に別CMSを同じパスへ組み込む構成には、保守する人の対応範囲も関係します。
3つの運用例から選ぶ
次は架空の事業サイトの設計例です。URLだけで順位の優劣を決める比較ではありません。
| 条件 | 最初に検討する構成 | 決める前に確かめること |
|---|---|---|
| 会社サイトもブログも同じWordPress。担当者1人が更新 | 同じサイトの/blog/などへまとめる | 既存URLとの衝突、カテゴリー、ナビゲーション、更新権限 |
| 会社サイトは別CMS。ブログだけWordPressを使いたい | 別ホストで動かせるblog.example.com等も候補 | DNS・HTTPS・バックアップ・障害対応を誰が持つか。同じパスへ置く案の実装費も比較 |
| 公開承認だけ別チーム。CMS更新と復旧は会社側で共通 | 同じCMSの/blog/で権限と承認手順を分ける案 | CMS本体の保守まで独立させる必要があるか。あるなら別CMS・サブドメイン案と比較 |
たとえば月2本の記事しか書かないのに、別のCMS、別の保守契約、別の更新手順を増やすと、記事制作より管理作業が重くなるかもしれません。反対に、会社サイトの担当が外部に固定され、ブログを毎週自分で更新したいなら、独立して更新できる仕組みに価値があります。
「編集チームを分けたい」を、担当と構成へ落とし込む記入例
架空の研修会社で、広報2人が毎週記事を書き、事業責任者が公開を承認するケースを考えます。会社サイトはWordPressで、CMSの更新・バックアップ・復元は既存の保守会社がまとめて担当できる、という条件にします。
| 決める項目 | この例での決定 | 理由 |
|---|---|---|
| 記事を置く場所 | 今のWordPress内のexample.com/blog/ | 別のCMSを必要とする機能がなく、保守も共通でよい |
| 執筆と承認 | 広報が下書き、事業責任者が内容を確認して公開 | 分けたいのは作業権限と承認。実装前に利用中CMSの権限でこの運用ができるかを確かめる |
| 更新と復旧 | 既存の保守会社。会社側の窓口は事業責任者 | 記事担当がテーマやCMS本体を更新しない。復旧を頼む先も一本にする |
| 今回採らない案 | サブドメインに別WordPressを新設 | この条件では独立した保守・バックアップを増やす必要がない |
ここで「ブログのCMSと更新日程を別の制作会社に任せ、障害時もブログだけで復元する必要がある」という条件が加わるなら、選択を見直します。その場合はblog.example.comへ別CMSを置く案を検討し、会社側はDNS・HTTPSの管理、ブログの制作会社はCMSの保守・バックアップ・復元、広報は記事更新、という分担まで書きます。同じパスへ別CMSを置く案は、経路の設定と障害対応を双方が引き受けられない、という条件なら見送ります。
二つの選択を分けたのは、チーム名の違いではなく、CMS本体の更新と復旧まで独立させる必要があるかどうかです。これは設計の記入例で、構築済みの事例や、URLを分けるだけで障害の影響を隔離できるという保証ではありません。
CMSより先に、更新と復旧の担当を決める
候補が決まったら、次の質問へ具体的な担当者名や契約範囲を書きます。
- 新規記事、既存記事、メニューを誰が変更できるか。
- プラグインやテーマ、CMS本体の更新を誰が確認するか。
- 更新に失敗したとき、どのバックアップへ誰が戻せるか。
- ドメイン、DNS、HTTPSの設定と契約更新を誰が管理するか。
- ブログからサービスページへ進むリンクを誰が点検するか。
「別サーバーなので安全」「同じドメインなので全部自動でつながる」といった言い切りは避けます。管理権限、認証、ネットワーク構成、テーマの作り方などによって実際の状態が違うからです。URLの見た目だけでセキュリティやデータ連携を判断しないでください。
読者には、一つの事業として迷わず使えるようにする
サブドメインで分けても、会社サイトとブログの関係が分からなければ、初めて訪れた人は戸惑います。ロゴやサイト名、著者紹介、メニュー、サービスへのリンクなどで、どの事業の情報なのかを示します。
一方、同じサブディレクトリでも、記事が孤立していれば必要なページへ進めません。たとえば料金を調べる人向けの記事なら、料金の条件を詳しく説明するページへのリンクが役立ちます。どの構成でも、関連する記事を行き来できる設計が必要です。
既存ブログは、形をそろえるためだけに移転しない
すでに公開している記事のURLを変えるなら、移転先の対応表、リダイレクト、内部リンク、画像、サイトマップなどの確認が必要になります。GoogleのURL変更を伴うサイト移転の案内も、新旧URLの準備やクロール・インデックスの変化を含めた作業を説明しています。
「サブディレクトリに変えれば必ず評価が集まる」という理由だけで、安定して更新できているブログのURLを変えるのは勧めません。運用上の問題があるなら、その問題を移転で解決できるか、今の構成を直す方がよいかを比べます。
たとえば、別CMSの保守契約が終了する、二重入力が頻発する、記事とサービスの関係が分かりにくい、といった具体的な課題を一つ書いてください。その課題を解決する構成と、移行作業に必要な人・費用・復旧方法を確認できてから進めます。
新規なら、無理なく更新し続けられる最小構成へ
同じCMS、同じ担当、同じ事業のブログなら、まず一体で管理できる構成を検討します。別CMSや独立した管理権限が必要なら、サブドメインも含めて比べます。どちらを選ぶにしても、記事が増えた後の更新、リンク、計測、復旧まで担当を決めておくことが大切です。
URLの形を正解探しで決めるのではなく、自分たちの作業を一つずつ当てはめてください。書いた記事を迷わず公開し、変更があったときに直せる構成が、事業ブログの土台になります。