自社の見え方を相談
技術実装

JavaScriptサイトのLLMO対策｜AIクローラーに本文を届ける設計

LLMO JavaScript対策ではSSR化を急ぐ前に、初期HTML、レンダリング後の本文、HTTP状態、リンク、robotsを順に検証し、AIクローラーが取得できる経路を整えます。

株式会社adding LLMO編集部#llmo#seo
この記事の目次を開く

LLMOのJavaScript対策では、SSR採用の有無より、公開URLへのアクセスだけで本文とリンクへ到達できるかを先に確かめます。初期HTML、JavaScript実行後のDOM、HTTPステータス、href、robots.txtの順に確認すれば、取得のどこで情報が途切れるかを切り分けられます。

ブラウザで文章が見えることは、人に表示できたという確認にすぎません。HTMLレスポンスが空に近く、API取得や操作後に本文が現れるなら、JavaScriptを実行しないクローラーには届きません。実行できる場合も、APIの失敗、認証、WAF、クロール拒否が取得を止めます。

ではSSRにすれば解決するのでしょうか。応答時のHTMLへ本文を含める設計は堅実です。ただしSSRでも、エラーを200で返す、リンクがクリック処理だけ、robots.txtで資源を止める、といった問題は残ります。採用方式より、配信経路の事実が判断材料になります。

LLMOでJavaScriptサイトを確認する5つの層

2026年8月8日に確認したGoogleのJavaScript SEO公式ガイドは、JavaScriptページの処理をクロール、レンダリング、インデックスの3段階で説明しています。Googlebotはrobots.txtを確認し、HTMLレスポンス中のリンクを抽出し、200のページをレンダリング待ちへ送り、レンダリング後のHTMLから本文とリンクを再び処理します。また、すべてのボットがJavaScriptを実行できるわけではないため、サーバー側レンダリングやプリレンダリングは有効だとしています。

この仕様から、実務の確認対象は次の5層に分けられます。

  1. URLへ制限なく到達できるか
  2. HTTPレスポンスがページの実態を表しているか
  3. 初期HTMLに何が含まれるか
  4. JavaScript実行後に本文とリンクが現れるか
  5. robots.txt、meta robots、CDNやWAFが取得を妨げていないか

一つでも欠ければ、完成画面とクローラーが得る情報は一致しません。応答時点で必要な情報があり、正しい状態コードと通常のリンクで配信できるサイトなら、全面的なSSR移行を前提にせず、途切れた層から修正できます。

1. 初期HTMLで本文の最低限を確保する

まずJavaScriptを実行せず、URLへのHTTPレスポンス本文を見ます。開発者ツールのElementsを使わず、NetworkでDocumentのResponseを確認するか、curlなどで取得します。ElementsはJavaScript実行後のDOMを表示するため、初期HTMLの検査には向きません。

受け取ったHTMLでは、少なくとも次を探します。

  • ページ固有のtitleと概要
  • 主題を示す見出し
  • 結論やサービス内容など、ページの中心となる本文
  • 関連する公開ページへのa hrefリンク
  • canonicalとrobots metaの意図した値

重複URLがある場合は、JavaScript実行前のHTMLへ正規URLを出すだけでなく、リダイレクト、サイトマップ、内部リンクも同じURLへそろえます。確認手順はAI検索のcanonical設計で整理しています。

ローディング表示と空のdivしかなければ、本文の取得はレンダリング能力に全面的に依存します。会員向け画面や操作中心のアプリなら合理的でも、検索やAI回答に届けたい記事、商品説明、会社情報まで同じ設計にする理由は薄いでしょう。重要な公開情報は静的生成、SSR、プリレンダリングなどで初期HTMLに含め、絞り込みや個別操作をクライアント側へ残す分担が現実的です。

全文を応答時点で返していなくても、GoogleはJavaScriptをレンダリングします。一方、ほかのボットまで同じ実行能力を持つとは限りません。実行に失敗しても主題が残る状態を基準にすると、クローラーごとの能力を推測せずに済み、仕様変更の影響も抑えやすくなります。

2. レンダリング後のDOMと失敗条件を見る

次は通常のブラウザとレンダリング検査で完成後のDOMを見ます。Google向けにはURL検査ツールやリッチリザルトテストでレンダリング後のHTMLを確認できます。公式ガイドも、レンダリング後のHTMLに見えないコンテンツはインデックスできないと明記しています。

目視に加え、次の条件を変えてください。

  • 未ログインの新しいセッション
  • Cookie、localStorage、キャッシュがない状態
  • API応答が遅い、または失敗した状態
  • JavaScriptやCSSのURLへ直接アクセスした状態
  • モバイル相当の画面とユーザーエージェント

普段のブラウザでだけ成功するなら、Cookieやキャッシュに助けられている可能性があります。本文APIの認証、地域制限、CORS、タイムアウトもNetworkとサーバーログで確認します。JavaScriptやAPIをWAFが拒否していれば、入口が開いていても本文は組み立てられません。

3. HTTPステータスを画面の意味と一致させる

JavaScriptのSPAでは、存在しないURLにも共通のアプリシェルを200 OKで返し、実行後に「見つかりません」と表示することがあります。人にはエラーだと分かっても、取得側には正常ページに見えます。Google公式ガイドは、このsoft 404を避ける方法として、サーバーが404を返すURLへのリダイレクト、またはエラーページへのnoindex追加を挙げています。

公開中の本文は200、恒久移転は適切なリダイレクト、存在しないページは404または410として、ヘッダーと最終到達先を記録します。画面の文言に頼らず、HTTP応答そのものが状態を伝える必要があります。CSRを維持しても、ルーティング層やエッジ側で状態コードは正せます。

4. リンクはa hrefとして発見可能にする

カードをクリックすると遷移できても、HTMLにhrefがなく、divのクリックイベントだけでURLを切り替えていることがあります。この実装では、人の操作とリンク発見が別物になります。

Google公式ガイドは、発見可能なリンクとしてhref属性を持つa要素を示し、SPAの画面遷移ではフラグメントだけに頼らずHistory APIを使うよう案内しています。JavaScriptでリンクをDOMへ追加すること自体は可能ですが、通常のURLを持つリンクとして完成する必要があります。

一覧、パンくず、本文内の関連リンクを、JavaScript無効時と実行後の両方で調べます。公開済みページ同士の経路なら、たとえばChatGPTで自社が出てこないときに確認する7項目のように、文脈のあるアンカーテキストと実URLを結びます。

サイトマップはURLの発見を補助します。ページ同士の関係を示す役割は本文やナビゲーションの内部リンクが担うため、両方を確認します。

5. robotsとアクセス制御を取得主体ごとに分ける

robots.txtは「AI全般」を一括で許可・拒否するスイッチではありません。2026年8月8日に確認したOpenAI公式クローラー仕様では、ChatGPTの検索結果にサイトを表示するためのOAI-SearchBotと、生成AI基盤モデルの学習に使われうるコンテンツを取得するGPTBotは独立した設定です。検索への表示を望む場合、OpenAIはOAI-SearchBotの許可と、公開IPレンジからのリクエスト許可を推奨しています。

ページ内でGoogle検索のスニペット利用範囲を制御する場合は、nosnippet、data-nosnippet、max-snippet、noindexの違いも確認し、robots.txtのクロール制御と混同しないようにします。

確認はrobots.txtの記述だけで終えません。

  • 対象ユーザーエージェントに意図しないDisallowがないか
  • ページの初期HTMLにnoindexがないか
  • JavaScript、CSS、本文APIの取得を拒否していないか
  • CDN、WAF、ボット対策が403や429を返していないか
  • サーバーログで対象URLへの応答が確認できるか

Googleはrobots.txtでブロックされたページやJavaScriptをレンダリングしないと説明しています。初期HTMLのnoindexをJavaScriptで後から消す方法も、レンダリング前に処理を止められる可能性があり安全ではありません。許可の宣言と実際の応答を対にして確認します。

OpenAIの仕様では、robots.txt変更の反映に検索結果側で約24時間かかる場合があります。これは掲載までの期限でも、引用の約束でもありません。変更日時、確認したユーザーエージェント、応答コード、ログの有無を残し、後日の再検証条件として扱います。

修正前後の検証記録

代表URLを選び、同じ表で修正前後を比較します。記事詳細、一覧、存在しないURL、リダイレクト元も含めます。

確認項目記録する事実
初期応答最終URL、HTTPステータス、リダイレクト履歴
初期HTMLtitle、見出し、中心本文、リンク、robots metaの有無
描画後本文とリンクの有無、コンソール・通信エラー
制御robots.txtの該当ルール、CDN・WAFの応答
発見経路一覧・本文からのa href、サイトマップ掲載
実アクセス日時、ユーザーエージェント、URL、応答コード

この記録により、「CSRだから出ない」という推測を、どの段階で情報が失われたかという事実へ置き換えられます。HTMLレスポンス、資源やAPI、ルーティングのうち、原因がある範囲を修正します。

結論：取得経路を最後まで通す

JavaScriptサイトのLLMO対策は、初期HTMLだけ、あるいはレンダリング後の画面だけを見ても完了しません。公開URLへ到達でき、実態に合うHTTP状態が返り、初期HTMLから主題を把握でき、実行後にも本文とa hrefリンクが残り、robotsとアクセス制御がそれを妨げていない。この一連の条件を満たすことが結論です。

SSRや静的生成は本文を早く渡す手段です。5層を同じURLで測り、途切れた層を直せば、全面移行を避けながら本文を届けられます。

技術的に取得可能でも、AI回答での引用、検索順位、流入は保証されません。cotomuの公開LPでは、LLMO/AIO診断10万円、実装支援30万円から、技術顧問・伴走は月15万円からが目安です。支援範囲は取得障害の診断、実装、継続観測であり、AIの回答そのものは制御できません。

参考にした一次情報

RELATED NOTES / 関連記事

技術実装AI検索の引用を制御するnosnippet｜設定前に確認する影響範囲技術実装AI検索で重複URLを減らすcanonical設計｜LLMOの技術チェック