WordPress移行ガイド｜プラグイン・サーバー機能・手動を比較

WordPressの移行では、サイトのコピーが完了しても、すぐに旧サーバーを止めてはいけません。新サーバー上で表示と機能を試し、SSLを用意してからDNSを切り替え、移行後の通信が落ち着くまで旧環境を残す必要があります。

主な方法は、移行プラグイン、移行先サーバーの専用機能、ファイルとデータベースの手動移行の3つです。この記事では、それぞれを具体的に比較し、移行前の準備から切り替え後の点検までを一続きで解説します。

WordPressの移行・引っ越しとは

WordPressの移行とは、公開中のサイトを別のサーバーや別の設置場所へ移す作業です。「引っ越し」「マイグレーション」「データ移行」とも呼ばれます。

ひとつのサイトは、WordPressのファイルだけでできているわけではありません。移す対象と切り替える対象を分けて考えます。

対象	含まれるもの	主な作業
ファイル	WordPress本体、テーマ、プラグイン、画像	コピーまたは移行ツールで転送
データベース	投稿、固定ページ、設定、ユーザー情報	書き出しと取り込み
ドメイン・DNS	ドメインと接続先情報	新サーバーへ接続先を変更
SSL	HTTPS通信の証明書と設定	新環境で証明書を発行・設定
メール	メールボックス、アドレス、配送先	必要なら別途移行・再設定

サーバーだけを変え、ドメインを維持する場合、訪問者が使うURLは変わりません。一方、ドメインや設置ディレクトリも変える場合は、データベースに残る旧URLの置換と、旧URLから新URLへの転送が加わります。

WordPress標準の「ツール」にあるエクスポート・インポートは、投稿、固定ページ、コメント、カスタムフィールドなどのコンテンツを受け渡すための仕組みです。テーマ、プラグイン、その設定、WordPress本体まで含むサイト全体の複製とは役割が異なります。

WordPressを移行する3つの方法

最初に、3方式の違いを一覧でつかみましょう。

方法	難度	向いているケース	注意点
移行プラグイン	低〜中	一般的な単一サイト、管理画面へ入れる	容量、実行時間、サーバー制限、無料版の範囲
サーバー移行機能	低	移行先が対応し、元サイトが利用条件を満たす	移せないデータや非対応構成を公式案内で確認
手動移行	高	大規模・特殊構成、細かく制御したい	DB操作、権限、URL置換、作業ミスの影響が大きい

記事や固定ページの一部だけを別サイトへ移したい場合は、サイト全体の引っ越しではなく標準インポートが合うことがあります。対象データと手順は「エクスポート・インポートでの移行」で確認してください。

移行プラグインを使う方法

移行プラグインは、ファイルとデータベースをまとめてパッケージ化し、移行先で復元する方式です。FTPやデータベース管理画面を個別に操作する場面を減らせるため、小規模から中規模の一般的なサイトで使いやすい選択肢です。

代表例のDuplicatorは、サイトのファイルとデータベースをバックアップとしてまとめ、別環境へ展開できます。WordPress.orgの公式プラグインページでは、無料版と上位版で、クラウド保存、マルチサイト、ドラッグ＆ドロップ取り込みなどの対応範囲が異なると案内されています。製品名だけで選ばず、自分のサイト規模と必要機能が現在のプランに含まれるかを提供元で調べましょう。

プラグイン方式が失敗しやすいのは、アーカイブがサーバーのアップロード上限を超える、PHPの実行時間が足りない、保存容量に余裕がない、といった場合です。大量の画像やバックアップファイルを含むサイトでは、作成したパッケージの容量も大きくなります。

サーバーの移行機能を使う方法

レンタルサーバーによっては、移行元のURLやログイン情報を入力すると、WordPressを新サーバーへコピーする機能を提供しています。移行先の環境に合わせた処理を任せやすく、対応条件を満たせば作業量を抑えられます。

ただし、メール、DNS、独自のSSL設定まで自動で移るとは限りません。Basic認証、二段階認証、ログインURL変更、アクセス制限、特殊なプラグイン、マルチサイトなどが実行を妨げる場合もあります。機能名が似ていても対象範囲は事業者ごとに違うため、移行元と移行先の条件を公式マニュアルで読みます。

ファイルとデータベースを手動移行する方法

手動移行では、SFTPなどでファイルをコピーし、データベースをエクスポート・インポートして、新しい接続情報を設定します。転送するディレクトリやテーブルを把握でき、プラグインの容量制限を避けやすい反面、技術的な理解が必要です。

特に注意したいのがURL置換です。WordPressのデータには、文字列の長さを含むシリアライズ形式が使われることがあります。SQLファイルをテキストエディターで一括置換するとデータを壊すおそれがあるため、シリアライズを扱える移行ツールやWP-CLIの検索置換機能などを使います。

WordPress移行方法の選び方

一般的な単一サイトで管理画面へ入れるなら、まずサーバー移行機能の対応可否を調べ、使えなければ移行プラグインを検討します。大容量、独自構成、マルチサイト、細かな制御が必要なケースは、手動移行または経験のある担当者による作業が適しています。

条件	移行プラグイン	サーバー機能	手動移行
小〜中規模の単一サイト	向く	対応していれば向く	可能だが作業量が多い
大量の画像・大容量DB	上限を要確認	上限を要確認	転送方法を選びやすい
ドメインを維持	向く	向く	向く
ドメインも変更	製品のURL置換範囲を確認	対応条件を確認	安全なURL置換が必要
マルチサイト	上位版や非対応の場合あり	非対応の場合あり	専門知識が必要
管理画面へ入れない	原則難しい	認証条件により難しい	サーバーアクセスがあれば可能
停止時間を短くしたい	事前復元と差分管理が必要	仮確認機能が有利	工程を設計しやすいが難度が高い

方式を決める前に、サイト容量、PHPとデータベースのバージョン、ドメイン変更の有無、メールの利用先、更新頻度を整理します。会員登録やECのように移行作業中もデータが増えるサイトは、単純な一回コピーでは新規注文や投稿が旧環境に残ります。更新停止時間を設けるか、最終差分を同期する方法まで計画しなければなりません。

移行前の準備チェックリスト

作業日を決める前に、次の準備を終えます。

• ファイルとデータベースを別々にバックアップする
• バックアップの保存先を旧サーバー外にも用意する
• サイト容量とデータベース容量を測る
• 現在のWordPress、PHP、データベースのバージョンを記録する
• 使用中のテーマ、プラグイン、ライセンス、独自コードを一覧にする
• ドメイン管理会社、DNS設定、ネームサーバーを把握する
• SSL証明書を新サーバーで発行できるか調べる
• メールを同じドメインで使っているか確認する
• SFTP、データベース、管理画面の認証情報を用意する
• フォーム、決済、会員登録など停止できない機能を洗い出す
• 切り戻しを決める担当者と判断時刻を決める

バックアップは、移行プラグインが作るパッケージだけに依存しないほうが安心です。復元ツール自体が新環境で動かない場合に備え、元のファイルとデータベースも保存します。取得方法と復元の流れは「移行前のバックアップ」で確認できます。

DNSのTTLを変更できる場合は、切り替えの少なくとも1週間前を目安に、数時間程度の控えめな値へ短くする方法があります。Google Search Centralも、ホスティング変更時のDNSキャッシュ更新を早める方法としてこの進め方を案内しています。ただし、反映済みのキャッシュがすぐ消えるわけではなく、短い値にすれば停止が必ずなくなるわけでもありません。現在のDNS管理先と変更権限を先に把握してください。

メールサーバーも変わるなら、メールアドレス、転送、迷惑メール設定、保存中のメールを別途扱います。WordPressのコピーではメールボックスは移りません。

プラグインでWordPressを移行する基本手順

製品ごとに名称は違いますが、共通する進め方は次のとおりです。

1. 旧サイトの更新を一時停止し、直前バックアップを取ります。
2. プラグインでサイト全体のパッケージを作成します。
3. 作成結果にエラーがなく、ファイル容量が想定と合うかを見ます。
4. パッケージと復元に必要なファイルを安全な場所へダウンロードします。
5. 移行先にドメイン、データベース、SSLなどの受け入れ環境を用意します。
6. 移行先でパッケージを取り込み、URLとデータベース情報を設定します。
7. 管理画面へログインし、パーマリンク設定を開いて再保存します。
8. キャッシュを削除し、DNS切り替え前のテストへ進みます。

実行中にブラウザーを閉じてよいか、分割アーカイブが必要か、元サイトと移行先の両方にWordPressを入れるかは製品によって違います。画面上の案内と公式ドキュメントを優先してください。

All-in-One WP Migrationを使う場合の画面操作や容量制限への対応は「All-in-One WP Migrationの使い方」で扱っています。Duplicatorなど別製品へ、そのまま同じ操作名を当てはめないようにしましょう。

移行が終わったら、移行用ファイルを公開ディレクトリへ放置しません。インストーラーやアーカイブに第三者がアクセスできると、サイトデータや接続情報が漏れる危険があります。製品が示す後片付けを完了し、不要になった移行プラグインも用途を確認して整理します。

サーバー移行機能を使う基本手順

サーバー側の専用機能では、申し込みからテストまでがおおむね次の流れになります。

1. 移行先サーバーに対象ドメインを追加します。
2. 公式マニュアルで、非対応プラグイン、容量、PHP、認証、設置形式などの条件を読みます。
3. 旧サイトのURL、WordPressのログイン情報など、指定された情報を入力します。
4. 移行処理を実行し、完了またはエラーの通知を待ちます。
5. 提供される仮URLや動作確認方法で新環境を開きます。
6. SSL、キャッシュ、フォーム、メールなど、自動移行の対象外を設定します。
7. 問題がなければDNSを切り替えます。

エックスサーバーの「WordPress簡単移行」は、他社サーバーからの移転やURL変更に利用できる一方、移行元・移行先の組み合わせやWordPress内の設定によって利用できない場合があります。Xserver固有の条件と操作は「エックスサーバーへのWordPress移行」で確認してください。

エラーになったときは、同じ処理を繰り返す前にエラーコードと対象条件を見直します。ログインURL変更やアクセス制限を一時的に調整する場合は、元の設定と戻す時点を記録し、移行が済んだら復旧します。

WordPressを手動で移行する流れ

手動作業では、旧環境の複製を新環境に作り、接続先だけを切り替えます。サーバーの管理方法によって操作名が違うため、以下は工程の順序として捉えてください。

1. 旧サーバーからWordPressの全ファイルを取得します。
2. データベースを文字コードや形式を確認してエクスポートします。
3. 新サーバーに空のデータベースと利用者を作成し、権限を設定します。
4. WordPressのファイルを新サーバーへ転送します。
5. 新しいデータベースへSQLデータをインポートします。
6. wp-config.phpのデータベース名、利用者名、パスワード、ホスト名を新環境に合わせます。
7. ドメインを変える場合だけ、シリアライズ対応の方法で旧URLを新URLへ置換します。
8. ファイル権限と所有者を新サーバーの仕様に合わせます。
9. DNSを変えずに新環境を開き、表示と管理画面をテストします。

同じドメインのままサーバーを変えるなら、サイトURLを置換しない構成が基本です。新環境を試すためだけに本番データのURLを書き換えると、テスト後に戻す工程が増えます。

データベース接続エラーが出たら、wp-config.phpの4つの接続値、作成したユーザーの権限、データベースサーバー名を見直します。画像だけ表示されない場合は、uploadsディレクトリの転送漏れ、権限、旧URLの残存を切り分けます。

ネームサーバー変更前に動作確認する

DNSを切り替える前に、自分の端末だけ対象ドメインを新サーバーのIPアドレスへ向けると、訪問者を旧サイトへ残したまま新環境を確認できます。サーバーが用意する動作確認URLを使えることもあります。ただし、仮URLでは本来のドメインと挙動が異なるプラグインやSSLがあるため、提供元の確認方法を選ぶのが確実です。

テストではトップページを眺めるだけでなく、実際の利用経路をたどります。

• 管理画面へログインし、投稿を下書き保存できるか
• 投稿、固定ページ、カテゴリー、検索結果が開くか
• 画像、CSS、JavaScriptがHTTPSで読み込まれるか
• お問い合わせフォームが届くか
• 会員登録、購入、予約などの主要機能が動くか
• パーマリンクと404ページが想定どおりか
• スマートフォンでヘッダーやメニューが崩れないか

ドメインも変更する移行では、旧URLが残る場所、正規URL、サイトマップ、転送を別途整えます。設定の全体像は「URL変更時の設定」を参照してください。

テストが通ったら、直前に増えた投稿、注文、フォーム送信などがないかを調べます。更新が続いていたサイトでは最終データをもう一度移すか、作業時間帯の入力を止めて差分が出ないようにします。その後にDNSまたはネームサーバーを変更します。

移行後に確認する項目

DNS切り替え後は、利用者によって旧サーバーと新サーバーのどちらへ接続するかが一時的に分かれることがあります。自分の端末だけで完了とせず、別回線やDNS確認手段も使って新しい接続先を確かめます。

移行後の点検は、次の順で行うと漏れを見つけやすくなります。

1. ドメインが新サーバーのIPアドレスへ向いているかを見る
2. HTTPからHTTPSへ正しく転送され、証明書エラーがないか試す
3. 公開ページ、管理画面、画像、内部リンク、検索を開く
4. フォームを送信し、管理者側と送信者側のメール到達を確認する
5. 会員、決済、予約などサイト固有の機能をテストする
6. アクセス解析、Search Console、広告計測が継続しているかを見る
7. バックアップ、WAF、定期処理、キャッシュを新サーバー用に設定する
8. エラーログとアクセスログに異常がないか調べる

移行が終わるとサーバー環境、バックアップ先、障害時の連絡先が変わります。以後の管理を止めないよう「公開後の保守・運用」で更新頻度と担当を整理してください。

メールを同じドメインで運用している場合は、送信だけでなく外部アドレスからの受信も試します。旧メールサーバーに届いたメールを一定期間確認できる状態にしておくと、DNSの切り替わり途中の取りこぼしに気付きやすくなります。

移行に失敗する原因と戻し方

失敗時は「データのコピー」「WordPressの設定」「接続先の切り替え」のどこで止まったかを分けます。

症状	考えられる原因	先に行う対処
移行ツールが途中で止まる	容量不足、実行時間、WAF、権限	ログと必要容量を確認し、条件を調整
データベース接続エラー	接続値、利用者権限、DBホスト	wp-config.phpとDB権限を見直す
トップ以外が404	パーマリンク、書き換え設定	パーマリンクを再保存し、サーバー設定を確認
画像やCSSだけ旧URL	URL置換漏れ、キャッシュ	安全な検索置換とキャッシュ削除
HTTPSで警告が出る	証明書未発行、混在コンテンツ	SSL設定と読み込みURLを確認
一部の人だけ旧サイトが見える	DNSキャッシュの残存	反映を待ち、両環境のログを監視

新環境に重大な不具合があり、短時間で直せない場合は、事前に決めた時刻で切り戻します。DNSを旧サーバーへ戻し、旧環境の更新停止を解除します。新環境だけで受け付けた注文やフォームがある場合は、そのデータを失わないよう保全してから戻してください。

旧サーバーを残していても、移行後に旧環境で更新を続けると内容が分岐します。どちらを正本にするかを明確にし、作業中の投稿や注文の扱いを記録しておくことが重要です。

SEOと停止時間への影響を抑えるポイント

サーバーだけを変更し、URLとページ内容を維持できれば、検索エンジンから見えるページの住所は変わりません。それでも、DNS切り替え中のエラー、遅い応答、robots設定の持ち込みなどでクロールに影響する可能性があります。

影響を小さくするため、次を守ります。

• 新環境の動作確認を終えてからDNSを切り替える
• 公開URLとパーマリンクを不用意に変更しない
• ステージング環境の検索除外設定を本番へ持ち込まない
• ドメイン変更時は旧URLから対応する新URLへ恒久転送する
• サイトマップと正規URLを新しいドメインに合わせる
• 移行前後で主要URLのHTTP状態と表示内容を比較する
• 旧サーバーをDNSの移行が落ち着く前に解約しない

停止時間は、コピー時間ではなく、更新停止から新環境で受付を再開するまでで考えます。読み取り中心の企業サイトと、注文が増え続けるECサイトでは許容できる時間も必要な同期方法も違います。アクセスが少ない時間帯を選び、関係者へ開始・終了・切り戻し条件を共有しておきましょう。

よくある質問

まとめ

WordPress移行では、移行プラグイン、サーバー機能、手動作業のうち、サイト容量、構成、操作できる範囲に合う方法を選びます。簡単な方式を選んでも、バックアップ、SSL、DNS、メール、移行後のテストは省けません。

安全な順序は、旧環境を保存し、新環境へ複製し、DNSを変える前に動作確認を行い、切り替え後も旧サーバーを残して監視する流れです。失敗時に戻す時刻と方法まで決めておけば、表示停止やデータの取りこぼしを抑えながら引っ越しを進められます。