「ヘッドレスCMSで作ったサイトなんですが、AI検索の対策は何をすればいいですか」。この問いには、従来型のCMSとは違う答えが要ります。
Contentful・microCMS・Strapi・Sanity。どれを使っていても、共通する分かれ道が1つあります。メタデータを、誰がどこで作るかです。
この記事は、ヘッドレスCMSでサイトを組んでいるWeb担当者とエンジニアの方を想定して書きました。専門用語はその場で言い換えます。最後は、公開前に何を確かめるかまで持っていきます。
こんなふうに調べていませんか
- 「ヘッドレスCMS AIO 実装」で検索して、何を実装するのかを探している
- AIクローラーがJavaScriptを実行するのか、はっきりした答えを探している
- SSR・SSG・ISRのどれを選ぶか、社内で決めきれずにいる
この記事を読み終えたときに手に入るもの
- 主要AIクローラーのJS実行について、公式文書に何が書かれているかを説明できるようになります
- メタデータをCMS側とフロント側のどちらで作るかを、自分で決められます
- SSR・SSG・ISRの選び分けを、更新頻度から判断できます
結論30秒でわかる、この記事の結論
- ヘッドレスCMSのAIO実装の要は、メタデータをJavaScriptの実行に頼らず初期HTMLで配ることです。
- GPTBot・OAI-SearchBot・PerplexityBot・ClaudeBotのJS実行有無は、2026年8月時点で公式文書に記載がありません。「実行しない」ではなく「未文書化」が正確です。
- CMS側にどれだけ丁寧なSEOの項目を作っても、
<head>へ出すのはフロントエンド側の仕事です。
進行役は3人です。若葉さん（Web担当2年目）は「そもそも、それって何ですか？」を、高梨課長（マーケ課長）は「誰がやるんですか？」を聞く役、鈴木さん（AIO/SEOの専門家・本誌監修）が答える役です。
01ヘッドレスCMSのAIO実装は、従来型のCMSと何が違うんですか？
若葉さんうちはヘッドレスCMSなんですが、AI検索の対策として何をすればいいんでしょうか。
鈴木さんまず、従来型のCMSとどこが分かれているかを押さえましょう。分かれ目が、そのまま作業の分担になります。
従来型のCMS（WordPress等）は、コンテンツ管理と画面表示のテーマ機能が一体です。管理画面で本文を保存すれば、meta descriptionやOGP画像も同じ仕組みでHTMLへ出力されます。
ヘッドレスCMSは、この2つを切り離します。CMSはコンテンツをAPI経由でJSON形式で渡すだけで、HTMLを生成しません。HTML化はNext.js・Nuxt等、フロントエンド側の仕事です。
違いを並べると、次のようになります。
| 従来型CMS（WordPress等） | ヘッドレスCMS | |
|---|---|---|
| コンテンツとHTMLの関係 | 同じシステム内で一体生成 | API経由で分離、HTML化は別工程 |
| メタタグ・OGPの生成場所 | CMS本体（テーマ・プラグイン） | 原則フロントエンド側の実装 |
| リスクが生じる典型パターン | プラグインの設定漏れ | CSR実装によるメタデータ未配信 |
この分離こそが、ヘッドレスCMS特有の自由度と、AIO観点でのリスクを同時に生む構造です。
この章のまとめ
違いは機能の多さではありません。メタデータを作る場所が、CMSの外へ出たという一点です。
02ヘッドレスCMSにすると、AI検索に本文が届かないことがあるんですか？
フロントエンドの実装方式によって、メタデータがAIクローラーに届くかどうかが決まります。 これが、ヘッドレスCMS特有の論点です。
ヘッドレスCMSの多くは、React・Vue系フレームワークのスターターテンプレートで構築されます。問題が起きやすいのは、フロントエンドをクライアントサイドレンダリング（CSR）で組んだ場合です。この場合、ブラウザがJavaScriptを実行して初めて、CMSから取得した本文やメタ情報がHTMLへ反映されます。
JavaScriptを実行しないクローラーには、この本文とメタ情報が存在しないページとして映るおそれがあります。
仕組みと診断方法は、姉妹記事『JavaScriptレンダリングとAIクローラー｜SSR移行の3択』で解説済みです。本記事では、この前提を踏まえたうえで、ヘッドレスCMS構成に特有のメタデータ設計に絞って扱います。
この章のまとめ
届かなくなるのは、コンテンツの質の問題ではありません。中身が入るタイミングの問題です。
03ヘッドレスCMSでは、AIクローラーはJavaScriptを実行するんですか？AI対策の前提を知りたいです
高梨課長そこが分かれば話が早いです。AIのクローラーは、JavaScriptを実行してくれるんですか。
鈴木さん正直に申し上げると、そこは公式には書かれていません。 主要4社の公式ドキュメントを実際に開いて確かめましたが、一様に触れられていないんです。
高梨課長書いていない、ですか。
鈴木さんはい。だからこそ、書いていないことを「実行しない」と読み替えないことが大事になります。
WEBMARKSは2026年8月時点で、OpenAI・Anthropic・Perplexity・Googleの公式ドキュメントを実際に確認しました。結果は次のとおりです。
| クローラー | 運営元 | 用途 | JS実行に関する公式記述 |
|---|---|---|---|
| Googlebot | 検索・AI Overviews | あり（クロール・レンダリング・インデックス登録の段階とキュー待機を明記） | |
| GPTBot | OpenAI | AIモデルの学習データ収集 | 記述なし |
| OAI-SearchBot | OpenAI | ChatGPT検索結果への表示 | 記述なし |
| PerplexityBot | Perplexity | 検索結果への表示・リンク | 記述なし |
| ClaudeBot | Anthropic | AIモデルの学習データ収集 | 記述なし |
4つのAIクローラーについて、公式ドキュメントの記載内容は次のとおりです。
- GPTBot（UA:
GPTBot/1.4）: OpenAI公式ボットドキュメントに掲載。AIモデルの学習データ収集が目的 - OAI-SearchBot（UA:
OAI-SearchBot/1.4）: 同ドキュメントに掲載。ChatGPTの検索結果表示が目的 - ClaudeBot: Anthropicのヘルプセンターに掲載。生成AIモデルの改善・安全性向上のための学習データ収集が目的
- PerplexityBot（UA:
PerplexityBot/1.0）: Perplexity公式ドキュメントに掲載。検索結果表示専用で、AI基盤モデルの学習には使用しないと明記
いずれのページにも、JavaScriptの実行有無への言及はありません。
この章のまとめ
分かっているのは、AIクローラーの実行能力が未文書化であることです。それ以上でも以下でもありません。
04Googlebotだけ記述があるのは、AI検索の実装にどう効くんですか？
比べる相手がいると、書かれていないことの意味がはっきりします。Googlebotだけは、公式ドキュメントに具体的な記述があります。
クロール・レンダリング・インデックス登録という段階のパイプラインで処理され、200番のステータスコードを返すページはレンダリングキューへ送られます。このキューでは、数秒以上待機することがあると公式に明記されています。
つまり、JavaScriptを実行する側でも、実行は即座ではありません。順番待ちが挟まります。
Google公式がSSRをすすめる理由も明快です。「JavaScriptを実行できないボットがある」ためだと説明しています。書いてある側の説明が、書かれていない側への構えを示していると読めます。
この章のまとめ
書いてある側にも待ち時間があり、書いていない側は分かりません。どちらにも効くのは、最初から載せておくことです。
05公式に書いていない場合、ヘッドレスCMSのAI検索最適化ではどこまで前提にできますか？
参考情報として、Webインフラ企業のVercelが2024年12月に公開した観測データがあります。自社ネットワークの通信ログを分析したもので、ChatGPTのクローラーはJavaScriptファイルを11.50%の頻度で取得するものの、実行した形跡はないと報告されています。ClaudeBotのクローラーも、ファイルを23.84%の頻度で取得しながら実行はしていないとされています。
ただしこれは、一企業による独自の観測データです。公式な仕様表明ではありません。公開から2026年8月で1年8か月が経過しており、各社の挙動が変わっていても、ドキュメントには反映されない可能性があります。
現時点で言えるのは「未文書化」であり、「実行しない」と断定することではありません。 そのうえで設計の結論は1つに絞れます。メタデータはJavaScript実行を前提とせず、初期HTMLの時点で確定させる。 どちらに転んでも届く形にしておく、という考え方です。
robots.txtでのクロール制御自体は、本記事の範囲外です。事業者別の設計は姉妹記事『AIクローラーrobots.txt設定ガイド｜7組織14種を3パターンで整理』を参照してください。
この章のまとめ
分からないときは、どちらでも成り立つ側に倒します。初期HTMLに載せておけば、実行されてもされなくても届きます。
06メタデータはCMS側とフロント側、AIO的にはどちらで作るんですか？
問題は、この設計をヘッドレスCMS構成のどの層で行うかです。
ヘッドレスCMS製品の多くは、HTMLの<meta>タグやJSON-LDそのものを生成しません。microCMSは公式ヘルプで明言しています。「ヘッドレスCMSという製品の特徴上、ウェブサイトのフロントエンド（見た目）部分については管理されない構成となります」。SEO対策は、利用するWebフレームワーク側での実装が前提です。
CMS側にどれだけ丁寧なSEOの項目があっても、<head>タグへ実際に出力するのは常にフロントエンド側の仕事です。 これがヘッドレス構成の構造そのものです。
Sanity公式のLearnコンテンツは、SEO用の項目を必須にせず「SEOの項目→通常のタイトル・本文の項目→デフォルト値」の順に自動で穴埋めする設計をすすめています。Next.jsのgenerateMetadata関数で、この穴埋め結果を集約する実装例が示されています。
JSON-LDの具体的な書き方は、姉妹記事『JSON-LDの書き方入門｜3つのコピペ例で今日から書ける【図解つき】』で解説済みです。llms.txtをCMS環境別に設置する手順は『CMS別のllms.txt実装手順をAIに個別設計させる方法』を参照してください。
この章のまとめ
役割は固定です。入れ物を用意するのがCMS、<head>へ出すのがフロント。 どちらか一方だけでは完結しません。
07ヘッドレスCMSごとにSEOの項目の持たせ方は、AI対策でどう違いますか？
<head>へ出すのはフロント側という点は共通です。一方で、SEO関連の「データ」をCMS側にどう持たせるかは、製品ごとに設計思想が分かれます。
| CMS | SEOデータの持たせ方 | 出典 |
|---|---|---|
| microCMS | CMS側では管理せず、フロント側の実装に委ねる | microCMS公式ヘルプ |
| Contentful | 「SEO Metadata」専用コンテンツタイプを作り、各ページから参照する設計を推奨 | Contentful公式SEOガイド |
| Sanity | 組み込み機能はなく、title・description・OG画像を持つカスタムスキーマを自作する | Sanity公式Learn |
| Strapi | 自社製SEOプラグインでメタタグ・OGP・サイトマップ・JSON-LDを管理画面に追加 | Strapi公式ブログ |
分かれ目は、編集者が使う入れ物を、製品が用意しているかどうかです。用意されている場合は入力欄に沿って埋めるだけで済みます。用意されていない場合は、入れ物の設計から始めることになります。どちらでも到達点は同じで、違うのは着手の重さです。
この章のまとめ
製品の優劣ではありません。入れ物づくりが手前にあるかどうかの違いです。ここを見ておくと、工数の見積もりがぶれません。
08SSR・SSG・ISRは、ヘッドレスCMSのAIO実装でどれを選ぶんですか？
高梨課長レンダリング方式の話になると、いつも社内で意見が割れます。どう決めればいいでしょうか。
鈴木さん決め手は好みではなく、そのコンテンツをどれくらいの頻度で更新するかです。そこから逆算すると、自然と絞れますよ。
3方式の違いは次のとおりです。
- SSR（サーバーサイドレンダリング）: リクエストのたびにCMS APIへ問い合わせて生成する方式。メタデータは常に最新だが、CMS APIとサーバーへの負荷が高い
- SSG（静的サイト生成）: ビルド時に全ページを生成する方式。応答は最速だが、CMSでの更新は次回ビルドまでHTMLへ反映されない
- ISR（増分的静的再生成）: Next.js公式ドキュメントによれば、
revalidateで指定した秒数の経過後、次のアクセス時に古いキャッシュを返しつつ裏側で再生成する方式
いずれの方式でも、メタデータは初期HTMLに載ります。選ぶ基準になるのは、CMSでの更新がメタデータへ反映されるまでの時間差です。
この章のまとめ
方式そのものに優劣はありません。更新頻度という物差しを先に決めると、選択はほぼ自動的に決まります。
09ヘッドレスCMSで更新した内容がAI検索に届くまでの時間差は、どう詰めるんですか？
ISRでは、CMSのWebhookでrevalidatePathを呼べば、更新直後の反映も可能です。ニュースやキャンペーンなど更新頻度が高いコンテンツを扱う場合、ISRとWebhook連携の組み合わせが、鮮度と負荷のバランスを取りやすい選択になります。
Next.js公式ドキュメントは、ISRのキャッシュ状態をx-nextjs-cacheヘッダーで確認できるとしています。値はHIT・STALE・MISS・REVALIDATEDの4種類です。反映されないという相談の多くは、ここを見れば状況が切り分けられます。
Next.js公式は、もう1つの重要な仕様を明示しています。JavaScriptを実行してDOM全体を検査できるボットには、メタデータを<body>タグへ後から追記する配信方式が使われます。一方、「HTML-limited bots」と分類される、JavaScriptを実行できないボットに対しては話が別です。メタデータの生成が完了するまでページのレンダリング自体を待たせ、<head>タグ内に含めて配信します。
AIクローラーの実行能力が未文書化である以上、この「待たせてでも<head>に含める」側の挙動を前提に設計するのが安全です。 この仕様自体が、JavaScriptを実行しないボットの存在を前提に設計されていることを裏づけています。
この章のまとめ
時間差は、方式選びとWebhookで詰められます。詰まったときは、キャッシュ状態のヘッダーを先に見ます。
10AIOの観点で、canonicalやOGPはどこでつまずくんですか？
若葉さん実装はできたんですが、細かいところで抜けが出そうで不安です。どこを見ればいいでしょうか。
鈴木さん抜けが出るのは、たいていCMSとフロントのつなぎ目です。値がそのまま渡っているかを、順番に見ていきましょう。
ヘッドレスCMS構成では、次の5点でつまずくケースが目立ちます。いずれもCMSとフロントエンドが分離しているために起こる、ヘッドレスCMS特有の落とし穴です。
- プレビューAPIと本番APIの取り違え: 下書き確認用のプレビューURLがcanonicalや構造化データに紛れ込み、本番と別ドメインを指してしまう
- OGP画像フィールドの未入力: 編集者が画像設定を忘れた場合のフォールバック画像を、フロント側で用意していない
- 絶対URLの指定漏れ: Next.js公式ドキュメントは、OGP画像のURLについて「絶対URLである必要がある」と明記している。CMSから相対パスのまま渡すと、この要件を満たせない
- 構造化データとコンテンツモデルの不一致: CMSの入力項目に無いフィールドを、フロント側でJSON-LDに埋めようとして空値や推測値を入れてしまう
- 多チャンネル配信時のcanonical不備: 同じコンテンツをWebとアプリなど複数チャネルへ配信する構成で、canonicalの向き先が定まっていない
個別のスキーマ（Article・Product・FAQ等）の書き方は、カテゴリ別の記事群で解説しています。構造化データを入れれば引用されるとは限らない、という検証結果もあります。姉妹記事『構造化データとAI引用の相関｜論文を読んで分かった3つの事実【図解で解説】』を参照し、過度な期待を持たず「読める状態にする」ことを優先してください。
この章のまとめ
つまずきは、どれもつなぎ目で起きています。CMSとフロントの間で、値がそのまま渡っているかを見ます。
11ヘッドレスCMSのAIO実装で、公開前に何を確かめればいいですか？
確認は、机上のレビューではなく実物で行います。JavaScriptを無効化した状態で開いて、本文とメタタグが表示されるかを見るのが、いちばん早い確かめ方です。
公開前に、この順で確かめます
メタデータが初期HTMLに含まれているか
JavaScript実行に依存していないことを、実物で確かめます
役割分担が決まっているか
メタタグ・構造化データ・canonical・OGPを、CMS層とフロント層のどちらで生成するかを決めます
更新頻度から方式を選んだか
SSR・SSG・ISRのいずれかを選定します
再検証の経路が通っているか
ISRを採用する場合、CMSのWebhookからオンデマンド再検証を呼べるか確認します
OGP画像URLが絶対URLか
相対パスのまま出ていないかを確認します
プレビューの内容が混入していないか
本番のcanonical・構造化データに紛れ込んでいないかを確認します
この章のまとめ
確かめ方は1つです。JavaScriptを切って開く。 ここで本文とメタタグが見えれば、前提はおおむね満たせています。
12LLMO対策として、ヘッドレスCMSでよくある失敗は何ですか？
CSRのスターターテンプレートをそのまま本番公開してしまう。 ヘッドレスCMSのチュートリアルはCSR構成が多く、動作確認だけで満足しがちです。公開前に、JavaScriptを無効化した状態で本文とメタタグが表示されるか確認することをおすすめします。
CMS側のSEOの項目を整備して安心してしまう。 ContentfulやSanityで丁寧な項目を作っても、フロント側の実装が伴わなければHTMLへ出力されません。項目の設計と出力の実装は別工程です。
AIクローラーの挙動を推測で断定してしまう。 「AIクローラーはJavaScriptを実行しないから対策不要」という判断は、未文書化の情報を断定に変えています。ドキュメントが更新される可能性を前提に、初期HTMLでの配信を基本方針にしてください。
この章のまとめ
3つとも、確かめていないことを確かめたことにしたときに起こります。実物を開く一手が、そのまま予防になります。
13よくある質問
ヘッドレスCMS製品自体に、AIクローラー対策の機能はありますか？
製品によります。StrapiはSEOプラグインでメタタグやJSON-LDの管理画面を追加できます。microCMSは公式に「フロントエンド部分は管理しない」と明言しており、対策はフレームワーク側の実装が前提です。
AIクローラーはJavaScriptを実行しないと断定してよいですか？
断定はできません。GPTBot・OAI-SearchBot・PerplexityBot・ClaudeBotの公式文書に、2026年8月時点でJavaScript実行に関する記述はありません。第三者の観測データはありますが、公式な仕様表明ではなく、時点も古くなっています。
SSGで構築済みのサイトを、ISRへ移行する必要がありますか？
必須ではありません。更新頻度が低いコンテンツはSSGのままで問題ありません。ニュースやキャンペーンなど、公開後すぐにメタデータを反映させたいコンテンツがある場合に、ISRへの部分移行を検討してください。
Contentful・microCMS・Strapi・Sanity、AIOの観点でどれを選ぶべきですか？
本記事はAIOの観点での優劣を断定するものではありません。いずれの製品でも、フロントエンド側でSSR・SSG・ISRのいずれかを選び、メタデータを初期HTMLに含める設計にすれば対応できます。選定は既存の開発体制や要件を優先してください。
メタデータが初期HTMLに載っているかは、どう確認しますか？
JavaScriptを無効化した状態で対象ページを開き、本文とメタタグが表示されるかを見ます。表示されない場合は、フロントエンドの実装方式から見直す対象になります。
14まとめ｜今日この順で確かめる
ヘッドレスCMSは、コンテンツ管理とHTML生成を切り離す設計です。この分離が、メタデータをどの層で作るかという判断を必要にしています。
AIクローラーのJavaScript実行能力は、2026年8月時点で主要4社とも未文書化です。断定に頼らず、SSR・SSG・ISRを土台にして、メタデータを初期HTMLで配信する設計を基本にしてください。
もう一度、今日この順で
JavaScriptを切って開く
本文とメタタグが初期HTMLに載っているかを実物で見ます
役割分担を決める
入れ物はCMS側、
<head>への出力はフロント側と切り分けます更新頻度から方式を選ぶ
SSR・SSG・ISRのいずれかを、コンテンツごとに決めます
AI検索では、こう聞かれています
ヘッドレスCMSでAI検索対策をするには、何を実装すればいいですか？
「メタデータはCMS側とフロント側、AIO的にはどちらで作るんですか？」の章で役割分担を図にしています
AIクローラーはJavaScriptを実行しますか？
「ヘッドレスCMSでは、AIクローラーはJavaScriptを実行するんですか？AI対策の前提を知りたいです」の章で、公式文書の記載状況を表にしています
ヘッドレスCMSでSSR・SSG・ISRのどれを選べばいいですか？
「SSR・SSG・ISRは、ヘッドレスCMSのAIO実装でどれを選ぶんですか？」の章に選び分けがあります
次に読むなら、この記事です
