WordPress から EmDash への移行ガイド

段階的なインポート、メディア検証、カスタムコンテンツの明確な計画で、WordPress サイトを EmDash に移行します。

WordPress から EmDash へ移行するのは、まずテーマの再現ではなくコンテンツとスキーマのプロジェクトとして扱うときが最も楽です。コンテンツを移し、メディアと構造を検証し、データモデルが安定してからカスタムレンダリングとデザインのパリティに取り組みます。

始める前に

インポートを実行する前に、移行元がどのような WordPress サイトか把握してください。

まず次を確認します。

  • 標準の投稿と固定ページ
  • メディアの添付
  • カスタム投稿タイプ
  • カスタムフィールドと編集用メタデータ
  • Gutenberg ブロックまたはショートコード中心のコンテンツ

単純な公開サイトは通常きれいにインポートできますが、カスタムブロック、プラグイン生成フィールド、特殊なフロントレンダリングに大きく依存するサイトは、インポート後に第二の実装パスが必要になります。

インポートの選択肢

WordPress のコンテンツを EmDash に取り込む合理的な方法は二つあります。

WXR エクスポート

ファイルベースの移行フローを望む場合は WXR エクスポートを使います。

通常、次のようなときに適しています。

  • 持ち運べるエクスポート成果物が欲しい
  • 複数人がソースのエクスポートをレビューまたはアーカイブする必要がある
  • ソースデータと移行先の検証の間に明確な境界が欲しい

典型的な流れ:

  1. WordPress 管理画面を開く。
  2. サイトコンテンツを WXR ファイルとしてエクスポートする。
  3. そのエクスポートを使って EmDash でインポートを開始する。
  4. インポートされたエントリとメディアを確認する。

EmDash Exporter プラグイン

稼働中の WordPress から直接移したい場合は EmDash Exporter プラグイン を使います。

典型的な流れ:

  1. WordPress サイトにプラグインをインストールする。
  2. 提供される安全なエクスポートエンドポイントを設定する。
  3. WordPress アプリケーションパスワードでアクセスを保護する。
  4. 保護されたソースから EmDash へインポートを実行する。

ソースサイトがまだ運用されており、エクスポートファイルを回し回すより直接プルしたい場合に適した選択です。

推奨の進め方

多くのチームにとって最も安全な順序は次のとおりです。

  1. コンテンツを受け取る EmDash サイトを用意する。
  2. インポート方法を一つ選び、第一パスの移行を実行する。
  3. エントリとメディアが正しく到着したか検証する。
  4. 汎用の編集コンテンツのままにすべきでないものには、適切な EmDash コンテンツタイプを作成する。
  5. インポートされたコンテンツ構造が信頼できることを確認してから、カスタムレンダリングを再構築する。

この順序により、最もリスクの高い作業は、データが EmDash で見えてレビュー可能になってからになります。

インポート後の検証

移行の成否はインポートが完了したかではなく、インポートされたコンテンツが使えるかで判断してください。

最初の検証では次を確認します。

  • 投稿と固定ページが想定件数で存在する
  • 添付メディアが EmDash のメディアライブラリに取り込まれている
  • タイトル、本文、公開メタデータが妥当に見える
  • インポート後も編集上の関係が意味をなす

WordPress コンテンツの EmDash へのインポート

この段階では、見た目の細部を先に直したくなる衝動に抗ってください。コンテンツモデルがまだ間違っていると、デザイン作業は高価なやり直しになります。

カスタムコンテンツ

WordPress サイトはしばしばデフォルトの PostPage モデルを超えて成長します。カスタム投稿タイプを使っている場合は、書式の問題ではなく移行中のスキーマの判断として扱ってください。

EmDash では、独自の構造に値するコンテンツにはネイティブのコンテンツタイプを作るのがよいアプローチです。通常、次を見直します。

  • 標準の編集エントリのままにすべきコンテンツ
  • 別の EmDash コレクションにすべきコンテンツ
  • 本文に暗黙のままにせず明示的にモデル化すべきフィールド

移行の質はここで上下します。技術的には成功しても、あらゆるコンテンツ形状を汎用エントリに潰すと、弱い EmDash 実装になりがちです。

ブロックと独自レンダリング

カスタムブロックは意図的に扱ってください。旧サイトが独自の Gutenberg ブロック、ショートコード駆動のレイアウト、プラグイン固有のレンダリングに依存しているなら、フォローアップ作業を想定してください。

妥当なアプローチは次のとおりです。

  • まず根底のコンテンツをインポートする
  • 移行後も残すべきレンダリングパターンを特定する
  • EmDash ネイティブのツールとコンポーネントでそれらを再構築する

独自ブロックの挙動を再現する必要がある場合は、EmDash Block Kit Agent Skill が出発点になります。

実践チェックリスト

作業用の移行チェックリストとして使ってください。

  • WordPress で投稿、固定ページ、メディア、カスタム投稿タイプを監査する
  • WXR と EmDash Exporter プラグインのどちらがよいインポート経路か決める
  • 移行先の EmDash サイトを用意する
  • 最初のインポートを実行する
  • メディア転送とエントリの整合性を検証する
  • 必要に応じてネイティブの EmDash コンテンツタイプを作成する
  • 第二の実装パスが必要なカスタムレンダリングを特定する
  • ビジュアルパリティに着手する前にコンテンツ構造をレビューする

まだ計画が必要なこと

インポート経路がきれいでも、一部の移行作業はインポータの外に残ります。

  • リダイレクト
  • SEO パリティの確認
  • フィールドの整理
  • カスタムレンダリングのパリティ
  • ロールバックと公開の順序

インポートはコンテンツを EmDash に入れます。編集レビュー、スキーマの判断、公開の規律の必要性を消すわけではありません。