JavaScriptナビゲーションはAI検索から見えない——41日間の実験が実証

JavaScriptナビゲーションはAI検索から見えない——41日間の実験が実証

要点: Search Engine Landが公開した41日間の統制実験で、ブラジルの事業分類ディレクトリサイト（約2,400ページ）を対象に、HTMLハードコードのリンクとJavaScript注入のリンクを比較したところ、GPTBot・ClaudeBot・Meta-ExternalAgent・Amazonbotの4クローラーはJavaScript注入リンクを一件も発見できなかった。 JavaScriptを実際に実行してリンクを辿ったのはGoogleのクローラースタック（Googlebot＋GoogleOther）のみだったが、検索インデックス構築を担うGooglebot自身の到達率もわずか2%（7ページ）にとどまり、「Googleなら万能」という前提も崩れた。 リンクをHTMLへ是正した後の回復速度もクローラーごとに大きく異なり、GPTBotは48時間、Bingbotは約1週間で再クロールされた一方、ClaudeBotは是正後も新規ページを発見しなかった。

最終更新日: 2026年8月20日

何が起きたのか

実験の設計

Search Engine Land（著者: Vinicius Stanula氏、編集: Isla McKetta氏、レビュー: Danny Goodwin氏）が2026年8月19日に公開した記事「How JavaScript links make your pages invisible to AI search」では、41日間にわたる統制実験の結果が詳しく報告されている。

対象サイトはブラジルの事業分類ディレクトリで、全体で約2,400ページ、そのうち階層構造をもつ1,062ページが実験対象になった。このサイトには21の最上位セクションがあり、実験ではこれを2グループに分けている。

• 11セクション: 内部リンクをHTMLにハードコード（ページソースを見れば誰でも、どんなクローラーでもリンク先を確認できる状態）
• 10セクション: 内部リンクをJavaScriptで動的に注入（ページのHTMLソースにはリンクが存在せず、ブラウザ上でJavaScriptを実行して初めてDOMに現れる状態）

計測の仕組みとして、エッジミドルウェアでボットリクエストをログ記録し、パス・ユーザーエージェント・リファラー・IP・タイムスタンプを追跡した。GooglebotとBingbotについては、なりすまし対策として逆引きDNSによる検証も行われている。実験設計上のポイントは、「JSグループのdivisionページ（下層ページ）へのアクセスがあった＝親ページ上でJavaScriptが実行され、注入されたリンクが実際に辿られた証拠」とみなす「発見シグナル」の考え方だ。これにより、各クローラーがJavaScriptを実行してリンクを辿る能力を実際に持っているかどうかを、間接的だが具体的な数値として可視化している。

41日間の総ボットリクエスト数は30,180件に達しており、規模としても十分な観測データが積み上がった実験と言える。

主要クローラー別の到達数

実験期間中に記録された、HTML階層ページとJS階層ページそれぞれへの到達数は以下の通りだ。

この表が示す事実は明確だ。8つのクローラーのうち、JavaScriptを実行して注入リンクを辿ったのはGoogleのクローラースタック（Googlebot・GoogleOther）だけである。GPTBot、ClaudeBot、Meta-ExternalAgent、Amazonbotの4クローラーはJS階層ページへの到達がゼロ、Bingbotのみ3件という結果だった。HTMLハードコードのセクションには数百件単位でアクセスしているにもかかわらず、JavaScriptで注入されたセクションの下層ページには実質的にたどり着けていない。

さらに注目すべきは、Googleのクローラースタック内部でも役割によって挙動が異なる点だ。実際に検索インデックス構築を担う「本体」のGooglebotは、HTML階層ページへの到達率が5%（35ページ）、JS階層ページへの到達率はわずか2%（7ページ）にとどまった。一方、レンダリング処理を専任的に担うとされるGoogleOtherは、HTML階層で66%（495ページ）、JS階層でも48%（142ページ）と、はるかに高い到達率を記録している。つまり「JavaScriptを実行できるクローラーがいるから安心」という単純な理解は誤りで、実際に検索結果・AI回答に反映されうるクロールを担う本体クローラー（Googlebot）自体の到達率も、HTML階層と比べて低い水準にとどまっているということだ。

第2段階：リカバリーテスト

実験は27日目の時点で、全セクションのJavaScriptリンクをHTMLへ変換する「是正」を行い、その後14日間（合計41日間）にわたって各クローラーの反応を追跡している。

• GPTBot: 是正後2日以内に250ページを新規発見。是正前はゼロだったことを踏まえると、HTML化した瞬間に急速にクロールが進んだことになる。
• Bingbot: 体系的なスウィープ（巡回的な再クロール）により212ページを追加発見。反応はGPTBotよりやや遅く、約1週間で本格的な再クロールに至った。
• ClaudeBot: 是正後も数百回のアクセスを継続していたにもかかわらず、新規ページの発見はゼロだった。アクセス頻度自体は高いが、それがそのままページ発見につながっていない点が特徴的だ。
• Amazonbot: 是正前の21日間の時点で、そもそもクロールを打ち切って離脱していた（是正が行われる前に対象サイトへの関心自体を失っていたとみられる）。
• Google: 実験期間中に「新規訪問予算」をすでに消費し尽くしていたとみられ、41日目の時点でも、conversion（コンバージョン）関連セクションにはGooglebotが1ページしか到達していなかった。

この結果から、著者は「修正すれば即座に全クローラーが追いついてくる」という単純な期待は禁物であり、クローラーごとに回復速度・回復パターンがまったく異なることを強調している。

著者の結論・推奨

記事は最後に、次の4点を実務上の推奨事項としてまとめている。

1. 監査: JavaScriptを無効化した状態で、実際にHTMLソース内にどんなナビゲーションが存在するかを確認する。
2. 認識を改める: JSレンダリングを実行するクローラーはむしろ例外的存在であり、Googlebot自身の到達率も2%と低い水準にとどまる。「Googleなら大丈夫」という前提を疑う必要がある。
3. 優先順位: サーバーサイドレンダリング（SSR）でリンクを実装する。コンテンツ本文よりも、まず「リンク（ナビゲーション構造）」をSSR化することを最優先にすべきだとしている。
4. 迅速な対応: 修正後の再クロール速度はクローラーによって大きく異なる。GPTBotは48時間、Bingbotは約1週間というスピード感の違いを踏まえた期待値設定が必要になる。

著者は記事の中で "With AI assistants becoming a real referral channel..., the question is now whether other crawlers can [see them]."（AIアシスタントが実際のリファラル経路になりつつある中で、問題は他のクローラーがそれらのページを見つけられるかどうかだ、という趣旨）とも述べており、AI検索・AIアシスタントからの流入がすでに現実の集客チャネルになりつつある前提の上で、この「見えない」問題を捉えるべきだと指摘している。

aiseo-llmo.com ユーザーへの影響

「うちはGoogleで表示されているから大丈夫」は通用しない

この実験結果が突きつける最も重要な事実は、Googleの検索順位やインデックス状況を見ているだけでは、AI検索・AIアシスタントからの到達可能性を判断できないということだ。GoogleがJavaScriptをレンダリングしてインデックスに反映しているページであっても、GPTBotやClaudeBot、Meta-ExternalAgent、Amazonbotといった主要なAIクローラーには、そのページの存在自体が伝わっていない可能性がある。

これは特に、LLMO（大規模言語モデル最適化）やGEO（生成エンジン最適化）に取り組むサイト運営者にとって死活的な問題だ。ChatGPT検索やClaude、その他のAIアシスタントが情報源として自社サイトを引用・参照するには、そもそもクローラーがそのページの存在をクロール・発見できていることが大前提になる。JavaScriptで構築されたナビゲーションの奥にあるページ、動的に生成されるカテゴリ一覧やタグ一覧、SPA（シングルページアプリケーション）のルーティングで表示される個別ページなどは、この実験結果に照らせば「AIクローラーからは実質的に存在しないページ」になっているおそれがある。

日本語サイトで特にリスクが高い業種・実装パターン

日本国内のWebサイトでは、以下のようなJavaScriptフレームワーク・実装パターンが広く採用されており、それぞれに固有のリスクがある。

• ECサイト: カテゴリナビゲーション、商品一覧のフィルタリング・絞り込みUI、無限スクロール型の商品一覧などをReactやVue.jsのクライアントサイドレンダリングで構築しているケースが多い。カテゴリページやタグページへの内部リンクがJavaScriptで動的に生成されている場合、AIクローラーはそのカテゴリ配下の商品ページ群にたどり着けない可能性がある。
• SaaS・BtoBサービスサイト: 機能紹介ページ、料金プラン別ページ、導入事例（ケーススタディ）一覧など、コンバージョンに直結するページ群がヘッダー・フッターのJavaScriptメガメニューの奥に配置されているケースが多い。AI検索経由での比較検討フェーズの流入を狙う上で、これらのページが発見されないことは機会損失に直結する。
• メディア・オウンドメディアサイト: タグページ、関連記事一覧、カテゴリアーカイブページなどが、JavaScriptによる「もっと見る」ボタンやページネーションの動的読み込みで実装されていることが多い。記事本文自体はSSR/SSGで配信されていても、記事間の内部リンク構造がJavaScriptに依存していれば、クローラーによる回遊・発見が阻害される。
• SPA（シングルページアプリケーション）で構築されたコーポレートサイト・ポータルサイト: React Router・Vue Routerなどのクライアントサイドルーティングを採用し、初期HTMLには<div id="root"></div>のような空の器しかないケースは最もリスクが高い。この場合、JavaScriptを実行しないクローラーからは、トップページ以外のすべてのページが実質的に見えないことになる。

なぜこの問題が起きるのか——AIクローラーのレンダリング能力の技術的背景

この問題の根本には、Webクローラーの技術的な設計思想の違いがある。伝統的なクローラーは、HTTPリクエストを送ってHTMLソースを取得し、そこに含まれる<a href="...">タグを解析してリンク先をキューに追加するという、比較的軽量な処理を行う。これに対して、JavaScriptを実行してレンダリング後のDOM（ブラウザが実際に描画する最終的なHTML構造）を取得するには、Headless Chrome相当のブラウザエンジンを動かし、ネットワークリクエスト・スクリプト実行・DOM構築・レイアウト計算といった一連の重い処理をクロール対象のページごとに行う必要がある。

Googleは長年にわたりこの「レンダリングを伴うクロール」に投資してきた経緯があり、Googlebotに加えて、レンダリング処理を専任的に担うプロセス（今回の実験でいうGoogleOther）を持つインフラを構築している。これは、検索エンジンとして長期間かけて構築してきたクロール基盤の成果であり、一朝一夕に他社が同等のものを用意できるものではない。

一方、GPTBot（OpenAI）、ClaudeBot（Anthropic）、Meta-ExternalAgent（Meta）、Amazonbotといった比較的新しいAIクローラーは、学習データ収集やAI回答生成のための情報収集を主目的としており、計算コストの高いレンダリング処理を大規模に行うインフラをまだ持たない、あるいは意図的にレンダリングを行わない設計を採用しているとみられる。膨大な数のWebページを継続的にクロールする際、レンダリングを都度実行することは処理コスト・時間コストの面で非常に重く、これがAIクローラーの多くが「静的HTMLの解析にとどまる」挙動につながっている一因と考えられる。

業種別インパクトの整理

今すぐできる対応策

1. JavaScript無効化での監査

まず着手すべきは、実際に自社サイトのHTMLソースに何が含まれているかを確認する監査だ。ブラウザの表示ではなく、クローラーが最初に受け取る「生のHTML」を見る必要がある。

Chrome DevToolsでの確認方法

1. Chromeでサイトを開き、F12またはCtrl+Shift+IでDevToolsを起動する。
2. Ctrl+Shift+Pでコマンドパレットを開き、「Disable JavaScript」と入力して実行する。
3. ページを再読み込みし、ナビゲーションメニューや内部リンクが表示されるかを確認する。表示されない、あるいは空白になる場合、そのリンクはJavaScriptに依存している。

curlでの確認方法

もっとも簡便な確認方法は、JavaScript実行環境を持たないcurlでページを取得し、内部リンクの有無を直接確認することだ。

curl -s https://example.com/category/example-category/ | grep -o 'href="[^"]*"' | sort -u

このコマンドで、対象ページのHTMLソースに含まれるhref属性を一覧表示できる。ブラウザで見えているナビゲーションリンクがここに含まれていなければ、それはJavaScriptで注入されたリンクであり、GPTBot・ClaudeBotなど多くのAIクローラーには見えていない可能性が高い。

さらに、view-source:をChromeのアドレスバーに付けてページを開く方法（例: view-source:https://example.com/）でも、レンダリング前の生HTMLを直接確認できる。

2. クローラーログの確認

自社サイトへの各クローラーのアクセス状況を、サーバーログやCDN/エッジのログから確認する。確認すべきポイントは以下の通りだ。

• User-Agentごとのアクセスパス一覧を集計し、GPTBot・ClaudeBot・Bingbot・Amazonbot・Meta-ExternalAgentなどが、カテゴリ配下の下層ページまで到達しているかを確認する
• HTMLハードコードされたセクションとJavaScript依存のセクションで、クローラーごとのアクセス数に明らかな差が出ていないかを比較する
• なりすましユーザーエージェント対策として、可能であれば逆引きDNSでクローラーの正当性を検証する

この種のログ分析を体系的に行う手順は、AIクローラー ログ解析完全ガイドで詳しく解説している。

3. SSR/SSG移行の優先順位付け

すべてのページを一度にサーバーサイドレンダリング（SSR）や静的サイト生成（SSG）に移行するのは現実的でないことが多い。今回の実験結果を踏まえると、優先順位は次のように整理できる。

1. 最優先: グローバルナビゲーション・カテゴリメニュー・パンくずリストなど、サイト全体の「リンク構造」を担う部分。著者が強調する通り、コンテンツ本文よりもナビゲーション（リンク）のSSR化が最優先事項だ。ここがJavaScript依存だと、そのメニューの先にあるページ群がまるごとクローラーから見えなくなる。
2. 次点: カテゴリ一覧・タグ一覧・検索結果一覧などの中間階層ページ。これらのページ自体がSSR化されていても、そこから先の下層ページへのリンクがJavaScript注入だと、同じ問題が再発する。
3. その次: 個別コンテンツページ本体のレンダリング方式。すでにSSR/SSGであることが多いが、ページ内の関連記事リンク・パジネーションなどが動的注入になっていないかも合わせて確認する。

Next.jsのようなフレームワークであれば、getServerSidePropsやgenerateStaticParamsなどを用いたSSR/SSGへの切り替え、あるいはNext.js App RouterのServer Componentsでリンクをレンダリングする設計に見直すことが具体的な対応策になる。

4. robots.txtとクローラー許可設定の見直し

SSR化と並行して、robots.txtで各AIクローラーのアクセスを不必要にブロックしていないかも確認したい。JavaScript依存が原因で発見できていないのか、そもそもrobots.txtでアクセス自体を拒否しているのかを切り分けることが重要だ。robots.txtの設定方針についてはAIクローラーのrobots.txt設定とAI検索引用戦略、Cloudflareを利用している場合の設定はCloudflare Content Signalsポリシーとrobots.txt設定ガイドを参照してほしい。

5. 修正後の再クロール速度を見越した期待値設定

今回の実験では、リンクをHTMLへ是正した後の反応速度がクローラーごとに大きく異なっていた。GPTBotは48時間以内に急速な再発見を見せた一方、Bingbotは約1週間、ClaudeBotに至っては是正後も新規ページを発見しなかった。修正を行った直後に「まだAI検索に表示されない」と焦る前に、クローラーごとに異なる回復パターンがあることを前提に、数週間単位でログをモニタリングし続ける運用体制を組んでおくことが望ましい。

よくある質問

Q1. GPTBotやClaudeBotはJavaScriptを一切実行できないのか

今回の実験結果では、GPTBot・ClaudeBotともにJS階層ページへの到達がゼロだった。

Search Engine Landの41日間実験に限って言えば、GPTBotとClaudeBotはJavaScriptで注入されたリンクを一件も辿らなかった。ただし、これは「JavaScriptエンジンをまったく持っていない」ことの証明ではなく、あくまで「今回の実験条件下では発見シグナルが確認されなかった」という観測結果である。クローラーの内部実装は公開されておらず、条件やページ構造によって挙動が変わる可能性もあるため、自社サイトについては個別にログで確認することが最も確実だ。

Q2. Googlebotなら安心してJavaScriptを使ってよいのか

Googlebot自身の到達率もJS階層でわずか2%（7ページ）にとどまり、安心はできない。

実験ではGoogleのクローラースタック全体（Googlebot＋GoogleOther）がJavaScriptを実行してリンクを辿った唯一の存在だったが、実際に検索インデックス構築を担うGooglebot本体の到達率は、HTML階層で5%、JS階層でわずか2%と低水準だった。レンダリング専任とみられるGoogleOtherの方が高い到達率（HTML階層66%、JS階層48%）を示しており、「Googleなら大丈夫」という単純な前提は成り立たない。

Q3. HTMLへの是正後、どれくらいで検索結果やAI回答に反映されるか

クローラーによって大きく異なり、GPTBotは48時間、Bingbotは約1週間が目安だが保証はない。

今回の実験ではGPTBotが是正後2日以内に250ページを新規発見した一方、Bingbotは体系的なスウィープに約1週間を要した。ClaudeBotに至っては是正後も新規ページの発見がゼロだったことから、クローラーやサイトの状況によって反映タイミングは大きく変動しうる。焦らず、複数週間にわたってクローラーログをモニタリングする運用を組むことが現実的だ。

Q4. SPA（シングルページアプリケーション）で構築されたサイトは全面的に作り直す必要があるか

ナビゲーション（リンク構造）を優先的にSSR/SSG化すれば、全面リビルドせずに改善できる可能性がある。

著者の推奨は「コンテンツ本文よりもリンクをSSR化することが最優先」というものだ。SPA全体をゼロから作り直すのではなく、まずグローバルナビゲーション・カテゴリメニュー・パンくずリストなど、サイト構造を担うリンク部分だけをサーバーサイドでレンダリングするように部分的に見直すことで、クローラーが下層ページへの経路を発見できるようになる可能性が高い。

Q5. どのように監査すればJavaScript依存のリンクを見つけられるか

ブラウザでJavaScriptを無効化した状態、またはcurlでHTMLソースを直接取得して、表示されているリンクが含まれているか確認する。

具体的には、Chrome DevToolsのコマンドパレットから「Disable JavaScript」を実行してページを再読み込みする方法、またはcurl -s [URL] | grep -o 'href="[^"]*"'のようなコマンドでHTMLソース中のhref属性を抽出する方法がある。ブラウザ上で見えているナビゲーションリンクが、これらの方法で確認したHTMLソースに含まれていなければ、そのリンクはJavaScriptに依存しており、多くのAIクローラーから見えていない可能性が高い。

Q6. AmazonbotがJS化されたセクションに全く到達しなかったのはなぜか

実験ではAmazonbotはJS階層への到達がゼロで、是正前の21日間の時点でクロール自体を打ち切っていたことも判明している。

これはAmazonbotがJavaScriptを実行できないこと自体に加えて、リンクが発見できない状態が続いたことで、そのサイト・セクションへのクロール優先度を下げた、あるいは打ち切った可能性を示唆している。クローラーは巡回リソースが有限であるため、発見できないページに割り当てる予算を早期に見切りをつける挙動を取りうる。これは「一度発見に失敗すると、放置するほど状況が悪化しうる」ことを示す重要な示唆でもある。

Q7. 日本語サイトでも同様の傾向が見られると考えてよいか

今回の実験対象はブラジルの事業ディレクトリサイトであり、日本語サイトを直接検証したものではないが、クローラーの実装はグローバル共通であるため、同様の傾向が生じる可能性は高いと考えられる。

GPTBot・ClaudeBot・Bingbot・Meta-ExternalAgent・Amazonbotといった主要AIクローラーは、言語やリージョンを問わず共通のクロールエンジンで稼働しているとみられ、JavaScriptレンダリング能力の有無というアーキテクチャ上の制約が、対象サイトの言語によって変わる理由は考えにくい。ただし、これは推測であり、日本語サイト固有のデータによる検証ではない点には留意してほしい。自社サイトについては、本記事で紹介した監査手順で個別に確認することを推奨する。

Q8. すべての内部リンクをHTMLにハードコードするだけで十分か

リンクの静的HTML化は必須の対応だが、robots.txtでのブロックやクロール予算の消費状況など、他の要因も併せて確認する必要がある。

今回の実験でも、HTMLへ是正した後でさえGoogleが「新規訪問予算」をすでに消費していたため、conversion関連セクションへの到達が41日目時点で1ページにとどまっていた例が示されている。リンクのHTML化はAI検索からの発見可能性を高める必要条件だが、robots.txtの設定、サイト全体のクロール優先度、サーバー応答速度なども合わせて点検し、総合的にクローラーがアクセスしやすい状態を作ることが求められる。

Q9. AIO（AI Overview）やAI検索での引用にもこの問題は影響するか

影響しうる。ページの存在自体がクローラーに発見されなければ、AI検索・AI Overviewでの引用対象にすらなり得ない。

AIO（AI Overview）やAI検索エンジンが回答を生成する際には、その情報源となるページが事前にクロール・インデックスされている必要がある。JavaScriptで隠れたページがクロールされていなければ、そのページの内容がどれほど優れていても、AI回答の引用元候補にすら入れない。今回の実験結果は、コンテンツの質以前の「発見可能性」というレイヤーの重要性を改めて示すものだ。

Q10. この問題への対応はSEOにも効果があるか、それともAI検索専用の対策か

AI検索専用ではなく、従来のSEOにも直結する対応である。

伝統的なGooglebotに限って言えば、レンダリング能力を持つため今回の実験でも到達自体はしているが、それでも到達率は低水準（HTML階層で5%）だった。JavaScriptに依存したリンク構造は、AI検索クローラーだけでなく、Google自身の効率的なクロールにとってもマイナス要因になりうる。SSR/SSG化やリンク構造の静的化は、AI検索対応と従来のSEO対応の両方に効く、共通基盤の改善策と位置づけるべきだ。

関連記事

• LLMO完全ガイド
• AIクローラー ログ解析完全ガイド
• AIクローラーのrobots.txt設定とAI検索引用戦略
• Cloudflare Content Signalsポリシーとrobots.txt設定ガイド
• Meta、独自AI検索エンジン構築か　クローラー急増で『脱Google』観測情報
• クローラーとは
• robots.txtとは
• GEO（生成エンジン最適化）とは
• LLMOとは