UCAMC
← 回到 Blog
網站經營約 3 分鐘閱讀

內容網站自動化營運 Runbook：從每日檢查到發佈驗證

Updated 2026/06/23UCAMC
分類網站經營自動化工作流
標籤#Content Ops#Automation#Next.js#SEO#Runbook
內容營運團隊在工作桌前檢查網站發佈、SEO 與自動化流程的場景

內容網站開始用 Markdown、Next.js 與自動化 Agent 維護後，最怕的不是「今天沒有新文章」，而是每次更新都靠臨場判斷：有人只看 build，有人只看畫面，有人忘了檢查 sitemap，最後就會累積出 canonical URL、分類頁、metadata 與版面細節不一致的問題。

UCAMC 的做法是把每日網站經營整理成一份可重複執行的 Runbook。它不只是工程 checklist，也包含內容品質、SEO 與品牌呈現，讓網站像長期經營的數位實驗室，而不是一次性的靜態頁面。

1. 開始前先確認工作區乾淨度

每日維護第一步不是改文章，而是看目前 repo 狀態。

建議檢查：

  • git status --short 是否有既有修改。
  • 是否有其他 Agent 或人工留下的未追蹤文章。
  • 是否有 duplicated CSS、暫存報告、build artifact 之類需要保留或列入決策的檔案。
  • 當天要新增的 slug 是否已存在，避免覆蓋舊文或造成兩篇文章共用 canonical URL。

如果看到不確定來源的變更，原則是先保留，不要在每日 cron 例行任務中主動刪除。真正需要整理時，再由 Leon 決定是否合併、刪除或另開一次清理任務。

2. 文章 frontmatter 要讓系統能理解

內容網站的自動化程度，取決於資料是否穩定。對 UCAMC 這類 Markdown blog 來說，每篇文章至少要具備：

  • title：給讀者看的文章標題。
  • slug：root-level canonical URL 使用的路徑。
  • date 與 modified：讓列表排序與 sitemap 更新時間一致。
  • excerpt：Blog 列表、首頁卡片與社群摘要使用。
  • categories、tags：分類頁與知識地圖使用。
  • author：維持品牌署名。
  • seoTitle、seoDescription：避免搜尋結果只抓到文章第一段。
  • draft: false：確認文章可正式發佈。

這些欄位看似重複，但它們讓首頁、Blog 列表、分類頁、文章 metadata、Open Graph 與 sitemap 使用同一份內容資料，不需要每個頁面各自猜測。

3. URL 規則要寫成驗證項目

UCAMC 目前文章 canonical URL 是 root-level /{slug}，/blog 只是文章列表頁。這表示每日驗證時要看的是：

  • 首頁 / 是否正常。
  • Blog 列表 /blog 是否正常。
  • 新文章 /{slug} 是否正常。
  • 實際分類頁 /category/{category-slug} 是否正常。
  • /robots.txt 與 /sitemap.xml 是否包含合理資訊。
  • 舊 WordPress ID-prefixed URL，例如 /123-{slug}，是否 301 到 /{slug}。

反過來說，新的 /blog/{slug} 不存在並不是錯誤。把這條規則寫進 Runbook，可以避免 Agent 或維護者誤把正確的 404 當成 SEO bug。

4. Lint、build 與 production-mode route probe 都要做

只跑 npm run build 不夠，因為 route redirect、robots、sitemap 與部分 metadata 問題，需要用 production server 或等價方式實際打 URL 才看得出來。

一個實用的每日驗證順序：

  1. 執行 npm run lint，先抓 TypeScript 與資料型別問題。
  2. 執行 npm run build，確認 App Router static generation 正常。
  3. 啟動 production local server。
  4. 用 curl -I 檢查關鍵 URL 的 status code。
  5. 用瀏覽器打開首頁、Blog 列表與新文章，確認最新文章真的可讀、沒有 placeholder、沒有裸露未整理網址。

對內容站來說，這些驗證不是工程潔癖，而是保護長期 SEO 與品牌可信度的最低成本。

5. 每日報告要留下可追溯證據

Runbook 最後一段是回報格式。建議每次報告至少包含：

  • 日期與工作目錄。
  • 檢查範圍。
  • 新增或整理的文章與 canonical URL。
  • 修改檔案。
  • npm run lint 與 npm run build 的實際結果。
  • route / SEO probe 的 status code 與 redirect Location。
  • 若有既有未追蹤檔案或需 Leon 決策的事項，也要列出。

這樣做的好處是，未來若搜尋流量、頁面樣式或部署狀態出現變化，可以回頭追溯是哪一天加入了什麼內容、驗證過哪些 URL，而不是只看到一串模糊的自動化 commit。

6. 可複製的每日操作清單

以下是一份可放進內容維護任務的精簡版：

  1. 讀取專案規範與每日營運計劃。
  2. 檢查 git status，標記既有變更。
  3. 確認 app/ route、lib/posts.ts、sitemap、robots 邏輯未偏離 URL 策略。
  4. 新增或整理一篇有完整 frontmatter 的文章。
  5. 優化文章內部連結，連到 /blog、相關分類頁或既有 root-level 文章。
  6. 執行 lint 與 build。
  7. 啟動 local production server，檢查首頁、列表、新文章、分類頁、robots、sitemap 與 legacy redirect。
  8. 做一次瀏覽器視覺檢查。
  9. 關閉 server，回報證據與下一步建議。

自動化不代表不用判斷；它的價值是把重複的品質門檻固定下來，讓人把注意力放在更重要的內容策略、舊文整理與讀者真正需要的工具型文章上。

延伸閱讀