Next.js 內容網站健康檢查模板：從路由、SEO 到版面巡檢

內容網站最怕的問題，不一定是大故障，而是每天累積的小破口：新文章沒有出現在列表、canonical URL 寫錯、分類頁可以 build 但實際 404、首頁出現 placeholder、或是舊文章連到已經不存在的路徑。這些問題如果沒有固定檢查流程，等到搜尋流量下降時才會很難追。

UCAMC 目前把 Blog 視為長期經營的技術內容品牌網站，所以每日維護不只看程式能不能編譯，也要看內容是否能被讀者與搜尋引擎正確理解。這篇整理一份可重複使用的 Next.js 內容網站健康檢查模板。

1. 先確認 canonical URL 規則

每個內容站都要先寫清楚正式網址策略，否則後續 sitemap、Open Graph、內部連結與 redirect 會各走各的。以 UCAMC 為例：

• /blog 是文章列表頁。
• 單篇文章使用 root-level /{slug}。
• 舊 WordPress ID-prefixed URL，例如 /123-example-post，才需要 301 到 /example-post。
• 新文章不建立 /blog/{slug} 單篇網址，也不把它的 404 視為錯誤。

這個規則應該同時反映在文章頁 metadata、sitemap、內部連結與維運文件中。若要複習搬家後的 SEO 檢查，可參考 WordPress 內容搬家後的 SEO 盤點表。

2. 檢查內容資料來源

Next.js App Router 內容站常見做法是用 Markdown 或 MDX 存文章，然後由共用 loader 讀取。每日檢查時，優先確認：

• 新文章是否放在正確資料夾，例如 content/blog。
• frontmatter 是否包含 title、slug、date、modified、excerpt、categories、tags、author、seoTitle、seoDescription、draft: false。
• slug 是否和 canonical URL 一致。
• draft 是否不小心維持在 true。
• 分類與標籤是否能被列表頁與分類頁讀取。

這一步不是形式檢查而已。列表頁摘要、首頁精選文章、文章 metadata 與 sitemap，通常都會依賴這些欄位。

3. 驗證首頁、列表頁與文章頁的品牌感

健康檢查不應該只跑指令，也要用讀者視角看頁面。至少檢查三種頁面：

1. 首頁 /：最新文章是否出現、導覽是否清楚、是否有不正式的 placeholder。
2. Blog 列表 /blog：文章日期、摘要、分類、閱讀按鈕是否一致。
3. 文章頁 /{slug}：標題、日期、分類、標籤、內文、站內延伸連結是否完整。

如果網站定位是技術內容品牌，而不是單純程式 demo，頁面文案就要避免「測試文章」「Coming soon」「example post」這類會降低信任感的文字。舊文章保留原貌沒問題，但主要入口頁要維持專業與可讀性。

4. 檢查 sitemap 與 robots

/sitemap.xml 和 /robots.txt 是搜尋引擎進入網站的重要入口。每日新增內容後，至少確認：

• sitemap 包含首頁、/blog、分類頁與新文章 root-level canonical URL。
• 新文章的 lastModified 使用 modified 或 date。
• robots 允許抓取，並指向正確 sitemap。
• sitemap 中沒有新產生的 /blog/{slug} 單篇網址。

這些檢查最好在 production build 後用 local production server 驗證，因為開發模式有時看不到靜態產出的完整狀態。

5. 用 lint 與 build 守住最低品質線

內容站每天新增文章，看似只是 Markdown，但仍可能讓 build 失敗，例如 frontmatter 格式錯誤、MDX 語法錯誤、分類 slug helper 型別錯誤、或 App Router metadata 寫法不符合版本要求。

最小檢查順序可以是：

npm run lint
npm run build

如果 lint 是 tsc --noEmit，失敗時先分辨是來源碼錯誤，還是 .next 快取或 generated types 留下的殘留問題。不要一看到錯誤就大改架構；先用最小修正讓網站恢復可 build。

6. 用 production server 驗證實際路由

build 成功後，還要確認實際 HTTP 狀態。可用本機 production server 檢查：

npm run start -- --hostname 127.0.0.1 --port 3000

接著測試：

• / 回傳 200。
• /blog 回傳 200。
• 新文章 /{slug} 回傳 200。
• 代表性分類頁回傳 200。
• /robots.txt 與 /sitemap.xml 回傳 200。
• legacy ID-prefixed URL 回傳 301 到正式 root-level 文章。

這比只看瀏覽器頁面更可靠，因為 redirect、robots 與 sitemap 都需要看狀態碼與 response header。

7. 把檢查結果變成每日報告

最後一步是把實際做過的事情記錄下來。每日報告至少包含：

• 檢查日期與範圍。
• 是否有既有 git 變更，是否保留。
• 新增或整理的文章。
• 修改檔案。
• lint/build 結果。
• route/SEO 驗證結果與狀態碼。
• 下一步建議或需要人工決策的事項。

這份報告不只是交差，而是讓長期經營有軌跡。當網站內容越來越多，未來要回頭查某次 SEO 策略、redirect 規則或版面調整，就能從每日報告找到脈絡。

讓維護流程本身成為內容資產

技術 Blog 的價值不只在單篇文章，也在它如何被持續整理。當 route、SEO、版面、內容與驗證流程都可以被模板化，網站就更不容易因為一次遷移、一次改版或一次疏忽而失去累積多年的內容價值。

對 UCAMC 來說，這份健康檢查模板可以和 AI Agent 網站營運工作流、AI Agent 每日 Route 與 SEO 檢查 搭配使用，讓日常維護不只是修 bug，而是逐步把網站變成更穩定、更可信的技術知識庫。