目次

• この記事の想定読者
• なぜGitHub Pagesから移行するのか
• GitHub PagesとCloudflare Pagesの比較
• 移行前に確認すること
• 1. Workers & Pagesから新しいアプリケーションを作成する
• 2. GitHubリポジトリを接続する
• 3. Hugoのビルド設定を入力する
• 4. pages.devで表示を確認する
• 5. カスタムドメインを追加する
• 6. GitHub Pagesの設定を削除する
• 7. GitHubリポジトリをPrivateへ変更する
• 8. pages.devへのアクセスを独自ドメインへ転送する
• さいごに

この記事の想定読者

• ブログのソースをGitHubリポジトリに置いている人
• Hugoで作成したブログや静的サイトをGitHub Pagesで公開している人
• ブログのホスティング先をGitHub PagesとCloudflare Pagesで迷っている人
• ブログのホスティング先をGitHub PagesからCloudflare Pagesに移行したい人
• (独自ドメインを持っている人で)無料でブログを公開したい人
• 独自ドメインをCloudflareで取得し、Cloudflare DNSで管理している人

移行前はGitHubがソース管理・ビルド・公開をまとめて担う。移行後はGitHubをPrivateなソース管理に限定し、Cloudflare PagesがHugoのビルドと公開を担う。 公開する独自ドメインは変えないため、読者がアクセスするURLはこれまでどおり維持できる。

この記事の操作画面や料金・プランは変わることがある。実行時は公式ドキュメントも確認してほしい。

なぜGitHub Pagesから移行するのか

GitHub Pagesは、GitHubで管理している静的サイトを手軽に公開できる。独自ドメインやHTTPSも使えるため、Hugoブログの公開先として十分便利だ。

ただ、ブログのリポジトリには記事だけではなく、Hugoの設定、テーマ、レイアウト、ビルド設定なども入る。

そして、無料でGitHub Pagesを利用するにはリポジトリをPublicにしておく必要がある。 ついうっかり秘密の画像等がソースリポジトリに紛れ込んでしまったらジ・エンドである。

そこで、無料でPrivateリポジトリからページを公開してくれるホスティング先を見つけた。Cloudflare Pagesである。

GitHub PagesとCloudflare Pagesの比較

以下の上限・料金に関する情報は2026年10月2日時点のもの。最新情報はGitHub Pagesの制限とCloudflare Pagesの制限を確認してほしい。

GitHubでソースを管理して、GitHub Pagesでビルド・公開の構成は単純で分かりやすい。 一方、Privateリポジトリから自動デプロイしたい場合はCloudflare Pagesが良い。 私は上記の理由からPrivateリポジトリを利用可能なCloudflare Pagesに移行することにした。 まぁPrivateにしてもstatic/ やページバンドルに紛れていたらアウトなんですけどね。。

移行前に確認すること

移行作業では、GitHub Pagesを先に止めない。まずCloudflare Pages上でサイトを公開し、pages.devのURLで表示を確認してから独自ドメインを切り替える。この順番なら、ビルドやDNSの設定に失敗しても、公開中のサイトを維持したまま修正できる。

作業前に、次の内容を控えておく。

• GitHub Pagesで公開しているブランチとデプロイ方法
• Hugoのバージョン、ビルドコマンド、出力先ディレクトリ

このあと進める順番は以下のとおりである。

1. Workers & Pagesから新しいアプリケーションを作成する
2. GitHubリポジトリを接続する
3. Hugoのビルド設定を入力する
4. pages.devで表示を確認する
5. カスタムドメインを追加する
6. GitHub Pagesの設定を削除する
7. GitHubリポジトリをPrivateへ変更する
8. pages.devへのアクセスを独自ドメインへ転送する

Cloudflare Pagesのプロジェクトを作成する

1. Workers & Pagesから新しいアプリケーションを作成する

Cloudflareのダッシュボードで「Workers & Pages」を開き、右上の「アプリケーションを作成する」を選ぶ。 その後、「始める」ボタンを押す。

2. GitHubリポジトリを接続する

次に、「既存のGitリポジトリをインポートする」を選ぶ。

GitHubアカウントにログインし対象リポジトリを選び、「セットアップの開始」を押す。 GitHubの認可時は、Cloudflare Workers & Pages GitHub Appにこのブログのリポジトリだけを許可しておくと管理しやすい。

Hugoのビルド設定

3. Hugoのビルド設定を入力する

一般的なHugoサイトなら、設定値は次のとおりになる。

このサイトでは、画像のとおりビルドコマンドをhugo --gc --minifyに設定した。--gcは不要になったキャッシュを掃除し、--minifyは生成するHTML・CSS・JavaScriptを圧縮する。出力先はpublicにする。CloudflareのHugoガイドもあわせて確認してほしい。

使っているHugoのバージョンを固定したい場合は、プロジェクトの環境変数にHUGO_VERSIONを追加する。ローカルとCIでバージョンがずれるとテーマやMarkdownの処理結果が変わることがあるため、再現性を優先するなら設定しておくと安心だ。本番環境とPreview環境の設定は分かれているため、Preview Deploymentも使う場合はPreview側にも同じHUGO_VERSIONを設定する。

最初のデプロイと確認

4. pages.devで表示を確認する

デプロイを選ぶと、Cloudflare Pagesがリポジトリを取得し、Hugoを実行してpublic/を配信する。完了すると以下の画面になりhttps://<project>.pages.dev形式のURLが発行される。

デプロイ成功画面が表示されたら、発行されたpages.devのURLを開いて確認する。ここではまだ独自ドメインを切り替えない。

独自ドメインに切り替える前に、このURLで適切に表示されていることを確認した。

独自ドメインをCloudflare Pagesへ切り替える

5. カスタムドメインを追加する

pages.devで問題がなければ、Cloudflare Pagesプロジェクトの「Custom domains」から独自ドメインを追加する。

プロジェクト画面で「カスタムドメイン」タブを開く。次に「カスタムドメインを設定」を選ぶ。

登録済みの独自ドメインを入力して「続行」を選ぶ。

DNSをCloudflareで管理している場合は、表示されたDNSレコードを確認して「ドメインをアクティブにする」を選ぶ。

DNSをCloudflareで管理しているドメインなら、案内に従ってCloudflare Pages用のDNSレコードを設定する。

設定直後はステータスが「初期化中」になる。DNSと証明書の処理が完了するまで待つ。画面上は反映まで最大48時間かかる場合があると案内されるが、筆者の環境では1分程度待ってページをリロードするとステータスが「アクティブ」になった。SSLが有効になれば設定は完了だ。表示や所要時間は変わるため、最新の手順はCloudflareのカスタムドメインガイドも確認してほしい。

切替が完了したらhttps://独自ドメイン/でページが表示されるようになっているのではないだろうか。

GitHub Pagesの設定を削除する

6. GitHub Pagesの設定を削除する

Cloudflare Pagesの独自ドメインで正しく表示できることを確認したら、古いGitHub Pages用の設定を削除する。GitHub Pagesを先に止めたりDNSを削除したりすると、一時的にサイトへアクセスできなくなるため、この作業はCloudflare Pagesでの公開確認後に行う。

6-1. 古いDNSレコードを削除する

DNS管理画面で、GitHub Pagesへ向いているレコードが残っていないか確認する。特に次のレコードは見落としやすい。

• 185.199.108.153 などGitHub PagesのIPアドレスを向いたAレコード
• <ユーザー名>.github.io を向いたCNAMEレコード
• wwwなどサブドメインに残ったGitHub Pages向けのA/CNAMEレコード

Cloudflare Pages用のレコードが正しく動いていることを確認したうえで、GitHub Pages用の不要なレコードだけを削除する。Cloudflare Pagesのレコードは削除しないよう、宛先を一つずつ見比べる。

6-2. GitHub ActionsのGitHub Pagesワークフローを削除する

GitHub ActionsでGitHub Pagesをビルド・公開していた場合は、.github/workflows/ にあるGitHub Pages用ワークフローも不要になる。残したままPrivateリポジトリへ変更すると、pushごとに失敗したワークフローが走り、Actionsの利用枠も消費する。

GitHub Pages用だと確認できたワークフローだけを削除してコミットする。ほかのCI用ワークフローを誤って消さないよう注意する。

git rm .github/workflows/<github-pages用ワークフロー>.yml
git commit -m "Remove GitHub Pages workflow"
git push

リポジトリをPrivateへ変更する

7. GitHubリポジトリをPrivateへ変更する

独自ドメインで正しくページが表示できていることを確認できたら、GitHubのリポジトリ設定からVisibilityをPrivateへ変更する。

Freeプランの同志達はPrivateリポジトリではGitHub Pagesが使えないと思うが、念のためGitHub PagesがOFFになっていることも確認する。

変更後は、記事などを実際に少し編集してからpushし、Cloudflare Pagesのデプロイ一覧で新しいビルドが走ることを確認する。秘密情報や関係のないファイルをうっかり追加しないため、まずgit statusで変更内容を確認する。

git status
# 編集したファイルだけを指定して追加する
git add content/blog/<編集した記事>/index.md
git commit -m "Verify Cloudflare Pages deployment"
git push

Cloudflare Pagesで新しいデプロイが成功し、編集内容がサイトに反映されていれば、Private化後の自動デプロイも正常に動作している。

pages.devから独自ドメインへリダイレクトする

8. pages.devへのアクセスを独自ドメインへ転送する

Cloudflare Pagesでは、独自ドメインを設定したあとも<プロジェクト名>.pages.devのURLでサイトへアクセスできてしまう。検索エンジンや読者に複数のURLを使わせないため、pages.devへのアクセスを独自ドメインへリダイレクトしたほうがセクシーだよな。

ここではCloudflareの「一括リダイレクト」を使い、document-6eg.pages.devからhttps://mitz17.comへ転送する設定を例にする。自分のプロジェクト名と独自ドメインへ読み替えてほしい。皆様のサイトがmitz17.comにリダイレクトされないように注意されたい。(別にええけど)

8-1. 一括リダイレクトリストを作成する

Cloudflareのアカウント画面で「配信とパフォーマンス > 一括リダイレクト」を開く。右上の「作成」を選ぶ。

リスト名を入力する。ここではpages_dev_redirectとした。名前は管理しやすい任意のものでよい。入力後、「次へ」を選ぶ。

8-2. pages.devから独自ドメインへの転送先を登録する

「手動でURLリダイレクトを追加します」を開き、次の内容を入力する。 ソースとターゲットURLは各々の環境に応じて読み替えてほしい。

画像のように、サブドメインも転送対象にする場合は「サブドメインを含める」にチェックを入れる。 他にも好きなところにチェックを入れてもOKである。
入力後、「次へ」を選ぶ。

8-3. リダイレクトルールを有効にする

リストを作成しただけではリダイレクトは動かない。完了画面で「リダイレクトルールに進む」を選び、作成したリストをルールへ紐付ける。

ルール名を入力し、リダイレクトリストとして先ほど作成したpages_dev_redirectを選ぶ。最後に「保存してデプロイする」を選ぶ。

設定後は、https://document-6eg.pages.devへアクセスし、https://mitz17.comへ301リダイレクトされることを確認する。ブラウザのキャッシュが残ることがあるため、シークレットウィンドウやcurl -Iで確認すると確実だ。

さいごに

皆様のQOBLが向上することを切に願う。