引っ越しの前日にやることといえば、荷造りの最終確認です。電気・ガス・水道の手続き、郵便の転送、新居の鍵。1つ抜けると、当日に困ります。サイトの引っ越しにも、同じ「最終確認」が欠かせません。その確認項目をまとめた移行チェックが、今回の主役です。
シリーズ「WordPressからEmDash移行」の第7回は、WordPressからEmDashへ切り替える前の、移行チェックリストです。記事の移行（第6回）のあと、公開する前に、何を確かめるのかを整理します。
移行チェックの結論：記事は「数」、見た目は「代表」、検索は「URL」で確かめる
結論から言うと、確認は次の3つの軸でやると、抜けにくくなります。
| 軸 | 確かめること |
|---|---|
| 数 | 投稿タイプとステータスごとの件数が、WordPressと合っているか |
| 代表 | Gutenberg、クラシックエディタ、ショートコードなど、代表的な記事が正しく表示されるか |
| URL | 旧URLにアクセスしたとき、新しい記事にたどり着けるか |
移行チェックリスト1：記事と画像
まず、公式の「Migrate from WordPress」にある、切り替え前の確認項目を、順番にたどります。
| 確認項目 | 見るところ |
|---|---|
| 件数 | 投稿タイプとステータスごとに、WordPressと件数を比べる |
| 代表的な記事 | Gutenberg、クラシックエディタ、ショートコード、ページビルダーの記事を開く |
| 画像 | アイキャッチと本文中の画像が、EmDashのURLで表示される |
| 作成者・分類 | 作成者、カテゴリー、タグ、カスタムタクソノミー、翻訳 |
| Exporterで取り込んだ場合 | メニュー、コメント、サイト情報、SEOの値 |
| 下書き | ログインしていない人から、未公開の下書きに、アクセスできない |
第6回で触れたとおり、予約投稿とプライベートは、すべて下書きとして入っています。そのため、公開してよいものかどうか、1本ずつ見直します。
移行チェックリスト2：テーマと表示
ただし、WordPressのテーマは、そのままではEmDashで動きません。そして、ページの表示は、Astroのページで作り直します。公式のドキュメントでは、アーカイブにgetEmDashCollection()、スラッグごとのページにgetEmDashEntry()を使うと説明されています。
そのため、作り直す前に、WordPressのサイトで、次を書き出しておくと楽です。
- 固定ページの構成と、メニュー
- 使っているショートコードと、ブロックの種類
- 表示しているウィジェット
- 使っているプラグインと、その役割
移行チェックリスト3：SEOとリダイレクト
つまり、検索結果からの流入を守るのが、切り替えでいちばん大事な部分です。EmDashの公式ドキュメントでは、次の機能が説明されています。
| 機能 | 中身 |
|---|---|
| SEOパネル | 記事ごとのタイトル、説明、画像、canonical、検索除外。コレクションでSEOを有効にして使う |
| サイトマップ | /sitemap.xmlと、コレクションごとのサイトマップ |
| robots.txt | 既定ではクローラーを許可し、/_emdash/を禁止し、サイトマップを参照 |
| 構造化データ | 記事ページにJSON-LD（BlogPosting） |
| リダイレクトと404ログ | 管理画面のRedirectsで設定。404の多いパスから、リダイレクトを追加できる |
さらに、リダイレクトは、301、302、307、308のどれかを選べます。移動元のパスには、名前付きの部分（/old/[slug]）や、残り全部を受ける[...path]が使えます。
リダイレクトの移動元のパスは、たとえば次のように書けます（公式のドキュメントの例）。
/old/[slug]
/old-blog/[...path]
注意したいのは、URLの形が変わる場合です。たとえば、WordPressの記事のURLと、EmDashのURLの形が違うなら、旧URLから新URLへのリダイレクトを用意しないと、検索結果のリンクが切れます。だから、移行の前に、旧サイトを巡回して、変わるURLの一覧を作るのが確実です。
一方で、YoastやRank Mathで設定していたSEOのタイトルと説明は、インポートで取り込めます。ただし、公式のドキュメントによると、これらはSEOパネルとは別の通常のフィールドに入るため、テンプレート側で出力する処理が必要です。
移行チェックリスト4：ドメインとログイン
そして、公開するドメインにも、確認が必要です。公式のデプロイの案内には、次のような注意があります。
- 最初は
workers.devのURLが割り当てられる - 独自ドメインは、同じアカウントでCloudflareが管理している、有効なドメインにする
- パスキーは、登録したホスト名でしか使えない。ドメインを変えると、パスキーの再登録が必要
- サイトのURLは、設定しないと、セットアップ時のURLが記録される。本番のドメインで初期設定をするか、あらかじめ
EMDASH_SITE_URLを設定する
つまり、初期設定（管理者の登録）は、本番に使うドメインでやるのが安全です。
移行チェックの進め方：優先順位をつける
ここまでの項目を、全部いっぺんに確かめるのは大変です。そこで、優先順位をつけて進めます。
まず、記事の件数と画像を確かめます。なぜなら、ここがずれていると、ほかの確認の前提が崩れるからです。次に、検索の流入に関わるURLとリダイレクトを確かめます。つまり、読者が迷わない状態を先に作るわけです。
その次に、テーマと表示を確かめます。ただし、見た目の細かい調整は、公開のあとに少しずつ直せます。しかし、URLの変更とリダイレクトは、公開の前に決めておかないと、検索結果からの流入に影響します。
また、確認の結果は、表に残しておくのがおすすめです。さらに、確認した日付と、確かめた人を書いておくと、あとで見返せます。そのため、チェックの表は、移行の記録としても役立ちます。
あるある：新居に引っ越したあと、旧居の鍵を返してしまう
引っ越しのあるあるを、もう1つ。新居の準備が完全に終わる前に、旧居の鍵を返してしまうことです。つまり、サイトなら、本番で問題なく動き、元に戻す必要がなくなるまで、バックアップとWordPressの環境を残しておくことにあたります。
また、公式のドキュメントにも、この考え方が書かれています。「本番で正常に動作し、ロールバックが不要になるまで、バックアップとWordPress環境を残す」。ごはんにたとえるなら、新しいお店の味が安定するまで、前のお店の味を、残しておくイメージです。
今回のまとめと次回予告
| 項目 | 内容 |
|---|---|
| 記事の確認 | 件数、代表的な記事、画像、作成者、分類、下書きの非公開 |
| 表示の確認 | テーマはAstroで作り直す。使っている機能を書き出しておく |
| 検索の確認 | SEOパネル、サイトマップ、リダイレクト。URLが変わるなら必須 |
| ドメイン | パスキーはホスト名ごと。本番ドメインで初期設定する |
| 戻れる状態 | 安定するまで、バックアップとWordPressを残す |
そして、次回は、切り替えたあとの運用を整理します。バックアップ、権限、AIとの連携、そして、このシリーズのまとめです。
ほかのCloudflare関連の記事は、当ブログの技術ネタからどうぞ。
参考
- EmDash公式ドキュメント「Migrate from WordPress」
- EmDash公式ドキュメント「Built-in SEO Features」
- EmDash公式ドキュメント「Deploy to Cloudflare」
ITもごはんも、腹八分目が長続きのコツ！
コメント