意味と範囲
CSRでは、サーバーは軽量なHTMLのシェルを返し、意味のあるコンテンツはJavaScriptがブラウザーで取得または組み立てます。操作の多いアプリケーションには適していますが、依存の連鎖が一つ増えます。クローラーも訪問者も同じ重要なコンテンツを受け取るには、HTML、スクリプト、API、レンダリングのロジックがすべて機能する必要があります。
実践的な流れ
まず、ユーザーとクローラーに見えている必要がある要件から始めます。titleタグ、メインの文章、canonicalタグ、robotsディレクティブ、内部リンク、画像、構造化データが、最初のHTMLにあるのか、JavaScriptの実行後にしか現れないのかを調べます。発見に重要なコンテンツが後回しになっている場合は、確実に届けられる構成を選びます。サーバーサイドレンダリング、静的生成、テスト済みのハイブリッド方式などです。
確認すること
代表的なテンプレートを一部選び、生のHTMLの取得結果と、レンダリング後の確認結果を比べます。JavaScriptのリソースがブロックされていないこと、非公開のセッションなしでデータのリクエストが成功すること、canonicalの情報が安定していること、エラー状態がメインのコンテンツに置き換わっていないことを確認します。Googleは、フレームワーク名だけでクロール可能性が保証されると考えず、JavaScriptアプリケーションをテストするよう勧めています。
限界とよくある間違い
CSRを、自動的にSEOに悪いとは言えません。クローラーには何も見えないと決めつけるのも誤りです。有用な問いは、実際のレンダリング経路を経たあとも、必要なコンテンツとメタデータが一貫して利用できるかどうかです。ボット専用の別の体験は、同等性を保ち、維持できる場合を除いて避けます。
具体的なルートでのレンダリング確認
/guides/renderingのようなルートを例にします。ブラウザーの状態なしで取得し、レスポンスボディを保存します。次に、クリーンなブラウザーセッションで同じルートを読み込み、レンダリング後のDOM、コンソール、ネットワークパネルを確認します。二つの内容がバイト単位で同一である必要はありませんが、ルートの目的は保たれている必要があります。使えるtitleタグ、メインの見出し、主要なテキスト、canonicalの参照、クロール可能なリンク、重要な構造化データは、認証が必要なAPI呼び出し、タイミングの競合、クライアントサイドの例外に頼らず解決される必要があります。
<a href="/guides/rendering">Rendering guide</a>\n<link rel="canonical" href="https://example.test/guides/rendering">アプリシェルが失敗する場合、最初のHTMLにはルート要素しかなく、データのリクエストが401、403、404、またはJavaScriptの例外で失敗していることがあります。人間はログイン後にキャッシュされたページを見ていても、クリーンなレンダラーには空のシェルしか見えません。対処は、そのルートを200の成功として扱うふりをすることではありません。エラーの経路を分類し、そのルートに必要な公開データを利用できるようにするか、すぐに届ける必要があるコンテンツにはサーバーサイドレンダリングや静的レンダリングを選びます。
Googleは、JavaScriptページに対するクロール、レンダリング、インデックス登録のパイプラインを文書化しています。200のレスポンスはレンダリングのキューに入れますが、ブロックされたページやブロックされたJavaScriptリソースはレンダリングされません。また、読み込まれたリソース、コンソール出力、例外、レンダリング後のDOMを確認するために、URL検査ツールやリッチリザルトテストを使うことも推奨しています。これらは補助的な根拠として使い、最新のログインしていないブラウザーでのテスト結果と比べます。クライアント側のアナリティクスは、Googlebotのレンダリングの動きを完全には反映しません。
動的レンダリングを、標準的な構成上の解決策にするのは避けます。Googleはこれを、長期的な解決策ではなく回避策だと説明しています。クローキングも避けてください。クローラーに配信するコンテンツは、ユーザーが受け取るものと同等でなければなりません。ルート、ユーザーの状態、生のレスポンス、レンダリング結果、失敗したリソースのステータスを記録します。後でフレームワークをアップグレードしたときに、同じ根拠で確認できるようにするためです。