JavaScriptのレンダリングとSEO。この話、もう何年も前から議論されてて、正直ちょっと食傷気味なところもある。でも、最近またクライアントのサイトで「あれ？」と思うことがあって、考えを整理してる。結局、みんな小手先のテクニックに走りすぎてるんじゃないかな、って。
CSRがダメでSSRがいい、みたいな単純な話じゃないんだよな。もっと根本的な、検索エンジン側の「事情」を考えないと、本質を見失う気がする。
まず結論というか、今の僕の考え
すごく、すごく雑に言うと、今のGooglebotはJavaScriptをちゃんとレンダリングできる。できるんだけど、すごく「気まぐれ」で「予算」がある。 サイトが重すぎたり、複雑すぎたりすると、途中で「もういいや」って諦めちゃう。この「諦めポイント」をどう避けるかが、JavaScript SEOの核心なんじゃないか、と思ってる。
よくある誤解：「CSR vs SSR」の議論
よくあるでしょ、クライアントサイドレンダリング（CSR）はSEOに弱くて、サーバーサイドレンダリング（SSR）にすべきだ、みたいな話。 間違いじゃない。確かにSSRの方が、クローラーが最初から完成品のHTMLを見れるから、SEO的には有利。 でも、それだけだと説明がつかないことがある。
例えば、ReactやVueで作られたゴリゴリのCSRサイトでも、ちゃんとインデックスされて上位にいるサイトもある。なんでか？ それは、Googleのレンダリングの「お作法」の範囲内で、ちゃんとコンテンツを見せられてるから。逆に、SSRにしててもサーバーの応答が遅かったりしたら、元も子もないわけで。
だから、「どの技術を使うか」というよりは、「Googlebotのレンダリングの仕組みをどう乗りこなすか」って視点の方が、たぶん大事。
本当の課題：Googleのレンダリングサービス（WRS）とその「予算」
Googleは、クロールとレンダリングを別々のプロセスでやってる。 まずHTMLをクロールして、そのあと「レンダリングが必要だね」って判断したら、Web Rendering Service（WRS）っていうサービスにキューイングする。 問題は、この第二段階のレンダリングが、無制限・無条件に行われるわけじゃないってこと。
ここが一番のポイントだと思う。WRSにはリソースの制約、つまり「予算」がある。最近のGoogle公式情報でも、レンダリングの仕組みについて言及が増えてるけど、具体的な数値はあまり出てこない。 でも、海外の技術ドキュメントとかを漁ると、もっと生々しい数字が出てきたりする。
例えば、ある技術情報サイトによると、Googlebotのレンダリング環境にはこんな制約があるらしい。
- JSヒープメモリ制限: モバイル版では256MB。これを超えるとクラッシュする可能性がある。
- タイムアウト: 重要な処理に数百ミリ秒以上かかると、打ち切られるリスクがあるらしい。
- サードパーティスクリプト: あまりに多くの外部スクリプトを読み込んでいると、実行が停止されることがある。
もちろん、これはGoogleが公式に常時発表してる数字じゃないから、あくまで目安。でも、日本の一般的なSEO解説記事が「レンダリングが遅れることがある」ってふんわり書いてるのとは、だいぶ解像度が違う。 この「予算」の存在を意識するだけで、やるべきことが見えてくる。
要するに、豪華な演出のために大量のJavaScriptをクライアント側で実行させると、Googlebotの予算オーバーで、肝心なコンテンツが表示される前にレンダリングを打ち切られる。結果、インデックスされない「空白のページ」ができあがる。これじゃないかな、問題の本質は。
じゃあ、どうすればいいのか？
まず、自分のサイトが「危険水域」にいるのかどうかを知ること。僕だったら、こんな感じで切り分けるかな。
| サイトの種類 | リスクレベル | まず確認すること | 個人的な一言 |
|---|---|---|---|
| ブログ、小規模なサイト (軽いJS) | 低い | Search Consoleの「URL検査」で、公開URLのスクリーンショットが正しく表示されてるか。 | たぶん心配しすぎ。SSRとか考える前に、普通にページの表示速度を気にした方がいい。 |
| SPAで作られたWebアプリ (重いJS) | 高い | 「URL検査」のレンダリング後HTMLに、主要なコンテンツやリンクが含まれているか。空っぽになってない？ | ここが一番危ないゾーン。開発者と協力して、初期表示に必要なJSを最小限にできないか相談するところから。 |
| ECサイト (JSでの絞り込み機能など) | 中くらい | 絞り込み後のURL（パラメータ付きURL）を「URL検査」にかけてみる。商品がちゃんと表示されてるか。 | ユーザーには便利だけど、クローラーには優しくないことが多い。絞り込み結果の主要な組み合わせは、静的なページとして存在させた方が安全かも。 |
| SSR/SSGフレームワーク利用サイト (Next.jsなど) | 低いけど油断は禁物 | サーバーの応答時間（TTFB）。SSRでもサーバーが遅かったら意味がないから。 | 技術的に解決済み、と思いがちだけど、インフラ側の問題でつまずくことも。結局、速さが正義。 |
回避策としての「動的レンダリング」
もし、どうしても既存のCSRサイトの改修が難しい…でもSEOはなんとかしたい…という場合の「緊急避難」的な策が、動的レンダリング（Dynamic Rendering）。
これは、アクセスしてきたのが人間（ブラウザ）か、クローラー（Googlebotなど）かをサーバー側で判別して、人間にはリッチなJSのページを、クローラーにはあらかじめ用意しておいた静的なHTMLを見せる、というやり方。
確かに、手っ取り早くクローラーにコンテンツを認識させるには有効。でも、Google自身がこれを「回避策（workaround）」と言っていて、長期的にはSSRなどを推奨していることは、知っておくべき。 ユーザーが見るものとクローラーが見るものが違うっていうのは、本来ちょっと不自然な状態だからね。管理も複雑になるし。
個人的には、大規模なリニューアルまでの「つなぎ」として使うならアリ、くらいの位置付けかな。
まとめ：結局、シンプルに考えよう
いろいろ書いたけど、突き詰めると「Googlebotに優しくしよう」ってことなんだと思う。人間でも、すごくごちゃごちゃしてて分かりにくい話は、聞く気が失せるじゃない？ それと一緒。
SSRやCSRという技術論も大事だけど、それ以前に、
- 本当にそのJavaScriptは必要か？
- もっと軽量にできないか？
- 重要なコンテンツは、できるだけ少ない処理で見せられないか？
という原点に立ち返るのが、一番の近道な気がする。技術のトレンドを追うのもいいけど、まずは検索エンジンの「気持ち」を想像してみることが、案外、解決の糸口になるんじゃないかな。
あなたのサイトはどうですか？
この記事を読んで、「うちのサイト、もしかしてレンダリングで損してるかも…？」と思った点はありましたか？ もしあれば、どんな「兆候」からそう感じたか、ぜひコメントで教えてください。（例：「Search Consoleのスクリーンショットが崩れてた」「特定のページのインデックスが異様に遅い」など）
