チームがこの決断に至る理由は三つに集約されます。まともなホスティングでもWordPressのエディタが遅い、誰がインストールしたか分からないプラグインで管理画面が膨れ上がっている、テーマを変えてもCore Web Vitalsが改善しない。ヘッドレス構成への移行は万能薬ではありませんが、パフォーマンス、セキュリティ、編集フローのコントロールを取り戻せます。以下は、検索順位や数ヶ月分の編集作業を失わずにWordPressから離れたいというクライアントに対して、私たちが適用しているレシピです。早すぎる最適化や全面書き換えの誘惑を避け、段階的に進めることが重要です。
-
監査。何も触る前に全てを棚卸しします。コンテンツタイプ(投稿、固定ページ、カスタム投稿タイプ)、カスタムフィールド(ACF、Meta Box)、タクソノミー、プラグイン由来のショートコード、総投稿数、著者別の内訳をすべて確認します。1万2千件の投稿のうち半分が廃止されたプラグインのショートコードを使っているなら、計画はそれに左右されます。各項目を件数と新システムでの行き先と一緒にスプレッドシートに記録し、関係者全員で共有します。この棚卸しが移行の地図になります。
-
スタック選定。頻繁に更新し著者が複数いるサイトには、Next.jsとSanityやContentfulのようなヘッドレスCMSを推奨します。編集者が一人か二人の技術ブログなら、静的MarkdownとDecap CMSの方が安く、速く、Gitでバージョン管理できます。経験則として、編集者が非技術者で毎日公開するならCMSに投資し、開発者か週次更新ならMDで十分です。レンダリングはNext.jsのISRかAstroの静的書き出しが定番で、サイトの更新頻度で選びます。
-
エクスポート。クリーンなJSONを得るためにWP REST APIを使い、メタデータを保持する必要があればWXRを使います。よく出る痛点は三つあります。本文に埋め込まれた添付ファイルID、WordPressだけが解決するoEmbedショートコード、生HTMLと混在するGutenbergブロックのJSON。これらをMarkdownや移行先のCMSスキーマに正規化するトランスフォーマーをNodeで書き、テストデータで動作確認してから全件に流します。
-
URLマップ。現行サイトの公開URLをすべて列挙し、新サイトでの正規URLを決め、301リダイレクト計画を作ります。ここを飛ばすと数ヶ月分のオーガニックトラフィックを失います。マップは元、先、想定ステータスコードの三列のCSVで管理し、CDNやNext.jsのリダイレクト設定に流し込めるようにしておきます。古いカテゴリやタグのページも忘れずに含めます。
-
メディア。画像はwp-content/uploadsにリダイレクト経由で残すか、S3やCloudflare R2に移してsrcsetを書き換えます。数百MBを超えるサイトはCDNへの移行が正解で、LCPの改善はほぼ即時に現れます。next/imageやastro:assetsで再最適化する場合は、AVIFとWebPの両方を用意し、古いブラウザにはJPEGをフォールバックします。
-
並行運用期間。staging.domain.comに新サイトを立てrobots.txtでnoindex指定、編集者にアクセス権を渡し、二、三週間テストしてもらいます。プレッシャーなくバグを潰せる貴重な時間です。プレビュー機能、画像アップロード、下書き保存、公開ワークフローを実際の記事で試し、フィードバックを集めて反映します。
-
カットオーバー。低トラフィックの時間帯にDNSを切り替え、新しいサイトマップをSearch Consoleで検証し、再インデックスを依頼します。最初の48時間はクロール統計と404エラーを注意深く監視し、漏れたリダイレクトを即座に追加します。古いドメインのキャッシュTTLは事前に短くしておくと切り替えがスムーズです。
-
編集者トレーニング。新CMSのセッションを録画し、リポジトリ内のREADMEかNotionにフローを文書化し、サポート連絡先を明示します。最初の二週間は質問が集中するので、専用のチャットチャンネルを開けておくと安心です。
移行しないもの。10年前のコメントスレッド、空のカテゴリページ、壊れたアフィリエイトリンク、誰も読んでいない古いお知らせ。移行は、もはや席を占める価値のないものを捨てる最良の機会です。残すか捨てるかの判断基準はシンプルで、過去12ヶ月で訪問があり、現在のサービス内容と矛盾しないものだけを連れて行きます。