トラフィックを失わずにWordPressからヘッドレスCMSへ移行する

ファイルではなく、参照です。画像は依然としてwp-content/uploadsにあり、別途移動させる必要があります。

ファイルを信頼する前に確認する価値がある2つのことがあります。

• サイズ。 非常に大規模なサイトは、エクスポートの途中でPHPの制限に達し、一見有効に見えるのに切り詰められたファイルを生成します。XML内の投稿数をwp_postsと比較してください。
• エンコーディング。 ASCII以外の文字を含む記事を、端から端まで確認してください。インポート後に見つかったエンコーディングのバグは、解きほぐすのが悲惨です。

#ステップ3——まずコンテンツモデルを設計する

直感的には、インポートしてから整理したくなります。順序を逆にしてください。

8つのカスタムフィールドを持つWordPressの投稿は、構造化CMSではたいてい2つか3つの適切なタイプになります。その形をインポート前に決めてください。さもないと、そこから抜け出すためにわざわざ選んだシステムに、WordPressのモデルを持ち込んでしまうことになります。

corpusctlには組み込みのコンテンツタイプがありません。パネルまたはAPIから定義し、フィールドはロールを持ちます——title、slug、bodyです。ロールは、あなたがどう名付けたかにかかわらず、システムがどのフィールドが見出しかを知る手段であり、それこそが、読了時間や目次といった計算フィールドを設定なしで機能させるものです。

典型的なマッピングは次のとおりです。

多言語対応はフィールドの属性であって、複製サイトではありません。WPMLやPolylangを使っていたなら、その構造がシンプルになるのがこのステップです。

#ステップ4——インポートをドライラン（試験実行）する

corpusctlのインポーターモジュールはWXRを読み込み、ドライランモードを備えています。何も書き込まずにプランを生成します。

レスポンスには、作成される予定のエントリーに加えて、それぞれの理由が付いたskippedとwarningsが含まれます。両方を読んでください。黙ってスキップされるというのは、2カ月目になって400件の投稿が届いていなかったと気づく、その原因です。

インポートの制限には理由があります——パーサーはDOCTYPE／ENTITY宣言を含むXMLを一切受け付けずに拒否します。それがXML爆弾のベクトルだからです。そしてサイズの上限を超えるファイルは、メモリにストリーミングされるのではなく拒否されます。エクスポートがどちらかに引っかかるなら、分割してください。

そのうえで本番として実行し、件数を突き合わせてください。投入した投稿数、出てきた投稿数を、タイプごとに。

#ステップ5——フロントエンドを再構築する

これは最大のタスクであり、通常のウェブプロジェクトです。したがって、移行に固有の助言はURLについてのものだけです。

できる限り、URLの構造を保持してください。 保持するURLはどれも、書かずに済む1つのリダイレクトであり、移さずに済む1つのランキングシグナルです。現在の構造が/2019/03/some-post/で、それが気に入らないとしても、それを変えるのは別のプロジェクトです——URLの再構築をCMS移行に抱き合わせないでください。両方が失敗したら、どちらが原因かわからなくなります。

読み取り側では、corpusctlのクライアントはAPIを呼び出しません。公開済みのコンテンツは公開時に不変でハッシュアドレス指定されたファイルに書き込まれ、クライアントはスラッグをローカルでマニフェストのシャードへと解決し、そのアドレスをnginxのエッジキャッシュから取得します。リクエストは2回、どちらもキャッシュ可能で、いずれもデータベースに触れません。

ブロックレンダラーはデフォルトスタイルをいっさい持たずに提供されるため、あなたのデザイン作業はあなたのデザイン作業のままです——CMSは、争うことになるCSSをいっさい持ち込みません。

#ステップ6——リダイレクト、忘れがちなものも含めて

古いURLはどれも、新しい場所への301が必要です。人々が書き出すリストは次のとおりです。

• 投稿とページ

人々が忘れるリストは次のとおりです。

• 添付ファイルページ（/some-post/image-name/）——WordPressはメディアアイテムごとに1つ生成し、Googleはそれらをインデックスしています
• フィード——/feed/、/comments/feed/、カテゴリーごとのフィード
• カテゴリー、タグ、著者、日付のアーカイブ
• ページ分割されたアーカイブ——/page/2/、/page/3/ …
• ?p=123と?page_id=123というクエリ文字列形式
• 大文字や末尾スラッシュのバリエーション。古いサーバーがそれらを受け付けていた場合

URLの一覧は、サイトマップからではなくSearch Console（ページレポート）からエクスポートしてください。サイトマップはあなたが公開しようとしたものであり、Search ConsoleはGoogleが実際に見つけたものです。

#ステップ7——切り替えて検証する

トラフィックの少ない時間帯に本番公開し、その後2週間監視してください。

Search Console——カバレッジで404の急増や「除外された」ページを、パフォーマンスをページタイプ別に分けて、あるテンプレートが他より多く失っていないかを確認します。

サーバーログ——クロールログは、Googlebotが何にアクセスし、何を受け取っているかを教えてくれます。ログ内の404は、あなたが見落としたリダイレクトであり、その日のうちに直せばコストはかかりませんが、1カ月後に直すとランキングという代償を払います。

Core Web Vitals——ラボスコアではなく、フィールドデータです。ここは、ヘッドレス移行が本物の改善を示すことが多い場所です。キャッシュから配信される事前ビルド済みのコンテンツには、隠すべき遅いオリジンがないからです。

WordPressのインストールは、少なくとも1カ月は削除しないでください。リンクを外し、noindexの状態で稼働させたままにしておけば、ページが以前どう見えていたかを確認できます。

#正直に言って、何が壊れるか

編集者はプレビューについて不満を言うでしょう。 WordPressはCMSの中でプレビューします。ヘッドレスのプレビューは、ドラフトモードを介してあなたのフロントエンドを経由します。切り替え前にそれを配線しておかないと、編集チームは初日に気づきます。まずそれを配線してください。（corpusctlのドラフトモードヘルパーは、シークレットを定数時間比較で検証し、確認済みの相対パスでないスラッグをすべて拒否します。これにより、手作りのプレビューエンドポイントの大半が抱えるオープンリダイレクトの穴をふさぎます。）

ショートコードは残留物を残します。 プラグインがレンダリングしていたものはすべて、インポートされた本文に生のテキストとして現れます。インポート後、コーパス全体を[で検索してください。

コメント。 WXRはそれらをエクスポートしますが、ほとんどのヘッドレスCMSにはそれらを置く場所がありません。コメントが重要なら、切り替えの後ではなく前に、第三者のサービスを計画してください。

最初の1カ月は遅くなります。 10年もたてば、人々はWordPressの中で何がどこにあるかを知っています。それを見込んでおき、同じ週にローンチを予定しないでください。

関連記事： corpusctl対WordPress · ヘッドレスCMSのSEO：トラフィックはどこで漏れるか · ヘッドレスCMSとは？