Cloudflare Pagesの使い方｜公開手順・独自ドメイン・Web Analytics設定とWorkers移行判断

Cloudflare Pagesは、Gitリポジトリをつなぐだけで静的サイトとサーバーサイド処理を無料枠のまま公開できるホスティングです。ただし2026年時点の前提は、登場当初から2つ動きました。新規プロジェクトの既定がWorkersに変わり、C3で作るときは --platform=pages の明示が必要になったこと。そして公式のRemix向けガイドが2026年4月に手順の記載をやめ、後継のReact Routerへの案内だけになったことです。

この記事では、Cloudflare Pagesでサイトを公開するまでの手順、独自ドメインとSSLの設定が分岐する条件、Web Analyticsの有効化、D1を使った動的化までを、公式ドキュメントの現行記述に沿って整理します。あわせて、いまPagesを選ぶ条件とWorkersへ移す条件を、Cloudflareが公開している互換表から判断できる形で示します。

まとめ

先に結論だけ挙げます。

• 公開経路はGit連携とダイレクトアップロードの2つ。後者はWrangler経由なら20,000ファイル、ドラッグ&ドロップなら1,000ファイルまでです。
• 独自ドメインはapexならネームサーバーのCloudflare移管が必須、サブドメインならCNAMEで足ります。ただしダッシュボードでの登録を先に済ませないと522になります。
• SSL証明書はCloudflareが発行します。検証が止まる原因はCAAレコードとACMEチャレンジパスの遮断の2つです。
• Web AnalyticsはPagesプロジェクトの Metrics タブから有効化でき、反映は次回デプロイのタイミングです。旧Browser Insightsの後継にあたります。
• 無料枠で先に当たるのは月500ビルドと1ファイル25MiBです。転送量ではありません。
• D1の課金は読み取った行数で決まります。返した行数ではありません。
• これから新規に作るなら既定はWorkersです。あえてPagesを選ぶ実務上の理由は、ネームサーバーをCloudflareに向けられない独自ドメインを使う場合にほぼ限られます。

以降で、各手順と判断の根拠を順に見ていきます。

Cloudflare Pagesでサイトを公開する2つの経路

Pagesの公開方法はGit連携とダイレクトアップロードの2種類です。継続的に更新するサイトはGit連携、既に別のCIでビルドしている場合や一度だけ出したい場合はダイレクトアップロードが向きます。

Git連携での公開とビルド出力ディレクトリの指定

ダッシュボードの Workers & Pages からプロジェクトを作成し、GitHubまたはGitLabのリポジトリを選びます。設定項目のうち後から詰まりやすいのは、ビルドコマンドと「ビルド出力ディレクトリ」です。フレームワークによって出力先が異なるため、ここを取り違えると、ビルドは成功しているのに空のサイトが公開されます。

C3というCLIからひな形を作ることもできますが、2026年現在は --platform=pages の指定が要ります。省略するとPagesではなくWorkersのプロジェクトが生成されます。この既定の変わり方が持つ意味は、後述の移行の章で扱います。

npm create cloudflare@latest -- --platform=pages

ダイレクトアップロードでビルド済み成果物を送る2つの方法

手元やCIでビルドした成果物をそのまま送る経路には、Wrangler CLIとダッシュボードのドラッグ&ドロップがあります。2026年8月11日時点のwranglerの最新版は4.120.1です。

npx wrangler pages deploy ./dist --project-name=my-site

本番ではなくプレビュー環境へ出したい場合は、--branch=BRANCH_NAME を付けます。プレビューデプロイは同時にいくつ持っていても構わないため、確認用に別プロジェクトを作る必要はありません。

2つの方法は扱えるファイル数が違います。この差は公式ドキュメントでプラン非依存の上限として定義されています。

ドラッグ&ドロップはサーバーサイド処理を置く functions フォルダをコンパイルしないため、Pages Functionsを使うならWrangler経由に固定してください。単一の _worker.js であればどちらでも動きます。なお、Git連携済みのプロジェクトに対してダッシュボードからドラッグ&ドロップすることはできません。

独自ドメインとSSLの設定が分岐する条件

公開直後のURLは pages.dev のサブドメインです。ここに独自ドメインを当てる手順は、apexドメイン（example.com）とサブドメイン（shop.example.com）で前提が変わります。この分岐を知らずに進めると、DNSは正しく見えるのにサイトが開かない状態に陥ります。

apexドメインはネームサーバーのCloudflare移管が前提

apexドメインをPagesに割り当てるには、そのドメインをCloudflareのゾーンとして登録し、ネームサーバーをCloudflareのものへ向ける必要があります。公式ドキュメントは、ネームサーバーの向き先が正しく切り替われば、CloudflareがCNAMEレコードを自動で作成すると説明しています。レジストラ側の作業が入るため、反映まで時間がかかる点は見込んでおいてください。

サブドメインのCNAME設定とダッシュボード登録の順序

サブドメインの場合、ドメイン全体をCloudflareのゾーンにする必要はありません。任意のDNSプロバイダーで、対象サブドメインから pages.dev のプロジェクトURLへCNAMEを張れば動きます。

ここで順序を間違えないでください。公式ドキュメントは、Pagesダッシュボードでドメインを紐づける前にCNAMEレコードだけを手動で追加した場合、名前解決に失敗して522エラーが表示されると明記しています。先にダッシュボードの Custom domains でドメインを登録し、そのうえでDNS側のレコードを整えるのが正しい順番です。

SSL証明書の発行が止まる2つの原因

SSL証明書はカスタムドメインの登録に伴ってCloudflareが発行するため、取得や更新を自分で回す作業はありません。ただし公式ドキュメントは、ドメインが Verifying の段階から進まなくなる原因を2つ挙げています。

1つはCAAレコードです。Cloudflare以外の認証局だけを許可するCAAレコードがあると、Cloudflareは証明書を発行できません。もう1つはHTTP検証の遮断で、PagesはドメインのACMEチャレンジパス /.well-known/acme-challenge/* へ実際にアクセスして検証します。Cloudflare AccessやWorker、リダイレクトルールがこのパスを横取りしていると検証が完了しません。curlで叩いてLocationヘッダが返っていないか確かめ、通過するまでAccessを一時的に外してください。なお、証明書の優先順位の都合でAdvanced CertificatesはPagesでは利用できません。

PagesプロジェクトでのWeb Analytics有効化と計測の切り分け

Cloudflare Web Analyticsは、Cookieやローカルストレージを使わずにページビューとCore Web Vitalsを取れるアクセス解析です。かつてBrowser Insightsという名前で提供されていた機能の後継にあたり、公式ドキュメントは「以前Browser Insightsを使っていたCloudflareプロキシ配下のサイトでは、Web Analyticsが既定で有効になっている」と記述しています。

Metricsタブからの有効化と、反映が次回デプロイになる理由

Pagesプロジェクトの場合、JSスニペットを自分でテンプレートに貼る必要はありません。手順は3つです。

• 1. ダッシュボードの Workers & Pages を開く
• 2. 対象のPagesプロジェクトを選ぶ
• 3. Metrics タブの Web Analytics で Enable を押す

公式ドキュメントによれば、これでCloudflareが次回のデプロイ時にJavaScriptスニペットを自動で追加します。有効化した直後にダッシュボードを見ても数字が動かないのは、この「次回デプロイで挿入」という仕様のためです。設定を反映させたいときは、空コミットでも構わないのでデプロイを1回走らせてください。

計測対象のパスを絞るRules機能は、Freeプランでは0件です。公式のLimitsは、上限が0のプランではスニペットが全サブドメインに挿入されると説明しています。つまりFreeプランでは「特定パスだけ計測する」設定はできず、逆に全サブドメインが対象になります。絞り込みが要るならProの5件以上が必要です。

数字が入らないときの切り分け

有効化したのにデータが表示されない場合、原因はほぼ次の3つです。

• 有効化後にデプロイしていない：Pagesのスニペット挿入は次回デプロイのタイミングです。まずここを疑ってください。
• 非プロキシサイトの登録上限：Cloudflareのプロキシを通っていないサイトは、Web Analyticsに登録できる数が10件までです。プロキシ配下のサイトに上限はありません。
• そもそもJavaScriptが実行されていない訪問：Web Analyticsが返すのはクライアント側の計測値だけです。ボットや解析ブロッカー経由のアクセスは数に入らないため、エッジ側のトラフィック統計とは必ずずれます。

公式には、レスポンスの Cache-Control が public, no-transform だとビーコンが自動挿入されないという注意書きもあります。ただしこれはCloudflareプロキシによるHTML書き換えを前提にした制約で、デプロイ時に挿入するPagesとは機序が違います。Pagesは圧縮済みアセットに自ら Cache-Control: no-transform を付けるため、この注意書きをPagesにそのまま当てはめる必要はありません。

実装で先に当たるPagesの上限値

Pagesを触っていて実際に止まるのは、料金ではなく上限値です。Freeプランの主要な数値を挙げます。

公式Limitsの2026年7月16日更新時点の値です。ビルドは20分でタイムアウトし、アカウント当たりのプロジェクト数は100が上限、カスタムドメイン数はプロジェクト単位で数えます。ファイル数の上限を有料プラン相当の10万に引き上げるには、プロジェクト設定で環境変数 PAGES_WRANGLER_MAJOR_VERSION=4 を指定してください。なお月500回というビルド上限は、Gitリポジトリへのプッシュを契機に走るPages側のビルドに対する制限です。

1ファイル25MiBという制限は、動画や大きなアーカイブを置こうとしたときに効いてきます。この場合はPagesに載せず、オブジェクトストレージ側に逃がすのが定石です。詳細はCloudflare R2とは？エグレス無料のS3互換オブジェクトストレージを料金・無料枠から解説で整理しています。

リダイレクトとヘッダの上限も押さえておくと設計が楽になります。_redirects は静的2,000件と動的100件の合計2,100件、_headers は100ルールで1ヘッダ2,000文字までです。プラン全体の料金や無料枠の考え方はCloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめにまとめてあります。

D1で動的サイトにする最小構成と課金の当たり方

静的ファイルだけでは足りず、フォームの保存や記事一覧の出し分けが要るなら、CloudflareのサーバーレスSQLデータベースであるD1を組み合わせます。SQLiteベースで、スケールトゥゼロのため未使用時の課金はありません。

Pages FunctionsでD1を使う場合のバインディング手順

既存のPagesプロジェクトにD1をつなぐなら、ダッシュボードでバインディングを追加します。プロジェクトの Settings から Bindings を開き、Add で D1 database bindings を選んで変数名とデータベースを指定し、再デプロイすると有効になります。Function側はコンテキスト経由で参照します。

export async function onRequest(context) {
  const ps = context.env.NORTHWIND_DB.prepare("SELECT * from users");
  const data = await ps.first();
  return Response.json(data);
}

Workers構成での設定ファイル1つによる静的アセットとの同居

新規に組むならWorkersの静的アセット構成を選びます。ダッシュボードでの設定作業が要らず、バインディングも配信設定も1ファイルに収まります。

{
  "name": "pages-to-workers-demo",
  "compatibility_date": "2026-08-10",
  "main": "./worker/index.ts",
  "assets": {
    "directory": "./dist/client/",
    "binding": "ASSETS",
    "not_found_handling": "single-page-application"
  },
  "d1_databases": [
    { "binding": "DB", "database_name": "demo-db", "database_id": "local-demo" }
  ]
}

スキーマはSQLファイルに書き、npx wrangler d1 execute DB --local --file=./schema.sql で適用します。アプリケーション側は、バインディング名 DB 経由でプリペアドステートメントを組み立てます。

export default {
  async fetch(request: Request, env: any) {
    const url = new URL(request.url);
    if (url.pathname.startsWith("/api/posts")) {
      const stmt = env.DB
        .prepare("SELECT id, title FROM posts WHERE published = ?1 ORDER BY id LIMIT 20")
        .bind(1);
      const { results, meta } = await stmt.run();
      return Response.json({ results, rows_read: meta.rows_read });
    }
    return env.ASSETS.fetch(request);
  },
};

この構成をwrangler 4.120.1のローカル開発サーバーで起動すると、ルートパスは静的アセットから、APIパスはD1を参照するWorkerから、それぞれ200で応答します。

行スキャン数で決まる課金と、避けたい書き方

D1の課金で誤解が起きやすいのは、読み取り行数の数え方です。公式ドキュメントは、rows readは「クエリが読んだ（スキャンした）行数」であり、インデックスの無い列で絞り込んだクエリはWorkerに返す行が少なくても、絞り込みのために多くの行を読む必要があると説明しています。5,000行のテーブルに全表走査をかければ、返り値が2行でも5,000行読取として数えられます。

Freeプランは1日500万行の読取と10万行の書込、ストレージは合計5GBまでです。ここで見落とされやすいのが、1データベースあたりの上限が別に効く点で、Freeは500MB、有料プランは10GBが上限になります。有料プランの課金は、月250億行の読取が含まれて超過分は100万行あたり0.001ドル、書込は5,000万行が含まれて超過分は100万行あたり1.00ドルです。

実装上の対処は2つに絞れます。第一に、WHERE句で使う列にインデックスを張ることです。公式ドキュメントは、インデックスを張った列に書き込みがあると索引側にも1行書き込まれるため書込行数は増えるが、読取削減の効果がほぼすべてのケースでそれを上回ると述べています。第二に、1回のクエリで大量の行を投入しないことです。SQL文の最大長は100,000バイトで、数千行分のVALUES句を1文にまとめると上限に触れます。分割するか、バッチAPIを使ってください。

どちらの対処が効いているかは、返り値の meta.rows_read で実測できます。テーブル設計を固める前にこの値を確認してください。

Pagesに残すかWorkersへ移すかの判断基準

検索結果の「他の人はこちらも質問」に「PagesはCloudflareからなくなりますか？」が並ぶとおり、この点は多くの人が気にしています。Pagesのドキュメントトップは2026年8月時点でも Available on all plans と表示され、移行ガイドを含めて提供終了を告げる記述はありません。ただし、新規に作るものの既定はWorkersへ移りました。

C3の既定がWorkersに変わった意味

前述のとおり、C3で新規プロジェクトを作るとき、明示的に --platform=pages を付けなければ生成されるのはWorkersプロジェクトです。フレームワークガイドも同様で、React RouterやAstroといった主要フレームワークの現行ガイドはWorkers側に置かれています。Cloudflare自身がPagesからWorkersへの移行ガイドと互換表を用意し、2026年7月28日に更新している点も、力の入れどころを示しています。

既存のPagesプロジェクトを慌てて移す必要はありません。静的アセットへのリクエストはWorkersでも無料かつ無制限で、Pages FunctionsとWorkersの課金レートは同じであるため、移行してもコスト構造はほぼ変わらないとCloudflareは説明しています。移行の動機はコストではなく、機能です。

互換表でWorkersが非対応となる独自ドメインの条件

Cloudflareが公開している互換表は、対応・対応予定・回避策あり・非対応の4段階で記号が振られています。Workers側にしか無い機能は多数あります。

表の最下行が判断の分かれ目です。互換表でWorkersに「非対応」が付くのはこの1行だけで、カスタムブランチエイリアスは対応予定、Early Hintsやブランチビルド制御、Pages Functionsのファイルベースルーティングは回避策ありの扱いになっています。移行ガイドも「Pagesと違い、Workersはネームサーバーがcloudflare管理下にないドメインを一切サポートしない」と注記しています。

したがって判断はこうです。DNSをCloudflareに預けられる、あるいは既に預けているなら、新規プロジェクトでPagesを選ぶ理由はありません。逆に、社内規程や既存のDNS運用でネームサーバーを動かせない案件では、いまもPagesが唯一の選択肢になります。「とりあえず新しいほうへ」と移した結果、独自ドメインが当てられなくなるのが典型的な失敗パターンです。移行の判断より先に、ネームサーバーの権限を誰が持っているかを確認してください。

プレビュー環境の運用ルールが固まっているチームは、ブランチごとのビルド制御とカスタムブランチエイリアスの扱いも移行前に見ておくと安全です。Workers側の料金体系や機能全体はCloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめで扱っています。

RemixからReact Routerへ変わったフレームワーク側の前提

Cloudflare公式のPages向けRemixガイドは、2026年4月21日の更新で手順の記載をやめました。現在の内容は、Remixは作者自身が新規プロジェクトに推奨しておらず後継のReact Routerを使うべきである、という案内だけです。npmレジストリで見ても、2026年8月11日時点の @remix-run/react は2.17.5（2026年6月1日公開）で止まり、後継のreact-routerは8.3.0が最新版、v7系が7.18.2です。remixパッケージのnextタグには3.0.0-beta.5が置かれていますが、ベータ段階です。

いまRemix v2で新規に組み始める理由はありません。既存アプリをCloudflare上で動かし続けること自体は可能ですが、公式ガイドの更新はReact Router側にしか入らないため、詰まったときに参照できる一次情報が先細ります。React Router v8とCloudflare Viteプラグインの組み合わせはWorkers前提で整備されている点も、Pagesではなく移行先を選ぶ理由になります。フレームワーク選定そのものを見直す段階なら、Astroフレームワークとは？特徴と使い方・Next.jsとの使い分けを解説【2026年版】とレンダリングとは？ブラウザ描画の仕組みとCSR/SSR/SSGの違い・選定基準を解説も判断材料にしてください。

よくある質問

Cloudflare Pagesは無料で使えますか？

Freeプランで公開まで完結します。静的アセットへのリクエストは無料かつ無制限で、転送量による課金もありません。Freeで先に当たるのは月500ビルドと1サイト20,000ファイル、1ファイル25MiBといった上限値のほうです。サーバーサイド処理を担うPages Functionsのリクエストは、Workersの無料枠である1日10万リクエストを共有します。

PagesはCloudflareからなくなりますか？

2026年8月時点で、Pagesのドキュメントトップには Available on all plans と表示されており、提供終了に関する記述はどこにもありません。ただし新規プロジェクトの既定はWorkersに移っており、C3で作成するときは --platform=pages を明示しないとWorkersプロジェクトになります。公式のPagesからWorkersへの移行ガイドも継続的に更新されています。既存プロジェクトを直ちに移す必要はありませんが、新規案件は原則Workersで組むのが現在の流れに沿った判断です。

Cloudflare Pagesで独自ドメインを無料で使えますか？

Freeプランでも1プロジェクトに100個までカスタムドメインを設定でき、SSL証明書の費用もかかりません。ドメイン自体の取得費用はレジストラに支払う必要があります。apexドメインを使う場合はネームサーバーをCloudflareに向けることが前提で、サブドメインだけならCNAMEで対応できます。ダッシュボードでドメインを登録する前にCNAMEレコードだけを追加すると522エラーになるため、登録を先に行ってください。

Cloudflare PagesでWordPressを動かせますか？

PHPとMySQLで動くWordPress本体をそのまま載せることはできません。Pagesが配信するのはビルド済みの静的アセットと、JavaScriptランタイム上で動くPages FunctionsおよびWorkersだからです。実現する場合は、WordPressを別サーバーでヘッドレスCMSとして運用し、REST APIから取得した内容を静的生成してPagesに配信する構成を取ります。データベースが必要な部分をD1に置き換える方法もありますが、この場合はWordPressのプラグイン資産を引き継げません。

Cloudflare PagesはSEOに不利になりませんか？

配信基盤としての不利はありません。CDNのエッジから配信されるため応答は速く、独自ドメインとHTTPSも標準で使えます。順位に影響が出るとすれば、基盤ではなくレンダリング方式の選択です。クライアント側でのみ描画するSPA構成にすると、初期HTMLに本文が含まれないため評価が安定しません。静的生成またはサーバーサイドレンダリングを選び、初期HTMLに本文と見出しが載る形にしてください。_redirects を使えばリダイレクトの管理も配信側で完結します。

関連記事

• Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ
• Cloudflare R2とは？エグレス無料のS3互換オブジェクトストレージを料金・無料枠から解説
• Astroフレームワークとは？特徴と使い方・Next.jsとの使い分けを解説【2026年版】
• Cloudflare Tunnelとは？無料の仕組みと設定・使い方を初心者向けに解説
• Cloudflareの危険性は本当か？障害・SLA・情報漏えいの実態と対策