Next.js 內容站上線後健康檢查模板｜Route、SEO、Sitemap 驗收

內容站上線後，最容易出現的問題不是完全壞掉，而是「看起來有更新，但某些入口其實還停在舊狀態」。例如首頁 Hero 已經顯示新文章，/blog 列表卻沒有更新；文章頁可以打開，/sitemap.xml 卻沒有包含新 slug；或是舊 WordPress ID-prefixed URL 沒有正確轉到 canonical route。

UCAMC 採用 Next.js App Router 與 Markdown 內容流程，文章 canonical URL 定義為 root-level /{slug}，/blog 只作為文章列表頁。這份模板整理成 10 分鐘內可執行的健康檢查，適合每日發文、版面微調、部署後驗收與舊站搬移後的例行巡檢。

1. 先確認這次上線的範圍

不要一開始就打開瀏覽器亂點。先列出這次變更真正應該影響哪些地方：

檢查項目	需要記錄
新文章 slug	例如 `nextjs-production-route-health-check-template`。
主要分類	例如 Next.js、網站經營、SEO。
代表性舊網址	只檢查 legacy ID-prefixed pattern，例如 `/{id}-{slug}`。
會變動的頁面	首頁、`/blog`、文章頁、分類頁、sitemap。
不該變動的地方	canonical URL 策略、舊文章 slug、品牌 Logo 與機密設定。

這一步的目的，是避免把「新文章的 /blog/{slug} 404」誤判成錯誤。對 UCAMC 目前策略來說，新文章本來就不使用 /blog/{slug} 當 canonical route。

2. 用 production build 驗證，不只看 dev server

開發模式可以快速預覽，但它不能代表正式部署後的靜態產物與 redirect 行為。建議至少跑：

npm run lint
npm run build
npm run start -- --hostname 127.0.0.1 --port 3020

如果 lint 是 tsc --noEmit，而錯誤來自 stale .next/types 或 TypeScript incremental cache，先清掉 .next 與 *.tsbuildinfo 後再重跑。不要在沒有證據時直接修改內容讀取邏輯。

3. Route 檢查清單

local production server 啟動後，用 curl -I 或瀏覽器依序確認：

/ 回 200，首頁 Hero 與最新文章區能看見本次新內容。
/blog 回 200，列表第一張或前幾張卡片包含新文章。
/{slug} 回 200，文章標題、日期、分類與封面正常。
/category/{category} 回 200，分類頁包含該文章。
/robots.txt 回 200，沒有阻擋主要內容。
/sitemap.xml 回 200，包含 root-level /{slug}。
/{id}-{slug} 回 301，Location 指向 /{slug}。

這裡不需要為新文章檢查 /blog/{slug} redirect；若它不存在，符合目前 UCAMC URL 策略。

4. SEO metadata 不只看 title

文章頁能打開只是第一步。內容站還需要確認搜尋與社群分享資訊是否合理：

Metadata	驗收方式
`title` / `description`	是否具體說明文章價值，而不是只有品牌名。
canonical	是否指向 `/{slug}`。
Open Graph	是否有 title、description、image。
Twitter Card	有封面時應使用 large image 類型。
sitemap lastmod	新文章日期與 modified 不應空白。

若文章有 coverImage 或 featuredImage，要直接請求圖片 URL，確認回 200 且 content-type 是 image。Build 成功不代表外部圖片沒有失效。

5. 版面巡檢：首頁、列表、文章頁各看一次

Route 正常後，還要看頁面是否像正式品牌網站。建議至少檢查三個畫面：

首頁：Hero CTA 是否重複、最新文章是否與右側 featured card 重複、分類入口是否過度擁擠。
Blog 列表：第一張卡片是否有清楚標題、摘要、分類與閱讀入口。
文章頁：封面比例、表格、程式碼區塊、GFM task list 與內部連結是否沒有水平溢出。

如果只是小型文案或 CSS 問題，可以直接修；如果牽涉品牌識別、整體架構或 canonical URL 策略，應保留現狀並列入人工決策。

6. 可複製的 10 分鐘驗收表

分鐘	動作	通過標準
0-2	看 git status 與本次變更清單	沒有覆蓋不明檔案。
2-4	跑 lint / build	指令成功，或已修復小型錯誤後成功。
4-6	啟動 local production server	`/`、`/blog`、`/{slug}` 回 200。
6-8	查 robots / sitemap / redirect	sitemap 包含新 slug，legacy ID-prefixed URL 301 到 canonical。
8-10	瀏覽器或截圖檢查主要頁面	沒有破圖、裸露 placeholder URL、明顯水平溢出。

這份表格可以接在 Next.js 內容站每日 SEO 巡檢清單後使用：前者偏日常 SEO 維護，這篇則偏每次部署後的 route 與 production freshness 驗證。

7. 部署後要分清楚「內容已推送」與「正式站已更新」

GitHub push 成功不一定代表正式網域已經服務新 HTML。若 origin/main 已經有新 commit，但 Vercel 或正式網域仍是舊頁面，應該把它報告成部署 freshness 邊界，而不是假裝 production 成功。

建議報告至少包含：

新 commit hash。
local lint / build 結果。
local production route status。
production /{slug}、/blog、/sitemap.xml 的 status 與是否包含新 slug。
若正式站仍 stale，列出需要 Dashboard redeploy、deploy hook 或 Vercel token 的後續處理。

長期經營內容站時，這種可追蹤的驗證證據比單純說「已更新」更重要。它能讓網站維護、SEO 與內容營運保持在同一個可回溯流程裡。

Next.js 內容站上線後健康檢查模板：10 分鐘確認 Route、SEO 與首頁狀態