Next.js 內容站上線後的 Vercel 觀測清單

內容網站的上線工作不該停在「build passed」。對 UCAMC 這種長期整理 WordPress 舊文、Next.js 筆記與自動化流程的技術 Blog 來說，每一次新增文章或調整版面，都需要留下可追蹤的營運證據：哪個 URL 是 canonical、sitemap 是否更新、Vercel 是否已經 serving 新頁面、以及什麼情況下需要回滾。

這份清單把每日內容發布後的 Vercel 觀測流程整理成可重複執行的步驟，可搭配內容網站內部連結與 SEO 地圖、Next.js 內容站健康檢查模板與 AI Agent Vercel 發布檢查清單使用。

1. 先確認本次變更的範圍

每次發布前，先把變更分成三類：

內容變更：新增 Markdown、整理 frontmatter、補內部連結、調整分類或標籤。
程式變更：改 App Router route、metadata、sitemap、robots、content loader 或 UI component。
樣式變更：改首頁、Blog 列表、文章頁排版、按鈕、卡片、字級或行動版間距。

分類的目的不是增加流程，而是決定驗證深度。只新增文章時，至少要檢查 /blog、新文章 root-level /{slug}、代表性分類頁與 sitemap；若改到 route 或 style，還要用 production mode 做瀏覽器或截圖巡檢。

2. Vercel 部署不是唯一成功條件

Vercel 顯示部署成功，只代表專案在遠端環境通過建置；內容站仍可能出現幾種營運問題：

新文章沒有出現在首頁或 Blog 列表的最新區塊。
sitemap 沒有包含新文章，搜尋引擎無法透過站點地圖快速發現內容。
canonical URL 與站內連結不一致，讓同一篇文章看起來像多個入口。
Open Graph / Twitter Card 摘要太短、太泛，社群分享時缺乏上下文。
Edge cache 還在 serving 舊 HTML，導致 build 結果和實際頁面不同步。

因此每日報告應該記錄「實際 URL 的狀態碼與內容證據」，而不是只寫部署完成。

3. UCAMC 的 root-level URL 檢查順序

UCAMC 單篇文章 canonical URL 採 root-level /{slug}，/blog 只是列表頁。新增文章後，可以依序檢查：

/ 是否顯示最新文章卡片或至少不破版。
/blog 是否依日期列出新文章。
/{slug} 是否回傳 200，並顯示標題、日期、作者、分類、標籤與內文。
/category/{category} 是否收錄該文章；中文分類要使用實際產生的 slug，不要猜英文路徑。
/sitemap.xml 是否包含正式站的新文章 canonical URL（也就是 root-level /{slug}）。
/robots.txt 是否仍允許抓取並指向 sitemap。
代表性 legacy ID-prefixed URL，例如 /123-{slug}，是否 301 到 /{slug}。

不要把新文章的 /blog/{slug} 404 當成錯誤；那不是 UCAMC 目前的 canonical 策略。

4. 設定可回滾的判斷條件

內容站不需要因為每個小文案問題回滾，但以下狀況應該暫停發布或回復前一版：

首頁、Blog 列表或所有文章頁出現 500。
新增文章造成 npm run build 或 npm run lint 失敗，且無法在同次維護中修復。
sitemap 或 robots.txt 無法回應，影響搜尋引擎發現內容。
大量舊文章 canonical URL 改變，可能造成 SEO 損失。
版面調整破壞 Logo、主導覽或文章閱讀體驗。

相對地，單篇文章摘要可再優化、分類順序可調整、或個別內部連結可補強，通常可以列入下一步，而不必立刻回滾。

5. 把觀測結果寫回營運紀錄

每日維護報告至少應留下：

新增或整理的文章標題與 canonical URL。
修改檔案與是否保留既有未追蹤變更。
npm run lint 與 npm run build 的實際結果。
/、/blog、新文章、分類頁、/robots.txt、/sitemap.xml 與 legacy redirect 的狀態碼。
若有視覺巡檢，記錄首頁、Blog 列表與文章頁是否看起來像正式品牌網站。

這些紀錄會讓 UCAMC 的內容維護更像產品營運：每篇文章不只是被發布，也被納入可追蹤、可回溯、可持續改善的網站系統。