III-D2 SSR・SSGで対応する

前のレッスンで、AIクローラーはJavaScriptを実行しないため、クライアントサイドレンダリングに依存したページが「空白」に見えてしまうリスクを確認しました。対応策としてよく名前が挙がるのがSSR(サーバーサイドレンダリング)とSSG(静的サイト生成)の2つですが、実際に手を動かすのは技術担当や制作会社です。マーケティング側に必要なのは、この2つの違いを技術担当へ自分の言葉で説明できる理解です。

そもそもCSR・SSR・SSGは何が違うのか

整理すべきは3つの言葉です。CSR(クライアントサイドレンダリング)は、ブラウザがJavaScriptを実行してはじめて画面のHTMLが組み立つ方式で、React・Vue等のSPA(シングルページアプリケーション)でよく使われます。これがIII-D1で扱った「AIには空白に見える」原因でした。SSR(サーバーサイドレンダリング)は、ユーザーやボットがアクセスするたびにサーバー側で都度HTMLを組み立てて返す方式で、最初のレスポンスの時点で文字としてコンテンツが存在します。SSG(静的サイト生成)は、事前(ビルド時)に全ページ分のHTMLファイルをあらかじめ作っておき、アクセスがあったらそのまま返す方式です。どちらも「AIクローラーが訪れた瞬間に、文字として読めるHTMLが用意されている」という点でCSR単体とは決定的に違います。

どちらを選ぶかの判断軸

選択の軸は主に更新頻度です。料金・会社概要・サービス紹介など更新頻度が低いページはSSGと相性が良く、表示速度も速くなりやすいという利点があります。一方、在庫連動の商品ページやログイン後の会員専用コンテンツなど、アクセスごとに内容が変わるページはSSRが向いています。既存のSPAサイトを丸ごと作り直す余力がない場合の折衷案として、AIクローラー等のボットにだけ事前レンダリング済みのHTMLを返す「動的レンダリング(dynamic rendering)」という手法も選択肢になります。いずれも一長一短があるため、自社の更新頻度と開発リソースに応じて技術担当と相談するのが現実的な進め方です。

技術担当への伝え方

マーケティング側が実装するわけではないからこそ、伝え方が重要になります。「JSでフロント実装しているページの重要コンテンツ(料金・FAQ・事例)が、AIクローラーには読めていない可能性がある。SSR・SSG・prerenderingのいずれかで、初期HTMLの時点で文字として存在する状態にできないか」という課題ベースの伝え方をすると、技術担当も対応方針を検討しやすくなります。いきなり「SSGに全部書き換えて」と手段を指定するより、まずIII-D1で作った「JS依存が疑われるページ一覧」を渡すところから始めるとスムーズです。

移行時に確認しておきたいこと

SSR・SSGへの移行や動的レンダリングの導入後は、見た目上の表示だけでなく、AIクローラーが見るであろう初期HTMLの中身まで確認することが欠かせません。移行が中途半端だと、一部のコンポーネントだけJS依存のまま残ってしまうことがあります。III-D1で紹介したソース確認・curlでの確認手順を、対応後にもう一度実行して初めて「対応が完了した」と言える、という認識を持っておきましょう。

実践ステップ

1. 1
   III-D1で作成したJS依存ページ一覧を、更新頻度(高/低)で仕分ける
2. 2
   更新頻度が低いページ(料金・会社概要等)から、SSG化の相談を技術担当に持ちかける
3. 3
   更新頻度が高いページ(在庫・会員専用等)は、SSRまたは動的レンダリングの検討を依頼する
4. 4
   全面的な作り直しが難しい場合、ボット向けの動的レンダリングだけ先行導入できないか確認する
5. 5
   対応後は、III-D1のソース確認・curl確認の手順で、文字として読める状態になったか再チェックする
6. 6
   対応の優先順位と進捗を、料金・FAQ・事例の順で一覧管理しておく

このレッスンはテキストとスライドで学べます。スライドは上のビューアからご覧ください。