VS Codeで変更したのにサイトに反映されない原因｜保存・GitHub・公開を順に確認

VS Codeで文章を変えたのに、ブラウザーでは前のまま。何度も更新しているうちに、「保存できていない？公開の失敗？」と分からなくなりますよね。

まず、編集したファイルがどこまで届いているかを確かめます。PCへの保存と、インターネットの公開先への反映は、別の工程です。

このサイト制作でも、コマンドが見つからない問題や開発サーバーの起動エラー、公開用の操作が進まない問題がありました。症状が似ていても、止まる場所によって直し方が変わります。この記事はAstroとGitHub連携のCloudflare Pagesを主な例に、切り分ける順番を説明します。

まずアドレス欄を見て、何を開いているか確認する

URLの例	見ているもの
`file:///C:/study/index.html`	PC内のファイルを直接開いたページ
`http://localhost:4321/`	PCで起動した開発サーバーのページ
`https://example.pages.dev/`	Cloudflare Pagesの公開サイト
`https://account.github.io/project/`	GitHub Pagesの公開サイト

localhostは基本的に自分のPCを指す名前です。開発サーバーは、編集中のサイトを確認するためにPCで動かす仕組みです。

例えば公開サイトを見ながらPCのファイルを保存しても、それだけでは公開先へ届きません。先にローカルで確認し、次に公開の工程を追います。localhostで動いたURLを送っても、相手が自分のPCの同じ画面を見られるわけではありません。

保存したファイルと、開いたプロジェクトをそろえる

Windowsなら、まず対象ファイルでCtrl + Sを押します。VS Codeのタブに未保存を示す丸い印が残っていないか見てください。自動保存も設定できますが、アプリが前の編集を覚えていることと、ファイルへの保存は別です。VS Code公式：保存と自動保存

次にパス全体を確認します。Desktop\my-siteとDocuments\my-siteを両方持っていると、別のコピーを編集している可能性があります。

PowerShellのターミナルで、現在地を調べます。

Get-Location

その場所と、VS Codeで開いたフォルダーを比べます。Git管理している場合は、git rev-parse --show-toplevelでもリポジトリの一番上を確認できます。エラーになる場合は、not a git repositoryの確認手順を使ってください。

表示する文章を一時的に分かりやすいものへ変え、どこまで届くか目印にするのも有効です。確認後に元へ戻せる小さな変更にします。

ローカルで変わらないなら、開発サーバーを確認する

Astroのソースである.astroファイルは、HTMLのようにダブルクリックするだけでは確認できません。プロジェクトの開発サーバーを起動し、ターミナルに表示されたURLを開きます。

既存プロジェクトでは、使っているパッケージ管理ツールとpackage.jsonの手順に合わせます。devという実行設定があるnpmのプロジェクトなら、例えば次です。

npm run dev

このサイトのようにpnpmを使うプロジェクトならpnpm devです。WindowsのPowerShellでnpm.ps1などの実行制限に止められる場合は、インストール済みのnpm.cmd run devやpnpm.cmd devで実行できる場合があります。npm自体が見つからない問題とは区別してください。

Astroの開発サーバーは変更を監視し、通常は保存すると表示を更新します。URLのポート番号は空き状況などで変わるため、4321を決め打ちせず、今回起動した端末の表示を読みます。Astro公式：開発とビルド

起動時にエラーで終了しているなら、ブラウザーの更新より先にそのエラーを直します。ターミナルを閉じてサーバーが止まっている場合も、起動し直します。

また、Astroでトップページを直すなら通常はsrc/pages/index.astroなどの元ファイルを編集します。ビルドで作るdist内だけを直すと、次のビルドで上書きされます。

GitHubへ変更が届いているか確認する

GitHub連携で公開している場合、ローカルで表示できた次の確認先はGitHubです。

git status
git branch --show-current
git log --oneline -3

コミットは編集を履歴へ記録する操作、pushはその履歴をGitHubなどの接続先へ送る操作です。保存しただけのファイルは、pushだけでは届きません。

コミットとpushを済ませたら、GitHubの対象ブランチで、変更した文章と最新コミットを開きます。具体的な記録・送信方法は、pushとpullの基本を参照してください。

Everything up-to-dateは「今回送れる履歴の更新がない」という意味で、編集中の内容まで公開できた保証ではありません。git statusに変更が残っていないか、違うブランチへ送っていないか確認します。

送信がnon-fast-forwardで拒否された場合は、履歴を消さずにpushを直す方法へ。強制送信して表示だけ直そうとしないでください。

Cloudflare Pagesで、そのコミットが本番公開されたか確認する

GitHubが新しくても、公開用ファイルを作って配置する工程が残っています。ビルドは公開用ファイルの作成、デプロイは公開先への配置です。

CloudflareのWorkers & Pagesから対象プロジェクトを開き、デプロイ一覧で次を見ます。

今送ったコミットを使うデプロイがあるか。
対象が本番環境か、確認用のプレビュー環境か。
処理が成功しているか。失敗ならビルドログの最初の具体的なエラーは何か。

Git連携では、設定したブランチなどの条件に応じてデプロイが動きます。本番用ブランチ以外の変更がプレビューだけに反映されることもあります。自動デプロイの停止設定や対象パスの設定も確認します。Cloudflare公式：Git連携、ブランチごとのデプロイ制御

成功したデプロイに紐づくURLを開き、変更した文章を探します。ビルドが失敗したときは、以前の成功したサイトが表示され続ける場合があるため、「サイトが開けるから今回も成功」とは判断できません。

GitHub Pagesを使っている場合は、Cloudflareの画面ではなくGitHubのActionsとSettings → Pagesを確認します。公開元がブランチなのかActionsの処理なのかも、プロジェクトの設定に合わせます。GitHub公式：公開元の設定

最後にブラウザーのキャッシュを確認する

正しいコミットの本番デプロイが成功し、URLも合っている。それでも古いときに、保存済みデータの再利用であるキャッシュを疑います。

まずWindowsのChromeやEdgeならCtrl + Shift + Rで再読み込みし、別のブラウザーでも同じ公開URLを確認します。開発者ツールのNetworkで返されたHTMLの内容を見ると、文章自体が古いのか、CSSなど見た目だけが古いのかを分けられます。

キャッシュはブラウザー以外にもあります。別端末でも同じなら、公開先・独自ドメインの向き先・配信側のキャッシュ設定を調べます。PWAのService Workerを使うサイトでは、その更新処理が関係する場合もあります。最初からすべての閲覧データを消す必要はありません。

練習：更新が止まっている場所を判断する

ローカルの開発サーバーでは新しい見出しが表示されています。GitHubの同じファイルを見ると古いままです。公開サイトも古いまま。この場合、先に確認するのはキャッシュでしょうか、Gitの記録・送信でしょうか。

模範解答

Gitの記録・送信を確認します。git status、現在のブランチ、最新コミット、接続先を調べ、必要な変更を確認してコミット・pushします。その後、GitHubと公開先のデプロイを確認します。

解説

GitHubまで届いていないので、ブラウザーを何度更新しても新しい内容は取得できません。反対に、GitHubが新しくてデプロイが失敗しているなら、調べるべきはそのビルドログです。

「保存 → ローカル表示 → GitHub → 本番デプロイ → 公開URL」の順に、目印の文章を探してみてください。最後に新しく表示できた場所と、その次の場所の間が、次に調べる範囲です。