devブランチを作る
Cloudflare Pagesでは、production branch以外のブランチをpushするとPreview deploymentが作られます。mainを本番、devを確認用にするなら、devブランチを作ってpushします。
devブランチのPreviewには、dev.example-project.pages.devのようなURLができます。便利ですが、URLを知っている人が見られる状態になることがあります。
未公開記事や調整中のページを置くなら、Previewは公開前提ではなく、確認環境として閉じておく方が安全です。
dev確認用のサブドメインを作る
毎回pages.devのURLを見るより、確認用の固定サブドメインを作ると運用しやすくなります。たとえば本番をcolumn.example.com、devをdev-column.example.comにします。
DNSでは、dev-column.example.comをdev.example-project.pages.devへ向けます。Cloudflare Pagesでは、branch名を含むpages.dev URLをCNAME先にすることで、dev branchのPreviewへ向けられます。これで、確認用URLを固定できます。Tag AssistantやAccessの設定、ユーザー確認URLとしても扱いやすくなります。
devサブドメインだけ守っても足りない
dev-column.example.comにCloudflare Accessをかけると、dev環境は守られたように見えます。しかし裏側のPreview URLは別です。dev.example-project.pages.devを直接開くと、Accessなしで見えてしまう場合があります。つまり、dev用カスタムドメインだけを守っても不十分です。
確認環境を本当に閉じるには、pages.dev側もAccess対象に入れる必要があります。
pages.dev側もAccessで閉じる
実運用では、*.example-project.pages.devをCloudflare Accessの対象にします。これでbranch previewやhash付きPreview URLもまとめて保護できます。
個別にdev.example-project.pages.devだけ閉じる方法もあります。ただ、Cloudflare PagesはdeploymentごとにURLが残るため、過去Previewまで考えるとワイルドカードで包む方が現実的です。
Preview URLは消して管理するものではなく、Accessで包んで管理するもの、と考えた方が運用しやすいです。
本番はAccess対象にしない
本番ドメインはAccess対象に入れません。公開サイトまでログイン必須にすると、通常のユーザーも検索エンジンも見られなくなります。
守るのはdev用サブドメインとpages.dev側のPreviewです。本番は公開、devと裏PreviewはAccess付き。この分け方が分かりやすいです。
設定後はゲストモードやcurlで、本番が200、devとPreviewがAccessログインへ向くことを確認します。
まとめ
Cloudflare Pagesは公開までは簡単ですが、実運用ではGitHub連携、Preview URL、Access、旧project整理を分けて考える必要があります。
大事なのは、見えているサイトがどのproject、どのrepository、どのbranch、どのcommitから出ているかを確認することです。