本番のWordPressを変更せず、Localに検証用コピーを作ります。必要なのは同じ時点のwp-contentとデータベースSQLです。本番へ戻す移行やマルチサイトの複製は、この手順には含みません。
1. バックアップを用意する
サーバーのバックアップ機能などで、テーマ・プラグイン・アップロード画像を含むwp-contentとSQLを取得します。元のバックアップは編集せず別に保管します。個人情報や認証設定が含まれるため、共有フォルダーや公開URLへ置きません。
2. 別名のローカルサイトへインポートする
Localの公式インポート手順に沿って、wp-contentとSQLを含むZIPをLocalへ読み込みます。既存のローカルサイトに上書きせず、検証用と分かる別名を付けます。本番や既存ローカルDBのテーブルを一括削除する操作は不要です。
コピー側のSMTP、決済、Webhook、外部API、予約処理など、本番へ通信する設定を起動前に確認します。設定を調べられない場合はコピーを実運用サービスに接続したままテストしません。
3. コピー側のURLを確認する
Localで対象のサイトを選び、Site Shellを開きます。以下は読み取り専用です。表示されたURLがコピー側を指すか確認してください。インポートで既に変換されていれば、追加の検索置換は不要です。
wp option get home
wp option get siteurl4. URLが残る場合だけ検索置換する
下記のexample.comとexample.localは例です。実際の完全なURLへ置き換え、http/httpsとwwwの有無を合わせます。ドメインだけを置換するとメールアドレス等も変える可能性があります。必ずコピー側のShellでdry-runを先に実行してください。
wp search-replace "https://example.com" "http://example.local" --skip-columns=guid --dry-run対象と変更件数が意図どおりなら、コピー側のDBをもう一度退避し、dry-runを外して実行します。
wp search-replace "https://example.com" "http://example.local" --skip-columns=guidWP-CLIの公式仕様ではシリアライズされたデータも扱います。ここではGUIDを変更せず、通常の対象テーブルに限定します。独自テーブルやマルチサイトを一括で含めるオプションは、対象を把握せず追加しません。
5. 表示と送信先を確認する
トップ、投稿、画像、管理画面、フォームの送信先を確認します。PCとスマホ幅で本番との差を見て、エラーがあればPHPバージョンとログから調べます。プラグインを切り分ける場合はコピー側で一つずつ停止し、ファイルをまとめて削除しません。
管理画面の配色やサイト名を検証用と分かるものにし、作業中のURLも毎回確認します。コピー側の変更を本番へ戻すときは別の移行計画が必要です。
失敗した場合の戻し方
本番はそのまま残し、失敗したコピーを停止します。元のバックアップから別名のサイトを作り直し、原因となった変更だけを避けて再確認します。アップロード上限を一律20GBへ変えたり、ログイン情報をコマンド履歴へ残したりする旧手順は採用しません。
このページは公式手順に基づく単一サイトの案内です。最新版Localでの画面操作と実際のサイト移行は今回未検証です。



