AIクローラーはJavaScriptを実行しない — サーバーレンダリングがGEOの前提になる理由 | Suparanku

事実関係：何がわかっているか

Vercel社はMERJ社と共同で、自社ネットワーク上のAIクローラーのトラフィックを分析しました。2025年初頭の時点で、GPTBotだけで月間5億件超のリクエストを観測し、結論は明快でした：JavaScriptを実行した痕跡はゼロ。GPTBotはJSファイル自体をダウンロードすることはあっても（リクエストの約11.5%）、実行はしません。ClaudeBotやPerplexityBotも同様です。

なお、ChatGPTの引用を支えているのは検索用ボットのOAI-SearchBotとChatGPT-Userであり、GPTBotは学習用のクローラーです。GPTBotをブロックしてもモデルの学習に影響するだけですが、OAI-SearchBotをブロックすると自社サイトはChatGPTの回答から消えてしまいます。許可・拒否のルールやCDNの確認は、GPTBotだけでなく検索用ボットも対象に含める必要があります。

つまり、ReactやVueでクライアントサイドだけでレンダリングされるページは、AIクローラーから見ると「ほぼ空のHTML」です。製品説明も料金も、ハイドレーション後にしか現れないなら、AIの学習にも回答生成にも使われません。

自社サイトを3分で確認する方法

1. ブラウザの開発者ツールでJavaScriptを無効化し、重要ページ（製品・料金・会社情報）を再読み込みします。本文が見えればサーバーレンダリングです。
2. もしくはページで右クリック→「ページのソースを表示」。ソースHTMLの中に本文テキストが含まれているかを確認します。<div id="root"></div>だけなら危険信号です。
3. あわせてCDN・WAFの設定も確認してください。robots.txtでAIボットを許可していても、CDN側が既定でブロックしているケースがあり、これはよくある隠れ原因です。Otterly社が100万件超のAI引用を分析したところ、73%のサイトにAIクローラーを妨げる技術的な障壁があることが判明しています。

対処の選択肢

• 静的生成（SSG）：コンテンツ中心のサイトの第一選択。ビルド時にHTMLが完成するため、クローラー・速度・運用のすべてに有利です。本サイトもこの方式です。
• サーバーサイドレンダリング（SSR）：リアルタイム性が必要なページに。リクエスト毎にサーバーがHTMLを返します。
• インタラクティブ部分の分離：ページ全体をSPA化せず、必要なウィジェットだけをクライアントで動かす設計（アイランド方式）にすれば、本文は常に静的HTMLに残ります。

なお、Googleの通常検索はJavaScriptをレンダリングできますが、Google自身もAI機能について「コンテンツがクロール・インデックス可能であること」を前提条件として挙げています。ただし2025年12月以降、Googleはステータスコードが200以外のページ（リダイレクトやエラー）をレンダリングのパイプラインから完全に除外しており、こうしたページ上のクライアントサイドJSはGoogleにすら見えません。サーバーレンダリングは全プラットフォーム共通の安全側の選択です。

まとめ

GEOの施策論の多くは「何を書くか」に集中しますが、その前に「書いたものがAIに見えているか」という技術の関門があります。JavaScript無効で本文が見えること、CDNがAIボットを遮っていないこと — この2点の確認が、すべてのGEO施策の出発点です。

関連用語：AIクローラー、RAG、GEO