WordPressの引っ越し・サーバー移行ガイド｜手順とダウンタイム最小化のコツ

サーバーの契約更新を機に乗り換えたい、表示が重いので高速なサーバーへ移したい、制作会社から自社管理に切り替えたい——WordPressサイトの「引っ越し（サーバー移行）」が必要になる場面はさまざまです。手順自体は決まっていますが、ファイルとデータベースの両方を移し、URLを置換し、DNSを切り替えるという工程を順番どおりに踏まないと、画像が消えたり、リンクが切れたり、移行中にサイトが落ちたりします。この記事では、失敗しやすいポイントを押さえながら、引っ越しを上から順にたどれるように整理します。

⚠️ 引っ越し作業を始める前に、現行サイトの完全なバックアップ（ファイル一式＋データベース）を必ず取得してください。移行は元のサーバーを消さずに進めるのが鉄則です。新サーバーで完全に動作確認できるまで、旧サーバーの契約は解約しないでください。

まず方針を決める：引っ越しの3つの型

「引っ越し」と一口に言っても、難易度と注意点は状況で変わります。自分がどれに当てはまるかを最初に確定させてください。

• A. 別サーバーへ移行（ドメインはそのまま） — 最も一般的。https://example.com を維持したまま、サーバーだけ乗り換える。最後にDNS（ネームサーバー）を切り替える。
• B. 同一サーバー内でプラン変更・移設 — 各社の管理画面内の移設機能で完結することが多く、DNS切替が不要な場合もある。
• C. ドメインも変更する — old.com → new.com。サーバー移行に加えて全URLの置換と301リダイレクトが必須になり、SEO評価の引き継ぎ作業が増える。

本記事は最も需要の多い A（別サーバーへの移行） を主軸に説明し、Cで追加になる作業は各所で補足します。

WordPress引っ越しの全体像と、失敗する典型パターン

WordPressサイトは大きく2つの要素でできています。引っ越しとは、この両方を新サーバーへ移し、整合させる作業です。

1. ファイル群 — WordPress本体、テーマ、プラグイン、アップロード画像（wp-content 配下）など
2. データベース — 記事本文・固定ページ・設定・ユーザー情報（MySQL／MariaDB）

移行でつまずく原因は、ほぼ次のパターンに集約されます。先に知っておくだけで回避できます。

DB接続エラーが出た場合の切り分けは データベース接続確立エラーの対処ガイド で詳しく扱っています。

移行方法を選ぶ：3つのアプローチ

引っ越しのやり方は大きく3通りです。サイト規模と「どこまで自分でやるか」で選びます。

迷ったら、移行先が下記の対応サーバーなら①、それ以外は②、容量が大きい・確実にやりたいなら③ が基本の判断軸です。以下、それぞれの手順を見ていきます。

① サーバー標準の移行機能を使う

移行先が主要レンタルサーバーなら、各社が提供する移行ツールが最も手軽です。多くは「移行元のWordPress管理画面ログイン情報」を入力するだけで、ファイルとDBをまとめて取り込んでくれます。代表的な3社の機能と前提条件をまとめます（正確な対応条件・容量上限は契約プランやサーバー世代で変わるため、必ず各社の最新マニュアルで確認してください）。

共通の注意点

• 実行前に移行元のセキュリティ・キャッシュ・リダイレクト系プラグインを停止しておく（移行エラーとループの主因）。
• 移行ツールは新サーバー側にコピーを作るだけで、DNSはまだ切り替わっていません。動作確認は後述の「hostsで事前確認」で行います。
• 容量超過などでツールが使えなかった場合は、迷わず②または③に切り替えます。

② 移行プラグインを使う

サーバー標準ツールが使えない場合は、移行プラグインが次の選択肢です。代表的な2つを挙げます。

All-in-One WP Migration 管理画面から「エクスポート → ファイルをダウンロード → 新サイトでインポート」するだけの定番。手軽ですが、無料版にはインポートできるファイルサイズの上限があります（上限値はバージョンにより異なるため、エクスポート後のファイルサイズと併せて要確認）。超える場合は、エクスポート時の「高度なオプション」でメディアライブラリを除外してファイルを小さくし、画像は別途FTPで wp-content/uploads を転送する、という分割が定番の回避策です（有料版で上限解放も可）。

Duplicator サイトを「アーカイブ（zip）＋インストーラ（installer.php）」として書き出し、新サーバーへ両方をアップロードして installer.php を実行する方式。新サーバーに空のデータベースを先に用意しておく必要があり、All-in-Oneより手数は多いものの、容量の大きいサイトや細かい制御に向きます。

プラグイン移行でも、移行後にパーマリンクの再保存（管理画面→設定→パーマリンク→変更せず保存）でリンク切れが直ることが多いです。

③ 手動移行の手順（FTP＋データベース）

確実性が必要な場合や標準ツール・プラグインが使えない場合は、手動移行が最も堅実です。WP-CLIが使える環境なら、DBのエクスポートとURL置換が安全かつ確実に行えます。

1. ファイルを移す 旧サーバーからFTP／SFTPでWordPress一式（wp-content を含むサイト直下すべて）をダウンロードし、新サーバーの公開ディレクトリ（public_html など）へアップロードします。

2. データベースを書き出す 旧サーバーで phpMyAdmin からSQL形式でエクスポートするか、WP-CLIが使えるなら次のコマンドで書き出します。

wp db export backup.sql

3. 新サーバーでDBを作成・取り込み 新サーバーの管理画面でMySQLデータベース（文字コードは utf8mb4 推奨）とユーザーを作成し、書き出したSQLを取り込みます。

wp db import backup.sql

4. wp-config.php を新サーバーの値に修正 DB_NAME / DB_USER / DB_PASSWORD / DB_HOST を、新サーバーの管理画面に記載された値へ書き換えます。

5. データベース内のURLを置換する（最重要） DBには旧環境のURLや絶対パスが各所に保存されています。これを置換しないと画像やリンクが旧サーバーを参照し続けます。手作業のSQLは serialize されたデータを壊すため非推奨で、WP-CLIの search-replace を使うのが安全です。

# まず --dry-run で置換件数だけ確認（実際には書き換えない）
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --dry-run

# 問題なければ本実行（serialize対応で安全に置換）
wp search-replace 'https://old-domain.com' 'https://new-domain.com'

ドメインを変えない型A・型Bでも、http:// → https:// や一時URLからの置換でこの手順が必要になることがあります。

サーバー別の DB_HOST と確認場所

手動移行・プラグイン移行のいずれでも、wp-config.php の DB_HOST はサーバーごとに異なります。代表的な値と確認場所をまとめます（正確な値は必ず各社の管理画面で確認してください）。

localhost 型と専用サーバー名型を取り違えると、移行直後にDB接続エラーになります。引っ越し元と引っ越し先で形式が違う点に注意してください。

DNS切替とダウンタイムの最小化

新サーバーで表示・動作を確認できたら、最後にドメインの向き先（DNS）を新サーバーへ切り替えます。ここを雑にやると、切替の前後でアクセスした人に旧サーバーと新サーバーが混在して見え、フォーム送信やコメントが旧DB側に書き込まれて消えるといった事故が起きます。次の順序が安全です。

1. 事前にTTLを短くする — 切替の1〜2日前に、DNSレコードのTTL（キャッシュ有効時間）を300秒など短い値に変更しておく。これで切替が早く伝播します。
2. hostsファイルで新サーバーを先行確認 — DNSを切り替える前に、自分のPCの hosts ファイルにドメインと新サーバーのIPを書いて、本番ドメインのまま新サーバーの表示・ログイン・フォーム送信を確認します。問題があればこの段階で直せます。
3. アクセスの少ない時間帯に切替 — ネームサーバー／Aレコードを新サーバーへ変更します。反映には最大24時間程度かかるため、深夜や週末など更新が止まる時間帯を選びます。
4. 切替直後は両サーバーを生かしておく — 伝播が完了するまで旧サーバーも稼働させ、どちらに当たっても表示は崩れない状態を保ちます。完全移行を確認してから旧サーバーを停止します。

切替の「直前」に旧サーバーで記事を更新すると、その変更が新DBに反映されません。**DNS切替前にコンテンツ更新を止める（凍結する）**と取りこぼしを防げます。

引っ越し後チェックリスト

移行が終わったら、次の項目を上から順に確認してください。リンク切れや検索順位の取りこぼしは、ここでの確認漏れが原因のほとんどです。

• トップページと記事ページ、管理画面（/wp-admin） が両方開けるか
• 画像が表示されるか（wp-content/uploads の転送漏れ・URL置換漏れの確認）
• 内部リンク・画像URLが新ドメイン／新サーバーを指しているか
• 常時SSL（https） が有効か。「WordPressアドレス」「サイトアドレス」が https:// で揃っているか
• パーマリンクを変更せず再保存して、.htaccess を作り直したか
• 開発中に付けた noindex（検索エンジンのインデックスをしない設定）を解除したか（設定→表示設定のチェックを確認）
• Search Console で新サーバーのサイトを確認し、必要なら再クロールを依頼したか
• 型C（ドメイン変更）の場合、旧ドメインから新ドメインへ 301リダイレクトを設定したか
• メールを同じサーバーで使っていた場合、メール（MXレコード）の移行も別途必要か確認したか

すべてチェックでき、数日間アクセスや表示に問題がなければ、旧サーバーを解約して引っ越し完了です。

同じ移行を繰り返さないという選択肢

サーバー移行は、速くなる・安くなるといったメリットがある一方で、WordPressである限り定期的に発生し続ける運用コストでもあります。PHPやプラグインのバージョン更新、サーバー老朽化のたびに、今回のような移行・互換性確認が必要になります。

もし引っ越しの動機が「表示が重い」「障害やメンテナンスに疲れた」「セキュリティが不安」であれば、移行のタイミングは構成そのものを見直す好機でもあります。データベースもログイン画面も持たない静的配信に作り替えれば、DB接続エラーも乗っ取りも原理的に起こらず、表示も高速になります。WordPressをやめる選択肢については 落ちない構造への作り替え で整理しています。

よくある質問

引っ越しでSEO（検索順位）は下がりますか？

ドメインを変えない型Aなら、正しく移行できれば検索順位への影響はほとんどありません。むしろ表示速度が上がって有利になることもあります。順位が落ちる典型は、noindexの解除漏れとドメイン変更時のリダイレクト設定漏れです。チェックリストの該当項目を必ず確認してください。

画像だけ表示されません

ほぼ「wp-content/uploads の転送漏れ」か「DB内のURL置換漏れ」のどちらかです。uploads配下を丸ごと転送し直し、wp search-replace で旧URLを置換してください。

「Too many redirects」でループします

SSL設定とWordPressのアドレス設定の不一致が主因です。新サーバーで常時SSLを有効にし、「WordPressアドレス」「サイトアドレス」を https:// で揃え、リダイレクト系プラグインを一旦停止して確認してください。

メールはどうなりますか

同じサーバーでメール（独自ドメインメール）も使っていた場合、ネームサーバーを切り替えるとメールの宛先（MXレコード）も一緒に移動します。新サーバーでメールアカウントを作り直すか、MXレコードを旧メール環境に向け直す設定が別途必要です。引っ越し前に現在のメール構成を必ず確認してください。

自分でやるのが不安です

データベースの操作やDNS切替は、誤るとサイトやメールが止まり、データを失うこともあります。**「お客様に見せている本番サイト」「ECや予約を動かしている」**ような止められないサイトでは、無理に操作せず、移行の代行をご検討ください。当社では移行作業の代行と、移行を機にした構成の見直しまで対応しています。