年末年始に向けたWordPressサーバー移行・引越し完全手順｜失敗しない移転チェックリストとダウンタイムゼロ復旧法

WordPressサイトを運用していると、「ページの表示速度が遅くて読者が離脱してしまう」「アクセスが集中したときに503エラーでサーバーがダウンする」「サーバーのPHPバージョンが古くセキュリティリスクを抱えている」といった深刻な悩みに直面することがあります。これらの問題を根本的に解決する最も有効な手段が、より高性能で安定したレンタルサーバーへの「WordPressサーバー移行（サーバー引越し）」です。

しかし、サーバー移行はWordPress運用における最難関の作業の一つです。DNSレコードの切り替え順序やデータベースの取り扱い、SSL証明書の設定を一つでも誤ると、「サイトが数日間にわたって閲覧不能になる」「ブラウザに保護されていない通信と警告が表示されて信用を失う」「ドメイン共通のメール送受信が停止する」といった重大なトラブルに発展しかねません。

そこで注目したいのが、「年末年始の大型休業期間」を活用したサーバー移行です。年末年始は多くの企業活動が停止し、一般的なWebサイトのアクセスも年間で最も落ち着く閑散期にあたります。万が一設定の調整に時間がかかっても、ビジネスへの被害や読者への影響を最小限に抑えることができる絶好のタイミングです。

本記事では、初心者から実務担当者までが迷わず安全に作業できるよう、「ダウンタイムゼロ（稼働停止なし）」でWordPressを別のサーバーへ引っ越す完全7ステップを徹底解説します。移行前の無料SSL事前発行手順、hostsファイルを用いた新サーバーでの完全動作確認法、メールの無停止移行、よくあるトラブル5選の緊急復旧法、印刷・コピペして使える実務チェックリスト20項目まで、プロの現場ノウハウを凝縮してお届けします。

---

なぜ年末年始が最適？WordPressサーバー移行を検討すべき5つのサインと移行スケジュール

「サーバー移行はいつ実行すべきか？」という問いに対し、多くのインフラエンジニアやWebディレクターが推奨するのが12月中旬から1月上旬にかけての年末年始シーズンです。ここでは、移行に踏み切るべき5つのサインと、年末年始の連休を最大限に活かした無理のない2週間移行スケジュールを整理します。

サーバー移行を検討すべき5つのサイン（速度遅延・503エラー・PHP旧版サポート終了・コスト）

現在利用しているレンタルサーバーに以下のような症状が見られる場合、放置するとSEO評価の下落や重大なセキュリティインシデントにつながる恐れがあります。今すぐ新サーバーへの移転を検討すべき危険信号です。

1. ページ表示速度が著しく遅く、直帰率・離脱率が高止まりしている
   GoogleのCore Web Vitals（LCPやINPなど）において評価が「要改善」または「不良」となっている場合、サーバーのCPU処理能力やディスクI/O（NVMe SSDの未導入等）がボトルネックになっている可能性が極めて高いです。どれだけキャッシュプラグインを導入しても、基盤サーバーの性能が不足していれば根本解決には至りません。
2. キャンペーンやSNS流入などのアクセス集中時に503/504エラーが頻発する
   同時アクセス数制限の厳しい旧世代のレンタルサーバーや安価な共用プランでは、一時的なトラフィック急増に耐えきれずサーバーが自動的にアクセスを遮断（503 Service Unavailable）します。販売機会の損失や検索エンジンのクロールエラーを招く重大要因です。
3. PHP 8.1以前のセキュリティサポート終了に伴い、最新のPHP環境へ更新できない
   旧サーバーのインフラ仕様が古く、公式サポートが終了したPHP 8.1以前のまま放置されている環境は極めて危険です。脆弱性を狙った攻撃に晒されるだけでなく、WordPress本体やプラグインの最新版へのアップデートがブロックされてしまいます。安全な運用の維持には、高速かつセキュアな最新PHP環境（PHP 8.2 / 8.3以降）が標準提供されているサーバーへの乗り換えが急務です。
4. 月額コスト（維持費）とスペックのコストパフォーマンスが合っていない
   数年前に契約したサーバーをそのまま更新し続けている場合、現在の最新レンタルサーバーに比べて「料金が高いのにストレージ容量が少なく、転送量上限も厳しい」という逆転現象が起きています。最新世代のサーバーへ移行することで、月額費用を据え置き（または削減）しながら処理速度を2〜3倍に引き上げることが可能です。
5. WordPress管理画面のレスポンスが重く、記事編集や更新作業がストレスになっている
   公開ページの表示速度だけでなく、管理画面でのブロックエディターの挙動やメディアアップロード、下書き保存に数秒以上の待機時間が発生している場合、データベース処理能力が不足しています。管理画面の遅延は日々の運用効率を著しく低下させます。

年末年始の大型連休を活用した安全な2週間移行工程表（スケジュールタイムライン）

サーバー移行で最も避けるべきは、「1日で準備からDNS切り替えまでを一気に終わらせようとする突貫工事」です。予期せぬトラブルが発生した際に慌てて旧環境へ戻すロールバック作業すら行えなくなるリスクがあります。

年末年始の休暇を活かし、「12月中旬の事前準備」から「年明けの最終確認」までを約2週間でゆとりを持って進める理想的なタイムラインを以下に示します。

フェーズ・日程	工程	主要なタスク内容	万が一のトラブル時の影響度
12月中旬 （移行準備期間）	新サーバー契約＆ 完全バックアップ	・新サーバーの契約（旧サーバーは絶対解約しない） ・独自ドメインの追加設定 ・DBおよび全ファイルの手動完全バックアップ取得 ・不要なリビジョンやゴミデータの事前大掃除	極小 （既存サイトは通常通り稼働）
12月下旬 （検証・仕込み期間）	データ複製＆ 事前検証・SSL発行	・簡単移行ツールまたはプラグインでデータ展開 ・新サーバーでの無料独自SSL事前申請 ・パソコンのhostsファイルを書き換え新環境の動作検証 ・管理画面ログイン、全固定ページ、問い合わせフォーム送信確認 ・DNSのTTL値を300秒に短縮設定	極小 （一般ユーザーには一切見えない内部検証）
年末年始休暇中 （本番切り替え期間）	ネームサーバー切り替え＆ アクセス監視	・DNSネームサーバー情報を新サーバーへ変更 ・DNS伝播の推移監視 ・新環境へのアクセスログ確認 ・問い合わせフォームの稼働監視	小〜中 （アクセス閑散期のため被害極小）
1月上旬 （年明け安定期間）	メール移行完了＆ 旧サーバー解約判断	・ドメイン共通メールの送受信テスト（新旧両面） ・DNSのTTL値を通常値（3600秒〜86400秒）に戻す ・DNS浸透確認（2週間経過後）ののち旧サーバーを安全に解約	極小 （安定稼働を確認後のクローズ作業）

このように、「12月下旬までに新環境での動作確認と無料SSLの仕込みを100%完了させておき、休暇に入ったタイミングでDNSを切り替える」というスケジュールを組むことで、業務への影響やサイトダウンのリスクを完全にゼロに抑え込むことができます。

---

【比較】WordPressのサーバー移行方法4選｜難易度・容量制限・おすすめの選び方

WordPressのサーバー移行には、レンタルサーバー事業者が提供する公式移行ツールから専用プラグイン、FTPとphpMyAdminを使った手動移行まで複数の手法が存在します。サイトのデータ規模や管理者のスキルセットに合わない手法を選んでしまうと、途中でタイムアウトを起こしてデータが破損したり、容量上限に阻まれて移行がストップする原因となります。

まずは、主要な4つの移行手法のメリット・デメリットと適性を一覧表で比較検討しましょう。

移行方法	難易度	移行速度	費用	データ容量上限	おすすめの対象読者・サイト規模
方法1：サーバー公式 「WordPress簡単移行」	★☆☆☆☆ （極めて簡単）	即時〜数十分	無料	サーバー規定 （通常10GB〜数十GBまで対応）	【最もおすすめ】 エックスサーバー、ConoHa、シンレンタル等へ移行する大半の個人・法人サイト
方法2：移行プラグイン （Duplicator等）	★★☆☆☆ （初級〜中級）	数十分〜1時間	無料〜有料	サーバーのPHP制限依存 （Duplicator無料版で数GB以上も対応可能）	サーバーの簡単移行機能が非対応の環境、ローカル環境からの移転、中規模サイト
方法3：手動移行 （FTP＋phpMyAdmin）	★★★★☆ （上級者向け）	数時間以上	無料	事実上無制限 （大容量DB分割やSSHが必要）	数十GB以上の超大規模サイト、プラグインが動作しない特殊なマルチサイト、エンジニア向け
方法4：専門会社による 移行代行サービス	☆☆☆☆☆ （完全委託）	数日〜2週間	3万円〜15万円程度	無制限（事前相談）	ECサイト、会員制サイト、社内に技術者が不在で失敗が絶対に許されない企業サイト

方法1：各サーバー会社の「WordPress簡単移行機能」（最も安全・おすすめ）

現在、国内の主要レンタルサーバー（エックスサーバー、ConoHa WING、シンレンタルサーバー、ロリポップなど）のコントロールパネルには、他社サーバーからの引越しを自動化する「WordPress簡単移行ツール」が標準搭載されています。

簡単移行ツールの仕組み：
新サーバーの管理画面から「移行元（旧サーバー）のWordPressサイトURL」「管理者ユーザー名」「管理者パスワード」を入力するだけで、新サーバーが移行元サイトにバックグラウンドで自動アクセスし、データベース（記事・固定ページ・設定値）とファイル一式（画像・テーマ・プラグイン）を丸ごと吸い上げて新サーバー環境へ自動展開してくれます。

• 最大のメリット : プラグインのインストールやFTP接続、データベースのエクスポート作業が一切不要。移行元サイトを停止させることなく、稼働したまま安全に複製を作成できる。
• 注意すべきケース : 移行元サイトで「BASIC認証」や「二要素認証（2FA）」、「特定のセキュリティプラグインによるREST API制限」が有効になっていると、新サーバーからの自動アクセスが弾かれてエラーになります。その場合は、一時的に認証を解除してから実行する必要があります。

方法2：移行プラグインの活用（Duplicator vs All-in-One WP Migrationの容量の壁対策）

旧サーバーや新サーバーが公式の簡単移行ツールに対応していない場合、最も定番となるのがWordPressの引越し専用プラグインを活用した移行です。

ここで多くの初心者が直面するのが、「All-in-One WP Migrationの容量制限の壁」です。All-in-One WP Migrationは操作がシンプルな反面、無料版でのインポート容量上限が厳格（最新仕様では最大512MB、環境によっては2MB〜数十MBに制限）に定められており、画像が多いブログや長年運用しているサイトでは有料アドオンを購入しないと復元できないという落とし穴があります。

そこでおすすめなのが、無料版でも大容量サイトに対応できる高機能移行プラグイン「Duplicator（デュプリケーター）」です。

比較項目	Duplicator（推奨）	All-in-One WP Migration
無料版のインポート容量上限	実質無制限 （サーバーのPHP実行制限に準拠）	厳しい制限あり （無料版は最大512MBまたはそれ以下）
移行の仕組み	バックアップアーカイブ（.zip）と展開スクリプト（installer.php）を生成し、新サーバーへ直接配置して展開	エクスポートしたバックアップファイル（.wpress）を新サーバーのWordPress管理画面からアップロード
新サーバー側の事前準備	空のディレクトリと空のデータベースがあればOK（WordPressの事前インストール不要）	新サーバーにWordPress本体を事前インストールし、プラグインを導入しておく必要がある
総合評価	中規模〜画像が多いサイトでも追加課金なしで確実に移行可能	テキスト中心の小規模サイト（500MB未満）向け

Duplicatorの基本手順：

1. 旧サイトでDuplicatorを有効化し、「パッケージ（Package）の作成」を実行。サイト全体のバックアップファイル（.zip）と展開用ファイル（installer.php）の2点をダウンロード。
2. 新サーバーのドメインルートディレクトリにFTP等で2つのファイルをアップロード。
3. ブラウザから https://独自ドメイン/installer.php（または一時URL）にアクセスし、新サーバーのデータベース情報を入力してウィザードを進めるだけで、完全な復元とURL置換が完了します。

方法3：手動移行（FTPダウンロード＋phpMyAdminデータベースエクスポート）

プラグインの実行時間制限（max_execution_time）やメモリ上限（memory_limit）に引っかかる数十GB規模の超大規模サイト、あるいは特殊なカスタマイズが施されたマルチサイト環境では、FTPクライアントとphpMyAdminを用いた手動移行が最も確実な選択肢となります。

• ファイル移行 : FileZillaやCyberduck等のFTP/SFTPソフトを使用し、旧サーバーの wp-content フォルダ（画像、テーマ、プラグイン）および設定ファイル（wp-config.php）をローカルPCへダウンロードし、新サーバーの所定ディレクトリへアップロード。
• データベース移行 : 旧サーバーのphpMyAdminからデータベースをSQL形式でエクスポート。新サーバーのphpMyAdminにインポート後、必要に応じて「Search-Replace-DB」スクリプトやWP-CLIコマンドを用いてシリアライズデータを破損させずにURLを置換。

確実性は高いものの、データベースの文字コード設定やテーブルプレフィックスの整合性確認などインフラの専門知識が求められるため、一般ユーザーにはやや敷居が高い手法です。

方法4：専門会社によるサーバー移行代行サービス

「社内にサーバーやデータベースを触れる専任エンジニアがいない」「WooCommerce等のECサイトや会員制サイトを運用しており、わずかなデータ欠損やダウンタイムも許されない」という企業サイトでは、サーバー移行の専門業者や保守代行会社へ外注するのが最も安全です。

• 費用相場 : 単一サイトの標準的な移行代行であれば3万円〜8万円前後、ECサイトやマルチサイト、SSL証明書の持ち込み等の特殊要件が含まれる場合は10万円〜15万円前後が一般的な相場です。
• 業者の提供範囲 : 事前の動作検証環境の構築、hostsファイルによる検証代行、深夜や連休中のDNS切り替え作業、メールアカウントの移行サポート、移行後の不具合保証までワンストップで対応してもらえます。自社スタッフの工数と万が一の障害リスクを天秤にかけて判断しましょう。

---

【完全手順】ダウンタイムゼロで失敗しないWordPressサーバー移行7ステップ

ここからは、サイトの稼働停止（ダウンタイム）を発生させず、安全かつ確実にWordPressサーバーを引っ越す「実務7ステップ」を詳しく解説します。インフラの切り替え順序を正しく守ることで、ユーザーや検索エンジンのクローラーに一切の不具合を見せることなく新環境へ移行できます。

ステップ1：新旧サーバーを並行契約し、現状の完全バックアップを取得

サーバー移行における鉄則中の鉄則は、「旧サーバーを絶対に即時解約せず、新旧両方のサーバーを最低1ヶ月間は並行契約・並行稼働させること」です。

サーバー費用を節約しようとして旧サーバーの解約日ギリギリに移行作業を行うと、万が一DNS切り替え後にエラーが発生した場合に旧環境へ巻き戻す（ロールバックする）逃げ道が断たれてしまいます。さらに、後述するメールの遅延到着やDNSキャッシュの完全消去を見届けるためにも、1ヶ月程度の契約重複期間は必須の保険コストと捉えてください。

新サーバーの契約が完了したら、作業に着手する前に移行元（旧サーバー）の完全バックアップを手動で取得し、必ず自分のパソコンやクラウドストレージなどの「サーバー外部」へ保存します。

また、新サーバーへ移行する前に不要なリビジョンやゴミデータを削減しておくと、移行データ容量が半減し、移行時間を大幅に短縮できます。詳しくは「年末年始のWordPressデータベース大掃除・最適化手順」を参照してください。

あわせて、新サーバー側で利用するPHPバージョンが、現在のテーマや主要プラグインと互換性があるかを事前に確認しておきましょう。バージョン選定の判断基準については「WordPressの推奨PHPバージョンと確認・変更手順」で詳しく解説しています。

ステップ2：新サーバーの契約と独自ドメインの追加設定

新サーバーの契約が完了したら、サーバーコントロールパネルから現在運用している「独自ドメインの追加設定」を行います。

ドメイン追加時の重要ポイント：

• この段階では絶対にネームサーバー（DNS）を変更しない : 新サーバーの管理画面に「ネームサーバーを〇〇に変更してください」と案内が表示されますが、このタイミングで変更してしまうと、新サーバー側にデータもSSL証明書もない状態のため、サイトが即座にダウンします。ネームサーバーの変更はすべてのデータ移行と動作検証が終わった最後のステップ6で行います。
• 無料独自SSLの「同時申し込み」チェックの扱い : サーバー会社によっては、ドメイン追加時に「無料独自SSLを利用する」のチェックボックスがあります。通常、DNSがまだ新サーバーを向いていない段階では認証が通らずエラーになるサーバー（ロリポップやさくら等）と、DNS切り替え前でも事前認証できるサーバー（エックスサーバーやConoHa WING等）に分かれます。次のステップ3の手順に従って設定を進めてください。

ステップ3：【超重要】DNS切り替え前の新サーバー「無料独自SSL」事前申請

サーバー移行で初心者が最も陥りやすい最大の落とし穴が、「DNS切り替え直後に発生するブラウザのSSL警告画面（保護されていない通信）」です。

通常、Let’s Encryptなどの無料SSL証明書は「ドメインがそのサーバーを向いていること」をHTTP通信（HTTP-01チャレンジ）で確認して初めて発行されます。そのため、何も対策せずにDNSを新サーバーに切り替えた場合、「DNS切り替え完了から新サーバーでSSL証明書が自動発行・反映されるまでの数十分〜数時間の間、サイトがHTTPでしか開けず、アクセスした全ユーザーに『この接続ではプライバシーが保護されていません』という警告画面が表示される」という致命的なダウンタイムが発生します。

主要サーバー別の事前SSL発行手順は以下の通りです。

• エックスサーバー（事前SSL設定） : ドメイン追加設定時、他社サーバーで運用中のドメインであっても「Web認証（旧サーバーの指定ディレクトリへ認証用htmlファイルを配置）」または「DNS認証（TXTレコードの追加）」を行うことで、DNS切り替え前に新サーバー上で無料独自SSLを即座に有効化できます。
• ConoHa WING（アルファSSL事前認証） : 他社サーバーからのWordPressかんたん移行時やドメイン追加時に、事前認証（DNSのTXTレコード確認等）を経てアルファSSL証明書をあらかじめ新環境へインストールしておくことが可能です。
• 事前SSL機能がないサーバーの場合 : 旧サーバーで利用している既存のSSL証明書（秘密鍵・中間証明書・サーバ証明書）をエクスポートし、新サーバーへ手動で「持ち込みSSL」としてインポートしておくことで、切り替えの瞬間の警告を完全に回避できます。

ステップ4：データの複製とインポート（ファイル一式＋データベース）

ドメイン設定と事前SSLの発行準備が整ったら、実際に旧サーバーのWordPress環境（データベース・画像・テーマ・プラグイン）を新サーバーへ複製・インポートします。

簡単移行ツールを利用する場合：
新サーバーのコントロールパネルにある「WordPress簡単移行」を開き、移行元サイトのURLと管理者ログイン情報を入力して実行します。データ量にもよりますが、通常15分〜1時間程度でバックグラウンドでのデータコピーが完了し、「移行完了」のステータスが表示されます。

Duplicatorプラグインを利用する場合：
旧サイトで作成したアーカイブファイル（.zip）と展開スクリプト（installer.php）を、新サーバーの該当ドメインフォルダにFTPでアップロードします。続いて、新サーバー側であらかじめ作成しておいた「空のMySQLデータベース名」「データベースユーザー名」「パスワード」を用意し、ウィザードを実行してデータを展開します。

ステップ5：パソコンのhostsファイルを編集して新環境での完全動作確認

データ展開が完了しても、まだ絶対にネームサーバーを切り替えてはいけません。世界中のユーザーに向けてDNSを切り替える前に、新サーバー上でサイトが本当に正常動作しているかを徹底検証する必要があります。

しかし、DNSを切り替えていない段階では、ブラウザで通常のドメインを入力しても旧サーバーへ接続されてしまいます。そこで、プロの現場で必ず行われるのが「PCローカルのhosts（ホスツ）ファイルを編集した事前動作検証」です。

hostsファイル編集の仕組み：
PCはWebサイトにアクセスする際、インターネット上のDNSサーバーへ問い合わせる前に、自端末内の `hosts` ファイルを最優先で参照します。ここに「新サーバーのIPアドレス」と「サイトの独自ドメイン」を紐付けて記述することで、「世界中からは旧サーバーが見えている状態で、あなたのパソコンだけが新サーバーへアクセスできる状態」を作り出すことができます。

OS環境	hostsファイルの保存場所	編集手順の要点
Windows	C:\Windows\System32\drivers\etc\hosts	メモ帳を「管理者として実行」で起動し、上記ファイルを開いて末尾に追記して保存
Mac	/etc/hosts	ターミナルを起動し、sudo nano /etc/hosts コマンドを実行して管理者パスワードを入力後に追記して保存

hostsファイルへの追記例：

# 新サーバーのIPアドレス（例: 203.0.113.10）と独自ドメイン名を半角スペースで区切って記述
203.0.113.10 example.com
203.0.113.10 www.example.com

記述して保存したら、ブラウザを再起動（またはシークレットウィンドウを開く）し、独自ドメインへアクセスします。この状態で以下の項目を徹底的にテストしてください。

• WordPress管理画面（/wp-login.php）へ正常にログインできるか
• トップページ、主要な投稿記事、固定ページ（プライバシーポリシーや会社概要等）のレイアウトが崩れていないか
• 画像ファイルがすべて表示されているか（旧サーバーへの直リンクが残っていないか）
• 問い合わせフォーム（Contact Form 7等）からテスト送信を行い、完了画面の表示と自動返信メールの受信ができるか
• 記事の新規作成・下書き保存がエラーなく動作するか

すべての検証が完了したら、hostsファイルに追加した行を削除（または先頭に # を付けてコメントアウト）して元に戻しておきます。

ステップ6：TTL短縮とネームサーバー（DNS）切り替えの実施

新サーバーでの完全動作が確認できたら、いよいよ本番のDNS切り替え工程に進みます。

切り替え2〜3日前のテクニック：DNSレコードのTTL短縮
DNSの切り替えをスムーズに行い、世界中のキャッシュDNSサーバーに新サーバーのIPアドレスを迅速に浸透させるため、ネームサーバー切り替えの2〜3日前にDNSレコードの「TTL（Time To Live）」を短縮しておきます。通常86400秒（24時間）や3600秒（1時間）に設定されているTTL値を「300秒（5分）」に変更しておくことで、切り替え後の情報伝播が圧倒的に早くなります。

ネームサーバー情報の変更手順：
ドメインを管理しているレジストラ（お名前.com、ムームードメイン、Xserverドメイン、Value Domainなど）のコントロールパネルにログインし、ネームサーバー設定を新サーバー会社が指定するネームサーバー情報（例: ns1.xserver.jp など）へ変更します。

ネームサーバーの変更ボタンを押した瞬間から、世界中のアクセスが徐々に新サーバーへと切り替わり始めます。事前に無料SSLを発行し、hostsファイルで完全動作確認を行っていれば、ユーザー側にはダウンタイムもエラーも一切発生せず、シームレスに新環境への移行が完了します。

ステップ7：メールアカウントの移行と旧サーバーの安全な解約タイミング

サーバー移行で見落とされがちなのが、独自ドメインメール（例: info@example.com 等）の送受信停止事故です。Webサイトの表示ばかりに気を取られていると、「DNSを切り替えた瞬間から問い合わせメールやお客さまからの重要メールが届かなくなった」という大惨事になりかねません。

メール送受信を無停止で維持するための鉄則手順は以下の通りです。

1. ネームサーバー切り替え前に新サーバーで同一メールアカウントを作成 : 旧サーバーで使っている全メールアドレス（パスワード含む）を、ネームサーバーを切り替える前に新サーバー側のメール設定で全く同じスペルで新規作成しておきます。
2. メールソフト（Outlook, Mac Mail, Thunderbird等）へ新アカウントを追加 : 既存のメール設定を上書きするのではなく、新サーバー接続用のアカウント（受信サーバー・送信サーバーのホスト名に新サーバー指定）を並行して別アカウントとして登録しておきます。
3. DNS浸透中のメール取りこぼし防止 : ネームサーバー切り替え後、数時間から最大48時間程度は、送信者の環境によって「旧サーバーのメールボックスに届くメール」と「新サーバーのメールボックスに届くメール」が混在します。新旧両方のメールアカウントを受信設定しておくことで、一通の取りこぼしも防ぐことができます。
4. 旧サーバーの安全な解約タイミング : ネームサーバー切り替え後、世界中のキャッシュDNSが完全に新サーバーへ切り替わるまでには最大72時間程度かかります。さらに、遅れて届くメールの確認や万が一の予備調査期間を考慮し、「旧サーバーの解約はDNS切り替えから最低2週間〜1ヶ月後」に設定してください。年末年始に切り替えた場合、1月中旬から下旬を目安に旧サーバーの解約手続きを行うのが最も安全です。

---

サーバー移行時によくあるトラブル5選と緊急復旧法

入念に準備を進めていても、サーバー環境の違いやプラグインの依存関係によって予期せぬエラーが発生することがあります。ここでは、サーバー移行時につまずきやすい「よくある5大トラブル」の原因と、現場で即座に使える緊急復旧手順を網羅します。

トラブル1：サイトや管理画面が真っ白になる（画面真っ白・WSOD・500エラー）

主な原因：新旧サーバーでのPHPバージョン非互換またはPHPメモリ不足（memory_limit）
新サーバーのPHPバージョン（例: PHP 8.3）に対し、旧サーバーで利用していた古いテーマやプラグインの関数が対応しておらず、Fatal Error（致命的エラー）を引き起こして画面が真っ白（White Screen of Death）になる現象です。

緊急復旧手順：

1. 新サーバーのコントロールパネルを開き、PHPのバージョンを一時的に「旧サーバーと同じバージョン（または1つ下の安定版）」へ切り替えてリロードを試す。
2. それでも解決しない場合、FTPまたはファイルマネージャーで新サーバーの wp-content/plugins フォルダ名を一時的に plugins_old に変更し、全プラグインを強制無効化して管理画面にログインできるか確認する。
3. wp-config.php に define('WP_MEMORY_LIMIT', '256M'); を追記し、PHPのメモリ割り当て上限を引き上げる。

トラブル2：データベース接続確立エラー（Error establishing a database connection）

主な原因：wp-config.php内のDB名・ユーザー名・パスワード・DBホスト名の不一致
新サーバー上のWordPressがMySQLデータベースと通信できない場合に発生します。特に「DBホスト名（DB_HOST）」がサーバー会社ごとに異なる（localhost、mysqlXXX.xserver.jp、IPアドレス指定など）点を見落とすミスが多発します。

緊急復旧手順：

1. 新サーバーのコントロールパネルから、該当ドメイン用に作成したデータベース設定（DB名、DBユーザー名、DBパスワード、MySQL接続ホスト名）を再確認する。
2. 新サーバーの wp-config.php を開き、以下の4つの定義が新サーバーの設定値と一字一句違わず完全一致しているか照合・修正する。

// wp-config.phpのデータベース設定確認箇所
define( 'DB_NAME', '新データベース名' );
define( 'DB_USER', '新ユーザー名' );
define( 'DB_PASSWORD', '新パスワード' );
define( 'DB_HOST', '新MySQLホスト名' ); // localhostとは限らないため要確認

トラブル3：トップページ以外が404エラーになる（個別記事・固定ページが表示されない）

主な原因：.htaccessのリライトルールの欠落・非反映
トップページは正常に表示されるのに、投稿記事やカテゴリーページを開くと「404 Not Found」になる現象です。手動移行や簡単移行の直後に最も頻発するトラブルですが、解決は非常に簡単です。

緊急復旧手順（定番処方箋）：

1. WordPress管理画面にログインし、左メニューの「設定 ＞ パーマリンク」を開く。
2. 設定内容（投稿名やカスタム構造など）を一切変更せず、そのまま画面下部の「変更を保存」ボタンを1回クリックする。
3. この操作により、WordPressが新サーバーの .htaccess ファイルに正しいリライトルールを自動で再生成・上書きし、全ページの404エラーが一瞬で解消します。

トラブル4：画像が表示されない・リンク切れやMixed Content警告が発生する

主な原因：画像パスのドメイン不整合・旧サーバーURLの残存・SSL混在
移行前のテスト環境URLや旧ドメイン、あるいは http:// の古いURLが記事本文のデータベース内に残っていると、画像が表示されなかったり、ブラウザで「一部の通信が保護されていません（Mixed Content）」の警告が表示されます。

緊急復旧手順：

1. プラグイン「Better Search Replace」を新サイトにインストール・有効化する。
2. 検索文字列に http://自社ドメイン、置換文字列に https://自社ドメイン を指定し、全データベーステーブルを対象に安全に置換を実行する（まずは「Run as dry run?（テスト実行）」で確認してから本番置換を行う）。
3. 画像ファイルが wp-content/uploads/ 配下に正しくアップロードされているか、パーミッション（通常ディレクトリは705または755、ファイルは604または644）が適切か確認する。

トラブル5：DNS浸透中のデータ先祖返り・書き込み不整合

主な原因：DNS伝播期間中の旧サーバー側への新規書き込み
ネームサーバーを切り替えてから世界中に浸透するまでの1〜2日間は、一部のユーザーが旧サーバーへ、一部のユーザーが新サーバーへアクセスする「通信の混在状態」になります。この間に問い合わせフォームの送信やECの注文、ブログのコメント書き込みがあると、データが旧サーバーのDBに書き込まれてしまい、新サーバーへ反映されない「データの先祖返り・欠損」が発生します。

事前の完全防止策：

• ネームサーバー切り替え直前に「旧サイトをメンテナンスモード」にする : 新サーバーへ最終データベースをコピーした直後、旧サーバー側のWordPressに「WP Maintenance Mode」等のプラグインを適用するか、旧サーバーの wp-config.php のDB接続パスワードを一時的に書き換えて新規書き込みを完全に遮断します。
• これにより、仮に旧サーバーへアクセスが流れた場合でも、ユーザーに「サーバー移転メンテナンス中」である旨を案内でき、データベースの不整合や二重書き込みを100%防止できます。

---

【保存版】WordPressサーバー移行前・移行中・移行後の実務チェックリスト20項目

サーバー移行作業を漏れなく確実に完了できるよう、「移行前」「移行中」「移行後」の実務チェックリスト20項目をまとめました。作業時に印刷またはコピペして、一つひとつの工程を確認しながら進めてください。

移行前フェーズ（準備・バックアップ：10項目）

• [ ] 新旧サーバーの契約期間が最低1ヶ月重複していることを確認した（即時解約の禁止）
• [ ] 旧サーバーの全ファイル（wp-content等）をPCローカルまたはクラウドへ手動ダウンロードした
• [ ] 旧サーバーのデータベース（MySQL/SQLファイル）をphpMyAdmin等から完全エクスポートした
• [ ] 不要なリビジョンやゴミデータを削除し、データベースを事前に軽量化・最適化した
• [ ] WordPress本体、テーマ、プラグインを安定稼働するバージョンに揃えた
• [ ] 新サーバーのPHPバージョンが既存サイトの構成と互換性があることを確認した
• [ ] 新サーバーのコントロールパネルで独自ドメインの追加設定を完了した
• [ ] 新サーバー側で「無料独自SSL」の事前申請・事前認証を完了した
• [ ] ネームサーバー切り替え前に、新サーバー上で同一のメールアカウントを作成した
• [ ] ドメインレジストラのDNS設定画面で、TTL値を「300秒」に短縮設定した

移行中フェーズ（データ展開・事前検証：5項目）

• [ ] 簡単移行ツールまたはDuplicatorを用い、新サーバーへのデータ展開を完了した
• [ ] パソコンのhostsファイルを編集し、自端末のみ新サーバーへ向く環境を構築した
• [ ] 新環境のWordPress管理画面へ正常にログインできることを確認した
• [ ] 主要記事・固定ページ・画像表示・問い合わせフォームのテスト送信を新環境で検証した
• [ ] 動作検証完了後、hostsファイルの記述を忘れずに削除・元に戻した

移行後フェーズ（本番切り替え・安定運用：5項目）

• [ ] 旧サーバー側を一時的にメンテナンスモードにし、新規書き込み不整合を防止した
• [ ] ドメインレジストラでネームサーバー情報を新サーバーへ変更した
• [ ] 管理画面の「設定 ＞ パーマリンク」を開き、何も変えずに「変更を保存」を実行した（404対策）
• [ ] 各種端末（PC・スマホ実機・シークレットウィンドウ）でSSL接続と正常表示を確認した
• [ ] DNS切り替えから2週間〜1ヶ月の安定稼働とメール送受信を確認後、旧サーバーを解約した

---

🔍 サーバー移行後の安全性・設定不備をMozCheckで今すぐ無料診断

サーバーの引越しが無事に完了した直後は、「初期設定の抜け漏れによるセキュリティ脆弱性」が最も発生しやすい警戒期間です。

新サーバーへ移転したことで、WAFの再設定漏れ、SSL設定の不備、ディレクトリリスティング（サーバー内のファイル一覧露出）、意図しないテストファイルの残存などが生じているケースが少なくありません。新しいサーバー環境で脆弱性や設定ミスがないか、今すぐ無料診断ツールで総点検を行いましょう。

---

まとめ：綿密な事前準備とDNS切り替え手順でサーバー引越しは怖くない

WordPressのサーバー移行は、サイトの表示速度を劇的に改善し、アクセス急増時の安定性と強固なセキュリティ基盤を手に入れるための最も確実な投資です。

最後に、失敗しないサーバー移行の超重要ポイントを振り返りましょう。

1. アクセスが落ち着く年末年始の連休を活用し、約2週間の無理のないスケジュールを組む
2. 新旧サーバーを最低1ヶ月は並行稼働させ、作業前のクリーンバックアップを外部退避する
3. ネームサーバーを切り替える前に、新サーバー側で「無料独自SSL」を事前申請・有効化しておく
4. パソコンのhostsファイルを編集し、世界へ公開する前に自分だけの環境で完全動作確認を行う
5. ネームサーバー変更数日前にTTLを300秒へ短縮し、切り替え直前の旧環境メンテナンスモード適用でデータ先祖返りを防ぐ
6. 同一メールアカウントを事前に新サーバーで準備し、DNS浸透を見届けてから旧サーバーを解約する

手順と順序さえ正しく守れば、ダウンタイムも表示警告も一切発生させずにWordPressを安全に移転させることができます。本記事の工程表とチェックリストを相棒に、ぜひ快適な新サーバー環境への引越しを実現させてください。

---

関連記事・あわせて読みたい年末年始メンテナンスガイド

サーバー移行とあわせて、プラグインやバックアップ体制全体の総点検を行うには「年末年始のWordPress保守総点検チェックリスト」をご活用ください。

また、新サーバーへ移行する前に不要なリビジョンやゴミデータを削減しておくと、移行時間を大幅に短縮できます。詳しくは「年末年始のWordPressデータベース大掃除・最適化手順」を参照してください。