サーバーサイドレンダリングとは? | SEO用語集

サーバーサイドレンダリング(SSR)とは、リクエスト時にサーバー上でページのHTMLを完全に組み立て、完成したドキュメントとしてブラウザに送信するレンダリング戦略です。最初のレスポンスにすでにテキスト、リンク、メタタグが含まれているため、JavaScriptが実行される前からページが意味を持ちます。

なぜ重要なのか

検索エンジンとAIクローラーは、JavaScriptの実行に実際のリソースを費やします。Googlebotは2段階のモデルを使用し、最初にHTMLを解析し、その後に遅延されたJSレンダリングパスを実行します。空のクライアントレンダリングのシェルを配信すると、インデックス登録が遅れたり、完全にスキップされたりすることがあります。GPTBot、PerplexityBot、ClaudeBotのようなAIクローラーは、ほとんどの場合JSを一切実行しないため、CSRは回答エンジンにとって実質的に不可視となります。SSRはこの問題を一手で解決すると同時に、Core Web Vitalsも改善します。SSRはSEOおよびGEOにとって最も効果の高い技術的判断の1つです。

CSR vs SSR vs SSG vs ISR

戦略	レンダリング場所	最初のHTML	SEO適合性	ユースケース
CSR (クライアントサイドレンダリング)	ブラウザ	空のシェル	弱い	ログイン済みダッシュボード
SSR (サーバーサイドレンダリング)	サーバー、リクエストごと	完成済み	強い	動的・パーソナライズされたコンテンツ
SSG (静的サイト生成)	ビルド時	完成済み	最も強い	ブログ、ドキュメント、マーケティング
ISR (増分静的再生成)	ビルド + 定期的な再生成	完成済み	最も強い	頻繁に更新される静的ページ

SEOの優先順位はおおむね SSG ≈ ISR > SSR > CSR です。Next.js、Nuxt、Remix、SvelteKitのようなフレームワークでは、単一のコードベース内でこれらのモードを組み合わせることができます。

SEOとGEOへの影響

即時のインデックス登録: コンテンツはGooglebotの最初のパスで表示されるため、遅延レンダリングパスを待つ必要がありません。新規ページのインデックス登録が数日から数時間に短縮されます。

AIクローラーとの互換性: GPTBotなどはJSを実行しません。SSRがなければ、あなたのコンテンツはLLMの学習や検索にとって実質的に存在しないことになります。

Core Web Vitalsの改善: LCPは、JSバンドルがダウンロードされて実行された後ではなく、最初のHTMLが到着したときに発火します。FCP、LCP、TTIのすべてが改善されます。

信頼できるメタタグ: Open Graph、検索スニペット、構造化データは、信頼されるために最初のレスポンスに含まれている必要があります。CSRは、Twitter、Facebook、その他のソーシャルボットに空のメタタグを送信してしまいます。

プログレッシブエンハンスメント: JSが無効でも、低速ネットワークでも、古いデバイスでも、コンテンツにアクセスできます。

SSRのトレードオフ

サーバーコストの増加: リクエストごとのHTML生成はCPU、メモリ、インフラを消費します。CDNキャッシュとISRで軽減できます。

TTFBが増加する可能性: 重いサーバーロジックは最初のバイトまでの時間を遅延させます。DBクエリと外部APIがボトルネックになります。

複雑さ: ハイドレーションの不一致、サーバー/クライアント環境の差異、キャッシュの無効化は、すべてデバッグコストを増加させます。

パーソナライズの制限: ユーザーごとのSSRはキャッシュが難しいです。パターンとしては共有シェル + クライアントサイドのパーソナライズです。

ハイドレーションとその落とし穴

SSRがHTMLを配信した後、クライアントはJavaScriptを再アタッチしてインタラクティブにするために「ハイドレーション」を行います。うまくいかない点は次のとおりです。

ハイドレーションの不一致: サーバーレンダリングされたHTMLとクライアントの最初のレンダリングが食い違うと、React/Vueが警告を発し、目に見えるちらつきや動作不良を引き起こすことがよくあります。

ハイドレーションのコスト: 大きなページをハイドレーションするとメインスレッドがブロックされ、INPが悪化します。部分的ハイドレーション、React Server Components、Astroのislandsが代替手段です。

SSR ≠ バンドルの縮小: SSRはクライアントバンドルを小さくしません。どちらも最適化が必要です。

SSRを使うべき場合

コンテンツがSEO/GEOトラフィックに依存している場合(ブログ、ニュース、Eコマース、ドキュメント)
ユーザー固有のデータが最初の描画に含まれている必要がある場合(パーソナライズされたダッシュボード)
ソーシャル共有のために動的なOGタグが重要な場合
AI検索での引用を狙っている場合

SSRが過剰な場合

認証済みダッシュボード(SEOの懸念なし)
静的コンテンツ。SSGの方が高速で低コスト
小規模サイト。単一の静的HTMLファイルで十分

よくある間違い

すべてをSSRにする: 静的コンテンツはSSG/ISRの方が高速で低コストです。ルートごとに適切なモードを選びましょう。

キャッシュなしでAPIを叩く: キャッシュなしのリクエストごとのデータ取得はTTFBを急増させます。SWRやキャッシュヘッダーを使いましょう。

ハイドレーションの不一致を無視する: コンソールの警告は、Googleが見たHTMLがユーザーのHTMLと異なることを示しており、SEOリスクとなります。

メタタグをクライアントだけで設定する: ボットが読めるように、メタタグはSSRレスポンスのheadに存在する必要があります。

フレームワークのデフォルトを信頼する: Next.jsやNuxtが常に適切なモードを自動で選ぶとは限りません。ルートごとに明示的に設定しましょう。

Sources: