ランキングを1つも失わない WordPress から Next.js への移行。

正直なところ、Lighthouseがそこまで到達することがないんです。

創業者たちに、Elementorで丁寧に作られたサイトがPageSpeed Insightsで62でベンチマークされ続ける理由を説明する朝は数えきれません。キャッシングプラグイン3つ、CDN、そして新しいホスティングに移行してからもです。天井があるんです。本気なら、クラシックなWordPressフロントエンドを低い80点代まで押し上げることはできますが、プラグインの更新のたびに回帰のリスクがあり、ページビルダーのリリースのたびに、あなたが望まなかった数百キロバイトがついてきます。

移行するチームを見ると、だいたい3つのグループに分かれていて、ほぼ重なることがありません。

パフォーマンスグループ

Series-A SaaS マーケティングサイト、現在WP Engineにいて、Elementor Proと3つのアドオンパックに課金中。モバイルでLighthouse 64。INP 380ms。コンテンツチームは週に2つのポストを出荷し、エンジニアリングチームはWordPatchではなくオンボーディングフローを出荷したいと考えています。Next.jsの再構築で96に到達でき、エンジニアはwp-adminに触らなくなります。

エンジニアリンググループ

TypeScript エンジニア3人。そのうち1人はマーケティングサイトのオンコール中。wp-adminは2週間に1回開き、呪います。「これはPHP 7.4か8.1か、エージェンシーは何バージョンのWooCommerceを残したのか」というルーチン全体が、Astroで気軽に出荷できればいいのにと思う人たちへの税金です。移行して、彼らにNext.jsまたはAstro レポをプロパーCI付きで渡せば、オンコール回転はより小さくなります。

セキュリティグループ

一般的ではありませんが、より決定的です。公開しているサーフェスがPHPを実行してはならないという取締役会レベルの強制力。あるいは、パッチ済みプラグインが3週間遅れで出荷されたセキュリティインシデント。非公開オリジンのHeadless WordPressはポリシーを満たし、編集チームに新しいCMSを学ばせることなく済みます。wp.example.comはプライベートになり、フロントエンドはVercelの静的サイトだけです。ほとんどのペンテストは興味深くなくなります。

3つです。本当に3つ、マーケティングページのような同じスコープに崩壊するものではなく。それぞれが異なるチームに適しています。

パス1 — WordPressを残す、フロントエンドを置き換える

ヘッドレス。WPはエディタ表面のままです。Yoastは管理画面で機能し続けます。ACFは管理画面で機能し続けます。公開サイトはNext.jsまたはAstroで再構築され、WPGraphQLでコンテンツを取得します。エディターは移行日にURLバーに新しいフロントエンドドメインが表示される以外、ほぼ気づきません。これが最も一般的なパスです。最近の移行の約3分の2がこの方法で進みました。

適切な場合：編集チームがWordPressで満足している、エンジニアリングの問題が純粋にフロントエンドである、12000ページのYoastメタデータを移行したくない。

パス2 — WordPressを完全に離れる

すべてをSanity、Payload、Storyblok、またはContentfulに移行します。ローンチ時にWordPressをシャットダウンします。新しいコードベース、よりクリーンなコンテンツモデル、どこにもPHPがない。移行コストが高いのは、フロントエンドを再構築するのではなくコンテンツを移行しているからです。編集チームが特にWordPressから抜け出したい場合、またはコンテンツモデルがACFフレキシブルコンテンツで対応できるよりも厳密性が必要な場合に価値があります。

適切な場合：単にフロントエンドが異なるのではなく、実際に異なるCMSが必要。

パス3 — ハイブリッド

一部のコンテンツはWordPressに残り、一部は他の場所に移動します。実例パターン：ブログはWPに残ります。編集チームが成熟していてYoastが実際の仕事をしているから。プロダクトページはPayloadに移動します。スキーマが適切な関連性と検証を必要とするから。フロントエンドは両方のバックエンドから読み取る1つのNext.jsアプリです。アーキテクチャは複雑ですが、時々それが正しい答えです。

適切な場合：同じサイト上に2つの明らかに異なるコンテンツ形状があり、1つのCMSに無理やり当てはめるのが誰かの人生を悪くしている。

ここは移行が成功するか失敗するか決まるところです。そしてそれはチームが日常的にスキップする部分でもあります。完全なマップがなければ初日にランキングを失います。部分的なマップでも6週間かけてゆっくり失い、その間、その下落は単なる季節変動だと自分に言い聞かせています。

マップは、コードをシップする前に3つの独立したソースから構築されます。

1. Search Console エクスポート — 過去16ヶ月間にGoogleがクロールし、インデックス可能と判断したすべてのURL。これはGoogleが現在あなたのドメインで見つけることを期待しているものの正規リストです。
2. AhrefsまたはSemrushエクスポート — 少なくとも1つの参照ドメインが指しているすべてのURL。参照ドメイン数でソート済み。これらは301保持が最も重要なURLです。バックリンクが200個あるページを404にしてしまえば、200個のバックリンクを捨てたことになります。
3. WordPress サイトマップ — 現在のXMLサイトマップエクスポート。バックリンクまたはオーガニックトラフィックがない可能性があるものの、構造内にまだ存在するページをキャッチします。最初の2つが見落とした何かを見つけるための3番目のパスとして有用です。

3つのリスト、重複排除済み、新しいURLにマッピング済み、vercel.jsonまたはnetlify.tomlでエッジで301として配信。302ではなく。JavaScriptドリブンなリダイレクトではなく。メタリフレッシュではなく。本当に廃止されたURLは410を取得します。スラッグが変更されたURLは301を取得します。ビルドリンターは、マイグレーション前のURLがマップに含まれていない場合、デプロイを失敗させます。

5,000ページのマイグレーションが8週間で有機検索の60%を失うのを見てきました。リダイレクトマップが87%完成し、「残りは心配する価値がない」という状況でした。その13%は心配する価値がありました。いつもそうです。

初日のプラグイン監査。すべてのアクティブプラグインは4つのバケットのいずれかに分類され、バケットが作業を決定します。

そのまま保持

サーバー側で実行され、パブリックフロントエンドに触れることのないプラグイン。WP Migrate DB、BackWPup、サーバー側アナリティクス、ロール管理。訪問者にHTMLをレンダリングすることが仕事に含まれていないため、機能し続けます。通常、プラグイン数の約20～25%がここに該当します。

コードに置き換え

フロントエンドにHTMLまたはJavaScriptを注入するプラグイン。ほとんどのSEOプラグイン（メタデータトランスポート、フロントエンド出力はカスタム）。ほとんどのフォームプラグイン（Next.jsエンドポイントまたはConvertKit / HubSpot / Mailchimpに置き換え）。ほとんどのスキーマプラグイン（手書きテンプレートに置き換え、そのほうがクリーンなJSON-LDを出力します）。クッキーバナーはTypeScriptで書き直されます。通常、プラグイン数の約30～40%。

サービスに置き換え

サードパーティをラップするプラグイン。HubSpotエンベッドプラグインはHubSpot Forms APIコールになります。StripeペイメントプラグインはStripe Elementsになります。ZapierとMakeはWordpress外に存在するため、そのまま残ります。カウントの約10～15%。

完全に削除

WordPress フロントエンドが必要としたからこそ存在するプラグイン。キャッシングプラグイン（Vercel が対応）。ほとんどのセキュリティプラグイン（公開攻撃面は消滅）。パフォーマンス最適化プラグイン（ビルド時の懸念事項に）。そして常に面白い「なぜここにあるのか見当もつかない、2年間無効化されているが削除されたことがない」グループ。WordPress 側のプラグイン数は移行後は通常 70～80% 減少する。これが勝利の一部だ。

プレビューとドラフト

エディターが wp-admin で Preview をクリック。WordPress が JWT プレビュートークンを生成。Next.js フロントエンドがトークンを読み込み、静的キャッシュをバイパスして WPGraphQL 経由でドラフトを取得し、レンダリング。ドラフト URL に署名が入り、インデックス不可、公開キャッシュされない。ワンクリックプレビュー UX は全く同じままだ。ほとんどのエディターは編集側では移行日を気づかない。

コメント、リビジョン、ロール

バックエンド側は変更なし。投稿のコメントは WordPress ネイティブのままにして WPGraphQL 経由でヘッドレスレンダリングするか、チームが望むなら Disqus / Giscus / カスタムシステムに置き換えるか選べる。リビジョンは変わらない — すべての投稿は WordPress エディターから完全な履歴にアクセス可能なまま。ユーザーロール、権限、マルチオーサーセットアップはすべて保持される。

YoastとRank Math

どちらも転送する。Yoast SEO for WPGraphQL はすべてのフィールド — フォーカスキーワード、メタタイトル、メタディスクリプション、canonical、OG、Twitter カード、スキーマブレッドクラム — を照会可能な GraphQL として公開。Rank Math には同等のものがある。Next.js レイアウトが型付きレスポンスを読み込み、Yoast または Rank Math が従来の WordPress で出力したのと同じメタタグをレンダリング。エディターは同じプラグイン UI で編集を続け、移行は彼ら側からは見えない。

第1週：ディスカバリーとスコーピング

プラグイン監査。コンテンツ監査。Search Console + Ahrefs エクスポートでリダイレクトマップのソース作成。現在のパフォーマンスベースライン。パス 1 対パス 2 対ハイブリッドの決定。成果物：固定価格とマイルストーン支払いスケジュール付きの書面化された SOW。第 1 週末までに、支払う対象が正確に分かっている。

第2～4週：基盤構築

リポジトリは GitHub にあり、当社のものではない。ホスティングはあなたのアカウント。WPGraphQL（または新 CMS）が設定済み。Next.js または Astro スキャフォルディング船積み。SEO リンターとリダイレクトマップ取り込みが配管済み。デザイントークン移行済み。第 4 週末までに基礎は実際に存在し、チームはページをシップしている。

第5～10週：構築

テンプレートはページごとにポート。リード エンジニアからの毎日の Loom があなたの Slack に。週次中盤ビルドレビューコール。Linear または Jira または既に使っているもので チケット。エッジケースは出現時にキャッチ。これはプロジェクトの退屈な中間で、実装コードのほとんどが書かれるところだ。

10～12週目：ローンチ前QA

手動でクロスブラウザー。モバイル監査。WCAG AA のアクセシビリティ監査。実デバイス Core Web Vitals（ラボの Lighthouse ではない）。SEO リンター緑。スキーマバリデーター緑。リダイレクトマップ検証済み URL 対 URL で Search Console エクスポート。カットオーバープラン書面化と実施。

12週目：ローンチ

選択したウィンドウで DNS カットオーバー。ほとんどは火曜日または水曜日の朝、低トラフィック。フロントエンドは既にステージングドメイン上で実行中。カットオーバーは DNS フリップ。エンジニアリングが 24 時間待機。新しいサイトマップで Search Console 送信。Ahrefs と GA に注釈。

12～16週目：ハイパーケア

インデックスの異常、リダイレクトチェーンの警告、スキーマエラーについて日々Search Consoleを監視する。トラフィックをベースラインと照らし合わせて週次で比較する。バグ修正を機能追加より優先する。16週目までにサイトは安定し、クリーンハンドオフするか、継続的なケアプランへ移行するかのいずれかになる。