Next.jsまたはAstro上のヘッドレスWordPress — wp-adminは残す、プラグイン税は払わない。

ヘッドレスWordPressは3つのうち1つが当てはまるときが正解。そうでなければデフォルトのクラシックWordPress構成が正解 — ヘッドレスはエンジニアリングのオーバーヘッドを増やすので、実際の理由がない限り支払うべきではない。

最初の理由はパフォーマンスです。バニラなWordPressサイトに5～6個のプラグインを入れると、H1がレンダリングされる前に約700キロバイトのJavaScriptが配信されます。ElementorやDiviに典型的なアドオンスタックを加えたサイトは、初回ロードで2～3メガバイト配信されます。最高のキャッシングプラグインを前に置いても、LighthouseとCrUXフィールドデータには厳密な上限があります。ヘッドレスなStaticまたはISR Next.jsやAstroフロントエンドなら、Lighthouse 95以上をシェアードホスティングで一貫して達成でき、フィールドデータもそれに続きます。

第2の理由は、編集チームを失わずにエンジニアリング体験を得ることです。TypeScriptを日々書くエンジニアは、WordPressフロントエンドスタックに不満を感じます。PHPテンプレート、jQuery、ページビルダーショートコード――言語が違う、ツールが違う、デプロイの流れが違う。ヘッドレスなら、エンジニアチームはNext.jsやAstroコードベースでバージョン管理、型チェック、エッジデプロイ、コンポーネント駆動設計を行いながら、編集者はwp-admin、Yoast、ACFをそのまま使い続けられます。

第3の理由はマルチデスティネーションです。マーケティングサイト、モバイルアプリ、社内ポータル、パートナーポータルが全て同じコンテンツソースから読み込みます。従来のWordPressは1つのCMS、1つのフロントエンドです。ヘッドレスWordPressは編集バックエンドになり、必要なあらゆるデスティネーションに対応し、それぞれのサーフェスに最適化された独自のフロントエンドフレームワークで動作します。

エンジニアリングストーリーの大部分は3つの決定によって決まります。

フロントエンドフレームワークは通常、マーケティングサイトや認証・インタラクティビティを持つアプリにはApp Router付きのNext.jsです。Astroは静的生成に利点があり、特定のコンポーネントでのみ部分ハイドレーションが必要なコンテンツ量が多いサイトの最もシンプルなパスです。チームが既にVueを運用している場合、Nuxtが適切な選択肢です。私たちはFaust.jsではなくNext.js + WPGraphQL + 小規模なカスタムスキャフォルディングをデフォルトとしています。Faust.jsは私たちが同意しない見解を搭載しているからですが、フレームワークに決定させたい場合はFaust.jsは優れています。

APIレイヤーはデフォルトでWPGraphQLです。型付きクエリ図形API、WPGraphQL for ACFを通じたACFサポート、Yoast SEO for WPGraphQLを通じたYoastサポート、RankMath相当。WP RESTはプラグイン不要で動作し、シンプルなサイトなら問題ありません。ただし必要以上にデータを取得する上、フロントエンド側でスキーマ内省がありません。ホスティングポリシーでWPGraphQLが阻止された場合か、非常に小規模なデータセットの場合にのみRESTを使用してください。

ホスティングはフロントエンドとバックエンドを分離します。フロントエンドはチーム好みに応じてVercel、Netlify、またはCloudflare Pagesに。バックエンドはCloudways、Kinsta、またはWP Engineにnon-publicサブドメイン（cms.yourdomain.com）で、Cloudflare AccessまたはIPアローリストの背後に。パブリックトラフィックがWordPressに直接ヒットすることはありません。WordPressはパブリックウェブから見えなくなります。編集者だけが存在を知っています。

成功したヘッドレスWordPress構築は、5つのものをWordPress側からパブリックフロントエンドに忠実度を失わず輸送します。

コンテンツが明らかなものです――すべてのポスト、ページ、カスタムポストタイプ、タクソノミー、ACFフィールドを、ビルドまたはリバリデーション時にWPGraphQLで取得します。メディアはその後です。すべてのアップロード画像で、WordPress側のWebP最適化が利用可能なら、または利用不可なら代わりにフロントエンド側の画像最適化。SEOメタデータが3番目です――Yoastまたはランクマスフィールドをプラグイン付属GraphQLスキーマを通じてブリッジし、型付きレスポンスからcanonical、title、description、OG、Twitterカードとしてレンダリングします。

スキーマが4番目で、ほとんどのチームはこれを間違えます。私たちはプラグインが発行するJSON-LDをフロントエンド側の手書きテンプレートで置き換え、クリーンな出力にします。Article、BlogPosting、Service、Product、BreadcrumbList――すべて型付きデータから生成され、ビルド時に検証されます。リダイレクトが5番目です。Yoast Redirect ManagerまたはRedirectionプラグイン内のすべてがエクスポートされ、vercel.jsonまたはNetlifyの_redirectsで301として配信され、transit中にランキング信号を失うJavaScriptリダイレクトにはなりません。

輸送は自動化されています。サイトごとにこれらのレイヤーを手作業で構築することはありません。同じスキャフォルディングがすべてのヘッドレス構築に対応するため、エンジニアリングサーフェスが増えたにもかかわらず、サイトあたりのコストは時間とともに低下しています。

ページビルダーが最初に壊れます。ElementorとDiviは大量のCSSとHTMLをフロントエンドに注入します。それらはヘッドレスフロントエンドでは実行されません。ほとんどの移行では、プロジェクトの一部としてコンテンツ書き換えを実施します。コンテンツを抽出し、新しいフロントエンドのコンポーネントライブラリに合わせて再フォーマットし、ビジュアルビルダーレイヤーのインポートは完全にスキップします。エディターはGutenbergブロックとACF flexible contentに基づいた、新しくてシンプルな編集UXを得ます。コンテンツは残り、ビジュアルビルダーは消え、結果としてページの重さが大幅に削減されます。

コメントとフォームも再考が必要です。ネイティブなWordPressのコメントは、レンダリングをプロキシしなければヘッドレスでレンダリングされません。ほとんどのチームはDisqus、Giscus、またはフロントエンド上のカスタムコメントシステムに置き換えます。フォームは一般的にConvertKit、HubSpot Forms、またはメール送信サービスを呼び出すカスタムNext.jsエンドポイントに移行します。Contact Form 7とGravity Formsはヘッドレス対応版を備えていますが、作業量を増やす明示的なGraphQL統合が必要です。

フロントエンドプラグインが3番目に壊れるものです。WordPressフロントエンドにHTMLやJavaScriptを注入するもの、つまりセキュリティプラグイン、キャッシングプラグイン、スキーマプラグイン、ソーシャルシェアプラグインなどはすべて機能しなくなります。各プラグインはフロントエンド上のコードか、マネージドサービスで置き換えられます。プラグイン数は移行後に通常70～80%削減されます。これは後退ではなく、メリットの一部です。