WordPressのサーバー移行は、初心者であれば All-in-One WP Migration や Duplicator のようなプラグインを使って進めることが多いかと思います。この記事ではあえて、再現性と切り分けやすさを重視するプロ向けの手動手順を紹介します。共用サーバーからVPSへ移す場合は、移行元と移行先の両方にSSHで入れる状態を作り、データベースとファイルを分けて移し、hostsで新環境を確認してからDNSレコードを切り替える流れで進めます。
この記事は概要版として、wp db export、rsync、wp-config.php の設定、必要に応じた wp db create、wp db import を使う手動移行の全体像を整理します。移行先はVPSを想定し、KUSANAGIを含む一般的なLAMPまたはLEMP構成でも読めるようにしています。なお、メール移行は本記事の対象外です。MX、SPF、DKIM、DMARC、SMTPまわりは別の記事で詳しく解説します。
- プラグインではなく、プロ向けの手動移行フローを把握できます。
- 共用サーバーからVPSへ移すときの準備チェックリストを確認できます。
- SSH設定、DBエクスポート、rsync、
wp-config.phpの設定、DB作成、DBインポート、hosts確認、DNS切替の流れを把握できます。 - エックスサーバー VPS を移行先候補として見るときの基準が分かります。
- 速度改善が出やすい箇所と、PageSpeedが必ずしも大きく変わらない理由が分かります。
先に結論
この手順は、初心者向けの最短ルートを目的とはしていません。プラグインに頼らず、ログとコマンドで状態を確認しながら丁寧に進めたい方に向いている手順です。どこで何を移し、どこで問題が起きたかを追いやすく、同じ移行を何度も再現しやすい点が大きな特徴です。
WordPressのサーバー移行を手動で行うなら、旧サーバーでDBを書き出す、新サーバーでファイルを受け取る、移行先の wp-config.php を整える、hostsで確認してからDNSを切り替えるという流れを意識して進めると、大きな事故を避けやすくなります。ドメインをそのまま使う移行でもこの順番は同じです。
- 手順1 移行元と移行先のSSH接続を確認し、VPS側の受け皿を作る
- 手順2 移行元で
wp db exportを実行してSQLを退避する - 手順3 移行先VPSから
rsyncでWordPressファイルを取得する - 手順4 移行先で
wp-config.phpを設定し、必要に応じてwp db createの後にwp db importを実行する - 手順5 hostsファイルでローカルから新サーバーを確認する
- 手順6 DNSレコードを切り替え、SSLと公開後監視を行う
よくある勘違いとして、wp export を使えばWordPress全体を移せると思われがちですが、これは投稿や固定ページをXMLで書き出す機能です。サーバー移行で必要なのはDB全体の移動なので、ここでは wp db export を使います。
移行前の準備チェックリスト
手順に入る前に、次の項目を揃えてください。ここが曖昧なまま進めると、移行作業そのものより事前準備の不足で詰まりやすいです。
- 移行元の共用サーバーと移行先VPSの両方でSSH接続できる
- 移行先VPSでWebサーバー、PHP、DB、ドキュメントルートが用意できている
- 移行元のフルバックアップを取得済みである
- 移行作業中に記事更新、フォーム送信、会員登録が集中しない時間帯を選ぶ
- PHPのメジャーバージョン差と必須拡張の有無を確認する
- 独自SSLはDNS切替後に再発行または再設定する前提で考える
- DNSレコードのTTLは可能なら前日までに短くしておく
- 旧サーバーは切替直後に解約せず、最低でも48時間から72時間は残す
wp export と wp db export の違い
wp export はWordPress標準のエクスポート機能をCLIから呼び出すもので、投稿、固定ページ、カスタム投稿、タクソノミーなどをXMLとして出力します。これはコンテンツ移送には使えますが、オプションテーブル、プラグイン設定、ユーザー情報、シリアライズされたデータまで丸ごと持っていく用途には向きません。
共用サーバーからVPSへWordPressをそのまま引っ越すなら、必要なのは wp db export です。こちらはDB全体をSQLで書き出せるため、wp db import と対で使えます。ファイル側は rsync、DB側は wp db export と覚えておくと混乱しません。
ロリポップで WP-CLI を使う準備
ロリポップでは、VPSのように最初から wp コマンドが使えるとは限りません。そのため、wp-cli.phar を自分のホームディレクトリに置き、PHPバイナリを明示して実行する準備が必要です。手元の検証では /usr/local/php/8.4/bin/php で動きましたが、このパスは契約プランやPHPバージョンで変わる可能性があります。
mkdir -p ~/bin
curl -fL -o ~/bin/wp-cli.phar https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x ~/bin/wp-cli.phar
/usr/local/php/8.4/bin/php ~/bin/wp-cli.phar --info
毎回長いコマンドを書くのが大変なら、ラッパーを1つ作っておくと扱いやすくなります。
cat > ~/bin/wp <<'EOF'
#!/bin/sh
exec /usr/local/php/8.4/bin/php "$HOME/bin/wp-cli.phar" "$@"
EOF
chmod +x ~/bin/wp
export PATH="$HOME/bin:$PATH"
wp --info
もしラッパーを作らないなら、この記事中の wp を /usr/local/php/8.4/bin/php ~/bin/wp-cli.phar に読み替えてください。ロリポップから移行する場合は、この準備を最初に済ませておくと後の作業が進めやすくなります。
WordPressサーバー移行の全体フロー
全体像は次のとおりです。重要なのは、公開切替より前に新環境の確認を終わらせることです。
旧サーバー
├─ SSH接続確認
├─ wp db export でSQL退避
└─ 読み出し元として維持
移行先VPS
├─ 初期設定とサイト受け皿作成
├─ rsync でファイルを取得
├─ wp-config.php を設定
├─ 必要に応じて wp db create
└─ wp db import でDB復元
手元PC
├─ hosts で新サーバーを強制参照
└─ フロント、管理画面、フォーム、画像を確認
公開切替
├─ DNSレコード変更
├─ SSL確認
└─ ログとエラー監視
| 工程 | 主な作業 | 目的 |
|---|---|---|
| 事前準備 | SSH確認、VPS初期設定、バックアップ取得 | 戻せる状態を作る |
| データ退避 | wp db export でSQLを書き出す | DBを安全に移す |
| ファイル転送 | rsync でWordPress一式をコピー | テーマ、プラグイン、uploadsを移す |
| 復元 | wp-config.php 設定、wp db create、wp db import | 移行先でWordPressを起動させる |
| 事前確認 | hostsでローカル確認 | DNS変更前に不具合を潰す |
| 公開 | DNSレコード変更、SSL確認、監視 | 本番切替を完了する |
WordPressサーバー移行の手順
手順1 SSH接続確認と移行先VPSの初期設定
最初にやるべきことは、移行元と移行先の両方へ安定してSSH接続できる状態を作ることです。毎回IPアドレスやポート番号を打つより、~/.ssh/config に別名を切っておくほうが安全です。
Host wp-old
HostName old.example.jp
User olduser
Port 10022
IdentityFile ~/.ssh/id_ed25519
Host wp-new
HostName 203.0.113.10
User admin
Port 22
IdentityFile ~/.ssh/id_ed25519
ssh wp-old
ssh wp-new
移行先VPSでは、少なくとも次の受け皿を先に作っておきます。KUSANAGIを使う場合も考え方は同じで、プロビジョニングやドキュメントルート作成を先に済ませてからファイルとDBを入れます。
- OS更新と公開鍵認証の確認
- NginxまたはApache、PHP、MariaDBまたはMySQLの用意
- 対象ドメインのドキュメントルート作成
- DB名、DBユーザー、権限、接続情報の確定
KUSANAGI の provision を使う場合は、DBや wp-config.php があわせて用意されることがあります。一方、通常のLAMPやLEMP環境では、このあとの手順で wp-config.php とDB接続先を手動で設定する前提で進めます。
この段階でSSLまで仕上げようとしなくても大丈夫です。DNS切替前は証明書発行の条件がまだ揃わないこともあるため、まずはWordPressが問題なく起動する状態を優先すると進めやすいです。
手順2 移行元でDBをエクスポートする
次に、移行元のWordPressディレクトリでDBを書き出します。ファイルだけを移しても、投稿本文、設定、プラグインの状態は復元できません。まずSQLを確保してください。
ssh wp-old
cd /home/olduser/public_html
wp db export ~/backup/site-$(date +%F).sql --add-drop-table
ロリポップのように標準の wp コマンドがない環境では、この段階のコマンドを /usr/local/php/8.4/bin/php ~/bin/wp-cli.phar db export ~/backup/site-$(date +%F).sql --add-drop-table のように読み替えます。
余裕があれば、出力したSQLとは別にホスティング会社のバックアップ機能でも世代を残しておくと安心です。切替直前にコメントや注文データが入るサイトでは、更新停止時間を短くする段取りも事前に決めてください。
手順3 移行先VPSから rsync でファイルをコピーする
ファイル移行は、移行先VPS側から rsync で取りにいく構成が扱いやすいです。転送途中で止まっても再実行しやすく、差分だけ拾えるのが利点です。ここでは移行先が移行元へSSH接続できる前提にしています。
ssh wp-new
rsync -avz --progress -e 'ssh -p 10022' \
--exclude 'wp-content/cache/' \
--exclude '.git/' \
[email protected]:/home/olduser/public_html/ \
/home/kusanagi/example.com/DocumentRoot/
- 最初の実行では
--deleteを付けないほうが安全です。 - キャッシュディレクトリや一時ファイルは除外して問題ありません。
wp-config.phpを丸ごと上書きすると、移行先のDB接続情報が戻ることがあります。- ドキュメントルートの末尾スラッシュを誤ると配置先が一段ずれるので注意してください。
共有ホスティング側の制限でサーバー間SSHが難しい場合は、手元PCを中継して rsync する方法もあります。この記事では説明を分かりやすくするため、まずはサーバー間転送を前提にしています。
手順4 移行先で wp-config.php を設定し、DBを作成してからインポートする
ファイルが揃ったら、まず移行先の wp-config.php を確認します。KUSANAGI で provision 済みなら、DBと wp-config.php が作成済みのことが多いため、値が合っているかを確認してからインポートへ進めます。通常のLAMPやLEMP環境では、移行先DBの接続情報へ書き換えたうえで、必要に応じて wp db create を実行し、その後に wp db import を行います。
cd /var/www/html
vi wp-config.php
define( 'DB_NAME', 'example_db' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'example_password' );
define( 'DB_HOST', 'localhost' );
この4項目は、移行先で使うDB名、DBユーザー、DBパスワード、DBホストに合わせます。DBユーザーの作成や権限付与は、あらかじめMySQLやMariaDB側で済ませておく必要があります。
ssh wp-new
cd /home/kusanagi/example.com/DocumentRoot
wp db create
wp db import /home/admin/backup/site-2026-03-29.sql
wp option get home
wp option get siteurl
wp rewrite flush --hard
wp cache flush
すでにDBが作成済みなら wp db create は省略して構いません。順序としては、wp-config.php の接続先を合わせる、必要なら wp db create を実行する、その後に wp db import を実行する、という流れで考えると整理しやすいです。
ここで確認するのは、DB接続、PHP拡張、パーミッション、アップロードディレクトリ、cron、キャッシュプラグインの状態です。移行元がApache、移行先がNginxのようにWebサーバーが変わる場合は、.htaccess の内容がそのまま効かないこともあります。
もしドメインを変更するなら、次のように置換を入れます。逆に、ドメインそのままの移行では、通常はこれを実行しなくて大丈夫です。
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid
手順5 hostsでローカル動作確認を行う
DNSを切り替える前に、手元PCのhostsファイルでドメインを新サーバーIPへ向け、表示確認を行います。これを省くと、公開後にトップは見えるのに管理画面が壊れている、フォームだけ送れない、といった事故を見逃しやすいです。
203.0.113.10 example.com www.example.com
- トップページと主要下層ページ
- 管理画面へのログイン
- 画像とダウンロードファイルの参照
- お問い合わせフォームや決済導線
- プラグインのエラー有無
- HTTPS化後の混在コンテンツやリダイレクトループ
hosts確認は、公開切替の前にできる最後の安全装置です。MacとWindowsで編集方法は違いますが、概要版ではまず「DNSより前に確認する」という原則だけ押さえておけば十分です。
手順6 DNSレコードを変更して公開後を監視する
動作確認が終わったら、最後にDNSレコードを新サーバーへ向けます。ここで大切なのは、ネームサーバーを丸ごと変えるのか、AレコードまたはAAAAレコードだけを変えるのかを切り分けて考えることです。共用サーバーからVPSへ移るだけであれば、対象レコードの切替だけで進められることが多いです。
- AレコードまたはAAAAレコードを新サーバーIPへ変更する
- Cloudflare利用時はプロキシ設定とSSLモードを再確認する
- DNS反映後にSSL証明書を発行または再設定する
- ブラウザキャッシュとサーバーキャッシュをクリアする
- アクセスログ、PHPログ、Webサーバーログを確認する
- 旧サーバーは数日残し、必要ならDNSを戻せるようにしておく
メールはこのタイミングでは分けて考えるほうが安心です。まずはWebだけを切り替え、メールは別の記事の手順で切り分けて進めると確認しやすくなります。
共用サーバーとVPSのコスト差は月額だけで見ない
WordPressのサーバー移行を考えるとき、比較されがちなのは月額料金ですが、実務では運用時間もコストです。単サイトを安定公開したいだけなら共用サーバーのほうが総コストで有利なことは多く、複数サイト運用や自動化まで考えるとVPSが逆転しやすくなります。
| 比較項目 | 共用サーバー | VPS |
|---|---|---|
| 初期設定 | 管理画面中心で軽い | OS、Webサーバー、DB、権限設定が必要 |
| 運用工数 | 低い | 高い |
| メール | 同梱されることが多い | 別サービス設計が必要になりやすい |
| 自由度 | 提供範囲の中で使う | 高い。構成を自分で決められる |
| 複数サイト統合 | 制限に当たりやすい | まとめやすい |
| 向いている状態 | 単サイト、更新頻度低め、運用を簡単にしたい | 複数サイト、自動化、高速化、学習を両立したい |
つまり、WordPressのサーバー移行でVPSを選ぶ理由は、単にサーバー代を下げたいからではなく、自由度と運用効率を取りにいくためと考えたほうが判断しやすいです。
移行で速度はどこまで変わるか
2026年3月17日から2026年3月24日までの7日間、3時間ごとに取得した自サイト検証では、共用サーバーのエックスサーバー スタンダードと、移行先候補として見やすい XServer VPS 2GB で、サーバー内部の応答差がかなり大きく出ました。
| 指標 | エックスサーバー スタンダード | XServer VPS 2GB |
|---|---|---|
| 外部TTFB 7日平均 | 0.185秒 | 0.130秒 |
| 内部TTFB 7日平均 | 0.510秒 | 0.058秒 |
| WP eval 7日平均 | 1.738秒 | 0.816秒 |
| REST API 7日平均 | 0.025秒 | 0.036秒 |
内部TTFBは約0.510秒から0.058秒まで縮んでおり、WordPress実行系の余裕はかなり増えています。特に管理画面や非キャッシュページ、バッチ処理では、この差が運用体感に効きやすいです。
一方で、PageSpeed Insightsはサーバー移行だけで劇的に跳ねるとは限りません。同じ7日分のログで平均すると、モバイルとデスクトップのスコア差は次の程度でした。
| 指標 | エックスサーバー スタンダード | XServer VPS 2GB |
|---|---|---|
| PSI モバイル平均スコア | 96.7 | 95.0 |
| PSI モバイル平均LCP | 2587ms | 2547ms |
| PSI デスクトップ平均スコア | 99.2 | 99.5 |
| PSI デスクトップ平均LCP | 732ms | 733ms |
ここから言えるのは、VPS化はバックエンドの安定化に効きやすいが、PageSpeed全体はテーマ、画像、JavaScript、CDN設定にも強く左右されるということです。WordPressサーバー移行をする価値はありますが、速度改善の評価はTTFBと運用体感まで含めて見るべきです。
エックスサーバー VPS は移行先候補になるか
結論から言うと、エックスサーバー VPS はWordPressの移行先候補として十分に検討できます。今回の7日集計では最速ではなかったものの、外部TTFB 0.130秒、内部TTFB 0.058秒、WP eval 0.816秒で、共用のエックスサーバー スタンダードよりは明確に余裕がありました。
- 共用サーバーから同系統サービスでVPSへ上げたい人には理解しやすい選択肢です。
- KUSANAGIや独自のNginx設定、WP-CLI運用に進みたい人とも相性が悪くありません。
- ただし、VPSの価値は性能だけで決まるものではありません。日々の運用を無理なく続けられるかもあわせて見ておきたいところです。
つまり、「エックスサーバー VPS だから」という理由だけで決めるのではなく、共用サーバーの制限がボトルネックになっているか、SSHとLinux運用を無理なく回せるかを基準に判断すると選びやすくなります。
エックスサーバー VPS を検討している場合は、キャンペーン時期によって初回利用料金の割引が案内されることがあります。最新の条件を確認したい場合は、以下のバナー先もあわせて確認してみてください。
移行で失敗しやすいポイント
- wp export と wp db export を混同する。XMLだけでは、サイト全体の移行には足りません。
- rsync の転送先パスを誤る。ディレクトリが一段ずれて配置されることがあります。
- wp-config.php を無造作に上書きする。移行先のDB接続情報や鍵が戻ることがあります。
- hosts確認を飛ばして先にDNSを切り替える。公開後の確認が難しくなります。
- メールを同日にまとめて移す。Webとメールを同時に触ると切り分けが難しくなります。
- 旧サーバーをすぐ解約する。ロールバックしにくくなります。
よくある質問
ドメインはそのままでWordPressのサーバー移行はできますか
できます。実務では、ドメインはそのままにして移行先VPSを先に用意し、hostsで新環境を確認してからDNSレコードだけを切り替える形が扱いやすいです。ドメイン変更がない分、URL置換も不要になることが多いです。
手動移行とプラグイン移行はどちらがよいですか
初心者が一度だけ移すなら、まずはプラグイン移行のほうが取り組みやすいかと思います。一方で、共用サーバーからVPSへ移して今後も運用を続けるなら、SSH、rsync、WP-CLIで手順を残したほうが再現性が高く、トラブル時の切り分けもしやすくなります。この記事は、そのようなケースを想定した概要版です。
移行料金はどのくらいかかりますか
自分で進めるなら主な追加コストはVPSの契約と作業時間です。代行を使うと作業は軽くなりますが、料金はサイト規模、メール有無、会員機能、EC機能の有無で大きく変わります。料金だけでなく、作業後に自分で運用できる状態にすることも重要です。
ダウンタイムはゼロにできますか
完全なゼロは難しくても、かなり小さくはできます。hosts確認を先に済ませ、TTLを短くし、DNS切替後もしばらく旧サーバーを残しておけば、体感上の停止時間はほぼ出さずに移行できるケースが多いです。
Mac / Windows 両対応の完全マニュアルはこちら
この記事は、共用サーバーからVPSへWordPressを手動移行する流れを把握するための概要版です。実際に作業する場合は、移行元・移行先の確認、KUSANAGI側の準備、Mac / Windowsそれぞれの操作、コマンド実行例、確認ポイント、切り戻しまで含めて手元で追える形にしておくと安全です。
具体的なコマンド付きで進めたい場合は、noteの 共用サーバー → KUSANAGI VPS WordPress移行マニュアル【Mac / Windows 両対応 / 全コマンド付き】 を確認してください。
まとめ
WordPressのサーバー移行を手動で安全に進めるなら、作業の核心はシンプルです。移行元では wp db export、移行先では wp-config.php の確認と必要に応じた wp db create、その後の wp db import、そして公開前の hosts 確認という流れで整理できます。
- 移行前にSSH、バックアップ、VPS受け皿を揃える
- DBとファイルを分けて移し、
wp-config.phpとDB作成手順を確認したうえでインポートする - hostsで動作確認してからDNSを切り替える
- メールは別工程として切り離し、旧サーバーは数日残す
VPSそのものの向き不向きを先に整理したい場合は、VPSとは何か。レンタルサーバーとの違いを完全解説もあわせて読むと判断しやすくなります。ドメイン変更を伴う移行なら、wp-cliを使用してWordPressサイトのURLを変更する方法も役立ちます。


Comment