WordPressのサーバー移行で「ドメインはそのまま使いたい」「URLは変えたくない」と考えるケースが多いかと思います。この場合、作業の中心になるのはドメイン移管ではなく、新しいサーバーに同じドメインを受けさせて、DNSの向き先だけを安全に切り替えることです。WordPress本体のURLが変わらないぶん、移行全体の難しさは下がりますが、TTL、hostsファイル、SSL、メール影響などの確認作業を怠ると事故につながりやすいです。
一方で、サーバー移行と同時にドメインも変更する場合は、siteurl と home の変更、URL置換、301リダイレクト、Search Consoleの対応まで必要になります。つまり、ドメインそのまま移行とドメイン変更ありの移行は似て見えても、実務では別の作業として考えたほうが安全でしょう。
- ドメインそのままのサーバー移行で、何を変えて何を変えないかが分かる。
- TTL短縮、hostsファイル確認、DNS切替の順番を整理できる。
- WindowsとMacのhosts編集例をまとめて確認できる。
- ダウンタイムを小さくするための進め方が分かる。
- ドメイン変更を伴う場合の追加手順もまとめて把握できる。
先に結論
WordPressのサーバー移行は、ドメインをそのまま維持したまま進めるのが基本です。同じURLを使い続けるなら、WordPressアドレスやサイトアドレスを無理に変更する必要はありません。移行先サーバーに同じドメインを設定し、hostsファイルで事前確認し、最後にDNSの向き先を切り替える流れで進めるのがもっとも安定します。
反対に、ドメイン変更を伴う場合は、単なるサーバー切替では終わりません。DB内URLの置換、旧ドメインから新ドメインへの301リダイレクト、Search Consoleやサイトマップの更新まで必要です。サーバー移行とドメイン変更を同時にやるなら、作業量は一段増えると考えて計画してください。
- ドメインそのまま移行では、WordPressのURL設定は原則そのままです。
- 実際に変えるのは、AレコードやAAAAレコード、またはネームサーバーです。
- 切替前にTTLを短くしておくと、反映待ちを短くしやすくなります。
- hostsファイルで新サーバーを確認してからDNSを切り替えると事故を減らせます。
- ドメイン変更ありの移行では、URL置換とリダイレクトが追加で必要です。
ドメインそのまま移行で変わるものと変わらないもの
| 項目 | ドメインそのまま | ドメイン変更あり |
|---|---|---|
| WordPressアドレス | 原則そのまま | 新URLへ変更が必要 |
| DNS設定 | 切替が必要 | 切替が必要 |
| DB内URLの置換 | 通常は不要 | 必要 |
| 301リダイレクト | 通常は不要 | 必要 |
| Search Console対応 | 監視中心 | プロパティ追加や移転対応が必要 |
| SSL再設定 | 必要になることが多い | 必要 |
この表のとおり、ドメインそのままの移行では、読者や検索エンジンから見えるURLは変わりません。大きく変わるのは、そのドメインが向いているサーバーの行き先です。そのため、SEO面でも「URL変更」より影響が小さく、切替作業はDNSとサーバー設定の整合性に集中しやすくなります。
ドメイン移管とサーバー移行は別作業です
ここで混同しやすいのが、ドメイン移管とサーバー移行です。ドメイン移管は、レジストラや管理会社を変える作業です。サーバー移行は、Webサイトの実体を置くサーバーを変える作業です。WordPressを別サーバーへ移しても、ドメイン管理会社を変えないなら、ドメイン移管は不要です。
実務では、まずサーバー移行だけを終わらせ、そのあと必要ならドメイン管理を見直すほうが切り分けしやすいです。1回の作業で要素を増やしすぎると、問題が出たときに原因が追いにくくなります。
ドメインそのままで安全に切り替える全体フロー
TTLを事前に短くする
↓
新サーバーを準備する
↓
ファイルとDBを移行する
↓
hostsファイルで新サーバーを事前確認する
↓
切替直前に最終同期する
↓
DNSを切り替える
↓
SSL・フォーム・管理画面・画像を確認する
↓
48〜72時間は旧サーバーを残し、安定後にTTLを戻す流れ自体はシンプルですが、失敗しやすいのは「切替前の確認不足」と「切替後すぐに旧サーバーを消してしまうこと」です。事前確認とロールバック余地を残しておけば、大半の事故は吸収できます。
より広い手順を最初から見直したい場合は、WordPressサーバー移行の全手順もあわせて見ると全体像をつかみやすいです。この記事では、その中でも特にドメイン切替まわりだけを深掘りしています。
切替前に確認したい準備チェックリスト
- 移行元サーバーのフルバックアップを取得している
- 移行先サーバーでWebサーバー、PHP、DB、SSLの前提が整っている
- 新サーバーに対象ドメインを追加できている
- 移行元と移行先のファイル転送方法とDBインポート方法を決めている
- 現在のDNS管理先とTTLの変更方法を把握している
- メールを同じドメインで運用している場合は、MXレコードや送信設定への影響を洗い出している
- 切替後すぐに旧サーバーを解約しない前提で計画している
- 切替作業は更新や注文が少ない時間帯に行う
動的サイトは最終同期の考え方が重要
ブログ中心のサイトなら、切替直前にDBを再エクスポートしてインポートすれば済むことが多いでしょう。しかし、EC、会員制サイト、予約サイト、問い合わせが多いサイトでは、DNS浸透中に旧サーバーへ書き込みが残るとデータ差分が発生します。この場合は、切替直前にメンテナンスモードへ入れる、フォームや注文受付を一時停止する、最終DB同期の時間を短くするといった対策が必要です。
TTLを事前に短くしてDNS切替を早くする
TTLは、DNS情報を各キャッシュがどれくらい保持するかを示す値です。ここが長いままだと、切替後もしばらく旧サーバーへアクセスする利用者が残りやすくなります。切替を予定しているなら、24時間から48時間前までにTTLを短くしておくと反映待ちを短くしやすいです。
- 現在のAレコードやAAAAレコードのTTLを確認する
- 可能ならTTLを300秒または600秒に下げる
- 短いTTLが各キャッシュに行き渡るまで1日ほど待つ
- その後にDNS切替を行う
- 切替が安定したらTTLを3600秒以上へ戻す
DNSを外部サービスで管理している場合は、Aレコードだけの切替で済む構成のほうが影響範囲を小さくできます。反対に、ネームサーバーごと新サーバー会社へ切り替える方式は、メールやTXTレコードを含めたゾーン全体の確認が必要になるため、より慎重に進める必要があります。
hostsファイルで新サーバーを事前確認する方法
DNSをまだ切り替えていない段階でも、hostsファイルを一時的に編集すれば、自分のPCだけ新サーバーへ向けて表示確認できます。これは、WordPressのURLが同じままのサイトを確認するときに特に有効です。仮URLだけの確認では、絶対パス、SSL、リダイレクトの挙動を見落としやすいためです。
Macでの確認例
sudo vi /etc/hosts
203.0.113.10 example.com www.example.com
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder203.0.113.10 の部分を新サーバーのIPアドレスに置き換えてください。確認が終わったら追加した行を削除し、再度キャッシュを流して元の状態に戻します。
Windowsでの確認例
Windowsでは、管理者権限で hosts ファイルを編集します。場所は C:\Windows\System32\drivers\etc\hosts です。追記する内容はMacと同じで問題ありません。
203.0.113.10 example.com www.example.com
ipconfig /flushdns確認後に hosts の追記を戻し忘れると、自分だけ古い確認状態に固定されてしまうことがあります。動作確認が終わったら削除する、という運用を必ずセットにしてください。
DNS切替当日の実務フロー
- 切替直前にファイル差分とDB差分を最終同期する
- 必要ならメンテナンスモードを有効にして更新を止める
- 新サーバー側で管理画面、画像、フォーム、固定ページ、プラグイン挙動を再確認する
- AレコードやAAAAレコード、またはネームサーバーを切り替える
- 反映状況を
dig、nslookup、ブラウザで確認する - SSL証明書の発行や再設定が必要なら実施する
- 48時間から72時間は旧サーバーも残して監視する
ダウンタイムを小さくするコツ
- TTLは前日までに短くしておく
- 本番切替の前に hosts で表示確認を終えておく
- rsync の差分転送を使って最終転送量を減らす
- DBの最終同期はDNS切替直前に行う
- 注文、会員登録、問い合わせが多い時間帯は避ける
- 旧サーバーはすぐ解約せず、ロールバック可能な状態を残す
Cloudflareを使っている場合は、DNSを切り替える前に新サーバー側がCloudflare経由のアクセスを受けられるかも確認しておくと安心です。ファイアウォール、SSLモード、オリジンサーバー証明書の条件がずれていると、切替後に 521 や SSL 関連エラーが出ることがあります。
SSLは事前発行できる場合とできない場合がある
独自SSLは、認証方式によって準備のタイミングが変わります。Web認証前提の無料SSLでは、DNS切替後でないと認証できないことがあります。DNS認証やCloudflare経由で先に用意できる環境なら、切替前に証明書を揃えられる場合もあります。ここは利用中のサーバー会社の仕様に合わせて確認してください。
ドメイン変更を伴う場合の追加手順
同じサーバー移行でも、ドメイン変更が入ると作業内容は一段増えます。最大の違いは、WordPress内部に保存されているURLを新ドメインへ揃える必要があることです。これを後回しにすると、画像、内部リンク、OGP、canonical、プラグイン設定の一部に古いURLが残ります。
URL置換の基本
wp search-replace 'https://old.example.com' 'https://new.example.com' --skip-columns=guid
wp cache flushwp search-replace は、シリアライズされたデータも考慮して置換できるため、手作業でDBを書き換えるより安全です。ただし、必ずバックアップを取ってから実行してください。まず --dry-run で差分を確認し、置換後は wp cache flush でキャッシュも整理しておくと反映確認がしやすくなります。
- WordPressアドレスとサイトアドレスを新ドメインへ更新する
- DB内URLを
wp search-replaceで置換する - 旧ドメインから新ドメインへ301リダイレクトを設定する
- Search Consoleで新旧プロパティを確認し、必要なら移転手続きを行う
- XMLサイトマップ、canonical、OGP、広告タグ、分析タグを見直す
- 外部サービス、CDN、API連携先に旧ドメインが残っていないか確認する
なお、http から https への統一やwww ありなしの統一も、広い意味ではURL変更です。サーバー移行と同じタイミングでまとめることはできますが、301リダイレクトと canonical の整合性を必ず確認してください。
移行時によくあるトラブルと対処
DNSを切り替えたのに旧サーバーが見えます
多くはTTLとキャッシュの問題です。まず dig や nslookup で自分がどのIPを見ているかを確認してください。ブラウザキャッシュやローカルDNSキャッシュ、hostsの戻し忘れでも同じ症状になります。反映確認は、ブラウザだけでなくDNSコマンドでも見るのが基本です。確認方法は DNSが更新されたかどうかの確認方法 も参考になります。
- Macでは
sudo killall -HUP mDNSResponderでDNSキャッシュを更新する - Windowsでは
ipconfig /flushdnsを実行する - Chromeでは
chrome://net-internals/#dnsを開き、Clear host cacheを実行する - hostsファイルの追記を削除し忘れていないかも確認する
特に Mac のローカル確認直後は、sudo killall -HUP mDNSResponder を実行してから再確認すると状況を切り分けやすいです。Chromeでだけ古い結果が残る場合は、chrome://net-internals/#dns の Clear host cache も試してみてください。
SSL証明書が発行できない、または警告が出ます
ドメイン追加の反映前に認証を走らせている、Cloudflareの設定とオリジンサーバーのSSL条件が合っていない、wwwありなしの片方だけ証明書対象に入っていない、といった原因が多いです。証明書の認証方式と対象ホスト名を先に整理すると、切替後の混乱を減らせます。
画像やフォームだけ正しく動きません
ドメインそのまま移行なら、ファイル不足、アップロードディレクトリの権限、PHP拡張差分、外部APIの許可設定が疑わしいです。ドメイン変更ありなら、DB内URLの置換漏れや mixed content が起きていないかを確認してください。まずはブラウザの開発者ツールとサーバーログを見ると切り分けしやすいです。
切替後にログインできない、管理画面がループします
この症状は、siteurl と home の不一致、リバースプロキシやSSL終端の設定差、Cookieドメインの残りが原因になりやすいです。特にドメイン変更を伴う移行では、管理画面URLと実際の公開URLがずれていないかを最初に確認してください。
よくある質問
ドメインそのままのサーバー移行でドメイン移管は必要ですか
必須ではありません。多くの場合は、現在のレジストラやDNS管理をそのまま使い、DNSの向き先だけ変えれば移行できます。ドメイン管理会社まで変える必要があるのは、管理の一本化や料金見直しなど別の理由があるときです。
ドメインそのままならSEO評価は落ちませんか
URLが変わらないため、ドメイン変更より影響は小さいです。ただし、切替後に 5xx エラー、SSLエラー、表示崩れ、速度低下が続くと評価へ影響する可能性があります。切替後しばらくは Search Console と実表示の両方を監視してください。
旧サーバーはいつ解約すればいいですか
最低でも48時間から72時間は残すのがおすすめです。TTLが短くても、利用者側やネットワーク側のキャッシュ、外部連携の再試行で旧サーバーへアクセスが残ることがあります。余裕があるなら1週間程度残しておくと、より安全です。
まとめ
WordPressのサーバー移行でドメインをそのまま使う場合は、WordPressのURL設定をむやみに触るのではなく、新サーバーを準備する、TTLを短くする、hostsで事前確認する、DNSを切り替えるという順番を守ることが大切です。これだけでも事故率はかなり下げられます。
もしドメイン変更も同時に行うなら、URL置換、301リダイレクト、Search Console対応まで含めて別工程として計画してください。全体像から見直したい場合は WordPressサーバー移行の全手順、DNS反映の確認方法は DNSが更新されたかどうかの確認方法 をあわせて読むと進めやすくなります。メール切替は別記事で詳しく整理します。
Comment