AIのクローラビリティにおけるSSR vs CSR ― 切り替えでAI引用が2倍に増加したデータ公開

クローラインフラの構築経験から、なぜこうなるのか説明します。

各種クローラーのJavaScript対応:

AIボットがJSを飛ばす理由:

1. スケール ― 数十億ページのレンダリングはコスト高
2. 速度 ― JSは遅延要因
3. 信頼性 ― JSは壊れたりタイムアウトする
4. シンプルさ ― HTML優先が簡単

実務上の意味:

JavaScript必須のコンテンツはAIのトレーニングデータに含まれない可能性大。モデル上「存在しない」ことに。

SSRが完全解決します。

HTMLレスポンス＝確実なアクセシビリティ。

静的サイト生成（SSG）はAI可視性でさらに優れています。

SSGが勝る理由:

• 100% HTMLコンテンツ
• SSR不要
• 超高速ロード
• 完全なキャッシュ性
• クローラーへの最大のアクセシビリティ

当社の事例:

• マーケティングサイトはHugo（5,000ページ）
• デプロイ時に事前ビルド
• CDNでグローバル配信

AIクローラビリティ：100%

どのページも純HTML。全AIボットが全てにアクセス可。

トレードオフ:

SSGはリクエスト毎に変わらないコンテンツ向き。動的（ユーザーごと・パーソナライズ）はSSRやハイブリッドが必要。

推奨構成:

• マーケティング → SSG
• ブログ/ドキュメント → SSG
• EC → SSR
• アプリ → ハイブリッド（重要はSSR、操作はCSR）

用途ごとに最適な手法を選んでください。

パフォーマンス観点から見たSSRとAI：

コアウェブバイタル（CWV）の改善:

SSRは通常、以下を改善します：

• LCP（Largest Contentful Paint）― 表示速度向上
• FID/INP ― JSがメインスレッドを妨げにくい
• CLS ― レイアウト安定

AIにとってなぜ重要か:

1. GoogleはCWVを順位要因とする
2. UX信号が強い＝権威性向上
3. 高速ページ＝クローラー体験向上

当社顧客データ:

AI可視性との相関:

CWVが良いサイトはAI引用も多い傾向。同じ品質信号・クロール体験・サイト権威性が理由と考えます。

SSRはパフォーマンスもAI対応も両立できる選択です。

大規模サイトのレンダリングアーキテクチャについて：

複雑性:

大規模サイトは用途ごとに異なる要件を持ちます：

• マーケティングページ（情報重視）
• 商品カタログ（動的データ）
• ユーザーアカウント（パーソナライズ）
• ドキュメント（リファレンス）

当社のハイブリッド戦略:

ページ種別            → レンダリング手法
マーケティング         → SSG（ビルド時）
ブログ/ドキュメント   → ISR（インクリメンタル静的）
商品ページ            → SSR（動的データ）
ダッシュボード        → CSR（認証済み）

Next.jsでの実装例:

// マーケティング - getStaticProps (SSG)
// 商品 - getServerSideProps (SSR)
// ダッシュボード - クライアントサイド専用

各セクションのAI可視性:

重要なポイント:

コンテンツの目的ごとに手法を合わせること。全てSSRにしなくていいが、重要なコンテンツは必要。

AI向けレンダリングの監査方法：

簡易テスト:

1. ブラウザでJavaScriptを無効化
2. ページを開く
3. コンテンツが見えるか？

見えなければ→AIボットも見えない可能性大。

技術的監査:

curl -A "custom-bot" https://yoursite.com/page | grep "your content"

レスポンスにコンテンツがなければ→問題あり。

利用ツール:

• Chrome DevTools → JS無効化
• Google Search Console → URL検査
• Screaming Frog → JavaScriptレンダリングモード
• Am I Cited → AI可視性の確認

よくあるパターン:

CSRサイトは多くの場合、

• Google順位は良好（JSレンダリング対応）
• Bing順位は不安定（JS対応に差）
• AI引用は少ない（ボットがJS非対応）

Google順位とAI可視性が一致しないなら、レンダリングが原因かもしれません。

AI対応レンダリングのためのフレームワーク推奨：

SSR向きの最良フレームワーク:

静的サイト向け:

移行推奨パス:

React SPA → Next.js（最も簡単な移行） Vue SPA → Nuxt（最も簡単な移行） ゼロから構築 → Astro（最も柔軟） コンテンツ重視 → Hugoまたは11ty（最速ビルド）

よくある間違い:

プリレンダリングを後付で追加しないこと。設計段階からSSR前提でコンテンツ設計を。

素晴らしい議論ですね。まとめます：

レンダリング戦略の意思決定フレームワーク:

AI可視性には、JavaScript不要でHTMLで見えるコンテンツが必須です。

AIアクセシビリティ順の選択肢:

1. SSG（静的サイト生成） ― 最良。全てビルドタイムHTML。
2. SSR（サーバーサイドレンダリング） ― 優秀。リクエスト毎にHTML生成。
3. ISR（インクリメンタル静的再生成） ― 良好。ハイブリッド手法。
4. ダイナミックレンダリング ― 良い。ボットはSSR、ユーザーはCSR。
5. CSR＋プリレンダリング ― 可。設定次第。
6. 純粋CSR ― 不可。多くのAIボットが見えない。

移行優先順位:

1. コンテンツページ（ブログ、ドキュメント、マーケ）― 最優先
2. 商品・サービスページ ― 高
3. カテゴリ・リストページ ― 中
4. ユーザー専用ページ ― N/A（AI対象外）

技術チェックリスト:

• JS無効でもコンテンツ表示
• curlレスポンスにコンテンツ含む
• クローラーで全文確認
• Am I CitedでAI可視性検証
• ハイドレーション不一致なし

2倍の改善は唯一の変更点から: HTMLレスポンスでコンテンツを見せるようにしただけ。

良質なコンテンツでもAI引用が少なければ、レンダリングを見直してみてください。

皆さん、技術的な洞察をありがとうございました！