2024年初頭、あるクライアントから連絡があった——中堅規模の e コマース企業で、React フロントエンド、Next.js を使用していて、理論上はすべてのベストプラクティスに従っていた。彼らのカテゴリーページは全く検索ランキングに表示されていなかった。全く表示されていなかった。サイトの見た目は素晴らしく、UX チームは満足していたのに、Googlebot は本質的に空の <div> スープを見ていたのだ。3ヶ月間の売上喪失。すべては 2021年の Medium の記事を読んだ誰かが、Googlebot は「今は Chrome のように JavaScript を処理する」と仮定したからだ。そんなことはない。確実ではない。2026年も変わらない。Next.js, did everything right on paper. Their category pages were ranking nowhere. Nowhere. The site looked brilliant, the UX team was proud of it, and Googlebot was essentially seeing empty<div>soup. Three months of missed revenue, all because someone had read a Medium post from 2021 and assumed Googlebot handles JavaScript "like Chrome does now." It doesn't. Not reliably. Not in 2026.
重要なポイント：Googlebotは JavaScript を「ある程度」レンダリングしますが、レンダリングは遅延し、失敗する可能性があるため、インデックスさせたいコンテンツはサーバーサイドでレンダリングし、クライアントのみのコンテンツは見えないものとして扱うべきです。Googlebot renders JavaScript "sort of": rendering is delayed and fallible, so server-side render anything you need indexed and treat client-only content as invisible.
誰も明確には言いませんが、これが事実です：GooglebotはJavaScriptをレンダリングできます。ただし、クロールバジェット内で実行され、非同期で2次波でレンダリングされ、初期ペイント後にコンテンツを取得するJavaScriptはランキングに対するギャンブルです。有機トラフィックの喪失で数万ポンドの損失をクライアントに招くのを見てきました。だから、サーバーサイドレンダリングが実際に役立つ時期と、SEOゲインなしにあなたのサイトを静かに遅くし、メンテナンスを難しくする時期について、正確に話しましょう。can render JavaScript. But it runs on a crawl budget, it renders asynchronously in a secondary wave, and any JavaScript that fetches content after the initial paint is a gamble you're taking with your rankings. I've seen this cost clients tens of thousands of pounds in lost organic traffic. So let's be precise about when server-side rendering actually helps you, and when it quietly makes your site slower and harder to maintain for no SEO gain whatsoever.
2026年のGooglebotがJavaScriptを処理する仕組み
Googlebot はヘッドレス Chromium インスタンスを使用している。その部分は本当で、ここ数年ずっとそうだ。しかし、ドキュメントが静かに目をそらしている重要な点がある——レンダリングは2段階で発生するのだ。第1段階は HTML をクロールする。第2段階——JavaScript が実行される——は後で発生する。時には数時間後、時には数日後だ。Google 自身のドキュメントでこの2段階アーキテクチャを認めている。ただし、遅延について明確には宣伝していない。Google's own documentation confirms this two-wave architecture, though it doesn't exactly advertise the delay.
これが実務的に何を意味するか——製品タイトル、メタディスクリプション、またはボディコピーが mount 後に実行される useEffect の内部に存在する場合、Googlebot がページの空白版または部分版をインデックスする実在する危険性がある。Google Search Console の URL 検査ツールを使用して、これを何十回も検証してきた——レンダリング HTML タブは、Googlebot が正確に何を見ているかを示す。今すぐ React ページで実行してみてほしい。不愉快な驚きが待っているかもしれない。useEffect that fires after mount, there's a real chance Googlebot indexes a blank or partial version of your page. I've verified this dozens of times using Google Search Console's URL Inspection tool -- the rendered HTML tab shows you exactly what Googlebot sees. Run it on your React pages right now. You might get a nasty surprise.
誰も語られないクロールバジェットの問題
Googlebot は無限の計算リソースを持っていません。大容量の JavaScript バンドルはクロールバジェットをより早く消費します。すべてのページで 200KB のブロッキング JS を持つサイトは、より軽いサイトよりも低頻度でクロールされます。小規模なブロシュアサイトではほぼ問題になりませんが、40,000 個の SKU を持つ e コマースカタログの場合はどうでしょう？新着商品を Googlebot が 2 日で見つけるのか、2 週間かかるのかの違いになります。
マンチェスターのクライアント向けに、卸売アパレルサイトを構築した——約22,000個の製品ページで、Shopify ベースだが、その上に大幅にカスタマイズされた React ストアフロント レイヤーが乗っている。Search Console のクロール統計は、Googlebot がクロール予算の約40%を JavaScript レンダリングだけに費やしていることを示していた。JavaScript が不要だった製品ページのクライアント側ハイドレーションを削除し、それらのテンプレート用の静的 HTML に落とし込み、6週間以内にクロール カバレッジが約30%改善された。
SSR が本当に活躍する場面
そう。サーバー側レンダリング——サーバーがブラウザに送信する前に完全な HTML を生成する——は実際に2段階の問題を解決する。コンテンツが初期 HTML レスポンスに含まれていれば、Googlebot は JavaScript レンダリングを待つ必要がない。第1段階でピックアップされる。終了。
SSR は以下の特定の状況で正しい選択です：
- ランキングが主な目標となるコンテンツが豊富なページ。ブログ記事、ランディング ページ、実質的なコピーを含む製品詳細ページ——これらは最初のバイトで完全な HTML を配信すべきだ。Blog posts, landing pages, product detail pages with substantial copy -- these should be delivering full HTML on the first byte.
- 頻繁に変わるデータが必要で、最新である必要があるページ。ニュース サイト、ライブプライシング、在庫状況——短いキャッシュ TTL を使用した SSR がここで有効だ。News sites, live pricing, stock availability -- SSR with short cache TTLs makes sense here.
- ページ数に対してクロールバジェットが少ないサイト。Googlebot が 1 週間で快適にクロールできるより多くのページがある場合、優先度の高いテンプレートに SSR を適用すれば、一貫したインデックスを確保できます。If you've got more pages than Googlebot comfortably crawls in a week, SSR on your high-priority templates buys you consistent indexation.
- ページごとに異なるメタデータ。タイトルタグ、canonical URL、Open Graph タグ——これらが JavaScript によって書き込まれている場合、SSR が即座に解決する問題がある。Title tags, canonical URLs, Open Graph tags -- if these are being written by JavaScript, you've got a problem SSR fixes instantly.
Next.js では getServerSideProps（または新しい App Router のサーバー コンポーネント、デフォルトで SSR）でこれを比較的簡単に実現できる。Nuxt は Vue ショップでも同じことができる。私は Seahawk でほぼすべての真剣な SEO プロジェクトで Next.js に依存している——コンテンツに関わるすべてのものについて、デフォルトでサーバー コンポーネント化する社内スターターテンプレートがある。getServerSideProps(or the newer App Router's Server Components, which are SSR by default). Nuxt does the same for Vue shops. I lean on Next.js for almost every serious SEO project at Seahawk -- we've got internal starter templates that default to server components for anything that touches content.
しかしSSRは無料ではない
ここが問題です。SSRはサーバー負荷を追加し、サーバーが遅い場合やリソース不足の場合は遅延を追加し、デプロイメントパイプラインに複雑さを追加します。最初のバイト時間（TTFB）はコアウェブバイタルにとって重要です。到着に800msかかる肥大化したSSRレスポンスは、クライアント側のハイドレーション少しを備えた高速な静的ページよりも、インタラクションから次のペイントと最大コンテンツペイントに悪いです。Interaction to Next Paint and Largest Contentful Paint than a fast static page with a bit of client-side hydration.
2022年のSaaSプロジェクトで私自身がこの過ちを犯しました。すべてをSSRしていました――ダッシュボードのすべてのビュー、すべての設定パネル、SEO価値がゼロでログイン壁の後ろにあるページまで。低スペックのホスティングでのTTFBは900ms前後を彷徨いていました。認証済みページに適用されないSEO施策を追い求めてCore Web Vitalsに悪影響を与えていました。解きほぐすのに2スプリント費やしました。
SSRがあなたを傷つける場所
直接言わせてください：SSRは構築されるもののかなりの部分に対して間違っています。wrong for a significant chunk of what gets built.
ログイン壁の後ろにある認証済みページ。Googlebotはそれらのページをみることができません。ここでのSSRは無駄です――ランキング上のメリットなしの純粋なオーバーヘッドです。クライアントサイドレンダリングを使用し、キャッシュできるものはキャッシュして、インデックスされることのないページを描画するためにサーバーコンピュートに対価を払うのをやめてください。Googlebot can't see them. SSR here is waste -- pure overhead with no ranking benefit. Use client-side rendering, cache what you can, and stop paying for server compute to render pages that will never be indexed.
高度にインタラクティブなUIコンポーネント。ダッシュボード、データ可視化、ドラッグアンドドロップインターフェース。SSRは初期シェルを提供しますが、あなたはとにかくすべてをハイドレーションしています。SSRコストとハイドレーションコストの両方を払っています。ここではアイランドアーキテクチャを検討してください――静的シェルを描画し、インタラクティブな部分だけをハイドレーションします。Astroはこれを見事に行います。2023年後半からコンテンツボリュームの多いサイトに使用していますが、これは本当にこの問題についての考え方を変えました。Dashboards, data visualisations, drag-and-drop interfaces. SSR gives you the initial shell but you're hydrating everything anyway. You're paying the SSR cost and the hydration cost. Consider islands architecture here -- render the static shell, hydrate only the interactive bits. Astro does this beautifully. I've been using it for content-heavy sites since late 2023 and it's genuinely changed how I think about this.
ランキング問題を抱えていない小規模サイト。5ページのポートフォリオ、地元のビジネスパンフレットサイト――SSRパイプラインのオーバーヘッドは正当化されません。CDN内の静的HTML、以上です。A five-page portfolio, a local business brochure site -- the overhead of an SSR pipeline isn't worth it. Static HTML in a CDN, full stop.
静的生成：使用されていない中間地点
「SEO が必要だ」から SSR に直行して、静的サイト生成（SSG）をスキップしてしまう人が多い。これは間違いだ。
SSG――ページがデプロイ時に構築され、静的HTMLとして提供される――SSRのすべてのSEO利点（最初のレスポンス内の完全なHTML、JavaScriptレンダリング依存なし）をオンデマンドレンダリングの必要なしで提供します。より高速です。スケーリングは自明です。そしてコンテンツサイトの大多数――ブログ、マーケティングページ、ドキュメンテーション、ポートフォリオ――のコンテンツはオンデマンドレンダリングが必要なほど頻繁に変わりません。
Seahawkでは、ライブデータが必要ないものについてはSSGをデフォルトとしています。App RouterのNext.jsのgenerateStaticParams、コンテンツボリュームの多いプロジェクト向けGatsby（はい、相変わらず、問題ありません）、パフォーマンスが主要な関心事である場合はAstro。静的HTMLはCloudflareまたはVercelのCDNを経由してエッジでキャッシュされ、TTFB値は素晴らしいです――グローバルに一貫して100ms未満です。generateStaticParams in the App Router, Gatsby for content-heavy projects (yes, still, it's fine), Astro for anything where performance is the primary concern. The static HTML gets cached at the edge via Cloudflare or Vercel's CDN and the TTFB numbers are extraordinary -- consistently under 100ms globally.
課題は、SSGは頻繁に更新される数千ページを扱う場合、またはコンテンツがユーザーごとにパーソナライズされる場合に破綻することです。そこでSSRまたはISR（Incremental Static Regeneration――スケジュールで静的ページを再検証するNext.jsのハイブリッドアプローチ）に手を伸ばします。Seahawkは60秒の再検証ウィンドウを持つISRが完璧なフィットであった物件ポータルプロジェクトを持ていました。リスティングは十分に新しい状態を保ち、TTFBは低いままで、Googlebotは毎回完全なHTMLをみました。
JavaScript SEO 問題の診断
何も書き直す前に、診断しよう。私が実際に使うプロセスはこれだ。
- Google Search Console の URL インスペクション。疑わしい URL をフェッチしてレンダリングする。「レンダリング済み HTML」を実際の DOM と比較する。レンダリング済みビューにコンテンツがなければ、Googlebot はそれを見ていない。Fetch and render any suspect URL. Compare the "rendered HTML" against your actual DOM. If content is missing from the rendered view, Googlebot isn't seeing it.
- JavaScript レンダリング モードの Screaming Frog。JavaScript をレンダリングするよう設定してクロールを実行する。レンダリングなしのクロールと比較する。差分が JS に依存しているものを示す。Set it to render JavaScript and run a crawl. Compare with a non-rendering crawl. The delta shows you what's JS-dependent.
- CI内のLighthouse。Lighthouse CIをデプロイメントパイプラインに統合します。ベースラインターゲットとしてLCPが2.5秒未満、TTFBが600ms未満であることを望みます。Integrate Lighthouse CI into your deploy pipeline. You want LCP under 2.5 seconds and TTFB under 600ms as baseline targets.
- Chrome DevTools > Network タブ > JavaScript を無効にする。いたってシンプル。JS を無効にしたときにページのコンテンツが消えたら、Googlebot の最初の波は何も有用なものを見ていない。Brutally simple. If your page content disappears when you disable JS, Googlebot's first wave sees nothing useful.
- Search Console カバレッジレポート。「クロールされています――現在インデックスされていません」が大規模に表示されることは、多くの場合、コンテンツ品質の問題ではなくレンダリング問題を指しています。コンテンツ品質を最初に想定しないでください。"Crawled -- currently not indexed" at scale often points to rendering issues, not content quality issues. Don't assume content quality first.
正直なところ、ステップ4でクライアントサイトで見かける問題の約60%を解決します。30秒で済みます。他の何をするよりも先にこれをやってください。
ハイドレーションの代償：Core Web Vitalsが低下している理由
完全なSSRと完全なクライアントサイドハイドレーションは、注意しないと両世界の悪いところです。完全なHTMLドキュメントを送信し、ブラウザが視覚的にそれをレンダリングしてから、React（またはVue、または何か）が起動してDOMを「引き継ぎます」。そのテイクオーバー――ハイドレーションフェーズ――の間、ページは視覚的にはインタラクティブですが、機能的には凍結しています。クリックが登録されません。フォームが送信されません。
これはTotal Blocking TimeとINPスコアを殺すものです。SSR化されているがクライアント側の大規模なバンドルを持つNext.jsサイトで常にそれを見ます。Reactチームの独自のServer Componentsのドキュメンテーションは、より多くのロジックをサーバー上に保ち、ブラウザにより少ないJavaScriptを送信することによってこの問題を減らすことを特に設計されています。React team's own documentation on Server Components is specifically designed to reduce this problem by keeping more logic on the server and shipping less JavaScript to the browser.
実践的な対策：next build の出力や Bundle Phobia を使って JavaScript バンドルを監査してください。何が大きいのかを特定し、それが本当にクライアントバンドルに含まれる必要があるのかを検討します。昨年、3つのデータ取得ライブラリをサーバーのみに移動し、server-only パッケージインポートを使用することで、クライアントのバンドルから 180KB を削減しました。彼らの INP は 340ms から 190ms に短縮されました。これは単なる UX 改善ではなく、ランキングシグナルの改善です。next build output or Bundle Phobia. Find what's large and ask whether it needs to be in the client bundle at all. I cut 180KB from a client's bundle last year just by moving three data-fetching libraries to server-only and using server-only package imports. Their INP went from 340ms to 190ms. That's a ranking signal improvement, not just a UX improvement.
レンダリングモード決定フレームワーク
推測を止めてください。ここが私の判断方法です：
- Googlebotはこのページを見る必要がありますか？いいえの場合――CSRを使用して、完了です。
- コンテンツが1日に複数回変わるか？変わらなければ、SSGを使用する。
- コンテンツが頻繁に変更され、かつGooglebotがそれを認識する必要がありますか？ 古さの許容度が存在すればISRを、存在しなければSSRを使用してください。
- ページが高度にインタラクティブで、コンテンツが最小限ですか？ SSGシェルを備えたCSRを使用してください。
- サーバー予算に制約がありますか？ SGとスタティックをできるだけ優先してください。
このフレームワークは約90%のケースに対応している。残りの10%はエッジケース――ログイン中のユーザー向けの個人化コンテンツで、かつSEOが必要な場合（e-commerceの公開ページにおける「あなた向けおすすめ」のようなもの）であり、通常はハイブリッドアプローチが必要になる。つまり、SSRでコンテンツの骨組みをレンダリングし、ハイドレーション後にクライアント側で個人化を追加する。
---
FAQ
Googlebotは2026年にJavaScriptを完全にレンダリングしますか？
JavaScriptをレンダリングするが、初回クロールより数時間から数日遅れる二次波となる。インデックス化に重要なコンテンツ――本文、タイトル、メタタグ――は初回HTMLレスポンスに含めるべき。GooglebotのレンダリングキューにSEOランキングを賭けるな。
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は、フルサーバーレンダリングHTMを経てハイドレーションするオーバーヘッドなしで、公開ページで動的データが必要なときに活躍する。両者は同じものではなく、正しい選択はコンテンツがどの程度動的かにかかっている。
---
率直な結論：Googlebot は2019年より賢くなったが、Chromeではない。二波レンダリングモデル、クロールバジェット制約、ハイドレーションコストは、「SSRを使っている」というだけではJavaScript SEO戦略として不完全――単なる出発点だ。各レンダリングモードの代償を知り、構築前に監査し、Googlebot が訪問しないページへのSSRデフォルト化をやめろ。Seahawk Mediaで私が最も誇りに思っているサイトは、最も洗練されたレンダリングパイプラインを使っているものではない。必要な分だけ、あるいはそれより少なく、正確にレンダリングされたサイトだ。exactly as much as it needed to be, and no more.