Cloudflare Pagesで独自ドメインを公開する手順｜Astro静的サイトの実例

この記事では、GitHubで管理している静的サイトを、Cloudflare Pagesで独自ドメインに公開するまでの手順を整理します。

題材は、このサイト（Web支度室／webjitaku.com）です。Astroで作った静的サイトを、2026年10月7日にCloudflare Pagesへ接続し、apexドメイン（wwwなしの webjitaku.com）で公開しました。記事では、そのとき実際に行ったことと、Cloudflareの公式ドキュメントで確認できることを分けて書いています。

画面の文言について：Cloudflareの管理画面のメニュー名やボタン名は、変更されることがあります。記事中の画面に関する記述は、2026-10-07時点の確認内容です。操作するときは、公式ドキュメントの最新の手順もあわせて確認してください。

前提

この記事が想定しているのは、次のような状態です。

サイトのソースコードをGitHub（またはGitLab）のリポジトリで管理している
静的サイト生成ツール（この記事の実例ではAstro）で、ビルドするとHTMLなどのファイルが出力される
独自ドメインを取得済みで、そのドメインをCloudflareで管理している、または管理する予定がある
Gitでのコミットやブランチの操作に慣れている

ドメインを取得してからCloudflareにDNSを任せるまでの流れは、独自ドメイン取得後にやることで説明しています。この記事は、その続きにあたる「ホスティングとつないで公開する」部分です。

なお、wwwなしのapexドメインをPagesで使う場合、公式ドキュメントでは、そのドメインがPagesプロジェクトと同じCloudflareアカウント上のゾーンになっている（ネームサーバーがCloudflareを向いている）必要があるとされています（Cloudflare公式：Pagesのカスタムドメイン、2026-10-07確認）。shop.example.com のようなサブドメインだけを使う場合は、この条件は異なります。

GitHubとPagesを接続する

Cloudflare PagesはGitHub・GitLabのリポジトリと接続でき、接続すると、本番用のブランチへの変更は本番環境へ、それ以外のブランチやプルリクエストはプレビュー環境へ、自動でデプロイされます（Cloudflare公式：Git連携、2026-10-07確認）。

Web支度室では、次の設定でプロジェクトを作成しました。

項目	Web支度室での設定
リポジトリ	Web支度室のGitHubリポジトリ
Production branch（本番ブランチ）	`main`
独自ドメイン	作成時点では未接続（`pages.dev` のURLのみ）

プロジェクト作成時の画面では、GitHubへのアクセスを許可し、対象のリポジトリを選び、ブランチやビルドの設定を入力する流れでした（2026-10-07時点）。

Build設定

Pagesのプロジェクトには、「ビルドのときに実行するコマンド」と「ビルド結果が出力されるフォルダ」を設定します。

Web支度室（Astro）での実際の設定は次のとおりです。

項目	値
Build command	`npm run build`
Build output directory	`dist`

この値は、Cloudflare公式のAstroのガイドとフレームワークプリセットの値とも一致しています（Cloudflare公式：Astroサイトのデプロイ、ビルド設定、2026-10-07確認）。

他のフレームワークでは値が異なります。 公式のビルド設定のページでは、たとえばHugoは hugo と public、Next.jsの静的書き出しは npx next build と out が示されています。使っているツールの公式ドキュメントと、手元で npm run build などを実行したときに実際にどのフォルダへ出力されるかを確認してから設定してください。

リポジトリ側には、Pagesの出力先を書いた設定ファイル（Web支度室では wrangler.toml に pages_build_output_dir = "dist"）も置いています。

まずpages.devで確認する

プロジェクトを作成すると、プロジェクト名.pages.dev のURLでサイトが表示できるようになります。Web支度室では、独自ドメインをつなぐ前に、このURLで一通りの確認を済ませました。 独自ドメインを接続してから問題に気づくと、利用者に見える状態で直すことになるためです。

実際に確認した項目は次のとおりです。

ビルド：Pages上のビルドが成功しているか
200：トップページ、固定ページ、/robots.txt、/sitemap-index.xml、/rss.xml がHTTP 200を返すか
表示：横幅390・768・1024・1440pxで、横にはみ出す要素がないか
console：ブラウザのコンソールにエラーが出ていないか
画像：表示されない画像がないか
canonical：pages.dev で開いても、canonicalが本番URL（https://webjitaku.com）を指しているか
robots・sitemap：robots.txtにsitemapのURLが書かれ、sitemapが本番URLで出力されているか
構造化データ：運営者（Organization）とサイト（WebSite）の情報が意図どおりか
計測：計測タグが、意図しない環境で読み込まれていないか

Web支度室では、この時点でGA4の測定IDを設定していなかったため、pages.dev でもGA4のタグは読み込まれず、計測データが送られない状態でした。「計測の混入を防ぐ仕組みを検証した」のではなく、「そもそも計測タグがない」ことを確認した、という点に注意してください（後述）。

canonicalが本番URLを向いているかは特に重要です。同じ内容が pages.dev と独自ドメインの両方で表示できるため、正式なURLを示しておく必要があります。canonicalの考え方は独自ドメイン取得後にやることで説明しています。

独自ドメインを接続する

pages.dev での確認が済んだら、Pagesプロジェクトに独自ドメインを追加します。2026-10-07時点の公式ドキュメントでは、ダッシュボードの「Workers & Pages」から対象のPagesプロジェクトを開き、「Custom domains」→「Set up a domain」を選んで、使いたいドメイン名を入力して「Continue」で進む手順が示されています。

公式ドキュメントでは、次の2点が強調されています（Cloudflare公式：Pagesのカスタムドメイン、2026-10-07確認）。

Pages側でドメインを関連付けずに、DNSにCNAMEレコードだけを手で追加すると、ドメインが正しく解決されない（エラーになる）
CAAレコードがあり、Cloudflareが使う認証局を許可していないと、証明書が発行できない

つまり、DNSレコードを先に手で作るのではなく、Pagesの画面からドメインを追加して、必要なレコードの作成を任せるのが基本です。

DNSはどう変わったか

Web支度室では、Custom Domainを追加する前と後で、Cloudflare上のDNSレコードが次のように変わりました。

時点	DNSレコード
Custom Domain追加前	0件（新規取得したドメインで、メールなど既存の用途がなかった）
Custom Domain追加後	1件（apexの `webjitaku.com` から、プロジェクトの `pages.dev` へ向けるCNAMEレコード。Cloudflareが自動で作成し、プロキシ有効・TTLは自動）

apexドメインには通常CNAMEを置けませんが、CloudflareはCNAME Flatteningという仕組みで、apexのCNAMEを最終的なIPアドレスに解決して応答します（Cloudflare公式：CNAME Flattening、2026-10-07確認）。実際に2026-10-07に外部のリゾルバーから webjitaku.com を照会すると、CNAMEではなくAレコード・AAAAレコードとしてIPアドレスが返ってきました。

これはWeb支度室のケースです。次のような場合は、結果が変わります。

すでにメールやほかのサービスでドメインを使っている場合（既存のレコードが残ります）
www などのサブドメインも追加する場合（追加した分だけレコードが増えます）
同じ名前にすでに別のレコードがある場合

既存のレコードがあるドメインで作業する場合は、事前の棚卸しが欠かせません。その手順はDNS・ネームサーバー移行のチェックリストにまとめています。

SSL

Web支度室では、Custom Domainを追加したあと、Pages上のドメインの状態がActiveになり、証明書が有効になったことを確認しました。そのうえで、次の2点を実際にアクセスして確かめています。

https://webjitaku.com/ がHTTP 200を返し、ブラウザに警告が出ない
http://webjitaku.com/ にアクセスすると、https://webjitaku.com/ へ301リダイレクトされる

証明書の発行には時間がかかることがあります。状態がActiveにならない場合は、前述のCAAレコードを確認してください。

wwwについて：Web支度室は、2026-10-07時点で www.webjitaku.com を設定していません（名前解決されません）。名刺などでwwwありのアドレスを使う予定がある場合は、wwwも追加し、正式なアドレスへリダイレクトする設定が必要です。Cloudflare Pagesでの方法は公式ドキュメントで紹介されています（Cloudflare公式：wwwのリダイレクト）。

PreviewとProductionを分ける

Pagesには、本番（Production）とプレビュー（Preview）の2つの環境があります。

Production：本番ブランチ（Web支度室では main）のデプロイ。独自ドメインと プロジェクト名.pages.dev で表示されます。
Preview：本番以外のブランチやプルリクエストのデプロイ。公式ドキュメントでは、ハッシュつきのURLやブランチ名のURLが作られると説明されています（Cloudflare公式：プレビューデプロイ、2026-10-07確認）。

同じドキュメントによると、プレビューデプロイには既定で X-Robots-Tag: noindex ヘッダーが付き、検索エンジンにインデックスされないようになっています。一方で、プレビューのURLは既定では誰でも開ける状態で、アクセスを制限したい場合はCloudflare Accessで認証をかけられるとされています。公開前の情報を含むブランチを扱う場合は、この点を意識してください。

注意したいのは、プロジェクト名.pages.dev 自体は本番のデプロイを表示するという点です。プレビューとは別物なので、noindexの扱いやcanonicalは別に確認する必要があります。Web支度室では、canonicalを常に https://webjitaku.com にすることで、pages.dev で表示されても正式なURLが独自ドメインになるようにしています。

Analytics contaminationを防ぐ

プレビューや pages.dev の閲覧が本番の計測データに混ざると、アクセス数やイベント数が実態とずれます。ここでは「Web支度室の現状」と「Movanceの別サイトでの運用例」を分けて説明します。

Web支度室の現状（2026-10-07時点）

GA4は未設定で、測定ID（PUBLIC_GA_ID）も設定していません。
サイトのコードは、測定IDが設定されているときだけGA4のタグを出力する作りです。そのため現在は、本番でも pages.dev でもGA4のタグは読み込まれません。
Web支度室では、プレビューを計測から除外する仕組みをまだ実地で検証していません。 「計測タグがないので混入しようがない」という状態です。

Movanceの別サイトでの運用例（AI議事録ナビ）

Movanceが運営する別のサイト「AI議事録ナビ」では、Cloudflare Pagesへの移行準備の中で、次の構成をとりました（2026-10-07の作業記録による）。

測定IDの環境変数（PUBLIC_GA_ID）を、PagesのProduction環境にだけ設定し、Preview環境には設定しない
さらに、GA4の設定とMicrosoft Clarityのタグは、ページを開いているホスト名が本番のホスト名と一致するときだけ動くようにする

2段構えにしているのは、Production環境の変数を設定すると、本番のビルドを表示する pages.dev のURLにも同じタグが入るためです。実際にAI議事録ナビでは、Production環境に測定IDを設定して再デプロイしたあと、HTMLにはGA4のタグが含まれている一方で、pages.dev のURLではGA4・Clarityの計測リクエストが0件であることを確認しました。ただし、本番の独自ドメインはまだCloudflare Pagesへ切り替えていないため、Pagesへの切り替え後に本番のホスト名で計測リクエストが送られるかの確認は、2026-10-07時点で未実施です。

これはAI議事録ナビでの実例で、Web支度室にはまだ同じ仕組みを入れていません。Web支度室でGA4を導入するときに、同様の構成を検討する予定です。計測が「設置できているつもり」になっていないかの確認方法は、GA4・Search Consoleの初期設定チェックリストで整理しています。

Rollback

「元に戻す」といっても、Pagesの公開では性質の違う2種類があります。混同すると、戻したつもりで戻っていない、という事態になりかねません。

1. デプロイのロールバック（サイトの中身を戻す）

新しいデプロイで表示が崩れた、内容に誤りがあった、といった場合です。

Pagesのロールバック機能：公式ドキュメントでは、デプロイの一覧から過去のデプロイを選んで「Rollback to this deployment」を実行すると、本番のデプロイが即座に切り替わると説明されています。ロールバック先にできるのは、ビルドに成功した本番のデプロイで、プレビューのデプロイは対象外です（Cloudflare公式：ロールバック、2026-10-07確認）。
Gitで戻す：問題のコミットを取り消すコミット（git revert など）を本番ブランチへ反映すると、新しいデプロイとして元の内容が公開されます。

Pagesのロールバックは本番の表示をすぐ戻せますが、リポジトリの中身は変わりません。原因のコミットはGit側で別に直しておかないと、次のデプロイで同じ問題が再び出ます。

2. DNS・カスタムドメインのロールバック（つなぎ先を戻す）

独自ドメインの接続そのものを取り消す場合です。

公式ドキュメントでは、カスタムドメインを外すときは、DNSのCNAMEレコードを削除したうえで、Pagesの画面からドメインを削除（Remove domain）する手順が示されています（Cloudflare公式：Pagesのカスタムドメイン）。
Web支度室の場合、接続前のDNSレコードは0件だったため、戻す先は「レコードがない状態」です。

ほかのサーバーから移行してきたドメインでは、戻す先は「移行前のサーバーとDNSの設定」です。その場合のロールバック先の残し方は、DNS・ネームサーバー移行のチェックリストで説明しています。

Web支度室の実例

Web支度室で行った作業を、時系列で整理します。作業はいずれも2026年10月7日（日本時間）に行いました。

ネームサーバーの委任：XServerで取得したドメインのネームサーバーをCloudflareへ委任
- 確認：Cloudflare上のステータスがActiveになったこと。DNSレコードは0件のまま
Pagesプロジェクトの作成：GitHubリポジトリと接続（本番ブランチ main、npm run build、dist）
- 確認：ビルド成功
pages.dev での公開前QA
- 確認：主要ページとrobots.txt・sitemap・RSSが200、390／768／1024／1440pxで横はみ出しなし、consoleエラー0、表示されない画像0、canonicalが https://webjitaku.com、GA4のタグなし
Custom Domainの追加：Pagesプロジェクトに webjitaku.com（apex）を追加
- 確認：DNSレコードが0件から1件（pages.dev へのCNAME）に変わったこと
SSLと本番表示の確認
- 確認：ドメインがActive、証明書が有効、https://webjitaku.com/ が200、http:// から301で https:// へ転送、本番でも手順3と同じ項目に問題がないこと

2026-10-07時点で、次の項目は未設定です。

www.webjitaku.com
DNSSEC（接続が安定してから、別の作業として検討する方針）
GA4・Search Console

また、実機（スマートフォン・タブレット）での表示確認は行っておらず、表示の確認はブラウザの画面幅を変えて行ったものです。

公開前後に確認する項目の全体は、ホームページ公開前チェックリストにまとめています。

この記事の確認方法

確認日：2026-10-07

Web支度室で実際に確認したこと

Pagesプロジェクトの設定（GitHub連携、本番ブランチ main、npm run build、dist）と、pages.dev での公開前QAの結果（作業記録による）
Custom Domain追加前後のDNSレコード（0件→apexのCNAME 1件）、ドメインのActive化と証明書（作業記録による）
https://webjitaku.com/ の200応答、http:// からの301リダイレクト、canonical、robots.txt、sitemapの応答、apexの照会結果がA・AAAAで返ること、www が名前解決されないこと、GA4のタグがないこと（2026-10-07の実際のアクセスとDNS照会による）

Movanceの別サイトで確認したこと

AI議事録ナビで、測定IDをProduction環境だけに設定し、ホスト名による判定を加えた結果、pages.dev ではGA4・Clarityの計測リクエストが0件だったこと（2026-10-07の作業記録による）。本番の独自ドメインはPagesへ未切り替えのため、切り替え後の本番ホスト名での送信確認は未実施

公式情報で確認したこと

Git連携とデプロイの仕組み：Cloudflare公式：Git連携
Astroのビルド設定と、ほかのフレームワークのプリセット：Astroサイトのデプロイ、ビルド設定
カスタムドメインの条件、手動CNAMEとCAAの注意、ドメインの削除方法：Pagesのカスタムドメイン
プレビューデプロイのURL、noindexヘッダー、アクセス制限：プレビューデプロイ
ロールバックの対象と手順：ロールバック
wwwのリダイレクト：wwwのリダイレクト
apexでのCNAMEの扱い：CNAME Flattening

編集上の判断

「独自ドメインを接続する前に pages.dev で一通り確認する」「1回の作業で変える範囲を小さくする」という進め方は、Web支度室での判断です。
ロールバックを「デプロイ」と「DNS・カスタムドメイン」の2種類に分けて考える整理は、Web支度室編集部によるものです。
アカウントID、ゾーンID、ネームサーバー名など、読者の作業に不要な固有情報は掲載していません。

Cloudflare Pagesで独自ドメインを公開する手順 — Astro静的サイトの実例

前提