Googlebot・Bingbot・Applebotは2019〜2020年にChromium/Edge/WebKitベースのレンダリングをevergreen化し、JavaScript実行を公式にサポートしている。一方、GPTBot・ClaudeBot・PerplexityBotの公式ドキュメントにはJS実行可否の明記がなく、ファーストペイントのHTMLにコンテンツが載っていないSPA（CSR）サイトの本文は、AIクローラーから見えていない可能性が高い構造になっている。
観察：HTMLが約28KBしかないあるLPに遭遇した
国内のあるノーコードSPAサービスで構築されたランディングページに対して、サーバーから返されるHTMLを生で取得してみた。レスポンスはわずか約28KB、しかも `<body>` の中はほぼ空で、本文・見出し・画像・内部リンクが一切含まれていない。コンテンツはすべてJavaScript実行後にクライアント側で描画される、典型的なCSR（Client-Side Rendering）の構造だった。
観測されたファクト
- •サーバーが返す初期HTMLは約28KB、bodyの可視テキストはほぼゼロ
- •User-AgentをGooglebotに偽装してリクエストしても、返ってくるHTMLは同じ
- •JSON-LD構造化データは一切実装されていない
- •サイトマップに登録されているのは6URLのみ（うちフォーム系3本）
このサイトをCodeQuest.work SEOで診断すると、本文文字数・H1・内部リンク・画像alt等のコンテンツ系項目がほぼ全てゼロ判定になる。診断結果は仕様通りに正しいが、「Googleが実際にどう見ているか」とは乖離する可能性がある。なぜ乖離が起きるのか、そしてその乖離はAIクローラーにも当てはまるのか — ここから検証を始める。
SEOクローラー側はすでに進化していた
「SPAはSEOに不利」という認識は2015年頃から長く語られてきたが、主要SEOクローラーは過去5年間で大きく進化している。3社の公式ステートメントを並べると、JavaScriptレンダリング対応がほぼ標準化されたことが分かる。
Googlebot：evergreen Chromium（2019/05〜）
Google公式の JavaScript SEO Basics は次のように明記している：「Google Search runs JavaScript with an evergreen version of Chromium」。クロール（fetch）の後、リソースに余裕ができた段階でヘッドレスChromiumがレンダリングを実行する2段階インデックス方式。
一次ソース：developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
Bingbot：Microsoft Edge=Chromium（2019/10〜）
Bing公式ブログより：「By adopting Microsoft Edge, Bingbot will now render all web pages using the same underlying web platform technology already used today by Googlebot, Google Chrome, and other Chromium-based browsers」。実質的にGooglebotと同等のレンダリング能力を持つ。
一次ソース：blogs.bing.com/webmaster/october-2019/The-new-evergreen-Bingbot
Applebot：WebKit (Safari互換)
Apple Support の About Applebot より：「Applebot may render the content of your website within a browser. If JavaScript, CSS, and other resources are blocked via robots.txt, it may not be able to render the content properly」。Safari互換のWebKitでレンダリングするため、Apple Intelligence / Siri / Spotlight向けの本文取得が可能。
つまり、SEO（オーガニック検索）の視点だけで見れば、SPA構造でも主要3社のクローラーは本文を読み取れる前提が成立する。問題はここではなく、次のレイヤーにある。
AIクローラー側は「公式に明記していない」
AI検索エンジンが使用する主要クローラーの公式ドキュメントを精査した結果、JavaScript実行可否について明確に記載しているものはなかった。「実行しない」とも「実行する」とも書かれていない、というのが現状である。
| クローラー | 用途 | JS実行の公式明記 |
|---|---|---|
| GPTBot | OpenAI モデル学習 | 明記なし |
| OAI-SearchBot | ChatGPT Search インデックス | 明記なし |
| ChatGPT-User | ユーザー要求時のリアルタイム取得 | 明記なし |
| ClaudeBot | Anthropic モデル学習 | 明記なし |
| Claude-User | Claudeユーザー要求時の取得 | 明記なし |
| Claude-SearchBot | Claude検索品質向上 | 明記なし |
| PerplexityBot | Perplexity 検索インデックス | 明記なし |
| Perplexity-User | ユーザー質問への応答時 | 明記なし |
比較対象として、SEOクローラー側はそれぞれの公式ドキュメントに「JavaScript実行のためにChromium / Edge / WebKitを使う」と明示している。AIクローラー側だけが「明記しない」のは、偶然というより構造的な選択と読むのが自然だ。
一次ソース：OpenAI Bots / Anthropic Crawlers / Perplexity Crawlers
「明記なし」をどう解釈するか
公式に書かれていない以上、「実行していない」と断定することはできない。しかし「実行している」と仮定するのも根拠が薄い。事実と推論を分けて整理する。
ファクト（公式ドキュメント由来）
- •GPTBot / ClaudeBot / PerplexityBot のいずれも、レンダリングエンジンに関する明記がない
- •User-Agent 文字列に「Chrome/W.X.Y.Z」のようなブラウザバージョン表記もない
- •Googlebot / Bingbot は2019年に「JS実行のためChromium/Edgeを採用した」と公式にアナウンス済み — 真逆の透明性
推論（断定ではない）
- •ヘッドレスブラウザ起動は1リクエストあたりのコストがHTML取得の数十倍。学習データ収集のような大規模クロールで全URLにJS実行をかけるのは現実的でない
- •ユーザー要求時取得（ChatGPT-User / Perplexity-User）は性質上リアルタイム処理が必要で、JS実行を含む可能性は比較的高い — ただし公式明記なし
- •もし学習用クローラーがJS実行していたら、SEOクローラーと同じく公式に宣言したほうが運営側にもメリットがある（無駄なエラーログ削減・WAFホワイトリスト調整）。それをしていない事実は、JS非対応寄りのシグナルと読める
本記事では「AIクローラーはJSを実行しない」と断定はしない。「公式に明記がなく、コスト構造と運用透明性のシグナルから推論するとJS非対応寄りである可能性が高い」というレベルで扱う。実務判断としては、この不確実性を許容しない方が安全である。
Googleの2段階インデックスも完全な救済ではない
「Googlebotがレンダリングしてくれるから大丈夫」という議論には2つの限界がある。公式ドキュメントから直接引用しながら整理する。
限界1：レンダリングは「リソースに余裕があるとき」に行われる
Google公式：「Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript」。クロール直後ではなく、Googleがリソースを割り当てたタイミング。新規ページのインデックスが遅れる、頻繁な更新が反映されない、といった現象の根本原因はここにある。
限界2：Dynamic Renderingは公式に非推奨化された
Google公式：「Dynamic rendering is a workaround and not a long-term solution for problems with JavaScript-generated content in search engines」。2018年頃に推奨された「Botに対してだけSSR HTMLを返す」手法は、現在では公式にレガシー扱い。今後の解は SSR / SSG / Hydration である。
一次ソース：developers.google.com/search/docs/crawling-indexing/javascript/dynamic-rendering
つまり、Googleですら「JS実行してインデックスはしますが、即時性は保証しません」というスタンスを公式に取っている。日々更新するメディアサイトでCSRを採用する場合、新規記事のインデックスに数日〜数週間の遅延が発生する可能性は常に念頭に置く必要がある。
自サイトが「AIから見えているか」を確認する3つの手順
自分のサイトがクローラー別にどう見えているかは、特別なツールがなくても確認できる。優先度の高い順に3つ紹介する。
Search Console「URL検査」→「公開URLをテスト」
Googleがレンダリング後に取得するHTMLとスクリーンショットを公式に確認できる唯一の方法。「HTML」タブで生のレンダリング結果、「スクリーンショット」でビジュアルを照合する。本文がスクリーンショットに映っていなければ、Googlebot第2段階すら失敗している。
curl で User-Agent を切り替えてHTMLを比較
`curl -A "Mozilla/5.0 (compatible; GPTBot/1.2; +https://openai.com/gptbot)" https://example.com/` のようにUA文字列を渡し、AIクローラーが見るのと同じ初期HTMLを取得する。bodyに本文が含まれていなければ、JS非実行型のクローラーには見えていない可能性が極めて高い。
`site:` 検索で実際のスニペットを観察
Googleで `site:example.com` を検索し、各ページのスニペットが本文から生成されているかを確認する。titleタグやdescriptionだけで埋まっていて、本文の抜粋が出てこない場合、Googleはレンダリング後の本文をうまく取得できていない可能性が高い。
打ち手の選択肢：SSR / SSG / Hydration
CSRを採用していて、Googleには映ってもAIに映らない状態を解消するための選択肢を整理する。Dynamic Renderingは公式に非推奨化されたため除外している。
| 手法 | 向いているケース | AI可視性 |
|---|---|---|
| SSR（サーバーサイドレンダリング） | 頻繁に更新・パーソナライズが必要なメディア・アプリ | 高 |
| SSG（静的サイト生成） | LP・ブログ・ドキュメントなど更新頻度が中程度のサイト | 高 |
| Hydration（SSR+クライアント復元） | インタラクティブだが初期表示も重視するアプリ | 高 |
| プリレンダリング | 既存SPAの最低限の改修で対応したい場合 | 中 |
| Dynamic Rendering | Google非推奨。新規採用すべきでない | 非推奨 |
Next.js App Router（SSR/SSG/ISRの自動切り替え）、Nuxt（SSR）、Astro（SSG中心）、SvelteKit（SSR）あたりが現代の選択肢である。既存のVue/React SPAを丸ごと書き直す余裕がない場合は、最低限プリレンダリングで主要ページのファーストペイントHTMLにコンテンツを載せる対応が現実的な落とし所になる。
なお、ノーコードSPAサービスを使っている場合、テンプレート側がCSR固定で利用者がレンダリング方式を選べないケースがある。その場合、サービス側に対するフィードバックチャネル経由でSSR/SSG対応を要望する以外の打ち手は限定的だ。
CodeQuest.work SEOでの判定の読み方
CodeQuest.work SEOは、Cloudflare Workers環境で動作する初期HTML解析型の診断ツールである。JavaScriptは実行せず、サーバーから返ってきたHTMLをそのまま45項目で評価する。これはBingbotやAIクローラー（公式明記はないが推論レベル）と同等の見え方になる。
シグナルとしての読み方
- 本文文字数・H1・内部リンク・画像数のいずれも極端に少ない判定 → CSR採用の可能性が高い。SPAサイトを診断したときに「全部ゼロに近い」結果が出たら、判定自体は正しくても「Googleが第2段階で見ているもの」とは別物と解釈する
- ただし、その「ゼロに近い見え方」こそが AIクローラー・Bingbot第1段階・OGPクローラー・Twitterボット等が見ているもの。SEOスコアが低くなっても、AIO/GEO観点では実態のリスクをそのまま反映していると言える
- 逆に、CSRサイトでも構造化データ（JSON-LD）・meta description・canonicalタグなど、HTML初期描画時点で読める要素は対応可能。これらは初期HTMLに直接埋め込めるため、最低限のAIO/GEO対策として優先度が高い
SEO診断ツールの結果は「ベンチマーク」ではなく「シグナル」として読むことが本質である。SPAだからスコアが低いのは仕様だが、そのスコアの低さはAIクローラーから見たときの可視性を正直に反映している、と読み替えれば打ち手が見えてくる。
あなたのサイトの初期HTMLをチェック
URLを入力するだけで、JS実行前の初期HTMLを45項目で診断。本文・H1・内部リンクがゼロに近ければCSR採用の可能性が高く、AIクローラーには見えていない可能性があります。
この記事を書いた人
今井政和SEOディレクター / フロントエンド開発者
Web業界20年以上の経験を持つSEOディレクター。CodeQuest.work SEOの開発者。WordPress公式プラグイン「ORECTIC SEO CHECK」作者。著書に「三方良しで勝つ 江戸商人に学ぶ現代WEB戦略」。
@imai_directorよくある質問
SEOクローラーがJS実行できるなら、SPAでも問題ないのでは？▾
AIクローラーが「実行しない」と公式に書いていないなら、実行している可能性もあるのでは？▾
Dynamic Renderingはなぜ非推奨になったのですか？▾
プリレンダリングとSSGはどう違いますか？▾
既存のSPAサイトをSSRに移行するコストが見合わない場合、最低限の打ち手は？▾
関連記事
あわせて読みたい
AIO対策のやり方｜AI Overviewに引用されるための実践ガイド
Google AI Overview（AIO）に自サイトを引用させるための実践的な対策方法を解説。構造化データ・見出し構造・直接回答・E-E-A-Tの4つの柱と、無料SEO診断ツールによるチェック方法。
llms.txtの作り方｜AI検索向けにサイト情報を整理する書き方・設置ガイド
llms.txtの書き方・設置手順を解説。Googleは公式に不要としているが、ChatGPT等の他AIからは未表明。低コストの先行施策としての位置づけと実装手順をまとめた設定ガイド。
「llms.txtは不要だった」は本当か｜Google公式声明の正しい読み方と論理的な穴
「llms.txtは不要だった」という声が拡散している。Google公式は確かに「不要」と明言したが、その対象は生成AI検索に限定された話だ。声明の正しい読み方、不要論3つの論理的な穴、ChatGPTアクセスの実測値・Google自身のサイトへの設置という矛盾をファクトベースで検証する。
llms.txtはGEO施策として機能するのか｜CDNログ実データで検証する
llms.txtを設置すればAI検索に引用される — 本当か？ChatGPT・Perplexity・ClaudeのCDNログデータと30万ドメイン調査から、llms.txtのGEO効果を3ツール横断で検証した。