WordPressからNext.jsへの移行：ヘッドレスを優先するか、それともクリーンな移行か.

WordPress から Next.js へ移行できるものと、移行できないもの?

投稿、ページ、カテゴリー、タグ、メディア、ユーザーはデータとして移行されます。でも、テーマやプラグインは別です。ショートコードの出力も、そのまま移行されるわけではありません。構築を計画する前に、REST APIを確認してください。そこには /wp/v2/posts、/wp/v2/pages、/wp/v2/categories、/wp/v2/tags、/wp/v2/media、および /wp/v2/users があり、どのコンテンツタイプが実際に JSON を返すかを見られます。

レイアウト層は残ります。そして、ここが重いところです。編集者がブロックやページビルダーでページを作っている場合、「body」フィールドには生のHTMLやブロックマークアップが入っています。そのため、Sanityの「Portable Text」形式などにパースし、見た目のレイアウトを構造化されたフィールドへ分ける必要があります。フォームやスライダー、プラグイン由来のマークアップは再構築が必要です。SEOメタデータにも、エクスポートする経路を用意してください（後から探すと忘れがちです）。WPGraphQLは、その「seo」フィールドを通じて、Yoastのタイトルや説明文を公開しています。

ご自身のドメインで /wp-json/ を開いてください。次に、ページのソースコードを見ます。数分あれば、データの不備を一覧にできます。この診断では、コードを確定する前に、公開されている情報を解析し、マークアップ、ヘッダー、構造化データを記録します。見える範囲だけでも、手がかりは十分に集まります。

検索トラフィックを維持するために、URLマップやリダイレクトをどのように計画すればよいでしょうか?

各旧URLと新URLを1対1で対応させ、URLマップを作成してください。ここは推測しません。そのうえで、検索トラフィックが確実に該当ページへ流れるよう、サーバーサイドで恒久的なリダイレクトを設定します。Googleでは、旧URLを新URLに対応付けること、連鎖リダイレクトを避けること、新しいサイトマップを送信することが求められています。両方のURLでトラフィックを追跡することも必要です。そして、この対応付けを省くと、後は勘で直すことになります。

Next.js では、next.config.js の redirects オプションにルールを書いてください。まずテストです。permanent: true を設定すると 308 ステータスが返され、ブラウザや検索ボットが無期限にキャッシュしてしまうため、公開前に各ルールを確認してください。パスパターンはルートから一致します。そのため、「/old-blog/:slug」では「/old-blog/a/b」は捕捉されません。ネストされた URL には明示的なルールが必要です。パターンの守備範囲は、見た目より狭いのです。

リダイレクトは少なくとも1年間、有効にしておいてください。短く見ても、それくらい必要です。ステージング環境に残っている「noindex」タグや「robots.txt」のアクセス拒否ルールは、すべて削除してください。canonicalタグは新しいURLに設定します。ヘッドレスバックエンドが検索エンジンのクロールを制限している場合、各投稿のSEOフィールドが「noindex」を返すことがありますし、YoastのURLにCMSのホスト名が入ることもあります。ステージング環境に残った設定は、リリース失敗の原因になりますが、気づきにくいのが厄介です。

WordPressからのコンテンツの移行方法：エクスポート、API、またはクロール?

サイトのページ数が数ページを超えたら、API 経由でコンテンツを移行してください。理由は単純です。REST API は、投稿、ページ、タグ、カテゴリ、メディアを JSON 形式で返します。エンドポイントで省略されたデータについては、レンダリング済みの HTML をスクレイピングして取得するのが代替手段です。また、SanityのAPIパターンも参考になります。REST APIにクエリを送り、ドキュメントを書き出し、レスポンスがなくなるまでページネーションを繰り返すCLIスクリプトを実行します。

メディアリストは、デフォルトで1ページあたり10件の項目を返します。少ないです。そのため、スクリプトではフェッチループの中でpageとper_pageを設定する必要があります。Sanityのツールは変更処理をバッチ処理します。デフォルトではドライランが行われ、Studioのスキーマに基づいてドキュメントが検証されるため、レコードを書き込む前にエラーを見つけられます。決定論的なIDを使い、スクリプトを冪等にしてください。アセットは、p-limitなどのレート制限の下で並行アップロードします。安全に再実行できないスクリプトは、あとで怖くなります（本番で動かすときほど）。

ページビルダーがマークアップをレンダリングする場合は、その出力をクロールし、HTMLを解析して、記録された合計数をマスターURLリストと照合してください。見つけるのは、公開前です。データの欠落は、公開後には読者の問題になってしまいます。

Next.js では、WordPress と比べて編集者にはどのようなメリットがありますか?

ヘッドレス化する場合、編集者はWordPressの管理画面を引き続き使えます。一方、コンテンツを移行する場合は、新しいSanity StudioまたはContentfulエディタを使うことになります。でも、どちらの設定でも、編集者はテーマやページビルダーのビジュアルキャンバスを使えなくなります。編集対象はフィールドです。読者に表示されるページそのものを触るのではなく、フォームに入力して編集します。作業の感覚としては、かなり大きな変化です。

プレビューは、編集者から真っ先に指摘される問題です。だから、早めに見せてください。Next.js で下書きコンテンツを取得するプレビュールートを作り、公開前に最も作業が遅い編集者でテストを行ってください。ISR では、再検証ウィンドウ後の最初のリクエストでも、再生成が実行されている間は古いページが表示されます。質問される前に、その点をチームへ伝えておいてください。

プラグインも、影響を感じやすい部分です。SEO、フォーム、リダイレクト用のプラグインは新しいフロントエンドでは動作しなくなるため、各機能をフィールド、サービス、またはルーティングルールとして作り直す必要があります。ただし、見返りはあります。プラグイン更新で、編集者がフロントエンドを壊してしまう心配はなくなるのです。

WordPress から Next.js への移行にはどのくらいの時間がかかり、その作業量に影響を与える要因は何でしょうか?

移行にかかる時間は、URLの数、コンテンツの種類、メディアライブラリ、連携機能、およびロケールによって決まります。公開スキャンでは、具体的な日程は約束できません。できるのは、外側から各要因を数えることです。サイトマップからURL数を把握し、/wp-json/ルートからコンテンツの種類を確認し、フォームやスクリプトから連携機能を見ます。見積もりは、数えた後の話です。

各要因は、互いに効いてきます。1つのコンテンツタイプに多数のURLがある場合は、主にリダイレクト作業です。一方、少数のURLに多くのタイプが含まれる場合は、主にスキーマのモデリング作業になります。メディア一覧ページがデフォルトで10件ずつ表示されるなら、ライブラリが大きいほど数千件のリクエストが発生します。ロケールが増えるたびに、マッピングするURLの数も倍増します。私はこのような移行を計画し、実行していますが、いつも同じパターンがあります。時間がかかるのは、構築そのものではありません。コンテンツをどう構成すべきかを決める段階です。

ISR を使うと、サイト全体を再構築せずに、キャッシュされた静的コンテンツを更新できます。これは大きな差です。だから、ページ数が増えてもデプロイ時間が長くなるとは限りません。

WordPressからNext.jsへの移行を避けるべき場合?

サイトの状態が良好で、編集者が問題なく作業できており、新しいフロントエンドで解決できるようなアプリケーション、パーソナライゼーション、または編集上の問題がないなら、移行すべきではありません。まずは現状維持です。証拠によって状況が違うと分かるまでは、そのままで構いません。まず無料の診断を実行してください。スコアが80～100の範囲にある場合、現在の構築がボトルネックではないことを示しています。そんな状態で再構築しても、予算を使い、検索トラフィックを危険にさらすだけで、得られる見返りはほとんどないでしょう。

ヘッドレスWordPressは、編集者が管理画面を維持する必要があり、かつフロントエンドに問題がある場合にだけ、中間ステップとして検討する価値があります。そうでないなら、コンテンツ用にWordPress、ページ用にNext.jsという2つのシステムを運用することになります。しかも、両方に対してパッチ適用、ホスティング、監視が必要です。移行する場合は、サイトの用途に合わせてスタックを選んでください。コンテンツサイトやマーケティングサイトにはAstroが向いています。アプリケーションの運用、パーソナライゼーション、または大規模な編集チームがある場合は、SanityやContentfulと組み合わせたNext.jsが適しています。どの選択でも、編集者が慣れているものを手放します。ビジュアルキャンバス、プラグイン、ホスト型管理画面です。どれか1つではなく、3つすべてです。

よくある質問.

次に読む.

1. 01WordPressの代替サービス現状維持、ヘッドレス化、または移行：各ページの内容に基づいて判断されます。
2. 02WordPress から Astro へあらかじめ作成されたページ、Markdown形式のコンテンツ、またはヘッドレスCMS。
3. 03Next.js SEO監査レンダリングモード、メタデータ、ハイドレーションコスト。
4. 04ヘッドレスCMSのSEO監査レンダリング、canonical、プレビュー、テンプレート由来の構造化データ。