ネームサーバーだけCloudflareに移し、サイトを止めずに切り替えた2段階の手順

この記事の結論：ドメインの登録はXserverに置いたまま、ネームサーバーだけをCloudflareへ移しました。サイトを止めないために、作業を2つに分けています。1段階目は、旧DNSと同じレコードをCloudflareに写し、すべてプロキシを切った「DNSのみ」にしてからネームサーバーを変えること。この時点では、どちらのDNSに問い合わせても旧サーバーの住所が返るので、見た目は何も変わりません。2段階目は、Cloudflareが有効になったのを確かめてから、Webの2つのレコードだけを新サイト（Cloudflare の Pages）に向け直すことです。どちらの段階も、戻す操作が1か所で済むようにしてあります。

このブログを WordPress（Xserver）から Cloudflare の Pages に載せ替えたときの、DNSまわりの作業だけを切り出した記録です。値や確認の結果は、2026年10月2日に手元で dig と curl を打って確かめたものです。

なぜ1回で切り替えなかったのか

ネームサーバーの変更と、Webの向き先の変更を同時に行うと、問題が出たときに原因を切り分けられません。しかも、ネームサーバーの変更は自分で時間を決められない作業です。

遅くて自分で制御できない方を先に、しかも「何も変わらない形」で済ませる。速くて自分で戻せる方を後に回す。これが2段階に分けた理由です。

段階0：今のDNSを、1行も漏らさず書き出す

最初にやったのは、Xserver側のDNSレコードを表に書き写すことでした。これが、そのまま切り戻しの台帳になります。

あわせて、次の2つを先に確かめました。

• DNSSECが有効になっていないか。Cloudflareの手順書は、DNSSECが有効なままネームサーバーを替えるとドメインに届かなくなる場合があるので、先に登録業者側で切るよう書いています。このドメインは、dig +short DS yamayamabloglink.com が何も返さず、DNSSECは使っていませんでした
• ドメインの無料特典が、サーバー契約にひも付いていないか。Xserverでは、サーバー契約の特典でドメインの更新料が無料になっていることがあります。新サイトに移ってもサーバーをすぐ解約しなかったのは、切り戻し用に残すためと、この特典が外れるのを避けるためです

段階1：DNSのみで写して、ネームサーバーを変える

1. Cloudflareでドメインを追加し（Freeプラン）、自動で読み込まれたレコードを段階0の表と1行ずつ見比べる。足りないものは手で足す
2. A・CNAMEのレコードを、すべて プロキシなし（DNSのみ） にする
3. Cloudflareが割り当てた2つのネームサーバー名を控える
4. Xserverの管理画面で、ネームサーバーを「その他」にして、控えた2つを入れて保存する
5. Cloudflareから、ドメインが有効になった知らせが来るのを待つ

2が肝心です。Cloudflareの説明では、DNSのみのレコードには登録したとおりの元のIPが返り、プロキシありのレコードにはCloudflareのIPが返ります。DNSのみにしておけば、新しいネームサーバーに聞いても古いネームサーバーに聞いても、返る住所は同じ旧サーバーです。反映の途中で読者がどちらに当たっても、同じWordPressが表示されます。

Cloudflareの手順書には、自動の読み込みはすべてのレコードを見つけられるとは限らないこと、必要なレコードがないまま有効にすると名前が引けなくなることも書かれています。表を先に作ったのは、この見比べのためでもありました。

段階1が終わったことを、dig で確かめる

管理画面の表示だけでなく、外から実際に引いて確かめました。

# 普段使っているリゾルバー経由
dig +short NS yamayamabloglink.com
# .com の上位サーバーに直接（キャッシュを通さない）
dig +norec NS yamayamabloglink.com @a.gtld-servers.net

2026年10月2日の結果は、どちらも jaziel.ns.cloudflare.com と melina.ns.cloudflare.com でした。上位サーバーの答えには、有効期間（TTL）として 172800（秒、つまり2日）が付いています。古いネームサーバーの情報を覚えた環境が、最大でこれくらい残りうるということです。段階1を「何も変わらない形」にしたのは、この2日を気にしなくて済むようにするためでした。

段階2：Webの2つのレコードだけを、新サイトへ向ける

ネームサーバーがCloudflareに移ったのを確かめてから、Webの向き先だけを変えました。

apex（www なし）を Pages につなぐには、そのドメインのネームサーバーがCloudflareにあることが条件です。段階1を先に済ませたのは、この条件を満たすためでもあります。また、Pages の説明には、先に Pages のプロジェクト側でカスタムドメインとして登録せず、CNAMEだけを手で作ると名前が解決されない、とあります。順番は「Pagesにドメインを登録 → レコードを向け直す」です。

正式なアドレスは www 付きにそろえ、www なしと *.pages.dev に来たアクセスは、Pages の Functions（リクエストごとに動く小さなプログラム）で、同じパスの www へ 301 で送っています。

段階2のあとに、外から確かめたこと

dig +short yamayamabloglink.com
curl -sI https://www.yamayamabloglink.com/
curl -sI https://yamayamabloglink.com/about/
curl -sI http://www.yamayamabloglink.com/

戻すときの手順

段階ごとに、戻す操作を1つに絞ってあります。

どちらも、旧サーバーを残しているから成り立つ戻し方です。サーバー契約の解約は、新サイトで問題がないと確かめられてから判断します（それまでは、いつでも元に戻せる）。

株式会社bundlyzeでは、会社サイトのDNSを触ったときも、変更前の値を切り戻し用に書き残してから作業しました。DNSの移し替えやサーバー構成の見直しは、bundlyzeのクラウド・インフラ構築でもご相談を受けています。

出典

下の3つは、2026-10-02 に記述を確認しました。

• Cloudflare：Set up a primary zone（Full setup）（DNSSECを先に切ること、反映に最大24時間、自動読み込みの取りこぼし）
• Cloudflare：Proxy status（DNSのみとプロキシありで返るIPの違い）
• Cloudflare Docs：独自ドメインを Pages につなぐ（Custom domains）（apex はネームサーバーがCloudflareにあること、先にPagesで登録すること）