Next.js 文章上線證據簿｜路由、圖片與 SEO 檢查紀錄

Next.js App Router 內容站上線文章時，最容易被低估的不是 Markdown 格式，而是「證據」。npm run build 成功只能證明程式能產生頁面，不代表正式網址、Blog 列表、sitemap、Open Graph 圖片與 legacy redirect 都已經對齊。

對 UCAMC 這類從舊 WordPress 延伸而來的技術 Blog，我會把每篇新文章都當成一筆可追溯的發布紀錄：文章 canonical URL 是 root-level /{slug}，/blog 只是列表頁；若有舊 WordPress ID-prefixed URL，才需要驗證它 301 到新的 root-level slug。

這篇整理一份「文章上線證據簿」的寫法，讓每次發布不是靠印象，而是留下可重跑、可比對、可交接的紀錄。

先定義這篇文章的 canonical URL

發布前先把 URL 規則寫清楚，避免後面檢查時把不存在的路徑誤判成錯誤。

Article slug:
nextjs-route-image-seo-evidence-log

Canonical route:
/nextjs-route-image-seo-evidence-log

Listing route:
/blog

Legacy WordPress redirect sample:
/1234-nextjs-route-image-seo-evidence-log
→ /nextjs-route-image-seo-evidence-log

這裡特別要分清楚：/blog/{slug} 不是 UCAMC 新文章 canonical，也不需要為新文章建立通用 redirect。檢查重點應該放在 root-level article URL、列表頁與 sitemap 是否一致。

Frontmatter 不是填完就好，要能生成 metadata

一篇文章至少要能回答三件事：它是什麼、搜尋結果怎麼呈現、社群預覽有沒有圖片。

title: "Next.js 文章上線證據簿"
slug: "nextjs-route-image-seo-evidence-log"
excerpt: "Next.js 內容站不是 build 成功就算上線。"
seoTitle: "Next.js 文章上線證據簿｜路由、圖片與 SEO 檢查"
seoDescription: "整理文章上線後的 route、圖片與 SEO 證據。"
coverImage: "/images/blog/nextjs-route-image-seo-evidence-log-cover.png"
coverAlt: >-
  Next.js 文章上線證據簿 cover，顯示 root-level 路由、sitemap、
  robots、Open Graph 圖片與 curl 狀態碼驗證
featuredImage: "/images/blog/nextjs-route-image-seo-evidence-log-cover.png"
draft: false

coverAlt 不只是圖片替代文字，也是在未來整理舊文章圖片時，幫自己判斷圖文是否對應的線索。若 cover 只是泛用插圖，之後很難知道當初為什麼選它。

圖片檢查要分成檔案、metadata 與實際渲染

圖片欄位存在不代表圖片可用。至少要保留三層證據：

檔案可讀：本機或遠端 URL 回應是 image content type。
metadata 有引用：文章頁輸出 og:image / Twitter image。
畫面有呈現：文章頁與 Blog 卡片都能看到圖片，且沒有壓縮錯位或破圖。

本機圖片可以用這種方式先確認 MIME type：

file -b --mime-type \
public/images/blog/nextjs-route-image-seo-evidence-log-cover.png

若是外部圖片，則要用 curl -I 或 curl -L -I 看 status 與 content-type，不要只因為瀏覽器曾經看過就當成可用。

Route 檢查要留下狀態碼，而不是只看畫面

文章上線後，我會把 route probe 寫成簡短紀錄：

for path in \
  / \
  /blog \
  /nextjs-route-image-seo-evidence-log \
  /category/next-js \
  /robots.txt \
  /sitemap.xml
 do
  curl -I "https://www.ucamc.com$path"
done

真正要寫進證據簿的不是整份 header，而是判斷結果：

/                              200
/blog                          200
/article route                 200
/category/next-js              200
/robots.txt                    200, contains Sitemap
/sitemap.xml                   200, contains article slug

這樣未來若首頁正常但 sitemap 漏掉文章，就能快速定位是 content loader、draft 狀態、日期排序還是 sitemap 產生邏輯出了問題。

Open Graph 與 canonical 要看正式網域輸出

App Router 的 metadataBase、文章 alternates.canonical、Open Graph url 與圖片 URL 應該對齊正式網域策略。UCAMC 的正式 canonical 是 https://www.ucamc.com/{slug}；本機測試時看到 canonical 指向正式網域，反而是合理的 SEO 行為。

可以在本機 production server 或正式站 HTML 裡確認：

canonical:
https://www.ucamc.com/nextjs-route-image-seo-evidence-log

og:image:
/images/blog/nextjs-route-image-seo-evidence-log-cover.png

og:url:
https://www.ucamc.com/nextjs-route-image-seo-evidence-log

若文章沒有 featuredImage，Twitter Card 可能退回 summary；若圖片 URL 錯誤，社群分享就會變成只有文字。這類問題不一定會讓 build 失敗，但會直接影響內容品牌品質。

Legacy redirect 只驗證 ID-prefixed URL

舊 WordPress 文章常有 /{id}-{slug} 形式。當它已經轉成 root-level canonical 時，redirect 檢查可以像這樣記錄：

curl -I \
  https://www.ucamc.com/1234-nextjs-route-image-seo-evidence-log

期待結果是：

301
Location: /nextjs-route-image-seo-evidence-log

不要把 /blog/nextjs-route-image-seo-evidence-log 的 404 當成錯誤；如果新的 canonical 策略不是 /blog/{slug}，硬補 redirect 反而會讓 URL 規則變得混亂。

證據簿建議格式

我會把每次文章發布記成這種格式：

Article:
- title: Next.js 文章上線證據簿
- slug: nextjs-route-image-seo-evidence-log
- canonical: /nextjs-route-image-seo-evidence-log

Build:
- npm run lint: pass
- npm run build: pass

Routes:
- /: 200
- /blog: 200, listing contains slug
- article route: 200
- /category/next-js: 200
- /robots.txt: 200, sitemap points to www.ucamc.com
- /sitemap.xml: 200, contains canonical URL
- ID-prefixed route: 301 to canonical slug

Images:
- cover file: image/png
- article image naturalWidth > 0
- Blog first card image naturalWidth > 0
- og:image present

這份紀錄不需要很長，但要能讓下一個維護者重跑同樣檢查。長期來看，內容站的穩定不是靠一次大改，而是靠每次小發布都留下可驗證的證據。

Next.js 文章上線證據簿：把路由、圖片與 SEO 檢查留成可追溯紀錄