SPAのSEO対策：PrerenderingとSSRの技術的違い - Web開発における知見共有系ページ

SPA（Single Page Application）でサイトを公開すると、必ず出てくる話題があります。
「SEOのためにSSRにするべきか？」

結論としては、検索エンジン対策のためにSSRが必須とは限りません。必要なのは検索エンジンがHTMLを読めることであり、SSRはその手段の一つに過ぎません。
ここで登場するのがPrerendering（プリレンダリング）です。両者は似て見えますが、内部の仕組みと適した用途が大きく異なります。

検索エンジンのクローラは、基本的にHTMLを取得して内容を解析します。

GET /article/123 HTTP/1.1

ここで返されるHTMLに本文が含まれていれば、その内容がインデックスされます。
問題はSPAです。SPAの多くは次のようなHTMLを返します。

<div id="app"></div>
<script src="/main.js"></script>

記事の本文は含まれていません。本文はJavaScript実行後にDOMへ追加されます。
クローラがJavaScriptを実行しなければ、ページは「空」と判断されます。

SSRではサーバがJavaScriptを実行し、完成したHTMLを返します。

<article>
  <h1>記事タイトル</h1>
  <p>本文...</p>
</article>

この時点で本文が存在するため、検索エンジンは確実に内容を取得できます。
つまりSSRは「クローラの代わりにサーバがレンダリングしている」状態です。

PrerenderingはSSRと似ていますが、実行タイミングが異なります。

SSR
リクエストのたびにHTMLを生成

Prerendering
ビルド時にHTMLを生成

つまり、公開前にページを全部作っておきます。
結果としてクローラが受け取るのは同じ「完成HTML」です。

<!-- 既に生成済み -->
<article>...</article>

検索エンジンから見ると、SSRもPrerenderingも区別がつきません。

Prerenderingは「静的サイト生成」に近く、SSRは「動的生成」です。
SEOだけが目的なら、Prerenderingの方がシンプルです。

Prerenderingが向いているケース：

更新頻度が低く、公開後に内容が変わらないページです。
配信も高速で、サーバもほぼ不要になります。

SSRが必要なケース：

この場合、事前生成では追いつきません。

GoogleはJavaScriptを実行できるとされていますが、必ずしも即座に実行されるわけではありません。
クロールとレンダリングは別の処理です。

つまりインデックス登録まで遅延が発生する場合があります。
また、全ての検索エンジンが同等の実行能力を持つとは限りません。

そのため「JSでも問題ない」は条件付きです。

Prerenderingにもリスクがあります。
データの更新です。

これらが変わってもHTMLは更新されません。古い情報が検索結果に残る可能性があります。
更新時に再ビルドを忘れると、SEOどころか信頼性に影響します。

SSRとPrerenderingの違いはSEO性能ではありません。
データ更新と配信モデルの違いです。

SSR
「アクセス時にページを組み立てる」

Prerendering
「公開前にページを完成させる」

SEO観点ではどちらも有効です。
重要なのは、サイトが「リアルタイム情報を持つか」です。

検索エンジン対策として技術を選ぶより、サイトの性質に合わせて配信方法を選ぶ方が結果としてSEO considerationも安定します。
SSRはSEOのための技術ではなく、更新性のための技術です。SEOはその副作用に近いものです。