WordPressの移転では、ファイルだけをコピーしても記事や設定は移りません。データベースだけでは画像やテーマが欠けます。両方を同じ時点で取得し、新しい接続情報へ合わせた後に、実際のドメインで動く状態を検証します。使うツールより先に、整合した一組を作る工程を決めます。

現環境と変更点を移転票へ記録する

WordPress本体・PHP・データベース・テーマ・プラグインの現在の版を記録します。Site Healthの情報も構成確認に使えます。独自テーマや外部API、定期処理がある場合は通常のページ確認だけでは足りません。移転先で変わるPHPやWebサーバーの条件を特定し、互換性を検証する対象を決めます。

ドメインを維持する移転と、URLも変える移転を分けます。同じURLなら主に接続先が変わりますが、URLが変わるとデータベース内の参照も対象です。マルチサイトは単一サイトと構造が異なるため、通常手順をそのまま適用しません。メールやDNS全体の移転は別工程とし、WordPress作業者が変える範囲を明記します。

ファイルとデータベースを同じ時点で取得する

移転前に公開担当と更新停止時間を決めます。ファイルを取得した後に画像が追加され、データベースを取得した後に記事が更新されると、新環境の参照がずれます。更新停止が難しいサイトは初回コピー後に差分を反映する方法を用意します。注文や予約を持つサイトでは、保守画面の使い方も業務担当と合意します。

バックアップにはWordPressの全ファイルとデータベースを含めます。プラグインを使う場合も、対象・容量上限・復元先の条件を公式情報で確認します。特定ツールだけを前提にせず、元データを別の安全な場所へ残します。取得後はファイル数とデータベースの出力結果を確認し、旧環境を復元できる一組として保管します。

新環境では接続情報と実行条件を合わせる

新しいデータベースへデータを入れ、WordPressファイルを正しい公開先へ置きます。データベース名・利用者・パスワード・ホストが変わる場合はwp-config.phpを新環境へ合わせます。秘密情報を作業記録へ貼り付けず、権限を限定して管理します。ファイル所有者と書き込み権限も移転先の標準設定に従います。

PHPの版を上げる場合は、移転と更新を一度にした影響を把握します。新サーバーで旧環境に近い版を選べるなら、まず移転だけを成立させてから段階的に更新できます。選べない場合は、テーマとプラグインを検証環境で確認します。エラー表示を公開画面へ出さず、ログから原因を切り分けます。

URL変更はシリアライズされたデータを壊さずに行う

ドメインや設置パスが変わると、投稿本文以外にも旧URLが残ることがあります。データベースの単純な文字列置換は、テーマやウィジェットが保存したシリアライズデータを壊す可能性があります。WordPress公式は安全な移行方法を案内しており、WP-CLIのsearch-replaceはシリアライズされたデータを扱えます。実行前に必ずデータベースを保存します。

置換は最初に--dry-runで対象件数を確認し、範囲を決めて実行します。主キーや変更不要な列まで一律に書き換えません。同じドメインを維持するサーバー移転なら、URL置換自体が不要な場合があります。問題が画像URLなのかキャッシュなのかを確認し、必要な変更だけを行います。

DNS切り替え前に業務機能まで検証する

確認端末だけを新環境へ向け、トップページ以外も確認します。ログイン・記事編集・画像追加・検索・フォーム・予約など、サイト固有の機能を操作します。パーマリンクとリダイレクトも対象です。ページが表示されても、管理画面から保存できなければ移転の合否は出せません。

キャッシュを一度消し、PCとスマートフォンで確認します。SSL証明書の発行条件がDNS切り替え後になる場合は、事業者の手順へ合わせます。検証中に本番の外部サービスへ通知や決済を送らないよう接続先を確認します。合格項目と保留項目を記録し、重大な保留がなくなってからDNSを変更します。

最終差分と旧環境の終了を別工程にする

切り替え直前に更新停止を行い、初回コピー後のファイルとデータベース差分を反映します。反映後に主要機能を再確認し、その時点を新環境の開始点として記録します。DNS変更後は社外回線からアクセスし、新環境へ到達しているかを確かめます。旧環境へ投稿が入っていないかも監視します。

旧サーバーは表示確認だけで解約しません。一定期間の更新・フォーム・監視を確認し、最終バックアップを取得します。新環境の契約情報と復元手順を台帳へ反映してから旧契約を終了します。移転後にPHP更新や不要プラグイン整理を行う場合は別の変更として計画し、移転不具合と混同しないように進めます。