この記事の結論
ホームページを新しいサーバーやクラウドへ移すときに最初に決めるのは、URLが変わる移行か、変わらない移行かです。
URLが同じままなら、Googleの案内ではアドレス変更の手続きは要らず、DNSの切り替えと切り替え後の見張りが中心になります。
URLが変わるなら、古いURLから新しいURLへの恒久的な転送（301など）を用意し、長く残します。
どちらの場合も、検索より先に止まりやすいのはメールと問い合わせフォームです。
サイトの向き先を変える作業の中で、メールの記録（MXやSPF）を消したり、意図しない書き換えをしたりしないよう、移す前に今の記録をすべて控え、触らない記録を決めておきます。
最初に、URLが変わる移行かどうかを分ける
サーバー移行やクラウド移行と一口に言っても、Googleは2つの場合を分けて案内しています。
1つは、URLを変えずに、ホスティング（サイトを置いている場所）だけを変える移行です。
Googleの案内では、手順は新しい環境の準備、移転の開始、アクセスの見張り、古い環境の停止の順で、Search Consoleでは、所有権の確認が移した後も通り続けるようにしておくことと、インデックスの状況を見ることが挙げられています。
移した直後にGooglebotのクロールの頻度が一時的に下がるのは通常の動きで、その後数日かけて戻っていく、とも書かれています（Google 検索セントラル：ウェブ ホスティングの変更と SEO、2026年10月5日確認）。
もう1つは、ドメインやページのURLが変わる移行です。
こちらは、古いURLと新しいURLの対応表を作り、できれば301や308のような恒久的な転送をサーバー側で設定し、その転送を一般的には1年以上、できるだけ長く残すよう案内されています。
移転の間は順位が一時的に変わることを想定しておくように、とも書かれています（Google 検索セントラル：サイトを移転する方法、2026年10月5日確認）。
Search Consoleの「アドレス変更」は、ドメインやサブドメインを変える場合に使う機能です。
httpからhttpsへの変更、wwwの有無だけの変更、URLを変えずにホスティングやCDNを変える場合は対象外と書かれています。
使った場合でも、転送は少なくとも180日は残すよう求められています（Search Console ヘルプ：アドレス変更ツール、2026年10月5日確認）。
サーバーを替えるついでにURLの付け方も整理したくなることがありますが、私は、2つは分けて行うほうが安全だと考えています。
何かがおかしくなったとき、どちらの変更が原因かを切り分けられなくなるからです。
移す前・当日・移した後に確かめること
下の表は、私たちが自社のドメインを移したときの手順と、Googleなどの公式の案内をもとにまとめたものです。
どの順で何を見るかは、私たちの考えとして書いています。
| いつ | 確かめること | 止まると困るもの |
|---|---|---|
| 移す前 | DNSの記録を、切り替える前にすべて書き出す（元の値はどこにも残らない） | すべて（切り戻しに要る） |
| 移す前 | 触らない記録を決める（MX、SPF・DKIMなど送信元の認証、所有確認のTXT、別の場所を向いているサブドメイン） | メール、Search Console |
| 移す前 | SPFに、サイトの向き先と連動する指定がないかを見る | メールの送信元の認証 |
| 移す前 | 切り替える記録のTTL（反映の待ち時間）を短くし、全部のDNSサーバーに行き渡ったかを確かめる | 切り戻しの速さ |
| 移す前 | 新しい環境の証明書を、切り替えより先に用意できるかを確かめる | https で開けるか |
| 移す前 | テスト用に置いた robots.txt の制限やパスワードを、本番の切り替え時に外す段取りを決める | 検索 |
| 当日 | 新しい環境に直接つないで、表示と証明書と転送を先に見る | サイト全体 |
| 当日 | 向き先を切り替え、全部のDNSサーバーと公開のDNSで新しい値が返るかを見る | サイト全体 |
| 当日 | 触らないと決めた記録が、変わっていないかを見る | メール |
| 移した後 | 問い合わせフォームから実際に送り、届くかを見る | 問い合わせ |
| 移した後 | Search Consoleの所有権の確認が通ったままか、インデックスの状況に変化がないかを見る | 検索 |
| 移した後 | 古いサーバーへのアクセスがなくなるまで、古い環境を止めない | 切り戻し |
| 移した後 | TTLを元に戻し、証明書の期限を見張る仕組みを置く | https で開けるか |
移す前：DNSの記録を全部控え、メールの記録を分けて考える
ドメインのDNSには、サイトの向き先だけでなく、メールの受け取り先（MX）、送信元の認証（SPF・DKIM）、Googleなどのサービスの所有確認の記録が同じ場所に並んでいます。
サーバーの移行で書き換えるのは、たいていサイトの向き先の記録だけです。
ところが、管理画面で一覧を見ながら作業していると、どれがサイトの記録でどれがメールの記録かが分かりにくく、要らなそうに見えたものを消してしまうことが起きえます。
私たちは2026年9月、wwwなしのアドレス（bundlyze.co.jp）を、それまでのレンタルサーバーから、wwwありのアドレスと同じFirebase Hostingへ移しました。
きっかけは、wwwなしのアドレスの証明書が、仕組みの上で自動で更新できない形になっていたことです（経緯と証明書の話はSSL証明書の期限切れを防ぐに書きました）。
切り替えの前日、2026年9月14日の18時50分に、権威DNS（ドメインの記録を持っている大元のサーバー）に直接問い合わせて、記録を1枚の表に書き出しました。
その表を、変える記録と、変えない記録の2つに分けています。
変えない側に入れたのは、MX、DKIM、所有確認のTXT、wwwの向き先、ワイルドカードの記録です。
切り替えた後も、この「変えない記録」が同じ値のままかを確かめるのに、その表を使いました。
SPFが、サイトの向き先と連動していないか
書き出した中で、手を入れる必要があったのはSPFでした。
SPFは、このドメインのメールを送ってよいサーバーを宣言する記録です。
私たちのSPFには、「wwwなしのアドレスが向いている先のサーバーを、送信元として許可する」という指定が入っていました。
これを残したまま向き先を変えると、メールの送信と関係のない新しいホスティングのサーバーが、自動的に送信元として許可されてしまいます。
メールが止まるわけではありませんが、自社で管理していないサーバーを許可する状態になります。
そこで、この指定を、向き先を変えるより先に消しました。
同じサーバーは別の指定でも許可されていたので、消しても送信は変わらないことを確かめたうえでの作業です。
順番が逆だと、短い時間でも、新しい側のサーバーが許可された状態になります。
調べる途中で、SPFにほかにも見直したい点が見つかりましたが、それは移行とは切り離して、別に考えることにしました。
メールの送信元の認証は、書き換えを誤るとメールが届かなくなる記録で、サイトの切り替えと同じ日に動かすと、どちらで何が起きたのかが分からなくなるからです。
SPF・DKIM・DMARCの見直し方は、問い合わせフォームのメールが届かないときの直し方にまとめています。
反映の待ち時間（TTL）は、切り替えの前に下げておく
TTLは、DNSの記録をほかのサーバーが手元に覚えておいてよい時間です。
JPRSの用語辞典では、秒単位で示し、たとえば3600なら、受け取った側は最大で1時間覚えておいてよい、と説明されています（JPRS用語辞典：TTL、2026年10月5日確認）。
3600のまま向き先を変えると、古い向き先を覚えている人には最大で1時間、古いサーバーが見え続けます。
切り替えに失敗して元に戻すときも、同じだけ待つことになります。
Googleのホスティング変更の案内では、移転の少なくとも1週間前にTTLを数時間などに下げることを検討するよう書かれています（先ほどの「ウェブ ホスティングの変更と SEO」）。
下げた値そのものも、古い値が消えるまでは効かないので、切り替えの直前に下げても間に合いません。
私たちは、切り替えの前日に、wwwなしのアドレスの記録のTTLを3600から300（5分）に下げました。
SPFの書き換えや確認用の記録の追加と同じタイミングです。
保存した後、ドメインの記録を持っている3台のDNSサーバーに1台ずつ問い合わせると、2台と、GoogleやCloudflareの公開のDNSはすぐ新しい値を返しましたが、1台だけ古い値のままでした。
その1台に行き渡ったのは、約10分後です。
管理画面で保存しても、全部のDNSサーバーにそろうまでには差があります。
「保存した」ではなく、「全部のサーバーが新しい値を返した」を確かめてから、次の手順に進むようにしました。
証明書は、向き先を変える前に用意する
新しい環境が自動で証明書を発行してくれる場合でも、DNSが新しい環境を向くまで発行が始まらない手順になっていることがあります。
Firebase Hostingは、DNSの設定を終えてから証明書が使えるようになるまで、最大で24時間かかる場合があるとしています。
そのうえで、ほかのサービスから止めずに移すための手順として、TXTの記録での所有の確認と、ACMEチャレンジ（証明書を発行するための確認）を先に済ませ、最後に向き先の記録を変える流れを案内しています。
向き先を変えるときに、ほかの事業者を向いた古いA・AAAA・CNAMEの記録が残っていると証明書を発行できない、とも書いています（Firebase：カスタム ドメインを接続する、2026年10月5日確認）。
私たちもこの流れで進め、向き先がまだ古いサーバーのまま、2026年9月14日の19時過ぎに、新しい証明書が発行されていることを確かめました。
翌朝は、切り替える前に、DNSを変えずに新しい環境のIPアドレスへ直接つなぐ方法で、証明書が正しく通ることと、wwwありのアドレスへ転送されることを先に見ています。
証明書が出るまで待つ時間を、切り替えの後ではなく前に置くと、訪れた人が警告を見る時間をなくせます。
当日：切り替えたら、サイトとメールを両方見る
向き先を変えたのは、2026年9月15日の朝9時前です。
9時4分には、3台のDNSサーバーと、確かめた4つの公開のDNSのすべてが新しい値を返しました。
そのうえで、次のことを1つずつ見ています。
wwwなしのアドレスが、新しい証明書で開けるか。
httpで来た人も、httpsのwwwありのアドレスへ転送されるか。
転送のとき、ページのパスや、URLの後ろに付くパラメータが落ちずに引き継がれるか。
wwwありのアドレスは、これまでどおり表示されるか。
そして、MX、DKIM、所有確認のTXTなど、前日に「変えない」と決めた記録が同じ値のままか。
1つ戸惑ったのは、Firebaseの管理画面の表示です。
DNSはもう新しい値を返しているのに、画面には「設定が必要です」と出たままでした。
画面に出ていた確認の結果は、切り替えの54分前に取られたもので、古い結果が残っていただけでした。
9時34分に改めて確かめると、「接続されています」に変わっています。
管理画面の表示だけを見て、慌てて設定を触り直さないほうがいい場面でした。
移した後：フォームとSearch Consoleを確かめる
サイトの表示が問題なくても、問い合わせのフォームが止まっていることがあります。
フォームの送信の仕組みが古いサーバーの上で動いていた場合、新しい環境では動かないことがあるからです。
移した後は、フォームから実際に送り、問い合わせた人への控えと、社内への通知の両方が届くかを見ます。
定期的に送って確かめる方法は、予約・問い合わせフォームが止まっていないか、見張る方法に書きました。
Search Consoleは、所有権の確認の方法によっては、移した後に通らなくなります。
確認用のHTMLファイルを古いサーバーに置いていた場合は、新しい環境にも置き直す必要があります。
DNSのTXTで確認している場合も、その記録をサイトの記録と取り違えて消すと、確認が外れます。
私たちのドメインにもGoogleの所有確認のTXTがあり、これは「変えない記録」に入れておきました。
テスト用の環境で、検索に出ないように robots.txt やパスワードで制限をかけていたなら、本番に切り替えるときに外します。
Googleの案内でも、移転を始めるときに新しいサイトのブロックをすべて外すよう書かれています。
外し忘れると、新しいサーバーでは検索から見えなくなります。
私たちの場合は、wwwなしのアドレスをwwwありへ転送する形にしただけで、検索に出しているページのURLはすべてwwwありのまま変わっていません。
canonicalもサイトマップもwwwありで書いていたので、アドレス変更の手続きはしていません。
古いサーバーは、すぐには止めない
Googleの案内では、古い環境を止めるのは、元の事業者へのアクセスがなくなってからです。
TTLが残っている間や、古い値を長く覚えているDNSがある間は、古いサーバーに来る人がいるからです。
私の考えでは、もう1つ理由があります。
切り替えに問題が見つかったとき、古いサーバーが動いていれば、DNSの向き先を戻すだけで元に戻せます。
私たちが前日に書き出した表にも、切り戻しの手順として、向き先と SPF を元の値に戻すことを書いておきました。
私たちは、切り替えの後の確認がすべて済んでから、古いサーバーの証明書の設定を外し、TTLを元の3600に戻しました。
2026年9月15日の11時ごろです。
ところが、古いサーバー側の設定を外したはずなのに、そのサーバーに直接つなぐと、2時間たっても古い証明書が返ってきていました。
訪れる人はすでに新しい環境に向いているので、影響はありません。
ただ、古い側の片付けは、管理画面で操作してもすぐに反映されるとは限らず、反映されたかどうかは自分でつないで確かめないと分からない、ということは覚えておいていいと思います。
制作会社のサーバーから移すなら、先に名義を確かめる
ここまでは、DNSを自分たちで書き換えられることを前提に書きました。
制作会社が用意したサーバーやドメインを使っている場合は、移す前に、ドメインの管理画面に誰が入れるのか、契約の名義は誰かを確かめるところから始まります。
名義が制作会社のままだと、DNSの記録を書き出すことも、TTLを下げることもできません。
確かめ方と移し方はドメイン移管とはに、サイトだけでなく業務システムも一緒に引き継ぐ場合はシステムを作った会社と連絡が取れないときに書いています。
切り替えの当日の作業は、朝から昼前までで終わりました（古い側の片付けの確認だけは、昼過ぎまで続けました）。
時間がかかったのは、どの記録が何のためにあるのかを1つずつ確かめて、変える記録と変えない記録を分けた、前日までの準備のほうです。
サーバーの引っ越しで止まるものの多くは、新しいサーバーの側ではなく、そのときに触った、または消したDNSの記録の側にあると私は考えています。
よくある質問
サーバーを移すと、検索の順位は下がりますか？
URLを変えずにサーバーだけ移す場合も、Search Consoleでアドレス変更をしますか？
サーバーを移すと、メールも止まりますか？
TTLはいつ下げればいいですか？
古いサーバーの契約は、いつ解約すればいいですか？
bundlyzeは、大阪市北区のグラングリーン大阪を拠点に、大阪・兵庫を中心とした関西の会社からのご相談を受けていて、打ち合わせはWeb会議でも対面でもできます。
全国からオンラインでもご相談いただけます。
この記事を書いた津嘉山は、業務システム開発とAWSを専門とするエンジニアで、この記事で書いた自社ドメインの切り替えでも、DNSの書き換えを自分で行いました。
移す予定がまだなくても、自社のドメインのDNSにどんな記録が並んでいるかを、一度書き出しておくと、いざというときの切り戻しの控えになります。
ご相談
サーバーやクラウドの運用について、いまの状況をお聞かせください。
「何から手をつければいいか分からない」という段階からで構いません。返信は担当者が直接お送りします。
