Next.js 內容站封面圖正常，社群預覽卻不穩：Cover 與 OG 圖片巡檢筆記

內容站的圖片問題常常不是「頁面完全壞掉」，而是比較細的品牌品質落差：文章頁封面看起來正常，但社群分享沒有大圖；Blog 列表卡片沒有足夠語意；或外部圖片服務偶爾回 404，Next.js build 卻仍然成功。這類問題如果只靠 npm run build，通常不會被抓到。

UCAMC 的做法是把圖片視為文章的一部分，而不是最後補上的裝飾。新增或整理文章時，會同時檢查 coverImage、coverAlt、featuredImage、metadata、Open Graph 與實際 production 頁面，確保讀者從首頁、搜尋結果、社群預覽到文章頁都看見同一個清楚的內容單位。

先確認 frontmatter，不要只看正文

Next.js 內容站通常會用 Markdown frontmatter 供應首頁卡片、Blog 列表、文章 metadata 與 sitemap。若欄位不完整，頁面可能仍可渲染，但品牌與 SEO 訊號會變弱。

UCAMC 新文章至少要檢查：

coverImage: "https://.../cover.webp"
coverAlt: "描述畫面內容與文章主題，不只寫 screenshot"
featuredImage: "https://.../cover.webp"
seoTitle: "社群與搜尋結果可理解的標題"
seoDescription: "一段具體摘要，說明讀者能解決什麼問題"
draft: false

coverImage 與 featuredImage 目前可以使用同一張圖，但兩者都保留的好處是：文章頁、卡片 UI 與 Open Graph 產生邏輯不用互相猜測。若未來改成不同尺寸，也能逐步調整而不破壞舊文章。

外部圖片要真的抓得到

圖片 URL 寫在 frontmatter 裡，不代表它能穩定服務。尤其是 Cloudinary 轉檔參數、Unsplash query string、舊 WordPress 匯入圖片，都可能因為路徑、授權、格式轉換或遠端 cache 出現問題。

最小巡檢可以先做：

curl -L -sS -o /dev/null \
  -w '%{http_code} %{content_type}\n' \
  'https://res.cloudinary.com/example/image/upload/f_webp,q_auto,w_1600/path.jpg'

判斷標準不要只看 200，也要看 content_type 是否為圖片，例如 image/jpeg、image/png、image/webp。若回到 HTML 錯誤頁，瀏覽器可能只顯示破圖或 alt text，build 仍然不一定會失敗。

文章頁 metadata 要和 canonical URL 對齊

UCAMC 的文章 canonical URL 是 root-level /{slug}，不是 /blog/{slug}。圖片巡檢時也要一起檢查 metadata 是否使用同一套 canonical 策略，否則社群分享與搜尋引擎可能看到不一致的 URL。

文章頁應該能生成：

• canonical：https://www.ucamc.com/{slug}
• Open Graph URL：同一個 root-level article URL
• Open Graph image：featuredImage 或相容欄位
• Twitter Card：有圖時使用 summary_large_image
• description：優先使用 seoDescription，不要只截正文第一段

這裡的重點不是塞更多 keyword，而是讓每篇文章成為可分享、可索引、可辨識的內容單位。

用頁面視角再看一次圖片品質

即使圖片 URL 正常，也要回到頁面看它是否真的適合文章。常見問題包括：

• 技術排查文章用了太抽象或太花的圖片，讀者無法理解主題。
• 深色圖片搭配首頁卡片時，標題與分類標籤視覺重量不平衡。
• 圖片比例在文章頁正常，但在 Blog 卡片或社群預覽中被裁切到重點。
• coverAlt 只寫「封面圖」，對螢幕閱讀器和維護者都沒有幫助。

在 UCAMC 的日常維護裡，圖片不需要每次都重新設計，但要能支撐文章定位。Next.js、Vercel、WordPress 維運類文章可以使用較穩定的工作台、程式碼、後台或流程圖意象；動畫、漫畫與短片文章則優先選擇分鏡、畫面製作或素材管理相關圖片。

發布前的最小驗證順序

一篇新文章準備發布前，可以把圖片與 SEO 驗證排成固定順序：

1. 搜尋 slug，確認沒有覆蓋既有文章。
2. 檢查 frontmatter 欄位完整，尤其是 coverImage、coverAlt、featuredImage。
3. curl 圖片 URL，確認 200 與圖片 content type。
4. 執行 npm run lint 與 npm run build。
5. 用本機 production 檢查 /、/blog、/{slug}、/sitemap.xml。
6. 用瀏覽器看文章頁：封面、標題、分類、程式碼區塊與內文是否可讀。
7. 發布後再檢查正式網域的 article route、Blog 列表與 sitemap 是否都包含新 slug。

這個流程看起來比「寫完文章就 push」多幾步，但它能避免最尷尬的內容站問題：文章其實存在，卻在分享、搜尋或首頁卡片中呈現得不完整。

結語：圖片是內容品質，不只是裝飾

對技術 Blog 來說，圖片不必比文字更搶眼；但它至少要穩定、語意清楚，並能支援 Open Graph 與列表卡片。當 coverImage、featuredImage、Alt、metadata 與 route 驗證一起被納入每日維護，內容站就比較不會在 production 才暴露破圖、預覽缺失或 URL 不一致。

UCAMC 會把這類巡檢保留在日常工作流中：先確認內容資料，再確認圖片回應，最後確認頁面與 SEO 輸出。這樣每篇新筆記不只是能開啟，也更像一個可以長期累積、被搜尋與被分享的技術內容資產。