2024年の初め、中規模のeコマース企業である顧客から連絡を受けました。React フロントエンド、Next.js で、書面上ではすべてを正しく実行していました。彼らのカテゴリページはどこにもランク付けされていませんでした。どこにも。サイトは素晴らしく見え、UX チームは誇りに思っていて、Googlebot は本質的に空の<div>スープを見ていました。3ヶ月間の収益損失、すべて誰かが 2021年の Medium の記事を読んで Googlebot が JavaScript を「Chrome と同じように処理している」と仮定したせいです。処理していません。確実ではありません。2026年でも。
重要なポイント：Googlebotは JavaScript を「ある程度」レンダリングしますが、レンダリングは遅延し、失敗する可能性があるため、インデックスさせたいコンテンツはサーバーサイドでレンダリングし、クライアントのみのコンテンツは見えないものとして扱うべきです。
誰も明確には言いませんが、これが事実です：GooglebotはJavaScriptをレンダリングできます。ただし、クロールバジェット内で実行され、非同期で2次波でレンダリングされ、初期ペイント後にコンテンツを取得するJavaScriptはランキングに対するギャンブルです。有機トラフィックの喪失で数万ポンドの損失をクライアントに招くのを見てきました。だから、サーバーサイドレンダリングが実際に役立つ時期と、SEOゲインなしにあなたのサイトを静かに遅くし、メンテナンスを難しくする時期について、正確に話しましょう。
2026年のGooglebotがJavaScriptを処理する仕組み
Googlebot はヘッドレス Chromium インスタンスを使用しています。この部分は本当で、数年前からそうです。しかし、ドキュメントが静かに見過ごしていることはこうです。レンダリングは2波で行われます。第1波は HTML をクロールします。第2波、JavaScript が実行される場所は後で行われ、時には数時間後、時には数日後です。Google のドキュメント自体がこの2波アーキテクチャを確認していますが、遅延について正確に宣伝しているわけではありません。
これが実際に意味するところ：製品タイトル、メタディスクリプション、または本文がマウント後に発火する useEffect 内に存在する場合、Googlebot が空白または部分的なバージョンのページにインデックスを付ける実際の可能性があります。Google Search Console の URL 検査ツール、レンダリングされた HTML タブを使用して、これを何十回も検証しました。これは Googlebot が見るものを正確に表示します。今すぐ React ページで実行してください。不愉快な驚きを受けるかもしれません。
誰も語られないクロールバジェットの問題
Googlebot は無限の計算リソースを持っていません。大容量の JavaScript バンドルはクロールバジェットをより早く消費します。すべてのページで 200KB のブロッキング JS を持つサイトは、より軽いサイトよりも低頻度でクロールされます。小規模なブロシュアサイトではほぼ問題になりませんが、40,000 個の SKU を持つ e コマースカタログの場合はどうでしょう？新着商品を Googlebot が 2 日で見つけるのか、2 週間かかるのかの違いになります。
マンチェスターのクライアント向けに卸売ファッションサイトを構築しました。約22,000の製品ページ、Shopify ベースですが、上に重くカスタマイズされた React ストアフロント層があります。Search Console の彼らのクロール統計は、Googlebot がクロール予算の約40%を JavaScript レンダリングに費やしていることを示していました。それを必要としなかった製品ページのクライアント側ハイドレーションを削除し、それらのテンプレートの静的 HTML にドロップしました。そしてクロール範囲は6週間以内に約30%改善されました。
SSR が本当に活躍する場面
よろしい。サーバー側レンダリング、サーバーが完全な HTML を生成してからブラウザに送信する場合、確かに2波問題を解決します。コンテンツが初期 HTML レスポンスに含まれている場合、Googlebot は JavaScript レンダリングを待つ必要がありません。第1波がそれを拾います。完了。
SSR は以下の特定の状況で正しい選択です：
- コンテンツが豊富なページで、ランク付けが主な目標である場合。ブログ投稿、ランディングページ、実質的なコピーを含む製品詳細ページ、これらは最初のバイトで完全な HTML を提供するべきです。
- 頻繁に変わるデータが必要なページで新鮮である必要がある場合。ニュースサイト、ライブ価格、在庫の可用性、短いキャッシュ TTL による SSR はここで意味があります。
- ページ数に対してクロールバジェットが少ないサイト。Googlebot が 1 週間で快適にクロールできるより多くのページがある場合、優先度の高いテンプレートに SSR を適用すれば、一貫したインデックスを確保できます。
- ページごとに異なるメタデータ。タイトルタグ、正規 URL、Open Graph タグ、これらが JavaScript によって書かれている場合、SSR が瞬時に解決する問題があります。
Next.js はこれを getServerSideProps（または新しい App Router の Server Components で、デフォルトでは SSR）で比較的簡単にします。Nuxt は Vue ショップ向けに同じことを行います。Seahawk でのほぼすべての真摯な SEO プロジェクトで Next.js に頼っており、コンテンツに触れるものはすべてサーバーコンポーネントをデフォルトにする内部スターターテンプレートがあります。
しかしSSRは無料ではない
ここが問題です。SSRはサーバー負荷を追加し、サーバーが遅い場合やリソース不足の場合は遅延を追加し、デプロイメントパイプラインに複雑さを追加します。最初のバイト時間（TTFB）はコアウェブバイタルにとって重要です。到着に800msかかる肥大化したSSRレスポンスは、クライアント側のハイドレーション少しを備えた高速な静的ページよりも、インタラクションから次のペイントと最大コンテンツペイントに悪いです。
2022年、私はSaaSプロジェクトでこの過ちを犯しました。すべてをSSR化した。すべてのダッシュボードビュー、すべての設定パネル、SEO価値がゼロでログイン壁の後ろにあるページまで。低スペックのホスティングでTTFBが900msほど出ていました。認証済みページには適用されないSEO効果を追い求めて、Core Web Vitalsに悪影響を与えていた。解き解くのに2スプリントかかりました。
SSRがあなたを傷つける場所
直接言わせてください：SSRは構築されるもののかなりの部分に対して間違っています。
ログインの後ろにある認証済みページ。Googlebotはそれらを見ることができません。ここでのSSRは浪費です。完全な無駄で、インデックス効果のないオーバーヘッドです。クライアントサイドレンダリングを使い、キャッシュできるものはキャッシュし、インデックスされることのないページをレンダリングするサーバーコンピューティングコストの支払いをやめてください。
高度にインタラクティブなUIコンポーネント。ダッシュボード、データ可視化、ドラッグアンドドロップインターフェース。SSRは初期シェルをくれますが、結局すべてをハイドレートしています。SSRコストもハイドレーションコストも支払っている。ここではアイランドアーキテクチャを検討してください。静的シェルをレンダリングし、インタラクティブな部分だけをハイドレートします。Astroはこれを美しく実装しています。2023年後期から、コンテンツ量の多いサイトに使ってきましたが、このアプローチについての考え方が本当に変わりました。
ランキング問題のない小規模サイト。5ページのポートフォリオ、地元企業のパンフレットサイト。SSRパイプラインのオーバーヘッドはそれだけの価値がありません。CDN上の静的HTML、終わり。
静的生成：使用されていない中間地点
「SEO が必要だ」から SSR に直行して、静的サイト生成（SSG）をスキップしてしまう人が多い。これは間違いだ。
SSG（ページをデプロイ時にビルドして静的HTMLで配信）は、SSRのSEO効果をすべて提供します（初回レスポンスで完全なHTML、JavaScriptレンダリングへの依存なし）が、サーバーコンピューティングコストはゼロです。より高速です。スケーリングは簡単です。そしてコンテンツサイト、ブログ、マーケティングページ、ドキュメント、ポートフォリオの大多数では、オンデマンドレンダリングを必要とするほどコンテンツが頻繁に変更されません。
Seahawkではライブデータを必要としないものはデフォルトでSSGを採用しています。App RouterのNext.js generateStaticParams、コンテンツ量の多いプロジェクト向けGatsby（はい、今でも、問題ありません）、パフォーマンスが主な関心事のAstro。静的HTMLはCloudflareまたはVercelのCDN経由でエッジにキャッシュされ、TTFB数値は驚異的で、グローバルで一貫して100ms未満です。
落とし穴は、数千ページが頻繁に更新される場合、またはコンテンツがユーザーごとにパーソナライズされている場合、SSGが機能しなくなることです。そこでSSRまたはISR（Incremental Static Regeneration、スケジュールに基づいて静的ページを再検証するNext.jsのハイブリッドアプローチ）を使います。Seahawkは60秒の再検証ウィンドウを持つISRが完璧に機能した物件ポータルプロジェクトを持っていました。リスティングは十分に新しく保たれ、TTFBは低いままで、Googlebotは毎回完全なHTMLを見ました。
JavaScript SEO 問題の診断
何も書き直す前に、診断しよう。私が実際に使うプロセスはこれだ。
- Google Search Console の URL インスペクション。疑わしい URL をフェッチしてレンダリングする。「レンダリング済み HTML」を実際の DOM と比較する。レンダリング済みビューにコンテンツがなければ、Googlebot はそれを見ていない。
- JavaScript レンダリング モードの Screaming Frog。JavaScript をレンダリングするよう設定してクロールを実行する。レンダリングなしのクロールと比較する。差分が JS に依存しているものを示す。
- CI内のLighthouse。Lighthouse CIをデプロイメントパイプラインに統合します。ベースラインターゲットとしてLCPが2.5秒未満、TTFBが600ms未満であることを望みます。
- Chrome DevTools > Network タブ > JavaScript を無効にする。いたってシンプル。JS を無効にしたときにページのコンテンツが消えたら、Googlebot の最初の波は何も有用なものを見ていない。
- Search Consoleカバレッジレポート。大規模な「クロール済み、現在インデックスなし」はコンテンツ品質の問題ではなく、レンダリング問題を指すことがよくあります。コンテンツ品質を最初に想定してはいけません。
正直なところ、ステップ4でクライアントサイトで見かける問題の約60%を解決します。30秒で済みます。他の何をするよりも先にこれをやってください。
ハイドレーションの代償：Core Web Vitalsが低下している理由
完全なSSRと完全なクライアントサイドハイドレーションは、注意しないと両者の最悪の側面です。完全なHTMLドキュメントを送信し、ブラウザーがビジュアルレンダリングを行い、その後React（またはVueなど）がキックインしてDOMを「引き継ぎます」。そのテイクオーバー（ハイドレーションフェーズ）の間、ページはビジュアル的にはインタラクティブですが、機能的には凍結しています。クリックは登録されません。フォームは送信されません。
これはTotal Blocking TimeとINPスコアを殺すものです。SSR化されているがクライアント側の大規模なバンドルを持つNext.jsサイトで常にそれを見ます。Reactチームの独自のServer Componentsのドキュメンテーションは、より多くのロジックをサーバー上に保ち、ブラウザにより少ないJavaScriptを送信することによってこの問題を減らすことを特に設計されています。
実践的な対策：next build の出力や Bundle Phobia を使って JavaScript バンドルを監査してください。何が大きいのかを特定し、それが本当にクライアントバンドルに含まれる必要があるのかを検討します。昨年、3つのデータ取得ライブラリをサーバーのみに移動し、server-only パッケージインポートを使用することで、クライアントのバンドルから 180KB を削減しました。彼らの INP は 340ms から 190ms に短縮されました。これは単なる UX 改善ではなく、ランキングシグナルの改善です。
レンダリングモード決定フレームワーク
推測を止めてください。ここが私の判断方法です：
- Googlebotはこのページを見る必要がありますか？いいえの場合、CSRを使い、終わり。
- コンテンツが1日に複数回変更されますか？いいえの場合は、SSGを使用してください。
- コンテンツが頻繁に変更され、かつGooglebotがそれを認識する必要がありますか？ 古さの許容度が存在すればISRを、存在しなければSSRを使用してください。
- ページが高度にインタラクティブで、コンテンツが最小限ですか？ SSGシェルを備えたCSRを使用してください。
- サーバー予算に制約がありますか？ SGとスタティックをできるだけ優先してください。
このフレームワークは約90%のケースに対応しています。残りの10%はエッジケース、ログイン済みユーザー向けのパーソナライズされたコンテンツでSEOも必要な場合（e-commerceの公開ページ上の「あなたにおすすめ」のようなもの）で、通常はハイブリッドアプローチが必要です。つまり、コンテンツスケルトンをSSRで、パーソナライゼーションをハイドレーション後のクライアント側で追加します。
---
FAQ
Googlebotは2026年にJavaScriptを完全にレンダリングしますか？
JavaScriptはレンダリングしますが、初回クロールから数時間から数日遅れる二次ウェーブで実行されます。インデックス登録に重要なコンテンツ、本文、タイトル、メタタグは初回HTMLレスポンスに含める必要があります。Googlebotのレンダリングキューにランキングを賭けないでください。
SSRは常にクライアント側レンダリングよりもSEOに優れていますか？
いいえ。SSRは、JavaScriptで生成されたコンテンツをパブリックにインデックスされるページでSEOに優れています。認証が必要なページ、高度にインタラクティブなツール、またはログインの背後にあるものについては、SSRはSEOのメリットなしにコストを追加します。コンテキストに応じた適切なレンダリングモードを使用してください。
サイトのJavaScript SEOの問題を確認する最速の方法は何ですか？
Chrome DevToolsを開き、Settings に移動して、Debugger の下の「Disable JavaScript」をチェックし、ページをリロードしてください。意味のあるコンテンツが消えた場合、Googlebot の最初のクロール波は同じ空のページを見ています。Google Search Console の URL検査も実行して、レンダリングされた HTML タブをライブ DOM と比較してください。
Next.js App Router は JavaScript SEO に役立ちますか？
はい、大きく異なります。App RouterのServer Componentsはデフォルトでサーバー上でレンダリングされるため、出力は完全なHTMLです。実質的に、インタラクティビティが不要なコンポーネントであれば自動的にSSRを取得しています。ただし落とし穴は、Server ComponentsとClient Componentsを正しく組み合わせるには規律が必要で、誤ってClient Componentsに過剰に処理を押し込んでしまい、以前のCSRの問題を再現するのが簡単ということです。
React Server Components を使うべきですか、それとも単に静的にすべきですか？
コンテンツが本当に静的で、デプロイ間で変わらなければ、静的にしてください。SSGはより単純で、ホスティングコストが安く、SEOの点でも同じくらい効果的です。React Server Componentsが活躍するのは、サーバーでレンダリングされたHTML全体をハイドレートするオーバーヘッドなしに、公開ページで動的データが必要な場合です。これらは同じものではなく、正しい選択はコンテンツがどの程度動的かによって完全に異なります。
---
率直な説明：Googlebotは2019年時点より賢くなりましたが、Chromeではありません。二段階レンダリングモデル、クロールバジェットの制限、ハイドレーションコストは、「SSRを使用している」というのは完全なJavaScript SEO戦略ではなく、出発点に過ぎないということです。各レンダリングモードが何を犠牲にするのか理解し、構築前に監査を行い、Googlebotが決して見ることのないページに対してSSRをデフォルトにするのはやめてください。Seahawk Mediaで私が最も誇りに思っているサイトは、最も高度なレンダリングパイプラインを使用しているサイトではありません。すべてのページが必要な量だけレンダリングされ、それ以上ではないサイトです。