WordPress のブログを Hugo や 11ty、Obsidian に移そうとして「ツール」から「エクスポート」を押すと、出てくるのは Markdown ではなく XML ファイルです。ここで手が止まる方は多いはずです。移行のルートは 1 つではなく、記事の件数と手元の環境によって最短路が変わります。この記事では 3 つのルートを比較し、それぞれの手順と、忘れがちな後処理までまとめます。
どのルートで移行するか
先に結論の判定表です。
- 数十〜数百件をまとめて移行したい。手元で Node.js を動かせる — ルート A（wordpress-export-to-markdown）
- サーバー側で完結させたい。プラグインを追加できる管理者権限がある — ルート B（エクスポート系プラグイン）
- 対象は数記事だけ。Node.js もプラグインも使えない、あるいは社外に出せない記事を扱う — ルート C（ブラウザ内変換、無料・登録不要・アップロードなし）
ルート C は「移行」というより「変換」に近い小回りの手段ですが、下書きの 1 本だけ先に移したい、退職者の残した社内 WordPress から記事を救出したい、といった場面では最短です。
エクスポートした XML がそのまま Markdown にならない理由
WordPress の管理画面で「ツール」から「エクスポート」を実行すると、WordPress eXtended RSS（WXR）と呼ばれる XML ファイル別タブで開きますがダウンロードされます。投稿・固定ページ・カテゴリ・タグ・コメントなどをまとめて含む形式で、記事本文はこの XML の中に HTML として埋め込まれています。つまりエクスポート直後の状態は「XML の殻に入った HTML」であり、Markdown へは二段階の変換が必要です。
さらにブロックエディタ（Gutenberg）で書いた記事の本文には、ブロックの区切りが HTML コメントとして直列化されています。WordPress 公式のブロックエディタ設計ドキュメント別タブで開きますにある通り、段落 1 つが次のような形で保存されています。
<!-- wp:paragraph -->
<p>ブロックの世界へようこそ。</p>
<!-- /wp:paragraph -->
[gallery] のようなショートコードも本文に埋め込まれたままです。この 3 層（XML の殻・ブロックコメント・ショートコード）をどう処理するかが、ルート選びの本質です。
移行前に確認 — 何が引き継がれ、何が消えるか
どのルートでも記事本文（見出し・段落・リスト・リンク・表・コードブロック）は Markdown になります。差が出るのはメタデータです。
- 投稿日時・スラッグ・カテゴリ・タグは WXR に含まれます。ルート A はこれらを frontmatter として書き出しますが、ルート C はコピーした本文 HTML だけを扱うため、frontmatter は自分で付けます
- 読者コメントはどのルートでも Markdown ファイルにはなりません。移行後も表示したい場合は静的サイト向けコメントサービスへの載せ替えが別途必要です
- カスタムフィールドの扱いはツール依存です。移行後に必要な値があるなら、事前にどのフィールドを使っているか棚卸ししておきます
ルート A — wordpress-export-to-markdown で一括変換
英語圏・日本語圏の両方で定番になっているのが wordpress-export-to-markdown別タブで開きます です。WXR ファイルを入力に取り、記事ごとに frontmatter 付きの Markdown ファイルを生成し、本文中の画像もダウンロードして参照を書き換えてくれます（機能一覧は同リポジトリの 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 にそのまま持ち込みやすい形式です。
注意点は 2 つです。プラグインの追加には管理者権限が必要なこと、そして同プラグインのページにも記載がある通り、規模の大きいサイトでは Web 画面からの実行がタイムアウトしやすく、コマンドライン実行が推奨されていることです。ホスティングによっては PHP のメモリ上限にも当たります。
ルート C — ブラウザだけで変換する
数記事だけなら、環境構築ゼロのブラウザ内変換が最短です。入力の取り出し方は 2 通りあります。
- ブロックエディタで記事を開き、右上のオプションから「コードエディター」に切り替えて本文 HTML をコピーする。この HTML には
<!-- wp:paragraph -->などのブロックコメントが含まれます - 公開済みページをブラウザで開き、開発者ツールなどで記事部分の HTML をコピーする。レンダリング後の HTML なのでブロックコメントは含まれず、代わりにテーマ由来のラッパー要素が付いてきます
コピーしたら HTML to 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"> のコードブロックはフェンス付きコードに、表はパイプ表になります。ショートコードは HTML ではないため変換されず、\[gallery ids="12,13,14"\] のように角括弧がエスケープされた平文として残ります（後処理の節で扱います）。
変換はすべてブラウザ内の JavaScript で完結し、貼り付けた内容はどこにも送信されません。社内 WordPress の記事や未公開の下書きを扱うとき、アップロード型の変換 SaaS との違いが効いてきます。この観点はオンライン変換は安全かで詳しく扱っています。なお、変換の基本操作は HTML を Markdown に変換するガイド、Word やブラウザからの貼り付け整形の一般パターンは HTML 貼り付け Markdown 化にまとめてあり、本記事は WordPress 固有の話に絞ります。
移行後の後処理チェックリスト
どのルートを通っても、次の 4 点は最後に手を入れることになります。
- ショートコードの掃除。
[gallery][caption]やプラグイン独自のショートコードは Markdown 化されず残ります。属性付き・囲み型など形が一定でないため、一括置換ではなくエディタで[を検索して 1 つずつ判断するのが安全です - 画像の移設。ルート C では画像 URL が
wp-content/uploadsを指したままです。移行先に画像をダウンロードして URL を書き換えます。srcsetやloading="lazy"属性は変換時に落ちるため、表示側で必要なら移行先の仕組みで付け直します - 内部リンクの書き換え。旧ドメインやパーマリンク構造 (
?p=123形式など) を指すリンクを、移行先の URL 規則に合わせます - frontmatter の付与。タイトル・日付・タグを YAML で先頭に付けます。SSG ごとの形式の違いは Markdown frontmatter の YAML と JSONが参考になります
比較 — 3 ルートの使い分け
| ルート | 向いている規模 | 前提環境 | メタデータ | 画像 |
|---|---|---|---|---|
| A: wordpress-export-to-markdown別タブで開きます | 数十〜数百件の一括移行 | Node.js + WXR エクスポート | frontmatter に自動出力 | ダウンロードして参照書き換え |
| B: エクスポート系プラグイン | サーバー側で完結させたい | 管理者権限（プラグイン追加） | frontmatter に自動出力 | プラグイン依存 |
| C: HTML to Markdown | 数記事のスポット移行 | ブラウザのみ（無料・登録不要） | 手動で付与 | URL は残るが手動移設 |
よくある質問
Node.js を使わずに WordPress 記事を Markdown 化できますか
できます。プラグインを追加できるならルート B、できないならルート C です。記事をコードエディター表示にして HTML をコピーし、HTML to Markdown に貼り付ければ、環境構築なしで 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 to Markdown のブラウザ内変換が最短です。どのルートでも、ショートコードの掃除・画像の移設・内部リンクの書き換え・frontmatter の付与という後処理までを移行の範囲に含めて計画してください。Notion からの移行で同じ考え方を使う場合は Notion エクスポートを Markdown に整形も参考になります。