SSR・CSR・SSGとは？SEOへの影響と最適な選び方【2026年版】

レンダリング方式とは何か

レンダリングとは、サーバーから受け取ったデータをブラウザで表示可能なHTMLに変換する処理を指します。この処理を「いつ・どこで」行うかによって、SSR・CSR・SSGの3方式に分類されます。

3方式の違いを一言で表すと以下の通りです。

• SSR（Server-Side Rendering）：ユーザーがアクセスするたびに、サーバーでHTMLを生成して返す
• CSR（Client-Side Rendering）：最小限のHTMLだけ送り、ブラウザ側でJavaScriptがHTMLを組み立てる
• SSG（Static Site Generation）：ビルド時に全ページのHTMLを事前生成し、ファイルとして配信する

3方式は対立する技術ではなく、同じサイト内でページごとに使い分けることが現代の標準的な設計です。本記事の後半では、SEGOや大手サイトがどのように使い分けているかを具体的に紹介します。

SSR（Server-Side Rendering）の特徴

SSRは、ユーザーがページにアクセスするたびに、サーバー側でHTMLを生成してブラウザに返す方式です。

最大の特徴は「常に最新のデータを反映できる」点です。データベースから取得した情報をその場でHTMLに埋め込んで返すため、在庫数・価格・ログイン状態など、リアルタイム性が必要な情報を表示するのに適しています。

SSRのメリットとデメリット

メリット	デメリット
最新データを常に反映	サーバーの計算負荷が高い
SEOに有利（クローラーがHTMLを直接読める）	アクセス集中時のスケーリングが課題
ユーザー固有の情報を表示できる	初回表示が SSG より遅い

SSR採用ケース：Amazon・楽天・Wikipedia

Amazon・楽天のような大規模ECサイトはSSRの代表例です。在庫数・価格・配送日時はリアルタイムで変動するため、ビルド時に固定したHTMLでは対応できません。ユーザーごとに「閲覧履歴」「おすすめ商品」も動的に変わるため、サーバー側でその都度HTML生成する必要があります。

WikipediaもSSRを採用しています。数千万ページの巨大サイトでも、強力なキャッシュ機構（Varnish）と組み合わせることでSSRが運用可能であることを示す好例です。「巨大サイトはSSGできない」と思われがちですが、実際にはキャッシュ戦略次第でSSRも高速に動きます。

SEGOでのSSR実装例

SEGO（本サイト）では、診断結果ページ（/r/[id]）にSSRを採用しています。診断のたびに異なる結果を表示する必要があるため、SSRが最適な選択肢です。

// app/r/[id]/page.tsx の概念図（実装イメージ）
export default async function ResultPage({ params }) {
  const { id } = await params;
  // Supabaseから診断結果を取得
  const result = await fetchScanResult(id);
  // データを埋め込んだHTMLをサーバーで生成
  return <ResultView data={result} />;
}

診断データはSupabaseに保存されており、ユーザーがURLを開いたタイミングでデータベースから取得→HTML生成→ブラウザに返却、という流れで動いています。

CSR（Client-Side Rendering）の特徴

CSRは、サーバーから最小限のHTMLとJavaScriptファイルだけを受け取り、ブラウザ側でHTMLを構築する方式です。

初回アクセス時のHTMLは「空の枠」のような状態で、ブラウザがJavaScriptをダウンロード・実行してから、画面が表示されます。一度表示された後はページ遷移が高速になるため、Webアプリケーションの設計でよく採用されます。

CSRのメリットとデメリット

メリット	デメリット
ページ遷移が高速（SPA体験）	SEOに不利（クローラーがHTMLを読みにくい）
サーバー負荷が低い	初回表示が遅い（JS読み込みまで真っ白）
リッチなUIを実現しやすい	JavaScript無効環境では動作しない

CSR採用ケース：Notion・Figma管理画面

Notion・FigmaのようなSEOが不要なWebアプリケーションは、CSRの典型例です。ユーザーがログインして使うツールであり、検索エンジンに公開する前提のページではないため、CSRで問題ありません。

むしろ、リッチな編集機能・リアルタイム同期・複雑なドラッグ操作などを実現するには、CSRの「ブラウザ内で動的にUIを書き換える」特性が向いています。

SaaSの管理画面・ダッシュボード・チャットアプリなど、「ログイン後の機能性重視のページ」は、ほぼすべてCSRで実装されています。

CSRとSEOの注意点

CSRをSEO対策が必要なページに採用するのは避けましょう。Googlebotは現在JavaScriptを実行できますが、Google公式のJavaScript SEOドキュメントでも「レンダリングの遅延が発生する」「全てのSEOシグナルが取得できない可能性がある」と明記されています。

特にAI検索エンジン（ChatGPT・Perplexity）のクローラーはJavaScript実行能力が限定的なため、LLMO対策を意識する場合はSSRまたはSSGを優先してください。

SSG（Static Site Generation）の特徴

SSGは、サイトをビルド（公開前の事前生成プロセス）するタイミングで全ページのHTMLを生成し、ファイルとしてサーバーに配置する方式です。

ユーザーがアクセスした時点では、すでに完成したHTMLが用意されているため、サーバーは「ファイルを返すだけ」で済みます。表示速度・SEO評価・サーバーコストの全ての面で最強のパフォーマンスを発揮します。

SSGのメリットとデメリット

メリット	デメリット
表示が最速（CDN配信で数十ms）	ビルド時点のデータで固定される
SEOに最強（HTMLが完成形で配信）	ページ数が多いとビルド時間が長い
サーバーコストが最低	ユーザー固有の情報は表示できない
セキュリティリスクが低い	更新時はビルド再実行が必要

SSG採用ケース：Vercel・Stripe・Zenn

Vercel・Stripeのような開発者向けSaaSのマーケティングサイトはSSGの代表例です。コンテンツの更新頻度が低く、ページ数も限られているため、SSGとの相性が抜群です。

Zenn・Qiitaのような技術記事プラットフォームは、記事ページにSSGを採用しつつ、検索機能やマイページにはCSRを採用する「ハイブリッド方式」の代表例です。記事は公開後ほぼ更新されないためSSGが最適、検索や設定画面は動的にしたいためCSR、という綺麗な使い分けです。

SEGOでのSSG実装例

SEGOでは、ブログ記事ページ（/blog/[slug]）にSSGを採用しています。

// app/blog/[slug]/page.tsx
import { getAllPosts } from "@/lib/blog/posts";

// ビルド時に全記事のslugを取得して、HTMLを事前生成
export async function generateStaticParams() {
  return getAllPosts().map((p) => ({ slug: p.slug }));
}

generateStaticParams関数は、Next.jsがビルド時に「どのページを事前生成するか」を判断するためのものです。SEGOでは現在17記事を運用していますが、ビルド時に17ページ分のHTMLが生成され、CDNに配置されます。

結果として、ブログ記事のページ表示速度は数十ms（ミリ秒）で完了し、Core Web Vitalsの全指標で高得点を獲得しています。

現代の主流：ハイブリッド方式

2026年現在、本格的なWebサービスでは1サイトの中で複数のレンダリング方式を使い分ける「ハイブリッド方式」が標準的な設計になっています。

ハイブリッド方式の判断基準はシンプルです。「SEOが必要 + データが固定」ならSSG、「SEOが必要 + データが動的」ならSSR、「SEO不要 + 操作性重視」ならCSR、というロジックでページごとに選択します。

SEGOも実際にこのハイブリッド方式で構築されています。トップページ・ブログ記事はSSG、診断結果ページ（/r/[id]）はSSR、診断フォーム自体はクライアントコンポーネントで実装、という3方式の使い分けで、各ページに最適なパフォーマンスを実現しています。

SEOへの具体的な影響

レンダリング方式は、SEOの3つの主要指標に直接的な影響を与えます。

① クローラーのHTML読み取り速度

Googlebotは1日に数十億ページをクロールする必要があるため、JavaScript実行が必要なCSRページは「2段階処理」で評価されます。最初のクロールではHTMLしか読まず、レンダリング処理は後回しにキューイングされます。この遅延は数日〜数週間に及ぶこともあります。

SSR/SSGなら最初のクロールで完成形HTMLが取得できるため、インデックス速度が大幅に改善されます。

② Core Web Vitals（特にLCP）

Core Web Vitalsの中でもLCP（Largest Contentful Paint）はレンダリング方式に強く依存します。

• SSG：CDN配信で200-500ms程度
• SSR：サーバー処理込みで500-1500ms程度
• CSR：JS実行込みで1500-3000ms程度

LCPはランキング要因に直接組み込まれているため、SEOを最優先するページではSSGまたはSSRを選択するのが基本です。

③ AI検索エンジンへの対応

GPTBot・ClaudeBot・PerplexityBotといったAI検索クローラーは、Googlebotに比べてJavaScript実行能力が限定的です。CSRのみで構築されたサイトは、AI検索結果での引用機会を大きく失います。

SEGOで715サイトを診断したデータでは、CSRベースのSPAサイトはAI検索可視性スコアが平均で30%以上低い傾向が確認されました。AI検索時代のSEO戦略では、SSR/SSGの選択が必須条件となっています。

レンダリング方式の選び方

新規プロジェクトや既存サイトのリファクタリングで、どの方式を選ぶかの判断基準を整理します。

多くの中小企業向けサイトでは、「コーポレートサイトとブログはSSG、問い合わせフォームの送信処理だけサーバー側で動的処理」というシンプルな構成で十分です。EC機能や会員制機能を持つサイトでのみ、SSRやCSRの併用を検討すれば良いでしょう。

制作会社に依頼する際は、「ページごとに最適なレンダリング方式を選定してほしい」と伝え、全ページCSR（SPA構成）の提案には注意してください。SEOで損をする可能性が高いです。

レンダリング方式の選び方まとめ

レンダリング方式の選択は、サイトのSEOパフォーマンス・ユーザー体験・運用コストの全てに影響する重要な技術判断です。本記事のポイントを整理します。

• SSR：毎回サーバー生成。最新データ反映・SEO有利・サーバー負荷高い
• CSR：ブラウザ生成。SPA体験・SEO不利・SaaS管理画面向け
• SSG：ビルド時生成。最速・SEO最強・更新時に再ビルド必要
• 2026年の標準はハイブリッド方式（ページごとに使い分け）
• SEO重視ページは必ずSSGまたはSSRを選択
• AI検索クローラーはJS実行が限定的なため、CSRのみのサイトは大きく不利
• 選定基準は「SEO要否」「データ更新頻度」の2軸で決める

SEGO自身も、ブログ記事はSSG、診断結果はSSR、フォーム入力はクライアントコンポーネント、というハイブリッド構成で運用しています。「自社サイトはどの方式か」を制作会社に確認し、SEO観点で適切な構成になっているかを定期的に見直すことを推奨します。

SEGOでは、レンダリング方式に依存するパフォーマンス指標（LCP・CLS・INP）を含む50項目以上のSEO・AI検索対応状況を、URLを入力するだけで無料診断できます。

SEGOで無料診断を試す

SSR・CSR・SSGに関するよくある質問

WordPressはどのレンダリング方式ですか？

標準のWordPressはSSRに分類されます。アクセスのたびにPHPがデータベースから情報を取得してHTMLを生成します。ただし、WP RocketなどのキャッシュプラグインやWP Engine等のホスティングサービスを使うと、実質的にSSGに近い挙動になります。

Next.jsとReactはどう違うのですか？

ReactはCSR向けに作られたUIライブラリで、Next.jsはReactをベースにSSR・SSG・CSRの全方式に対応するフレームワークです。素のReactのみで作るとCSRになりますが、Next.jsを使えば同じReactコンポーネントでSSGやSSRも実装できます。

既存のCSRサイトをSSR/SSGに移行する難易度は？

フレームワーク次第です。React製のSPAをNext.jsに移行する場合、コンポーネントは流用できますが、データ取得ロジックの書き換えが必要です。一般的に、中規模サイト（20-50ページ）で1〜3ヶ月の工数が目安です。

静的サイトジェネレーターは何を選べばよいですか？

2026年現在、Next.js（React）・Astro・Hugo・Gatsbyが主要選択肢です。Next.jsは最もエコシステムが大きく、SSG/SSR/CSRをハイブリッドで使える柔軟性が魅力です。AstroはSSGに特化していて、不要なJSを削減する設計が優秀です。HugoはGo言語製でビルドが圧倒的に高速、コンテンツ重視のサイト向きです。

SSRとSSGのどちらかしか選べない場合は？

更新頻度が「日次以上」の場合はSSR、「週次以下」の場合はSSGを選んでください。Next.jsの場合はrevalidateオプションで「SSGだけど指定時間ごとに再生成」も可能で、両者の中間的な運用ができます。コンテンツ系サイトではこの方式が現代的な選択肢です。