WordPress サーバ移行の基本ガイド【2025年最新版】〜失敗しない手順とチェックリストで安全な移行を実現しましょう〜

  • Published
  • Author 穂苅 智哉
  • コラムカテゴリ Web運用
  • コラムカテゴリ WordPress
  • Bookmark
  • -
    Copy
WordPress サーバ移行の基本ガイド【2025年最新版】〜失敗しない手順とチェックリストで安全な移行を実現しましょう〜

企業がWordPressサイトを運営していると、

  • 「サイトの表示速度が遅い」
  • 「アクセス集中でサーバダウンする」
  • 「現在のサーバのコストが高すぎる」

といった課題に直面することがあります。

そんなとき、サーバ移行は有効な解決策となりますが、

  • 「移行作業は複雑そう」
  • 「データが消えたらどうしよう」
  • 「SEO評価が下がらないか不安」

などの理由で、なかなか一歩を踏み出せない企業も多いのではないでしょうか。

私も以前はそうでした。

そこでこの記事では、企業のWordPressサイト担当者に向けて、
サーバ移行を検討すべきタイミング、具体的な移行手順、そして失敗を防ぐためのチェックリストまで、実践的な内容を解説します。

【こんな方におすすめ！】

  • 現在のサーバに不満があり、移行を検討している企業のWeb担当者
  • サイトの成長に伴い、より高性能なサーバが必要になった企業
  • 移行の失敗を防ぎ、リスクを最小限に抑えたい方

なお、サーバの種類（共用サーバ・VPS・クラウド）について詳しく知りたい方は、まず以下の記事をご覧ください。

おすすめの記事

WordPressサーバ移行とは？なぜ必要なのか？

WordPressサーバ移行とは、現在WordPressサイトが稼働しているサーバ（移行元）から、別のサーバ（移行先）にサイトのすべてのデータ（ファイル、データベース、設定）を移動させることです。

WordPressサイトは主に以下の要素で構成されています。

構成要素内容保存場所
ファイルテーマ、プラグイン、画像、wp-config.php等サーバの特定のディレクトリ
データベース記事、固定ページ、コメント、ユーザー情報等MySQL（MariaDB）等のデータベース
ドメイン設定DNSレコード、SSL証明書ドメイン管理会社

これらすべてを正しく移行先サーバに移動させ、正常に動作する状態にすることが「サーバ移行」です。

企業がサーバ移行を検討する主な理由

そもそも、WordPressのサーバをなぜ移行する必要が出てくるのでしょうか？

お読みいただいている皆さまも、今まさに直面している課題かもしれませんし、将来なんらかの理由が出てくる機会はあると思います。

１．パフォーマンスの向上

課題感：WordPressサイトの表示速度が遅くなってしまい、ユーザー離脱が増えている。打つ手がなかなかない。

少し古い情報にはなりますが、Googleの2018年の調査では、ページ読み込み時間が1秒から3秒に増えると、直帰率が32%増加することが報告されています。（出典：Think with Google – Mobile Page Speed Study）

２．コスト最適化

課題感：サーバ技術の進化により、数年前と同等のスペックが現在はより安価に提供されているケースや今の現状にあわせたサーバスペックにするための見直しが必要な場合。

３．安定性・可用性の確保

課題感：サーバダウンが頻発すると、ビジネスの機会損失になるだけでなく会社のブランディングにも影響が出てしまいます。1時間のダウンタイムによる機会損失は平均約50万円とも言われています（※中規模ECサイトの試算。実際はサイト規模や業種によって異なります）。

４．セキュリティ対策の強化

課題感：古いPHPバージョンしかサポートされていないサーバは、セキュリティリスクが高まります。また、自分たちでサーバのセキュリティ対策をしっかりとやっていくという判断をした場合にはクラウドサーバ等に移行してセキュリティ対策を強化する必要があります。

５．機能・サポートの改善

課題感：自動バックアップ、ステージング環境などの便利な機能や、手厚いサポート体制を求める場合。

サーバ移行を検討すべき6つのサイン

それでは、サーバ移行を検討するサインについてお伝えしていきます。自社のWordPressサイトが、以下の6つのサインに当てはまる場合、サーバ移行を真剣に検討すべきタイミングといえます。

サイン１：サイト表示速度が3秒以上かかる

確認方法： Google PageSpeed Insightsでサイトを測定し、モバイルスコアが50点未満の場合は要注意。特に「TTFB（Time To First Byte：最初の1バイトまでの時間）」の項目が遅い場合は、サーバーの応答速度に問題がある証拠です。

TTFBとは：ブラウザがサーバーにリクエストを送ってから、サーバーが最初のデータを返すまでにかかる時間のことです。いわば「サーバーの反応速度」を測る指標となります。

【TTFBの判断基準】

  • 0.6秒以下：良好
  • 0.6〜1.0秒：やや遅い
  • 1.0秒以上：サーバー性能不足の可能性が高い

TTFBが遅い場合、画像の軽量化やキャッシュプラグインでは改善できず、サーバーそのものの性能アップ（移行）が必要です。

【TIPS：サイト表示の流れとTTFB】TTFBをもう少し身近にするために、普段のWebサイト表示の流れで見てみます。

  1. ユーザーがURLをクリック
  2. ブラウザがサーバーに「ページください」とリクエスト
  3. ⏱️ ←ここがTTFB （サーバーが処理して最初のデータを返すまでの時間）
  4. サーバーからデータが送られてくる
  5. ブラウザが画面を表示

TTFBが遅い原因は？

  • サーバーのCPU・メモリ不足
  • データベースの応答が遅い
  • サーバーの地理的距離が遠い
  • 共用サーバーで他ユーザーの影響を受けている

サイン２：アクセス集中時にサーバダウンや503エラーが発生する

確認方法：自社のWebサイトでアクセスが集中するタイミングで表示速度が遅くなっているか、サイトがしっかり閲覧できているかを確認

テレビ・SNS・ニュースサイトで取り上げられた際、突発的なアクセス増加でサイトが表示されなくなる状況は、ビジネス上の最大の機会損失です。
当社プライム・ストラテジーでも、大規模なメディアサイトなどでは大量アクセスと外部メディアに取り上げられた等で一気に瞬間風速的にアクセスが来るというサイトも保守運用していますが、まさに同じ問題を抱えていました。
せっかくのチャンスに、サーバダウンでサイトが閲覧できない、サイトの表示が激重、ではユーザーは離れてしまいますし機会損失も大きくなります。

サイン３：PHPバージョンが8.1以前でサポートが終了している

確認方法： WordPressダッシュボード → 「ツール」→「サイトヘルス」→「情報」→「サーバ」で確認。PHP 8.3以上の対応が推奨されます。

WordPressサイトヘルス例

WordPress管理画面から確認できる「サイトヘルス」の画面イメージ。問題がある内容は早めに対応しましょう。

【執筆時点での主要PHPバージョンのサポート終了日】

PHPバージョンアクティブサポート終了日セキュリティサポート終了日現在の状態
PHP 7.32021年12月6日2021年12月6日❌ 完全にサポート終了
PHP 7.42021年11月28日2022年11月28日❌ 完全にサポート終了
PHP 8.02022年11月26日2023年11月26日❌ 完全にサポート終了
PHP 8.12023年11月25日2024年11月25日❌ 完全にサポート終了
PHP 8.22024年12月31日2026年12月31日⚠️ セキュリティサポートのみ
PHP 8.32025年12月31日2027年12月31日✅ アクティブサポート中（推奨）
PHP 8.42026年12月31日2028年12月31日✅ アクティブサポート中

※2025年11月時点の情報。最新情報はPHP公式サイトをご確認ください。

サイン４：現在のサーバ費用が同等スペックの他社より明らかに高い

確認方法：Web資産を見直すタイミング（半年に１回、年に１回など）で、今のサーバ費用が現状のサイトにとって適切なのかを社内で議論。

数年前に契約したサーバと同等のスペックが、現在はより安価に提供されているケースは珍しくありません。定期的に見積もり比較を行いましょう。

サイン５：管理画面の動作が重く、記事投稿・編集にストレスを感じる

確認方法：管理画面側の表示速度、動作速度が遅い・重いと感じるかどうか。それによって、記事更新やコンテンツ管理の効率性が損なわれれているのであればすぐ対応。

運営者自身が管理画面の遅さにストレスを感じる場合、コンテンツ制作効率の低下につながり、更新頻度の低下によるSEO評価への悪影響も考えられます。

サイン６：現在のサーバのサポート対応に不満がある

確認方法：現在利用しているサーバやサービスのサポートに満足しているか、していないのであればどうすると改善するのかを考える。

トラブル発生時に迅速かつ的確なサポートを受けられるかどうかは、サーバ選びの重要な基準です。返信が遅い、技術的質問に答えてもらえない場合は移行を検討しましょう。

WordPressのサーバ移行 3つの主要パターン

企業のWordPressサイトにおけるサーバ移行は、主に以下の3つのパターンに分類されます。

パターン１：共用サーバ → VPS（仮想専用サーバ）

適しているケース： 月間アクセスが1~3万PVを超え、共用サーバでは不定期に重くなる。企業管理のサイトのため、必要な対策は自社で行いたい。

VPSの予算：月額3,000円〜10,000円程度
移行の難易度： ★★☆☆☆（中）
代表的なVPSサービス： さくらのVPS、ConoHa VPS、エックスサーバ VPS

パターン２：共用サーバ or VPS → クラウドサーバ

適しているケース： 月間アクセス3~10万PV以上、事業の急成長が見込まれスケーラビリティが必要、高可用性構成（冗長化）が必要。

移行の難易度： ★★★★☆（高）
代表的なクラウドサービス： AWS、Microsoft Azure、Google Cloud、さくらのクラウド
参考記事： WordPressでおすすめのクラウドサーバ4選+サービス

パターン3：同じサーバタイプ内での移行（クラウド→クラウド等）

適しているケース： 現在のサーバ会社のサポートやサービスに不満、より高性能・低価格なサーバが見つかった。

移行の難易度： ★★☆☆☆（中）

WordPressのサーバ移行 基本フロー（8ステップ）

それでは、実際に「サーバ移行をしよう！」となった際ですが、どのパターンの移行でも、基本的な流れは以下の8ステップで構成されます。

ステップ作業内容所要時間目安重要度
1. 事前準備現状確認、バックアップ取得、移行計画策定1~2週間★★★★★
2. 移行先サーバの選定・契約新サーバ契約、WordPress環境セットアップ1週間★★★★☆
3. ファイル・データベースの移行wp-content、データベースのコピー1週間（移行準備、テスト等も含む）★★★★★
4. 移行先での動作確認DNSを切り替える前に新サーバ側でサイトが問題なく動いているのかの動作テスト１日〜１週間程度★★★★★
5. DNS切り替え準備TTL値の短縮、DNS設定情報の確認作業自体は１日程度※切り替え作業の1〜2日前に実施★★★★☆
6. DNS切り替え実施ネームサーバ変更、DNSレコード書き換え１日程度
※ネームサーバの設定が完全に切り替わるまで時間が必要		★★★★★
7. 移行後の最終確認全ページの表示確認、フォーム動作確認等半日〜１日
※関係者で時間を取って一気に確認する		★★★★★
8. 旧サーバの解約問題なければ1ヶ月後に旧サーバ解約1ヶ月後
※２週間〜１ヶ月程度は並行稼働させて、問題が発生していたらすぐに切り戻せるようにしておく		★★★☆☆

具体的なWordPressのサーバ移行手順

ステップ１：事前準備とバックアップ取得

現在のサーバ環境を確認

【確認項目】

  • WordPressバージョン
  • PHPバージョン
  • MySQLバージョン
  • 使用中のテーマ・プラグイン一覧
  • サイト容量（ファイル＋データベース）
  • 独自ドメインの管理会社
  • SSL証明書の種類

完全バックアップを取得

  • プラグイン利用： 「UpdraftPlus」または「BackWPup」
  • 手動バックアップ： FTPクライアント＋phpMyAdmin
  • イメージバックアップ（クラウド等の場合）
おすすめの記事

バックアップ内容

  • ファイル一式（移行対象のWordPressファイル群（DocumentRoot配下（/public_html/配下など）すべて）
  • データベースのエクスポート（.sqlファイル） ダンプファイル
  • wp-config.phpファイル

ステップ２：VPS/クラウドの契約と初期設定

スペックの目安

これは、様々な状況によって変動すると思いますが、よく使われているVPSの価格表を見てみると、おおよその基準がつけられると思います。

ConoHa VPSの場合（https://vps.conoha.jp/pricing/ ）

ConoHa VPSの場合

さくらのVPSの場合（https://vps.sakura.ad.jp/specification/ ）

さくらのVPSの場合

エックスサーバVPSの場合（https://vps.xserver.ne.jp/price.php ）

エックスサーバVPSの場合

通常のWebサイトであれば、CPUは2コア〜4コア、メモリは2GB〜4GBメモリくらいがスタートラインになりますね。

クラウドの場合も同様のイメージで、CPUは2コア〜4コア、メモリは2GB〜4GBメモリ位を1つの基準にするのが良いと思います。AWSのEC2ですと、t3.smallやt3.mediumなどが該当になります。

KUSANAGI（超高速WordPress実行環境）の利用を推奨

KUSANAGIは標準LAMP環境と比較すると2倍〜260倍の高速化を実現し、セキュリティ対策も標準実装されています。主要クラウドサーバ（AWS、Azure、Google Cloud、さくらのクラウドなど）、主要VPS（さくらのVPS、ConoHa、エックスサーバVPS等）で提供されています。

実は、KUSANAGIの推奨スペックも2コアCPU, 4GBメモリです。
https://kusanagi.tokyo/cloud/

KUSANAGI-Logo

ステップ３：ファイルとデータベースの移行

方法１：プラグイン「All-in-One WP Migration」を使う（簡単）

WordPressの有名な移行プラグインとして「All-in-One WP Migration」（https://ja.wordpress.org/plugins/all-in-one-wp-migration/）があります。これを使ってマイグレーションをするのが難易度が高くないためまずは検討範囲となります。

【移行元環境】

  1. プラグインをインストール
  2. エクスポート（.wpressファイルが生成）
  3. ファイルをダウンロード

【移行先環境】

  1. WordPressを新規インストール
  2. 同プラグインをインストール
  3. インポート機能でアップロード

注意： 無料版は512MBまで。それ以上の場合は有料版が必要。

方法２：手動でFTP転送（大規模サイト向け）

FTPクライアント（FileZilla等）で、WordPressが置かれているディレクトリ（/public_html/配下など）をすべてダウンロード→移行先にアップロード。

①データベースの移行

phpMyAdminでエクスポート→移行先でインポート。

②wp-config.phpの書き換え

移行先のデータベース情報に合わせてwp-config.phpを編集します。

// データベース名
define('DB_NAME', '新しいデータベース名');

// データベースのユーザー名
define('DB_USER', '新しいユーザー名');

// データベースのパスワード
define('DB_PASSWORD', '新しいパスワード');

// データベースのホスト名
define('DB_HOST', 'localhost');  // または指定されたホスト名

方法３：手動でサーバから取得し、移設（大規模サイト向け）

当社でもお客様のサイトをサーバ移行する場合にはこの手順で行うことが多いですが、WordPressの移行に必要な「データベースのダンプファイル」「ドキュメントルート内のファイル」「wp-config.php」をサーバから直接取得していく方法です。

※ここは、ざっくりした手順を把握してもらえたら問題ないです。細かいコマンドなどは気にせず読み進めてください。このあたりの内容にご興味がある方は、こちらの記事もご覧ください。https://atmarkit.itmedia.co.jp/ait/articles/1702/06/news006.html

１．データベースのダンプファイルを取得する

cd /var/www
mysqldump -u wpuser -p -h localhost example > example.sql

２．必要なデータ3つを１つのファイルに纏める

cd /var
tar czvfp www.tar.gz www

３．取得したデータを新しいサーバに転送する（以下は、KUSANAGI環境に転送する例）

scp www.tar.gz kusanagi@203.0.113.1:/home/kusanagi/

４．移行先の環境で、移行元のWordPressサイトを再現する（以下は、KUSANAGI環境のプロファイル内に展開する例）

cd /home/kusanagi/
tar zxvfp www.tar.gz

５．データベースのインポート（以下は、KUSANAGI環境内にインポートする例）

cd /home/kusanagi/www
sed 's/ENGINE=MyISAM/ENGINE=InnoDB/g' example.sql > example.InnoDB.sql
mysql -u example -p -h localhost example < example.InnoDB.sql
mysql -u example -p -h localhost example -e 'show table status'

６．展開したファイルを配置（以下は、KUSANAGI環境のプロファイル内に配置する例）

cd /home/kusanagi/example.com
mv DocumentRoot DocumentRoot.def
mv /home/kusanagi/www/html /home/kusanagi/example.com/DocumentRoot
cd /home/kusanagi/example.com/DocumentRoot
mv wp-config.php ../

７．wp-config.phpの内容を修正

/** MySQL データベースのユーザー名 */
define('DB_USER', 'exampleuser');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'Password123!');
define('WP_CACHE', false);
define('WPSM_DISABLE_CACHE', true);
define('WPSM_DISABLE_DEVICE', true);

８．オーナーとパーミッション設定

cd /home/kusanagi/example.com
chown kusanagi.kusanagi wp-config.php
chmod 0644 wp-config.php
chown -R kusanagi.kusanagi DocumentRoot
chmod 0755 DocumentRoot
cd DocumentRoot
find ./ -type d | xargs chmod 0755
find ./ -type f | xargs chmod 0644
chmod 0777 wp-content
cd wp-content
rm advanced-cache.php
chown -R httpd.www uploads
chown kusanagi.kusanagi uploads/.htaccess

９．移設先のWordPress管理画面にログインし、動作と設定の確認を行う

    ステップ４：hostsファイル編集で動作確認

    DNS切り替え前に、必ず移行先サーバで正常動作するか確認します。

    hostsファイルは、自分のPC内だけで利用できるDNSの紐づけファイルのようなものです。ホスト名としてexample.com が指定されたらIPアドレスxxx.xxx.xxx.xxxのことだと思ってね！というような紐づけをPC内で設定します。これによって、DNSサーバの設定を指定なくても、自分のPCでは移行したサイトを確認できるようになります。

    hostsファイルの編集方法（Windows）:

    1. メモ帳を管理者権限で起動
    2. C:\Windows\System32\drivers\etc\hosts を開く
    3. 最終行に以下を追加：
      1. 移行先サーバのIPアドレス    example.com
      2. 移行先サーバのIPアドレス    www.example.com
    4. 保存してブラウザでアクセス

    確認項目：

    • トップページが正常に表示される
    • 個別記事ページが表示される
    • 画像がすべて表示される
    • 管理画面にログインできる
    • お問い合わせフォームが動作する
    • SSL証明書が正常（南京錠マークが表示）

    問題なければhostsファイルの追記を削除し、次のステップへ。

    ステップ５・６：DNS切り替え

    ５−１. TTL値を短縮（切り替え24〜48時間前）

    現在のTTL値： 86400秒（24時間） → 300秒（5分）に変更
    ※DNS反映を早めるための対応

    ５−２. DNS切り替え実施

    ドメイン管理画面で、ネームサーバを移行先VPSのものに変更します。

    【変更前】
    ネームサーバ1: ns1.old-server.com
    ネームサーバ2: ns2.old-server.com

    【変更後】
    ネームサーバ1: ns1.new-server.com
    ネームサーバ2: ns2.new-server.com

    DNS浸透の確認：

    # コマンドプロンプトで確認（Windows）
nslookup example.com
# 移行先サーバのIPアドレスが返ってくればOK

    サーバ移行の失敗事例から学ぶ5つの教訓

    ここで、サーバ移行の事例から学ぶ教訓をお伝えします。ここに気をつけて移行作業を行うことがポイントです。

    失敗事例１：バックアップを取らずに移行して全データ消失

    教訓： 移行前に必ず完全バックアップを取得をすること。バックアップは複数箇所に保管（ローカルPC、クラウドストレージ等）すること。

    失敗事例２：DNS切り替え後にSSL証明書エラーで全ページ表示不可

    教訓： DNS切り替え前に移行先サーバでSSL証明書を取得・設定しておくこと。（意外と作業漏れが発生するケースあり）hostsファイル編集での事前確認時にSSLもチェック。

    失敗事例３：DNS浸透期間中のデータ不整合

    教訓： DNS切り替え期間中（前後24時間）は更新作業を一切行わない。事前に更新担当部門（メディアであれば編集部等）・関係者に周知徹底。

    失敗事例４：画像パスの書き換え漏れでメディアファイルが表示されなく・・・

    教訓： データベース内のURLを一括置換するツールを使う。WP-CLIのsearch-replaceコマンド、またはプラグイン「Better Search Replace」を活用。

    # WP-CLIでのURL一括置換例

# --dry-runで事前シミュレーション
wp search-replace 'http://old-domain.com' 'https://new-domain.com' --dry-run

# 問題なければ本実行
wp search-replace 'http://old-domain.com' 'https://new-domain.com'

    失敗事例５：旧サーバを即解約してロールバック不可能に

    教訓： 旧サーバは移行後最低1ヶ月は残して、何かあった際に戻せるようにしておく。移行後1週間は毎日動作確認し、問題が完全に解消されたことを確認してから旧サーバ解約をしましょう。

    WordPressサイト移行後の必須チェックリスト１０項目

    DNS切り替え後、必ず以下の10項目をチェックしましょう。

    No.確認項目重要度
    1トップページが正常に表示される★★★★★
    2個別記事・固定ページが表示される★★★★★
    3画像・メディアファイルが表示される★★★★★
    4お問い合わせフォームが動作する★★★★★
    5SSL証明書が正常（南京錠マークが表示）★★★★★
    6管理画面にログインできる★★★★★
    7検索機能が動作する★★★☆☆
    8会員ログイン機能が動作する（該当する場合）★★★★★
    9メールフォーム・メルマガ配信が正常★★★★☆
    10Google Analytics/Search Consoleなど外部ツールが正常に動作★★★★☆

    確認時の注意点： 複数のデバイス・ブラウザ（PC、スマートフォン、タブレット）、複数の回線（社内、自宅、モバイル）でチェックしてください。

    よくある質問（FAQ）

    Q1. ドメインはそのままでサーバだけ移行できますか？

    A. はい、可能です。ドメインの所有権は変わらず、DNSの向き先を変更するだけでサーバ移行ができます。

    Q2. SEO評価は下がりませんか？

    A. 正しい手順で移行すれば、SEO評価が下がることはありません。URLを変更しない、リダイレクト設定、robots.txtの確認、Google Search Consoleでサイトマップ再送信などの対策が取れます。

    Q3. 移行に失敗したらどうすればいいですか？

    A. すぐに旧サーバにロールバック（巻き戻し）をします。DNSを旧サーバのネームサーバに戻し、DNS浸透を待ちます。この対応のために、旧サーバを1ヶ月間残しておく（並行稼働）が重要です。

    Q4. 移行代行を依頼する場合の費用相場はいくらですか？

    A. サイトの規模や移行パターンによって異なります。プライム・ストラテジーの移行プランの場合ですと、1サイトあたり30〜40万円です。（参考：KUSANAGIマネージドサービス価格表）

    まとめ：安全なサーバ移行で企業サイトを進化させる

    ここまで、企業のWordPressサイトにおけるサーバ移行について、検討すべきタイミングから具体的な手順、失敗事例、リスク対策まで解説してきました。

    サーバ移行成功のための5つの鉄則

    • 事前準備とバックアップを徹底する
    • DNS切り替え前に必ず動作確認する
    • DNS切り替え期間中は更新作業を行わない
    • 旧サーバは最低1ヶ月間残す
    • 不安な場合は専門家に依頼する

    プライム・ストラテジーができること

    プライム・ストラテジー株式会社では、WordPressサイトのサーバ移行から運用まで、トータルでサポートいたします。

    【KUSANAGIマネージドサービス】

    KUSANAGIマネージドサービスは、企業様のWordPressサイトのセキュリティ・表示速度・リソース不足等の課題を解決し、フルマネージドの形でご支援をいたします。

    • WordPress ＋ サーバを一元管理
    • 超高速WordPress実行環境「KUSANAGI」を標準提供
    • 移行作業込み・初期費用40万円〜、月額10万円〜
    • 24時間365日の監視・サポート体制
    • 200件以上の導入実績（住友不動産、ヤマハ、新潮社、國學院大學等）
    おすすめの記事

    この記事が参考になりましたら幸いです。

    • Bookmark
    • -
      Copy