Vercel 部署回滾檢查表｜Next.js 內容站上線驗證與復原

內容網站的部署問題常常不是「整站壞掉」，而是某幾個關鍵頁面沒有更新：首頁還停在舊文章、/blog 沒有新卡片、/sitemap.xml 缺少最新 slug，或 root-level 文章頁在正式環境仍然 404。這些狀況如果只看 build 成功，很容易誤判成已經完成發佈。

這份檢查表適合 UCAMC 這類 Next.js App Router 內容站，也適合任何把文章放在 Markdown、再部署到 Vercel 的技術 Blog。目標不是把流程變複雜，而是讓發佈後的判斷更快、更有證據。

1. 先確認本機內容狀態

部署前先確定要上線的是正確內容，而不是工作目錄裡的半成品：

git status --short
npm run lint
npm run build

檢查重點：

新文章是否真的在 content/blog。
frontmatter 是否包含 title、slug、date、modified、excerpt、categories、tags、author、seoTitle、seoDescription 與 draft: false。
coverImage、coverAlt、featuredImage 是否存在且圖片可抓取。
沒有把臨時檔、測試文章或機密設定一起 commit。

如果本機 build 失敗，就不要先推到 production；先把 type、lint 或 Markdown frontmatter 問題修好。

2. 用 production mode 驗證代表性路由

next build 成功後，最好再用 production server 檢查真實路由：

npm run start -- --hostname 127.0.0.1 --port 3000
curl -I http://127.0.0.1:3000/
curl -I http://127.0.0.1:3000/blog
curl -I http://127.0.0.1:3000/vercel-deployment-rollback-checklist
curl -I http://127.0.0.1:3000/robots.txt
curl -I http://127.0.0.1:3000/sitemap.xml

對 UCAMC 來說，文章 canonical 是 root-level /{slug}，/blog 只是列表頁。不要把新文章的 /blog/{slug} 404 當成錯誤；真正需要驗證的是舊 WordPress 轉換留下的 ID-prefixed route 是否 301 到 root-level canonical。

3. 部署後分開看「Git 已更新」與「正式站已更新」

當 GitHub 已經有新 commit，不代表正式站一定已經刷新。部署後可以分兩層確認：

來源層：origin/main 是否已經指到新 commit？
呈現層：Vercel preview / production domain 是否真的回傳新 HTML？

可以用這幾個 probe：

curl -I https://ucamc-next-blog.vercel.app/vercel-deployment-rollback-checklist
curl -s https://ucamc-next-blog.vercel.app/blog | grep vercel-deployment-rollback-checklist
curl -s https://ucamc-next-blog.vercel.app/sitemap.xml | grep vercel-deployment-rollback-checklist

如果文章頁是 404，但 origin/main 已更新，問題可能在 Vercel 部署未觸發、部署卡住、production alias 尚未切換，或 edge cache 還在提供舊版本。

4. 什麼時候該回滾？

不是每個異常都需要馬上 rollback。可以用下面的決策方式：

狀況	建議動作
本機 build 失敗	不部署，先修 source code
只有 production domain 暫時 stale	持續輪詢，確認 Vercel deployment 狀態
新文章顯示但圖片 404	修圖片或換已驗證的 fallback image，再重新部署
首頁、Blog 與 sitemap 同時缺新內容	檢查 commit/push/deploy hook 是否成功
部署後出現大範圍 route 500	優先回滾到上一個健康 deployment

回滾的原則是：如果錯誤會影響讀者主要入口、SEO crawl 或大量文章頁，就應該先恢復穩定版本，再慢慢修原因。

5. 回滾後也要留下紀錄

回滾不是失敗，而是維護流程的一部分。建議每次回滾至少留下：

回滾日期：
影響範圍：首頁 / Blog / 文章頁 / sitemap / 圖片
問題 commit：
回滾到的 deployment 或 commit：
已驗證 URL：
後續修復項目：

這份紀錄未來可以變成內容站的維運知識庫，也能讓 AI Agent 在下一次 cron run 判斷問題時有上下文。

6. UCAMC 的每日最小驗證清單

每天新增或整理文章後，至少確認：

首頁 / 可讀，最新文章導讀不是 placeholder。
/blog 列表包含新文章與清楚摘要。
新文章 root-level /{slug} 回傳 200。
代表性分類頁回傳 200。
/robots.txt 與 /sitemap.xml 存在，sitemap 包含新 slug。
舊 ID-prefixed URL 301 到 root-level canonical。
新文章圖片 URL 回傳 200 且 content-type 是 image。

這份清單可以搭配 /content-ops-automation-runbook-template 與 /nextjs-content-site-health-check-template，形成一套可重複執行的內容站維護流程。

結語：部署完成要以讀者看到的結果為準

內容網站的發佈不是 commit 完就結束，而是讀者、搜尋引擎與社群分享卡片都能看到正確內容才算完成。把 Vercel deployment、root-level article route、Blog 列表與 sitemap 放進同一份檢查表，可以讓每次更新都更穩定，也讓回滾決策不靠猜測。

Vercel 部署回滾檢查表：內容站上線後如何快速確認與復原