「WordPressをやめたい。でも記事が300本ある」。脱WordPressの相談で、いちばん最初に出てくるのがこれです。作り直しの見積もりより先に、中身をどう運ぶかが決まらない。

EmDashにはWordPressからの取り込み機能があるので、記事とメディアとタクソノミーは機械的に運べます。とはいえ全部が自動で片づくわけではなく、手が要る場所ははっきり決まっている。どこまで自動で、どこから人力なのかを先に把握しておくと、見積もりも工程も組めます。

入れ方は3つ。基本はWXRファイル

取り込みの入口は3種類あります。

  • WXRファイルのアップロード：WordPressの標準エクスポート（.xml）を読ませる。下書きも非公開記事もカスタムフィールドも入る、いちばん完全な方法
  • WordPress.com のOAuth連携：WordPress.comでホストしているサイト向け。ファイル書き出しなしで繋がる
  • REST APIプローブ：URLを入れると、WordPressかどうかと記事数を検出してくれる。あくまで事前確認用で、これ単体では完全な移行にならない

自己ホストのWordPressなら、実質WXR一択です。REST APIは「先方から資料が出てこないけど、だいたいの規模を知りたい」ときの調査に使う。ここを取り違えると、下書きが丸ごと落ちます。

書き出し元での操作は、WordPress管理画面の「ツール → エクスポート → すべてのコンテンツ → エクスポートファイルをダウンロード」。この.xmlがすべての起点になります。

インポートの流れは、ウィザードに沿って5段

EmDash側は「管理画面 → 設定 → インポート → WordPress」から。ファイルを渡すと、中身を解析して何が入っているかを出してくれます。

  • 検出：投稿127件、固定ページ12件、メディア89件、といった内訳が出る
  • マッピング：どの投稿タイプをどのコレクションに入れるか決める。既存コレクションに無いフィールドは自動で足され、型が衝突する場合は警告が出る
  • 実行：1件ずつ処理され、進捗が出る
  • メディア：本文の取り込み後、画像を落とすかどうかを選ぶ。WordPress側のURLからダウンロードし、内容が同じファイルは1つにまとめられ、本文中のURLも書き換わる
  • 確認：完了後に「成功・調整済み・失敗」のサマリが出る。失敗した記事は下書きとして残るので、後から手当てできる
WXRインポートの流れ。書き出す、解析する、マッピングを決める、実行してメディアを取り込む、リダイレクトを当てる

実務でありがたいのは、同じファイルで再実行しても重複しないことです。WordPress側のIDで突き合わせるので、失敗した回を作り直す必要がない。移行はたいてい一発で決まらないので、この性質は工程の組み方を変えます。テスト環境で通してから本番、という順番が踏めるわけです。

そのまま入らないものを、先に把握しておく

自動変換が効くのはここまでで、ここから先が人力です。見積もりに乗せるべきなのもこの部分。

本文はGutenbergのブロックがPortable Text（構造を保ったまま持つ本文形式）に変換されます。段落・見出し・画像・リスト・引用・コード・埋め込み・ギャラリーは、対応する形へそのまま移る。旧クラシックエディタのHTMLも、<strong> や <a> がマークとして引き継がれます。

問題は、変換表に無いブロックです。

  • 未知のブロックは htmlBlock として生HTMLのまま保持される。消えはしませんが、そのままだと構造を持たない塊なので、レビューして手で直すか、専用の表示コンポーネントを作る判断が要る
  • ACFのリピーター・フレキシブルコンテンツはJSONとして入る。使える形にするには、EmDash側に対応するフィールドを用意して詰め替える作業が発生する
  • プラグインの機能そのものは移らない。フォーム、会員機能、独自ショートコードは作り直しになる
自動で入るものと手が要るもの。本文と分類は自動、未知のブロックとプラグイン機能は手動

カスタムフィールドは値から型を推測してくれます。数字の文字列は数値、1 や true は真偽値、ISO形式の日付は日付、といった具合。_edit_ や _wp_ で始まる内部フィールドは既定で隠れ、SEOプラグインの項目は seo にまとまります。ACF風のフィールド設計をEmDash側でどう組むかはField Kitの記事に書きました。

カテゴリとタグは階層を保ったまま移ります。記事のステータスも対応していて、公開は公開、下書きは下書き、予約投稿は予約のまま入る。

順位を落とすかどうかは、リダイレクトで決まる

移行で技術的にいちばん怖いのは、実は本文ではありません。URLが変わることです。

WordPressの /2024/01/hello-world/ や /?p=123 を放置すると、積み上げてきた評価がそこで切れます。EmDashはインポート後にリダイレクトマップを出してくれるので、これを配信側へ適用します。

{
  "redirects": [
    {
      "from": "/?p=123",
      "to": "/posts/hello-world"
    },
    {
      "from": "/2024/01/hello-world/",
      "to": "/posts/hello-world"
    },
    {
      "from": "/category/news/",
      "to": "/categories/news"
    }
  ],
  "feeds": [
    {
      "from": "/feed/",
      "to": "/rss.xml"
    }
  ]
}

適用先は、Cloudflareのリダイレクトルール、ホスティング側の設定、Astroの redirects のいずれか。案件の構成に合わせて選びます。RSSの購読者を切らないよう、/feed/ の転送も忘れずに。

旧サイトは、移行が問題ないと確認できるまで動かしたままにしておく。リダイレクトの検証と並行して、リニューアルで順位を落とさないための手順も合わせて踏むと安全です。

詰まるのは、だいたい決まった場所

実際に手を動かすと引っかかるのは、この3つです。

  • XMLの解析エラー：書き出しが途中で切れている可能性が高い。WordPress側で書き出し直す
  • メディアのダウンロード失敗：認証の裏にある画像や、すでに消えている画像。処理自体は止まらず、失敗したURLが記録されるので後から手当てする
  • エクスポートが100MBを超える：投稿タイプごとに分けて書き出し、順番に取り込む

どれも致命傷にはなりませんが、知らないと当日に慌てます。移行日の前にテスト環境で1周しておけば、本番でやることは確認だけになる。

WordPressからの乗り換えを検討する段階の話は乗り換え先にEmDashという選択肢にまとめました。実際の移行では、記事の量よりも「変換表に無いブロックが何種類あるか」で工数が決まります。見積もりの前に、まずWXRを1本流してみるのがいちばん早い。

WordPressサイトのヘッドレス移行を検討中で、実装を任せられる相手を探している制作会社の方はお問い合わせからどうぞ。移行できるかどうかの事前調査だけでも承ります。

本記事は2026年7月時点の情報です。