Headless WordPress を Next.js または Astro で運用し、wp-admin は保持しつつ、プラグイン依存を排除する。

Headless WordPress が正しい選択になるのは 3 つの条件のいずれかが当てはまる場合です。デフォルトの Classic WordPress セットアップが間違っているわけではありませんが、Headless は実装のオーバーヘッドを増やすため、正当な理由なしに導入すべきではありません。

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

2 番目の理由は、エディトリアルチームを失わずにエンジニアリング体験を向上させることです。TypeScript を日々書くエンジニアは WordPress フロントエンドスタックに不満を感じます。PHP テンプレート、jQuery、ページビルダーのショートコード、言語が間違っている、ツーリングが間違っている、デプロイ戦略が間違っている。Headless なら、エンジニアチームは 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 は時々わたしたちの意見と合わない判断を含むからです。ただしフレームワークに決定を委ねたい場合、Faust は優れた選択肢です。

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 を非公開サブドメイン cms.yourdomain.com で運用し、Cloudflare Access または IP ホワイトリストで保護。パブリックトラフィックは WordPress に直接到達しません。WordPress は公開ウェブから見えなくなり、エディタだけが存在を知ります。

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

コンテンツは明らかです。すべてのポスト、ページ、カスタムポストタイプ、タクソノミー、ACF フィールドを WPGraphQL でビルド時またはリバリデーション時に取得します。メディアは次です。すべてのアップロード画像を、WordPress 側の WebP 最適化がある場合はそれを、ない場合はフロントエンド側の画像最適化を使用。SEO メタデータは 3 番目で、Yoast または Rank Math フィールドをプラグイン連携 GraphQL スキーマで橋渡しし、型付きレスポンスから canonical、title、description、OG、Twitter card をレンダリング。

スキーマは 4 番目で、ほとんどのチームはこれを間違えます。わたしたちはプラグインが吐き出す JSON-LD を、クリーンな出力のためフロントエンドの手書きテンプレートで置き換えます。Article、BlogPosting、Service、Product、BreadcrumbList、すべて型付きデータから生成され、ビルド時に検証。リダイレクトは 5 番目です。Yoast Redirect Manager またはRedirection プラグインのすべてが、vercel.json または Netlify の _redirects 経由で 301 として出荷されます。JavaScript リダイレクトとしてではなく、ランキングシグナルの喪失を避けるため。

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

ページビルダーが最初に壊れます。Elementor と Divi はフロントエンドに大量の CSS と HTML を注入します。その一切は Headless フロントエンドでは動きません。ほとんどのマイグレーションはプロジェクトの一部としてコンテンツ書き換えを含め、コンテンツを抽出し、新しいフロントエンドのコンポーネントライブラリに合わせて再フォーマットし、ビジュアルビルダーレイヤーの取り込みはスキップ。エディタは 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% 削減されます。これは退行ではなく、勝利の一部です。