WordPressの移行では、記事だけでなく、画像・入力項目・テーマ・プラグイン・外部連携を確認します。管理画面のエクスポートで取得したXMLだけでは、サイト全体を再現できるとは限りません。移すデータと再構築する機能を分けて計画しましょう。
移行対象を4つに分ける
| 区分 | 対象例 | 確認すること |
|---|---|---|
| コンテンツ | 投稿、固定ページ、画像、分類 | 件数、本文、画像の参照先 |
| 表示・入力 | テーマ、カスタム投稿、独自項目 | 新環境でも表示・更新できるか |
| 運用設定 | ユーザー、権限、フォーム、定期処理 | 必要な動作と担当者 |
| 外部環境 | サーバー、メール、計測、ライセンス | 接続情報と継続利用条件 |
同じWordPressでも、独自投稿の定義や表示コードがテーマ側にある場合があります。データだけ入れても一覧に出ないときは、投稿タイプや必要な機能が新環境にあるか確認します。
XMLとサイト全体のバックアップは違う
WordPressのエクスポートは投稿などを移すためのものです。テーマやプラグイン本体、サーバー設定まで一式を保存するバックアップとは用途が違います。画像もXMLに画像ファイル自体が埋め込まれるわけではありません。
移行前にはファイルとデータベースを含む復元手段を用意し、別環境で戻せるか確認します。WordPress公式のバックアップ資料でも、この二つを対象にしています。
本番切替前に試すこと
記事件数、画像、カテゴリ、独自入力欄を照合し、フォーム送信、サイト内検索、自社更新を試します。移行後のURLが変わるなら、旧URLとの対応も確認します。
データ内のURLを変更するときは、WordPressのデータ形式に対応した方法を使います。単純なSQL置換で設定を壊すことがあるため、バックアップと試行結果を確認してから本番へ反映します。
移行後の記事重複に注意する
投稿のXMLを読み込む操作は、既存記事を指定どおり上書きする専用の更新処理とは違います。取り込み方法や記事の識別条件によって、スキップや重複が起こり得ます。既存の記事を差し替えたい場合は、投稿タイプとスラッグなどで対象を特定して更新する方法を確認します。
本番で試行錯誤せず、検証環境で件数とURLを照合します。記事本文だけでなく、抜粋、カテゴリ、アイキャッチ、独自項目も確認し、移行で変えるものと維持するものを先に整理します。
切替と戻し方を決める
公開直前の追加記事をどう移すか、旧サイトの更新を止める時間があるかを決めます。切替後にフォームや予約データが増えた場合、古いバックアップへ丸ごと戻すと失われる可能性があるため、差分をどう守るかも担当者と確認します。
移行完了はトップの表示だけで判断せず、管理画面から更新できることと、問い合わせが届くことまで確認しましょう。