WordPressからEmDashへ移行する方法｜URL・画像・SEOを崩さない手順

← Blogに戻る

WordPressからEmDashへの移行は、記事コピーではなく『サイトの役割を分解して移す作業』です

WordPressからEmDashへ移行する場合、記事本文だけをコピーして終わりではありません。結論を先に言うと、①コンテンツ、②画像、③URL、④SEO設定、⑤フォームや検索などの機能、⑥プラグインが担っている役割、⑦計測タグと外部連携を分けて移す必要があります。

EmDashにはWordPressからの公式インポート経路があり、WordPress管理画面から出力したWXRファイル、またはEmDash Exporterプラグインを使って既存コンテンツを移せます。ただし『データを取り込める』ことと『検索順位や問い合わせ導線まで同じ状態で移せる』ことは別です。

移行前にWordPressサイトの役割を棚卸ししてから進めるのが安全です。

EmDashとは｜WordPressの考え方を残しながら、AstroとCloudflare Workersで再設計されたCMS

EmDashはCloudflareが開発する無料・オープンソースCMSで、2026年9月に1.0がstable版として公開されました。CloudflareはEmDashをWordPressの『精神的後継』と位置づけています。

管理画面、テーマ、プラグインというWordPressで馴染みのある考え方を持ちながら、Astroをベースにし、拡張機能をWorker isolateで分離して動かすなど、現在のWeb実行環境に合わせた設計へ変えています。API、CLI、MCPも用意されているため、AIエージェントや外部ツールからコンテンツや設定を扱う構成も想定されています。

WordPressの編集思想を完全に捨てず、実行基盤を新しくしたい会社にとって候補になりやすいCMSです。

移行方法は2つ｜WXRファイルとEmDash Exporterの違い

Cloudflare公式が案内しているWordPressからEmDashへの移行方法は大きく2つあります。1つ目は、WordPress管理画面のエクスポート機能からWXR形式のファイルを書き出し、それをEmDashへ取り込む方法です。

比較的シンプルで、サイト規模が小さい場合や一度きりの移行に向いています。2つ目はEmDash ExporterプラグインをWordPressへ入れ、Application Passwordで保護された専用エンドポイントを通じて移行する方法です。

Cloudflareによれば、この方法では添付メディアもEmDashのメディアライブラリへ取り込めます。どちらを選んでも、移行前にWordPress側のバックアップを取り、ステージング環境で試すのが基本です。

ステップ1｜WordPressで使っている機能を『CMS標準・テーマ・プラグイン・外部SaaS』に分ける

最初に、現在のWordPressサイトで動いている機能を書き出します。投稿、固定ページ、カテゴリ、タグ、著者、画像のようなCMS標準機能だけでなく、問い合わせフォーム、検索、関連記事、SEO設定、キャッシュ、会員機能、予約、EC、SNS連携、広告タグ、アクセス解析なども含めます。

次に、それぞれがWordPress本体、テーマ、プラグイン、外部SaaSのどこで実現されているかを分けます。この作業をしないまま移行すると、記事は表示できてもフォームが動かない、構造化データが消える、パンくずがなくなる、計測が止まる、といった抜けが起きます。

移行先CMSの機能一覧を見る前に、現在のサイトが何をしているかを把握する方が先です。

ステップ2｜記事・固定ページ・画像をテスト移行し、件数と欠損を照合する

本番切り替え前に、まず記事・固定ページ・画像だけをテスト移行します。WordPress側の記事数、固定ページ数、カテゴリ数、タグ数、画像数を控え、EmDash側へ移した後に件数を照合します。

本文の見た目だけでなく、アイキャッチ、本文中画像、キャプション、リンク、公開日、著者、カテゴリなどが保持されているかも確認します。WordPressではテーマやプラグイン独自のショートコードが本文中に保存されていることがあるため、移行後に意味のない角括弧やコード片として残らないかも確認が必要です。

カスタム投稿タイプや独自フィールドを多用しているサイトは、標準記事とは別に変換設計が必要になる可能性があります。

ステップ3｜URLを先に固定する｜検索流入を守る中心作業は301リダイレクトです

SEO移行で最も重要なのは、CMS名ではなくURLです。現在Googleに評価されているURLをできるだけ維持し、変更するURLだけ旧URLから新URLへ301リダイレクトします。

WordPressではパーマリンク設定やカテゴリベース、日付、カスタム投稿タイプによってURL構造が決まっています。EmDash側で新しいURL設計を先に決め、旧URLと新URLの対応表を作ります。

全記事をトップページへ転送するような雑なリダイレクトではなく、原則として内容が対応するページ同士を1対1で結びます。移行後は旧URLへアクセスし、301で正しい新URLへ移動すること、さらに最終ページが200を返すことを確認します。

ステップ4｜title・description・canonical・OGP・構造化データを比較する

WordPressでYoast SEO、All in One SEO、Rank Mathなどを使っている場合、SEO設定は記事本文とは別のプラグインデータとして保存されていることがあります。移行時にはtitle、meta description、canonical、robots、OGP、Xカード、構造化データなどがどこから生成されているかを確認します。

新サイト側で同じ情報を自動生成できるなら、すべてを1件ずつ移す必要はありません。一方、記事ごとに個別設定しているtitleやdescriptionが多い場合は、移行対象として抽出する必要があります。

検索順位を守るためには『SEOプラグインを移す』のではなく、『検索エンジンへ出していた情報を新しい仕組みで再現する』と考える方が正確です。

ステップ5｜フォーム・検索・会員・ECなど、CMS以外の機能を別システムとして再設計する

WordPressではプラグインを追加することで、フォーム、サイト内検索、会員機能、予約、ECなどを同じ管理画面へ載せられます。EmDashへ移行する場合、これらをどこで実現するかを個別に決めます。

問い合わせフォームなら外部フォームサービスやWorker、検索なら専用検索サービス、ECならShopify等と分離する選択肢があります。分離は構成が複雑に見える一方、CMS更新がフォームや決済機能へ影響しにくくなる利点もあります。

移行計画では『WordPressプラグインXの代わりは何か』ではなく、『そのプラグインが担っている業務機能をどこへ置くか』という粒度で考えます。

ステップ6｜GA4・GTM・広告タグ・Search Consoleを切り替え前に確認する

CMS移行時に見落とされやすいのが計測です。GA4、Google Tag Manager、Meta Pixel、広告コンバージョンタグ、ヒートマップ、チャット、Cookie同意管理などがWordPressテーマやプラグインへ埋め込まれている場合、新サイトでは再設定が必要です。

ドメインを変えない移行でも、HTMLの出力元が変わればタグが消えることがあります。本番公開前にステージングでタグ発火を確認し、公開直後はGA4のリアルタイム、GTM Preview、フォーム送信、広告CVを実際にテストします。

Search Consoleについても、サイトマップURLやcanonicalの変化を確認し、新しいサイトマップを送信します。

切り替え当日｜DNSより先に『戻せる状態』を用意する

本番切り替え前には、WordPressサイトを一定期間残し、すぐ戻せる状態を用意します。データベースとwp-contentを含むバックアップを取り、旧サイトへアクセスできる退避先も確認します。

新サイトを公開した後は、代表的な記事、問い合わせフォーム、404ページ、サイトマップ、robots.txt、canonical、OGP、構造化データ、主要な内部リンクを確認します。特に数百ページ規模のサイトでは、全ページを人間が目視するのではなく、URL一覧を使ってHTTPステータス、リダイレクト、title、canonicalなどを自動検査した方が安全です。

『切り替えた後に考える』のではなく、異常があれば何分で旧サイトへ戻せるかまで決めておきます。

移行後7日間｜404・検索流入・フォームCVを毎日確認する

公開できた時点で移行は終わりではありません。最低でも最初の7日間は、404、5xx、リダイレクト、Search Consoleのクロール状況、主要ページのインデックス、検索流入、GA4、フォームCVを確認します。

SEO移行では、一時的にクロールや順位が揺れることがありますが、URL不一致やcanonicalミスを放置すると長期的な損失につながります。特に旧URLから流入の多かった上位ページ、問い合わせに貢献していたページ、被リンクが付いているページを優先して監視します。

CMSを変えたこと自体ではなく、ユーザーと検索エンジンが以前と同じ情報へ到達できているかが判断基準です。

EmDash移行が向いている会社・慎重にすべき会社

EmDashが向いているのは、WordPressのようなCMS体験を残したい、AstroやCloudflareの技術基盤を使いたい、プラグイン拡張を維持したい、AIエージェントとの連携も視野に入れたい会社です。一方、WordPressの特定プラグインに業務が強く依存している、WooCommerceや会員機能など複雑な機能を大量に持つ、社内・制作会社ともにEmDashの運用経験がない場合は、一括移行より小規模サイトやメディア部分から検証した方が安全です。

EmDash 1.0はstable版ですが、WordPressほど長い運用実績や日本語情報が蓄積しているわけではないため、新しさを利点として取れる体制かも選定条件になります。

一括移行が不安なら、まずメディア部分だけをEmDashへ移す

企業サイト全体を一晩で切り替える必要はありません。WordPressで会社情報やフォーム、会員機能を残しながら、まずブログ・ニュースなど比較的独立したコンテンツだけをEmDashへ移す段階移行も可能です。

サブドメインや特定パスで新環境を運用し、編集者の使い勝手、公開フロー、画像管理、表示速度、検索流入、障害対応を数週間から数か月確認します。その間に旧WordPressと新EmDashの運用工数を実測すれば、『新しいから良さそう』ではなく実データで全面移行を判断できます。

特にプラグイン依存が大きいサイトでは、記事領域と業務機能を分離するだけでも保守負荷を減らせる場合があります。段階移行では同一コンテンツを両方で公開しないようcanonicalと公開責任を明確にし、どちらが正本かを決めておくことが重要です。

段階移行中は旧WordPress側の更新を止める範囲と、新EmDash側で更新する範囲を文書化します。担当者ごとに判断が分かれると、同じ記事が二重更新されたり、片方だけ古い情報のまま残ったりします。

更新対象、公開責任者、切り戻し条件、検証期間終了日を決め、一定期間の結果を見てから次の領域へ広げると、全面移行よりリスクを抑えられます。その記録自体が、全面移行時の運用手順書になります。

FAQ｜WordPressからEmDashへの移行でよくある質問

Q. WordPressの記事と画像は自動で移せますか。A. Cloudflare公式はWXRまたはEmDash Exporterによるインポートを案内しており、Exporterでは添付メディアの取り込みにも対応しています。

ただし独自プラグインやカスタムフィールドは個別確認が必要です。Q. URLは変えなければいけませんか。

A. 必須ではありません。現在のURLを再現できるなら維持する方がSEO上わかりやすく、変える場合は301対応表を用意します。

Q. WordPressのテーマはそのまま使えますか。A. そのまま移すものではありません。

デザインやコンポーネントを新しいフロントエンドで再構築する前提で考えます。Q. PHP脆弱性が怖いので今すぐ移行すべきですか。

A. 緊急のセキュリティ更新とCMS移行は別です。まず現在利用中のPHP・WordPress・プラグインを安全な状態に更新し、その後に中長期の移行判断を行います。

まとめ｜EmDashへの移行は、WordPressの『中身』ではなく運用全体を移す

WordPressからEmDashへ移行する場合、WXRやEmDash Exporterによってコンテンツ移行の入口は用意されています。ただし企業サイトで本当に守るべきなのは、記事データだけではありません。

既存URL、検索評価、画像、フォーム、計測、外部連携、プラグインが担っていた業務機能まで含めて移行計画を作る必要があります。最初に現状を棚卸しし、テスト移行、URL対応表、SEO比較、機能再設計、ロールバック、移行後監視の順で進めれば、CMS変更を単なる作り直しではなくWeb運用基盤の再設計として進められます。

無料・約30秒

あなたのサイト、WordPressをやめられる？

URLを入れるだけで、移行難易度・デザインやSEOの維持しやすさ・推奨構成・概算費用を自動で簡易診断します。

↗