ヘッドレスCMSとは？WordPressとの違いを制作会社が実務目線で解説

ヘッドレスCMSとは、コンテンツの管理機能と表示機能を切り離したCMSのことだ。通常のWordPressは「記事を書く場所」と「記事を表示する場所」が一体になっているが、ヘッドレス構成ではCMSはAPIでデータを返すだけの裏方になり、表示は別のフロントエンド（AstroやNext.jsなど）が担当する。

結論を先に言うと、ヘッドレスCMSで成果を出すには「本文入りの生HTML」「記事ごとに正しいcanonical」「サイトマップへの個別URL掲載」の3点を、設計の最初の段階で仕込んでおく必要がある。ここを後回しにすると、表示は速くモダンなのに、検索エンジンからはほとんど存在しないサイトになるリスクがある。この記事では、その想定される落とし穴と対処、どういうサイトにヘッドレスが向くのかの判断基準を、制作会社の実務目線で書く。

ヘッドレスCMSと通常のWordPressの違い

「ヘッドレス」のヘッドとは表示部分（フロントエンド）のことだ。頭（表示）を切り落として、胴体（コンテンツ管理）だけを使うからヘッドレスと呼ぶ。

通常のWordPressは、記事の保存も、テーマによる表示も、1つのサーバーの中で完結する。ユーザーがアクセスするたびにPHPが動き、データベースに問い合わせて、HTMLを組み立てて返す。

ヘッドレス構成では役割が分かれる。

コンテンツ管理: WordPressやmicroCMSなどが担当し、記事データをAPIで返すだけ
表示: AstroやNext.jsなどのフレームワークが、APIから記事を取得してページを生成する
配信: 生成済みの静的HTMLをサーバーやCDNに置いて配信する

実務上の違いは主に4つある。

表示速度: 事前に生成した静的HTMLを返すだけなので、PHPとデータベースを毎回動かすWordPressより構造的に速い
セキュリティ: 公開サーバーに置くのは静的ファイルだけなので、WordPress本体への攻撃経路を表から隠せる
編集体験: 記事を書く人の画面はWordPressのままにできる。編集者は違いに気づかないまま運用できる
構築コスト: フロントエンドを別途開発するため、テーマを当てるだけの通常構築より工数がかかる

なお「ヘッドレスCMS」というと microCMS や Contentful のような専用サービスを思い浮かべる人が多いが、既存のWordPressをそのままAPIサーバーとして使う「ヘッドレスWordPress」という選択肢もある。すでにWordPressで記事資産があるサイトのリニューアルでは、この形が現実的になりやすい。

ヘッドレスCMS導入で起こりやすい落とし穴：検索に載らないサイトになるリスク

ヘッドレス構成でもっとも注意すべきなのは、レンダリング方式の選び方だ。フロントエンドをCSR（クライアントサイドレンダリング）、つまりブラウザ側のJavaScriptが記事本文を描画する方式で組んでしまうと、次のような事態が起こりうる。

記事ページの生HTMLに本文が存在しない。JavaScriptが動いて初めて本文が描画されるため、検索エンジンから見ると「ほぼ空のページ」に見える
canonical（正規URL指定）の実装が甘いと、全記事のcanonicalがトップページを指してしまい、「この記事の正体はトップページです」と検索エンジンに申告し続ける状態になる
サイトマップの生成をフロントエンド側に任せきりにすると、ブログ記事の個別URLが1件も載らないまま運用が進んでしまう

この3つが重なると、記事を何本公開してもGoogleにほとんど届かない、表示が速いだけの「存在しないブログ」ができあがる。ヘッドレスCMSの解説記事で「SEOに強い」と書かれることがあるが、それは本文入りHTML・canonical・サイトマップを正しく実装した場合の話で、そこを怠ると通常のWordPressより遥かに弱くなる。WordPressなら何もしなくても本文入りのHTMLが返るのに、ヘッドレスではそれすら設計しないと手に入らない。

実際、この3点のどれか一つでも欠けた状態で運用してしまうと、記事を14本公開してもサイトマップに個別URLが1件も反映されない、といった状況になり得る。当社でも構成を検証した際にこの状態を確認したことがあり、その場ではrobots.txtへのサイトマップ宣言追加とcanonicalの修正という応急処置で、Search Console上で120ページが検出される状態まで回復させた。だからこそ、この3点は応急処置ではなく最初の設計段階で仕込んでおくべき項目だと考えている。

この落とし穴を防ぐ設計原則：SSG（事前生成）で作る

上記のリスクを防ぐには、フロントエンドの生成方式をSSG（静的サイト生成）にするのが土台になる。SSGとは、アクセス時ではなくビルド時にWordPressから記事を取得し、本文入りの完成したHTMLをあらかじめ全ページ分生成しておく方式だ。

同じヘッドレスでも、レンダリング方式で検索エンジンからの見え方が全く変わる。

CSR（クライアントサイドレンダリング）: ブラウザのJavaScriptで描画。生HTMLは空になりやすく、ブログには不向き
SSR（サーバーサイドレンダリング）: アクセス毎にサーバーで描画。常駐サーバーが必要でコストが上がる
SSG（静的サイト生成）: ビルド時に全ページ生成。本文入りHTMLが最初から存在し、配信も最速

Next.jsではなくAstroを選ぶ理由も実務的なものだ。

ビルドした静的ファイルをFTPでレンタルサーバーに上げる運用がそのまま使える。SSRは常駐サーバーが必須で、ホスティング環境の変更を強いられる
中小企業のコーポレートサイトやサロンのHPは更新頻度が低く、動的機能も薄い。SSGで十分であり、十分なら最速・最安の選択が正しい
学習コストが低く、制作の仕組み化・量産に向く

工数の実感値も書いておく。ヘッドレスSSG構成の初回設計・構築は9〜12.5人日を見ておくとよい。ただしテンプレート化してしまえば、2件目以降は1案件2〜4人日まで落ちる計算だ。初回の設計コストは重いが、量産フェーズに入ると通常のWordPress構築と競争できる水準になる。

ヘッドレスCMSが向いているサイト・向いていないサイト

ここまでの想定リスクと設計原則を踏まえて、判断基準は次のように整理している。

向いているサイト:

表示速度を営業上の武器にしたいサイト（速度はユーザー体験と広告品質スコアに直結する）
更新頻度が低〜中程度のコーポレートサイト・店舗サイト・LP
セキュリティ要件が高く、WordPress本体を表に出したくないサイト
同じ構成を複数サイトに横展開する予定がある会社

向いていないサイト:

予約システムや会員機能など、ページ内容がユーザーごとに変わる動的機能が主役のサイト
記事を公開した瞬間に反映されないと困る運用（SSGはビルドを挟むため数分のラグがある）
構築予算が限られていて、テーマ構築のWordPressで要件を満たせるサイト

正直に言えば、世の中の中小企業サイトの多くは通常のWordPressで十分だ。ヘッドレスは「速度・セキュリティ・横展開」のどれかに明確な狙いがあるときに選ぶ技術で、流行っているからという理由で選ぶものではない。

導入前に必ず確認すべきチェックリスト

上で挙げた落とし穴を防ぐためのチェックリストを置いておく。ヘッドレス構成の提案を受けたら、制作会社にこの項目を確認してほしい。

記事ページの生HTMLに本文が含まれるか（ページのソース表示で本文が見えるか）
各ページのcanonicalが自分自身のURLを指しているか
サイトマップに記事の個別URLが全件載っているか
WordPressで記事を更新したとき、何分で公開サイトに反映されるか。その仕組み（Webhookや定期ビルド）は用意されているか
ビルド時にWordPressが落ちていた場合の挙動（前回ビルドを保持するか）
旧URLから新URLへの301リダイレクトとcanonicalの統一が移行計画に含まれているか

特に最後の項目は重要だ。移行時に旧URLと新URLが両方生きていると、検索エンジンから見て同じ記事が2つ存在することになり、評価が分散する。旧URLと新URLの整理は、移行の後回しにせず、移行計画そのものに組み込んでおくことを推奨する。

まとめ：ヘッドレスCMSは「正しく完成させる」ことが全て

ヘッドレスCMSとは、コンテンツ管理と表示を分離する構成であり、速度・セキュリティ・横展開性に優れる一方、SEOの土台（本文入りHTML・canonical・サイトマップ）を自前で組み上げる必要がある技術だ。

ヘッドレスCMSの成否を分けるのは技術選定そのものではなく、検索エンジンから正しく見えるところまで設計と検証を完成させられるかどうかだ。本文入りHTML・正しいcanonical・サイトマップへの個別URL掲載という3点を最初から設計に組み込めば、表示速度とセキュリティを活かしながら検索流入も両立できる。

導入を検討している方は、まず自社サイトの更新頻度と動的機能の有無を確認し、上のチェックリストを制作会社との会話に使ってほしい。それだけで、「速いだけで誰にも見つからないサイト」になるリスクは大きく減らせるはずだ。