把 WordPress 部落格遷移到 Hugo、11ty 或 Obsidian 時，在後台「工具」裡按下「匯出」，得到的卻是一個 XML 檔案而不是 Markdown。很多人卡在這一步。遷移的路徑不只一條，最快的路取決於你有多少篇文章、手上有什麼環境。這篇文章比較三條路徑，帶你看每一步操作，也整理那些容易忽略的後處理。
選哪條路徑遷移
先給結論判斷：
- 數十到數百篇要一次搬完，本機能跑 Node.js — 路徑 A（wordpress-export-to-markdown）
- 想在伺服器端全搞定，有管理者權限可以裝外掛 — 路徑 B（匯出外掛）
- 只有幾篇文章，沒有 Node.js 也不能裝外掛，或內容不能外洩 — 路徑 C（瀏覽器內轉換，免費、免註冊、不上傳）
路徑 C 與其說是「遷移」，不如說是「轉換」——靈活度高的手段。但如果只是想先搬一篇草稿，或從離職同事留下的內部 WordPress 裡救回幾篇文章，路徑 C 最快。
為什麼匯出的 XML 不是 Markdown
WordPress 後台的「工具」→「匯出」會下載一個 WordPress eXtended RSS（WXR）XML 檔案在新分頁中開啟。這個格式把文章、固定頁面、分類、標籤、留言等全部包在一起，而文章正文是以 HTML 形式嵌在 XML 裡面。也就是說，匯出完的狀態是「XML 殼裡的 HTML」，要變成 Markdown 需要兩道轉換。
另外，用區塊編輯器（Gutenberg）寫的文章，正文中區塊的分隔以 HTML 註解的形式序列化。WordPress 官方區塊編輯器架構文件在新分頁中開啟中說明，一個段落的儲存形式如下：
<!-- wp:paragraph -->
<p>歡迎來到區塊的世界。</p>
<!-- /wp:paragraph -->
[gallery] 這類 Shortcode 也原封不動地留在正文中。這三層（XML 殼、區塊註解、Shortcode）怎麼處理，才是選擇路徑的核心。
遷移前確認 — 什麼保留、什麼消失
無論走哪條路徑，文章正文（標題、段落、列表、連結、表格、程式碼區塊）都會變成 Markdown。差異在 metadata。
- 發布日期、slug、分類、標籤都在 WXR 裡。路徑 A 會把它們寫進 frontmatter，但路徑 C 只處理你複製的正文 HTML，frontmatter 要自己加
- 讀者留言在哪條路徑都不會變成 Markdown 檔案。如果遷移後要保留顯示，需要另外遷到靜態網站的留言服務
- 自訂欄位的處理視工具而定。如果遷移後會用到特定欄位，先列清單確認你在用哪些欄位
路徑 A — wordpress-export-to-markdown 批次轉換
事實上的標準工具是 wordpress-export-to-markdown在新分頁中開啟。它接收 WXR 檔案作為輸入，為每篇文章產生帶 frontmatter 的 Markdown 檔案，同時下載正文中的圖片並改寫引用路徑（功能清單見 repo 的 README）。
- 在後台「工具」→「匯出」中選擇「全部內容」，下載 XML。
- 在裝有 Node.js 的環境中執行：
npx wordpress-export-to-markdown
互動式精靈會詢問：輸入檔案位置、輸出目錄、資料夾結構（--post-folders / --date-folders）、檔名是否加日期前綴（--prefix-date）、圖片保存方式（--save-images）、frontmatter 包含哪些欄位（--frontmatter-fields）。文章數量越多，這條路徑的批次優勢越明顯。
路徑 B — 用外掛匯出
想在伺服器端搞定，可以用 Static Site Exporter（原 Jekyll Exporter）在新分頁中開啟 這類匯出外掛。它會把文章和固定頁面打包成帶 YAML frontmatter 的 Markdown，以 ZIP 形式輸出，可以直接放進 Jekyll 或 Hugo。
注意兩點：裝外掛需要管理者權限；另外該外掛頁面本身也提到，規模大的網站從網頁介面執行容易超時，建議用命令行。部分主機還會碰到 PHP 記憶體上限的問題。
路徑 C — 純瀏覽器轉換
只有幾篇文章的話，零環境設定的瀏覽器內轉換最快。取得輸入有兩種方式：
- 在區塊編輯器中打開文章，從右上角選項切到「程式碼編輯器」，複製正文 HTML。這份 HTML 會包含
<!-- wp:paragraph -->等區塊註解 - 在瀏覽器中打開已發布的頁面，用開發者工具複製文章區域的 HTML。這是渲染後的 HTML，沒有區塊註解，但會帶上主題的包裝元素
複製好了就貼到 HTML 轉 Markdown 執行。
舉例來說，把程式碼編輯器複製的以下 HTML 貼上：
<!-- wp:heading -->
<h2 class="wp-block-heading">遷移檔案庫</h2>
<!-- /wp:heading -->
<!-- wp:image -->
<figure class="wp-block-image size-large"><img src="https://example.com/wp-content/uploads/2024/03/diagram.png" alt="架構圖" class="wp-image-42"/><figcaption class="wp-element-caption">圖 1：舊架構</figcaption></figure>
<!-- /wp:image -->
輸出如下：
## 遷移檔案庫
圖 1：舊架構
區塊註解、wp-block-* class、inline style 都會被移除，標題和圖片轉為 Markdown 語法。figcaption 的文字會以純文字留在圖片下方。<pre class="wp-block-code"> 程式碼區塊變成圍欄程式碼，表格變成管線表格。Shortcode 不是 HTML，所以不會被轉換，會以 \[gallery ids="12,13,14"\] 這樣轉義過的純文字形式留下（後處理節會講）。去除網頁複製的 span 與 inline style 的方法，可參考 HTML 貼上後轉 Markdown。
轉換全程在瀏覽器內的 JavaScript 中完成，貼上的內容不會傳送到任何外部伺服器。處理內部 WordPress 的文章或未公開草稿時，這個差別就很重要了。線上轉換的安全判斷基準見 轉換工具使用前必做的 5 項隱私檢查，HTML 轉 Markdown 的常見步驟整理在 HTML 轉 Markdown 指南。
遷移後後處理清單
不管走哪條路徑，以下四項最後都會要你動手：
- Shortcode 清理。
[gallery]、[caption]或外掛自訂的 Shortcode 不會變成 Markdown，會原樣留下。它們的形態不固定（有無屬性、包裹結構不同），比起一鍵全替換，在編輯器中搜尋[逐一判斷比較安全 - 圖片搬移。路徑 C 中圖片 URL 仍指向
wp-content/uploads。把圖片下載到新站並改寫 URL。srcset和loading="lazy"屬性在轉換時會被移除，需要的話在新平台上重新加 - 內部連結改寫。指向舊網域或舊永久連結結構（如
?p=123格式）的連結，要改成新站的 URL 規則 - 加上 frontmatter。把標題、日期、標籤以 YAML 形式放在檔案最前面。各 SSG 的格式不同，查你目標 SSG 的官方文件即可。frontmatter 的 YAML 語法與常見陷阱詳見 Markdown frontmatter 格式與語法：YAML 轉 JSON 的 5 個陷阱
比較 — 三條路徑怎麼選
| 路徑 | 適合規模 | 需要的環境 | Metadata | 圖片 |
|---|---|---|---|---|
| A: wordpress-export-to-markdown在新分頁中開啟 | 數十到數百篇批次遷移 | Node.js + WXR 匯出 | 自動寫入 frontmatter | 下載並改寫引用 |
| B: 匯出外掛 | 想在伺服器端搞定 | 管理者權限（裝外掛） | 自動寫入 frontmatter | 視外掛而定 |
| C: HTML 轉 Markdown | 幾篇的臨時遷移 | 只要瀏覽器（免費、免註冊） | 手動加上 | URL 保留，手動搬移 |
常見問題
不用 Node.js 也能把 WordPress 文章轉成 Markdown 嗎？
可以。能裝外掛就走路徑 B，不能就走路徑 C。把文章切到程式碼編輯器檢視、複製 HTML、貼到 HTML 轉 Markdown，完全不需要建置環境。
Gutenberg 的區塊註解在轉換後還留著嗎？
FormatArc 的轉換中，<!-- wp:paragraph --> 這類 HTML 註解不會出現在輸出中。另外，這些註解只存在於程式碼編輯器複製的 HTML 中；從已發布頁面複製的 HTML 本來就沒有。
圖片也能一起遷移嗎？
路徑 A 有下載正文中圖片並改寫引用的功能（README在新分頁中開啟 有記載）。路徑 C 只轉格式，圖片 URL 仍指向原站。如果只有幾篇，手動保存圖片再改 URL 比較實際。
未公開草稿或內部 WordPress 的內容貼到外部工具安全嗎？
會傳送到伺服器的工具，一貼上內容就離手了。FormatArc 完全在瀏覽器內處理，不發生任何傳輸。
舊版經典編輯器寫的文章也能用同樣步驟遷移嗎？
可以。經典編輯器的正文是不含區塊註解的純 HTML，轉換反而更簡單。路徑 A、B、C 都能處理。
總結
WordPress 到 Markdown 的遷移，取決於規模和環境。數百篇批次遷移用 wordpress-export-to-markdown，想留在伺服器端就用匯出外掛，只有幾篇、不想建置環境、或涉及機密就用 HTML 轉 Markdown 的瀏覽器內轉換。無論選哪條路徑，把 Shortcode 清理、圖片搬移、內部連結改寫、frontmatter 加上都納入遷移計畫中，不要留到最後才想起來。從 Notion 做類似遷移的話，Notion 匯出 Markdown 整理 也可參考。