我最近把自己的 Blog 從 WordPress 遷移到 Hugo。
一開始以為這只是一次很單純的工程整理：把 WordPress MySQL 裡的文章匯出成 Markdown，重新做 Hugo theme/template，補上 SEO metadata、sitemap、RSS、canonical、Open Graph，然後 build、deploy。
表面上看起來很順。
但真正上線後才發現，WordPress migration 最麻煩的地方，往往不是文章內容本身，而是那些已經在網路上存在很多年的舊 URL。
為什麼要離開 WordPress？
主要有兩個原因。
第一，長期 hosting 持有成本與維護成本。
WordPress 很方便，但它需要 PHP、資料庫、外掛、登入後台、更新維護，也會持續面對 wp-login.php、xmlrpc.php、舊外掛漏洞等掃描。對一個主要用來寫文章的個人 Blog 來說，這些成本有點重。
Hugo 的好處是輸出 static rendered pages。部署出去的是 HTML、CSS、圖片與少量 JavaScript。沒有資料庫，沒有 WordPress 後台，也沒有 PHP runtime。長期來看更便宜、攻擊面也更小。
第二，我想把寫作流程自動化。
我平常很多內容先寫在 Obsidian，理想流程是讓 AI agent 自動整理筆記，做 body clean，移除帳號、密碼、token、內部路徑等敏感資訊，再轉成 Hugo Markdown 發佈到 Blog。
簡單說：
原因也很誠實：我很懶惰。
能讓工具自動處理的事情，就不要每次手動複製貼上。
真正的坑：Cloudflare 看到一堆 3xx、4xx
上線後我查看 Cloudflare AI Crawl Control，發現大量 3xx、4xx。
一開始以為是 bot 或 CDN 設定問題，後來一看 path 就知道答案了：舊 WordPress permalink 全部失效。
舊網址長這樣：
/yyyy/mm/dd/post-slug
Hugo 新網址則變成：
/posts/post-slug/
文章內容雖然搬好了，但搜尋引擎、外部連結、AI crawler、書籤和歷史引用還是會打舊 URL。
如果舊 URL 沒有處理好，搜尋引擎和 AI crawler 看到的不是「你成功搬家」
而是「一堆內容消失了」
我的處理順序
這次我把問題分成幾個層級處理：
5xx 是伺服器錯誤，優先級最高。這次沒有明顯 5xx。4xx 是舊文章找不到，這會直接影響使用者與搜尋引擎，所以先修。3xx 本身不是錯，但要確認沒有 redirect chain、redirect loop，或是最討厭的 301 -> 404。
批次修復：用 SQL、Hugo 內容與 Cloudflare CSV 比對
手動一條一條修 redirect 會瘋掉，所以我用三份資料做批次比對：
- WordPress export SQL
- Hugo
content/posts/*.md - Cloudflare 匯出的 4xx / 3xx path CSV
比對邏輯大致是：
先看 WordPress post_date
再比對 WordPress post_name 與 Hugo slug
再比對 WordPress title 與 Hugo title
高信心才自動產生 redirect
低信心保留 manual review
最後把高信心的舊文章 URL 匯入 Cloudflare Bulk Redirects。
正式結果是：
為什麼不用 JavaScript redirect？
Static HTML 當然可以用 JavaScript 讀 URL，再用 location.replace() 導到新頁。
但那比較適合補救真人使用者，不適合作為正式 SEO migration 策略。
搜尋引擎與 crawler 最好看到的是 HTTP 層級的 301，而不是先回一個 HTML，再期待 JavaScript 幫它跳轉。
所以這次我最後選擇 Cloudflare Bulk Redirects，當然類似這樣重覆性高、又粗重的活當然要交給 Claude 自動去處理，順便自動驗證處理之後的成果是否達成預期效果。
3xx 也要驗收
修完 4xx 之後，我又回頭 audit 3xx。
原因是 redirect 不是「有跳就好」，還要確認最後落點是正常頁面。
這次就抓到兩條舊分頁：
/page/7
/page/9
它們原本被導到不存在的新分頁，形成：
這種 301 -> 404 比單純 404 更容易被忽略，因為你會以為 redirect 已經修好了，實際上只是把錯誤藏到下一跳。
最後我把它們改導到文章列表：
這次最大的教訓
WordPress 搬到 Hugo，不只是「把文章轉成 Markdown」。
真正完整的 migration 至少要看這些項目：
靜態網站的好處很明確：便宜、快、攻擊面小，也更容易接上 AI agent 自動化流程。
但靜態網站不會自動記得 WordPress 的歷史包袱。
Migration 上線不是結束，Cloudflare、Search Console 和 redirect audit 才是收尾。
水很深，但有 AI agent 這艘船，很多原本會讓人放棄的細節，終於可以一段一段渡過去。
完整技術紀錄、Cloudflare 修補流程與驗收細節，我整理在這篇：
👉 https://blog.stanwu.org/posts/wp-to-hugo-migration-is-deeper-than-expected/
