WordPressサーバー移行｜ドメインそのまま（URLを変えずに）移す手順と注意点 26.02.20  （更新: 26.02.22）

「WordPressを別サーバーへ移したいけど、ドメインはそのまま（URLを変えずに）運用したい」----このケースで押さえるべき核心は、サイトを新サーバーに"複製して先に動作確認"→最後にDNS（Aレコード等）を切り替える、という流れです。

本記事では、移行当日に慌てないための事前準備、停止時間（ダウンタイム）を最小化する手順、DNS切替の見方、切替後のチェック項目、よくあるトラブルの原因と対処までを、初心者でも手順通りに進められる形でまとめます。

なお、メール（MX）やサブドメイン運用、マルチサイトなどは落とし穴が増えます。該当する方は、目次の該当箇所を先に確認しつつ、必ずフルバックアップを取ってから進めてください。

全体の手順（チェックリスト）を先に確認したい方は下記記事をご覧ください。

サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト

作業が不安な方、代行/相談の注意点などは下記記事をご覧ください。

サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応

結論：ドメインそのまま移行は「DNS切替」が要点

WordPressを別サーバーへ移しても、ドメイン（URL）を変えずに運用を継続できます。結論から言うと、要点は「DNS（Aレコード等）を新サーバーへ向ける」ことです。URLが変わらないのはWordPressの設定ではなく、そのドメインが"どのサーバーを指すか"を決めるDNSが握っているためです。

失敗しやすいのは「先にDNSを切り替えてから新サーバーで調整する」進め方。安全なのは、新サーバー側にサイトを複製して先に動作確認し、問題がない状態を作ってからDNSを切り替える流れです。これで停止時間（ダウンタイム）とトラブルを最小化できます。

移行パターン（通常サイト／サブドメイン／マルチサイト）

「ドメインそのまま移行」と言っても、サイト構成によって確認ポイントが変わります。まずはご自身がどのパターンかを把握しましょう。基本はどれもDNS切替で公開先を切り替える点は同じですが、レコードの種類や影響範囲が変わります。

特に、サブドメインやマルチサイトは、メインドメインだけ切り替えても一部が旧サーバーに残ることがあります。移行前に「どのホスト名（wwwあり/なし、sub.example.com など）が、どのDNSレコードで管理されているか」を洗い出すのが安全です。

作業時間の目安と停止時間を減らす考え方

移行作業は「データ移行」「動作確認」「DNS切替」「切替後チェック」に分けると整理しやすく、停止時間を短くできます。停止が発生しやすいのは、主にDNS切替直前〜切替後の確認のタイミングです。

停止時間を減らすコツは、DNS切替より前に新サーバー側で確認を終えておくこと。例えば hosts を使ってURLを変えずにテストしたり、TTLを事前に短くしてDNSの浸透を早めたりすると、当日のリスクが下がります。

事前準備：現状把握とバックアップ

WordPressのサーバー移行で失敗が起きる原因の多くは、移行作業そのものよりも「事前に把握すべき情報が抜けていた」ことにあります。移行は基本的に「新サーバーへ複製して、最後にDNSを切り替える」だけですが、現状の構成（ドメイン、SSL、メール、プラグイン、特殊設定）が分からないまま進めると、切替後に思わぬ不具合が出ます。

まずやるべきは、現状把握（チェックリスト化）と、いつでも戻せるようにフルバックアップを取ること。これだけで移行の成功率が大きく上がり、当日の焦りが減ります。

現サーバー情報・WordPress環境の確認リスト

まずは「どこで何が管理されているか」を洗い出します。特に重要なのが、DNSの管理者（どのサービスでレコード編集しているか）と、現在のサーバー情報（PHP/DB/ディレクトリ構造）です。ここが曖昧だと、移行後に「DNSを触れない」「DBに繋がらない」「PHPのバージョン違いでエラー」などが起きがちです。

下記は、移行前にメモしておくと強い項目です。分からないものがあってもOKですが、分からない項目を"分からない"と把握することが重要です（必要ならサーバー会社に確認できます）。

フルバックアップ（DB＋wp-content＋設定）

移行前に必ずやっておきたいのが、「WordPressを丸ごと復元できるバックアップ」です。バックアップは「念のため」ではなく、移行作業の一部。もし新サーバーでうまく動かなくても、バックアップがあれば落ち着いてやり直せます。

最低限必要なのは、データベースと、WordPressファイル一式（特に wp-content）、そして設定情報です。バックアップを取ったら、ファイルサイズや作成日時を確認し、可能なら別の場所（PC＋クラウド等）にも保管しておきましょう。

TTL短縮・メンテナンス案内・作業環境の整備

DNS切替の直前直後は、アクセス先が旧サーバーと新サーバーで一時的に混在します。ここで「編集した内容が消えた」「注文や問い合わせが二重になった」などが起きないように、事前に打てる手を打っておくのが安全です。

特に効果が大きいのがTTLの短縮です。TTLを短くしておくと、DNS切替後の反映（浸透）にかかる時間を短縮でき、混在時間を減らせます。合わせて、作業時間帯の確保、管理画面のログイン情報整理、必要ならメンテナンス告知も準備しておきましょう。

移行手順（王道）：新サーバーに複製→動作確認→DNS切替

ドメイン（URL）を変えずにWordPressを移行する王道手順は、「新サーバーに複製して先に完成形を作る」→「URLを変えずに動作確認する」→「最後にDNSを切り替える」の順番です。

この流れにすると、DNS切替の前に不具合を潰し切れるため、切替当日にやることが「切り替える」「最終チェックする」に絞れます。結果として、停止時間（ダウンタイム）とトラブルの両方を最小化できます。

新サーバーでWordPressの受け皿を用意（PHP/MySQL/権限）

まずは新サーバー側に「サイトを置ける状態」を作ります。ここで大事なのは、現サーバーの環境にできるだけ寄せることです。特にPHPのバージョンが大きく違うと、移行後にエラー（真っ白・500）になりやすいので注意してください。

また、移行後のトラブルは「データのコピー」よりも、DB接続設定・権限・公開ディレクトリのズレで起きがちです。次のチェックを満たす状態まで整えてから、データ移行に進みましょう。

データ移行（プラグイン／手動：FTP＋SQL）

WordPress移行でコピーすべきものは大きく2つだけです。「WordPressのファイル一式（特にwp-content）」と、「データベース（DB）」。この2つが揃えば、基本的に同じサイトを再現できます。

移行方法は「プラグインで一括」か「手動（FTP＋SQL）」のどちらかです。どちらが正解というより、サイト規模・サーバー制限・作業に慣れているかで選ぶのが安全です。

どちらの方法でも、移行後に最初に確認すべきはDB接続と管理画面ログインです。新サーバー側のwp-config.phpに、新しいDB名・ユーザー・パスワード・ホスト名が正しく入っているかを確認し、表示できない場合はここから見直します。

なお「ドメインそのまま移行」では、基本的にURLを変更する必要はありません。テストのために一時的なURLへ置き換えると、後で戻し漏れ（リンク・画像・シリアライズデータ）が出やすいので、できる限りURLは触らず、次の「hostsで先行確認」で動作チェックするのが安全です。

hostsで先行確認（URLは変えずにテスト）

DNSを切り替える前に、新サーバー上のサイトを確認する代表的な方法がhosts（ホストファイル）です。自分のPCだけ「example.comは新サーバーのIPへ行く」と仮指定できるため、URLを変えずに本番に近い形で表示・ログイン・動作確認ができます。

ここでの注意点は、hostsを設定している間は「自分だけ新サーバーを見ている」状態になることです。フォーム送信や注文など、データが増える操作をテストで行うと、DNS切替後にデータ不整合が起きることがあります。テストは「表示・ログイン・画像・リンク・管理画面操作」中心にし、必要ならテスト用の一時フォームなどで確認しましょう。

SSL（Let's Encrypt）とHTTPS化・リダイレクト

新サーバーで動作確認ができたら、SSL（HTTPS）も本番同様に整えておきます。DNS切替後に慌てやすいのが「証明書がまだでhttpsがエラー」「http/httpsやwwwあり/なしが混在して表示が崩れる」などのパターンです。切替前にHTTPS運用まで完成させておくと安心です。

Let's Encryptを使う場合は、新サーバー側で証明書を発行し、http→https、必要に応じてwwwあり→なし（または逆）のリダイレクト方針も決めて統一します。移行前にHSTSを入れていたり、CDN（例：Cloudflare）を使っている場合は、設定の整合が取れているかも要チェックです。

DNS切替の実務：A/AAAA/CNAMEと反映確認

DNS切替は「難しそう」に見えますが、WordPress移行の文脈でやることはシンプルに"参照先を新サーバーへ変える"だけです。重要なのは、触る行を間違えないことと、切替後に浸透（反映）まで混在が起きる前提でチェックすることです。

ここでは「WordPressをURLそのままで移すために必要な最低限のDNS切替」だけに絞って解説します。DNSの仕組みや、ネームサーバー変更・ドメイン移管との違いなどは、別記事「サーバー移転のドメイン設定」で詳しく扱う想定で、ここでは深掘りしません。

DNSレコードの見方と変更箇所

まずはDNS管理画面で、「どのホスト名（example.com / www / サブドメイン）が、どこを向いているか」を確認します。WordPress移行で変更対象になりやすいのは、ルートドメイン（example.com）と、www（www.example.com）です。

新サーバー側の案内には、たいてい「設定すべき値」が明記されています。ここで大事なのは、案内された値を"該当する行だけ"にコピペすること。分からない行やメール系の行まで触ると、移行は成功してもメールが止まるなど別事故につながります。

もし「wwwだけ表示されない」「サブドメインだけ旧サーバーのまま」などが起きたら、ほとんどの場合は切替対象のホスト名が漏れているか、wwwの参照先（CNAME等）が旧のままです。まずは"どのホスト名を切り替えたか"を見直してください。

浸透中に起きる"混在アクセス"への対策

DNS切替後はすぐに全員が新サーバーへ行くわけではなく、一定時間は旧サーバーに到達する人／新サーバーに到達する人が混在します。ここで困るのが、フォーム送信や注文など「データが増える」サイトです。混在中に旧側で受けた送信が、新側に反映されず取りこぼしになる可能性があります。

そのため、切替の時間帯はアクセスが少ない時間にし、必要なら一時的に「更新・送信を止める」運用を取ります。移行当日に焦らないためにも、混在を前提に"確認の段取り"を決めておくのが安全です。

もし切替後に「表示が安定しない」「環境によって見える内容が違う」と感じたら、まずはDNS浸透中の混在を疑ってください。そのうえで、次章の「切替後チェック（表示・管理画面・メール・SEO）」を順に確認すれば、移行の不安を潰しやすくなります。

DNSの用語や、ネームサーバー変更・移管との違いまで含めて整理したい方は、下記記事を参考にしてください。

サーバー移転のドメイン設定｜DNS切替・ネームサーバー変更・移管の違いと手順

切替後チェック：表示・管理画面・メール・SEO

DNS切替が完了したら、最後は「問題がないことを確認して移行を確定」するフェーズです。ここでのポイントは、トップページが見えるかどうかだけで判断しないこと。移行直後は、キャッシュやHTTPS設定、権限、プラグインの影響で「一部だけ壊れている」ことがよくあります。

またDNS浸透中は旧/新が混在するため、チェックは複数回線（PC/スマホ、別回線、シークレット窓）で行い、必要なら旧サーバーのログも見て「取りこぼしがないか」を確認します。以下の観点で順番に潰していけば、移行後の不安はかなり減ります。

表示崩れ／404／パーマリンク／画像の確認

まずはユーザーが見る画面（フロント）の確認です。移行直後に多いのが、CSS/JSが読み込めず崩れる、一部ページが404、画像だけ表示されないといった症状です。原因はキャッシュ、権限、HTTPS混在、パーマリンク設定の未反映など、複合しやすいので「よく見るページから順に」チェックします。

特に404は「記事が消えた」のではなく、パーマリンク（リライトルール）が効いていないだけのことが多いです。管理画面でパーマリンク設定を開いて保存（変更しなくてもOK）するだけで復旧するケースもあります。

メール（MX/送信SMTP）・フォーム・通知の確認

次に重要なのが「問い合わせが届かない」事故を防ぐチェックです。WordPress移行では通常、DNSのMX（受信）設定は触りませんが、フォームプラグインやSMTP設定、サーバー側のメール送信制限が変わることで、通知メールだけ届かなくなることがあります。

ここは必ず、実際にフォーム送信して確認してください。送信者（ユーザー側の自動返信）と、管理者（運営側の通知）の両方が届くか、迷惑メールフォルダに入っていないかまでチェックするのが安全です。ECや会員サイトなら、注文メール・登録メールなども同様に確認します。

メール移行や、送受信できない原因の切り分け・IMAP/SMTP設定まで詳しく確認したい方は下記記事を参考にしてください。

サーバー移転のメール移行｜送受信できない原因と設定手順（IMAP/SMTP）

Search Console／GA4／広告タグの確認

最後に、SEOと計測まわりの確認です。URLが変わらない移行でも、サーバーが変わることで「タグが読み込まれていない」「noindexが付いた」「canonicalが崩れた」などが起きると、順位や計測に影響します。移行直後は、まず意図しない設定になっていないかの確認が最優先です。

Search Consoleは、カバレッジ（インデックス）やクロールエラーだけでなく、移行後に急に増える「404」「サーバーエラー」などの兆候を早期に見つけるのに役立ちます。GA4や広告タグは、ページ上でタグが発火しているか、リアルタイムでイベントが入っているかを確認しておくと安心です。

失敗しやすいポイントとトラブルシューティング

WordPressのサーバー移行は、手順通りに進めれば高確率で成功しますが、それでもトラブルが起きるときは「よくある原因」に集中します。特に多いのは、環境差（PHP/権限/WAF）、DB接続、HTTPSまわり、そして「旧サーバーの名残り」です。

ここでは、移行直後にありがちな症状を「原因の当たり」から逆引きできるようにまとめます。焦ったときは、まずキャッシュを疑う→エラーログを見る→wp-config.phpと権限を見る、という順番で切り分けると迷いにくいです。

真っ白／500／DB接続エラーの典型原因

移行後にアクセスして「画面が真っ白」「500 Internal Server Error」「Error establishing a database connection（DB接続エラー）」が出る場合、原因はだいたい絞れます。まずはDNSが新サーバーを向いているかを確認したうえで、新サーバー側で切り分けます。

500系はPHPや権限、.htaccessの不整合が多く、DBエラーはwp-config.phpの設定ミスが多いです。特にDBホストは「localhost」ではない環境もあるため、旧サーバーと同じだと思い込まないのが安全です。

まず試す対処の順番は、（1）キャッシュ無効化（2）プラグイン一時停止（3）エラーログ確認です。プラグイン停止は「pluginsフォルダ名を一時的に変える」方法でも切り分けできます。ログが見られる場合は、致命エラーのファイル名や行番号が出るので、最短で原因に当たれます。

画像が表示されない／旧サーバー参照が残る問題

「ページは出るけど画像だけ出ない」「CSSが当たらない」「一部リンクが旧サーバーへ飛ぶ」などは、移行で非常に多い症状です。原因は大きく分けて、（A）パスや権限、（B）URLの混在（http/https、www）、（C）キャッシュ/CDNの3つです。

特に「旧サーバー参照が残る」ケースは、外部URLがコンテンツ内に保存されていたり、テーマ設定・ウィジェット・プラグイン設定に旧情報が残っていることが原因になります。ドメインが変わらない移行でも、http→httpsやwwwあり/なしの統一を変えた場合は要注意です。

まずはブラウザの開発者ツールで「どのURLが失敗しているか」を見て、404なのか403なのか、httpが混ざっているのかを判定すると一気に近づきます。原因が分かれば、権限修正、https統一、キャッシュ削除、DB内URLの修正など、打つ手が明確になります。

移行後に遅くなった（キャッシュ／設定／WAF等）

「移行したら表示が遅くなった」「管理画面が重い」は、移行直後に意外と多い相談です。新サーバーが必ず速いとは限らず、キャッシュ設定が外れていたり、PHPバージョンやOPcache設定、画像最適化、WAFの検知などで体感が落ちることがあります。

まずは「いつ遅いか」を切り分けます。トップだけ遅いのか、全ページ遅いのか、管理画面だけ遅いのかで原因が違います。加えて、DNS浸透中に一部が旧サーバーへ行っていると「速かったり遅かったり」に見えることもあります。

速度の問題は「感覚」だと迷子になりやすいので、ページ速度計測やサーバーのアクセスログを見ながら、重い原因（TTFB、画像、外部JS）を特定して対処するのが近道です。移行直後は設定が初期状態に戻っていることも多いため、旧サーバーで有効だった高速化（キャッシュ、圧縮、画像最適化）を新サーバーでも再現できているかを確認しましょう。

ここまで試しても改善しない場合は、環境差（PHP/権限/WAF/DB）を含めて一括で切り分ける方が早いことがあります。作業が不安なら代行/相談は下記記事をご覧ください。

サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応

旧サーバーの解約タイミングと移行完了の判断

DNSを切り替えてサイトが表示できたとしても、すぐに旧サーバーを解約するのは危険です。DNS浸透中は一定時間、旧サーバーへアクセスするユーザーが残る可能性があり、フォーム送信や注文、メール通知などが絡むサイトでは「取りこぼし」の原因になります。

旧サーバーの解約は、「移行が本当に終わった」と判断できてからが基本です。その判断材料として、アクセスログ（旧サーバーにどれだけ到達しているか）と、重要機能（フォーム・メール・計測・管理画面など）が一定期間安定しているかを確認します。

旧サーバーを残す期間の目安とログの見方

旧サーバーを残す期間はサイトの性質で変わりますが、目安としては最低でも数日〜1週間は様子を見るのが無難です。特に、問い合わせフォームや予約、会員登録、ECなど「ユーザーの書き込み」が発生するサイトは、混在期間中の取りこぼしが起きやすいので慎重に判断します。

判断の具体策として有効なのが、旧サーバーのアクセスログです。DNS切替後も旧サーバーにアクセスが来ているなら、まだ完全に切り替わっていないユーザーがいる可能性があります。旧サーバー側のログが減っていき、一定期間ほぼ来なくなったら「浸透が落ち着いた」と判断しやすくなります。

もし旧サーバーにアクセスが残り続ける場合、DNSレコードの見直し（wwwあり/なし、AAAAの残り、サブドメインの未切替）や、CDN/DNSサービス側の設定（プロキシ、キャッシュ）を再確認します。「どこか一箇所だけ旧のまま」が原因であることが多いです。

バックアップ保管と再発防止（自動バックアップ）

移行が安定してきたら、最後にやるべきは「解約しても困らない状態」に仕上げることです。旧サーバー上のデータが唯一のバックアップになっていると、解約後に不具合が出た場合に戻せません。移行完了の判断とセットで、バックアップの保管と自動バックアップの仕組み化をしておくのがおすすめです。

具体的には、手元（PC）だけでなくクラウドなど別の場所にバックアップを置く、バックアップが「本当に復元できるか」を想定する、新サーバー側で自動バックアップが動くようにする、という3点が重要です。これができていれば、旧サーバー解約の心理的ハードルが一気に下がります。

最後に、旧サーバーの解約前に「更新・送信・計測」が一通り安定していることを確認できたら、移行は完了です。旧サーバーは解約してもよい状態になりますが、可能なら契約更新の締め日（課金タイミング）も踏まえて、余裕を持って解約すると安心です。

まとめ：最短で安全に移行するためのチェックリスト

WordPressのサーバー移行をドメインそのまま（URLを変えずに）行う場合、成功の鍵は「手順の順番」です。王道は新サーバーに複製して先に動作確認し、最後にDNS（A/AAAA/CNAME）を切り替えること。これだけで停止時間とトラブルを大きく減らせます。

最後に、作業当日に迷わないためのチェックリストをまとめます。全てを完璧にやる必要はありませんが、最低限の項目（DNS／バックアップ／動作確認／切替後チェック）だけでも押さえると安全です。

サーバー移転の全体の流れは下記記事で解説しています。

サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト

作業が不安なら代行/相談を紹介した下記記事をご覧ください。

サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応