Cloudflare Pagesの使い方｜静的サイトの公開手順・独自ドメイン・商用利用とWorkers移行の判断【2026年10月】

Cloudflare Pagesは、Gitリポジトリかビルド済みのフォルダを渡すだけで、静的サイトをCloudflareのネットワークから配信できるホスティングです。静的ファイルへのリクエストは無料プランでも無料・無制限で、独自ドメインとSSL証明書も追加費用なしで使えます。

2026年10月時点で押さえておきたい前提が1つあります。Pagesの公式ドキュメントの冒頭には「Start new projects with Workers.」という案内が表示され、新規プロジェクトの推奨先はWorkersに移りました。ただしPagesは全プランで提供が続いており、Workersでは代替できない用途も残っています。この記事では、Pagesでサイトを公開する手順を中心に、ビルドが失敗したときの確認順、独自ドメインとSSL、商用利用の条件、Web Analytics、そしてWorkersへ移すかどうかの判断までを、公式ドキュメントの現行記述とローカルでの実測をもとに整理します。

まとめ

• 公開方法はGit連携・Wrangler・ドラッグ&ドロップの3つです。Git連携とダイレクトアップロードは、後から相互に切り替えられません。
• HTMLだけのサイトなら、ビルドコマンドは exit 0、出力先はHTMLを置いたフォルダです。最上位に index.html が無いと404になります。
• ビルドが失敗したら、ビルドログ→Node.jsの版（既定22.16.0）→出力ディレクトリ→環境変数の順に見ます。
• 独自ドメインは、apexならネームサーバーをCloudflareへ移す必要があり、サブドメインならCNAMEで足ります。ダッシュボードで登録する前にCNAMEだけ足すと522エラーになります。
• 規約上、無料プランの商用利用を禁じる条項は見当たりません。ただし pages.dev のサブドメインはCloudflareが変更しうると規約にあるため、本番は独自ドメインで公開します。
• 404.html を置かないと、存在しないURLにもステータス200でトップページが返ります。SPAではない静的サイトは、公開前に404.htmlを置いてください。
• 新規開発の推奨先はWorkersです。ただし、ネームサーバーをCloudflareに向けられないドメインのサブドメインで公開するなら、PagesとWorkersのうち対応できるのはPagesだけです。

Cloudflare Pagesで静的サイトを公開する手順

公開方法は、Gitリポジトリと連携する方法と、ビルド済みの成果物を直接アップロードする方法（Wranglerかダッシュボードへのドラッグ&ドロップ）に分かれます。Git連携の公式ガイドとDirect Uploadの公式ガイドは、どちらも「後から他方へは切り替えられない」と明記しています。方式を変えるにはプロジェクトを作り直すことになるため、最初に決めておきます。なお、Git連携のプロジェクトでも自動デプロイを止めたうえでWranglerからデプロイすることはでき、作り直しが要るのはダイレクトアップロードの方式へ完全に移る場合です。

HTMLだけのサイトをGit連携で公開する手順

フレームワークを使わない静的HTMLのサイトは、Static HTMLの公式ガイドどおりに次の順で公開します。GitHubとGitLabに対応し、公開・非公開どちらのリポジトリも選べます。

1. HTML・CSS・画像をGitHubのリポジトリにpushする（少なくとも1つのブランチをpushしておかないと、本番ブランチを選べません）
2. ダッシュボードの Workers & Pages で Create application を選び、Pages タブの Import an existing Git repository を選ぶ
3. リポジトリを選んで Begin setup を押す
4. Production branch に main、Build command に exit 0、Build output directory にHTMLを置いたフォルダを入れる
5. Save and Deploy を押すと プロジェクト名.pages.dev で公開される

Build command の exit 0 は「何もせず成功で終わる」という意味で、ビルドが不要なサイト向けに公式が推奨している値です。公開後に pages.dev で404が出るときは、出力ディレクトリの最上位に index.html があるかを確かめてください。以降は対象ブランチにpushするたびに自動で再公開され、本番以外のブランチは ブランチ名.プロジェクト名.pages.dev のプレビューURLで確認できます。

フレームワークを使う場合は、ビルドコマンドと出力ディレクトリをフレームワークに合わせます。ビルド設定の公式ドキュメントのプリセットから主なものを抜き出します。Next.jsの行は、next.config に output: 'export' を書いて静的エクスポートする場合の値です（この指定が無いと out は生成されません）。

Wrangler・ドラッグ&ドロップでのビルド済み成果物のアップロード

手元やGitHub Actionsでビルドした成果物を送るなら、CLIのWranglerを使います。2026年10月20日時点のnpmの最新版は4.151.2です。初回は wrangler login でブラウザ認証し、プロジェクトを作ってからデプロイします。

npx wrangler login
npx wrangler pages project create
npx wrangler pages deploy ./dist
# 本番以外のブランチとしてプレビューへ出す
npx wrangler pages deploy ./dist --branch=staging

ダッシュボードの Create application から Drag and drop your files を選ぶ方法は、zipかフォルダを放り込むだけで済みます。ただし上限が1,000ファイルと小さく、サーバー側の処理を置く functions フォルダをコンパイルしません。Pages Functionsを使うならWranglerに固定してください（単一の _worker.js はどちらでも動きます）。

ひな形をCLIのC3（create-cloudflare）で作る場合、フレームワークのテンプレートは --platform=pages を付けないとWorkersプロジェクトとして生成されます。create-cloudflare 2.74.1 のヘルプでは、この指定はPagesとWorkersの両方に対応するフレームワークのテンプレートにだけ効くと説明されています。

npm create cloudflare@latest -- my-site --framework=astro --platform=pages

ビルドが失敗するときの確認順

Debugging Pagesの公式ドキュメントの段階区分に沿って、ログのどの段階で止まったかから原因を絞ります。ログはプロジェクトの Deployments から View details を開き、Build log で読めます。

Building application で止まった場合は、次の順に確かめます。

1. Node.jsの版：ビルドイメージv3の既定はNode.js 22.16.0です。手元と版が違って落ちるなら、環境変数 NODE_VERSION を設定するか、リポジトリに .nvmrc か .node-version を置きます。Python・Ruby・Go・Bun・Hugoも同じく環境変数で版を指定できます。
2. 出力ディレクトリ：ビルドは成功しているのに空のページや404が出るなら、まず出力先を疑います。上のプリセット表と、ビルドログに出る生成先を突き合わせます。出力先が合っているのに真っ白な場合は、ブラウザの開発者ツールでJavaScriptのエラーやアセットの404を確かめます。
3. 環境変数：APIキーなどを手元の .env でだけ渡していると、Pagesのビルドでは未定義になります。Settings の Environment variables に入れます。Pagesは CF_PAGES=1 や CF_PAGES_BRANCH を自動で渡すので、手元とPagesでビルドを分けたいときに使えます。
4. 権限とコミット：GitLabのリポジトリはMaintainer以上の権限が要ります。公式は、コミットメッセージの絵文字や特殊文字がビルドの問題を起こしうるとも注意しています。

独自ドメインでだけ古い内容が出る場合は、ビルドではなくキャッシュ設定を疑います。Page Rulesに Cache Everything が残っていると、Pages自身のキャッシュと二重になって新しい内容が出ません。公式はこのルールの削除を案内しています。

公開前に確かめたいPagesの配信挙動（ローカル実測）

Pagesは、ファイルを置いただけでURLの扱いを自動で決めます。この自動判定を知らずに公開すると、SEO上の不具合をそのまま本番に出すことになります。そこで、wrangler 4.151.2 の wrangler pages dev（Node.js v26.5.0・2026年10月20日）で、次の構成をローカル起動して各URLのレスポンスを確かめました。

public/
  index.html
  about.html
  _redirects     # /old-page /about 301
                 # /blog/* /posts/:splat 302
  _headers       # /*  X-Frame-Options: DENY
functions/api/hello.js   # JSONを返すPages Function

読み取れることは3つあり、重要な順に並べます。

1つ目は、存在しないURLへの200応答です。Serving Pagesの公式ドキュメントは、最上位に404.htmlが無いプロジェクトをSPA（シングルページアプリケーション）とみなし、一致しないパスにルートの内容を返すと定めています。ReactのSPAには便利な仕様ですが、静的なコーポレートサイトやブログでは、打ち間違いのURLや削除したページがすべて「トップページと同じ内容の200」になります。検索エンジンからはソフト404と判定されやすい状態です。SPAでないサイトは、公開前に404.htmlを置いてください。

2つ目は、.html付きURLから拡張子なしURLへの308リダイレクトです。サイト内リンクやsitemap.xmlに about.html と書いていると、リンクのたびに転送を挟みます。リンクとsitemapは拡張子なしで書くのが無駄がありません。

3つ目は、_headers がFunctionsの応答には効かない点です。公式のHeadersのドキュメントも、Pages Functionsが生成した応答には _headers のルールを適用しないと明記しています。SSRフレームワークやAPIでセキュリティヘッダーを付けるなら、Functionの Response 側で付けます。なお _redirects は静的2,000件・動的100件の計2,100件、_headers は100ルールが上限です。

独自ドメインとSSLの設定手順

公開直後のURLは プロジェクト名.pages.dev です。独自ドメインはプロジェクトの Custom domains から Set up a domain で追加しますが、Custom domainsの公式ドキュメントのとおり、apexドメイン（example.com）とサブドメイン（www.example.com や shop.example.com）で前提が違います。

apexドメインに必要なネームサーバーの移管

apexドメインを使うには、そのドメインをPagesプロジェクトと同じCloudflareアカウントのゾーンとして登録し、ネームサーバーをCloudflareのものへ向ける必要があります。切り替わればCNAMEレコードはCloudflareが自動で作ります。ゾーン追加とネームサーバー変更の具体的な手順はCloudflareにドメインを追加する手順：ネームサーバー変更とDNS移行をAPIとdigで確かめる【2026年9月版】に、レジストラごとCloudflareへ移す場合はCloudflare Registrarの移管手順と料金｜.jp非対応・API登録の実装【2026年9月版】にまとめています。

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

サブドメインなら、ドメイン全体をCloudflareに移す必要はありません。お名前.comなど今のDNSサービスのまま、CNAMEを1行足せば動きます。

順序には注意が要ります。Pagesのダッシュボードでドメインを登録する前にCNAMEだけを追加すると、名前解決に失敗して522エラーが表示されると公式は明記しています。先に Custom domains で登録し、そのあとでDNS側のレコードを整えます。

wwwからapexへのリダイレクトとpages.devの扱い

example.com を正にするなら、www.example.com からの転送も用意します。公式のwwwリダイレクトの手順は、アカウントの Bulk Redirects でリストを作り、ルールを有効にする方法です。

1. Bulk Redirects のリストに、Source URL www.example.com・Target URL https://example.com・Status 301 を登録し、Preserve query string・Subpath matching・Preserve path suffix・Include subdomains をオンにする
2. そのリストを使うBulk Redirectルールを作る
3. DNSに www のAレコードを 192.0.2.1（ダミーのアドレス）・Proxied で作る
4. curl --head -i https://www.example.com/ で location ヘッダーと301を確かめる

本番の プロジェクト名.pages.dev は、独自ドメインを付けた後も同じ内容で公開され続けます。重複を残したくなければ、同じBulk Redirectsで pages.dev から独自ドメインへ転送します。一方、ブランチごとのプレビューURLには既定で X-Robots-Tag: noindex が付くとプレビューデプロイの公式ドキュメントにあるため、検索エンジン対策の追加作業は要りません。ただしプレビューURLは既定で誰でも閲覧できるので、公開前の内容を見せたくない場合は Settings の Enable access policy でCloudflare Accessをかけます。

SSL証明書がVerifyingのまま止まる原因

SSL証明書はドメインの登録に伴ってCloudflareが発行・更新します。Verifying から進まないとき、公式のトラブルシューティングが挙げる確認先は、HTTP検証の遮断・CAAレコード・ゾーンホールドの3つです。

1つ目はHTTP検証の遮断です。Pagesは /.well-known/acme-challenge/ 配下に実際にアクセスして検証するため、Cloudflare AccessやWorker、リダイレクトルールがこのパスを横取りしていると完了しません。次のコマンドで302やlocationヘッダーが返るなら、検証が終わるまでその設定を外します。

curl -s -o /dev/null -D - https://example.com/.well-known/acme-challenge/randomstring

2つ目はCAAレコードです。dig CAA example.com でCAAレコードが返り、その中にCloudflareが使う認証局（letsencrypt.org・pki.goog・ssl.com）が含まれていない場合だけ、これらを許可するCAAレコードを追加します。CAAレコードが1件も無ければ発行は制限されないので、追加は不要です。

3つ目はゾーンホールドです。他のアカウントからの同じゾーンの追加を防ぐゾーンホールドを有効にしていると、その配下のホスト名を独自ドメインとして追加できません。設定の間だけ解除し、登録が完了したら戻します。

商用利用の条件と無料プランで先に当たる上限

商用利用を禁じない規約とpages.devを本番URLにしない理由

Workers・Pages・D1・R2などに適用されるDeveloper Platformのサービス別規約（2026年9月28日更新）を確認した範囲では、無料プランでの商用利用を禁じる条項は見当たりません。Vercelの無料プラン（Hobby）が非商用の個人利用に限られているのとは対照的で、会社のサイトやLPをFreeプランで公開できます。Vercelとの条件の違いはVercelとCloudflare Pagesの違い：Next.jsの動かし方・料金の増え方・商用条件で選ぶ【2026年10月】で比べています。

独自ドメインでの公開は規約上の義務ではありません。ただ、商用で使うなら同じ規約の次の2つの条項を設計に反映し、本番URLは独自ドメインにするのが安全です。

• pages.devのサブドメイン名はCloudflareが変更しうる：規約は、workers.dev・pages.dev 上のプロジェクトのサブドメイン名を理由を問わず変更できると定めています。通知は「少なくとも1週間前の通知を試みる」という努力規定で、規約違反による変更はその対象外です。独自ドメインにはこの変更権が及びません。名刺や広告に pages.dev のURLを刷ると、変更時に差し替えられません。
• 他社名や紛らわしい語を含むプロジェクト名は禁止：違反と判断されると、アカウントやプロジェクトが即時に停止される場合があります。

コーポレートサイトをPagesで公開する場合、ホスティング費はかからなくても、問い合わせフォームの受け口・独自ドメインのメール・アクセス解析はそれぞれ別に用意します。サイトの設計からまとめて任せたい場合は、株式会社一創の企業サイト制作・コーポレートサイト制作でも対応しています。

Freeプランの上限値

Pagesで実際に止まるのは、料金より先に上限値です。Pagesの公式Limits（2026年9月5日更新）の値を抜き出します。

ビルドは20分でタイムアウトし、プロジェクト数はアカウントあたり100が上限です。サービスを使い始めて最初の48時間は、乱用対策で新規プロジェクトの作成数が制限され、48時間を過ぎると自動で解除されます。有料プランでファイル数の上限を10万に上げるには、環境変数 PAGES_WRANGLER_MAJOR_VERSION=4 を設定します。25 MiBを超える動画や配布ファイルは、公式も案内しているとおりR2に置いて配信します。R2の料金と使い方はCloudflare R2とは？料金・無料枠とS3互換の範囲、使い方を解説で整理しています。

Pages Functionsのリクエストは、Workersの無料枠（1日10万リクエスト・UTCの0時にリセット）をWorkersと共有します。静的ファイルへのリクエストはFunctionsを呼ばない限り数えられません。Workers側の料金体系はCloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方で扱っています。

Web Analyticsを有効にする手順と数字が入らない原因

Cloudflare Web Analyticsは、Cookieやローカルストレージを使わずにページビューとCore Web Vitalsを計測するアクセス解析です。Web Analyticsの公式手順では、Pagesプロジェクトならスニペットを自分で貼る必要はありません。

1. ダッシュボードの Workers & Pages で対象のPagesプロジェクトを選ぶ
2. Metrics を開き、Web Analytics の Enable を押す
3. 次のデプロイを1回走らせる（空コミットでも可）

スニペットは「次のデプロイ時」に自動で追加される仕様なので、有効化した後に再デプロイしたかを最初に確かめます。それでも入らない場合は、次の順に見ます。

• スニペットの有無：公開ページのHTMLを開き、Web Analyticsのビーコン用スクリプトが入っているかを見ます。公式は、自動挿入には正しいHTMLが必要で、<html> や <head> の無い断片だけのファイルには挿入できないと説明しています。
• 計測通信：開発者ツールのNetworkタブで、ビーコンの通信が送られているかを確かめます。広告・解析ブロッカーで遮断されていると記録されません。
• サイト数の上限：Cloudflareのプロキシを通していないサイトは、登録できるのが10件までです（プロキシ配下は無制限）。
• 計測範囲：計測するパスを絞る Rules はFreeで0件です。公式のLimitsは、上限0のプランではスニペットを全サブドメインに挿入すると説明しています。Rulesで絞るにはProの5件以上が要り、しかもRulesはCloudflareのプロキシ配下のサイトでしか使えません。自動挿入をやめてスニペットを手動で貼る方式なら、計測したいページだけに置けます。
• 計測方式の差：数えるのは、ブラウザでスニペットが実行され、計測通信が届いた訪問だけです。JavaScriptを実行しないクローラーやブロッカーで遮断された訪問は入らないため、エッジ側のリクエスト数とは別の指標として読みます。

D1をつないで動的にするときの課金の数え方

フォームの保存や一覧の出し分けが要るなら、SQLiteベースのサーバーレスDBであるD1をつなぎます。既存のPagesプロジェクトでは、Settings の Bindings で Add から D1 database を選び、変数名とデータベースを指定して再デプロイします。次の例は、バインディング名を DB とし、id・title・published 列を持つ posts テーブルが作成済みである前提です。Function側からはコンテキスト経由で参照します。

// functions/api/posts.js
export async function onRequest(context) {
  const { results, meta } = await context.env.DB
    .prepare("SELECT id, title FROM posts WHERE published = ?1 ORDER BY id LIMIT 20")
    .bind(1)
    .run();
  return Response.json({ results, rows_read: meta.rows_read });
}

課金で誤解されやすいのは「読み取った行数」の数え方です。D1の公式料金ページは、rows read をクエリがスキャンした行数と定義しています。5,000行のテーブルを全表走査すれば、返す行が2行でも5,000行の読み取りです。WHERE句で使う列にインデックスを張ると読み取りは減り、書き込みは索引の分だけ1行増えますが、公式はほぼすべてのケースで読み取り削減の効果が上回ると述べています。上の例のように meta.rows_read を返しておけば、テーブル設計を固める前に実測できます。

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

PagesのドキュメントはWorkersでの新規作成を勧めていますが、提供終了の告知はありません。CloudflareはPagesからWorkersへの移行ガイド（2026年10月12日更新）に互換表を載せ、静的アセットへのリクエストはWorkersでも無料、Pages FunctionsはWorkersと同じ料金と説明しています。移る理由はコストではなく機能です。

互換表で、PagesにはなくWorkersにだけある機能は次のとおりです。

• 開発・デプロイ：Cloudflare Viteプラグイン、段階的デプロイ、--remote での開発、ダッシュボードのQuick Editor
• 観測：Workers Logs、Logpush、Tail Workers、ソースマップ
• 実行・バインディング：Cron Triggers、Queueのコンシューマー、レート制限、Email Workers、画像リサイズ
• ルーティング：サブパスでのアセット配信、ルート単位の割り当て

逆にWorkersが「非対応」なのは、Cloudflareのゾーン外にある独自ドメインの1行だけです。移行ガイドも、Pagesと違ってWorkersはネームサーバーがCloudflare管理下にないドメインを一切サポートしないと注記しています。2026年8月の版では「対応予定」だったカスタムブランチエイリアスは、10月の版でWorkersでも対応済み（プレビューURLを独自ドメインで出す方式）に変わりました。

判断はこうなります。DNSをCloudflareに預けられる案件の新規開発は、Workersで始めてください。社内規程や既存のDNS運用でネームサーバーを動かせず、サブドメイン（www.example.com など）で公開する案件は、PagesとWorkersのうちPagesでしか対応できません。apexドメインはPagesでもネームサーバーの移管が必要なので、この例外には入りません。「新しいほうへ」と移した結果、独自ドメインが当てられなくなるのが典型的な失敗なので、移行を決める前にネームサーバーの権限を誰が持っているかを確認します。既存のPagesを移す場合は、設定ファイルの pages_build_output_dir を assets に書き換えるのが中心です。

{
  "name": "my-worker",
  "compatibility_date": "2026-10-19",
  "assets": {
    "directory": "./dist/client/",
    "not_found_handling": "404-page"
  }
}

この設定例は静的アセットの配信部分だけです。Pages FunctionsやD1を使っている場合は、Functionsのコードを main で指すWorkerに移し、バインディングも設定ファイルへ書き直す作業が別に要ります。また、Pagesは404.htmlの有無でSPAかどうかを自動判定していましたが、Workersでは not_found_handling に single-page-application か 404-page を明示します。前の章の実測で見た「未知URLが200」の挙動を、移行時に設定で選び直すことになります。

フレームワーク側も前提が変わっています。Cloudflare公式のPages向けRemixガイドは、Remixの作者が新規プロジェクトに推奨しておらず後継のReact Routerを使うべきだ、という案内だけになりました。npmでは react-router 8.5.0 が最新で、React Router向けの公式ガイドはWorkers側にあります。2026年10月1日に正式版になった remix 3.0.0 は、Remix v2とは別の設計のフレームワークで、v2アプリの移行先ではありません。React Router v8の書き方はReact Router v8の使い方｜meta・title設定と基本ルーティング、v7からの変更点で解説しています。

よくある質問

CloudflareのPagesの無料の枠は？

静的ファイルへのリクエストと転送量は無料・無制限です。Freeプランで先に当たるのは、月500回のビルド、1サイト20,000ファイル、1ファイル25 MiB、同時ビルド1本といった上限値です。Pages Functionsを使う場合は、Workersの無料枠である1日10万リクエストをWorkersと共有します。

Cloudflare Pagesはなぜ無料で使えるのですか？

料金の仕組みとして、静的ファイルの配信そのものが課金対象になっていないためです。費用が発生するのは、Workers Paidに入ってPages Functionsを無料枠を超えて使う場合（Workersと同じ従量課金）、ビルド枠や同時ビルド数を増やすために上位プランへ上げる場合、D1やR2などの組み合わせる製品を無料枠を超えて使う場合です。静的サイトだけならFreeプランで公開から運用まで完結します。

Cloudflare Pagesは安全ですか？

HTTPSは独自ドメインを含めて自動で有効になり、証明書の更新も不要です。注意したいのはプレビューURLで、既定では誰でも閲覧できます（検索エンジン向けには noindex が付きます）。公開前の内容を見せたくない場合は、プロジェクト設定の Enable access policy で閲覧者を絞ってください。Cloudflare自体の障害履歴とSLAの扱いはCloudflareの危険性は本当か：障害・SLA・情報漏えいの実態と設定点検の手順で整理しています。

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

2026年10月20日時点で、Pagesのドキュメントは「Available on all plans」と表示しており、提供終了の告知はありません。一方で同じページの冒頭には「Start new projects with Workers.」とあり、新規開発の推奨先はWorkersです。既存のPagesを急いで移す必要はありませんが、新しく作るものは、Cloudflareのゾーン外にあるドメインのサブドメインで公開する場合を除いてWorkersで始めるのが現在の流れです。

Cloudflare PagesでWordPressやPHPは動きますか？

動きません。ビルド環境ではPHPを使えますが、公開後に動くのは静的ファイルと、JavaScriptランタイム上のPages Functionsだけです。WordPressを使うなら、別サーバーのWordPressをヘッドレスCMSとして使い、REST APIから取得した内容を静的生成してPagesで配信する構成にします。この場合、プラグインに頼っていたフォームや検索は別の手段で作り直します。

関連記事

• Cloudflare Workersとは？料金・無料枠・Workers Paidの中身と対応言語・使い方
• VercelとCloudflare Pagesの違い：Next.jsの動かし方・料金の増え方・商用条件で選ぶ【2026年10月】
• Cloudflareにドメインを追加する手順：ネームサーバー変更とDNS移行をAPIとdigで確かめる【2026年9月版】
• CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説
• Cloudflare R2とは？料金・無料枠とS3互換の範囲、使い方を解説