p4ni.

比較

AI クローラーは JavaScript を実行するのか(GPTBot が実際に見ているもの)

· 読了まで約8分

目次

短く答えると、実行しません。2026年半ばの時点で、主要な AI クローラーはどれも JavaScript を実行しません。GPTBot も、ClaudeBot も、PerplexityBot も、Meta や ByteDance のクローラーもです。HTML を取得し、そこに書いてあるものを読み、次へ行きます。あなたの JavaScript がページに描画したはずのものは、クローラーにとっては最初から存在しません。

Google は10年かけて「Googlebot はヘッドレス Chromium でページを描画するから、クライアントサイドレンダリングでも大丈夫」と業界に教え込みました。その前提は、もう全体には当てはまりません。AI 検索と AI 学習に流れ込む第2のクローラー集団が現れ、その集団が読むのは DOM ではなくソース表示のほうだからです。

この記事では、AI クローラーが静的サイトから受け取るものと、クライアントレンダリングのサイトから受け取るものを並べて、どれだけ気にすべきかを考えます。

誰が巡回していて、何を飛ばすのか

知っておく価値のあるユーザーエージェントは3群に分かれます。学習用のクローラー(GPTBot、ClaudeBot、Meta-ExternalAgent、Bytespider)、AI 回答エンジンの検索インデックス用クローラー(OAI-SearchBot、Claude-SearchBot、PerplexityBot)、そしてユーザーがいま質問したからページを取りに来るライブフェッチャー(ChatGPT-User、Claude-User、Perplexity-User)。

目的は違いますが、ここで関係する挙動は同じです。少なくとも名乗っているクローラーは、どれもスクリプトを走らせません。

一方で、JavaScript ファイルのダウンロード自体はします。サーバーログを読むと、ここで混乱しがちです。Vercel と MERJ が公開したクロール分析はそれを実測していて、GPTBot はフェッチのおよそ 11.5% を、実行もしない JavaScript ファイルに費やしていました。

クローラーはファイルを集めはするものの(おそらく学習データとして、あるいはリンク抽出のために)、描画は起きていません。GPTBot のユーザーエージェントで main.js がアクセスログに出ていても、それは React アプリが描画された証拠にはなりません。

Googlebot だけは例外のままです。いまも描画しますし、Google の AI 機能はそのインデックスを引き継ぎます。それ以外は、curl と同じ視界でサイトを見ています。

2分でできる確認

推測で済ませる必要はありません。全部ターミナルから確かめられます。クローラーと同じやり方でページを取得して、返ってきたものの中に自分のコンテンツがあるか探します。

curl -s -A "GPTBot" https://astro.p4ni.com/ja/blog/cloudflare-pages-vs-workers/ \
  | grep -c "段階的デプロイ"

このサイトなら該当ありで返ってきます。記事がすべて静的にプリレンダリングされているからで、見出しもコードブロックも含めて全文が HTML レスポンスの中にあります。生の HTML を読むクローラーは、1リクエストで記事を丸ごと受け取れます。

同じ確認をクライアントレンダリングのアプリに向けると、返ってくるのは中身のない HTML です。

<!doctype html>
<html>
  <head>
    <script type="module" src="/assets/index-Bka92mQd.js"></script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

描画しないクローラーにとっては、この <div id="root"></div> が「コンテンツ」の全部です。製品説明もドキュメントもブログ記事もありません。Googlebot はこのアプリを描画してインデックスします。一方 AI クローラーから見れば、このサイトは実質 title タグ1枚です。

自分のサイトでも試せます。ブラウザの JavaScript を切ってみるか、いちばん重要なページの一節を curl | grep してみる。レスポンスにその一節が無ければ、AI 検索に引用される見込みはありません。

クローラーの席から見た静的 HTML と CSR

静的・サーバーレンダリングクライアントレンダリング
Googlebot全文全文(描画キューの後)
GPTBot / ClaudeBot / PerplexityBot全文空の殻
ChatGPT-User(ライブフェッチ)全文空の殻
クローラー側のコスト1リクエスト何も得られない1リクエスト

要点はこの非対称さです。静的 HTML は追加の労力ゼロで両方の読者に応えるのに、CSR は片方にだけ応えて、もう片方を黙って取りこぼします。

Astro と Next.js が既定で何を配信するかを自分で測ったときの数字は、JavaScript 645 バイト対 642 kB でした。AI クローラーの側から見ると、同じ数字が可視性の問題として立ち上がります。静的なページのほうが軽いという以前に、その JavaScript が1バイトも走らなくてもコンテンツはそこにある、ということです。

念のため書くと、これは「JavaScript フレームワークは見えない」という話ではありません。SSR か静的エクスポートを使う Next.js のサイトは完全な HTML を配信しますし、何の問題もありません。Astro のアイランドは完全な HTML の上にインタラクティブなコンポーネントをハイドレートするので、どちらにせよコンテンツはクローラーから見えます。

線を引くのはフレームワークではありません。コンテンツが最初のレスポンスに入っているか、それともブラウザの中で後から組み立てられるかです。そしてそのブラウザを、クローラーは持っていません。

で、今それは実害なのか

費用対効果を正直に書きます。2026年のマーケティング文書は「AI 検索は未来だ」の一言で論証を済ませがちなので、気にすべき理由と慌てなくていい理由を分けます。

気にすべき側の理屈から。AI アシスタントは引用付きで質問に答えることが増えていて、その引用から、控えめではあれ実際に参照トラフィックが来ます。引用されえないということは、そのチャネルがどれだけ育とうと、そこに存在しないということです。

動いているのは AI の側だけではありません。ツールのベンダー側も開発サーバーの段階で AI エージェントを検出しはじめていますし、クローラーのトラフィックは公開されている計測を見るかぎり伸び続けています。ブログ、ドキュメント、製品ページといったコンテンツサイトは、まさに AI の回答で引用される種類のもので、同時に静的レンダリングの採用コストがゼロの種類のものでもあります。

では逆に、慌てなくていい理由は何か。AI 経由の参照は、私の見ている範囲ではまだ検索経由のごく一部です。CSR のフロントエンドで動いている製品が、設定画面を読めないクローラーのために緊急の書き直しを迫られる理由はありません。ログインの向こうにあるアプリの画面は、そもそも誰にもまともにクロールされる予定がありませんでした。

落としどころはこうです。公開コンテンツがクライアントレンダリングなら、それはもう実在する穴。アプリがそうなだけなら、穴ではない。すでに静的なサイトにとっては追加の作業がゼロで、構造上、AI クローラーからも中身が見えています。

すでに静的なら、もう一歩

静的なサイトにとって、次の問いは「どれだけ読みやすくしてやるか」になります。手間の軽い追加が2つあります。

  • llms.txt — AI の読者に向けたサイトの Markdown 索引で、ページと同じ content collections から生成できます。クローラー側の採用状況はまだ未知数ですが(誰が実際に取りに来ているかは、リンク先の後半に書きました)、コストはビルド時のエンドポイント1本です。
  • 構造化データ — JSON-LD は最初の HTML の中にあるので、スクリプトを飛ばすクローラーもメタデータのほうは受け取ります。著者、日付、これが何のページなのか。機械可読な層が効くのは、まさに描画に依存していないからです。

どちらも、レンダリングの問題そのものを決めているのと同じ原則から出てきます。自分の HTML を読むのは、こちらのコードを走らせない機械だと想定する。

Googlebot は長年、その原則を大目に見てくれる例外でした。新しいクローラー群では、厳格な解釈がふたたび当たり前になりました。静的サイトは、アーキテクチャの好き嫌いは別として、その違いを一度も気にせずに済んだ唯一の構成です。