網站內容庫盤點｜改版前檢查 slug、圖片與內部連結

網站改版、WordPress 搬到靜態站、或把舊 Blog 逐步整理成內容庫時，最容易被低估的不是版面，而是內容資產之間的連結關係。文章 slug、分類頁、封面圖片、內部連結、sitemap 與舊網址轉址，只要其中一段斷掉，就可能讓讀者看到 404、讓社群預覽沒有圖，或讓搜尋引擎重新理解錯誤的 canonical。

我會把這類工作當成「內容庫盤點」，而不是單純的改版收尾。目標不是一次把所有舊文改到完美，而是先把首頁與 Blog 可見、流量重要、最近新增、缺圖或路由容易出錯的文章排出優先順序，逐批留下可驗證的 QA 證據。

先建立盤點範圍，不要直接批次改 slug

slug 是內容站的長期地址。改版時如果看到舊網址不漂亮，不能直接大量改名；比較安全的做法，是先列出現況與風險，再決定哪些 URL 維持、哪些需要 redirect。

Inventory scope:
- Homepage visible posts: newest 4 posts.
- Blog first page: newest 10 posts.
- Priority legacy posts: high traffic or often linked.
- Risk signals: missing coverImage, empty coverAlt, long code blocks,
  naked external URLs, old sourceUrl-only references.

對 UCAMC 這類從舊 Blog 延伸而來的技術內容站，我會優先保留 canonical URL 策略：文章放在 root-level /{slug}，/blog 只是列表頁。新文章不需要也不應該期待 /blog/{slug} 存在；真正需要驗證的是 root-level 文章頁與舊 WordPress ID-prefixed URL 的 301。

用 frontmatter 把內容資產補齊

一篇可長期經營的技術文章，不應只靠 Markdown 本文。frontmatter 需要能支撐 Blog 列表、文章頁、Open Graph、sitemap 與未來自動化檢查。

title: "網站內容庫盤點：改版前先檢查 slug、圖片與內部連結"
slug: "website-content-inventory-migration-qa"
excerpt: "改版前用 slug、圖片、內部連結與 SEO 證據降低遷移風險。"
coverImage: "/images/blog/example-cover.png"
coverAlt: "內容庫盤點示意，包含 URL、圖片與 sitemap 檢查"
featuredImage: "/images/blog/example-cover.png"
draft: false

其中 coverImage、featuredImage 與 coverAlt 不是裝飾欄位。Blog 列表卡片、文章 hero image、社群預覽與品牌一致性都會受影響。若找不到真正對應主題的舊圖，寧可產生新的技術品牌封面，也不要拿不相關圖片當通用填充。

檢查圖片時同時看檔案與畫面

圖片 URL 能回 200，不代表它適合文章，也不代表頁面實際好看。盤點時至少保留兩層證據：資源本身可讀，以及文章頁真的顯示。

curl -I https://www.example.com/images/blog/example-cover.png

記錄時我會看：

項目	檢查重點
status	200，不是 404 或 403
content-type	`image/png`、`image/jpeg` 或 `image/webp`
coverAlt	說明圖片內容，而不是塞關鍵字
Blog card	圖片比例正常，不擠壓、不溢出
Article page	圖片與文章主題相符，沒有只剩 alt text

這一步能避免「build 成功，但首頁第一張圖其實壞掉」的品牌傷害。

內部連結要指向 canonical，不要混用舊路徑

改版後最常見的小問題，是文章內還殘留舊路徑。讀者點得到不代表 SEO 最佳；如果內部連結一直指向舊網址，再靠 redirect 回來，會讓站內訊號變得混亂。

Link QA:
- Article card href uses /{slug}.
- Related article links use /{slug}.
- Category links use /category/{category-slug}.
- Sitemap uses https://www.ucamc.com/{slug}.
- Robots points to https://www.ucamc.com/sitemap.xml.

如果遇到舊 WordPress ID-prefixed URL，例如 12345-sample-post，再確認它 301 到 root-level sample-post。但不要把新文章的 /blog/{slug} 404 當錯，因為那不是 UCAMC 目前的 canonical 設計。

把檢查結果寫成 observe / change / verify

內容庫盤點最有價值的地方，是讓下次維護能看懂你做過什麼。與其只寫「已檢查 SEO」，不如把證據拆成三段。

Observe:
- /blog first card has coverImage and correct title.
- /website-content-inventory-migration-qa returns 200.
- Sitemap contains the root-level article URL.

Change:
- Added missing coverAlt.
- Replaced unrelated generic image with topic-specific cover.
- Updated internal article links to root-level canonical paths.

Verify:
- npm run lint: pass.
- npm run build: pass.
- curl -I /12345-slug returns 301 Location: /slug.

這種紀錄也適合放進團隊 issue、PR description 或每日網站經營報告。它讓內容維護從憑感覺的整理，變成可回放的生產流程。

UCAMC 的長期做法

UCAMC 會持續把舊 WordPress 筆記、新的 Next.js 維護紀錄、WordPress 排查、前端 QA、動畫與內容製作流程整理在同一個知識庫裡。每天只處理幾篇也沒關係，重點是每次都把 slug、圖片、metadata、內部連結與 production route 證據對齊。

當內容庫越來越大，真正能降低風險的不是一次性的完美改版，而是穩定重複的盤點節奏：先看可見文章，補齊缺圖與摘要，確認 canonical，最後用 lint、build、local production route 與 sitemap 證據收尾。