ドメインを変えずに WordPress のホストを移す：移行・検証・DNS 切り替え

数年使ってきたスタジオのサイトを別のホストへ移したいが、名刺の刷り直しや記事 URL の変更は避けたい。こうした移行では独自ドメインとパスを維持できる場合が多く、実際に変わるのはサイトを配信するホスト環境です。先に新サイトを検証してからアクセスを移す方が、最初から DNS を変更するより問題を特定しやすくなります。

見落としやすいのはファイル容量より、移行中にも届くデータです。最初の複製後に旧サイトがコメントや問い合わせを受け取ることがあります。新サイトもそのまま公開すると、記録が両方に分かれかねません。以下では最後のデータ引き継ぎを独立した工程とし、サイトだけでなく最新の記録がどこにあるかを確認します。

引き継ぎ表を作り、移行範囲を決める

旧ホスト、新ホスト、ドメイン登録事業者、DNS 提供者を列挙します。一社が四役を兼ねる場合も、すべて別々の場合もあります。サイトのホストだけを変えるなら、ドメイン登録先の移管は必須ではありません。ネームサーバーも変更するなら、サイトの IP だけでなく DNS レコード全体を確認します。

WordPress、PHP、データベースの各バージョン、ディスク使用量、主なプラグインも記録します。メール、定期実行ジョブ、送信メール、CDN、外部サービスのコールバック URL は別に列挙します。移行プラグインが何を運べるかは、そのバージョンと実際の設定で確認してください。一つのエクスポートファイルだけでホスト管理画面の全サービスが移るわけではありません。

1. 旧ホスト、新ホスト、DNS、バックアップ保存先に誰がログインできるか確認する。
2. 現在の DNS レコードとサイト全体のバックアップを保存し、取得方法を記録する。
3. 切り替え時間を決め、サイト更新や注文処理を担当する人へ知らせる。

新ホストに検証可能なコピーを作る

新ホストにサイト領域、データベース、必要なソフトウェアのバージョンを用意し、ホストの移行サービスまたは選んだツールの手順でファイルとデータベースを取り込みます。接続情報の変更が必要なら新ホストが提供する値を使い、旧ホストの認証情報で上書きしないでください。独自のサーバー規則も新環境で有効か確認します。

URL を変えないホスト移行では、サイトに保存された公開 URL も同じままにします。UpdraftPlus の公式案内にはこの場合の専用手順があり、データベース内の URL を不用意に置換しないよう説明しています。仮 URL でプレビューするとリンクやログインの動作が変わる場合があります。正式 URL を維持したまま検証する方法をホスト事業者に確認してください。

コピーへのアクセスを制限し、本番の決済、通知、外部への書き込みを停止します。特に定期実行ジョブが新旧両方からメールを送らないようにします。隔離方法と公開時に戻す機能を一覧にして、必要なサービスを再開し忘れないようにします。

本当に新ホストを見ているか確かめる

ブラウザーに同じ画面が出ると旧サイトを新サイトと取り違えやすくなります。ホストが提供するプレビュー入口を使うか、PC の設定に慣れた人がローカルの hosts ファイルを一時的に変更し、元のドメインを新 IP に向けます。これはテスト用 PC だけに影響し、世界中の DNS を変えるものではありません。終了後はその設定を削除します。

新サイトにアクセス制限付きの識別用目印を置き、新ホストのアクセスログと照合してリクエストが実際に届くか確認できます。HTTPS 証明書も適切に用意し、ブラウザーの警告を無視してよい公開状態とは考えないでください。証明書発行にドメインの事前確認が必要なら、そのホストが案内する方法に従います。

1. トップページ、記事、画像、ダウンロード、ログイン画面を開き、仮 URL に戻らないことを確認する。
2. 検索、メニュー、フォーム、必要な機能を操作し、通知がテスト用の受信先に届くか調べる。
3. モバイル表示、旧記事の固定リンク、エラーページを確認して問題一覧を残す。

最後に増えたデータを引き継ぐ

最初の複製は機能検証に向いていますが、本番の切り替え前にはデータの基準時点を決める必要があります。更新の少ないサイトなら、調整した時間帯に投稿と操作を止め、最後のバックアップと取り込みをして最新内容を照合します。取引が続くサイトでは、そのシステムを知る人に同期と重複排除を設計してもらい、データベース全体を上書きしないでください。

機能を一時停止する際は、再開予定と連絡方法を訪問者へ明確に示します。切り替え前後の記録件数、最新記録の時刻、関係する識別子を保存しますが、個人情報を公開文書に入れてはいけません。データの一致を確かめてから書き込み再開を決め、検証中に新たな差分を作らないようにします。

DNS を切り替え、別々のネットワークで結果を見る

DNS サービスで適切な TTL を事前に設定すると、新しいレコードの採用待ち時間を短くできます。ただしキャッシュ済みの旧値は保存ボタンを押してもすぐには消えません。切り替え時には計画したサイト用レコードだけを変更し、ルートドメイン、www、IPv4、IPv6 に旧向き先が残っていないか確認し、使用中のメール用レコードは維持します。

公開前にはテストサイトのアクセス制限とテスト用のインデックス禁止設定を解除し、必要な連携を有効にします。自宅回線とモバイル回線で結果を見て、新旧ホストのログを比較します。Google のホスト変更ガイドも両側のトラフィックを監視するよう勧めています。一台の PC で正常でも、全訪問者の切り替えが終わった証拠にはなりません。

切り戻し条件を先に決め、旧ホストは最後に停止する

重要な機能から送信できない、データが欠ける、多数の個別ページが壊れるなど、切り戻しが必要な条件を事前に決めます。DNS を元に戻すなら、まず新ホストで発生したデータを洗い出して保存します。そうしないと旧サイトへ戻った際に直前の記録が失われる可能性があります。切り戻しは IP を戻すだけでなく、データを引き継ぐ作業です。

発見時刻、URL、使用したネットワーク、期待した結果、実際の結果を記す問題記録も残します。各問題の担当者を固定します。複数人が同時に DNS、プラグイン、ホスト設定を変えると、特定できたはずの問題を再現しにくくなります。

新ホストが安定してアクセスを処理し、旧サイトに対応が必要な訪問者やサービスが残らず、新環境のバックアップも保存できたと確認してから旧ホストの停止を計画します。旧プランがメールや DNS も提供しているなら先にそれらを移します。自動更新の停止と即時削除は結果が異なる場合があるため、操作前に請求画面を読んでください。

復元できるサイトのバックアップを先に作る

DNS レコードと名前解決の問題を理解する

サイトの HTTPS 証明書を設定する

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress