企業サイトのWordPressへ採用サイトを追加するとき、「同じドメイン配下だから同じWordPressでよい」とは限りません。反対に、デザインが違うという理由だけで別WordPressを増やすのも早計です。
最初に見るべきなのはURLではなく、次の4つを既存サイトと共有できるかです。
- 有効化するTheme
- 変更を公開する時間と担当者
- 障害時に止めてよい範囲
- backupから復旧する単位
4つを共有でき、stagingで変更と復旧を確認できるなら、同じWordPressへ追加する候補になります。どれかを独立させる必要があるなら、別インストールを候補に戻します。
この記事では、通常の単一サイト構成のWordPressを対象に、実装前のread-only確認、stagingでの受け入れ、rollback記録までを一つの流れにします。hosting比較、WordPressのマルチサイト構築手順、SEO上の優劣は扱いません。
結論：URLではなく、変更と復旧の単位をそろえる
判断を先にまとめると、次のようになります。
| 確認する境界 | 同じWordPressの候補 | 別WordPressへ戻す条件 |
|---|---|---|
| active Theme | 既存サイトと同じThemeで採用ページを成立させる | 採用サイトだけ別Themeを有効化する必要がある |
| release | 同じ担当者・同じ変更時間で公開できる | 変更時期、承認者、保守担当を分ける必要がある |
| failure | 既存サイトと採用サイトを同じ障害単位として扱える | 一方の変更で他方を止めてはいけない |
| restore | 同じdatabaseとfilesを同じ時点へ戻せる | 復旧時点や復旧担当を分ける必要がある |
別WordPressにすると、更新、backup、監視、account管理も別に増えます。そのため「分ければ安全」とは決めません。分離の必要性と、増える運用を両方記録して選びます。
Themeの切り替えは1ページだけの変更ではない
WordPressでは、通常1サイトにつき一つのThemeがactiveになります。Themeは個別ページの見た目だけでなく、header、footer、template、style、Navigationなど、サイト全体の表示を担います。詳しくはWordPress公式のThemesの解説で確認できます。
したがって、次の前提は分けて考える必要があります。
同じURL配下に置きたい
≠ 同じWordPressで別Themeを同時に使える
既存データを上書きしない制作物である
≠ Themeを有効化しても既存サイトへ影響しない
採用サイト用Themeを既存WordPressで有効化する案では、採用ページだけでなく、既存のトップページ、投稿、固定ページ、404、検索結果、Navigationも確認対象です。
最初にread-onlyで現状を採取する
設計前に、対象環境を取り違えていないことを確認し、現在値を変更せずに採取します。WP-CLIを使える環境なら、次のようなコマンドを候補にできます。
wp core version
wp theme list \
--status=active \
--fields=name,status,version,auto_update \
--format=table
wp plugin list \
--status=active \
--fields=name,status,version,auto_update \
--format=table
wp option get home
wp option get siteurl
wp option get show_on_front
wp option get page_on_front
wp option get page_for_posts
ここでは更新、Theme切り替え、option変更を行いません。wp theme list、wp plugin list、wp option getの仕様は、それぞれWP-CLIのTheme一覧、Plugin一覧、option取得で確認できます。
WP-CLIを使えない場合は、WordPress管理画面の「ツール → サイトヘルス → 情報」も現状把握に使えます。Site Health画面の公式説明では、active Themeやactive Plugin、versionなどの情報を確認できます。
採取結果には、内部URL、Plugin構成、環境名など、公開範囲を限定すべき情報が含まれることがあります。コマンド出力をそのまま公開issueや記事へ貼らず、案件の管理場所へ必要項目だけ記録します。
判断記録を先に作る
口頭の「同じサイトで大丈夫」を実装条件にしないため、変更前に小さな判断記録を作ります。値は案件ごとに埋め、未確認をyesへ寄せません。
wordpress_boundary_review:
current:
active_theme: "確認済みのTheme名とversion"
home_and_siteurl_checked: true
active_plugins_recorded: true
front_page_settings_recorded: true
candidate:
requires_active_theme_change: true
release_owner_shared: false
maintenance_window_shared: false
failure_window_shared: false
restore_point_shared: false
safety:
staging_or_clone_ready: false
full_site_backup_ready: false
current_theme_package_or_source_ready: false
restore_test_passed: false
decision: "pending"
requires_active_theme_change: trueで、既存Themeを維持する必要があるなら、同じWordPressへ無影響で追加できるとは扱いません。別インストールへ分けるか、既存Theme内で実装するか、要件へ戻します。
restore_point_sharedは重要です。同じdatabaseへ採用コンテンツと既存コンテンツを保存すると、片方だけを任意の時点へ戻せないことがあります。「復旧時に既存のお知らせや固定ページまで巻き戻してよいか」を先に確認します。
stagingまたはcloneで変更範囲を確かめる
本番で初めてThemeを切り替えず、production相当のstagingまたはcloneで確認します。空のWordPressへThemeを入れて表示できても、既存サイトへの影響確認にはなりません。
最低限、次の順序を固定します。
- production相当のdatabaseとfilesからstagingまたはcloneを用意する。
- 外部メール、応募送信、決済、計測など、stagingから実行してはいけない送信を止める。
- 変更前のactive Theme、active Plugin、WordPress version、front page設定、主要routeを記録する。
- site全体backupと復旧手順を用意する。
- 候補Themeをstagingだけで有効化する。
- 採用ページと既存ページの両方をPC・mobileで確認する。
- 元の状態へ戻し、復旧後の主要routeと管理画面を再確認する。
確認対象は採用ページだけでは足りません。
- トップページ
- 既存の固定ページと投稿
- header、footer、Navigation
- 404、検索結果、archive
- formの表示と送信停止状態
- canonical、robots、sitemapなどの公開面
- 管理画面での編集、preview、公開権限
- cacheを消した後の表示
ここで発見した差分は、Themeの不具合と決めつけません。既存Theme固有のtemplate、Plugin依存、Navigation設定、front page設定、cacheのいずれかを切り分けます。
backupはdatabaseとfilesを一組で考える
WordPress公式のBackupの解説では、databaseとfilesを別の対象として説明しています。Themeを戻すだけでは、次の変更は戻らないことがあります。
- databaseへ保存されたTheme設定やカスタマイザーの値
- Site Editorで変更したtemplateやstyle
- Navigationやwidgetの割り当て
- Pluginが追加・更新したoptionやtable
- 新規・更新した投稿、固定ページ、media
そのため、rollback記録には少なくとも次を含めます。
| 項目 | 記録する内容 |
|---|---|
| backup | databaseとwp-contentを含むsite全体backupの取得時刻・保管先・担当 |
| baseline | WordPress、active Theme、active Pluginのversionとfront page設定 |
| trigger | 既存route欠落、重大な表示崩れ、管理不能、form誤送信などの停止条件 |
| restore | 誰が、どの手順で、どの時点へ戻すか |
| verification | 復旧後に確認する主要route、管理画面、form、public metadata |
backupが存在するだけでは、復旧できるとは限りません。少なくともstagingでrestore手順を通し、戻した後の状態まで確認します。
同じWordPressにする場合の受け入れ条件
同じWordPressを選ぶなら、「作れた」ではなく次を完了条件にします。
- 既存Themeのまま実装するか、Theme変更のsite全体影響を関係者が受け入れている
- 採用ページと既存ページを同じrelease windowで変更できる
- 既存サイトと採用サイトを同じ障害・復旧単位として扱える
- stagingまたはcloneで既存routeを含む確認に合格している
- databaseとfilesを含むsite全体backupがある
- 現行Themeとversion、元へ戻す手順、rollback担当が確定している
- 引き渡し後のWordPress、Theme、Pluginの更新担当が一つの運用表に載っている
この条件を満たさないまま「まず同じWordPressで試す」と進めると、試す行為自体が既存サイトの変更になります。
別WordPressにする場合の受け入れ条件
別インストールを選ぶ場合も、URLだけ決めて終わりではありません。
- WordPress core、Theme、Pluginの更新担当
- backup、監視、障害連絡、復旧担当
- account発行、退職・契約終了時の無効化
- form送信先と個人情報の管理範囲
- domain、TLS、redirect、canonical、sitemapの責任
- 既存サイトと採用サイトをまたぐNavigationの変更担当
- 引き渡し時の環境一覧と保守期限
運用を二つへ分ける必要がないなら、別WordPressは管理対象を増やすだけになる場合があります。分離によって守りたい障害単位・担当・変更時期を明記できることが採用条件です。
2GU Themeを既存WordPressで使う場合の境界
2GU Themeを既存WordPressで有効化すると、採用ページだけでなく、既存site全体のheader、footer、style、template、Navigationへ影響し得ます。既存データを意図せず上書きしない制作キットであっても、Theme有効化の影響がなくなるわけではありません。
既存Themeを維持したまま同じWordPressへ無影響で追加できる、とは扱わないでください。既存WordPressで確認する場合は、production相当のstagingまたはclone、databaseとwp-contentを含むsite全体backup、現行Themeとversion、rollback手順を先にそろえます。
この条件をそろえられない場合は、本番で有効化せず、別WordPressまたは既存Theme内での実装へ判断を戻します。
公開前に残す最終チェック
[ ] 対象のWordPress環境を取り違えていない
[ ] active Themeとversionを記録した
[ ] active Pluginとversionを記録した
[ ] home / siteurl / front page設定を記録した
[ ] 同じrelease・failure・restore単位でよいと確認した
[ ] production相当のstagingまたはcloneで試した
[ ] 採用ページ以外の主要routeも確認した
[ ] databaseとfilesを含むsite全体backupがある
[ ] 現行Themeへ戻すだけでは不足する変更を列挙した
[ ] restore後の確認まで通した
[ ] 更新・障害・引き渡しの担当を記録した
同じWordPressか別WordPressかは、どちらが常に優れているかでは決まりません。active Theme、変更、障害、復旧の単位をそろえ、実際に戻せる構成を選ぶことが判断の中心です。
判断条件を制作・運用の8項目で整理した一般向け版は、採用サイトは既存WordPressか別WordPressかにまとめています。