【ダウンタイムゼロ】WordPressサーバー移行の完全手順｜hosts活用・SSL事前設定

公開日: 更新日: 投稿者: ブロガー夫婦：森広志：エンジニア
目次

サーバー移行は、Webサイト運用において最もリスクの高いプロジェクトの一つです。

DNS切り替えのタイミングで発生する「数時間のダウンタイム」、切り替え直後の「SSL証明書エラー（保護されていません）」、そして予期せぬ「SEO順位の急落」。これらは、手順の順序を一つ間違えるだけで確実に発生します。

多くの「移行ガイド」では、プラグインを使用したデータ移行を推奨していますが、プロの現場では不十分です。DNSが切り替わるまで新環境の動作確認ができない「ぶっつけ本番」の手法では、ビジネスにおける機会損失を防げないからです。

本記事では、「hostsファイル」を活用したローカルDNSスプーフィングと、DNS切り替え前のSSL事前認証を組み合わせた、エンジニア向けの堅牢な移行フローを解説します。

一般ユーザーには現行サイトを見せたまま、裏側で新環境を構築・検証し、ダウンタイム「ゼロ秒」で安全にサーバーを切り替える技術手順を習得してください。

Step0. 移行環境の定義と前提条件

移行作業における事故（データ損失、長時間ダウンタイム）の9割は、環境差異の確認不足と権限情報の不備に起因します。

作業着手前に、現行環境（Prod）と新環境（New-Prod）の仕様差分を明確化し、SSH/DB接続に必要な認証情報を手元に揃えてください。特にPHPバージョンの不一致は、移行直後の「500 Internal Server Error」の主因となります。

現行環境（Prod）と新環境（New-Prod）のサーバー仕様

移行元と移行先の環境仕様を照合します。特に以下の3点は、アプリケーションの動作に直結するため必ず確認してください。

項目確認ポイント・リスク
PHPバージョン最重要。移行元が7.x系、移行先が8.x系の場合、廃止された関数によりサイトがクラッシュする可能性があります。移行先サーバーの設定で、一時的に旧環境のバージョンに合わせることを推奨します。
WebサーバーApache / Nginx / Litespeed等の違い。.htaccessの記述（リダイレクトやセキュリティ設定）が効くかどうかに影響します。Xserver同士であれば基本構成は同じですが、プラン変更時は注意が必要です。
DBバージョンMySQL / MariaDBのバージョン差異。基本的には上位互換ですが、極端に古いバージョンからの移行時は文字コード（utf8mb4等）の扱いに注意が必要です。

【メールサーバーに関する重要警告】

本手順はWebサイトの移行に特化していますが、DNS（ネームサーバー）を切り替えると、同ドメインで使用しているメール（@prod.com）も新サーバー経由に切り替わります。 新サーバー側でも同名のメールアカウントを作成しておかないと、切り替え後にメールが不達となります。Web作業と並行してメールアカウントの準備も必ず行ってください。

【Xserver特有の注意点：WAF設定】

Xserverには強力なWAF（Webアプリケーションファイアウォール）が標準搭載されています。REST APIやXML-RPCを使用するバックアッププラグインや外部ツールを使用する場合、WAFが通信を遮断し「403 Forbidden」を返す頻度が高いです。

  • 推奨アクション： 移行作業中（特にデータインポート時）は、新サーバー側のWAF設定を一時的に「OFF」にすることを強く推奨します。

必須情報（FTP/SSH接続情報、DB接続情報）

効率的に作業を進めるため、以下の接続情報をテキストエディタ等に控えてください。GUI（ファイルマネージャー）ではなく、ターミナル操作やローカルのFTPクライアントを使用することで、作業時間を大幅に短縮できます。

1. サーバー接続情報（FTP / SFTP / SSH）

エンジニアであれば、転送速度と安全性の観点からSSH接続の利用を推奨します。

  • ホスト名（SV番号.xserver.jp 等）
  • ユーザー名
  • パスワード（または公開鍵認証のパス）
  • ポート番号（SFTP/SSHは通常22以外の場合が多い。Xserverは10022）

2. データベース接続情報

wp-config.phpの書き換え時に必須となります。

  • データベース名
  • データベースユーザー名
  • データベースパスワード
  • データベースホスト名（注意： Xserverはlocalhostではなくmysqlxxxx.xserver.jpのような固有ホスト名が割り当てられます）

3. WordPress管理者権限

  • ログインURL（セキュリティプラグイン等で /wp-admin から変更されている場合はそのパス）
  • 管理者ID / パスワード
  • ※Basic認証がかかっている場合は、そのID/PWも必要です。

Step1. 現行サーバーでのバックアップ取得

プラグインによるバックアップは手軽ですが、ファイルサイズ制限やPHPの実行時間制限（Time Out）により、大規模サイトでは失敗するリスクがあります。

エンジニアであれば、「ファイル領域」と「データベース領域」を物理的に分けて手動取得する方法が最も確実であり、トラブルシューティングも容易です。

ファイル一式（/wp-content/他）のダウンロード

WordPressの全ファイルをダウンロードする必要はありません。新サーバーではクリーンインストール（最新のコアファイル配置）を行うため、移行に必要な以下の固有データのみを取得します。

  1. /wp-content/ ディレクトリ配下すべて（テーマ、プラグイン、画像・アップロードファイル）
  2. wp-config.php（DB接続情報やSaltキーの参照用。上書きはしない）
  3. .htaccess（リダイレクト設定やセキュリティ設定の参照用）

【推奨：SSHを用いた高速バックアップ】

FTPで数万個のファイルを個別にダウンロードすると数時間かかる場合があります。SSH接続が可能であれば、サーバー上で圧縮してからダウンロードしてください。

Bash

# wp-contentディレクトリへ移動

cd /home/user_id/domain_name/public_html/

# wp-contentをtar.gzで圧縮

tar -czvf wp-content_backup.tar.gz ./wp-content

※作成された wp-content_backup.tar.gz をFTPソフトでダウンロードすれば、転送時間は数分で完了します。

データベース（MySQL）のダンプ・エクスポート

記事データや設定値が含まれるデータベース（SQLファイル）を取得します。

A. SSH / コマンドラインでの取得（推奨）

mysqldump コマンドを使用すれば、タイムアウトを気にせず一瞬でエクスポート可能です。

Bash

# DBバックアップコマンド例

mysqldump -u [DBユーザー名] -p -h [DBホスト名] [DB名] > db_backup.sql

※Xserverの場合、DBホスト名は localhost ではなく mysqlxxxxx.xserver.jp となる点に注意してください。

B. phpMyAdminでの取得

GUIを使用する場合、phpMyAdminの「エクスポート」機能を使用します。

  • エクスポート方法: 「詳細」を選択
  • 生成オプション: DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT を追加 にチェックを入れる（インポート時のテーブル重複エラーを防ぐため）
  • データ: 完全な INSERT 文を作成する を選択
  • 出力: 圧縮（gzip）を選択して実行

このバックアップ取得時点からDNS切り替え完了までの間に記事更新やコメント投稿が行われると、「データの先祖返り（消失）」が発生します。

可能な限り、現行サイトにBasic認証をかけるか、メンテナンスモードプラグインを有効化し、データ更新を凍結した状態でバックアップを取得してください。

Step2. 新サーバーの構築とデータ配置

DNSレコードがまだ旧サーバーを指している状態で、新サーバー上に「受け皿」となるアプリケーション環境を構築します。

ここでは手動でDBを作成する手間を省くため、Xserverの「WordPress簡単インストール」機能を活用し、その後にデータを入れ替える手法を採用します。

新サーバーへのドメイン追加設定（DNS未変更）

Xserverのサーバーパネルにて、移行対象のドメインを追加します。

  1. サーバーパネル > ドメイン設定 > ドメイン設定追加 を選択。
  2. ドメイン名（例: prod.com）を入力。
  3. 重要: 「無料独自SSLを利用する」のチェックを外してください。
    • 理由: 現時点でDNSが新サーバーを向いていないため、SSL認証（Let’s Encrypt）は必ず失敗します。SSL設定はStep4で個別に行うため、ここではドメインの箱だけを作ります。
  4. 「確認画面へ進む」→「追加する」をクリック。

WordPressクリーンインストールとDB作成

空のWordPressをインストールし、ディレクトリ構造とデータベース（DB）を自動生成させます。

  1. サーバーパネル > WordPress簡単インストール を選択。
  2. 対象ドメインを選択し、「WordPressインストール」タブをクリック。
  3. 必要な情報を入力してインストールを実行。
    • サイトURL: ドメインのみ（サブディレクトリ不要）
    • データベース: 「自動でデータベースを生成する」を選択
    • ユーザー名/PW: 任意（後でDBインポート時に上書きされるため何でも良い）
  4. インストール完了後、表示されるMySQL接続情報（データベース名、ユーザー名、パスワード）を必ずメモしてください。

バックアップデータのインポートとwp-config.php接続情報修正

「空のWordPress」を「旧環境のデータ」に置換します。ここで最も技術的なミスが起きやすいため、手順を厳守してください。

1. 静的ファイル（wp-content）の差し替え

FTP/SSHで新サーバーのドキュメントルート（/home/user/domain/public_html/）にアクセスします。

  • 既存の wp-content ディレクトリを削除します。
  • Step1でバックアップした旧環境の wp-content をアップロードします。

2. データベースのインポート

新サーバーのphpMyAdminにログインします（ID/PWは先ほどメモしたもの）。

  • 対象のデータベースを選択します。
  • 「簡単インストール」で生成された初期テーブル（wp_users, wp_options 等すべて）をすべて選択し、「削除（DROP）」します。
    • 目的: 完全に空にしてからインポートしないと、主キー重複エラー等が発生します。
  • 「インポート」タブから、Step1で取得したSQLファイル（db_backup.sql）をアップロード・実行します。

3. wp-config.php の整合性確認（最重要）

新サーバー上の wp-config.php を確認します。旧環境のファイルを上書きしてはいけません。（DB接続情報が旧サーバーのものになり、接続エラーになります）

確認すべきは「テーブル接頭辞（Prefix）」の一致です。

  • 旧環境: Step1でバックアップした wp-config.php を開き、$table_prefix の値を確認（例: ‘wp_’ や ‘wp1234_’）。
  • 新環境: サーバー上の wp-config.php を編集し、$table_prefix の値を旧環境と同じものに書き換えます。

PHP

/**

 * 新サーバーのwp-config.php

 * DB接続情報（DB_NAME等）は新サーバーのまま維持する。

 * 下記の接頭辞だけ、旧環境に合わせて修正する。

 */

$table_prefix = ‘wp_’; // ← ここが旧データと一致していないとサイトが表示されません

Step3. hostsファイル設定による動作検証

DNSを切り替える前に、新サーバー上でWebサイトが完全に動作するかを検証します。

PC内のhostsファイルを編集し、対象ドメインの向き先（IPアドレス）を強制的に新サーバーへ向けることで、疑似的な切り替え状態を作り出します。

PCローカルのhostsファイル書き換え（IP固定）

1. 新サーバーのIPアドレスを確認

Xserverサーバーパネルの「サーバー情報」を開き、「IPアドレス」の項目をコピーします。

（例: 183.18.xxx.xxx）

2. hostsファイルの編集

OSごとに以下のファイルを管理者権限で開きます。

  • Windows: C:\Windows\System32\drivers\etc\hosts
    • ※メモ帳などを「管理者として実行」して開いてください。
  • Mac / Linux: /private/etc/hosts
    • ターミナルで sudo vi /private/etc/hosts 等を実行。

3. 設定の追記

ファイルの末尾に、以下の形式で一行追記して保存します。

Plaintext

# [新サーバーIPアドレス] [半角スペース] [ドメイン名]

183.18.xxx.xxx prod.com

183.18.xxx.xxx www.prod.com

エンジニア向けのTips:

編集後、ブラウザが旧DNSキャッシュを保持している場合があります。Chromeのシークレットウィンドウを開くか、コマンドプロンプト/ターミナルでDNSキャッシュをクリアしてください。

  • Win: ipconfig /flushdns
  • Mac: sudo killall -HUP mDNSResponder

新サーバー環境での表示・管理画面ログイン確認

hosts設定後、ブラウザでサイトにアクセスします。

見た目は変わりませんが、接続先が新サーバーに変わっているはずです。以下の手順で「本当に新サーバーに繋がっているか」を確証し、動作チェックを行います。

1. 接続先IPの確認（必須）

Chrome等の開発者ツール（F12）を開き、「Network」タブを選択します。

リロードして最初のHTMLリクエスト（ドメイン名）をクリックし、Header情報の 「Remote Address」 が新サーバーのIPになっているか確認してください。

  • 旧IPのままの場合：hosts設定が反映されていません。ブラウザ再起動等を試してください。

2. 動作検証チェックリスト

接続先が正しいことを確認したら、以下の項目を重点的にテストします。

  • トップページおよび下層ページの表示:
    • もし下層ページが 404 Not Found になる場合、管理画面の「設定 > パーマリンク」を開き、何も変更せずに「変更を保存」ボタンを押してください。これで .htaccess が再生成され、リンク構造が修復されます。
  • 管理画面へのログイン:
    • ログイン可否、記事の保存、画像のアップロード機能を確認します。
  • 画像の表示:
    • メディアライブラリの画像が表示されているか確認します。表示されない場合、wp-content/uploads のパーミッション（通常755）または所有権の問題です。
  • お問い合わせフォーム:
    • テスト送信を行い、メールが届くか確認します（サーバーのメール送信機能の確認）。

Step4. DNS切り替え前のSSL事前設定

ここが多くのエンジニアが躓き、「切り替え直後のSSLエラー（保護されていません）」を発生させるポイントです。

DNSがまだ旧サーバーを向いている状態で、いかにして新サーバー用のSSL証明書を発行させるか、その「認証ロジックのハック（Web認証）」を解説します。

通常、無料独自SSL（Let’s Encrypt）は、発行申請時に「そのドメインがサーバーに紐付いているか」をDNS経由で確認します。

今回はDNSがまだ旧サーバーを向いているため、普通に申請ボタンを押すだけでは「ドメイン認証失敗」となり、追加できません。

しかし、Xserverの「他社サーバーでのWeb認証」機能を利用することで、DNS切り替え前に証明書を裏側で発行・インストールすることが可能です。

Xserverパネルでの無料独自SSL追加申請

新サーバーのサーバーパネルにて操作を行いますが、認証用ファイルは旧サーバーに設置する必要があります。この「認証のねじれ」を理解して作業してください。

1. SSL追加申請（Web認証の選択）

  • 新サーバーのパネルで「SSL設定」>「独自SSL設定追加」を選択します。
  • 対象ドメインを選択し、「確認画面へ進む」をクリックします。
  • ここでエラーが出ますが正常です。 エラー画面、または認証方法の選択肢から「Web認証」を選択してください（または「他社サーバーで運用中」オプション）。

2. トークンファイルのダウンロード

  • 画面に表示される「トークンファイル（認証用ファイル）」をダウンロードします。
  • または、表示された「ファイル名」と「記述内容」をコピーし、ローカルで同名のファイルを作成します。

3. 旧サーバーへのトークン設置（最重要）

FTP/SSHを使用し、このファイルを「現在稼働中の旧サーバー」にアップロードします。

認証局（Let’s Encrypt）は、現在のDNS（旧サーバー）を見に行って認証を行うためです。

  • アップロード先:
    /home/user/domain/public_html/.well-known/acme-challenge/
  • ※ディレクトリが存在しない場合は作成してください。ドット（.）から始まる隠しディレクトリである点に注意。
  • 重要注記: 旧サーバーでBasic認証をかけている場合、.htaccess で .well-known ディレクトリを除外設定しないと認証に失敗します。

4. 認証の実行

  • アップロード後、ブラウザで http://prod.com/.well-known/acme-challenge/[ファイル名] にアクセスし、文字列が表示されるか確認します。
  • 確認できたら、新サーバーのパネルに戻り「追加する（認証実行）」をクリックします。

これにより、DNSは旧サーバーを向いたままで、新サーバー内に正当なSSL証明書がインストールされます。

SSL認証・発行完了のステータス確認

認証が通ると、ステータスが「反映待ち」になります。

通常、数分～1時間程度で「利用中」に変わりますが、以下の点を確認してください。

  • 「利用中」になるまでDNSは切り替えない:
    ステータスが「利用中」になる前にDNSを切り替えると、証明書のインストールプロセスが中断され、最悪の場合SSL設定が破損します。
  • hosts環境での確認:
    Step3で行ったhosts設定がまだ有効であれば、新サーバーにHTTPS（https://prod.com）でアクセスできるか確認してください。証明書エラーが出ず、鍵マークが表示されれば準備完了です。

Step5. DNS切り替えとSEOリカバリ確認

準備はすべて整いました。ここからは世界中のユーザーを新サーバーへ誘導する「DNS切り替え」と、その後の「正常性確認」を行います。

特にSEO担当者として、「新サーバーで意図せず noindex が入っていないか」の確認は、順位下落を防ぐための最重要事項です。

ネームサーバー（DNS）の変更実行

ドメイン管理画面（今回はムームードメイン）にて、ネームサーバー情報を新サーバー（Xserver）のものに変更します。

  1. ムームードメイン管理画面へログイン:
    • 「ネームサーバー設定変更」を開きます。
  2. ネームサーバー情報の入力:
    • 「GMOペパボ以外のネームサーバーを使用する」を選択し、以下を入力します。
    • ns1.xserver.jp
    • ns2.xserver.jp
    • ns3.xserver.jp
    • ns4.xserver.jp
    • ns5.xserver.jp
  3. 変更の保存:
    • 保存ボタンを押します。反映には数時間～最大24時間程度かかります（プロパガーション期間）。

注記: Xserver間で移行する場合でも、契約IDが異なる場合はネームサーバーの再設定（更新）アクションが必要です。

hostsファイルの復元と一般アクセスの確認

DNS変更を行ったら、必ず自分のPC環境を「一般ユーザーと同じ状態」に戻します。

Step3で設定した hosts の設定が残っていると、自分だけは新サーバーに見えても、世界中からはまだ旧サーバーが見えている（または繋がらない）状態に気づけません。

1. hostsファイルの復元

  • Step3で追記した IPアドレスとドメインの記述行（183.18.xxx.xxx prod.com）を削除、またはコメントアウト（#）して保存します。

2. プロパガーションの確認

  • コマンドプロンプト/ターミナルで nslookup prod.com を実行し、返ってくるIPアドレスが新サーバーのものに変わっているか確認します。
  • または、外部ツール「Whatsmydns.net」を使用し、世界各国のDNSサーバーが新IPを認識しているかチェックします。

検索エンジン巡回確認（robots.txt・計測タグ・GSC）

サイトが表示されただけでは完了ではありません。SEOとマーケティングデータの「血管」が繋がっているかを検証します。

1. インデックス制御の確認（事故率No.1）

新サーバーのWordPress設定で、誤って検索エンジンをブロックしていないか確認してください。

  • 確認場所: 管理画面 > 設定 > 表示設定
  • チェック項目: 「検索エンジンがサイトをインデックスしないようにする」のチェックが外れていること。
  • ソースコード確認: <head> 内に <meta name=”robots” content=”noindex”> が存在しないこと。

2. 計測タグの発火確認（機会損失防止）

GA4（Google Analytics）やGTM、広告コンバージョンタグが正常に動作しているか確認します。

  • GA4リアルタイム: 自分でサイトにアクセスし、GA4の「リアルタイム」レポートで計測されているか確認します。
  • ※プラグイン設定の移行漏れにより、タグIDが空欄になっているケースが多発します。

3. Google Search Console（GSC）での検証

  • URL検査ツール: GSCでトップページ等のURLを検査し、「公開URLをテスト」を実行します。Googlebotが正常にアクセスでき（200 OK）、レンダリングできているか確認します。
  • サイトマップ送信: 念のため、XMLサイトマップ（/sitemap.xml）を再送信し、クローラーの巡回を促します。

移行の成否は「切り替え前の準備」で決まる

本記事では、Xserver間でのWordPress移行を例に、ダウンタイムとSEOリスクを最小化する以下の5ステップを解説しました。

  1. 環境定義とバックアップ： 物理的なファイルとDBを分離して保全する。
  2. 新環境のサイレント構築： DNS変更前に、裏側で受け皿を完成させる。
  3. hostsによる動作検証： 自分だけが新サーバーへアクセスし、表示・ログインを保証する。
  4. SSL事前設定： Web認証を用い、HTTPSエラーの発生を未然に防ぐ。
  5. DNS切り替えとSEOリカバリ： 切り替え後のインデックス監視で順位を守る。

サーバー移行において最も重要なのは、「DNSを切り替えた後に祈る」ことではなく、「切り替える前に勝算を確定させる」ことです。

今回解説したhostsファイルを活用した検証フローを踏めば、どのようなトラブルが起きても、DNS切り替え前に検知・修正が可能になります。

最後に：ロールバックプランの確保

移行が完了しても、旧サーバー（移行元）の契約は即座に解約せず、最低1ヶ月は保持してください。

万が一、特定のプラグインが新環境のPHPバージョンで動かない等の致命的な不具合が発覚した場合、DNSを旧サーバーに戻すだけで即座に復旧（ロールバック）できるからです。

「常に最悪のケースを想定し、リカバリ手段を確保しておく」。

このエンジニアリング思想こそが、SEOにおける検索順位と、その背後にいるユーザー体験を守る唯一の手段です。

To Page Top