WordPressを移行する手順｜URLを変える場合と変えない場合を分ける

何を別の環境へ移すのか、先にそろえる

まず対象のWordPressと旧・新環境、公開URLを変えるかを決めます。この記事は一つの自己ホストWordPressサイトを別の環境へ移す説明です。複数サイトをまとめるMultisiteや、どのホストでも同じ画面で移せる方法を扱うものではありません。

移転前には、どの時点のファイルとデータベースを使うか、更新や注文等をいつ止めるか、何を誰が確認して切り替えるかをそろえます。データベースを短くDBと呼びます。複製中に旧サイトへ投稿が増えれば、その更新を新環境へどう反映するかも必要になります。

戻すときに使う保存と対象を決め、確認前に旧環境を削除しません。バックアップを持つこと、復元を試して戻せると確認すること、今回の移転先で動くことは別です。ファイルを受け取った表だけで移転完了にはしないでください。

管理先、権限、契約やコードの引継ぎをまだ整理していない場合は、制作会社変更のガイドへ接続します。ここでは、その対象と担当が決まったあとの複製・接続・URL参照の扱いを説明します。

制作会社変更時の権限・データ・コードをそろえる

同じURLのまま移す場合は、どうコピーする？

WordPressのファイルとDBを、合意した新環境へそれぞれ複製します。ファイルには本体・テーマ・追加機能・アップロード画像等、DBには投稿や設定等が入るため、片方だけで同じサイトになるとは限りません。

旧環境の管理担当が、対象DBをエクスポートして保存し、対応するWordPressのファイルも保存します。エクスポートはDBの内容を取り出したファイルを作ることです。同じ時点の組として管理し、移転先の担当がファイルを配置して、用意した新環境の対象DBへ保存内容をインポートします。インポートはDBへ取り込む操作です。

管理画面やコピー機能はホストや採用した方式により違います。コピー先のディレクトリとDBを特定し、既存の別サイトへ上書きしない対象を担当がそろえます。新環境の用意や取り込みに使う方法は、現在の管理担当とホストの条件で決めます。

DBの接続先が変わる場合は、コピーしたWordPressの設定ファイルwp-config.phpを新環境に合わせます。DB_NAMEはDB名、DB_USERは接続ユーザー、DB_PASSWORDはそのパスワード、DB_HOSTはDBサーバーの場所です。旧環境の値のまま別DBへ接続していないかを、権限を持つ担当が確認します。認証実値は記事や共有メモへ貼りません。

同じ公開URLで移す場合、そのURLを変えるための置換は不要です。ただし接続先やファイルの配置、環境固有の設定は別に確認します。公開URLが同じことだけで、新環境のDB接続や描画まで確定しないでください。

実際に、別サーバーへの移転で新DBの接続情報をどう扱うかを相談した本人報告があります。後続の本人返答は特定の移行方法の経験であり、どの方式でも接続設定が不要になるという保証ではありません。

参考：WordPress：ファイルとDBのバックアップ・取り込みの関係

参考：WordPress：設定ファイルと接続先の意味

参考：WordPress：DB接続項目の意味（設定項目の説明）

参考：当事者の相談と本人返答：新サーバーのDB接続

URLも変えるなら、基本設定だけで終わる？

URLを変える場合は、基本設定と保存された旧参照を分けて扱います。公開URLの設定を変えた記録があっても、本文中の画像やリンクの参照が全部更新されたことにはなりません。

一般設定の「サイトアドレス」は訪問者がサイトへ来るURLで、homeという設定に対応します。「WordPressアドレス」はWordPress本体の配置URLで、siteurlに対応します。別ディレクトリへ本体を置く構成では二つが違うため、同じ値を機械的に入れません。wp-config.phpの定数で上書きしている場合も、DBに保存された値とは分けて担当が確認します。

以下は説明用の単一サイトの架空記録です。旧新URLが同じ例と、新しい基本設定の記録に旧画像参照が併存する例を比べます。いずれも複製記録はありますが、接続・置換適用・描画・本番切替・原因は未確認です。

図のURLを変える・変えない条件を、項目ごとに読む

公開URLを据え置く例と、公開URLも変える例では、URL設定と保存された参照を確認する条件が違います。後者には新しいURL設定と旧URLの画像参照が併存していますが、画像の404や個別原因を確認した記録ではありません。両例とも複製記録がある段階で、接続・描画・本番切替は未確認です。

両例の共通する設置方式と複製記録

対象の設置方式

単一WordPressサイト

ファイルの複製記録

複製記録あり

DBの複製記録

複製記録あり

同じ時点のセットの記録

同じ時点のセットという記録あり

旧公開URL

公開URLを変えない例

https://site.example.invalid

公開URLも変える例

https://old.example.invalid

予定する公開URL

公開URLを変えない例

https://site.example.invalid

公開URLも変える例

https://renewed.example.invalid

公開URL設定の記録（home）

公開URLを変えない例

https://site.example.invalid

公開URLも変える例

https://renewed.example.invalid

WordPress配置URL設定の記録（siteurl）

公開URLを変えない例

https://site.example.invalid

公開URLも変える例

https://renewed.example.invalid

保存された本文画像の参照

公開URLを変えない例

https://site.example.invalid/wp-content/uploads/sample.png

公開URLも変える例

https://old.example.invalid/wp-content/uploads/sample.png

方法を分ける条件

公開URLを変えない例

公開URLは据置。移転先DBの接続設定と環境確認を行う。URL変更だけを理由にした置換は不要。

公開URLも変える例

home/siteurlの記録だけで全参照更新とはしない。本文や画像等の旧参照を、対象を限定したシリアライズ対応の方法で扱う。

両例とも未確認の作業と結果

移転先DB接続の確認

未確認

URL置換の適用

未確認

本文・画像の描画確認

未確認

本番切替

未確認

個別の原因

未確認

これは説明用の架空記録です。記載のURLへアクセスしたり、DB接続・置換・切替を実行した結果ではありません。

PC原寸画像を開く · モバイル原寸画像を開く

この架空例のhomeとsiteurlは同じ公開URLになっていますが、全サイトで同じという意味ではありません。二例目では画像参照が旧URLのままという保存記録があります。その記録だけから、実画像が404になる、画面が壊れた、個別の原因が確定したとはしません。

更新する対象には本文中の画像・リンクだけでなく、使うテーマや追加機能等が保存した参照が関係する場合があります。どの保存項目が何を指すかを確認し、URLの文字が見つかっただけで全部を置換しないでください。

別ドメインへ変える際に、既存のページや画像を手で作り直すのかと迷う本人の相談もあります。既存内容の複製と、その中に残ったURLの扱いを分ける必要があります。コメントの製品推薦や短時間で終わるという説明を、本稿の完了条件には採用しません。

参考：WordPress：サイトURL・本体URLと移転時の保存参照

参考：当事者の相談：別ドメインへの移転で何をするか

旧URLのまとめ置換は、なぜ方法を選ぶ？

保存形式に合わせた方法を選びます。WordPressのテーマ等が使うシリアライズという保存形式では、文字列とその長さを一緒に保存する場合があります。普通の文字置換だけでは、内容と長さが食い違うことがあります。

次の3行は、架空のASCII文字列の長さを示す説明です。旧URLはUTF-8で27byte、新URLは31byteです。文字だけ替えて27という宣言を残すと、31byteの内容と合いません。最後の行は長さも合う表現の見本で、PHPやDBで正常に使えると試験した結果ではありません。

元の保存表現：s:27:"https://old.example.invalid";
文字だけ替えた表現：s:27:"https://renewed.example.invalid";
長さも合う説明表現：s:31:"https://renewed.example.invalid";

担当が既設のWP-CLIを使える場合には、シリアライズを扱うsearch-replaceが選択肢です。これはコマンドでWordPressを扱うツールです。対象環境のパス、旧新URL、対象テーブルと列、除外する項目を決め、まずdry-runの報告を見ます。dry-runはDBへ変更を保存せずに報告する指定です。

以下はコピーした単一サイトで本文列だけを対象にする説明用の形です。パスもURLも仮の値で、表名wp_postsも実際の接頭辞へ合わせる必要があります。すべての移転にそのまま実行する完成コマンドではありません。

wp --path='/path/to/copied-wordpress' search-replace 'https://old.example.invalid' 'https://renewed.example.invalid' wp_posts --include-columns=post_content --skip-columns=guid --dry-run

–pathは対象WordPressのファイルの場所、wp_postsはこの例の表、–include-columns=post_contentは本文列の限定です。–skip-columns=guidは投稿識別子GUIDを除外する指定です。GUIDは表示URLと役割が違うため、旧URLの文字が含まれるだけで移転用の置換対象にしません。

この限定例は、設定や追加機能の参照まで全部更新するものではありません。担当は対象ごとの報告をレビューし、許可された範囲を確かめてから適用と再確認を行います。dry-runの件数を、置換適用済み・画像表示成功・本番移転完了へ変えないでください。対象が未確定なら、一括の全テーブル指定で埋めません。

参考：WordPress：保存参照・シリアライズとGUIDの注意

参考：WP-CLI：対象の限定、dry-runとGUID除外

切り替える前に、どのページと画像を確かめる？

許可された試験環境で代表的な本文、画像、リンクを開き、新環境から必要な内容を読めるかを確認します。コピーの報告やURL設定の記録だけで画面確認を終えないでください。

トップだけでなく、投稿・固定ページ・画像を使うページ等、対象の違う代表を決めます。開いたURLと本文、読み込まれた画像が、想定した新環境へ対応するかを担当が照合します。管理者だけの表示と、想定する訪問者の公開範囲の表示も分けます。

同じドメインのまま切替前に試す方法は、ホストや試験環境に依存します。試験用URL等の条件を担当と決め、旧公開環境の設定を思いつきで変えないでください。DNSはドメイン名と接続先の対応に関わり、証明書はHTTPSの接続に関わります。それぞれの担当と対象をそろえ、画面が読めたことだけで切替済みにしません。

フォーム・メール・決済等は、画面を見るだけと実際の処理が違うため、許可された試験範囲と確認担当を別に決めます。本稿の複製記録から実送信や決済を実施済みにしません。旧URLからの転送や検索移転は、301リダイレクトのガイドで整理できます。

URL変更時の301リダイレクトと行き先を準備する

コピー、描画、切替を一つの完了にしない

複製・接続・保存参照の扱い・描画確認・切替を分けて記録します。実行した対象と時点に対応する結果だけを残し、説明やコマンドがあることを実移転の証拠にしません。

次の架空例では、ファイルとDBの複製記録はありますが、最終URLがまだ決まっていません。新しい基本設定や画像参照も未確認です。未確認を空のURLや0、成功へ補完して切替を始めないでください。

切替前には、新環境での確認結果、反映すべき旧環境の追加更新、切替する担当と条件、問題時に戻す対象をそろえます。旧環境を保持する期間と担当も合意します。すべてのデータが移った、停止時間がない、検索順位が変わらないと、手順だけから約束しません。

今日の一歩は、旧新環境と「公開URLを変えるか」を一組で書き、複製するfilesとDBを対応させることです。同URLなら新接続先と環境を、URL変更なら基本設定に加えて保存された旧参照の対象を担当と確かめます。未確認の最終URLや処理結果は、そのまま次の確認事項にしてください。