ReactやVueなどで構築したSPA(シングルページアプリケーション)のサイトで、AI検索からの流入が伸び悩んでいませんか。原因は、AIクローラーの多くがJavaScriptを実行できないという技術的な制約にあります。本記事では、この問題を診断する方法と、SSR(サーバーサイドレンダリング)・SSGなど実装面の選択肢を、Google公式ドキュメントにもとづいて解説します。

01この記事でわかること

  • SPA/CSRサイトがAIクローラーにどう見えているか(初期HTMLのみ取得という制約)
  • 自社サイトが「空白ページ」問題を抱えているか診断する3つの方法
  • Google公式が挙げるSSR・SSG・ハイドレーションの違いと選び方
  • ダイナミックレンダリングがGoogle公式で「回避策」と位置づけられている理由

02結論サマリー

GPTBotやClaudeBot、PerplexityBotなど主要なAIクローラーの多くは、JavaScriptを実行しません。 読み取るのは、ページの初期HTMLに含まれる情報だけです。

Reactなどのフレームワークでクライアントサイドレンダリング(CSR)している場合、本文はJavaScript実行後にしか現れません。この場合、AIクローラーには空白のページとして扱われるリスクがあります。

Googleは公式ドキュメントで、この問題への対処として案内してきた「ダイナミックレンダリング」を回避策と位置づけています。代わりに案内されているのは、サーバーサイドレンダリング(SSR)・静的レンダリング(SSG)・ハイドレーションという3つの実装方式です(最終更新日2025年12月10日時点)。本記事では、この3つを順に解説します。

03JavaScriptレンダリングとAIクローラー対応とは（基礎定義）

CSR(クライアントサイドレンダリング)は、ブラウザ側でJavaScriptを実行して初めて本文が組み立てられる方式です。人間のユーザーがブラウザで見る画面には問題なく表示されますが、JavaScriptを実行しないクローラーには、その本文が存在しないページとして映ります。

この違いを理解しないままサイトを構築すると、デザイン・操作性は優れていても、AI検索からは「情報がないページ」として扱われる恐れがあります。

04なぜAIクローラーの多くはJavaScriptを実行しないのか

主要AIクローラーがJavaScriptを実行しない実態は、Webインフラ企業Vercelの調査データで裏付けられています。ChatGPTのクローラーはJavaScriptファイルを11.50%の頻度で取得します。しかし実行した形跡は確認されていません(出典: Vercel「The rise of the AI crawler」2024年12月17日公開)。 同調査はClaudeBotなど主要AIクローラーについても、いずれも現時点でJavaScriptをレンダリングしないと報告しています。

OpenAIが公開する複数のクローラーの役割の違いは、姉妹記事『GPTBot・OAI-SearchBot・ChatGPT-User比較』で解説しています。

なお、この調査データは2024年12月時点のものです。各社のクローラー仕様は更新されうるため、最新の挙動は自社ログでの確認とあわせて判断することをおすすめします。

問題が起きやすいのは、いわゆる「アプリシェルモデル」のサイトです。Google公式ドキュメントは、この種の設計を次のように説明しています。初期HTMLに実際のコンテンツが含まれず、「JavaScriptが生成する実際のページコンテンツを見る前に、JavaScriptを実行する必要がある」という状態です。CSRで構築されたSPAの多くは、この構造に該当します。

AIクローラーの許可・拒否そのものの設定は、本記事の範囲外です。robots.txtでの制御方法は、姉妹記事『AIクローラー別robots.txt設計テンプレ集【2026年版】』を参照してください。

05自社サイトが「空白ページ」問題を抱えているか診断する4つの方法

自社サイトがこの問題を抱えているかどうかは、次の4つの方法で確認できます。手軽さの順に並べています。

方法具体的な手順確認できること
JavaScript無効化での閲覧ブラウザの開発者ツールでJavaScriptを無効にし、該当ページを再読み込みする本文がJavaScriptなしでも表示されるか
view-source確認ブラウザで「ページのソースを表示」を開き、本文がHTML内に存在するか確認する初期HTMLの時点で本文が含まれているか
URL検査ツールSearch Consoleの「URL検査ツール」でレンダリング後のHTML・スクリーンショットを確認するGooglebotが実際に取得・処理できている内容
curlでの取得AIクローラーのUser-Agentを指定して初期HTMLを取得し、本文の文字列を検索するAIクローラーに実際に届いているHTMLの中身

Google公式ドキュメントは、URL検査ツールについて「読み込まれたリソース、JavaScriptコンソールの出力、レンダリングされたDOMを確認できる」と説明しています。この機能を使えば、Googlebotの視点で自社ページがどう見えているかを直接確認できます。

AIクローラーはGooglebotと異なりJavaScriptを実行しないため、view-source確認のほうがAIクローラー視点の診断としては実態に近い方法です。3つの方法を併用し、複数の視点で本文の有無を確認することをおすすめします。

なお、AIクローラーの見え方に最も近い形で確認したい場合は、コマンドラインで初期HTMLをそのまま取得する方法があります。User-Agentによって配信内容を出し分けているサイトでも、実態を確認できます。

# 初期HTMLに本文が含まれているかを、AIクローラーのUser-Agentで確認する
curl -s -A "GPTBot/1.4" https://example.com/your-page/ | grep -c "本文の一部を貼り付ける"

出力が0であれば、その文字列は初期HTMLに存在しません。つまりJavaScriptを実行しないクローラーには、そのページの本文が届いていない状態です。主要な数ページで試し、0が返るページから優先的に対処してください。

06解決策1: SSR(サーバーサイドレンダリング)

SSRは、サーバー側でJavaScriptを実行し、本文を組み込んだ完成済みのHTMLをブラウザ・クローラーへ返す方式です。Next.js・Nuxtなど主要なフレームワークは、SSRを標準機能として備えています。

初期HTMLの時点で本文がすでに含まれているため、JavaScriptを実行しないAIクローラーでも、人間のユーザーと同じ情報を取得できます。Google公式ドキュメントも、ダイナミックレンダリングに代わる解決策の1つとしてSSRを挙げています。

一方で、ページを表示するたびにサーバー側でレンダリング処理が発生するため、サーバーの負荷・応答速度への配慮が必要になります。更新頻度の高いページや、ユーザーごとに内容が変わるページに向いた方式です。

07解決策2: SSG(静的サイト生成)

SSGは、ビルド時にあらかじめ全ページのHTMLを生成しておき、リクエストのたびに静的なHTMLファイルをそのまま返す方式です。ブログ記事・製品ページなど、更新頻度が低いコンテンツに向いています。

サーバー側でのリアルタイムなレンダリング処理が不要なため、応答速度に優れ、AIクローラーへの負荷も小さくなります。Google公式ドキュメントも、SSRと並ぶ代替解決策として「静的レンダリング」を挙げています。

コンテンツの更新頻度が低いサイトはSSG、ユーザーごとに内容が変わる・更新が頻繁なサイトはSSRを軸に検討するのが実務上の目安です。両方を組み合わせるハイブリッド構成を採用するフレームワークも増えています。

08解決策3: ハイドレーション(SSR/SSGと組み合わせる前提)

ハイドレーションは、SSR・SSGと並列に選ぶ「第3の選択肢」ではありません。サーバー側で生成したHTMLを配信したうえで、ブラウザ到着後にJavaScriptで対話機能を後付けする仕組みを指します。SSR・SSGで配信したページに、クリックや入力といった動きを取り戻すための工程です。

AIクローラー対応の観点で重要なのは、ハイドレーション前のHTMLに本文が含まれているかどうかという一点に尽きます。JavaScriptを実行しないクローラーは、ハイドレーションが起きる前の状態しか見ません。ここに本文が入っていれば、後段でどれだけ複雑な処理が走っても影響はありません。

逆に、初期HTMLを骨組みだけにして本文をハイドレーション後に流し込む実装にすると、SSRを導入しているつもりでもCSRと同じ結果になります。SSR/SSGを採用したあとは、前節のcurlによる確認を必ず一度は行ってください。

09ダイナミックレンダリングはなぜ非推奨になったのか

ダイナミックレンダリングは、ユーザーエージェントを判定し、クローラーにだけサーバー側でレンダリング済みのHTMLを返す方式です。かつては、CSRサイトの一時的な回避策として広く案内されていました。

Google公式ドキュメントの記述は明快です。「ダイナミックレンダリングは、検索エンジンにおけるJavaScript生成コンテンツの問題に対する回避策であり、長期的な解決策ではありませんでした」。 同ページの最終更新日は2025年12月10日です。ただしGoogleがこの位置づけを打ち出したのは2022年の文書改訂時とされており、直近で方針が変わったわけではありません。

問題は、ユーザーエージェント判定という仕組み自体の複雑さです。判定ロジックの継続的なメンテナンスが必要になるうえ、GPTBot・ClaudeBot・PerplexityBotなどAIクローラーはそもそもJavaScriptを実行しません。ダイナミックレンダリングが想定する「クローラー向けの特別対応」という発想自体が、AIクローラーとはかみ合いにくくなっています。

新規サイトを構築する場合、ダイナミックレンダリングを起点に設計するのではなく、SSR・SSGを土台にすることをおすすめします。

10実装方針の選び方(サイト規模・更新頻度別)

ここまでの選択肢を踏まえ、実務でどう判断すればよいかを整理します。

  1. 新規サイトを構築する場合: SSRまたはSSGを土台に設計する。ダイナミックレンダリングは選択肢に含めない
  2. 既存のCSRサイトを段階的に移行する場合: 優先度の高いページ(トップページ・主要な商品ページ・記事ページ)からSSR/SSGへ移行する
  3. 更新頻度が低いコンテンツが中心の場合: SSGを軸に検討する
  4. ユーザーごとに内容が変わる、更新頻度が高い場合: SSRを軸に検討する
  5. フレームワークの移行が難しい場合: 該当ページだけプリレンダリングしたHTMLを配信する部分的な対応も検討する

内部リンク構造の整備とあわせて実施すると効果的です。href付きリンクへの統一や階層設計の考え方は、姉妹記事『サイト構造とAIクローラビリティの関係｜設計手順を7ステップで解説』で扱っています。

11チェックリスト

  • JavaScript無効化した状態で、主要ページの本文が表示されるか確認した
  • view-source(ページのソースを表示)で、初期HTMLに本文が含まれているか確認した
  • Search ConsoleのURL検査ツールで、レンダリング後のHTMLを確認した
  • AIクローラーのUser-Agentを指定したcurlで、初期HTMLに本文が含まれるか確認した
  • 新規サイト構築でダイナミックレンダリングを起点にしていない
  • 更新頻度に応じてSSR/SSGの使い分けを検討した
  • SSR/SSG導入後、本文がハイドレーション前のHTMLに含まれているか再確認した
  • 移行の優先順位を、主要ページから順に整理した

12よくある失敗

ダイナミックレンダリングを恒久的な解決策として導入してしまう。ユーザーエージェント判定の仕組みは複雑で、継続的なメンテナンスが必要です。Googleが「長期的な解決策ではない」と明記している以上、新規構築では避けることをおすすめします。

JavaScript無効化での確認だけで満足してしまう。ブラウザでの見え方の確認は重要ですが、Search ConsoleのURL検査ツールなど、実際のクローラー視点での確認もあわせて行うことをおすすめします。

全ページを一度に移行しようとしてしまう。SSR/SSGへの移行は、フレームワークやページ数によっては大掛かりな作業になります。優先度の高いページから段階的に移行するほうが、現実的な計画になります。

13FAQ

Q. JavaScriptを使うと必ずAIクローラーに読まれなくなりますか?

一律に読まれなくなるわけではありません。問題になるのは、本文などの重要な情報がJavaScript実行後にしか表示されない場合です。ナビゲーションのアニメーションなど、本文に影響しない部分へのJavaScript利用は、大きな問題にはなりません。

Q. SSRとSSG、どちらを選べばよいですか?

更新頻度と、ユーザーごとに内容が変わるかどうかで判断することをおすすめします。更新頻度が低いコンテンツはSSG、更新頻度が高い・パーソナライズが必要なコンテンツはSSRが目安です。

Q. ダイナミックレンダリングは今すぐ廃止すべきですか?

既存サイトで運用中の場合、即座に廃止する必要はありません。ただしGoogleが「回避策」と位置づけている以上、新規構築や大規模な改修のタイミングでSSR/SSGへの移行を検討することをおすすめします。

Q. フレームワークを変更せずに対応する方法はありますか?

特定ページだけをプリレンダリングしたHTMLとして配信する部分的な対応も選択肢の1つです。ただしサイト全体の恒久対応としては、SSR/SSGへの移行が現時点でGoogleが推奨する方式です。

14まとめ

主要なAIクローラーの多くはJavaScriptを実行せず、初期HTMLに含まれる情報だけを読み取ります。この制約を踏まえ、SSR・SSGを土台にした実装へ移行することが、AIクローラー対応の基本方針です。

ダイナミックレンダリングは、Googleが回避策であり長期的な解決策ではないと明記した方式です。新規構築ではSSR・SSGを起点に、既存サイトは優先度の高いページから段階的に移行を進めてください。