WordPressの記事を別サイトへ移す前に｜エクスポート・画像・公開範囲の確認

WordPressの記事を別のサイトへ移すときは、移行する内容、移行先の公開範囲、画像やリンク、戻す方法を先に決めます。エクスポートできたことと、移行先で正しい記事を読めることは別です。書き出したXMLを、サイト全体のバックアップとは扱いません。

本記事は、一部の記事や固定ページを引き継ぐ企業・制作会社向けです。サーバー・メール・ドメインをまとめて移す場合はサーバー移行の確認表へ分け、本記事では投稿データの範囲と移行後の検収を説明します。

1. 移す記事と、移行先での状態を決める

元の投稿ID、URL、タイトル、種類、カテゴリ、著者、公開状態を一覧にします。公開記事だけか、下書きも含むか、コメントや独自項目を扱うかを決めてください。資料の移行を理由に、公開許可のない下書きまで相手へ渡さないようにします。

元の記事を、残すかどうかも別に決める

取り込みは、元記事の削除やURL変更を自動で決定する作業ではありません。移行先の公開、元サイトの扱い、重複する公開情報の方針、リダイレクトなどは影響を確認し、承認された範囲で進めます。

対象件数だけでなく、代表的な記事を選びます。長文、表、画像、独自ブロック、外部埋め込み、特殊な入力項目を含む記事は、本文だけの投稿と分けて試験すると不足を見つけやすくなります。

2. エクスポートと、全体の復元点を分ける

WordPressのエクスポートの公式説明では、投稿などをWXRというXMLへ書き出す手順と、種類・期間・著者・状態などの絞り込みを確認できます。出力の対象は、使用する投稿タイプ等の対応も含めて実際のファイルで確認してください。

XMLには投稿データ等が含まれますが、テーマ、プラグイン、DBの全設定、画像ファイルそのものを含む完全な復元点とは限りません。必要なDBとファイルのバックアップは別に取得し、保存結果と取り出せる経路を確認します。

移行元だけでなく移行先の現行状態も保管します。移行先の既存記事を上書きしたり、分類や著者が混ざったりする影響を、試験前に確認してください。

3. 書き出しファイルの範囲と内容を読む

正規の権限でツールのエクスポートを開き、対象と絞り込み条件を指定します。保存後は、ファイル名・取得日・元サイト・条件・件数の確認結果を記録します。ダウンロード操作を押しただけで成功としません。

ファイルを共有する前に、中身を確認する

下書き、コメント、メールアドレス、独自項目などが含まれる場合があります。共有先と利用目的に合う範囲かを確認し、公開用の共有フォルダーへ無条件で置かないでください。確認用の台帳にも秘密情報を貼り付けません。

ファイルが空、不完全、開けない場合は条件と取得結果を確認します。未確認のファイルを取り込んでから原因を探す順番にはしません。

4. 画像は、取得と保存先と本文参照を揃える

本文が移っても、画像が元サイトのURLを参照したままになることがあります。移行方式で画像を取得するのか、移行先へ保管するのかを確認し、画像ファイルと本文の参照先を照合してください。

画像の権利、使用許可、表紙と本文画像、サイズ別の画像、代替テキストも確認します。元サイトを停止した後に見えなくなる外部参照がないか、公開ページで実際に画像を取得して確かめます。

元のファイルが制限されている場合、取得のために広く公開する前提を置きません。管理者が許可した移行方法を選び、取り込み先のメディア件数だけで全画像の移行完了としないでください。

5. 取り込みは、試験環境と少量の代表記事で確かめる

WordPressのインポートの公式説明では、元の形式に応じた取り込み方法を確認できます。必要な追加機能、著者の割当、画像の扱い、対応する投稿タイプを、採用する方式と現在の環境で照合します。

テスト先から通知や公開が発生しないか見る

取り込みで追加された記事が公開されるか、外部連携・メール・定期処理が動くかを先に確認します。テスト環境の分離を参照し、実利用者へ通知する状態で試さないようにします。

代表記事を取り込み、期待する状態・分類・著者・本文が保存されたかを読み戻します。結果が不明なら、同じファイルを続けて投入せず、現在の投稿を確認してください。

6. 元記事と移行先を、対応表で照合する

元IDと先ID、両方のURL、本文、画像、分類、著者、日時、状態を一組にします。同じタイトルだけで照合すると、別記事や重複取り込みを見落とすことがあります。

移行先のテーマで、表・図・目次・独自ブロックが読めるか、PC・スマホ・途中の幅で確認します。内部リンク、PDF、問い合わせ先、外部埋め込みも開き、元サイトへ戻ってしまう案内を探します。

全件をどこまで照合したか記録します。数件だけ確認したなら、残りを未確認と残してください。検索への掲載や問い合わせ成果は、移行品質の検収とは別の観察です。

7. 失敗・再処理・本番反映を、現在状態から判断する

途中で止まった場合は、実行記録と移行先の投稿・画像を照合します。一部が作られているなら不足を特定し、重複を避ける方法と戻す範囲を担当者と決めます。

全体を戻す前に、他者の変更を確認する

移行開始後に他の記事が更新されている場合、DB全体を巻き戻すとその変更を失います。戻す対象、復元点、追加媒体の扱いを確認し、投稿単位や移行対象の範囲で復元できるかを検討します。

本番前には、元データの更新差分と移行先の現行状態を再確認します。公開対象・順序・担当・戻し方を合意し、移行後の更新をどちらで続けるかも引き継ぎます。

8. 移行の依頼は、データと実装・検収を分ける

自社で整理できるのは対象記事、公開許可、権利、必要な分類と運用担当です。企業向けWeb支援には更新業務と移行後の管理を、制作会社向け実装支援には環境、独自項目、デザイン、対応表、検収条件を共有します。

相談窓口へ、元と先の概要、対象件数、特殊な記事、希望する状態、残す運用を伝えてください。方式・費用・公開やURL変更の範囲は、現行環境を確認して決めます。

解決状態は、合意した記事と画像が正しい先で読め、分類・導線・更新を引き継げ、失敗時の戻す範囲が分かることです。XMLを作っただけでは完了にしません。

一次資料の確認日：2026年10月8日。