ヘッドレスCMSは全案件に必要ではない｜採用してよい条件と、WordPressのままでいい条件

ヘッドレスCMSの比較記事を何本読んでも、自社サイトをどうすべきかが決まらない。よくある行き詰まりです。

理由ははっきりしています。比較の対象が「ツール」になっているからです。microCMSとNewtとWordPress REST APIを並べても、それは採用が決まったあとの選択肢にすぎません。その手前にある「そもそもヘッドレスにするのか」が決まっていないと、どの表を見ても判断材料になりません。

先に結論を書きます。

中小規模のサイトで実際に選ぶべき対象は、CMSツールではなく「構成」です。選択肢は3つあり、そのうち2つはWordPressを普通に使ったままの構成です。

そしてヘッドレス化が効くのは、記事や実績のような「増え続けるページ」を数十本以上抱えているサイトに限られます。ページが10本前後で止まっているサイトは、ヘッドレスにしても得られるものがほとんどありません。

構成の比較と、採用・見送りの判断基準を順番に書いていきます。

まず比べるべき3つの構成

ツール名の前に、サイト全体の作りを3つに分けて考えます。

構成	表側の作り	記事の置き場	向くサイト	初期工数
①フルヘッドレス	静的サイトジェネレータでビルドした静的HTML	別ドメイン（サブドメイン）のWordPress	記事・実績が数十〜数百本あり、今後も増える	重い（実績で8〜13人日）
②分離同居	静的サイトまたはSPA	同じドメインの /wp/ 配下	表側のデザイン自由度が要る多店舗・多拠点	中（表側の制作量しだい）
③テーマ内包	WordPressテーマの中にデザインを持たせる	WordPress本体	ページ数が少なく、更新が文言差し替え中心	軽い（既存デザインを流用できる）

①だけがいわゆるヘッドレス構成です。②と③はWordPressをそのまま使います。

重要なのは、②と③でも「表示の速さ」と「デザインの自由度」はかなりの部分まで手に入るという点です。ヘッドレスでしか得られないものは意外と限られていて、そこを見誤ると工数だけが増えます。

ヘッドレスでしか得られないもの

①フルヘッドレスの本当の利点は、次の3つに集約されます。

1. ページ数が増えても表示速度が落ちない

ビルド時にHTMLを作りきってしまうため、記事が100本でも300本でも、訪問者に返すのは完成済みのファイルです。データベースへの問い合わせもプラグインの処理も、訪問のたびには走りません。

2. 表示の構造と、編集の仕組みを切り離せる

たとえば「お知らせ」と「ブログ」を管理画面上では別の投稿タイプとして分けたまま、サイト上では1つの新着一覧にまとめて見せる、といった構成が取れます。書き手の動作（お知らせは事務連絡、ブログはアイキャッチつきの発信）を変えずに、訪問者側の見え方だけを整理できる。これはWordPress単体では作りにくい形です。

3. 同じ型を横展開できる

設定ファイルに社名・電話番号・使うページのオン/オフをまとめておけば、2件目以降は差し替えるだけで作れます。実際、初回の構築は12人日規模でも、テンプレートが固まったあとの2件目以降は2〜4人日まで下がります。

裏を返すと、この3つに当てはまらないサイトは、①を選ぶ理由がありません。

採用してよい4つの条件

以下を4つとも満たすなら、ヘッドレス化は投資に見合います。

条件1：増え続けるページが数十本以上ある

記事・実績・症例・導入事例など、これから増えていく種類のページです。固定ページだけで構成されたサイトは該当しません。

目安として、自社サイトを再構築したときはブログ記事が168本、実績が58本ありました。合計226本です。この規模になると、1本あたりの表示速度と検索での拾われ方が、そのまま売上への影響として効いてきます。

条件2：更新はクライアント自身がWordPressで行う

ヘッドレスにしても、編集画面はWordPressのままです。クライアント側の操作は1つも変わりません。ここが「静的サイトに作り替える」提案との決定的な違いで、更新を自社でやりたい会社にそのまま渡せます。

条件3：動的機能がフォーム程度で済む

問い合わせフォームや資料請求までなら問題ありません。会員ログイン後の画面、在庫と連動したカート、リアルタイムの予約枠表示が主役になるサイトは、静的に焼く方式と噛み合いません。この場合はサーバー側で描画する構成を選ぶべきで、判断軸がまるごと変わります。

条件4：更新の反映に数分待てる

これがいちばん見落とされます。詳しくは後述します。

見送ってよい条件

逆に、以下のどれかに当てはまるなら、②や③で十分です。

ページが10本前後で、記事を書く予定がない

会社概要・サービス紹介・お問い合わせで完結するサイトです。ここにヘッドレスを持ち込んでも、ビルドの仕組みを維持する手間だけが残ります。

福岡の生活支援サービス会社のサイトがこの型でした。ページは7本、ブログ運用の予定なし。選んだのは③のテーマ内包型で、既存のデザインをそのままWordPressテーマの中に持たせ、WordPressからは各ページの文章と画像だけを差し替えられるようにしました。PHPの全面書き直しを避けられるため、工数も抑えられます。

なお、このサイトで実際に問題になっていたのは表示速度ではなく、7ページすべてで <title> と <meta name="description"> が同じだったことです。Googleがページを区別できず、検索結果のサイトリンクに本文の見出しの断片が出ていました。これはページごとにメタ情報を出し分ければ解決する話で、ヘッドレス化とは関係ありません。「検索での見え方がおかしい」の原因が構成にあるとは限らない、という一例です。

保守を引き継ぐ相手にビルド環境の知識がない

ヘッドレス構成は、Node.jsのバージョン、ビルドコマンド、デプロイの自動化がセットで動いています。将来この保守を引き継ぐ相手がWordPressしか触らない場合、誰も直せない構成を残すことになります。引き継ぎ先が決まっていないなら、それ自体が見送りの理由になります。

表側の自由度だけが目的

デザインを自由に作りたいだけなら②で足ります。名古屋の美容サロンFCでは、25店舗すべてを「トップページから下は独自の静的サイト、ブログは同じドメインの /wp/ 配下」という構成で運用しています。表側は完全に自由に作れて、ブログはWordPressのまま。店舗ごとの量産にも耐えます。

移行時に必ず設計へ入れる4点

①を選んだ場合、公開の初日から入れておくべき設計が4つあります。あとから足すと手戻りになります。

1. 旧URLの301リダイレクトとcanonicalを、切り替えと同時に入れる

表側と /wp/ に同じ本文が2つのURLで配信される状態は、検索エンジンから見れば重複です。評価が2つのURLに割れ、どちらも上がりきらないという結果になります。

これを防ぐには、旧URLから新URLへの301と、各ページの自己参照canonicalを、切り替えと同じタイミングで入れるのが正解です。切り替えを先にやって301を後回しにする、という順番だけは避けてください。

なお、既存URLをそのまま使えるページは301が不要です。愛知県のクリニックの案件では、固定ページ16件のうち5本がすでに検索エンジンに登録済みだったため、新しい構成でも同じURLを採用しました。結果、301が必要だったのは3系統だけです。URL設計の前に「今どのURLが評価されているか」を実際に調べると、移行の作業量そのものが減ります。

2. 更新の反映ラグを、仕組みと説明の両方で潰す

ヘッドレス構成では、記事を保存した瞬間にはサイトに出ません。ビルドが走って初めて反映されます。定時のビルドだけに頼ると、最大でその間隔ぶん待つことになります。30分間隔なら最大30分です。

正しい作り方はWordPressの保存をきっかけにビルドを起動する仕組みと、保険としての定時ビルドを両方持たせることです。ビルド自体は1〜2分程度で終わるので、体感は数十秒〜数分に収まります。

そして仕組み以上に大事なのが運用の説明です。「保存してもすぐには出ません。1〜2分お待ちください」と最初に伝えてあるかどうかで、同じ挙動が「仕様」にも「不具合の問い合わせ」にもなります。納品時の説明資料に必ず1行入れてください。

3. 日本語のURLを含む記事を、先に洗い出す

日本語のスラッグ（URLの末尾部分）を使っている記事は、移行時に注意が必要です。WordPressのAPIはURLエンコードされた文字列を返すため、そのまま静的ファイルの出力先に使うと、エンコードされた文字列そのものがフォルダ名になり、公開後に404になります。

対処は難しくありません。API から受け取った時点でデコードして扱えば済みます。ただしローカルでは動いて本番だけ404になる種類の問題なので、移行前に日本語スラッグの記事が何本あるかを数え、公開後の検証リストに入れておくのが安全です。

4. ビルドはサーバー側の環境で通るまで確認する

手元のパソコンでビルドが通っても、本番と同じサーバー環境では通らないことがあります。レンタルサーバーは基幹ライブラリのバージョンが古めに固定されていることが多く、ビルドツールが要求するバージョンに届かないケースがあるためです。

手元で作った依存関係の固定ファイルをそのままサーバーに持ち込まないこと、そしてサーバー上で一度ビルドを通してから本番反映の手順を組むこと。この2つで大半は避けられます。

判断のチェックリスト

最後に、実際の判断に使える形でまとめます。

①フルヘッドレスを選ぶ

• 記事・実績が数十本以上あり、今後も増える
• クライアントがWordPressで自分で更新する
• 動的機能はフォーム程度
• 更新反映に1〜2分待てる、または説明できる
• 保守を引き継ぐ体制がある

②分離同居を選ぶ

• 表側のデザイン自由度が主目的
• 多店舗・多拠点で同じ型を量産したい
• ブログはWordPressの標準機能のままでよい

③テーマ内包を選ぶ

• ページ10本前後で完結する
• 更新は文言と画像の差し替えが中心
• 保守をWordPressの範囲に収めたい

そもそも構成の話ではない可能性を先に潰す

• 表示が遅い→まず画像の書き出し設定を見る（容量は見た目を変えずに大きく落ちます）
• 検索での見え方がおかしい→まずページごとのtitleとdescriptionを見る

まとめ

ヘッドレスCMSの比較で最初にやるべきは、ツールを並べることではなく、自社のサイトが3つの構成のどれに当てはまるかを決めることです。

判断軸はシンプルで、増え続けるページを数十本以上抱えているか。ここがイエスなら、ヘッドレス化は初期の工数を回収できます。ノーなら、WordPressをそのまま使う②か③で十分です。

そして①を選ぶ場合は、301とcanonical、反映ラグの仕組みと説明、日本語URLの洗い出し、サーバー側でのビルド確認。この4つを最初の設計に入れておいてください。あとから足すと、その分だけ手戻りになります。

graciautoでは、ホームページ制作から更新の仕組みづくりまで、構成の選定と移行設計をあわせて行っています。ヘッドレス化ありきでは進めません。現在のサイトのURL構成と記事本数、そして誰がどのくらいの頻度で更新しているかをお聞かせいただければ、3つのうちどの構成が合うかをお答えします。