ダイナミックレンダリング
ダイナミックレンダリングとは、サイトが各ページについて2つのバージョンを配信する手法です。検索エンジンのクローラーには事前レンダリングされた静的なHTMLのスナップショットを、人間のユーザーには完全なJavaScriptのシングルページアプリケーションの体験を配信します。Googleは2018年に、JSの多いサイトのための回避策としてこれを公に推奨しましたが、GooglebotのJSレンダリングが成熟するにつれて、2024年までにひそかに「過去の回避策」へと格下げしました。
ダイナミックレンダリングとは、サイトが各ページについて2つのバージョンを配信する手法です。検索エンジンのクローラーには事前レンダリングされた静的なHTMLのスナップショットを、人間のユーザーには完全なJavaScriptのシングルページアプリケーションの体験を配信します。Googleは2018年に、JSの多いサイトのための回避策としてこれを公に推奨しましたが、GooglebotのJSレンダリングが成熟するにつれて、2024年までにひそかに「過去の回避策」へと格下げしました。
なぜ重要か
JavaScriptの多いサイトは、かつては空のHTMLの骨組みだけを配信し、クローラーがJSを実行して本当のコンテンツを認識してくれることに頼っていました。Googlebotは最終的にそこにたどり着きましたが、その速度は遅く、多くの場合、最初のHTML取得から数日後でした。そして他のクローラー（Bing、AIボット、Facebookのリンク展開）はさらに劣っていました。ダイナミックレンダリングは、アプリを書き換えることなく、クローラーが完全にレンダリングされたHTMLを即座に認識できることをSEOチームに保証しました。eコマースのカタログ、JSのダッシュボード、SEO上の要件が重要なSPAにとって、これは実用的な橋渡しでした。今日でも多くのサイトがダイナミックレンダリングで稼働しており、移行が必要なため、これを理解することは依然として重要です。
仕組み
1. リクエストの到着: エッジまたはサーバーがユーザーエージェントを調べます。
2. クローラーの検出: ユーザーエージェントが既知の検索ボット（Googlebot、Bingbot、Twitterbot、LinkedInBot、AIクローラー）に一致する場合、リクエストは事前レンダリングサービスへ振り分けられます。そうでなければ、通常のSPAに到達します。
3. 事前レンダリングサービス: ヘッドレスChrome（多くはprerender.io、Rendertron、Puppeteer、Playwrightを介して）がページを取得し、JSの完了を待ってDOMをキャプチャし、静的なHTMLを返します。
4. キャッシュ: レンダリングされたHTMLはキャッシュされ、以降のクローラーのアクセスで再レンダリングが起きないようにします。
5. ボットはHTMLを、ユーザーはSPAを認識する: 同じURLで、2つの体験が提供されます。
なぜいまや「過去の回避策」なのか
Googleの2024年のガイダンスは、ダイナミックレンダリングを「推奨」から「回避策であり、長期的な解決策ではない」へと移しました。その理由は次のとおりです。
Googlebotは今やJSをうまくレンダリングする: Googleは最新のヘッドレスChromeを実行し、ほとんどのページでJSを迅速に処理します。ダイナミックレンダリングの本来の理由は、Googleに関してはほぼなくなりました。
メンテナンスの負担: 2つ目のレンダリングパイプラインを並行して運用することは、たいていメリットを上回る運用の複雑さを生みます。
乖離のリスク: 事前レンダリングサービスが壊れたり古くなったりすると、ボットは古いコンテンツを、ユーザーは新しいコンテンツを認識します。これは典型的なクローキングのシグナルです。
クローキングのペナルティではないが、紙一重: Googleはダイナミックレンダリングがクローキングではないと明言していますが、ボットとユーザーの表示の乖離は手動での審査を引き起こす可能性があります。
最新のSSR / SSGの方が優れている: Next.js、Nuxt、SvelteKit、Astro、Remixは、デフォルトでサーバーレンダリングまたは静的生成されたページを配信します。ダイナミックレンダリングは不要です。
（もしあるとすれば）いつ依然として理にかなうか
書き換えられないレガシーなSPA: SSRへの移行の予算がない、成熟したJSの多いアプリ。ダイナミックレンダリングは、つなぎとして依然として有効です。
Google以外のクローラー: AIクローラー、Bing、Baidu、ニッチなボットは、依然としてGoogleよりもJSのレンダリングが劣ります。それらがトラフィックにとって重要なら、ダイナミックレンダリングが役立ちます。
ウィジェットや埋め込み: 最初のHTMLの後にJSで読み込まれるコンテンツ。クローラーにそれを見せる唯一の方法である場合もあります。
エッジレンダリングの回避策: CDNのエッジで、別の事前レンダリングサービスを使わずに、SPAをその場でHTMLに変換する薄いダイナミックレンダリング。
ダイナミックレンダリングから移行する方法
1. JSで実際に何が失敗しているかを監査する: Search ConsoleのURL検査やレンダリングの比較を使います。多くの「JS SEOの問題」は、重要なページにSSRが欠けているだけです。
2. 重要なページをSSRまたはSSGに移す: ホーム、ランディング、商品、記事のページを最優先に。ダッシュボードやログイン後の領域はSPAのままにします。
3. 最新のフレームワークを使う: Next.js / Nuxt / SvelteKitは、ハイブリッドレンダリングを標準で扱います。
4. 同等性を検証する: 移行後、Screaming Frogで新しいサイトをクロールし、HTMLが以前の事前レンダリングが生成したものと一致することを確認します。
5. 事前レンダリングサービスを廃止する: Search Consoleのカバレッジレポートが数週間にわたってクリーンになってからにします。
よくある間違い
意図的に異なるコンテンツを配信する: ダイナミックレンダリングは「同じコンテンツ、異なる形式」です。異なる コンテンツ はクローキングであり、ペナルティを受けます。
事前レンダリングのキャッシュを更新しない: 古い事前レンダリングはボットに古いコンテンツを供給し、昨日の商品で上位表示されてしまいます。
すべてを事前レンダリングに頼る: SSR戦略のないサイトの前面に事前レンダリングを置くと、障害が1つ起きるたびにクローラーから見えなくなる状態が続きます。
Googlebot以外のUAリストを無視する: Bing、Yandex、Baidu、AIクローラーはいずれも異なるUAを持っています。1つでも忘れると、そのボットに対してクローキングしてしまいます。
新規構築でダイナミックレンダリングを使う: やめましょう。代わりに最新のフレームワークでSSR/SSGを使います。
Sources: