本番WordPressをステージングに完全複製する手順：URL置換・CPT再現・クローラー遮断まで

WordPressサイトを改修するとき、いきなり本番をいじるのは怖い。だから本番のコピーをテスト環境に作って、そこで試したくなります。当然のニーズです。

ステージング＝本番のコピーを置いて安全に試すための検証環境。ところが、WordPressの複製は「バックアップを展開すればOK」では済みません。実際にやると、次々と問題が出てきます。

• URLが本番のまま。リンクをクリックすると本番に飛ぶ
• CSSや画像が読み込まれず、レイアウトが崩壊する
• カスタム投稿（症例・お知らせ等）が空になり、グリッドが「記事がありません」表示になる
• うっかりGoogleにインデックスされて、重複コンテンツ扱いの危険が生まれる

この記事では、本番WordPressをテスト環境に完全複製する手順を、実際にハマったポイントとともに整理します。LP単体をステージングで検証する話はステージング環境でLPのモバイル最適化を検証する記事でも触れているので、あわせてどうぞ。

結論：URL置換は3層、クローラー遮断は4層で守る

複製の肝は次の4点です。

• URL置換は3層でやる（DB / テーマPHPファイル / サブドメイン参照）
• クローラー遮断は4層で多重に守る（Basic認証 / HTTPヘッダー / metaタグ / WP設定）
• 特殊なディレクトリ構造（/wp/ サブディレクトリ + WP外のアセット）に注意する
• カスタム投稿タイプ（CPT）を削除したら、最小再現でUIを復元する

順番に見ていきます。

ハマり1: URL置換はDBだけでは終わらない

WordPressのデータには、本番ドメインのURLが大量に埋め込まれています。これを新ドメインに置換しないと、テスト環境から本番にリンクが飛んでしまう。

wp search-replace を使うのが基本ですが、DBの置換だけでは不十分でした。URL置換は3層あります。

層1: データベース

wp search-replace 'https://example.com' 'https://staging.example.com' \
  --all-tables --precise --recurse-objects

--all-tables で全テーブル、--recurse-objects でシリアライズされたデータ内のURLも置換します。シリアライズ＝配列やオブジェクトを文字列に変換して保存したデータ形式で、文字数情報を含むため単純な文字列置換だと壊れることがある。だから専用オプションが要ります。

層2: テーマPHPファイル内のハードコード

DBの置換では、テーマのPHPファイルに直接書かれたURLは消えません。

# テーマディレクトリ内のハードコードされたURLを一括置換
grep -rl 'https://example.com' wp-content/themes/yourtheme/
# → 該当ファイルに sed -i で一括置換
sed -i 's|https://example.com|https://staging.example.com|g' \
  wp-content/themes/yourtheme/**/*.php

テーマによっては数十ファイルにURLがハードコードされています。grepで洗い出してから一括で潰すのが速い。

層3: サブドメイン参照（保護が必要）

サブドメイン（例: blog.example.com）への参照は、テスト環境でも本番のものを使いたい場合があります。これは置換せず保護する。意図せず置換すると、サブドメインへのリンクが壊れます。

置換してはいけないもの

wp_posts テーブルの guid カラムは、URLの形をしていますが置換禁止です。GUIDはWordPressの慣例で「外部識別子」として永続的に使われるもので、表示には影響しません。置換するとRSSフィードの購読者などに影響が出る可能性があります。

ハマり2: アセットがWordPressの外にある構造

多くの制作会社が作るWordPressサイトには、特殊な構造があります。

example.com/
├── wp/          ← WordPress本体（サブディレクトリ）
├── common/      ← CSS/JS（WordPressの外）
└── img/         ← 画像（WordPressの外）

WordPress本体を /wp/ サブディレクトリに置き、CSS・JS・画像は /common/ や /img/ などWordPressの外に配置するパターンです。

この構造が厄介なのは、WordPressのバックアップツール（.wpress など）が wp-content だけをバックアップする仕様だから。つまり /common/ や /img/ 配下がテスト環境に欠落して、CSSも画像も読み込まれません。気づかずに展開すると、見た目が完全に崩れた状態でスタートすることになります。

対処：WP外アセットを別途取得して配置

サイトマップから全ページのURLを取得し、各HTMLから /common/ /img/ への参照をgrepで抽出して、まとめてダウンロードしてからテストサーバーに配置します。

# 1. 各ページのHTMLから /common/ /img/ 参照を抽出
# 2. 並列curlで一括取得
# 3. tar + scp でテストサーバーの public_html 直下に展開

これでアセットが揃い、レイアウトが本番と同等に再現されました。

ハマり3: カスタム投稿タイプ（CPT）を削除すると画面が崩れる

CPT（Custom Post Type）＝WordPress標準の「投稿」「固定ページ」以外に自分で定義する投稿タイプ。症例記事やお知らせなどがこれにあたります。

テスト環境では、本番の大量の投稿を削除して軽くしたいことがあります。個人情報を含む問い合わせ履歴なども消したい。

ところが、CPTの投稿を全削除すると、それらを表示するセクションが「まだ記事はありません」表示になり、UIが崩れてしまう。

対処：CPTを最小再現してダミー投稿を入れる

CPTの登録自体を mu-plugin（must-use plugin、常時有効なプラグイン）で復元し、各CPTにダミー投稿を数件入れます。

// wp-content/mu-plugins/restore-test-cpts.php
// テスト環境用にCPTを最小構成で再登録
register_post_type('case', [...]);
register_taxonomy('case_category', 'case', [...]);

そして各CPTに5件ずつダミー投稿を作り、グリッドが埋まるようにします。

副次的なハマり：テーマがWP_Queryを直接newする場合

テーマによっては、投稿一覧を pre_get_posts フィルタではなく WP_Query を直接 new して取得しています。この場合、フィルタで絞り込みを上書きできない。そこでタクソノミー（カテゴリ）の term を実体として作り、ダミー投稿に紐付けるアプローチが必要になりました。

「どのカテゴリページでも記事が表示される」状態を作るには、テーマが参照するtermをすべて作成して、ダミー投稿に全部紐付けます。

ハマり4: クローラー遮断は4層で多重に守る

テスト環境がGoogleにインデックスされると、本番と重複コンテンツ扱いになり、SEO上の事故になります。これは絶対に防ぎたい。

1つの方法だけだと設定ミスで漏れるので、4層で多重防御します。

特にBasic認証が強い。認証情報を知らないクローラーは中身に一切アクセスできません。テスト環境には必ずBasic認証をかけます。

クローン作業チェックリスト

複製の各工程を抜け漏れなく進めるための一覧です。上から順に潰していくと、4つのつまずきを踏まずに済みます。

完了チェック

複製が成功したかは、次で確認します。

• 複数viewport（スマホ/タブレット/PC）でレイアウトが本番と同等か
• 404になっているアセットがゼロか（CSS/JS/画像が全部ロードされているか）
• 「記事がありません」表示がゼロか（CPTのダミー投稿が効いているか）
• 本番ドメインへのリンクが残っていないか（URL置換の漏れ確認）

ブラウザの開発者ツールでNetworkタブを見て、404が出ていないかチェックするのが確実です。

アンチパターン3つ

アンチパターン1: DBのURL置換だけで終わらせる

wp search-replace でDBを置換しても、テーマPHPのハードコードURLは残ります。テスト環境から本番にリンクが飛ぶ原因No.1がこれ。DBとテーマファイルの両方を置換します。

アンチパターン2: クローラー遮断を1層だけにする

「noindex metaタグを入れたから大丈夫」は危険です。設定ミスや反映漏れで漏れます。Basic認証を含む4層で多重に守るのが正解。

アンチパターン3: CPT削除後のUI崩れを放置する

投稿を消すと「記事がありません」だらけになり、レイアウト確認ができなくなる。CPTの最小再現とダミー投稿でUIを復元してから検証に入ります。

まとめ：複製は「URL3層 + クローラー4層」で守る

本番WordPressをテスト環境に完全複製する手順は、次の4つに集約されます。

1. URL置換は3層（DB / テーマPHPハードコード / サブドメイン保護）、guidは置換しない
2. WP外のアセット（/common/ /img/）は別途取得して配置する
3. 削除したCPTは最小再現とダミー投稿でUIを復元する
4. クローラー遮断は4層（Basic認証 / HTTPヘッダー / metaタグ / WP設定）で多重防御する

「バックアップを展開すれば終わり」と思って始めると、URL・アセット・CPT・インデックスの4つで必ずつまずきます。これらを最初から押さえておけば、本番と同等のテスト環境を安全に作れて、改修を安心して試せるようになりました。

WordPress運用・改修でお困りなら

WordPressの改修は、安全なテスト環境があるかどうかでリスクとスピードが大きく変わります。「本番をいじるのが怖くて改修が止まっている」「ステージングを作ろうとしたがURLやアセットの欠落でつまずいた」という状態は、ステージング環境の設計を一度整えれば解消できます。

f2t.jpでは、WordPressのテスト環境構築から、安全な改修フロー（ステージングから本番への反映）の設計まで一貫してお手伝いしています。お問い合わせフォームからお気軽にどうぞ。