Webページは、ローカル環境で見た目が完成しただけでは納品・公開完了ではありません。

実際の公開では、どの差分を本番へ入れるか確認する、Preview環境で動作を見る、品質チェックをする、本番公開後にもう一度確認するという工程があります。

この記事では、GitHubとCloudflare PagesのようなGit連携型ホスティングを例に、Webサイトを安全に公開する流れを整理します。

情報の基準日：2026年8月12日
GitHubやCloudflare Pages、Chrome Lighthouseの仕様は更新されることがあります。最新情報はGitHub公式Pull Requestドキュメント、Cloudflare Pages Git integration、Cloudflare Pages Preview Deployments、Chrome Lighthouse公式を確認してください。

先に結論：本番公開を「最後の1クリック」にしない

安全な公開フローは次のように分けます。

  1. 作業branchで変更する
  2. test / buildを実行する
  3. Pull Requestを作る
  4. Preview Deploymentを確認する
  5. PC / SP / 動作をQAする
  6. Lighthouse等で追加確認する
  7. 差分をレビューする
  8. production branchへmergeする
  9. 本番deployを確認する
  10. 本番URLで再確認する

重要なのは、Previewで確認したあとに本番へ進むことです。

GitHub Pull Requestを使う理由

GitHub公式ではPull Requestを、あるbranchの変更を別branchへ統合する前に提案・議論・レビューする仕組みとして案内しています。

本番branchへ直接pushするより、

  • 変更ファイル
  • commit
  • diff
  • CI結果
  • レビュー内容

を一か所で確認できます。

一人で運用する小規模サイトでも、「何を本番へ入れようとしているか」を確認する場所として使えます。

Webサイトを公開する簡単な使い方【2026年8月時点】

Step 1：production branchを確認する

最初に、どのbranchが本番か確認します。

例：

  • main
  • master
  • production

Cloudflare PagesのGit integrationではProduction branchを設定でき、それ以外のbranchをPreviewとして使える構成があります。

思い込みでbranchを選ばず、プロジェクト設定を確認します。

Step 2：作業branchを作る

変更内容に応じてbranchを分けます。

例：

feat/service-page
fix/mobile-header

別の修正を同じbranchへ大量に混ぜると、差分確認や切り戻しが難しくなります。

Step 3：ローカルでtest / buildを通す

プロジェクトにコマンドがあるなら、Pull Request前に実行します。

例：

npm test
npm run lint
npm run build

すべてのプロジェクトに同じコマンドがあるわけではありません。READMEやpackage.jsonを確認してください。

Step 4：不要な差分がないか確認する

commit前に、

  • debug用コード
  • 仮画像
  • 個人用設定
  • 秘密情報
  • 自動生成された不要ファイル

が混ざっていないか確認します。

API keyやpasswordをソースコードへ直接入れないことも重要です。

Step 5：Pull Requestを作る

Pull Requestの説明には、少なくとも次を書くと確認しやすくなります。

  • 何を変えたか
  • なぜ変えたか
  • 確認方法
  • 影響範囲
  • スクリーンショットやPreview URL

GitHub公式ではPull Requestをbranch間の変更提案として作成し、レビュー後にmergeする流れが案内されています。

Step 6：Preview Deploymentを確認する

Cloudflare Pagesでは、Git連携時にproduction branch以外のbranchからPreview Deploymentを作ることができます。

Pull Requestから固有のPreview URLが作られる構成なら、そのURLを確認用に使えます。

Previewでは、ローカルと違って、

  • build後のassets
  • 実際のURL path
  • 環境変数
  • routing

など本番に近い条件を確認できます。

Step 7：PC・SP・中間幅で見る

Preview URLで最低限、

  • Desktop
  • Smartphone
  • Tablet / 中間幅

を確認します。

チェックするのは、

  • 横スクロール
  • 文字切れ
  • 画像比率
  • sticky / fixed UI
  • menu
  • card grid
  • table
  • button

です。

DevToolsのdevice emulationだけでなく、可能ならスマートフォン実機でも確認します。

Step 8：主要導線を実際に操作する

見た目だけでなく、

  • navigation
  • CTA
  • anchor link
  • accordion
  • modal
  • form
  • external link

を押します。

フォームがある場合は、本番へ送信してよいPreview環境なのか確認してください。

実データを送ってはいけない場合はtest用の方法を使います。

Step 9：Lighthouseを実行する

Chrome公式のLighthouseは、Performance、Accessibility、Best Practices、SEOなどを監査できます。

Chrome DevTools、PageSpeed Insights、command line等から実行できます。

重要なのは100点を取ること自体を目的にしないことです。

失敗したauditを見て、

  • 画像が大きすぎないか
  • labelが不足していないか
  • contrast問題がないか
  • title等が適切か
  • 不要なJavaScriptが重くないか

など改善候補を確認します。

Step 10：Lighthouseの数値は条件をそろえて比較する

Chrome公式でもPerformance scoreは、テスト環境や端末、network、拡張機能などの条件で変動し得ると説明されています。

1回の数字だけで良し悪しを断定せず、同じ条件で変更前後を比較します。

Step 11：アクセシビリティを目視でも確認する

自動監査だけではすべてを確認できません。

例えば、

  • Tabキーで操作できるか
  • focusが見えるか
  • 見出し順が不自然でないか
  • link textだけで目的が分かるか
  • 画像の意味が伝わるか

などを確認します。

Step 12：最終diffを確認する

merge直前にPull Requestの変更ファイルをもう一度見ます。

確認するのは、

  • 予定外ファイル
  • config変更
  • package変更
  • lock file
  • environment設定
  • 削除ファイル

です。

「Previewが見えたからOK」ではなく、何をmergeするかを確認します。

Step 13：productionへmergeする

CI・Preview・レビューが通ってからproduction branchへmergeします。

Cloudflare PagesのGit integrationでは、production branchへの変更を自動build / deployする構成ができます。

チームによってはmerge後に別の承認やdeploy操作が必要です。プロジェクトルールを優先してください。

Step 14：deploy statusを確認する

mergeしただけで終わらず、deployが成功したか確認します。

  • build failure
  • environment variable不足
  • dependency error
  • routing error

などで本番更新に失敗する場合があります。

Step 15：本番URLを開いて確認する

最後に本番URLで、

  • CSS
  • images
  • JavaScript
  • links
  • forms
  • title
  • description
  • canonical等の必要設定

を確認します。

Previewと本番で環境変数やdomainが違う場合、本番だけ問題が出ることがあります。

公開前チェックリスト

Git / Pull Request

  • 作業branchが正しい
  • productionへ直接pushしていない
  • 不要差分なし
  • secretなし
  • CI成功

Preview

  • PC表示
  • SP表示
  • 中間幅
  • 主要リンク
  • 主要UI
  • 404なし
  • console errorなし

品質

  • Lighthouse確認
  • alt / label等の基本確認
  • title / description
  • 画像サイズ
  • フォント

本番

  • deploy成功
  • production URL確認
  • domain / HTTPS
  • links / form
  • assets

Previewで確認できないものを整理する

Previewと本番は完全に同じではない場合があります。

例えば、

  • production専用API
  • domain依存処理
  • analytics
  • OAuth callback
  • payment
  • production database

などです。

その場合は、本番反映後の確認項目をあらかじめ分けておきます。

問題が出たときは「直す」より先に影響を確認する

公開後に問題が見つかった場合は、焦って別の修正を重ねる前に、

  • 何が壊れたか
  • 全ページか一部か
  • 直前commitとの関係
  • rollback可能か

を確認します。

重大な障害では、追加修正より安全なrollbackのほうが早い場合があります。

Figma実装から公開までつなげる

デザインカンプから作っている場合は、FigmaデザインからHTML/CSSへ実装する実務レシピで実装を終えてから、この公開フローへ進むと一連になります。

Webページの基礎から確認したい場合はHTML・CSS・JavaScriptでWebページを1枚作る方法へ戻れます。

実際のクライアント案件ではWeb制作案件の受注後フローと組み合わせ、仕様確認→実装→Preview→納品まで通してください。

まとめ

Webサイトの公開は、buildしてURLが出れば完了ではありません。

作業branch → test/build → Pull Request → Preview → QA → Lighthouse → merge → deploy → 本番確認を固定すると、公開時の見落としを減らせます。

小規模な副業案件でも、この流れを一度作っておくと、次の案件で同じ確認手順を再利用できます。