Cloudflare Pages 部署成功但網站沒更新？小企業 GitHub 架站最容易搞混的 4 個發文環節

小企業自己用 GitHub 架站，最容易遇到一種很尷尬的狀況：

文章明明貼了。

檔案明明 commit 了。

Cloudflare Pages 看起來也有部署。

可是打開公開網址，文章就是沒有出現。

有時候是部落格列表沒更新。

有時候是文章頁直接 404。

有時候舊文章正常，新文章卻不見。

這種問題最麻煩的地方是：每個環節看起來都像成功，但最後公開網站沒有成功。

今天這篇不是抽象講網站部署，而是用 printapp.uk 手動貼文流程來整理一個很實際的觀念：GitHub 架站時，commit、build、deploy、cache / route 是四個不同環節。任何一段沒有接上，最後使用者看到的網站都可能不是你以為的版本。

第一個環節：GitHub commit，不等於網站已經更新

很多人第一次用 GitHub 後台貼文時，會以為按下 Commit changes 就代表網站已經更新。

其實不是。

GitHub commit 只代表檔案已經寫進 repo。

例如新增文章時，正確檔案可能是：

src/content/blog/cloudflare-pages-github-deploy-success-site-not-updated.md

按下 commit 後，這個檔案會進入 GitHub 的 main branch。

但這時候公開網站還不一定有任何改變。

因為靜態網站還需要下一步：Cloudflare Pages 讀取 repo，執行 build，產出新的靜態檔案，再部署到公開環境。

所以第一個檢查點是：

文章檔案是否真的存在於 GitHub？

是否在正確路徑？

是否 commit 到 main branch？

檔名是否和預期網址 slug 一致？

如果這一步錯了，後面看 Cloudflare 也沒用。

例如檔案放錯資料夾，Cloudflare 就算部署成功，也不會產生你預期的文章頁。

第二個環節：build 成功，不等於文章一定被收進去

Cloudflare Pages 會從 GitHub 拉取程式碼，然後執行網站的 build 指令。

對 Astro 這類靜態網站來說，build 會把 markdown 文章、頁面、樣式與路由整理成公開網站可以使用的檔案。

但 build 成功，不代表每篇文章都一定被正確收進去。

例如前面遇過一個很典型的問題：文章檔案放在 src/content/blog/，但 frontmatter 欄位寫錯。

網站現有文章格式需要：

title

date

summary

code

category

但如果文章開頭寫成：

pubDate

description

tags

summaryCode

這就可能讓網站讀不到正確資料，或讓文章列表無法照預期呈現。

這種情況很容易讓人誤會是部署失敗。

實際上，檔案有 commit，Cloudflare 也可能有 build，但文章資料格式不符合網站程式期待。

所以第二個檢查點是：

Cloudflare Pages 最新 build 是 Success 還是 Failed？

如果 Failed，錯誤訊息指向哪個檔案？

如果 Success，新文章有沒有被文章列表讀到？

frontmatter 是否符合網站現有格式？

這一步不能只看「部署有跑」，還要看「網站有沒有把文章收進內容集合」。

第三個環節：deploy 成功，要確認是不是最新版本

Cloudflare Pages 的 Deployments 頁面會顯示部署狀態。

但有時候使用者會只看見一個 Success，就以為最新文章一定上線了。

這裡要更小心。

要確認的是：成功的 deployment 是不是對應你剛剛那次 commit。

如果你剛 commit，但 Cloudflare 最新成功部署仍然是前一個 commit，那公開網站當然不會有新文章。

也可能出現最新 deployment 失敗，但上一版成功版本還在，所以公開網站看起來正常。這時候舊文章可以開，新文章沒有出現，原因不是公開站壞掉，而是新版本沒有部署成功。

比較好的檢查方式是：

到 Cloudflare Pages。

打開對應專案。

進入 Deployments。

看最新一筆是否是 Success。

看時間是否在你剛 commit 之後。

如果有 commit hash 或部署訊息，要確認它對應剛剛的 GitHub commit。

這個步驟很重要，因為公開網站正常不代表最新版本正常。

有些人看到首頁可以開，就以為部署成功；但首頁可能是上一版留下來的。

第四個環節：cache、route 和公開網址驗收

即使 commit、build、deploy 都成功，最後仍然要開公開網址驗收。

這一步不能省。

對部落格文章來說，至少要檢查兩個地方。

第一，文章列表頁。

例如：

https://printapp.uk/blog/

新文章應該要出現在列表中，標題、摘要、日期、分類要正常。

第二，文章詳細頁。

例如：

https://printapp.uk/blog/cloudflare-pages-github-deploy-success-site-not-updated/

這個網址要能正常開啟，不能 404，也不能只顯示半篇文章。

如果列表有出現，但文章頁 404，可能是路由或 slug 問題。

如果列表沒有出現，但檔案已存在，可能是 frontmatter、content collection 或 build 問題。

如果文章頁可以開，但內容少了一半，可能是 markdown 內容中有特殊格式導致貼文截斷。

如果舊內容還在，新內容看不到，才需要再考慮 cache 或部署延遲。

公開網址驗收不是形式，而是最後一關。

GitHub 和 Cloudflare 後台都只是中間狀態，真正給讀者看的，是公開網址。

為什麼小企業特別容易卡在這裡？

大型團隊通常會有工程師、CI/CD 流程、preview environment、錯誤監控與部署記錄。

小企業自己維護網站時，常常是同一個人負責寫文章、貼 GitHub、看 Cloudflare、開網址測試。

這種情況下，最容易把不同環節混在一起。

以為 commit 就是部署。

以為部署成功就是文章成功。

以為網站首頁正常就是最新版本正常。

以為 404 一定是網址錯。

以為 Cloudflare 有 Success 就不用再測公開頁。

這些誤判都很常見。

所以小企業用 GitHub 架站，不一定需要很複雜的工具，但一定要有清楚檢查順序。

手動貼文後，最少要做 5 個確認

printapp.uk 後續每次手動貼文，應該固定做 5 個確認。

第一，確認檔案位置。

文章要在：

src/content/blog/

不是 repo 根目錄，也不是錯的資料夾。

第二，確認檔名。

檔名要和預期網址 slug 對得起來。例如檔名是：

cloudflare-pages-github-deploy-success-site-not-updated.md

預期網址就是：

/blog/cloudflare-pages-github-deploy-success-site-not-updated/

第三，確認 frontmatter。

開頭欄位要使用網站現有格式：

title / date / summary / code / category

不要臨時換成其他欄位。

第四，確認 Cloudflare Deployments。

要看最新一筆是不是成功，而且時間要在剛剛 commit 之後。

第五，確認公開網址。

一定要打開文章網址，不只看 GitHub，不只看 Cloudflare。

這 5 個確認做完，才算貼文完成。

遇到網站沒更新，不要一開始就亂改程式

當公開網站沒更新時，最怕的不是錯誤本身，而是排查順序亂掉。

有些人一看到 404，就去改 route。

有些人一看到網站沒更新，就重新貼文章。

有些人懷疑 Cloudflare cache，先清快取。

有些人以為 GitHub 壞掉，又重建檔案。

這樣很容易把簡單問題變複雜。

比較穩的順序是：

先看檔案是否在正確路徑。

再看 commit 是否進 main。

再看 frontmatter 是否符合格式。

再看 Cloudflare 最新 deployment。

最後再看公開網址與 cache。

這個順序可以避免一開始就動到不該動的地方。

很多時候，問題只是文章欄位寫錯，或 commit 還沒對應到最新部署。

這次流程修正後，手動貼文要更像工單

手動貼文看起來只是複製 markdown，但其實它也是一個小型發布流程。

所以每次貼文最好固定留下四個資訊：

檔名。

repo 路徑。

完整文章內容。

發布後公開網址。

這四項缺一個，都可能讓後續排查變麻煩。

如果只知道文章標題，不知道檔名，就很難快速找到檔案。

如果只知道 GitHub 有貼，不知道公開網址，就無法確認路由。

如果只知道網址 404，不知道檔案路徑，就不知道問題是在 GitHub 還是 Astro。

所以小企業手動維護網站，不要只把它當貼文字，而要把它當作一個輕量發布工單。

結論：部署成功只是中間站，公開網址正常才算完成

Cloudflare Pages 部署成功但網站沒更新，通常不是一句話能判斷原因。

它可能是檔案沒有 commit。

可能是檔案放錯位置。

可能是 frontmatter 不符合 Astro 網站格式。

可能是 build 失敗。

可能是 deploy 不是最新 commit。

也可能是公開網址、路由或 cache 還沒對上。

所以小企業用 GitHub 和 Cloudflare Pages 架站時，要把發文流程拆成四個環節看：

commit 是檔案進 repo。

build 是網站產生靜態檔。

deploy 是新版本送到公開環境。

公開網址驗收才是讀者真的看得到。

不要把其中一個成功，當成整個流程成功。

下一次文章貼完後，不只要問「GitHub 有沒有存檔」，也要問：

Cloudflare 有沒有 build 成功？

最新 deploy 是不是這次 commit？

文章列表有沒有出現？

公開網址能不能開？

這幾個問題都通過，才叫真正發文完成。