「ReactやVueで、見た目も操作性もいいサイトを作ったのに、AI検索からの流入だけが伸びない」。制作を担当した方から、こうした相談を受けることがあります。

調べてみると、原因はデザインでも内容でもなく、AIクローラーの多くがJavaScriptを実行しないという、技術的な制約にあることが少なくありません。人間が見ている画面と、AIクローラーが読み取っている中身が、実はまったく違う場合があるのです。

この記事は、自社サイトがAI検索から「空白ページ」のように扱われていないか、はじめて確認する方を想定して書きました。専門用語は出てきたその場で言い換えます。図解と会話をはさみながら、最後は自社サイトに合った直し方まで一緒に整理します。

こんなふうに調べていませんか

  • ReactやVueで作ったサイトのAI検索からの流入が伸びず、原因を探している
  • 「JavaScript レンダリング AIクローラー」で検索して、専門用語の多さに戸惑っている
  • SSRやSSGという言葉を聞いたことはあるが、自社にどちらが向いているか分からない

この記事を読み終えたときに手に入るもの

  • AIクローラーがJavaScriptを実行しない理由を、人に説明できるようになります
  • 自社サイトが「空白ページ」問題を抱えているか、4つの方法で確認できるようになります
  • SSR・SSG・ダイナミックレンダリングの違いと、自社に合った選び方が分かります

結論30秒でわかる、この記事の結論

  • 主要なAIクローラーの多くは、JavaScriptを実行しません。 読み取るのは、ページの初期HTMLに含まれる情報だけです。
  • ReactなどでクライアントサイドレンダリングしているCSRのサイトは、AIクローラーには「本文のない空白のページ」として映っているおそれがあります。
  • Googleは、この問題への対処として長く案内してきた「ダイナミックレンダリング」を、回避策と位置づけています。代わりに案内されているのが、SSR(サーバーサイドレンダリング)とSSG(静的サイト生成)です。
そのサイト、AI検索には何が見えていますか?その原因、一緒に確認していきましょうそのサイト、AI検索には何が見えていますか?なぜ読まれないのかAIクローラーの多くはJSを実行しない自社の状態を確認する方法4つの確かめ方SSR・SSGへの移行の考え方土台から選ぶ判断の順番鈴木さんその原因、一緒に確認していきましょう
そのサイト、AI検索には何が見えていますか? — その原因、一緒に確認していきましょう

この記事では、Web担当の若葉さんとマーケ課長の高梨さん、外部コンサルタントの鈴木さんの会話をはさみながら進めます。あなたに近い立場の人の質問から読んでいただいて構いません。

01そもそもJavaScriptのレンダリングは、AI検索でAIクローラーにどう見えているんですか?

若葉さん
若葉さんの発言

うちのサイト、Reactで作っていて見た目はきれいなんですけど…AI検索からの流入がずっと伸びなくて。そもそも何が起きているのか、想像もつかなくて。

鈴木さん
鈴木さんの発言

それは、よくいただくご相談です。ひとことで言うと、AIクローラーの多くは、JavaScriptを実行しないんですよ

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

この違いを知らないままサイトを構築すると、デザインや操作性がどれほど優れていても、AI検索からは「情報がないページ」として扱われるおそれがあります。初期HTMLに本文を含めておくことは、AI検索最適化LLMOとも呼ばれます)の出発点でもあります。

この章のまとめ

CSRは、ブラウザ側でJavaScriptを実行してはじめて本文が組み立つ方式です。人間の画面には問題なく出ますが、JavaScriptを実行しない相手には本文がまだ無いページとして映ります。

02AIクローラーがJavaScriptを実行しない根拠は、AI検索の調査で示されているんですか?

高梨課長
高梨課長の発言

「実行しない」というのは、どこかで確かめられている話なんでしょうか。感覚の話だと社内で通しにくいのですが。

鈴木さん
鈴木さんの発言

公開されている調査データがあります。取得はするけれど、実行した形跡はないという報告です。

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

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

ブラウザとAIクローラーでは、見えているものが違います同じ初期HTMLからスタートしても、途中で分かれますブラウザとAIクローラーでは、見えているものが違います同じ初期HTMLからスタートしても、途中で分かれますブラウザで見える流れ初期HTMLを受け取るJavaScriptを実行する本文が組み立って表示される人間のユーザーが見る画面AIクローラーに見える流れ初期HTMLを受け取るJavaScriptは実行しない本文がないまま終わる空白ページとして扱われるおそれ
ブラウザとAIクローラーでは、見えているものが違います — 同じ初期HTMLからスタートしても、途中で分かれます

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

この章のまとめ

AIクローラーの多くはJavaScriptを実行しません。CSRで本文を組み立てているサイトは、AI検索には空白のページとして映っているおそれがあります。

03AI検索とAIクローラーの話がむずかしいので、出前の料理にたとえてもいいですか?

若葉さん
若葉さんの発言

JavaScriptを実行しない、というのが、まだ実感としてつかめなくて…何か身近なものにたとえてもらえませんか。

鈴木さん
鈴木さんの発言

いいですよ。出前の料理にたとえてみましょう。

出前の配達員は、すでに完成した料理しか受け取って運べません。厨房でこれから調理するための材料とレシピだけを渡されても、配達員はそれを客席まで運べないですよね。

AIクローラーも、これと同じ立場です。初期HTMLの時点で本文が完成しているページ(SSR・SSGで作られたページ)は、そのまま受け取って読めます。一方、初期HTMLが空っぽで、JavaScriptという「厨房での調理」を経てはじめて本文が完成するページ(CSRのページ)は、完成前の状態しか渡されないため、中身を読み取れません。

渡す時点で完成しているかAIクローラーは「実行後」の姿を待てません渡す時点で完成しているかAIクローラーは「実行後」の姿を待てませんSSR・SSGのページ初期HTMLの時点で本文が完成CSRのページ本文はJS実行後に組み上がる
渡す時点で完成しているか — AIクローラーは「実行後」の姿を待てません

このたとえで言うと、この記事の後半でやることは、「厨房での調理」に頼らず、配達の時点ですでに完成した状態で渡すように作り方を変えることです。

この章のまとめ

AIクローラーは、完成した状態のものしか受け取れない配達員のようなものです。JavaScript実行後に完成するページは、完成前の状態しか渡っていません。

04自社サイトがAIクローラーに「空白ページ」と見えていないか、AI検索でどう確かめるんですか?

高梨課長
高梨課長の発言

鈴木さん、うちのサイトが実際にこの問題を抱えているかどうか、専門知識がなくても確認する方法はありますか。

鈴木さん
鈴木さんの発言

はい、4つの方法があります。手軽なものから順にご紹介しますね。

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

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

この章のまとめ

自社サイトの状態は、JavaScript無効化・view-source・URL検査ツール・curlの4つの方法で確認できます。手軽な順に試して構いません。

05AIクローラーに実際に届いているHTMLは、AI検索対策としてどう取り出すんですか?

若葉さん
若葉さんの発言

Search Consoleで見えるのはGooglebotの視点ですよね。AIクローラーの視点そのものは、見られないんでしょうか。

鈴木さん
鈴木さんの発言

見られます。初期HTMLをそのまま取ってくるのが、いちばん実態に近い確認方法です。

ただし、AIクローラーはGooglebotと異なりJavaScriptを実行しません。AIクローラーの見え方に最も近い形で確認したいなら、コマンドラインで初期HTMLをそのまま取得する方法がいちばん実態に近づきます。

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

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

この章のまとめ

AIクローラーに近い視点で見たいなら、User-Agentを指定して初期HTMLを取得する方法がいちばん実態に近づきます。出力が0のページから優先して対処してください。

06JavaScriptレンダリング方式であるSSR・SSG・ハイドレーションは、AI検索最適化として何がどう違うんですか?

若葉さん
若葉さんの発言

直し方の話に進みたいんですが…SSRとかSSGとか、略語が多くてこんがらがってしまって。

鈴木さん
鈴木さんの発言

大丈夫です。1つずつ、役割から整理しましょう。

SSR(サーバーサイドレンダリング)は、サーバー側でJavaScriptを実行し、本文を組み込んだ完成済みのHTMLをブラウザやクローラーへ返す方式です。Next.js・Nuxtなど主要なフレームワークは、SSRを標準機能として備えています。初期HTMLの時点ですでに本文が入っているため、JavaScriptを実行しないAIクローラーでも、人間のユーザーと同じ情報を取得できます。一方で、ページを表示するたびにサーバー側で処理が発生するため、サーバーの負荷や応答速度への配慮が必要です。更新頻度の高いページや、ユーザーごとに内容が変わるページに向いています。

SSG(静的サイト生成)は、ビルド時にあらかじめ全ページのHTMLを生成しておき、リクエストのたびに静的なHTMLファイルをそのまま返す方式です。ブログ記事や製品ページなど、更新頻度が低いコンテンツに向いています。サーバー側でのリアルタイムな処理が不要なため、応答速度に優れ、AIクローラーへの負荷も小さくなります。

Google公式ドキュメントも、ダイナミックレンダリングに代わる解決策として、この2つ(SSRと「静的レンダリング」)を挙げています。

SSR・SSG・ダイナミックレンダリング、何が違いますか並べて比べると、向き不向きが見えますSSR・SSG・ダイナミックレンダリング、何が違いますか並べて比べると、向き不向きが見えますSSRサーバーで都度レンダリング更新頻度の高いページに向くSSGビルド時に事前生成更新頻度が低いコンテンツに向く非推奨ダイナミックレンダリングクローラーにだけ別HTML、回避策
SSR・SSG・ダイナミックレンダリング、何が違いますか — 並べて比べると、向き不向きが見えます

この章のまとめ

SSRは表示のたびにサーバーで処理し、SSGはビルド時に事前生成します。Google公式も、この2つをダイナミックレンダリングに代わる解決策として挙げています。

07ハイドレーションは、AIOではJavaScriptレンダリングとしてSSR・SSGとは別の選択肢なんですか?

高梨課長
高梨課長の発言

もう1つ、ハイドレーションという言葉も見かけたんですが、これは3つ目の選択肢なんですか?

鈴木さん
鈴木さんの発言

いえ、そこは誤解されやすいところです。ハイドレーションは、SSR・SSGと並ぶ「第3の選択肢」ではありません。

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

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

逆に、初期HTMLを骨組みだけにして本文をハイドレーション後に流し込む実装にすると、SSRを導入しているつもりでも、AIクローラーから見た結果はCSRと変わらなくなってしまいます。SSR・SSGを採用したあとは、前章のcurlによる確認を、一度は行ってください。

この章のまとめ

SSRは表示のたびにサーバーで処理し、SSGはビルド時に事前生成します。ハイドレーションはそのどちらとも組み合わせて使う「後付けの動き」であり、独立した3つ目の選択肢ではありません。

08なぜダイナミックレンダリングは、AI検索対策の長期的な解決策にならないんですか?

高梨課長
高梨課長の発言

ダイナミックレンダリングという言葉も聞いたことがあるんですが、それではダメなんですか?

鈴木さん
鈴木さんの発言

そこは、Google自身がはっきりと立場を示しているところなんです。

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

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

検索エンジンの案内が変わってきた道のり出典が確認できている3つの節目検索エンジンの案内が変わってきた道のり出典が確認できている3つの節目2022年文書改訂ダイナミックレンダリングを回避策と位置づけ2024年12月17日Vercel調査を公開ChatGPTクローラーがJSを実行しないと報告2025年12月10日Google公式ドキュメント最終更新回避策という位置づけを維持
検索エンジンの案内が変わってきた道のり — 出典が確認できている3つの節目

この章のまとめ

Google公式ドキュメントは、ダイナミックレンダリングを「長期的な解決策ではなかった」と明記しています。直近で方針が変わったわけではありません。

09AI対策で、ユーザーエージェント判定がAIクローラーとかみ合わないのはなぜですか?

若葉さん
若葉さんの発言

クローラーにだけ別のHTMLを返す、という発想自体はダメなんでしょうか。

鈴木さん
鈴木さんの発言

発想の前提が崩れているんです。そもそもAIクローラーはJavaScriptを実行しないので、「実行できない相手のための特別対応」という枠組みがかみ合いません。

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

ダイナミックレンダリングの前提と、AIクローラーの実際「クローラー向けの特別対応」という発想がかみ合いませんダイナミックレンダリングの前提と、AIクローラーの実際「クローラー向けの特別対応」という発想がかみ合いませんダイナミックレンダリングの前提クローラーを判定して別のHTMLを返す判定ロジックを継続的にメンテナンスする仕組みが複雑になりますAIクローラーの実際GPTBot・ClaudeBot・PerplexityBotはJavaScriptを実行しない特別対応をしなくても初期HTMLがあれば読めるだからSSR・SSGを土台にします
ダイナミックレンダリングの前提と、AIクローラーの実際 — 「クローラー向けの特別対応」という発想がかみ合いません

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

この章のまとめ

ユーザーエージェント判定は、判定ロジックの継続的なメンテナンスが必要になります。そのうえAIクローラーはJavaScriptを実行しないため、この仕組み自体がかみ合いません。新規構築ではSSR・SSGを起点にするのが実務的です。

10AI検索対策として、JavaScriptのレンダリングをAIクローラー向けにどう直せばいいんですか?

高梨課長
高梨課長の発言

全部の考え方は分かってきました。それで、実際うちの場合はどれを選べばいいんでしょうか。

鈴木さん
鈴木さんの発言

サイトの状況によって変わるので、判断の順番を整理しますね。

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

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

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

この章のまとめ

新規構築はSSR・SSGを土台に、既存サイトは優先度の高いページから段階的に移行するのが実務的な進め方です。

11AI検索対策でやってしまいがちな失敗って、AIクローラー対応で何がありますか?

これまでの内容を踏まえ、確認しておきたいチェック項目と、よくある失敗をまとめます。

移行の前後で、確認したいことはこれですできているかどうかを、順にチェックします移行の前後で、確認したいことはこれですできているかどうかを、順にチェックしますview-sourceで初期HTMLに本文があるか確認したJavaScriptを実行しない視点での確認curlでAIクローラーのUser-Agentから本文が取得できるか確認した実際にAIクローラーへ届いている中身に近い確認ダイナミックレンダリングを恒久的な解決策として使い続けているGoogleは「長期的な解決策ではない」と明記している全ページを一度に移行しようとしている優先度の高いページから段階的に移行するほうが現実的
移行の前後で、確認したいことはこれです — できているかどうかを、順にチェックします

この章のまとめ

移行そのものより、「恒久策のつもりでダイナミックレンダリングを使い続けること」と「一度に全部を移行しようとすること」の2つが、遠回りの原因になりやすい失敗です。

12よくある質問

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

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

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

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

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

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

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

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

13まとめ|今日確認する3つのこと

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

今日この順で確認します

  1. view-sourceで、主要ページの本文が初期HTMLに含まれているか見る

    JavaScriptを実行しない視点での確認になります

  2. curlでAIクローラーのUser-Agentを指定し、本文の文字列が取得できるか試す

    実際にAIクローラーへ届いている中身に近い確認です

  3. 新規構築・大規模改修のタイミングを、SSR・SSGへ移行する機会として検討する

    ダイナミックレンダリングを起点にしない方針です

AI検索では、こう聞かれています

  • JavaScriptで作ったサイトはAI検索から見えなくなりますか?

    「そもそもJavaScriptのレンダリングは、AI検索でAIクローラーにどう見えているんですか?」の章で、仕組みから説明しています

  • 自社サイトがAIクローラーに読まれているか、どうやって確認すればいいですか?

    「AIクローラーに実際に届いているHTMLは、AI検索対策としてどう取り出すんですか?」の章に、curlを使った確認方法があります

  • SSRとSSG、AIクローラー対策としてはどちらを選べばいいですか?

    「AI検索対策として、JavaScriptのレンダリングをAIクローラー向けにどう直せばいいんですか?」の章で、状況別の判断の順番を整理しています

次に読むなら、この記事です