採用サイトは既存WordPressか別WordPressか

採用サイトを作るとき、既存の企業サイトと同じWordPressへ追加するか、別のWordPressとして分けるかは、URLの見た目だけでは決められません。既存サイトと同じTheme、更新担当、障害対応、復旧手順で運用できるなら同じWordPressが候補になります。見た目、変更時期、運用担当、障害範囲、引き渡しを独立させたいなら、別WordPressが候補になります。

受注から公開・引き渡しまでの全体順は、WordPress採用サイトの制作・引き渡しチェックリストで確認できます。まだ顧客が更新する内容を決めていない場合は、先に採用サイトで何をCMS化するか｜更新範囲の決め方を整理してください。顧客へ渡す操作とaccountは、WordPress採用サイトの権限設計｜顧客に渡す操作の決め方で分けられます。本記事では、その間にある「どのWordPressへ配置するか」だけを扱います。

結論：URLより、変更と復旧の境界で決める

最初に、次の二つを比べます。

同じWordPressへ追加する案は、企業サイトと採用サイトで一つの有効Theme、Plugin構成、管理画面、更新・復旧手順を共有する案です。既存のブランド、共通Navigation、運用体制を一体で扱いたい案件に向きます。

別WordPressへ分ける案は、採用サイト専用のWordPressを用意し、Theme、Plugin、account、更新、backup、復旧を独立させる案です。採用サイトだけを別の見た目や日程で改修したい、企業サイトの障害や変更と切り分けたい、別の担当へ引き渡したい案件に向きます。

どちらかが常に安い、安全、検索に強いわけではありません。同じWordPressは管理先をまとめられますが、一つのTheme・Plugin変更が企業サイト全体へ及びます。別WordPressは影響範囲を分けられますが、更新、監視、backup、account、計測等の管理対象が増えます。

判断するときは、「どのURLが有利か」ではなく、次の順で確認します。

1. 何を同じ見た目・構造で管理するか
2. 誰が更新・公開・保守するか
3. どこまで同時に停止してよいか
4. どの単位でbackupから戻すか
5. どの単位で顧客へ引き渡すか

同じWordPressと別WordPressで、何が変わるか

ここでいう「同じWordPress」は、同じWordPressインストールの管理画面、データベース、有効Theme、Plugin、ユーザー、更新、backupを共有する状態です。WordPress公式のThemeの操作案内では、インストールしたThemeのうち有効にできるのは一つで、有効Themeの見た目と機能がサイトへ適用されると説明されています。

「別WordPress」は、採用サイト用に別のWordPressインストールを用意する状態です。企業サイトとは別に、有効Theme、Plugin、ユーザー、データベース、更新、backup、復旧を管理します。

ドメインやURLの形だけでは、この違いを判定できません。サブドメインだから必ず別WordPress、サブディレクトリだから必ず同じWordPress、とは限りません。提案前に、次の実体を確認します。

• WordPress管理画面とデータベースは同じか
• 有効ThemeとPluginを共有するか
• ユーザーと権限を共有するか
• WordPress本体、Theme、Pluginを同時に更新するか
• backupと復旧を同じ単位で行うか
• 障害時に企業サイトと採用サイトが同時に影響を受けるか

本記事は通常の単一サイトを比較対象とし、WordPressマルチサイトの構築手順は扱いません。

8つの判断軸で比較する

次の表を案件ごとに埋めます。一つの行だけで決めず、公開後の運用まで含めて比べます。

判断軸	比較する内容
既存資産	同じWordPress：既存Theme、共通部品、ページ、Navigationを採用サイトでも使える。別WordPress：既存Themeや構造を変えず、採用サイトだけ別に作りたい。確認：現在の有効Theme、独自実装、同じslugのページ、共通部品、変更時の影響。
構成の独立	同じWordPress：企業サイトと採用サイトを一つのTheme・Plugin構成で検証できる。別WordPress：採用サイトだけ別Theme、別Plugin構成、別の更新時期にしたい。確認：Theme切り替え時の全ページ、Plugin依存、更新前後の確認範囲。
更新・公開	同じWordPress：同じ担当と承認手順で両方を運用する。別WordPress：採用担当や外部制作者が採用サイトを独立運用する。確認：下書き、公開、募集終了、固定ページ、構造変更の担当。
権限	同じWordPress：同じ利用者と権限体系を共有してよい。別WordPress：採用サイト利用者を企業サイトの管理画面から分離したい。確認：管理者、編集者、外部担当、退職・契約終了時のaccount処理。
障害・復旧	同じWordPress：両サイトを同じ時間、同じ復旧点へ戻してよい。別WordPress：一方の障害や復旧をもう一方へ及ぼしたくない。確認：backup対象、取得頻度、保存先、復元担当、復旧時間、停止判断。
URL・計測	同じWordPress：共通Navigationと同じ計測単位で管理したい。別WordPress：導線や計測を採用サイト単位で管理したい。確認：相互link、現在URL、redirect、canonical、sitemap、計測owner。
引き渡し	同じWordPress：企業サイトと採用サイトを一つの保守範囲で渡す。別WordPress：採用サイトだけ別担当・別契約・別時期に引き渡す。確認：契約主体、管理資料、更新窓口、障害連絡先、保守終了時の移管。
運用工数	同じWordPress：既存環境を安全に使え、管理先を増やさずに済む。別WordPress：分離に必要な初期作業を許容し、独立運用の価値が上回る。確認：構築、検証、更新、監視、backup、計測、引き渡しの継続作業。

同じWordPressにすると初期費用が必ず低くなる、別WordPressにすると保守が必ず安全になる、とは判断しません。既存サイトの調査やTheme変更が大きければ、同じWordPressの方が確認範囲は広がります。別WordPressでも、運用担当、backup、相互導線が決まっていなければ、分けただけでは管理できません。

同じWordPressへ追加する前に確認する

同じWordPressへ追加する場合は、現在の企業サイトを「採用ページを置く空き場所」と見なさず、変更対象の本番サイトとして扱います。

1. 現在の有効Themeと全体構造を確認する

現在のThemeが、固定ページだけでなく、header、footer、テンプレート、全体style、Navigation、検索、404等の表示をどう作っているか確認します。採用サイト用に別Themeを有効化すると、採用ページだけでなく既存ページの表示も変わります。

既存Themeを維持するなら、そのTheme上で必要な採用ページとデータ表示を実装できるかを確認します。別Themeを使うなら、企業サイト全体をそのThemeへ切り替える案件として見積ります。

2. stagingまたはcloneで先に試す

本番でThemeや主要Pluginを直接切り替えず、stagingまたは複製した検証環境で試します。検証環境は本番と同じ版、主要設定、代表コンテンツを持ち、外部送信や検索公開等の扱いを分けます。

少なくとも次を確認します。

• 企業サイトの主要ページ、採用ページ、投稿、一覧、検索、404
• header、footer、PC・スマートフォンのNavigation
• 問い合わせ、応募等のフォームと送受信
• 既存Pluginの主要機能と管理画面
• 画像、PDF、外部link、計測の継続
• WordPressとPHPの対応、エラーlog、表示速度の大きな変化

3. backupとrollback手順を実物で確認する

作業前に、データベースとwp-contentを含むサイト全体のbackupを確認します。現在の有効Theme名、Theme・Pluginの版、変更前設定、復元担当、復元後に確認するURLも記録します。

「以前のThemeを再び有効にする」だけでは、データベース、Plugin設定、生成ページ、Navigation等の変更まで戻るとは限りません。どの変更をTheme切り替えで戻し、どの変更をbackupから復元するかを先に分けます。

4. 既存ページとNavigationの衝突を確認する

同じslug、同じ用途の固定ページ、既存Navigation、トップページ設定を確認します。既存ページを再利用するのか、別slugで作るのか、作成を止めるのかを実行前に決めます。自動生成機能がある場合も、既存本文やNavigationを上書きしない条件と、失敗時の停止条件を確認します。

別WordPressへ分ける前に確認する

別WordPressは、企業サイトへのTheme・Plugin変更を避けやすく、採用サイトの公開時期、更新、障害対応、引き渡しを分離できます。一方で、WordPressをもう一つ管理する責任が増えます。

1. 新しい管理単位のownerを決める

WordPress管理者、サーバー・ドメイン、更新、backup、障害対応、フォーム・メール、計測の担当を決めます。企業サイトの担当者が自動的に採用サイトも管理するとは扱いません。

2. 企業サイトとの往復導線を設計する

企業サイトから採用サイトへ、採用サイトから企業情報や問い合わせ先へ到達できるようにします。ロゴ、会社名、Navigationの文言、プライバシー情報、障害時の案内が食い違わないよう、どちらを正本にするか決めます。

3. URL変更がある場合だけ移転計画を作る

新規サイトとして始める場合と、既存の採用ページを新しいURLへ移す場合を分けます。既存URLを移すなら、旧URLと新URLの対応、redirect、canonical、内部link、sitemap、計測、公開切り替えを確認します。Google Search CentralのURL変更を伴うサイト移転も確認できます。

URL構成だけから検索順位の優劣を断定しません。移転には一時的な変動や確認作業があり、別WordPressにしたこと自体が検索成果を保証するものでもありません。

4. 二つのWordPressを継続管理できるか確認する

WordPress本体、Theme、Plugin、backup、監視、account、問い合わせ先、引き渡し資料が二組になります。初期構築費だけでなく、更新のたびに誰がどちらを確認するかまで見積ります。

判断を提案・見積りへ落とす

比較だけで終わらせず、次の順で一案を選びます。

1. 採用サイトで更新する情報と固定する情報を決める
2. 現在の企業サイトのWordPress、Theme、Plugin、ページ、Navigationを調べる
3. 両サイトで共有できるものと、独立させるものを8軸へ記入する
4. stagingまたはcloneで成立する構成を確認する
5. backup、rollback、障害時の停止・復旧単位を確認する
6. 初期作業と継続作業を見積り、顧客へ二案の差を説明する
7. 採択案、採択理由、再検討条件を提案書と引き渡し資料へ残す

判断記録には、少なくとも次を残します。

• 同じWordPress／別WordPressの採択結果と理由
• 現在と採択後の有効Theme・主要Plugin
• URL、Navigation、計測の管理単位
• 更新、公開、技術保守、基盤管理の担当
• backupの対象、取得者、保存先、復元担当
• rollbackの開始条件と確認する主要ページ
• 初期工数、継続工数、保守範囲
• Theme変更、担当変更、移転、障害等の再検討条件

2GUを使う場合は、一般論と適合条件を分ける

ここまでの判断方法は2GUを使わない案件にも当てはまる一般論です。2GUを使う場合は、その後に商品の構成と適合条件を重ねます。

2GUは、2GUテーマ、2GU Plugin、2GU採用キットを組み合わせるWordPress採用サイト制作キットです。2GUテーマは、サイトの表示、基本テンプレート、header、footer、全体styleを担います。2GU Pluginは、募集要項等の採用データ、入力、検証、セットアップ等を担います。採用キットは、両者の上で必要なページを選んで下書きを作る出発点です。

既存WordPressで2GUテーマを有効化すると、サイト全体へ影響する

既存WordPressで2GUテーマを有効化すると、有効Themeが2GUへ切り替わります。採用ページだけでなく、既存サイトのheader、footer、全体style、テンプレート、Navigation等の見た目と動作が変わる可能性があります。

そのため、2GUを「既存Themeを維持したまま、採用ページだけを無影響で追加するPlugin」とは扱いません。既存の企業サイト全体を2GUテーマで構成し直せる場合は同じWordPressが候補になります。現在の企業サイトで有効Themeを維持する必要がある場合は、2GU用の別WordPressまたは別の制作方法を比較します。

採用キットの非上書きと、Theme切り替えの影響は別である

2GU採用キットは、既存ページと同じslugや用途を実行前に確認し、ページごとに新規作成、既存採用、再利用、スキップを選びます。採用した既存ページの本文を自動で書き換えず、既存Navigationやサイトのホームページ設定も明示操作なしには変更しません。

ただし、これはページ生成とNavigationの非上書き境界です。2GUテーマを有効化した時にサイト全体の有効Themeが切り替わる影響をなくすものではありません。この二つを混同せず、Theme切り替えを先に検証してから採用キットの実行計画を確認します。

既存WordPressへ導入する場合の必須確認

2GUを既存WordPressへ導入する案では、少なくとも次を満たしてから本番作業を判断します。

1. stagingまたはcloneを用意する
2. データベースとwp-contentを含むサイト全体のbackupを確認する
3. 現在の有効Theme名と版、主要Plugin、元へ戻す手順を記録する
4. 検証環境で2GUテーマと2GU Pluginを有効化する
5. 既存の主要ページ、Navigation、フォーム、検索、404、スマートフォン表示を確認する
6. 同じslug・用途の既存ページと、採用キットの実行計画を確認する
7. 意図しない表示崩れや機能停止があれば追加作業を止める
8. 復元後に確認するページと担当を含むrollback手順を確定する

2GUはサイト全体のbackupや完全復元を代行しません。Themeを元へ戻すだけで保存形式や設定まで安全に戻るとは限らないため、作業前に用意したサイト全体のbackupと復元手順を使います。

一般判断と2GU固有条件を照合した後は、対応環境で利用予定のWordPressとPHP等を確認し、公開マニュアルで導入、採用キット、問題時の停止手順を確認してください。デモでは、同じ商品から作成した二つの架空企業サイトの表示を確認できます。

条件が合う場合は、2GUの内容と料金・提供条件で、案件に含まれるものと含まれないものを確認してください。先に商品へ構成を合わせるのではなく、同じWordPressか別WordPressかを決め、その構成へ2GUが適合するかを照合する順序が重要です。