Cloudflare PagesとAstroで高速な静的Webサイトを構築・公開する実践手順と初期設定
Webサイトや技術ブログを新規構築する際、「表示速度の速さ」「運用コストの低さ」「メンテナンスのしやすさ」の3つを高い水準で満たす構成として、Astro(静的サイトジェネレーター)× Cloudflare Pages の組み合わせが非常に優れています。
当サイト(EGPL Tech Note / egpl.net)でも実際にこのアーキテクチャを採用しており、HTMLを中心とした軽量なビルド出力と Cloudflare のグローバルエッジネットワークを組み合わせることで、初回表示(TTFB・LCP)を極限まで短縮しています。
本記事では、Astro プロジェクトの作成から Cloudflare Pages へのデプロイ、そして本番運用でつまずきやすい Node.js バージョン指定や末尾スラッシュ(Trailing Slash)の挙動統一まで、実際に検証した手順を体系的に解説します。
1. なぜ「Astro × Cloudflare Pages」なのか?アーキテクチャの利点
従来のクライアントサイドレンダリング(CSR)主体のSPAフレームワークや、データベースを毎回参照する動的CMSと比較した場合、Astro と Cloudflare Pages の組み合わせには明確な技術的メリットがあります。
| 比較項目 | 動的CMS(WordPress等) | SPA / 従来型SSR構成 | Astro (SSG) + Cloudflare Pages |
|---|---|---|---|
| 配信時のランタイム負荷 | PHP + DBクエリが都度発生(キャッシュ未命中時) | JSバンドルのダウンロード・水和(Hydration)が必要 | ビルド済み静的HTMLをエッジから直接配信(原則0KB JS) |
| TTFB(最初の1バイト到達時間) | 150ms〜600ms前後 | 100ms〜300ms前後 | 20ms〜50ms前後(最寄りのエッジ拠点から応答) |
| セキュリティリスク | 管理画面・プラグインの脆弱性対応が必須 | 依存パッケージとAPIエンドポイントの保護が必要 | 攻撃対象領域(Attack Surface)が極めて小さい |
| インフラ維持コスト | レンタルサーバー代(月額1,000円〜) | コンピュート課金が発生しやすい | 静的アセットの帯域幅が無制限・無料枠で十分運用可能 |
特に技術ドキュメントやブログのように「読みやすさ」と「検索エンジンからのクローラビリティ」が重視されるサイトでは、不要なクライアントサイド JavaScript を削ぎ落とす Astro の Islands Architecture(アイランド・アーキテクチャ) が大きな効果を発揮します。
2. Astro プロジェクトの初期構築と本番向け設定
まずはローカル環境で Astro プロジェクトを初期化し、検索エンジン最適化(SEO)に不可欠なサイトマップ自動生成パッケージ @astrojs/sitemap を導入します。
2.1 プロジェクトの作成とパッケージ導入
Node.js(推奨は LTS バージョン 20 または 22 以降)がインストールされた環境で、以下のコマンドを実行します。
# Astro プロジェクトの初期化(Minimal テンプレート)
npm create astro@latest my-tech-site -- --template minimal --typescript strict
cd my-tech-site
# サイトマップ自動生成インテグレーションの追加
npx astro add sitemap
2.2 astro.config.mjs で必ず設定すべき項目
初期状態のままだと、生成される sitemap-index.xml や正規URL(Canonical URL)の基準ドメインが未定義になるほか、URL末尾のスラッシュ有無が混在して重複ページ判定を受ける原因になります。
astro.config.mjs を開き、以下の3点を明示的に設定します。
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
// 1. 本番ドメインを正確に指定(Canonical URL と Sitemap 生成に使用)
site: 'https://egpl.net',
// 2. 末尾スラッシュの挙動を統一(Cloudflare Pages の標準挙動と合わせる)
trailingSlash: 'always',
// 3. 404ページなどをサイトマップから除外
integrations: [
sitemap({
filter: (page) => !page.includes('/404'),
}),
],
// 4. シンタックスハイライト(Shiki)の折り返し設定
markdown: {
shikiConfig: {
theme: 'github-dark',
wrap: true,
},
},
});
trailingSlash: 'always' を推奨する理由
Cloudflare Pages では、src/pages/about.astro または dist/about/index.html として出力されたページに対し、デフォルトで /about/(末尾スラッシュあり)へ正規化する挙動をとります。Astro 側でも trailingSlash: 'always' を指定しておくことで、内部リンク・Canonical タグ・サイトマップ内のURL表記がすべて /about/ に統一され、不要な 308 リダイレクトを完全に防ぐことができます。
3. Cloudflare Pages へのデプロイ手順(2つのアプローチ)
Cloudflare Pages へデプロイする方法には、大きく分けて 「GitHub / GitLab リポジトリ連携(CI/CD自動ビルド)」 と 「Wrangler CLI によるダイレクトアップロード」 の2通りがあります。
方法A:GitHub リポジトリ連携による自動デプロイ(推奨)
記事を Markdown で書いて git push するだけで自動的に本番反映されるため、通常のサイト運用ではこちらが最も効率的です。
- Cloudflare ダッシュボードにログインし、左メニューの 「Workers & Pages」 > 「作成」 > 「Pages」 タブを選択します。
- 「Git に接続」 を選択し、対象の GitHub リポジトリを認可・選択します。
- ビルドとデプロイの設定 で以下の値を入力します。
| 設定項目 | 設定値 | 備考 |
|---|---|---|
| フレームワーク プリセット | Astro | 自動でビルドコマンドが入力されます |
| ビルド コマンド | npm run build | package.json の scripts に準拠 |
| ビルド出力ディレクトリ | dist | Astro の標準出力先 |
環境変数 (NODE_VERSION) | 22(または 20) | 古い Node バージョンでのビルド失敗を防止 |
ポイント:環境変数
NODE_VERSIONの明示指定
Cloudflare Pages のビルドイメージが使用するデフォルトの Node.js バージョンが古い場合、Astro v5 系のビルド時にモジュール解決エラーが出ることがあります。環境変数にNODE_VERSION = 22を追加するか、プロジェクトルートに.node-versionファイルを置いておくと確実に回避できます。
方法B:Wrangler CLI を使ったローカルからの直接デプロイ
リポジトリ連携を行う前に手元のビルド結果(dist/)を素早く本番・プレビュー環境に反映したい場合は、Cloudflare 公式 CLI である wrangler を使用します。
# 1. Astro の本番ビルドを実行(dist/ ディレクトリに静的ファイルと sitemap を生成)
npm run build
# 2. Cloudflare アカウントへログイン(初回のみブラウザが開きます)
npx wrangler login
# 3. Pages プロジェクトの作成(初回のみ)
npx wrangler pages project create egpl-net --production-branch main
# 4. dist ディレクトリを直接デプロイ
npx wrangler pages deploy dist --project-name=egpl-net --branch=main
このコマンドを実行すると、数秒〜十数秒で dist/ 内の全ファイルが Cloudflare のエッジへアップロードされ、https://<プロジェクト名>.pages.dev および設定済みのカスタムドメインへ即時反映されます。
4. カスタムドメイン接続と pages.dev の重複インデックス防止策
Cloudflare で取得・管理している独自ドメイン(例:egpl.net)を Pages プロジェクトに紐付ける手順と、SEO 上非常に重要な注意点を解説します。
4.1 カスタムドメインの割り当て手順
- Cloudflare Pages の対象プロジェクト画面から 「カスタム ドメイン」 タブを開きます。
- 「カスタム ドメインの設定」 をクリックし、
egpl.netを入力します。 - 同一アカウント内の Cloudflare DNS でドメインを管理している場合、必要な
CNAMEレコードが自動提案されるため、「ドメインを有効にする」 を押すだけで数分以内に SSL 証明書の発行と名前解決が完了します。 - 同様に
www.egpl.netからegpl.netへの正規化(リダイレクト)も設定しておきます。
4.2 *.pages.dev が Google に重複インデックスされるのを防ぐ
Cloudflare Pages を作成すると、初期状態で https://xxxx.pages.dev というサブドメインも公開アクセス可能な状態になります。このまま放置すると、検索エンジンが本番ドメイン(egpl.net)と pages.dev の両方をクロールしてしまい、重複コンテンツと見なされるリスクがあります。
これを防ぐには、public/_headers ファイルを作成し、pages.dev ドメイン経由でアクセスされた場合やプレビュー環境に対して X-Robots-Tag: noindex を返すか、Cloudflare Access / Bulk Redirects で本番ドメインへリダイレクトさせる設計が有効です。
また、各ページの <head> 内に必ず本番ドメインを指す <link rel="canonical" href="https://egpl.net/..." /> を出力しておくことで、検索エンジンに対して正規URLを明確に伝えることができます。
5. デプロイ後に必ず確認すべき5つのチェックリスト
サイトを公開したら、以下の5項目をブラウザおよび curl コマンドで確認しましょう。
- HTTPS 通信とステータスコードの確認
curl -I https://egpl.net/HTTP/2 200(またはHTTP/3 200)が返り、server: cloudflareヘッダーが付与されていることを確認します。 - サイトマップの出力確認
https://egpl.net/sitemap-index.xmlおよびhttps://egpl.net/sitemap-0.xmlにアクセスし、全記事のURLがhttps://egpl.net/...で出力されているか確認します。 robots.txtの疎通確認
https://egpl.net/robots.txtにアクセスし、Sitemap: https://egpl.net/sitemap-index.xmlが正しく記載されているか確認します。- 存在しないURLへのアクセス(404ページ)確認
https://egpl.net/non-existent-page/にアクセスした際、用意した404.astroの内容が HTTP ステータス404とともに表示されるか確認します。 - モバイル表示での横スクロール(レイアウト崩れ)チェック
スマートフォン幅(375px)で記事内のコードブロックや表(Table)を閲覧した際、画面全体が横に溢れずブロック単位で横スクロールできるかを確認します。
まとめ
Astro と Cloudflare Pages を組み合わせることで、サーバー管理の手間をゼロにしつつ、Core Web Vitals で最高評価を獲得できる高速・高信頼なWebサイトを最短で構築できます。
特に最初は astro.config.mjs の site と trailingSlash の統一、そして Canonical URL と Sitemap の正確な出力 を固めておくことが、公開後のスムーズなインデックス登録とサイト評価向上への近道となります。