WordPressサーバー移行

WordPressサーバー移行の安全な手順|プラグイン5種の選び方と復旧方法

WordPressのサーバー移行は、プラグインを実行するだけでは完了しません。移行方式の選択、復元できるバックアップ、テスト、DNS切替、公開後確認、ロールバックを一つの計画として進めます。サイト条件に合うプラグインの選び方と、安全に止める判断基準まで実務順に整理しました。

公開 2024.12.05 最終更新 2026.07.24 執筆・検証 Finite Field 編集部
WordPressサーバー移行先を検討するためのサーバーラック
既存記事のサーバー写真を継続使用しています。特定の移行先や性能を示す画像ではありません。

移行結果はサイト容量、PHP・データベースの互換性、プラグイン、権限、DNS、メール構成によって変わります。本記事は失敗ゼロ、停止時間ゼロ、検索順位の維持を保証しません。公式資料は2026年7月24日に確認し、料金やキャンペーンではなく復旧可能性を優先して編集しています。この記事にアフィリエイトリンクはありません。

この記事でわかること

最初にツールを決めるのではなく、戻せる状態を作ってから移行します。

移行前提の整理

URL変更の有無、サイト容量、更新停止の可否、メールやDNSの管理場所を洗い出せます。

プラグインの選び分け

5種を順位付けせず、アーカイブ、バックアップ、データベース、外部サービスという方式で比較します。

安全な作業順序

バックアップ、テスト移行、差分反映、DNS切替、公開後確認を順番に実行できます。

復旧の判断基準

どの異常で作業を止め、旧環境へ戻すかを移行前に決められます。

WordPressサーバー移行は「条件」と「戻し方」から選ぶ

同じドメインを維持するサーバー移転と、ドメインやURL構造も変えるサイト移転では必要な作業が異なります。さらに、更新頻度、容量、複雑な機能、機密データ、移行先の制限によって安全な方法は変わります。まず次の4点を確認してください。

URLは変わるか

同じURLのままホスティングだけ変えるなら、コンテンツとURLを維持して接続先を切り替えます。ドメインやディレクトリを変えるなら、旧URLと新URLの対応表、恒久的リダイレクト、canonical、サイトマップ、Search Consoleまで計画します。

容量とサーバー制限に収まるか

WordPressファイル、uploads、データベース、バックアップを別々に計測します。PHPのアップロード上限、実行時間、空き容量、ファイル数、データベース権限が不足すると、インポートが途中で止まることがあります。

更新を止められるか

注文、会員登録、予約、コメント、フォーム送信が続くサイトは、最初のコピー後にもデータ差分が生じます。メンテナンス時間、最終差分の反映方法、利用者への案内、担当者を決めます。

誰が認証情報とデータを扱うか

サーバー、SFTP、データベース、DNS、WordPress管理者の認証情報を確認します。外部移行サービスへデータを渡す場合は、社内ルール、個人情報、契約、保存・削除方針も確認します。

バックアップがあることと、復元できることは別です

移行プラグイン内だけにバックアップを置かず、旧サーバーとは別の場所へファイルとデータベースを保存してください。少なくとも一度はテスト環境へ復元し、管理画面、画像、フォーム、ログイン、注文など重要機能が動くことを確認します。復元テストをしていないバックアップだけで本番切替を始めないでください。

WordPress移行プラグイン5種の選び方

人気順や総合順位ではなく、作業方式と制約で選びます。無料・有料機能、対応容量、外部保存先、移行先要件は更新されるため、実行前に各公式ページと利用環境で確認してください。

Duplicator

アーカイブとインストーラーで複製したい場合

サイトをパッケージ化し、移行先へ展開する方式です。移行先に既存WordPressがない構成も検討しやすく、同じ構成を複製したい場合に向きます。作成前に容量、除外対象、サーバーの実行条件を確認します。

注意: 大きなアーカイブは作成・転送・展開時の容量と実行時間を消費します。失敗後に中途半端なファイルを残さないよう、空の移行先または隔離したテスト領域で試します。

WordPress.orgの公式掲載ページを確認

All-in-One WP Migration

エクスポートとインポートを画面中心で進めたい場合

移行元から専用ファイルを書き出し、移行先のWordPressへ取り込む方式です。管理画面で完結しやすい一方、移行先へWordPressとプラグインを用意する工程があります。

注意: 取り込めるファイルサイズはPHPやホスティング環境、利用する拡張機能の条件に左右されます。書き出せたことだけで完了とせず、移行先でのインポートと動作確認まで試します。

WordPress.orgの公式掲載ページを確認

UpdraftPlus

日常バックアップと復元手順を移行にも生かしたい場合

ファイルとデータベースのバックアップ・復元を中心とするプラグインです。通常運用のバックアップを整えながら移行準備を進めたいサイトで候補になります。

注意: 移行や複製、保存先によって無料版と有料機能の範囲が異なります。バックアップ一式がそろっているか、暗号化や外部保存、復元手順が運用要件を満たすかを確認します。

WordPress.orgの公式掲載ページを確認

WP Migrate Lite

データベースとURL置換を理解して管理したい場合

データベースの検索・置換やエクスポートを扱う管理者向けの選択肢です。ドメインやパスを変更する移行で、どの値を置換するか確認しながら進めたい場合に適します。

注意: WordPressデータにはシリアライズされた値があります。SQLを単純な文字置換で編集するとデータを壊す可能性があるため、プレビュー、バックアップ、対象確認を行い、理解できない置換を本番へ適用しません。

WordPress.orgの公式掲載ページを確認

Migrate Guru

対応ホスト間を外部サービス経由で移したい場合

移行処理を外部サービス側で行う方式です。大きなサイトやホスト間移行で、サーバー自身の負荷を抑えたい場合の候補になります。移行先にWordPressを準備するなど事前条件があります。

注意: ローカル環境や一部のマルチサイト変換など、公式ページに非対応条件があります。外部サービスへのデータ送信が社内規程や契約に適合するかも確認してください。

WordPress.orgの公式掲載ページを確認

移行開始前に揃える6つの準備

本番作業中に調べ始めると、停止時間と誤操作が増えます。移行元・移行先・DNSを別々に整理し、実施者と確認者が同じ計画を見られる状態にします。

準備 01

サイトと周辺サービスを棚卸しする

WordPress本体、テーマ、プラグイン、uploads、データベース、PHP・データベースの版、cron、Basic認証、CDN、WAF、外部ストレージ、送信メール、アクセス解析、決済・予約連携を一覧にします。DNSゾーンとメールが同じ事業者にあるかも確認します。

準備 02

容量・権限・互換性を確認する

移行先のPHP、データベース、HTTPS、拡張モジュール、書込み権限、アップロード上限、最大実行時間、空き容量が現在のサイトに合うか確認します。WordPressの公式要件は最低条件であり、利用テーマやプラグインの要件も別に確認します。

準備 03

独立したバックアップを作り、復元する

WordPressファイルとデータベースを同じ時点で取得し、旧サーバー外へ保管します。バックアップ日時、対象、作成方法、暗号化、保管場所、復元担当を記録し、テスト環境で復元します。メールボックスやDNS設定はWordPressバックアップに含まれない場合があります。

準備 04

更新停止と連絡方法を決める

注文や投稿を止める時間、管理画面へ入れる人、利用者への案内、障害連絡先、最終判断者を決めます。更新を止められないサイトは、差分同期を扱える移行方法または専門家による手順を選びます。

準備 05

DNSと旧環境の保持期間を決める

権威DNS、現在のTTL、A・AAAA・CNAME・MX・TXTレコード、CDNやプロキシの有無を記録します。切替後すぐ旧契約を解約せず、ロールバックとメール確認に必要な期間を確保します。

準備 06

成功条件と中止条件を書く

主要URLが200、管理画面ログイン、画像表示、フォーム受信、注文・決済、メール、定期処理、SSL、計測が正常という成功条件を決めます。同時に、どの異常で切替を中止するかも数値や操作で判断できる形にします。

WordPressサーバー移行前の不安点をノートパソコンで確認する担当者
既存記事のイメージ写真です。移行前は、作業を始める前に不明点と復旧手順を解消してください。

WordPressサーバー移行を安全に進める8ステップ

具体的なボタン名はプラグインやホストで異なりますが、安全上の順序は共通します。各段階の証跡を残し、確認が終わるまで次へ進みません。

  1. 1

    作業計画と変更凍結を共有する

    作業日時、対象、担当、連絡先、成功条件、中止条件、復旧手順を共有します。投稿、注文、会員登録など差分が生じる操作をいつ止めるか決め、開始直前の状態を記録します。

    • 変更凍結の開始時刻と対象操作を明記した
    • 作業者以外の管理画面アクセスを制限した
  2. 2

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

    WordPressファイルとデータベースを同じ時点で取得します。取得後にハッシュ値やファイルサイズを記録し、別の保存先へ複製します。プラグインのエクスポートだけでなく、ホスト側バックアップや手動取得など独立した復旧経路を用意します。

    • wp-content、wp-config.php、データベースを確認した
    • 旧サーバー外の保存先から読み出せる
  3. 3

    移行先を隔離して準備する

    PHP、データベース、SSL、権限を設定し、公開DNSを変えずにテストできるURL、hosts設定、またはステージング環境を使います。検索エンジン向けnoindexだけに頼らず、必要なら認証やアクセス制限で外部公開を防ぎます。

    • 本番URLへ誤公開されない
    • 移行用の一時認証情報を管理している
  4. 4

    選んだ方式でテスト移行する

    プラグインの公式手順に従ってアーカイブ、エクスポート、復元、または外部サービス移行を実行します。ログ、警告、除外ファイル、置換結果を保存し、エラーを無視して先へ進みません。ドメイン変更時はシリアライズデータに対応した置換方法を使います。

    • エラーと警告を担当者が確認した
    • 除外したデータを別手順で移した
  5. 5

    URLと重要機能をテストする

    トップだけでなく、代表的な投稿、カテゴリ、検索、404、管理画面、画像、フォーム、ログイン、決済、予約、メール、cron、APIを確認します。キャッシュを消した状態とログインしていない状態でも試します。

    • PCとスマートフォンで主要導線を確認した
    • フォームや注文は受信側まで確認した
  6. 6

    本番直前の差分を反映する

    更新停止後に増えた投稿、注文、会員、コメント、アップロードを反映します。データベース全体を上書きするとテスト環境の設定や本番の新規データを失う場合があるため、サイト特性に合う差分方法を決めます。判断できない場合は作業を止めます。

    • 差分の始点と終点を記録した
    • 件数や最新レコードを移行元と照合した
  7. 7

    DNSまたは接続先を切り替える

    DNSレコード、CDN、ロードバランサーなど実際の接続先を計画どおり変更します。旧環境を停止せず、どちらへ接続しているかをレスポンスヘッダー、専用確認ファイル、サーバーログなどで識別します。DNSの反映時間は利用者ごとに異なります。

    • A・AAAA・CNAMEを想定どおり更新した
    • MX・TXTなどメール関連レコードを意図せず変えていない
  8. 8

    公開後確認と監視を行う

    複数回線と主要ブラウザで確認し、5xx、PHPエラー、404、証明書、混在コンテンツ、フォーム、メール、注文、ログイン、cron、アクセス解析を監視します。問題がなければ更新停止を解除し、旧環境は計画した期間保持します。

    • 公開直後・数時間後・翌日の確認担当を決めた
    • 旧環境の解約日を検証完了後に設定した
WordPressサーバー移行後の確認をノートパソコンで行う担当者
既存記事のイメージ写真です。完了判断は表情ではなく、定めたチェック項目とログで行います。

移行に失敗したときのロールバック手順

復旧は、障害が起きてから考えるものではありません。切替前に戻す条件、旧環境の状態、DNSの戻し先、バックアップの場所、復旧担当を確認します。原因調査より先に、利用者への影響を止める判断が必要な場合があります。

次の状態では切替続行を止める

  • 管理画面へ入れない、または致命的エラーや5xxが継続する
  • 注文、決済、会員登録、予約、問い合わせなど主要取引が完了しない
  • 移行元と移行先で注文数、会員数、最新投稿など重要データが一致しない
  • SSL、DNS、メール、認証、外部APIの問題を予定時間内に解消できない
  • 画像やファイルの欠落、URL置換ミス、権限エラーが広範囲にある
  1. 復旧 01

    変更と新規受付を止める

    移行先で投稿、注文、登録が増え続けないようメンテナンス状態にし、障害発生時刻、症状、直前操作、ログを保存します。無計画に再実行を重ねません。

  2. 復旧 02

    旧環境または直前スナップショットへ戻す

    旧環境が健全なら接続先を戻します。復元が必要なら、同一時点のファイルとデータベースを組み合わせます。片方だけ古い状態へ戻すと、参照不整合が生じる場合があります。

  3. 復旧 03

    接続先とキャッシュを確認する

    DNS、CDN、ブラウザ、サーバーキャッシュを確認し、利用者が実際にどの環境へ接続しているか識別します。DNSを戻しても全利用者が即時に旧環境へ戻るとは限りません。

  4. 復旧 04

    取引データを照合し、再計画する

    障害中の注文や問い合わせをログ、決済事業者、受信メールと照合します。原因、影響、復旧時刻、失われた可能性のあるデータを記録し、修正と再テスト後に別の切替日時を決めます。

DNS切替のロールバックは即時ではありません。キャッシュやTTLにより新旧環境への接続が混在します。両環境で更新を受け付けるとデータが分岐するため、更新停止と接続先の識別を維持してください。

サーバー移行でSEOを守る確認事項

サーバー移行だけで検索順位が上がる、または必ず維持されるとはいえません。検索エンジンと利用者が同じ内容へ到達できる状態を保ち、クロールエラーや重複を減らします。

URLを変えない移行

既存URL、本文、title、canonical、robots、サイトマップ、構造化データ、HTTPステータスをできるだけ維持します。公開前のテスト環境に付けたnoindexやアクセス制限を本番へ残さず、主要URLを移行前後で比較します。

ドメインやURLを変える移行

旧URLと新URLを一対一で対応させ、関連性のある新URLへ恒久的リダイレクトを設定します。すべてをトップへ転送しません。内部リンク、canonical、hreflang、サイトマップを新URLへ更新し、Search Consoleとログで監視します。

Googleは大きな変更を一度に重ねないよう案内しています

Googleのサイト移転資料は、URL変更を伴う移転で、新サイトの準備と十分なテスト、旧URLと新URLの対応、恒久的リダイレクト、監視を案内しています。また、ドメイン変更、CMS変更、デザイン変更を同時に重ねず、一つずつ変更する考え方を示しています。移転中は一時的な検索順位変動が起こり得るため、短期の変化だけで設定を繰り返し戻さず、クロール・インデックス・サーバーログを確認します。

旧記事に掲載していたサーバー画面

既存記事にあったスクリーンショット5点は削除せず、撮影時点の資料として残します。ただし、いずれも移行操作画面ではなく、2025年8月1日頃に表示された各社の案内・キャンペーン画面です。現在の料金、特典、移行機能、提供条件を判断する根拠には使えません。

撮影時点のサーバー画面5点を表示する
2025年8月1日頃のXServerビジネス公式サイトの画面
XServerビジネスの旧画面。撮影時点の資料であり、現在のキャンペーンや移行条件を示しません。
2025年8月1日頃のエックスサーバー公式サイトの画面
エックスサーバーの旧画面。契約前に現在の公式料金、無料移行、対象条件を確認してください。
2025年8月1日頃のConoHa WING公式サイトの画面
ConoHa WINGの旧画面。表示されている期間限定情報を現行情報として扱いません。
2025年8月1日頃のカラフルボックス公式サイトの画面
カラフルボックスの旧画面。過去の周年案内を含むため、現在の特典や移行機能とは分けて参照してください。
2025年8月1日頃のロリポップ公式サイトの画面
ロリポップの旧画面。現在のプラン、移行代行、対象サイト条件は公式サイトで確認してください。

移行後に確認するチェックリスト

トップページが表示できるだけでは完了ではありません。利用者の主要タスクと運用者の定期処理まで確認し、結果と確認者を記録します。

ページと管理画面

  • トップ、投稿、固定ページ、カテゴリ、検索、404が想定どおり
  • 管理画面へログインでき、投稿・画像アップロード・更新ができる
  • 画像、PDF、CSS、JavaScriptに404や権限エラーがない
  • PC・スマートフォンと主要ブラウザで表示崩れがない

取引と通知

  • 問い合わせフォームを送信し、受信側と自動返信まで届く
  • ログイン、会員登録、パスワード再設定が完了する
  • 注文、決済、予約、在庫、通知が実際の業務手順で一致する
  • cron、キュー、Webhook、外部APIが予定どおり動く

SSL・DNS・メール

  • 証明書が有効で、HTTPからHTTPSへ意図どおり転送される
  • 混在コンテンツ、リダイレクトループ、www有無の不一致がない
  • A・AAAA・CNAME・MX・TXTを移行前記録と比較した
  • 送受信メール、SPF、DKIM、DMARCへの影響を確認した

SEO・監視・復旧

  • robots、noindex、canonical、サイトマップ、構造化データを確認した
  • 重要URLのHTTPステータスとリダイレクト先を一覧で検査した
  • 5xx、404、PHPエラー、負荷、バックアップを監視できる
  • 旧環境、バックアップ、復旧手順を保持し、解約条件を満たした

参照した公式資料

WordPressの移行・バックアップ・動作要件、Googleのサイト移転、各プラグインの現行説明は、次の公式ページを2026年7月24日に確認しました。各プラグインの提供者による性能・容量の表現は保証として転記せず、適合条件と制約の確認に使用しています。

WordPressサーバー移行のよくある質問

WordPress移行プラグインを使えば停止時間をゼロにできますか?

保証できません。DNS反映、最終差分、キャッシュ、外部サービスにより新旧環境が混在します。更新が続くサイトでは短い更新停止、差分同期、負荷分散など別の設計が必要です。停止許容時間を先に決めて方式を選んでください。

無料プラグインだけで大きなサイトを移行できますか?

容量だけでは判断できません。ファイル数、PHP上限、実行時間、空き容量、データベース、外部ストレージ、マルチサイト、更新差分によって難易度が変わります。テスト環境で一連の復元が完了しない場合は、ホストの移行支援や専門家を検討してください。

移行後、旧サーバーはすぐ解約してよいですか?

すぐには解約しないでください。DNSの混在、遅れて見つかる機能不良、メール、バックアップ、ロールバックに備え、契約期限と費用を確認したうえで保持期間を決めます。問題なく運用でき、必要データを別場所へ保管した後に解約します。

ドメインを変えると検索順位は必ず下がりますか?

必ずとはいえませんが、Googleはサイト移転中に一時的な順位変動が起こり得ると説明しています。URL対応表、恒久的リダイレクト、内部リンク、canonical、サイトマップ、Search Console、ログ監視を準備し、CMSやデザインの大幅変更を同時に重ねない方が原因を切り分けやすくなります。

自分で移行すべきか、依頼すべきかの境目は何ですか?

復元テストを完了できない、注文や会員データを止められない、DNSとメールの管理場所が不明、マルチサイトや独自システムがある、失敗時の事業影響が大きい場合は依頼を検討してください。作業前に対象、停止時間、復旧方法、費用、責任範囲を書面で確認します。

移行前後に読む関連ガイド

最適な移行方法は、最も速い方法ではなく確実に戻せる方法

WordPressサーバー移行では、ツール名より先に、URL変更、容量、更新差分、互換性、機密性、停止許容時間を確認します。独立バックアップを復元し、隔離環境でテストし、公開後の成功条件とロールバック条件を決めてから切り替えてください。プラグインはその計画を実行する手段であり、安全を保証するものではありません。

この記事の編集・検証方針

Finite Field 編集部

WordPress、サーバー、Web制作の記事を、利用者が自分で条件を確認し、危険な作業を止められる順序へ編集しています。公式資料を優先し、失敗ゼロ、順位維持、期間限定価格など確認できない断定を避けます。

自分で移行できない・失敗時の影響が大きい方へ

WordPressのサーバー移行とサイト制作を相談できます

バックアップを復元できない、DNSやメールの構成がわからない、注文・会員データを止められない、自分でサイトを作れない場合は、現在のURL、利用サーバー、希望時期、困っていることをお知らせください。Finite Fieldが、事前調査、移行計画、Webサイト制作、公開後確認の対応範囲を整理します。

サーバー移行とサイト制作を相談する

内容を確認し、対応可否、作業範囲、停止時間の見込み、費用が発生する場合は事前に説明します。無停止や検索順位の維持は保証しません。