すでに運用中のCloudflare Pagesのサイトを独自ドメインに移行してみた
この記事はUEC2 Advent Calendar 2025 4日目の記事です。今年も2つ生えてますが、埋まる気配がないので飛び入り参加です。
3日目までの参加者はいません……。
ドメイン購入
このサイトを運用し始めて2年が過ぎているが、特に必要性を感じていなかったため、独自ドメインを取得せずにCloudflare Pagesで無料で提供されるサブドメインazumino.pages.devを使い続けてきた。これまた特に理由はないのだが、「短いドメイン欲しくね?」という気持ちが湧いてきたため、普段より多くの人の目に触れるアドベントカレンダーの記事を公開する前のタイミングで独自ドメインを取得し、移行を行った。
英数字IDとして主に使用している「DG-7D」に合わせることと、できるだけ短くすることを考慮し、dg7.devとした。普通に既存のCloudflareのアカウントで購入した。カードはKyashが使えた。住所は日本語が入力できなかったため、「-shi」とかつけてローマ字で入力した。市とcityは異なる概念だとか言われたり言われなかったりするが、結局郵便が届きさえすればいいのであまり厳密なものではない。
支払いのタイミングについて、公式FAQには「はじめて支払プランを選択された日の日付が、毎月の請求日になります」とあったが、中途半端な日付で請求されても気持ち悪いので、月始めに購入した。12月1日の午前8時に購入したところ、「2026年11月1日 に更新」と表示され、てっきりUTCでは11月だったために11月始まりになってしまった(30日分くらい無駄になった)のかと思ったが、この「更新」はドメインの有効期限の30日前(31日と1日の人がいたので恐らくそう)となるだけで、有効期限はきっかり1年の2026年12月1日だった。
Cloudflare Pagesの設定
dg7.devからCloudflare Pagesでホストしているサイトにアクセスできるようにするためには、公式ドキュメントに従って設定すればよい。CNAMEが自動で設定されるが、これだけでは従来のazumino.pages.devも同時に存在する状態になってしまう。同ドキュメントでは*.pages.devへのアクセスを要認証にするかリダイレクトを設定するかが選択肢として挙げられているが、今回は新規サイトではなく既存サイトの移行であるため、後者を選択した。
リダイレクトについては検索すると「ルール」のほうを使う記事も出てくるが、公式ドキュメントに従い一括リダイレクト(Bulk Redirects)を使用した。ドメインごとのダッシュボードではなくアカウント全体のダッシュボードのほうにある。詳細な手順は画面に従うだけなので割愛する。ステータスは恒久な移動を示す301、クエリ文字列は保持、サブドメインは含めず(dev環境は残す)、サブパスは一致させ、パスサフィックスは何のことだかよく分からないがとりあえず保持する。
検索エンジンの設定
サイトの追加
*.pages.devは自分の所有するドメインではないため、サイトに特定のファイルを配置するという方法で認証をしていたが、独自ドメインであればドメイン単位での認証ができるようになる。
Google Search Consoleでは、Cloudflareと謎の連携をすることができ、ボタンをぽちぽちしているだけで勝手にDNSレコードが追加され、認証が完了した。Bing Webmaster Toolsでは従来のファイルを配置する方法で認証した。このファイルはアカウントごとに発行されるもので、別のサイトでも使い回すことができるため、内容を維持した移行である今回は追加のアップロードは不要だった。DNSレコードで認証したほうがなんかつよそうだが、一旦ファイルで認証すると変更できなさそうなので放置しておく。多分ファイルを破壊すれば再認証を求められるが、古いほうの認証も外れてしまうのでやるとしても移行が済んでからである。
Googleのほうは1日待つと情報が出るよんみたいなことが書かれていたが、実際にはn日経たないと出てこなかった。ただ、1日くらい経った時点でsite:dg7.devでいくつかページが出るようにはなっていた。2日以上経ったところでインプレッションがあったよんみたいなメールが来た。Bingは最大48時間かかると表示され、実際2日後にはトップページのその表示は消えていたものの、「検索パフォーマンス」画面では変わらず48時間待てのままだった。また、site:dg7.devでは表示される気配がない。そもそも前々回の記事を出したあたりでBingから嫌われていて旧ドメインのほうでも出なくなっていたため、ドメイン変更とは関係ないかもしれない。Googleでは出ているし、放置すれば直るという噂なので放っておく。
Bingのほうはサイトマップの送信を推奨してきたため、それぞれでサイトマップを送信しておいた。Google Search Consoleはバグり散らかしていて*.pages.devのころはs.xmlみたいなふざけた名前にしないとサイトマップを読み込んでくれなかったが、独自ドメインにしたら普通に読み込んでくれるようになった。
サイトの移行
Google Search Consoleでは、移行元のサイトから別のサイトに移行するためのアドレス変更ツールなる機能が用意されているため、これを利用した。移行先のサイトが登録されていない場合はここで登録をすることができるが、登録後に画面が戻ってしまうため、改めて移行画面を開く必要があった。旧ドメインからの流入がなくなるまでこの機能を有効にしておけばよいらしい。
Bing Webmaster Toolsのほうにはサイト移行の機能はぱっと見存在しなかった。かつては存在していたようで、説明をしている記事がいくつも出てくるが、古い情報だったようである。古いほうで一括でクロールを要求することで、301リダイレクトをいい感じに処理してくれないかなと祈っている。
Crawler Hintsの設定
Bingはサイト側から変更のあったページを通知してインデックスしてもらうIndexNowという機能に対応しているが、*.pages.devのころはCloudflare側では対応していなかった。独自ドメインにしたことでIndexNowに対応するCrawler Hintsなる機能が使えるようになり、Bing Webmaster Toolsに「IndexNow使えよ」という通知が出ることがなくなった。
Email Routing
サイトとは関係ないが、Cloudflareでは追加料金なしでEmail Routingという機能を使うことができる。これは独自ドメインでメールを受信し、指定した外部メールアドレスに転送するというだけの機能であり、送信はできない。受信メールアドレスのユーザ名部分(@の前)によって振り分けたり、逆にすべてを一つのアドレスに転送したり(初回設定時に条件設定みたいなのが出るがスキップできる)することができる。なんか色々複雑な処理をすることもできるらしい。
送信について、無料のGmailやOutlookでも送信元を独自ドメインに設定することはでき、これを送信の設定としている記事が多く見られるが、これはヘッダFromを勝手に書き換えているだけであり、なりすましと区別がつかない。配信元サーバ(エンベロープFrom)や署名のドメインはGmailやOutlookであるため、SPF(送信元サーバのIPアドレスがドメイン側で認められているか)やDKIM(署名時点から中身が変わっていないか)には合格するが、それら(のどちらか一方)とヘッダFromの整合性を要求するDMARCアラインメントには適合せず、受信側で迷惑メール扱いされる可能性が高い。真っ当な送信を行いたい場合は、DKIM等の面倒を見てくれるサービス(GoogleやMicrosoftでは有料)を使う必要があるらしい。
あとがき
意外とCloudflare Pagesを途中から独自ドメインに移行するという記事は見つからなかったので書いてみたが、結局全部公式ドキュメントに書いてあり、特に難しいことはなかった。特筆すべき情報としては、Bing Webmaster Toolsのサイト移行機能が滅びていることと、サイトとは関係ないがメールの認証まわりの話くらいである。
UEC2 Advent Calendar 2025 5日目の参加者はいません。今からでも記事を生やしましょう。