ヘッドレスCMSを検討していて、こんな話を聞いたことはないでしょうか。
「表示速度は速いけれど、SEOに弱い」
これは正確ではありません。
弱いのはヘッドレスCMSそのものではなく、JavaScriptでコンテンツを描画する方式です。
当社はこの問題を避けるため、JavaScriptを一切使わないヘッドレス構成にしました。
データと表示は分離したまま、検索エンジンにもAIにも通常のHTMLとして届きます。
なぜJavaScript描画は検索に弱いのか
一般的なヘッドレスCMSは、次の流れで表示します。
ブラウザがページを開く ↓ JavaScriptが動く ↓ APIを呼んでデータを取得 ↓ 取得したデータでHTMLを組み立てる ↓ 画面に表示される
人間が見る分には問題ありません。1秒足らずで表示されます。
問題は、読み手が機械の場合です。
クローラーは必ずしもJavaScriptを実行しない
検索エンジンのクローラーがページを取得したとき、最初に受け取るのはJavaScriptが動く前のHTMLです。そこには本文がありません。
Googleはレンダリング（JavaScriptを実行して最終的な表示を得る処理）に対応していますが、次の点に注意が必要です。
- レンダリングは通常のクロールとは別の処理で、後回しになることがある
- すべてのページが必ずレンダリングされる保証はない
- JavaScriptの実行に失敗すると、中身が空のまま評価される
Google以外の検索エンジンやクローラーは、そもそもJavaScriptを実行しないものもあります。
AIのクローラーはさらに慎重に考えたい
近年はAIがWeb上の情報を収集し、要約して提示する場面が増えました。
これらのクローラーがJavaScriptをどこまで実行するかは、公開されている情報が限られています。実行しないものもあれば、実行するものもあるでしょう。
確実なのは、JavaScriptを必要としないHTMLなら、どのクローラーでも確実に読めるということです。
検索とAIの両方から情報を見つけてもらいたいなら、機械が読むために前提条件が少ない方が有利です。
解決策は「配信前に組み立てる」こと
JavaScript描画の問題は、組み立てる場所がブラウザだから起きます。
ならば、ブラウザに届く前に組み立てればよいわけです。
| JavaScript描画 | 今回の構成 | |
|---|---|---|
| 組み立てる場所 | ブラウザ | Webサーバー |
| 組み立てるタイミング | ページを開いたとき | 配信する直前 |
| クローラーが受け取るもの | 空のHTML＋JS | 完成したHTML |
| JSの実行 | 必須 | 不要 |
「サーバーサイドレンダリング（SSR）」と呼ばれる考え方に近いものですが、当社はもっと単純な方法を使っています。
SSIという古い仕組みを使う
SSI（Server Side Includes）は、Webサーバーが持つ古くからの機能です。
指定したファイルの中身を、配信の直前に差し込みます。
HTMLにはこう書いておきます。
<!--#include virtual="/included/news-latest.html" -->
訪問者に届くときには、この1行が新着情報のHTMLに置き換わっています。
ブラウザから見れば、最初からそこに書かれていたのと同じです。
クローラーが受け取るのも、当然この完成したHTMLです。
「古い」ことは欠点ではない
SSIは1990年代から使われている仕組みです。新しい技術ではありません。
しかし、目的が「配信前にHTMLを完成させること」であれば、これで十分です。
フレームワークの学習も、ビルド環境の構築も要りません。
レンタルサーバーの多くが対応しているため、導入のハードルも低くなります。
当社のトップページの構成
実際にどう分かれているかを示します。
| 部品 | 中身 | 作っているもの |
|---|---|---|
| ヘッダー・フッター | ナビゲーション・会社情報 | 静的ファイル |
| ヒーロー | キャッチコピー・特徴 | HTMLに直書き |
| サービス一覧 | 4カテゴリと項目 | 会社概要CMS |
| 代表者メッセージ | 要約・全文・開閉ボタン | 会社概要CMS |
| 新着情報 | 一覧・絞り込み・記事データ | 新着情報CMS |
| ブログ | 最新記事の一覧 | Drupal |
トップページのHTMLファイルは12KBしかありません。
実際に書かれているのはヒーロー部分と各セクションの見出しだけで、あとはSSIの1行です。
中身を持たない器になっています。
会社概要を直すとトップページに反映される仕組み
3つのCMSのうち、会社概要CMSを例に流れを追います。
データはひとつ
会社概要ページとトップページで、同じデータを使っています。
サービス内容も代表者メッセージも、会社概要CMSに登録した1つのデータが元です。
トップページ用に別途入力する必要はありません。
以前は同じ内容を2箇所に入力していましたが、どちらかを直し忘れると内容が食い違います。
データを1つにすれば、その問題は起きません。
保存すると部品が書き出される
会社概要を保存すると、次の処理が走ります。
会社概要CMSで保存 ↓ company.html を生成（会社概要ページ） ↓ included/services.html を生成（サービス一覧） included/rep-message.html を生成（代表者メッセージ） included/contact-lead.html を生成（お問い合わせ文言）
トップページのHTMLは変更されない
この間、トップページのHTMLファイルには一切手が加わりません。
次に誰かがページを開いたとき、Webサーバーが最新の部品を読み込んで配信します。
トップページ側は「部品を読む」と書いてあるだけなので、中身が変わっても気づく必要がありません。
この設計にした理由は、トップページのレイアウトを手で自由に編集したかったからです。
以前はCMSがトップページを丸ごと生成していたため、手で加えた変更が次の生成で消えていました。
同じデータでも見せ方は変えられる
会社概要ページでは説明文つきで詳しく、トップページではカード形式で簡潔に表示しています。
データは同じで、組み立て方だけが違います。将来スマートフォンアプリやデジタルサイネージへ配信することになっても、同じデータから別の形式で出力できます。
これはヘッドレスCMSの本来の利点です。JavaScriptを使わなくても、この利点は失われません。
ヘッドレスCMSの弱点をどこまで解決したか
正直に整理します。
解決できたこと
| 一般的な弱点 | 今回の構成では |
|---|---|
| JSを実行しないと中身が読めない | 配信時点で完成したHTML |
| 初回表示に待ち時間がある | 静的HTMLと同じ速度 |
| フロントエンドの構築が必要 | HTMLに1行書くだけ |
| APIが止まるとページが空になる | 最後に書き出したファイルが残る |
解決していないこと
| 課題 | 状況 |
|---|---|
| 公開前のプレビュー | 別途仕組みが必要 |
| リアルタイム性 | 書き出した時点の状態。秒単位で変わる情報には不向き |
| 構成の理解 | どのファイルがどこから来るかの把握が必要 |
| 環境の制約 | SSIが使えるサーバーが前提 |
特にリアルタイム性は明確な制約です。在庫数や予約状況のように秒単位で変わる情報を扱うなら、APIで都度取得する方式が適しています。
逆に言えば、企業サイトのように更新頻度が日単位・週単位の情報であれば、この制約は問題になりません。
どう使い分けるか
| 状況 | 向いている方式 |
|---|---|
| 検索・AIからの流入が重要 | 配信前に組み立てる |
| 更新頻度が日単位・週単位 | 配信前に組み立てる |
| 同じ情報を複数の媒体へ配信したい | どちらでも可（データ分離が本質） |
| 秒単位で変わる情報を扱う | APIで都度取得 |
| ログイン後の個別表示が必要 | APIで都度取得 |
| アプリなど複数の画面で使う | APIも併用 |
両方を組み合わせることもできます。基本は配信前に組み立て、変化の速い部分だけAPIで取得する形です。
まとめ
ヘッドレスCMSがSEOに弱いのではなく、JavaScriptで描画する方式が弱いのです。
- クローラーは必ずしもJavaScriptを実行しない
- ならば、配信前にHTMLを完成させればよい
- SSIで部品を差し込めば、JSなしでヘッドレスの利点が得られる
- データと表示の分離という本質は変わらない
- ただしリアルタイム性は犠牲になる。用途で選ぶ
「ヘッドレスCMS＝APIとJavaScript」と考えると、選択肢が狭まります。
データを持つ場所と、表示する場所を分ける。
それがヘッドレスの本質であり、実現方法は1つではありません。
検索とAIの両方から見つけてもらいたい企業サイトであれば、機械が読むための前提条件は少ない方が有利です。
同じような構成を検討されている方は、まず「その情報はどのくらいの頻度で変わるのか」を整理してみてください。
そこが決まれば、適した方式も見えてきます。