引用戦略の前に確認すべき GEO の条件
重要な事実が JavaScript の実行後にしか現れないなら、AI エージェントはその情報を受け取れない可能性があります。
該当するのは、製品の機能、比較ページの結論、価格条件、ドキュメントの回答、著者情報、そして AI に引用してほしい根拠です。人が Chrome で完成したページを見られることと、クローラー、本文抽出器、ブラウザ型エージェントが同じ内容を取得できることは別の話です。
ある SEO 実務者は、各ページテンプレートについて生の HTML とレンダリング後のページを比較しました。記事、チュートリアル、ショップ、コース、ランディングページ、カテゴリページの多くでは、見える内容の大半がすでに HTML に入っており、JavaScript の後に出る部分はわずかでした。重要なのはその比率そのものではありません。問うべきなのは、最初の HTML レスポンスに、エージェントに理解してほしい答えがすでにあるかです。
GEO では、これは引用以前の適格性チェックです。システムがページの主要な事実を取得できなければ、根拠を評価したり引用候補に選んだりする段階に進めません。
ページへの到達経路によって、JavaScript を使える範囲は異なります。生の取得と本文抽出は、通常 HTML レスポンスだけを頼りにします。
Google がレンダリングできても、すべてのエージェントが同じとは限らない
「Google は JavaScript をレンダリングできる」は正しい説明です。しかし、そこから「すべての AI 検索製品やエージェントが最終的なブラウザ画面を見る」と結論づけるのは危険です。
同じ URL でも、アクセス経路は複数あります。
| アクセス経路 | 取得するもの | JavaScript への依存 |
|---|---|---|
| 生の HTTP 取得 | 初期 HTML レスポンス | 実行しない |
| リーダー・本文抽出器 | HTML から選んだテキスト | 通常は実行しない |
| ブラウザ自動化 | レンダリング済み DOM | 実行する場合があるが、タイムアウトやポリシーに左右される |
| 検索インデックスの処理 | 取得後、キューで必要に応じてレンダリング | プラットフォームごとに異なる |
| ツール利用型エージェント | 利用中の Web 取得ツールの出力 | 生の取得に近いことが多い |
Google のレンダリング能力は強力ですが、他のシステムにも通用する保証ではありません。回答エンジン、企業内検索、ブラウジングエージェント、Web 抽出ツールは、HTML だけを取得したり、遅いクライアントデータの読み込み前に処理を終えたりすることがあります。特定プラットフォームの能力をサイト設計の前提にするのは、不要な賭けです。
安全な原則は明快です。発見や引用に関わる公開情報は、最初のレスポンスだけで読める状態にしておくべきです。
フレームワークではなく、事実が現れる層を監査する
SSR と CSR は GEO の成績表ではありません。React、Vue、Next.js でもエージェントに読みやすいサイトは作れます。一方で、従来のサーバーサイドレンダリングでも、重要な事実をクライアント API の呼び出し後に隠してしまうことがあります。
重要なブロックがどの層で利用可能になるかを監査してください。
| コンテンツの層 | 典型例 | GEO のリスク |
|---|---|---|
| 初期 HTML | タイトル、本文、仕様、FAQ、著者、日付 | 低い |
| サーバー取得後の HTML | 現在価格、地域別の提供状況 | 低から中 |
| クライアント API リクエスト | 製品の利点、比較表、ドキュメント本文 | 高い |
| ユーザー操作後 | タブ、アコーディオン、フィルタ、無限スクロールの結果 | 高い |
| ログイン後の表示 | ダッシュボード、非公開ナレッジベース | 公開引用は期待しない |
AI に公開回答で繰り返してほしい事実は、クリック、クライアントリクエストの成功、長い JavaScript タスクに依存させるべきではありません。操作性のための機能は残しても、説明に必要な情報は前に出します。
よくある失敗は、読み込み用の殻だけを返す製品ページ、hydration の後に比較表が出る比較ページ、クライアントルーティングで本文を読み込むドキュメント、無限スクロールだけに依存するカテゴリページ、結論が画像や Canvas にしかないビジュアルモジュールです。
完成画面が美しくても、最初の HTML レスポンスに意味のある情報がほとんど出ていない場合があります。
二つの表示状態を比較して確認する
「このサイトは React を使っているか」を問う必要はありません。同じ URL について、次の二つを保存してください。
- JavaScript を実行せずに取得した生の HTML。
- ブラウザでページを開き、主要コンテンツを待ってから取り出したレンダリング済みの
mainテキスト。
基本的な取得は、次のように始められます。
curl -sL "https://example.com/product" -o raw.html
比べる対象は、ヘッダー、Cookie バナー、フッターではなく、意味を持つブロックです。
- H1 と短い回答
- 最初の説明段落
- 製品情報と制約
- 比較表
- FAQ の回答
- 著者情報と更新日
- 内部リンクと canonical URL
ブラウザ側の完了条件を networkidle だけにしないでください。分析スクリプト、チャットウィジェット、長時間接続がページを永遠に「通信中」に見せることがあります。主要コンテンツのセレクタが現れること、または重要な事実を供給する特定データが完了することを待つ方が確実です。
この比較は、リリース指標にもできます。
主要コンテンツ露出率 = 生の HTML に存在する重要ブロック数 / ページに必要な重要ブロック数
目標は、あらゆるピクセルを HTML に入れることではありません。ページを理解するための根拠を、クライアント実行の成功に依存させないことです。
フロントエンド全体を作り直す前に、コンテンツの届け方を直す
多くのチームに全サイトの書き換えは必要ありません。安定した公開情報を最初のレスポンスに移し、フィルタ、保存設定、地図、アニメーション、パーソナライズには JavaScript を使い続ければよいのです。
| 状況 | より適した配信方法 |
|---|---|
| 安定した記事、チュートリアル、用語集ページ | 静的生成またはビルド時のプリレンダリング |
| 頻繁に変わる価格、在庫、地域情報 | キャッシュと明確な無効化を伴うサーバーレンダリング |
| 操作性は高いが説明は安定しているページ | 説明、事実、FAQ をサーバーで出力し、操作部分を hydration する |
| 大規模アプリ内の公開ドキュメント | 公開ルートをプリレンダリングし、主要な回答をログインに依存させない |
| 複数の内部 API に依存するページ | サーバーまたは BFF 層で重要データを集約し、HTML とアプリで共有する |
JSON-LD は役に立ちますが、読みやすい本文の代わりにはなりません。構造化データには、訪問者と抽出器がドキュメント内でも見つけられる事実を記述します。
GEO チームのための二週間の進め方
1-2 日目：自然流入、AI 引用、営業支援、サポートに影響するテンプレートを一覧にします。記事、製品ページ、ドキュメント、比較ページ、カテゴリページで十分なことが多いでしょう。
3-5 日目：テンプレートごとに URL を抽出し、生の HTML とレンダリング後の内容を保存します。H1、説明、製品情報、FAQ、内部リンクで欠けているものを記録します。
6-9 日目：価値が高く内容が安定しているページから修正します。定義、事実、比較結論、FAQ をサーバーまたはビルド出力へ移します。
10-14 日目：同じテストを繰り返し、リリースゲートを追加します。初期 HTML に H1、主要回答、重要な事実、canonical リンクがなければ、そのテンプレートは公開すべきではありません。
これはすべての AI 製品からの引用を保証するものではありません。しかし、潜在的なエージェントが公開情報を確実に読めないという、避けられる失敗を取り除きます。
Auspia の見解
GEO では、ブランド言及、情報源の質、エンティティの明確さ、回答構造から話を始めがちです。これらはすべて、システムがそもそもページを取得できたことを前提にしています。
JavaScript 自体が問題なのではありません。公開説明をクライアント実行時の副産物として扱うことが問題です。HTML にコンテンツの責任を持たせ、JavaScript には体験の責任を持たせる。この分担は、テスト、技術 SEO、エージェントの可読性にも良い影響を与えます。
FAQ
Google が JavaScript をレンダリングするなら、生の HTML を監査する必要はありますか？
あります。Google の能力が、他のクローラー、リーダーツール、エージェントの経路を保証するわけではありません。生の HTML を確認すると、レンダリングの遅延やクライアントリクエストの失敗も見つけやすくなります。
GEO では SSR が常に CSR より優れていますか？
いいえ。静的生成、サーバーレンダリング、プリレンダリングはいずれも機能します。高い操作性が必要な要素にはクライア���トレンダリングを残せます。判断基準は、公開ページの重要な事実が初期 HTML レスポンスで読めるかどうかです。
ページのすべてで JavaScript を避けるべきですか？
いいえ。フィルタ、アニメーション、地図、保存設定、パーソナライズ、ログイン後の体験には JavaScript を使えます。ページの主題を説明し、引用可能な事実を示すコンテンツを優先してください。
llms.txt は JavaScript の後にしか出ないコンテンツを解決しますか？
解決しません。あるシステムが llms.txt を読んだとしても、完全な本文やクライアント API のデータを自動で取得するわけではありません。公開ページ自体が主要コンテンツをアクセス可能にする必要があります。
情報源について
この記事は、Adrian Skowron による SSR と CSR の可視コンテンツを比較した投稿 をきっかけに作成しました。投稿の図表は著者自身のテンプレート計測であり、業界全体のベンチマークではありません。
著者：Julian Mercer、Auspia の 14 年のテクニカル SEO 実務者。Julian はクロール、レンダリング、構造化データ、検索と AI にコンテンツを理解させる技術基盤について執筆しています。
