最初に、最も重要な点をお伝えします。現在、主要なAIクローラーのほとんどはJavaScriptを実行しません。ページのコンテンツがブラウザ側でJSを実行して初めて生成される設計なら、GPTBot、ClaudeBot、PerplexityBotには空白ページとして映ります。これは順位の問題ではありません。そもそも認識されるかどうかを分ける、決定的な問題です。
Googlebotの挙動を基準に、AIクローラーも同じように動くと考える方は少なくありません。しかし、誤解はここから始まります。Googlebotは長年にわたり、成熟したJavaScriptレンダリング機能を整備してきました。純粋なフロントエンドレンダリングでも、時間とリソースは余計にかかるものの、コンテンツを取得できる可能性があります。一方、AIクローラーの仕組みは異なります。多くの場合、サーバーが返した元のHTMLを取得して読み、そのまま処理を終えます。ブラウザを起動せず、JSの実行を待たず、2回目のレンダリングも行いません。
AIクローラーとGooglebotは別物です
Googlebotのクロールは2段階で進みます。第1段階では元のHTMLを読み、取得できる内容を先に収集します。第2段階ではページをレンダリングキューに入れ、ChromeのようなヘッドレスブラウザでJavaScriptを実行し、動的に生成されるコンテンツを補完します。多大な計算リソースを要する仕組みですが、検索を中核事業とするGoogleだからこそ、そのコストを負担できます。
AI企業のクローラーには、この第2段階がありません。OpenAIのGPTBot、AnthropicのClaudeBot、Perplexityのクローラー、さらにChatGPTのリアルタイム検索を担うOAI-SearchBotは、現時点ではHTMLを取得した時点で処理を終えます。理由は現実的です。Web全体を対象にヘッドレスブラウザを動かすコストはあまりに大きく、必要なのは画面表示の再現ではなく、「モデルが直接読み込めるテキスト」だからです。フロントエンドの操作、アニメーション、遅延読み込みのために用意したJavaScriptも、AIクローラーにはノイズか空白にしかなりません。唯一の例外は、Googleの既存インデックスを基盤とし、Googlebotのレンダリング機能を利用できるGoogle AI Overviewsです。ただし、ChatGPT、Perplexity、Claudeも対象にするなら、JavaScriptが実行されることを前提にはできません。
3つのレンダリング方式は、AIからどう見えるのか
同じコンテンツでも、レンダリング方式によってAIクローラーが取得できる内容は大きく変わります。分かれ目は1つだけです。コンテンツが「サーバー側でHTMLに書き込まれている」のか、それとも「ブラウザ側でJSを実行した後に表示される」のかです。
- SSG（Static Generation／静的生成）：ビルド時に各ページの完全なHTMLを生成し、静的ファイルとして保存します。サーバーは完成済みのページをそのまま返すため、AIクローラーは全文を取得できます。最も読み取られやすく、表示も高速です。
- SSR（Server Side Rendering／サーバーサイドレンダリング）：リクエストのたびにサーバーが完全なHTMLをリアルタイムで組み立てて返します。AIクローラーは全文を取得できますが、毎回サーバー側で処理が発生します。アクセスが多い場合は負荷に注意が必要です。
- CSR（純粋なフロントエンドレンダリング）：サーバーが返すのは、ほぼ空のHTMLの骨組みだけです。実際のコンテンツは、ブラウザがJSをダウンロードして実行した後に挿入されます。AIクローラーがJSを実行しなければ、引用できるテキストがほとんどない空の骨組みしか取得できません。
端的に言えば、AIクローラーにとってSSGとSSRに本質的な違いはありません。どちらもサーバー側でコンテンツをHTMLに書き込みます。異なるのは「いつ生成するか」だけで、SSGは事前、SSRはリクエスト時に生成します。本当の分岐点はCSRです。シングルページアプリケーション（SPA）のフレームワークでサーバーサイドレンダリングを行っていない場合、初期HTMLには空のルートコンテナであるdivと複数のscriptタグしかないことがよくあります。AIクローラーが読むのは、そのテキストのないHTMLです。
30秒でできるセルフチェック
特別なツールも、エンジニアへの確認も必要ありません。重要なページをブラウザで開き、右クリックして「ページのソースを表示」を選択すれば、そのページをAIクローラーが読めるか判断できます。注意したいのは、開発者ツールの「Elements」パネルではないという点です。Elementsに表示されるのはJS実行後の結果なので、実態を見誤る可能性があります。「ページのソースを表示」で確認できるのは、サーバーが最初に返した元のHTMLであり、AIクローラーが実際に読む内容です。
CSRサイトを改善する方法
CSRだと分かっても、フロントエンド全体を作り直す必要はありません。一般的には、導入コストの低い順に3つの選択肢があります。
- プリレンダリング：クローラーがアクセスした際に、事前生成した静的HTMLのスナップショットを返します。既存のSPAを最小限の変更で素早く改善できる方法です。一方で、スナップショットを更新・管理する運用が別途必要になります。
- SSR／SSG対応フレームワークへの移行：Next.js、Nuxt、SvelteKitなどを使えば、ファーストビューのコンテンツをサーバー側でレンダリングしつつ、フロントエンドのインタラクションも維持できます。確実性が高く、多くのB2Bクライアントに標準的な選択肢として推奨している方法です。
- 重要ページからSSR化：リソースが限られている場合、サイト全体を一度に変更する必要はありません。商品・サービスページ、プランページ、料金ページ、詳細な解説記事など、AIに参照してほしいページからサーバーサイドレンダリングへ切り替えます。管理画面やインタラクティブなツールは、CSRのままでも問題ありません。
すべてのページをSSR化する必要はありません
レンダリング方式は、信条ではなく要件に応じて選ぶものです。ログイン後のダッシュボード、社内ツール、操作性を重視した設定ページは、AIからの参照を目的とするコンテンツではありません。CSRを維持するのが合理的であり、SSRにこだわればサーバー負荷が増えるだけです。重視すべきなのは、「AIに回答の情報源として使ってほしいページ」です。自社がどのような課題を、なぜ、どう解決し、他社と何が違うのかを説明するページが該当します。判断基準はシンプルです。そのページの内容をChatGPTやPerplexityの回答に表示させたいなら、コンテンツ全体がサーバー側のHTMLに存在していなければなりません。
GooglebotはJavaScriptの実行完了を待ちますが、AIクローラーは待ちません。AIが引用元を選ぶ時代には、見えないコンテンツは存在しないのと同じです。— Tenten GEO
台湾のB2Bサイトでよく見られるクロール可能性の問題は、コンテンツの質ではなく、そもそもAIにコンテンツが届いていないことです。原因はフレームワークの選定やレンダリング設定に潜んでいることが多く、通常の画面表示では問題なく見えても、「ページのソースを表示」して初めて発覚します。重要ページをAIが読み取れているか分からない場合は、当社の30分間GEO診断をご利用ください。実際のURLを基に、ファーストビューのHTMLにコンテンツが含まれているか、どのページから優先的にサーバーサイドレンダリングへ切り替えるべきかを確認します。
