ホームページのサーバー移管手順｜同じドメインで止めずに切り替えるチェックリスト

結論：同じドメインで移管するなら、先に4つの論点を切り分けます

ホームページのサーバー移管は、同じドメインのままでも進められることが多いです。ただし実務では、サーバーだけ変える作業、URL も変える作業、ドメイン管理会社も変える作業、メール経路を保つ作業 が混ざると止まりやすくなります。

切り替え当日に慌てないために、最初に次の4点だけ確定してください。

• URL は変わらないか
• ドメイン管理会社の変更はあるか
• 問い合わせメールも同じドメインで動いているか
• 旧サーバーを何日残せるか

この4点が曖昧なまま日程だけ決めると、公開停止よりも先に メール不達 認証待ち 戻し先なし で詰まります。

まず切り分ける3つの判断基準

1. URLが変わるなら、サーバー移管だけの話ではありません

Google 検索セントラルは、URL を変更する移転では URL マッピング を準備し、元 URL から新 URL への対応を決めるよう案内しています。一方で、URL を変更しない場合は、ホスティング変更などのインフラ変更として扱うよう分けています。

つまり、example.com/service が example.com/services/ に変わるなら、必要なのは DNS 切り替えだけではありません。URL 対応表、301 リダイレクト、内部リンク修正、Search Console 監視が別タスクで発生します。逆に URL が変わらないなら、リダイレクト設計よりも DNS とメール確認の方が優先です。

出典画像: Google 検索セントラル「サイトを移転する方法」の参照箇所（2026年8月7日取得）

https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes?hl=ja

2. ドメイン管理会社も変えるなら、AuthCode の確認を先に終えます

サーバー移管とドメイン管理会社変更は別作業です。JPRS は、指定事業者変更で 認証コード（AuthCode） が必要になり、変更元と変更先をまたぐ承認手順があることを示しています。

旧制作会社や保守会社がドメイン管理を持っている場合は、「サーバーを切り替えてから管理会社変更を考える」進め方だと止まりやすいです。誰が AuthCode を取得できるか、承認依頼がどこへ届くか、レジストラ画面へ入れるかを先に確認してください。

出典画像: JPRS「ドメイン名の管理指定事業者の変更」の参照箇所（2026年8月7日取得）

https://jprs.jp/about/dom-rule/agent-change/

3. メールを同じドメインで使うなら、MX と TXT まで差分確認します

NTTドコモビジネスのサポート情報では、既存 DNS のゾーン情報を正しく転記しないまま参照先ネームサーバーを変更すると、メールサービスが使えなくなる可能性があると案内しています。さらに、アカウント作成前に MX レコードを切り替えるとメールロストが発生すると明記されています。

問い合わせフォーム通知や代表メールを同じドメインで運用している会社は、A CNAME だけでなく、MX TXT SPF DKIM DMARC を含めた差分表を先に作る方が安全です。サーバー移管のつもりでも、実際の障害はメール側で起こりやすいからです。

出典画像: NTTドコモビジネス「現在利用しているDNSからDNSオプションサービスへ切替時の順番や注意点が知りたいです。」の参照箇所（2026年8月7日取得）

https://support.ntt.com/office365/faq/detail/pid2300001nsz/

同じドメインで止めずに移管する6手順

1. 現行環境の棚卸しを 1 枚にまとめる

ドメイン管理会社、サーバー契約者、CMS ログイン、SSL 更新先、フォーム通知先、解析権限を並べます。DNS は A CNAME MX TXT を控え、どれがサイト表示用で、どれがメールや外部サービス用かを分けます。

最低限そろえたい項目は次のとおりです。

• ドメイン管理会社と契約名義
• 現在のネームサーバー
• 本番サーバーと旧制作会社の管理権限
• フォーム通知先メールアドレス
• A CNAME MX TXT の現行値
• 戻し作業に必要な連絡先とログイン情報

2. 新サーバーで複製と動作確認を先に終わらせる

本番ドメインを切り替える前に、新サーバー側で主要ページ、画像、フォーム、管理画面、プラグイン互換を確認します。未確認のまま DNS を切り替えると、障害が出るのは公開後です。

確認時は「見えるページ」だけでなく、「通知が届くか」「アップロードが通るか」「管理画面へ入れるか」まで見ます。企業サイトでは、表示崩れよりフォーム通知漏れの方が影響が大きいことが多いです。

移管前に、切り替え表と戻し手順だけ先に作ってください

New Check では、移管前の確認漏れを洗い出したい方向けに、無料診断とアクセス改善事例を公開しています。社内確認用の観点を先にそろえたい場合は https://newcheck.jp/setagaya-shindan と https://newcheck.jp/analytics が参考になります。

3. DNS とメールの差分表を作る

新旧の DNS レコードを見比べる表を作り、切り替え当日に触る項目を明示します。ここで A だけ見ていると、メール経路や認証用の TXT が抜けます。

特に確認したいのは次の点です。

• サイト表示用の A CNAME
• メール用の MX
• 送信認証や所有権確認で使う TXT
• 外部配信や計測タグで必要な CNAME
• 既存値へ戻すときの手順

4. 切り替えは、戻せる担当者がいる時間帯に行う

問い合わせメールを同じドメインで使っている会社は、DNS 切り替え直後にフォーム送信と通知メール受信を必ず確認します。作業時間は深夜より、戻し判断できる担当者が待機できる時間帯の方が安全です。

5. 切り替え後もしばらく旧サーバーを残す

東京大学情報基盤センターは、DNS サーバ交代時には 新しい DNS サーバの情報が全域で有効になるまでタイムラグがあり、しばらくは旧サーバーへ問い合わせが来る可能性があるため、数日間は旧サーバーを稼働させる方が安全だと案内しています。

そのため、切り替え直後に旧環境を解約せず、少なくとも数日は 旧サーバーを止めない 前提で日程を組んでください。戻し先がない状態で切り替えると、障害時の選択肢が一気に減ります。

出典画像: 東京大学情報基盤センター「DNSサーバ交代の際の注意点」の参照箇所（2026年8月7日取得）

https://www.itc.u-tokyo.ac.jp/education/services/dns-hosting/faq/page-2304/

6. 切り替え後 3 日間の監視項目を決める

確認対象は次のとおりです。

• 主要ページが HTTP 200 で返るか
• フォーム送信後の通知メールが届くか
• 画像、PDF、外部スクリプトが欠けていないか
• URL を変えたページだけ 301 が機能しているか
• Search Console と解析で異常が出ていないか
• 旧サーバー停止前に必要データを回収できているか

URL を変えないサーバー移管なら、監視の中心は サイト表示 と メール到達 です。URL を変えた場合だけ、加えて 301 とインデックス推移を追います。

切り替え前のチェックリスト

• URL を変える作業か、サーバーだけ変える作業かを分けた
• ドメイン管理会社の名義、AuthCode の取得先、承認経路を確認した
• 現在の DNS レコードとメール利用有無を控えた
• 新サーバーで主要ページとフォームを検証した
• 旧サーバーを数日残す前提で停止日を決めた
• 戻し手順と担当者を決めた

よくある質問

ホームページのサーバー移管でドメインはそのまま使えますか

多くのケースではそのまま使えます。ただし、管理会社変更が入る場合は DNS 切り替えとは別に AuthCode と承認手続きが必要です。

DNS切り替え中にメールが止まることはありますか

あります。ホームページとメールが同じドメインを使っている場合は、MX や TXT の差分確認をせずに切り替えると受信経路に影響が出ます。

301リダイレクトは必ず必要ですか

URL が変わらないなら必須ではありません。旧 URL と新 URL が変わる場合だけ、対応表を作って 301 を設定します。

旧制作会社はいつ解約すればいいですか

DNS 切り替え、フォーム確認、メール受信確認、必要データ回収が終わる前は解約しない方が安全です。少なくとも旧環境へ問い合わせが来なくなるまでは余裕を残してください。

先に決めるべきなのは、切り替え日より戻せる状態です

同じドメインのサーバー移管は、URL変更の有無 AuthCodeの要否 MX/TXTの差分 旧環境を残す期間 を先に分けるだけで事故率が下がります。逆に、この4点が曖昧なまま日程だけ決めると、公開後の確認より前に止まりやすくなります。

移管前の確認項目を第三者目線で整理したい場合は、New Check で現状診断から進行表づくりまで支援できます。切り替え前の段階で詰まりそうなら、公開日を決め切る前に相談する方が安全です。