WordPressサブドメイン入門｜失敗しない設定手順と注意点まとめ

2026年2月25日

「ブログを別に立ち上げたいから、サブドメインを使うのが良さそう」
そう思って調べ始めたものの、こんな不安や疑問で手が止まっていませんか？

「サブドメインって、結局どこで作るの？サーバー？ DNS？どっちが先？」
「設定したのに表示されない…DNSが反映してない？それともSSL？」
「サブドメインにするとSEO的に不利って聞いたけど、本当？」
「サブディレクトリと何が違うの？どっちを選べば後悔しない？」
「WordPressを入れる方法が複数あるみたいだけど、初心者はどれが安全？」
「移行したいけど、301リダイレクトや正規化って何をどうすれば…？」

サブドメインは、目的に合えばとても便利です。
たとえば「企業サイト＋ブログ」「サポートページ」「キャンペーン用LP」「検証（ステージング）環境」など、役割を分けることで運用がスムーズになります。

一方で、順番を間違えると

表示されない・SSLが効かない
管理画面に入れない（リダイレクトループ）
旧URLが残って重複扱いになる
計測やSearch Consoleが混乱する

といった“よくある事故”が起きやすいのも事実です。

この記事では、初心者でも迷わないように、目的の決め方 → 選び方 → 設定手順 → 運用の注意点を、つまずきポイントを先回りしながら整理します。

「とりあえず作ってみたけど不安」でも大丈夫。
読み終える頃には、あなたの状況に合う構成が分かり、失敗しにくい手順でサブドメインを安全に運用できる状態を目指せます。

サブドメインを最短で理解する

サブドメインの仕組みとURLの見え方

サブドメインは、同じドメインの「別入口（別サイトの住所）」を増やす仕組みです。
たとえば example.com を持っているとき、blog.example.com や support.example.com のように、左側に文字列を足して作れます。

まずはURLの部品をざっくり掴むと迷いません。

スクロールできます

例	どこが何？	意味
`https://blog.example.com/guide/`	`https://`	通信の方式（暗号化＝https）
	`blog`	サブドメイン（用途ごとに分けるラベル）
	`example.com`	ルート（メイン）ドメイン
	`/guide/`	ディレクトリ（サイト内の階層）

WordPressでサブドメインを使う場合はシンプルで、「サブドメイン（DNSで作る）→ その場所にWordPressを置く」だけです。

自分のサーバーに blog.example.com を作って、そこにWordPressをインストールする
あるいは、WordPress.comなど外部サービスに、サブドメインを向ける（DNSで紐付ける）

ポイントは、サブドメインはWordPressの機能ではなく、ドメイン（DNS）の設定で生まれるということ。
WordPressは「その住所に置かれる中身（サイト）」という立ち位置です。

よくある利用例（ブログ／ショップ／サポート／テスト環境）

サブドメインが便利なのは、目的がはっきり違うものを分けたいときです。代表例をまとめます。

ブログ（blog.example.com）
会社サイト本体と、読み物コンテンツを分離して運用したい
ショップ（store.example.com）
ECだけ別システム（Shopify等）で動かす／決済や機能要件が違う
サポート（support.example.com）
FAQ・ヘルプセンター・チケット管理など、役割がまったく別
テスト／検証環境（stg.example.com や dev.example.com）
本番に影響させずに、テーマ変更やプラグイン検証をしたい
国・言語別サイト（en.example.com など）
多言語を“別サイト単位”で管理したい（運用体制が分かれる場合に特に）

初心者が失敗しにくいコツは、「何を分けるか」を先に決めてから名前を付けることです。
後から用途がブレると、サイト構造も運用もグチャっとなりがちです。

「別サイト扱い」になりやすい理由をかみ砕いて説明

サブドメインは、見た目が似ていても、実務上は“別サイトとして管理する場面が多い”のが特徴です。理由は大きく3つあります。

検索エンジン側の「サイトの単位」がサブドメインになることがある
Googleの一部の仕組みでは、「サイト」はドメインまたはサブドメイン単位で扱われます。
そのため、同じ example.com 配下でも、blog.example.com は“別枠”として処理されるケースがあります。
計測・設定が分かれやすい
サブドメインを増やすと、アクセス解析やSearch Consoleなどで
「どこまでを同じサイトとして集計するか」を意識して設計する必要が出ます。
- 例：example.com と blog.example.com をまとめて見たいのか
- それとも、別々に成果を測りたいのか
中身（テーマ・目的）が違うほど「別物」と判断されやすい
検索エンジンは、同じ会社のサイトかどうかよりも、
「ユーザーにとって同じ目的のまとまりか」を重視します。
- 本体：会社概要・サービス紹介
- サブドメイン：EC、ヘルプ、コミュニティ、開発者向け…

このように役割が違うほど、結果的に“別サイトっぽい”扱いになりがちです。

覚えておくと迷わない結論

サブドメインは「同じドメインの別住所」。用途で切り分けるのに強い
ただし運用・計測・SEOの設計は、別サイトを1つ増やすくらいの意識が安全
「一体運用で育てたい（評価や導線を集約したい）」なら、サブディレクトリも候補になる

まず結論：どれを選ぶべきかの判断基準

サブドメイン・サブディレクトリ・新規ドメインの選び方

まず3つの違いを、「住所の分け方」として理解すると迷いません。

サブドメイン：blog.example.com（別入口を増やす）
サブディレクトリ：example.com/blog/（同じ入口の中で部屋を増やす）
新規ドメイン：example-blog.jp（別の建物を建てる）

初心者が判断するときは、次の表から入るのが早いです。

スクロールできます

やりたいこと（目的）	まずの第一候補	理由	気をつける点
本体サイトと同じテーマで、集客や評価をまとめたい	サブディレクトリ	ひとつのサイトとして運用しやすい	構造が大きくなると管理が複雑化
役割が明確に別（ショップ／サポート／会員機能など）	サブドメイン	目的別に分離でき、技術や運用も切り替えやすい	“別サイト感”が出やすく育成が別作業になりがち
事業やブランドが別物、リスクも分けたい	新規ドメイン	炎上・評価・運用を完全分離しやすい	立ち上げ直後はゼロから積み上げが必要

迷ったら、次の3問診断でかなり整理できます。

「本体サイトと同じ人に向けて、同じテーマで書く？」
→ YESならサブディレクトリ寄り
「仕組みが違う（EC、ヘルプデスク、アプリ、コミュニティなど）？」
→ YESならサブドメイン寄り
「ブランドや責任範囲を分けたい（別会社・別事業・別ターゲット）？」
→ YESなら新規ドメイン寄り

補足：SEOについては「絶対にどれが勝つ」と断言しにくい一方で、実務では “まとめて育てたいならサブディレクトリが扱いやすい／分けたいならサブドメイン” という設計思想がブレにくいです。
また、Googleの一部機能では“サイト”がドメインまたはサブドメイン単位で扱われる前提が明記されています。

テーマの関連性で決める（近い／遠い）

ここはSEOだけでなく、ユーザー体験（迷子を作らない）にも直結します。

テーマが近い（同じ悩み・同じ購買導線）なら、まとめるのが強い

例：企業サイト（サービス紹介）＋ノウハウ記事（集客）
- サブディレクトリ：example.com/blog/ が相性良い
- 理由：記事→サービスへの導線が自然で、サイト全体の設計も一体化しやすい

テーマが遠い（目的が別、検索意図が別）なら、分けるメリットが出る

例：本体（BtoBサービス）＋サポート（FAQ／手順／障害情報）
- サブドメイン：support.example.com が相性良い
- 理由：情報設計・UI・必要な機能が違い、運用担当も分かれやすい

判断をさらに具体化するために、「近い／遠い」チェックを置いておきます。

近い（統合向き）
- 同じ検索意図の延長線で読まれる
- 同じCTA（問い合わせ・資料請求・購入）につなげたい
- メニューや内部リンクを強くつなぎたい
遠い（分離向き）
- 読者層が違う（顧客向け vs 求職者向けなど）
- 必要機能が別（会員・決済・チケット管理など）
- デザインや情報量が別物（軽いヘルプ、重いコーポレートなど）

管理コスト・運用体制（更新担当・権限・工数）で決める

初心者が後で困るのがここです。
「作る」より「回す」が長いので、運用の現実で決めるのが失敗しにくいです。

サブドメインが増えると増えやすいコスト

WordPressをサブドメインごとに別インストールする場合、ざっくり次が“サイト数分”かかります。

更新作業が倍化
コア更新／テーマ更新／プラグイン更新／動作確認
セキュリティ管理が倍化
ログイン保護、権限設計、バックアップ、復元テスト
設定や計測の管理が増える
Search Console・解析・タグ・広告計測などの整合性チェック

「サイトを分けたい」気持ちは正しくても、運用が回らないと結局どちらも弱くなります。

体制でのおすすめ（ざっくり）

1人運用／少人数で更新頻度も限られる
→ サブディレクトリが無難（運用対象を増やしすぎない）
担当者や権限を分けたい（サポート担当・開発担当・編集チームなど）
→ サブドメインが便利（責任範囲が明確）
会社やブランドごと完全に別管理（方針・炎上リスク・法務責任も別）
→ 新規ドメインが安全（完全分離）

迷ったときの“落としどころ”設計

「今は小さく、将来に備える」なら、次の発想が使えます。

最初はサブディレクトリで育てる（運用が軽い）
役割がはっきり分かれた段階で、サブドメインに切り出す（分離の合理性が出てから）

この順番だと、最初から管理対象を増やしすぎずに済みます。

SEOへの影響を誤解なく整理する

評価の伝わり方と「別扱いになりやすい」ポイント

サブドメインは、検索エンジンの仕組み上、「同じドメインの仲間」ではあるものの、運用によっては“別サイト”のように扱われやすい存在です。

初心者が押さえるべき誤解しやすい点はこの3つです。

評価は“自動で共有される”とは限らない
メインドメインで積み上げた実績が、サブドメインへそのまま移るとは限りません。
サブドメイン側はサブドメイン側で、内容・被リンク・内部導線・更新の継続が必要になりやすいです。
「サイトの単位」がサブドメインで区切られる場面がある
たとえば検索結果の“サイト名”の扱いなど、ドメイン／サブドメインが単位として扱われる仕様があります。
これは「別扱いになりやすい」感覚を強める要因になります。
テーマ（検索意図）が離れるほど、別サイトに見えやすい
example.com が企業サイト、support.example.com がヘルプ、store.example.com がEC…のように役割が分かれるほど、検索エンジンにもユーザーにも「別物」に見えやすいです。

結論として
サブドメイン運用は「SEO的にダメ」ではありません。ただし、“分けるメリット”と引き換えに、育成と管理が増えると理解しておくのが安全です。

同一ドメイン配下で起きる可能性があるリスク

サブドメインは「分けられる」反面、設計を誤るとマイナスが出やすいです。ありがちなリスクを、初心者向けに整理します。

カニバリ（同じキーワードで身内が競合する）
メインサイトとサブドメインで似た記事が増えると、どちらを上げたいのかが曖昧になります。
→ 対策：狙うテーマを明確に分担し、重複ページを作らない
重複・正規化のミス（同じ内容が複数URLに残る）
テスト環境（stg）を公開状態にしたり、コピーサイトを残したままにすると危険です。
→ 対策：検証用は noindex、Basic認証、アクセス制限を基本に
品質差でブランド評価が割れる
サブドメイン側が薄い内容・更新停止・広告過多だと、ユーザー体験が崩れます。
→ 対策：最低限、運用できる量に絞る（増やし過ぎない）
計測・設定の分断で改善できなくなる
「どのSearch Consoleを見ればいい？」「どのGA4の数字？」となりがちです。
→ 対策：後述のとおり、全体＋個別の二段構えにする

内部リンク・ナビゲーションで迷子を作らない設計

サブドメインを使うなら、SEO以前にユーザーが迷わない導線が最重要です。
設計のコツは「行き来はできるが、押しつけない」です。

基本設計（迷子を作らないための型）

グローバルナビの役割を固定する
例：
- 企業サイト：サービス理解・問い合わせ
- ブログ：学習・比較・事例
- サポート：解決・手順・障害情報
  役割が違うのに、同じナビを無理に共通化すると迷子が増えます。
ヘッダー／フッターは“最短リンク”だけ置く
サイト全体で共通の導線（例：会社情報、問い合わせ、主要カテゴリ）だけに絞るとスッキリします。
サブドメイン間の遷移は“目的が自然につながる場所”に置く
例：ブログ記事の末尾に「詳しい使い方はサポートへ」
例：サポートのFAQに「背景知識はブログへ」
→ こうするとユーザーにも検索エンジンにも納得感が出ます。

相互リンクを貼るときの考え方（やり過ぎ注意）

サブドメイン同士の相互リンクは、やり方次第で良くも悪くもなります。
やり過ぎを避ける判断軸は次のとおりです。

やっていい相互リンク（自然）

記事・FAQの文脈上、本当に次に読むべきページを案内している
アンカーテキストが不自然にSEOっぽくない（文章として自然）
クリックした人が「助かった」と感じる導線になっている

避けたい相互リンク（不自然）

全ページに同じキーワードリンクを大量設置（サイトワイドでの押し込み）
目的が違うのに、無理に相互送客している
“リンクのためのページ”が増える（薄いまとめや中身のない誘導記事）

目安としては、「リンクは“便利な案内板”」。
順位目的が先に立つと、構造が崩れやすいです。

Search Console／サイトマップ／計測の持ち方

ここを整えるだけで、サブドメイン運用の失敗が大幅に減ります。
おすすめは 「全体を俯瞰できる設定」＋「サブドメインを個別に追える設定」 の二段構えです。

Search Consoleのおすすめ構成

Domainプロパティ（全体俯瞰）
example.com のように登録すると、サブドメインやhttp/httpsも含めて全体を見やすいです。
URLプレフィックス（個別管理）
https://blog.example.com/ のように、サブドメイン単位で登録すると、
インデックス状況・問題の切り分けが楽になります。

「どっちかだけ」にすると、あとで混乱しやすいので、初心者ほど二段構えが安定です。

サイトマップの考え方（基本だけでOK）

サブドメインのURLは、基本的に そのサブドメインのサイトマップで管理するのが安全
WordPressは通常、/sitemap.xml などで自動生成されます（環境により異なる場合あり）
Search Consoleの「サイトマップ」から送信して、エラーが出ないか確認する

アクセス解析（GA4など）の持ち方

「全体で成果を見る」なら：同一プロパティでまとめて計測
「サブドメイン別に改善する」なら：レポートや探索でホスト名（hostname）等で分けて見る／必要に応じてデータストリームを分ける

ここまで作っておけば、サブドメイン運用でありがちな
「数字が合わない」「どこが落ちたのかわからない」事故を避けやすくなります。

サブドメイン名を決める前にやること

用途を固定する命名（後で困らない設計）

サブドメイン名は、いちど公開すると URL・被リンク・ブックマーク・共有リンクに広く残ります。
後から変えると移行やリダイレクトが必要になり、手間もリスクも増えるので、先に「用途」を固定してから命名するのが鉄則です。

まず決めるべきこと（最小セット）

そのサブドメインは「何のため」か（ブログ／サポート／ショップ／検証など）
公開用か、非公開の検証用か（ここを曖昧にすると事故が起きやすい）
将来増やす可能性（今後 help 以外も増えそう？）

初心者におすすめの命名ルール

用途が一目でわかる短い英字にする（例：blog / support / store / docs）
ハイフンは最小限（読み間違い・打ち間違いが増えやすい）
日本語（Punycode）や妙に長い単語は避ける（共有・入力・見た目で不利）
“一時用途”っぽい名前を本番に使わない（例：new / test2 など）

よくある命名パターン（用途別）

スクロールできます

用途	例	補足
読み物・集客	`blog.example.com`	記事が増える前提なら運用設計が重要
ヘルプ・FAQ	`support.example.com` / `help.example.com`	検索されやすい言葉を優先
ドキュメント	`docs.example.com`	開発・操作マニュアルに相性が良い
EC	`store.example.com`	決済や外部サービス連携と相性が良い
検証	`stg.example.com` / `dev.example.com`	基本は非公開運用（下で触れます）

検証用サブドメインだけは例外的に“守り”を優先

検証（stg / dev）は、検索に出たり第三者に触られると危険です。最低限、次のどれかを入れてください。

Basic認証（ID/PW）
IP制限（社内・自分だけ）
noindex（検索に出さない設定）

「名前」だけ決めて先にDNSを作る人も多いですが、検証用途は特に、公開のまま放置が起きやすいので注意です。

DNSの管理場所を確認する（どこで設定するか）

サブドメインはWordPressの画面では作れません。DNS（ドメインの設定）側で作ります。
ここで初心者がつまずく原因はシンプルで、“どこがDNSの管理画面なのか分からない”ことです。

DNSの管理場所はだいたい3パターン

ドメインを買った会社（レジストラ）のDNS
レンタルサーバー側のDNS（サーバー契約でDNSも管理している）
Cloudflareなど外部DNS/CDNのDNS

見分け方は簡単で、ドメインの ネームサーバー（NS） がどこを指しているかで決まります。
NSが指している先が「いまのDNS管理者（権威DNS）」です。

確認しておくチェックリスト（ここだけ押さえればOK）

今のDNSはどこで管理している？（NSで判断）
example.com のDNSと同じ場所で、blog.example.com のDNSも設定できる？
サブドメインの向き先はどれ？
- サーバーのIPに向ける → A/AAAAレコード
- 既存ホスト名に向ける → CNAMEレコード

CNAMEを使うときの注意（地味にハマりやすい）

CNAMEは「別名」を作る仕組みなので、同じ名前に他のレコードを置けないなど制約があります
目的（サーバー直指定か／外部サービス連携か）に合わせて選ぶのが安全です

SSL（https）をどう用意するか

サブドメインをWordPressで運用するなら、HTTPSは実質必須です。理由は2つあります。

ブラウザはHTTPに警告を出すことがあり、信頼性を落としやすい
Googleは以前からHTTPSをランキング要素の1つとして扱う方針を示しています

ここで大事なのは、証明書は「ドメインごと」ではなく「ホスト名ごと」という点です。
つまり、example.com の証明書があっても blog.example.com は別途カバーされている必要があります。

まず押さえる証明書の種類（迷ったらこれだけ）

単一ホスト：blog.example.com だけ
複数ホスト（SAN）：blog.example.com と store.example.com をまとめて
ワイルドカード：*.example.com（配下のサブドメインを広くカバー）

サブドメインを増やす予定があるなら、最初から「どう増えるか」を考えておくと、あとで証明書が増殖して管理が大変…を避けられます。

ワイルドカードの現実的な注意点

ワイルドカードを無料で取れるケースもありますが、一般に DNSで所有確認（DNS-01）が必要になりやすく、DNS事業者側の設定や反映待ちが絡みます。
初心者はまず「サーバーの無料SSL機能で、対象サブドメインにもSSLを付けられるか」を確認するとスムーズです。

無料SSLで足りるケース／有料SSLが必要になりやすいケース

結論から言うと、ほとんどのブログ・企業サイト・小規模サイトは無料SSLで十分です。
ただし、要件によっては有料SSLが選択肢になります。

無料SSLで足りるケース（多くの人はここ）

ふつうのWordPressサイト（ブログ、サービス紹介、オウンドメディア）
問い合わせフォームがある程度（HTTPSで暗号化される）
コストを抑えつつ、常時HTTPSを実現したい
証明書更新をできるだけ自動化したい（サーバー側の自動更新が使える環境）

有料SSLが必要になりやすいケース（要件主導）

取引先や社内規定で OV/EV証明書（組織実在確認）が求められる
金融・医療・大企業案件などで、監査・証跡・契約上の要件が強い
多数のサブドメインや特殊構成で、運用サポートや保証を重視したい
証明書の発行・管理を「特定ベンダーで統一」する必要がある

初心者が一番やりがちな落とし穴：HTTPS化したのに“完全に安全”になっていない

画像やCSSがHTTPのまま → “保護されていないコンテンツ”扱い（Mixed Content）
http:// と https:// が両方生きている → 重複・転送ループの原因

サブドメインでも、最終的に 常時HTTPS（http→httpsへ統一） までセットで考えるのが安全です。

サブドメインを作成する手順（共通フロー）

サーバー側でサブドメインを追加する

サブドメイン作成は、ざっくり言うと次の流れです。

サーバー管理画面で「サブドメイン」を追加する
サブドメインの公開フォルダ（ドキュメントルート）を決める
そのフォルダにWordPressを置ける状態にする（空フォルダでもOK）

レンタルサーバーの種類が違っても、だいたい同じ項目が並びます。

サブドメイン名（例：blog）
ドメイン（例：example.com）
ドキュメントルート（例：/public_html/blog/ など）
PHPバージョン（選べる場合）
SSL設定（ここでは“後で有効化”でもOK）

公開フォルダ（ドキュメントルート）を分ける

ここが一番重要です。
サブドメインは「別入口」なので、入口ごとに入るフォルダも分けるのが基本です。

おすすめ（安全）

example.com → /public_html/
blog.example.com → /public_html/blog/
support.example.com → /public_html/support/

避けたい（事故りやすい）

サブドメインを本体と同じフォルダに向ける
→ 既存サイトの上書き、表示崩れ、意図しない公開につながりやすい

さらに、検証用（stg / dev）を作るなら、フォルダを分けたうえで、

Basic認証
IP制限
noindex

のいずれか（できれば複数）を最初から入れて、“公開しっぱなし”を防ぐのが安全です。

反映までの確認手順（疎通チェック）

サーバー側の追加が終わったら、「フォルダが正しく見えているか」を先に確認します。
DNSがまだでも、サーバー側の準備ができていれば、後がラクになります。

チェックのコツ（順番が大事）

① サブドメイン追加後、管理画面に「作成済み」と表示されているか
② ドキュメントルートに、仮のファイルを置いてみる
- 例：index.html を置いて “接続テスト” 用の短文を入れる
③ DNS設定後、ブラウザでアクセスして表示確認する
④ 表示できたら、WordPressをインストール（または移行）する

ここでよくある勘違い
DNSが反映する前にアクセスしても、表示されないことがあります。
その場合は「失敗」と決めつけず、次のDNSチェックへ進むのが正解です。

ドメイン側でDNSレコードを設定する

次に、サブドメイン（例：blog）がどこへ行くかをDNSで決めます。
ここは「どこでDNSを管理しているか（ネームサーバー）」によって、操作する画面が変わります。

やること自体はシンプルです。

blog のレコードを追加する
“向き先（サーバー）”を指定する
TTL（キャッシュ時間）を確認する

A／CNAMEの使い分け

初心者が迷いやすいので、結論から整理します。

Aレコードを選ぶケース（IPアドレスへ直行）

サブドメインを サーバーのIPアドレスに向けたい
自分のレンタルサーバー（固定IPが案内されている）で運用することが多い

CNAMEを選ぶケース（別のホスト名へ転送）

サブドメインを 別のホスト名（FQDN）に向けたい
外部サービス連携（例：ホスティング／CDN／SaaS）で指定されることが多い

覚え方

A = 数字（IP）へ向ける
CNAME = 文字（ホスト名）へ向ける

CNAMEの重要な注意点（初心者がハマりやすい）

同じ名前（例：blog）に CNAMEと他のレコードを混在させないのが原則です
（「二重に設定したつもりはないのに挙動が変」になりやすい）

よくある設定ミス（向き先違い・二重設定・TTL）

失敗の多くは「設定そのもの」より、見落としで起きます。
下の表を“チェックリスト”として使ってください。

スクロールできます

症状	ありがちな原因	直し方（最短）
ずっと表示されない	向き先（IP/ホスト名）が間違い	サーバー側の案内値と一致しているか再確認
自分だけ見える／他人は見えない	TTLやキャッシュが残っている	時間を置く／別端末・別回線で確認
たまに別のページが出る	古いDNSが残っている、二重設定	DNS管理場所を一本化し、古いレコードを削除
Cloudflare等で“プロキシ有効”にして不具合	まだSSLやサーバー準備が未完了	まずDNSのみ（DNS only）で疎通→安定後に切替
反映が遅い	TTLが長い（例：4時間など）	変更前にTTLを短く→変更→安定後に戻す

TTLの考え方（これだけ覚えればOK）

TTLは「その情報が各所にキャッシュされる時間」です
DNS側の変更は比較的すぐ反映しても、古い情報がTTLの間だけ残ることがあります
“急いで切り替えたい日”は、事前にTTLを短くしておくと安全です

サブドメインにWordPressを入れる2つの方法

サブドメインにWordPressを入れるやり方は、大きく次の2つです。

方法A：サブドメインごとにWordPressを別インストール（いわゆる“複数サイトを別々に運用”）
方法B：WordPressマルチサイトでまとめて運用（“1つのWordPressで複数サイトを束ねる”）

どちらが正解、というより 「管理したい単位」で決めるのが失敗しにくいです。

方法A：サブドメインごとにWordPressを別インストールする

方法Aは、blog.example.com 用にWordPressを1つ、support.example.com 用にもう1つ…というように、サブドメイン＝別WordPressで構築するイメージです。

マルチサイトと違い、各サイトは完全に独立します。
その分、更新や保守は“サイト数分”増えます。

データベース作成・初期設定・ログインまで

流れは「いつものWordPressインストール」をサブドメインでやるだけです。

手順（初心者向けの最短ルート）

サブドメインの公開フォルダを用意（例：/public_html/blog/）
データベースとユーザーを作成（DB名・ユーザー名・パスワードを控える）
WordPress一式をアップロード（または自動インストール機能を使う）
インストール画面を開く
https://blog.example.com/ にアクセス → 画面の案内どおりに進める
管理画面にログイン
https://blog.example.com/wp-admin/

ここでつまずきやすいポイント（先回り）

DB情報を控え忘れる → 後で探すのが地味に大変
同じDBに複数WPを入れてしまう → 事故が起きやすい
- どうしても同じDBを使うなら、テーブル接頭辞を分ける必要があります（初心者は避けるのが無難）
URLが http のまま → SSL設定後にログイン不具合が出ることがある
- 最初から https で運用する前提で進めるのが安全です

小さなチェックリスト（この3つが揃えばOK）

サブドメインでトップが表示できる
wp-admin に入れる
サイトURLが https://サブドメイン/ になっている

テーマ／プラグイン／キャッシュの初期方針

方法Aは自由度が高い反面、初期の方針がないと“プラグイン増殖”しがちです。
最初に次の考え方で揃えると、後がラクになります。

テーマ方針（迷ったらこれ）

見た目を寄せたい → 同じテーマ＋子テーマで微調整
役割が違う（ブログとサポート等） → テーマも分ける（UI最適化を優先）

プラグイン方針（入れ過ぎ防止の型）

共通で必須：SEO／セキュリティ／バックアップ（必要最小限）
サイト固有：お問い合わせ、会員、ECなど“目的に直結するものだけ”
「便利そう」で追加しない
→ プラグインは増えるほど、更新・不具合調査のコストが増えます

キャッシュ方針（初心者が事故らない順）

まずはサーバー側キャッシュ（提供されているならそれを優先）
次にページキャッシュ系プラグイン（必要になってから）
高負荷ならCDNやオブジェクトキャッシュを検討

方法Aの強み（運用目線）

片方の不具合が、もう片方に波及しにくい
サイトごとにプラグインや設定を自由に変えられる
「やめたい／移したい」が比較的簡単（移行単位が明確）

方法B：WordPressマルチサイトでまとめて運用する

方法Bは、1つのWordPress（コアファイル）で複数サイトを管理する方式です。
ネットワーク全体で テーマやプラグインを共有できる一方、管理ルール（権限）や制約が増えます。

マルチサイトでは、サイトは“仮想的に分かれた別サイト”として存在し、アップロード領域やデータベースはサイトごとに区切られます。

向くケース／向かないケース

向くケース（まとめる価値が大きい）

サイトが複数あり、共通のテーマ・共通の機能で揃えたい
更新やセキュリティ対応を できるだけ一括で回したい
ユーザーや運用ポリシーを“ネットワーク全体”で統制したい

向かないケース（後で苦しくなりやすい）

サイトごとに使いたいプラグインや設定が大きく違う
担当者ごとに「自由に追加・変更」したい（権限分離を厳密にしたい）
いずれサイトを売却・分社化・完全分離したい可能性が高い

ハマりやすい制約（プラグイン・権限・移行難易度）

初心者が「思ったより難しい」と感じるのは、だいたいここです。

権限のクセ（ここが重要）

マルチサイトでは、通常の管理者より上位に ネットワーク管理者（Super Admin）がいます
サイト管理者は、テーマやプラグインを“有効化”できても、新規インストールはできないなど権限が制限されます

プラグイン相性の問題

“マルチサイト対応”を前提に作られていないプラグインもあります
ネットワーク全体に影響する設定があるため、導入前の検証が必須になりやすいです（特にキャッシュ系・会員系・EC系）

サブドメイン型にしたいときの前提

ネットワーク構成で「サブドメイン型」を選ぶ場面があり、環境によってはDNS・サーバー側の条件が絡みます
公式ドキュメントでも、サブドメイン型に関する注意（警告表示や、必要になるケースがあること）が説明されています

移行の難易度（後で効いてくる）

“ネットワーク全体”で構造がつながるため、サイトを1つだけ切り出す・引っ越すといった作業が、方法Aより複雑になりやすいです
逆に、最初から「ずっとまとめて運用する」前提なら強力です

どっちにするか迷ったときの早見表

スクロールできます

観点	方法A：別インストール	方法B：マルチサイト
最初の分かりやすさ	かんたん（通常のWPと同じ）	やや難しい（ネットワーク概念が増える）
自由度	高い（サイトごとに好きにできる）	ルールが増える（統制しやすい）
運用コスト	サイト数に比例して増えやすい	一括管理しやすい反面、影響範囲が広い
権限設計	サイトごとに完結	Super Admin中心になりやすい
トラブル時の影響	片方だけ止まりやすい	ネットワーク全体に波及しやすい
将来の分離・売却	やりやすい	やや難しくなりやすい

初心者のおすすめ（現実的な結論）

まず迷ったら 方法A（別インストール）が無難です。理解しやすく、失敗しても巻き戻しやすいからです。
「同じ型のサイトを量産して一括管理したい」「運用統制が必要」という要件が固まっているなら 方法B（マルチサイト）が刺さります。

既存サイトをサブドメインへ移す手順（失敗しやすい所を先回り）

移行設計：URL構造・公開タイミング・戻し方を決める

移行で一番大事なのは、作業に入る前の「設計」です。ここが曖昧だと、SEOも表示もぐちゃっとなりやすいです。

最初に決める3点（これだけは紙に書く）

何をどこへ移すか（範囲）
- サイト全体を https://blog.example.com/ に移すのか
- 一部（例：ブログだけ）を移して、本体 example.com は残すのか
URLの対応表（旧→新）
“できるだけ同じパスで移す”のが基本です。
例：https://example.com/guide/aaa/ → https://blog.example.com/guide/aaa/
戻し方（ロールバック）
失敗したときに戻せるように、最低限これを用意します。
- 移行前のフルバックアップ（ファイル＋DB）
- DNSやリダイレクト設定の元の状態メモ
- “戻す判断ライン”（例：決済やフォームが直らない／重大な404が多発など）

公開タイミングのおすすめ（初心者向けに安全）

まず stg.example.com などの検証環境で、移行後の見た目・リンク・計測を確認
次に本番サブドメインへ反映
公開直後は更新を控えめにして、エラー潰しを優先

データ移行の進め方（プラグイン／手動の選択）

移行は「プラグインで丸ごと」か「手動でコピー」の2ルートがあります。迷ったら、下の基準で決めると失敗しにくいです。

スクロールできます

選び方	プラグイン移行が向く	手動移行が向く
操作のわかりやすさ	画面で完結しやすい	手順が多いが理解が深まる
サイト規模	小〜中規模で安定しやすい	大規模でも調整しやすい
制約	サーバー容量・実行時間に左右されることがある	権限（SSH/DB操作）前提になりやすい
再実行	やり直しやすい	慣れると確実だが慎重さが必要

どちらでも共通の鉄則

移行前にバックアップ
新サブドメイン側で先にSSL（https）を使える状態にする
公開前に “リンク切れ・画像・フォーム・ログイン” を点検する

DB内URLの置換で事故らないコツ

サブドメイン移行で初心者が最も壊しやすいのが、DBに保存されたURLの置換です。
WordPressのDBには、記事本文だけでなく、設定値やウィジェット、テーマ設定などにもURLが入り込みます。

事故パターン（代表例）

単純な置換で、シリアライズデータ（配列など）を壊して画面が真っ白
置換漏れで、画像だけ旧URLのまま（Mixed Contentや404の原因）
逆に置換し過ぎて、識別子まで変わる（例：GUIDなど）

安全に進めるコツ（手順）

まずWordPressの基本URLを新サブドメインへ
- 「WordPressアドレス（URL）」と「サイトアドレス（URL）」を https://blog.example.com に揃える
次にDB内の旧URLを、新URLへ置換
最後に、表示・画像・管理画面を確認

おすすめのやり方（壊しにくい）

WP-CLI の search-replace は、DBの置換でシリアライズデータを考慮して処理できます。
いきなり本番書き換えせず、まずは --dry-run で差分を確認すると安全です。
置換対象は最初は絞る（例：wp_posts / wp_postmeta / wp_options など）
迷うなら、guid のような列は置換対象から外す判断も有効です（必要なときだけ検討）

※ここは「早く終わらせたい」気持ちが一番危険です。小さく試して→問題がない範囲を広げるが正解です。

画像・CSSのhttps化（Mixed Content対策）

移行後によく起きるのが、ページ自体はHTTPSなのに、画像やCSSがHTTPで読み込まれる状態です。これが “Mixed Content（混在コンテンツ）” です。

よくある原因

記事本文に http:// の画像URLが残っている
テーマ設定（ロゴ・背景画像）に旧URLが残っている
外部スクリプト（計測タグ・広告タグ）が http:// のまま
キャッシュが残っていて、古い参照が出続けている

最短の潰し方（順番が大事）

① ブラウザの開発者ツール（Console）で “どのURLがhttpか” を特定
② DB置換で http:// → https:// を整理（必要なら）
③ WordPress内のメディアURL、テーマ設定、ウィジェットを点検
④ キャッシュ（サーバー／プラグイン／CDN）を削除して再確認

Mixed Contentは「放置すると勝手に直る」ことは少ないので、検出→原因のURLを潰すのが近道です。

301リダイレクトと正規化で評価を落とさない

SEO面で最優先は、旧URLを新URLへ正しく301でつなぐことです。
ここが弱いと、評価や被リンクが引き継がれにくく、検索流入が落ちやすくなります。

301設計の基本

旧URL → 対応する新URLへ“1対1”で転送
なるべく 同じパス構造を保つ
リダイレクトチェーン（A→B→C）を作らない
404に落とさない（特に流入が多いページ）

おすすめの作り方（迷わない）

まず、旧サイトでアクセスが多いページを一覧化
そのページだけでも先に 確実に301 を作る
次に、全体のルール（例：ドメイン部分だけ差し替え）を適用

http/https・www有無の統一

サブドメイン移行は、URLの「表記ゆれ」も増えがちです。

http://blog.example.com
https://blog.example.com
https://www.blog.example.com（環境によっては存在し得る）

この状態を放置すると、検索エンジンにもユーザーにも混乱が出ます。

統一の鉄則

正は 1つだけに決める（基本は https://blog.example.com）
それ以外は、すべて正へ 301で統一する

重複URLを残さない（検索エンジン向けの整理）

旧サイトが “残って見える” 状態は避けたいです。以下は典型的な重複パターンです。

旧URLのページが200で表示され続ける（＝移行したつもりが複製になっている）
新旧どちらにも同じコンテンツが存在する
カテゴリやタグ、アーカイブで似たページが量産される

対策（やることはシンプル）

旧URLは基本すべて 301で新へ
新サイト側は canonical（正規URL）を正しく出す（通常はWordPressが適切に出します）
新サイトのXMLサイトマップを送信し直す
検証用（stg/dev）を作った場合は noindex＋アクセス制限（ここが漏れると危険）

移行後チェックリスト（計測・インデックス・主要ページ）

移行は「切り替えた瞬間」ではなく、切り替え後の監視で成否が決まります。
初心者向けに、やるべき点検を“短い順”に並べます。

最初の30分（致命傷チェック）

トップ・主要カテゴリ・人気記事が表示される
画像が欠けていない／デザインが崩れていない
フォーム送信・決済・ログインなど重要導線が動く
wp-admin に入れる（管理画面が飛ばされ続けない）

当日中（SEOと計測の土台）

旧→新の301が意図通りか（主要URLで確認）
Search Consoleで 新サブドメインをプロパティ追加
新サイトマップを送信
主要ページがインデックス対象になっているかを監視

1〜2週間（落ち込みを最小化）

404（存在しないページ）増加の確認 → 重要ページから直す
リダイレクトの連鎖がないか確認
検索流入の主要クエリ／主要ページの動きの監視
内部リンクの旧URLが残っていないか（置換漏れ点検）

必要なら、Search Consoleの Change of Address（サイト移転） を使って移転を伝える選択もあります（旧サイト→新サイトの301が前提）。

運用を安定させる管理・セキュリティ

バックアップ設計（世代管理と復元テスト）

サブドメイン運用で一番怖いのは、トラブルそのものより 「戻せない」ことです。
バックアップは「取る」だけでは不十分で、世代管理と復元テストまでがセットです。

まず押さえるべき結論

バックアップ対象は ファイル と データベース の両方
保存先は 同一サーバー内だけに置かない（障害・乗っ取りで同時に失うため）
最低でも 1ヶ月以上の世代を持つ（気づくのが遅れる事故が多い）

何をバックアップする？（初心者の最短整理）

別インストール（方法A）の場合は、サブドメイン＝サイト数だけ対象が増えます。

ファイル：wp-content（テーマ・プラグイン・画像）＋必要ならWordPress本体
DB：そのサイトが使うデータベース（またはテーブル群）

マルチサイト（方法B）の場合は、基本は“ネットワーク丸ごと”が対象になります。

ファイル：wp-content（ネットワーク全体の資産）
DB：ネットワークのDB（サイトごとのテーブルも含むため、部分バックアップは要注意）

世代管理のおすすめ（例）

「どのくらい残す？」で迷う人が多いので、実務で扱いやすい例を置きます。

毎日：14世代（直近の事故に強い）
毎週：8世代（2ヶ月の巻き戻し）
毎月：12世代（長期の保険）

これをそのまま真似すると、“気づくのが遅い改ざん”にも対応しやすくなります。

保存先の鉄則（3つだけ）

同一サーバー外にもコピー（クラウドストレージ等）
権限を絞る（バックアップ先にサイトの認証情報を置きっぱなしにしない）
暗号化・鍵管理（可能なら。特に顧客情報を扱う場合）

復元テスト（ここが抜けがちで一番重要）

バックアップがあっても、復元できないケースは珍しくありません。
初心者でもできる、現実的な復元テストのやり方です。

おすすめ手順（30〜60分で終わる形）

検証環境（ステージング）を用意する
最新バックアップを 検証環境へ復元して表示確認
次を最低限チェックする
- トップが表示される
- 画像が欠けない
- 管理画面に入れる
- お問い合わせフォームが動く（テスト送信）

頻度の目安

月1回（最低ライン）
大型アップデート前後は必ず

ログイン防御（ID設計・二要素・権限）

ログイン周りは「やることが多そう」に見えますが、優先順位を付けるとシンプルです。
ここでは 効果が大きい順に並べます。

ID設計（アカウントの作り方で事故を減らす）

“admin”系のユーザー名を避ける
推測されやすく、攻撃の的になりやすいです。
管理者アカウントは 普段使いしない
記事更新用は編集者などに分けるのが安全です。
退職者・外注のアカウントは 放置しない
期限を決めて削除・権限剥奪します。

二要素（2FA/MFA）は「最優先で強い」

パスワードだけより、二要素（認証アプリ等）を追加した方が、突破されにくさが一段上がります。

導入の考え方は次の通りです。

まずは 管理者だけでも良い（いきなり全員強制でなくてOK）
復旧手段（バックアップコードなど）は 安全に保管する
“SMSだけ”に頼るより、認証アプリ等の方式が一般に扱いやすい

パスワードは「強さ」より「運用」で勝つ

初心者がやりがちなのが「複雑さルールで苦しむ」ことです。現実的には、

長め（例：12〜16文字以上）
使い回さない
パスワードマネージャーを使う

これだけで事故率がガクッと下がります。

権限（最小権限の原則）

サブドメイン運用はサイトが増える分、権限の事故も増えます。
以下の型にすると管理が楽になります。

管理者：保守・設定だけ（最小人数）
編集者：記事更新・公開
寄稿者：下書きまで

ポイント
「必要な操作ができる最小の権限」を、最初から役割で決めておくと、後から揉めません。

追加で効く防御（必要に応じて）

ログイン試行制限（ブルートフォース対策）
管理画面へのアクセス制限（IP制限、Basic認証）
不要ならXML-RPCを止める／制限する
WAF（ホスティングやCDN側の防御）を使う

全部を最初から盛るより、管理者の2FA＋権限整理を先に固める方が成功率が高いです。

本番／検証（ステージング）を分ける運用

サブドメイン運用と相性が良いのがステージングです。
「本番で試す」をやめるだけで、障害の確率が大きく下がります。

ステージングの基本形（初心者向け）

例：stg.example.com（本番のコピー）
目的：テーマ変更、プラグイン更新、設定変更の事前テスト

ただし、ステージングは 公開しないのが原則です。

最低限の守り

noindex
Basic認証 or IP制限
計測タグ（GA4等）は本番と混ぜない（混ざると数字が崩れます）

何をステージングで確認する？

“全部”を確認しようとすると回らないので、失敗が多い箇所に絞ります。

ログインできる
主要ページが崩れていない
フォーム送信・決済など重要導線が動く
速度が極端に落ちていない
エラーが出ていない（管理画面・ブラウザコンソール）

本番反映（事故らない手順）

おすすめの型はこれです。

本番のバックアップ（直前）
ステージングで更新・検証
反映は アクセスが少ない時間帯に
反映後は次をチェック
- トップ／主要ページ
- フォーム
- 管理画面
- 目立つエラー

サブドメイン運用ならではのコツ

サブドメインが複数あると、更新の当たり外れが出ます。
そこで、運用を「一括ルール化」すると安定します。

月2回など 更新日を固定（複数サイトを同じリズムで回す）
重要度の高いサブドメインから順に更新（影響が大きいものを先に検証）
不具合が出たら「戻す」を最優先（原因究明は落ち着いてから）

よくあるトラブル解決

表示されない（DNS・キャッシュ・SSLの切り分け）

「表示されない」は原因が幅広いので、上から順に“切り分け”すると最短で直せます。

まず確認すること（10分でできる）

URLは合っているか
blog.example.com と blogs.example.com のような打ち間違いが意外と多いです。
DNSが“どこで管理されているか”が一致しているか
ドメインのDNS管理（ネームサーバー）がA社なのに、B社のDNS画面をいじっている…が定番事故です。
DNSが反映途中ではないか（TTL/キャッシュ）
変更直後は、端末や回線によって見え方が違うことがあります。

DNSの切り分け（よくある詰まりどころ）

チェックポイント

Aレコードなら：サーバーのIPが正しいか
CNAMEなら：向け先ホスト名が正しいか
同じ名前（例：blog）に、A/CNAMEが二重に存在していないか
CDN（Cloudflare等）利用時：DNS only / プロキシ有効の状態で挙動が変わらないか

確認コマンド例（分かる人だけでOK）

nslookup blog.example.com
# または
dig blog.example.com A
dig blog.example.com CNAME

見たいのは「今どこに向いているか」です。
向き先が想定と違えば、WordPress以前の問題なので、DNSを直すのが先です。

サーバー側の切り分け（ドキュメントルート/設定ミス）

DNSが正しいのに表示されない場合、次が多いです。

ドキュメントルートが間違っている
サブドメインの公開フォルダが、本体と同じ場所や存在しない場所になっている。
サブドメインの受け口（バーチャルホスト）が作られていない
「DNSは向いたのに、サーバーが受け取れない」状態。

確認のコツ

ドキュメントルートに index.html を置いて、簡単な文字を表示できるかを先に確認
→ これで「DNS〜サーバーの入口」までが通っているか判断できます。

SSLの切り分け（httpsで開けない／証明書エラー）

症状はだいたい2つです。

証明書エラーが出る：そのサブドメインが証明書に含まれていない
httpは開くがhttpsは開かない：SSLが未設定、またはCDN/サーバーの設定不一致

よくある原因

example.com のSSLはあるが、blog.example.com が未カバー
Cloudflare等でSSLモードが合っていない（“柔らかい設定”がループや警告の原因になることも）

対処の優先順位

サブドメインにSSLを発行・適用（無料SSLでもOKなケースが多い）
http → https の統一は、SSLが安定してから入れる
キャッシュ（ブラウザ/サーバー/CDN）をクリアして再確認

管理画面に入れない／リダイレクトループ

この系統は原因が「URL設定」「SSL」「キャッシュ」「リダイレクト規則」に集中します。
“いきなり全部いじらない”のがコツです。

まずやること（被害を広げない）

シークレットモードで試す（Cookieの影響を外す）
キャッシュ削除（キャッシュ系プラグイン、サーバーキャッシュ、CDNキャッシュ）
別端末・別回線で再現するか確認（自分だけのキャッシュ問題を切り分け）

典型パターン1：URL設定がズレている

サブドメイン移行直後に多いです。

サイトURLが example.com のまま
http と https が混在している
www 有無が混在している

直し方の考え方

正しいURL（例：https://blog.example.com）を1つに決める
それ以外はすべて正へ寄せる（301や設定統一）

もし管理画面に入れない場合は、DBの siteurl / home がズレているケースもあります。
（手動修正はリスクがあるので、慣れていなければバックアップを取ってから）

典型パターン2：CDN/SSL設定が原因でループ

とくに Cloudflare などを挟んでいると、

ブラウザは https でアクセス
CDNとサーバー間は http 扱い
WordPress側は「http→httpsへリダイレクト」
ループ…

という形が起きます。

切り分け方法

一時的にCDNのプロキシをオフ（DNS only）にして挙動が変わるか確認
変わるなら、CDN側のSSLモードとサーバー側SSLを整合させるのが本筋です

典型パターン3：プラグインや .htaccess が原因

セキュリティ系・キャッシュ系・リダイレクト系が、URL変更に追従できていない
.htaccess（Apache）やNginx設定に古い転送が残っている

応急処置（最短で切り分け）

FTP/ファイルマネージャーで wp-content/plugins を一時的にリネーム
→ 全プラグイン停止状態になるので、ログインできるか確認
できたら、プラグインを1つずつ戻して原因特定

インデックスされない／重複扱いになる

サブドメインは「別サイト扱いになりやすい」ため、放置すると

いつまでも検索に出ない
旧URLと新URLが共存して重複扱い
検証用（stg/dev）がインデックスされてしまう

が起きやすいです。

まず確認する3点（ここが9割）

Search Consoleにサブドメインを追加しているか
https://blog.example.com/ を対象として見れていないと、原因分析ができません。
noindexになっていないか
テーマ設定、プラグイン、検証環境の設定で意図せず noindex が入ることがあります。
robots.txt がブロックしていないか
Disallow: / などが残っていると丸ごとクロールされにくくなります。

重複扱いになりやすい典型パターン

旧URLが200で生きている（301されていない）
http/https、www有無、末尾スラッシュの表記ゆれが複数存在
同じ内容が本体とサブドメインに二重掲載

対処の基本セット

旧→新は 1対1で301（可能なら同じパスで）
正規URLを1つに統一（http→https、www有無）
サイトマップをサブドメイン側で送信し直す
Search ConsoleのURL検査で「クロールできる/インデックス可能か」を確認

検証環境がインデックスされたとき（早めに止血）

Basic認証 or IP制限（最優先）
noindex（併用推奨）
検索に出てしまったURLは、Search Consoleの削除ツールで“表示を一時的に”抑える（根本はアクセス制限）

フォーム・決済・外部連携が動かない

サブドメイン化すると、外部サービスが「別サイト」と認識し、設定が外れることがあります。
ここは“相手側の設定”が原因のことも多いので、切り分けが重要です。

まず見るべき場所（原因の当たりを付ける）

ブラウザのConsole（JavaScriptエラー、Mixed Content、CORS）
ネットワーク（Network）（送信先URL、ステータスコード、ブロック有無）
WordPress側のログ（プラグインログ、サーバーログ）

よくある原因と対処（頻出順）

1) ドメイン許可設定の更新漏れ

reCAPTCHA、Googleログイン、決済、チャット、埋め込みフォームなどは
許可ドメインにサブドメインを追加しないと弾かれます。

例：許可が example.com だけ → blog.example.com では失敗

2) Mixed Content（httpsページ内にhttpリソース）

フォームのJS、決済のウィジェット、埋め込みタグが http:// のままだと動かないことがあります。

対処はシンプルで、

埋め込みコードを最新版に更新
DB置換で http→https を整理
キャッシュ削除

3) キャッシュ/最適化がスクリプトを壊す

圧縮（minify）や遅延読み込みが、決済やフォームのJSと相性悪いことがあります。

切り分けのコツ：

最適化を一時オフ → 動くなら「除外設定」で共存させる
（“止める”より“除外”が現実的）

4) メール送信が届かない（お問い合わせの定番）

サブドメインは“別送信元”に見えるので、到達率が落ちることがあります。

SMTP利用（プラグイン/外部SMTP）
SPF/DKIM/DMARC（可能なら整備）
送信元（From）ドメインの整合性

※「送信できたのに届かない」は、迷惑メール判定のことが多いです。

5) Webhook/リダイレクトURLの更新漏れ（決済で多い）

返却URL（success/cancel）
Webhookの通知先URL

が旧URLのままだと失敗します。
決済は“本番/テスト”環境の混同も起きやすいので、URLだけでなくモードも要確認です。

ケース別おすすめ構成

同一ブランドで別テーマを展開したい

「同じ会社・同じブランドだけど、見せ方（デザイン）や役割を分けたい」ケースです。ここは先に “分ける理由” を言語化すると、構成がブレません。

まず決めること（3つ）

目的が同じか（同じ問い合わせ・同じ購買導線か）
運用チームが同じか（更新担当・承認フローが同じか）
仕組みが同じか（同じWordPressで十分か／別システムが必要か）

おすすめ構成（現実的に回る順）

スクロールできます

目的	構成案	向いている状況	注意点
“同じ目的”で、見た目だけ少し変えたい	`example.com/` 配下にまとめる（可能なら）	SEO・導線を集約したい	1つのWPで「ページごとに別テーマ」は基本できないため、作り分けはテンプレ/ブロック/子テーマで行う
役割は近いが、運用や実装を分けたい	`example.com/brand/` に別WP（別インストール）	小規模で管理できる範囲	更新・セキュリティが“サイト数分”増える
役割や体験が明確に別（コミュニティ/会員/サポート等）	`community.example.com` などサブドメイン	UIや機能が別物	“別サイト感”が出るので育成と計測設計を最初から
同じ型のサイトを複数、統制して運用したい	マルチサイト（サブドメイン型/サブディレクトリ型）	複数拠点サイト、複数ブランドの統一運用	権限・移行の難易度が上がるので長期運用前提で

迷ったときの結論

ブランドが同じで検索意図も近いなら、まずは 同一ドメイン配下に寄せる（導線と改善がラク）
“体験が違う” “運用責任が違う” “機能が違う” が明確なら サブドメインで分離が安全

キャンペーンやLPだけ切り出したい

キャンペーンは「期間が短い」「訴求が尖る」「終わったら畳む」が多いので、SEOよりも 運用事故を起こさない設計が重要です。

おすすめは基本この2択

長く使う／検索流入も取りたい
→ example.com/lp/ や example.com/campaign/（サブディレクトリ）
短期・検証用／頻繁に差し替える
→ lp.example.com（サブドメイン）または専用ツール（静的LP/外部LP）

短期LPでやりがちな失敗と対策

失敗：キャンペーン終了後にページを消して404
- 対策：終了後は「後継ページ」へ 301、または告知ページとして残す（アクセスがある限り）
失敗：計測タグが本体と混ざって数字が崩れる
- 対策：GA4や広告計測は「LP専用の判別軸」を決める（ホスト名やパスで分ける）
失敗：同じ内容のLPを量産して重複だらけ
- 対策：役割を分ける（1ページ＝1テーマ）。似るなら統合してセクションで出し分け

“切り出す”判断の目安

LPが毎月のように入れ替わる → サブドメインや外部LPの方が運用しやすい
常設の集客導線として育てたい → サブディレクトリに置いて資産化しやすい

企業サイト＋ブログの定番パターンを作りたい

初心者にとって一番失敗しにくい「王道」構成です。狙いはシンプルで、ブログで集客 → 企業サイトで信頼 → 問い合わせ。

おすすめ構成（まずこれ）

企業サイト：example.com
ブログ：example.com/blog/

この形の強みは、導線が自然に作れることです。

ブログ側の設計（最低限で強い）

カテゴリは「サービスの理解→比較→事例→導入」の流れを意識
記事末尾に、次の一手を固定（例：資料請求、無料相談、料金ページ）
会社情報（運営者・実績・所在地・問い合わせ）は企業サイトに集約し、ブログから迷わず行けるようにする

サブドメインにする方が向く例

ブログだけ運用会社・担当が別で、権限分離が強く必要
本体はCMSがWordPressではない（別システムで動いている）
ブログ側で特殊機能（会員/多言語/重い検索など）を入れる予定がある

この場合は、次のように割り切ると事故が減ります。

企業サイト：example.com
ブログ：blog.example.com
共通導線：ヘッダー/フッターは最短リンクだけ（押し付けない）
計測：全体俯瞰＋サブドメイン個別（どこで落ちたか追える形）

開発・検証環境を安全に用意したい

サブドメインはステージング（検証環境）と相性が良い一方、放置すると危険です。ここは“安全第一”で設計します。

おすすめ構成

本番：example.com（または blog.example.com）
検証：stg.example.com（または stg.blog.example.com）

ステージングの必須ガード（この3つはセット）

検索させない：noindex（＋必要なら robots でも制御）
見せない：Basic認証または IP制限
混ぜない：解析・広告タグを本番と分ける（数字汚染を防ぐ）

検証で見るポイント（最小で効く）

ログインできる
主要ページが崩れていない
フォーム/決済/会員など重要導線が動く
表示速度が極端に落ちていない
更新（テーマ/プラグイン）後に致命的エラーが出ない

運用ルール（初心者でも回る形）

更新は“本番直”ではなく、必ずステージング→本番
大きな変更は「戻せる状態」を作ってから（直前バックアップ＋戻し手順メモ）
ステージングは公開資産にしない（URLが外部に出ない設計が大切）

WordPress.comでサブドメインを使う場合

事前条件（サイト・プラン・連携の前提）

まず前提として、「WordPress.comでのサブドメイン」には次の2種類があります。

スクロールできます

種類	例	できること	向いているケース
WordPress.comの無料アドレス	`example.wordpress.com`	すぐ公開できる	とりあえず試したい／準備ゼロで始めたい
自分のドメインのサブドメイン	`blog.example.com`	独自アドレスで公開できる	ブランドを揃えたい／用途別にサイトを分けたい

今回の「サブドメインを使う」は基本的に後者（blog.example.com など）です。ここで押さえるべき前提は3つあります。

有料プランが必要
WordPress.comでサブドメイン（＝独自ドメイン配下のサブドメイン）を“サイトのアドレスとして接続”するには、有料プランが必要です（※サイトごとにプランが必要）。
ルートドメイン（example.com）を管理しているWordPress.comアカウントが同じであること
ルートドメインを別アカウントで管理している場合、サブドメイン作成や連携の一部を「その管理者側」で行う必要が出ます。
DNSをどこで管理しているか把握する
ルートドメインがWordPress.comのネームサーバーを使っているか／外部（お名前.com等）でDNSを管理しているかで、設定手順が分岐します。

補足：複数ドメインを同一サイトに接続している状況だと、連携途中でドメイン所有確認（認証コード／EPPコード等）を求められることがあります。これは「移管」ではなく、所有者確認のために使われます。

連携手順の要点（どこで何を設定するか）

初心者が迷いやすいのは、「WordPress.com側」と「ドメイン会社（DNS）側」でやることが分かれている点です。ざっくり流れは次のとおり。

（WordPress.com側）サブドメインを使う“サイト”を決める
- 既存サイトに blog.example.com を付けるのか
- サブドメイン専用に新規サイトを作るのか
  ※ここを先に決めると、後戻りが減ります。
（WordPress.com側）サブドメインを追加する
ダッシュボード →（Upgrades / Hosting）→ Domains →「自分のドメインを使用」→ blog.example.com のように“フルのサブドメイン”を入力して進めます。
途中でサイトにプランが無ければ、購入導線に進みます。
（DNS側）DNSレコードを入れる（ここが本番）
ルートドメインがWordPress.comネームサーバーなら、必要なDNSは自動で揃っている場合があり、動作確認へ進めます。
外部DNSの場合は、WordPress.comの画面で表示される指示に従ってDNSを設定します。 おすすめはNSレコード（委任）方式です。

NSレコード方式（推奨）：blog.example.com のDNS管理をWordPress.com側に“委任”する形
- メリット：WordPress.com側で必要なレコードを管理しやすく、迷いにくい
- 注意：そのサブドメイン配下で独自にメール等のDNS運用をしている場合は影響が出ることがある
A/CNAME方式（advanced setup）：外部DNSでAやCNAMEを手入力して向け先を作る形
- メリット：DNS管理を外部に寄せたまま運用しやすい
- 注意：設定ミス（向き先違い、二重設定）・保守が増えやすい

SSL（https）は基本“自動”
WordPress.comは、接続されたドメイン／サブドメインに対して無料SSLを自動提供します。表示がhttpsにならない、証明書が保留のまま…のときは、ドメイン管理画面の「Domain security」周りで状態確認→DNS側の不整合（CAAやNS混在など）を潰していくのが近道です。

重要な注意点として、www のサブドメインは、ルートドメイン以外のサイトに割り当てられない（＝www.example.com を別サイトに向けるのは不可）という制約があります。サブドメイン運用をするなら blog / shop / help / lp など “www以外” を前提に設計しましょう。

切り替え・削除時に気をつけること

サブドメインは「作る」よりも「変える／やめる」時に事故が起きがちです。ポイントを先回りで整理します。

1) 切り替え（別サイトへ付け替え）で起きること

サブドメインは多くの場合、検索エンジン上も運用上も“別サイト”として扱われやすいので、付け替え＝実質的なURL変更になりがちです。
DNS反映にはタイムラグがあり、状況によっては最大72時間ほど古い表示が残ることがあります。
付け替え前に、次を決めておくと安全です。
- 新旧どちらを正にするか（正規URL）
- 旧URLから新URLへ恒久転送（301）するか
- 計測（GA等）・Search Consoleのプロパティをどう持つか

2) 削除（WordPress.comからサブドメイン接続を外す）で起きること

WordPress.com側での削除は、基本「Domains」から対象サブドメインを選び、削除（接続解除）します。
接続を外すと、そのサブドメインでの表示は止まります。次の行き先を用意しないと、ユーザーも検索も迷子になります。

3) “別のURLに送るだけ”なら、サブドメイン転送という選択肢もある
「サブドメインにWordPressを置く」ではなく、サブドメインを別URLへリダイレクトしたいだけなら、WordPress.comのドメイン／サブドメイン転送が使える場合があります。
ただし、転送は仕組み上の向き不向きがあり（転送時の表示URLの扱い等）、また利用には条件（ネームサーバー等）が絡むため、用途が「運用サイト」なのか「誘導用URL」なのかを先に確定すると判断が速くなります。

よくある質問

サブドメインは本当に無料で増やせる？

多くの場合、サブドメイン自体（DNS上の追加）は無料です。
ただし「サブドメインを増やす＝運用コストゼロ」とは限りません。

無料になりやすいもの

DNSレコードの追加（A／CNAMEなど）
同一サーバー内でのサブドメイン作成（サーバー機能として提供されている範囲）
無料SSLがサブドメインにも対応しているプラン（ホスティング次第）

お金がかかりやすいもの

サブドメインごとに別サーバー／別契約が必要な構成
WordPress.comで「独自ドメイン配下（サブドメイン含む）を接続して使う」ための有料プラン
有料SSL（組織認証などが必要な要件）
外部サービス（CDN／WAF／フォーム／決済）の追加利用料

「無料で増やせるか？」は、実務的には “DNSは無料でも、運用する仕組みに費用が出るか”で判断するのが安全です。

サブドメインはSEO的に不利なの？

結論：一概に不利ではありません。ただし、サブドメインは状況によって 「別サイトっぽく評価されやすい」ため、設計を雑にすると不利に働きます。

不利になりやすいパターン

本体とサブドメインで内容が似ていて、重複が増える
内部リンクやナビが弱く、ユーザーもクローラも行き来しづらい
Search Consoleやサイトマップ運用が分断され、改善が遅れる

有利に回しやすいパターン

役割が明確（例：サポート／ドキュメント／アプリ／会員など）
コンテンツの対象が明確に違う（検索意図が分かれる）
本体とサブドメイン間の導線が自然（ヘッダー・フッター・関連記事など）

迷ったら、SEOの観点では 同一テーマで育てたいものはサブディレクトリ寄り、
体験や運用が別物なら サブドメインで分離が失敗しにくいです。

複数インストールとマルチサイトはどっちが安全？

「安全」は どのリスクを重く見るかで答えが変わります。ざっくり比較するとこうです。

スクロールできます

観点	複数インストール（別々）	マルチサイト（まとめる）
影響範囲	片方が壊れても他に波及しにくい	1箇所の障害が全体に波及しやすい
更新運用	サイト数ぶん手間が増える	コア・テーマ・プラグインを統制しやすい
権限設計	サイトごとに完結しやすい	ネットワーク管理（Super Admin）中心になりやすい
将来の切り離し	比較的やりやすい	切り出しが重くなりやすい

初心者に多い“安全な結論”

まずは 複数インストール：理解しやすく、トラブル時の切り分けが楽
「同じ型のサイトを増やす」「統制が必要」なら マルチサイト：運用ルールを作れる前提で強い

後からサブディレクトリ運用に戻せる？

可能です。ただし実態としては URL移転（サイト移行）なので、手間とリスクはあります。

戻すときに必ず発生すること

旧（サブドメイン）→新（サブディレクトリ）の 301リダイレクト設計
DB内URLの置換（画像・内部リンク・設定値）
https混在（Mixed Content）やキャッシュの再調整
Search Console／サイトマップの再提出・監視

戻しやすくするコツ（今のうちにできる）

URL設計をシンプルにしておく（無駄な階層・表記ゆれを作らない）
旧→新の対応表を作りやすいパス構造にする
記事内で絶対URLを乱用しない（可能なら相対や統一運用）

「将来戻すかも」が少しでもあるなら、最初から サブディレクトリ寄りにしておく方が総コストは下がりやすいです。

Search Consoleはサブドメインごとに必要？

目的で答えが変わります。

結論（使い分け）

全体をまとめて見たい → ドメインプロパティ（例：example.com）が便利
1つで、プロトコル（http/https）やサブドメインをまとめて扱える考え方です。
サブドメイン単体だけを細かく見たい／共有したい → URLプレフィックス（例：https://blog.example.com）を追加するのも有効

初心者におすすめの運用

まずドメインプロパティで“全体”を一括監視
問題が起きやすいサブドメインだけ、URLプレフィックスも追加して深掘り

まとめ：目的→選択→設定→運用の順で迷わない

サブドメイン運用で迷いがちなポイントは、実は「技術」よりも順番です。
最初に目的を決めずに作り始めると、あとでSEO・導線・管理が全部ちぐはぐになりやすいので、次の流れで整理すると失敗しにくくなります。

1) 目的を言語化する（ここが最重要）

まずは、サブドメインを作る理由を 1行で言える状態にします。

役割分離：サポート／ドキュメント／ショップ／会員など、体験や機能を分けたい
運用分離：担当者・権限・更新頻度が違うので、管理単位を分けたい
検証：本番に影響なく更新テストしたい（ステージング）

この1行が固まると、次の「選択」がスムーズになります。

2) 選択する（迷ったらこの基準）

スクロールできます

目的・状況	まずの第一候補	理由
本体と同じテーマで評価も導線もまとめたい	サブディレクトリ	集約しやすく、運用がシンプル
役割が別（サポート／会員／ECなど）で体験も違う	サブドメイン	分離が合理的、設計がスッキリ
ブランドや責任範囲まで分けたい	新規ドメイン	完全分離で安全
複数サイトを統制して一括管理したい	マルチサイト	更新・権限・標準化に強い

ポイント
SEOで“絶対”を求めるより、「ユーザーにとって分かりやすい分け方」＋「運用が回る単位」を優先した方が、長期で成果が出やすいです。

3) 設定する（作業はこの順で事故が減る）

初心者が詰まりにくい「共通フロー」を、最短ルートに並べます。

命名を決める（用途が一目で分かる名前）
例：blog / support / docs / store / stg
サーバー側でサブドメイン作成 → ドキュメントルートを分ける
本体と同じフォルダに向けない（事故防止）
DNS設定（A/CNAME）→ 疎通確認（表示できるか）
変更直後はキャッシュ（TTL）で見え方が揺れることがある
SSL（https）を有効化 → http/https を統一
SSLが安定してから統一するのが安全
WordPress導入（方法Aか方法B）
- 方法A：別インストール（分かりやすい・切り離しやすい）
- 方法B：マルチサイト（統制しやすい・制約も増える）
計測と検索向けの整備
- Search Console：全体（ドメイン）＋必要ならサブドメイン個別
- サイトマップ送信
- noindexの有無チェック（特にステージング）