Headless CMSとしてのWordPress

SSG（静的サイトジェネレーター）の盛り上がりとともに、WordPressをバックエンドでのみ使うサイトが増えた時期がありました。この記事はその2022年に書いたものです。当時の私は、フロントエンドにNuxt.jsやNext.js、バックエンドにWordPressという構成で新規サイトを立ち上げることはあっても、純粋なWordPressサイトの立ち上げは皆無になっていました。

その後どうなったかと言うと、私はこのブログをWordPressからAstroベースの構成に移行しました。つまり「WordPressをヘッドレス化する」のではなく「WordPressから出る」選択をしたわけです。2022年の主張を残しつつ、その答え合わせも含めて書き直します。

Headless CMSとしてのWordPressの強み（2022年の主張、今も有効）

Headless CMSと言えばContentfulなどのSaaSが有名ですが、それらと比較してもWordPressには大きなアドバンテージがあります。

• 認証機能やAPI（REST API / WPGraphQL）など、必要な機能が一通り揃っている
• プラグインによる拡張性が高い
• レンタルサーバーで動くのでランニングコストが安い
• 編集者にとって管理画面が馴染み深く、プレビュー画面を別途用意する必要がない
• 将来フロントエンドもWordPressに戻すニーズが出ても対応できる

この評価は2026年も変わっていません。REST APIもWPGraphQLも健在で、ヘッドレスWordPressは今も普通に有効な選択肢です。

WordPressで実現可能なのに、わざわざLaravelなどで管理画面を自作する必要性も、相変わらず薄いと思っています。それは「車輪の再発明」や「開発者のエゴ」になり得ます（私自身はLaravelでの開発は大好きです笑）。

では、なぜ自分はWordPressから出たのか

このブログは長年WordPressで運用していましたが、現在はAstroと、データベースを直接使うCMSの構成で動いています。移行した理由は、突き詰めると2つです。

ひとつは、動的サイトとしてのWordPressの保守から解放されたかったこと。本体・プラグイン・PHPの更新、セキュリティ、バックアップ。1人で複数サイトを見ていると、この維持コストが地味に積み重なります。

もうひとつは、フロントエンドを完全にコードで持ちたかったこと。テーマのカスタマイズではなく、普通のWebフロントエンド開発としてサイトを作りたい。これはヘッドレスWordPressでも実現できますが、その場合「WordPressの保守」は残ります。コンテンツの置き場所ごと変えてしまえば、保守対象はひとつ減ります。

なお、移行時は旧URL（/blog/記事ID/）から新URLへ301リダイレクトを張り、検索エンジンの評価を引き継いでいます。この手の移行はリダイレクト設計が一番大事です。

判断の軸（2026年版）

整理すると、こういう判断になると思います。

• 既存のWordPress資産が大きい、編集チームがWordPressに慣れている → ヘッドレスWordPressは有力。コンテンツと編集環境はそのままに、フロントだけモダンにできる
• 動的サイトのままで困っていない → 無理にヘッドレス化する必要はない。WordPressは今もWebの大きなシェアを支える成熟したCMSです
• エンジニアが新規で作る、保守先を減らしたい → WordPressに固執する理由は薄い。最初からヘッドレスCMSやデータベース直結の構成も検討に値する

「ノーコードでサイトが作れる」という出自から、WordPressにはどこか初心者的な響きがつきまといますが、Headless CMSとしても普通に優秀です。一方で、私のように「出る」決断をしても、REST APIやエクスポート機能のおかげで移行先に困らないのもWordPressの良さでした。入るも出るも自由なのは、オープンソースの強さだと思います。