JavaScript SEOとレンダリング方式の選び方｜SPAサイトが検索で評価されない理由と対処【2026年版】

React、Vue、Next.js、Nuxt——モダンなフロントエンドで構築したサイトが、コンテンツの質は悪くないのに検索流入だけ伸びない。この相談は年々増えています。

JavaScript SEOと呼ばれる領域は、話を広げるといくらでも複雑になりますが、実務上の論点はほぼ1つに集約されます。サーバーが最初に返すHTMLに、主要コンテンツとリンクが入っているかどうかです。入っていれば、多くのサイトで追加の対応は要りません。入っていなければ、どれだけコンテンツを足しても評価は安定しません。

本記事では、その判定を1分で行う方法から始めて、なぜCSR(クライアントサイドレンダリング)だけだと不利になるのか、CSR/SSR/SSG/ISRをどう選ぶのか、そして数万〜数十万ページ規模のサイトでどう段階的に移行するのかを、開発チケットに落とせる粒度まで書きます。

なお本記事は、データベース型サイトのSEO完全ガイドの「クロールを通す」レイヤーの詳細版です。DB型サイト全体の設計から知りたい方は親記事を先にご覧ください。

0. まず1分で自己診断する

対応が必要かどうかは、ブラウザだけで判定できます。ツールもアカウントも不要です。

1. 検索流入を取りたいページ(一覧ページや詳細ページ)をブラウザで開く
2. URLの先頭に view-source: を付けて再読み込みする。例: view-source:https://example.com/jobs/sales/osaka/
3. 表示された生HTMLの中を Ctrl + F(Mac は Cmd + F)で検索する

見るのは次の2点です。

両方が含まれていれば、レンダリング方式に起因するSEO問題は基本的にありません。この記事の5章(SSR/SSGでも解決しない落とし穴)だけ確認して、他の施策に進んでください。

含まれていない——<div id="root"></div> とスクリプトタグしかない、リンクが1本も見つからない——という場合は、対応が必要です。以降の章がその手順になります。

なお view-source: の代わりに開発者ツールの「Elements」パネルを見てはいけません。あれはJavaScript実行後のDOMであり、Googleが最初に受け取るHTMLとは別物です。必ず view-source:、もしくは curl の出力で確認してください。

# コマンドラインで確認する場合
curl -sL "https://example.com/jobs/sales/osaka/" | grep -o "<a href=[^>]*>" | head -50

リンクが数本しか出てこない、あるいはナビゲーション部分しか出てこないなら、クローラーから見たそのページは「ほぼ空」です。

1. なぜCSRだけだと不利なのか

まず前提を正確にしておきます。GoogleはJavaScriptを実行します。 「GoogleはJSを読めない」という説明を見かけますが、これは誤りです。Googlebotは最新版に追従したChromiumでページをレンダリングし、JavaScriptで描画されたコンテンツも評価対象にできます。

問題は「できるかどうか」ではなく、いつ・どれだけの規模で行われるかです。

処理が2段階に分かれている

Googleのページ処理は、大きく2つの段階に分かれています。

1. クロール(HTML取得):サーバーからHTMLを取得する。ここで得られた内容はすぐに解析される
2. レンダリング:取得したHTMLをレンダリング用のキューに入れ、順番が来たらJavaScriptを実行してDOMを完成させる

CSRのみのサイトでは、1の段階でほぼ何も情報がありません。コンテンツもリンクも、2が完了して初めて認識されます。そしてレンダリングは即座に行われるとは限らず、リソースの空き状況に応じて後回しになることがあります。数分で処理されることもあれば、それ以上待たされることもあり、タイミングをサイト側でコントロールできません。

これが「評価されるかどうかがGoogleの都合次第になる」という状態です。

ページ数が増えるほど不利になる

ここがデータベース型サイトで致命的になる理由です。

レンダリングはHTML取得よりも重い処理です。ブラウザを起動し、JSをダウンロードして実行し、必要ならAPIリクエストの結果を待つ必要があります。1ページあたりのコストが高いということは、ページ数が多いサイトほど、全ページを回し切るのに必要な総コストが跳ね上がるということです。

5,000ページのコーポレートサイトなら、CSRでも実務上ほとんど困りません。しかし30万ページの求人サイトで同じ構成を取ると、次のような症状が出ます。

• 新規追加ページのインデックス登録が遅い(公開から検索に出るまでが長い)
• 更新した内容が検索結果のスニペットに反映されるまで時間がかかる
• 一部のテンプレートだけインデックス率が極端に低い
• Search Consoleの「検出 - インデックス未登録」が積み上がる

さらに悪いことに、リンクもレンダリング後にしか現れないため、クローラーが次のページを発見すること自体が遅れます。発見が遅れる → クロールが進まない → レンダリングも進まない、という連鎖が起きます。ページ数が多いサイトほど、この連鎖の影響が大きくなります。

Googlebotが「やらないこと」を前提にする

もう1つ、CSR特有の落とし穴があります。Googlebotは人間のユーザーとは振る舞いが違います。

• クリックしない:ボタンやタブのクリックで初めて読み込まれるコンテンツは取得されません
• スクロールしない:スクロール到達で追加読み込みされるコンテンツは取得されません
• フォームを送信しない:検索フォームの先にしかないページは発見されません
• ページ間で状態を保持しない:ページ読み込みごとに状態はリセットされる前提で設計されており、localStorageやセッションに依存した表示は再現されません

「ユーザーがブラウザで見れば正しく表示される」ことは、クローラーが同じものを見ている保証になりません。CSRのサイトでは、この差が本文まるごとの欠落になり得ます。

2. 診断手順:5つのチェック

0章の view-source: で黒判定が出たら、次の5つで症状を確定させます。上から順に、5〜10分で終わります。

チェック1:生HTMLの中身(view-source:)

0章のとおりです。加えて、テンプレートごとに1枚ずつ見てください。サイト全体で1つの方式とは限りません。 トップページだけSSRで、一覧ページと詳細ページはCSR、という混在構成は珍しくありません。DB型サイトなら最低限、トップ／一覧／詳細／検索結果の4種を個別に確認します。

チェック2:Search ConsoleのURL検査

Search Consoleで対象URLを検査し、「公開URLをテスト」を実行したあと、「テスト済みのページ」を開きます。ここで確認できるのは3つです。

• HTML:Googleがレンダリングした後のHTML。ここに主要コンテンツが出ていれば、レンダリングは成功している
• スクリーンショット:Googleが見た画面。真っ白、あるいはローディング表示のままなら明確な異常
• その他の情報 > ページのリソース／JavaScriptコンソールメッセージ:読み込めなかったリソースやJSエラーが出る

「読み込めなかったリソース」が最も情報量の多い項目です。 robots.txtでJSファイルやAPIエンドポイントをブロックしていると、ここに出ます。この場合、Googleはページを組み立てられません。DB型サイトで「なぜか一部テンプレートだけ評価されない」という症状の原因が、/api/ を Disallow していたこと、というケースは実際にあります。

なお、URL検査のテストは実際のインデックス処理より条件が良い(その場で優先的にレンダリングされる)ため、ここで正しく見えていても「本番のインデックスでも常に成功している」ことの証明にはなりません。テストが失敗していれば確実に問題あり、成功していても大規模サイトでは1章の遅延の問題が残る、という読み方をしてください。

チェック3:リッチリザルトテスト

構造化データを実装している場合は、リッチリザルトテストでレンダリング後のHTMLを確認します。JSで後から挿入している構造化データは、ここで検出されないことがあります。検出されなければ、リッチリザルトの対象外です。

チェック4:JavaScriptを無効にして表示する

ブラウザの開発者ツールからJavaScriptを無効化し、対象ページを再読み込みします。これは厳密にはGooglebotの挙動と同じではありませんが(Googleはレンダリングするため)、「JSなしで何が残るか」を視覚的に把握するのに最も速い方法です。真っ白になるなら、生HTMLは空だということです。

チェック5:サーバーログでクロール到達を確認する

最終確認はサーバーログです。Googlebotのアクセスログを抽出し、テンプレート別にクロール数を集計します。

見るべきは2点です。

• 主要テンプレートのURLに、そもそもGooglebotが到達しているか
• JSファイル・APIエンドポイントへのGooglebotのリクエストが発生しているか(していれば、レンダリングは試みられている)

「一覧ページには来ているが、詳細ページには月に数回しか来ていない」という配分が見えたら、それがそのままインデックス率の低さの説明になります。ログ分析はDB型サイトの診断で最も情報量の多い作業です。

3. レンダリング方式の選択肢と選び方

診断で対応が必要と分かった場合の選択肢です。

5つの方式の比較

動的レンダリングを最初から選択肢から外す理由

動的レンダリングは、ユーザーには従来どおりCSRで返し、クローラーだと判定したリクエストにだけレンダリング済みHTMLを返す方式です。既存実装を大きく変えずに済むため一時期は広く使われましたが、Googleはこれを恒久的な解決策ではなく回避策(workaround)と位置づけており、長期的な推奨構成としていません。

実務上の理由も揃っています。

• ユーザー向けとクローラー向けで2系統の出力を維持することになり、内容がズレたときに検知できない(そしてズレは必ず起きます)
• レンダリング用の中間サーバーが単一障害点になる。ここが落ちるとクローラーにだけ壊れたページが返る
• User-Agentによる出し分けであるため、実装を誤るとクローキングと判定されるリスクを常に抱える

既にこの構成で動いていて安定しているなら即座に剥がす必要はありませんが、これから新規に選ぶ理由はありません。 同じ工数を使うなら、SSRまたはISRに投資したほうが将来の負債になりません。

判断軸は4つ

方式選定は好みではなく、次の4つで機械的に決まります。

実務でのおおまかな結論はこうなります。更新頻度が「日単位」以下で、ページ数が数万を超えるDB型サイトは、ISRが最も費用対効果が高い選択です。 一覧ページは数分〜数時間のキャッシュで十分成立し、詳細ページは更新時にオンデマンドで再生成すればよいためです。

一方、価格や在庫が分単位で変わり、それがそのまま検索結果のスニペットに影響する事業(航空券、宿泊、リアルタイム在庫のEC)は、主要テンプレートをSSRにする合理性があります。

4. DB型サイトでの現実的な移行戦略

ここが投資判断で最も詰まる部分です。結論から書きます。全ページ一斉に移行してはいけません。

全ページ一斉が失敗する理由

数十万ページのサイトを一度にSSR化しようとすると、次の3つが同時に起きます。

• 見積もりが半年単位になり、経営判断が下りずに企画ごと止まる
• 影響範囲が全ページのため、リリース時の事故がそのまま全ページに波及する
• 効果が出るまで何も検証できず、途中で優先度を落とされる

テンプレート単位で、流入の主戦場から

正しい進め方は、親記事で解説したテンプレート分解を先に行い、流入の主戦場となるテンプレート1つだけを対応することです。

優先順位のつけ方は次のとおりです。

1つ目のテンプレートを対応したら、インデックス率とクロール数の変化を2〜4週間観測してから次に進みます。ここで数字が動けば、以降の投資判断は圧倒的に通りやすくなります。動かなければ、原因はレンダリングではなく別のレイヤー(コンテンツの薄さなど)だったということで、これも大きな情報です。

段階移行を可能にする実装上の前提

テンプレート単位の段階移行は、フレームワークがページ単位でレンダリング方式を切り替えられることが前提です。Next.jsやNuxtのようなフレームワークはこれを標準機能として持っています。逆に、素のReact/Vueで独自にルーティングを組んでいる場合は、まずフレームワークへの載せ替えが必要になり、見積もりが一段上がります。この差は初期の見積もり段階で開発チームに確認しておいてください。

5. SSR/SSGにしても解決しない落とし穴

レンダリング方式を変えても、以下が残っていると成果は出ません。順に確認してください。

落とし穴1:リンクがaタグではない

最頻出です。onClick でJavaScriptのルーターを呼ぶだけの実装は、Googlebotから見るとリンクが存在しません。

<!-- 辿られない -->
<div onclick="router.push('/jobs/sales/osaka/')">大阪の営業求人</div>
<button onclick="goTo('/jobs/sales/osaka/')">大阪の営業求人</button>

<!-- 辿られる -->
<a href="/jobs/sales/osaka/">大阪の営業求人</a>

要件は「遷移先を持つUI要素は、必ず href 属性を持つ a タグで実装する」です。クリック時の挙動をJSで制御すること自体は問題ありません(SPAの高速遷移は維持できます)。href が生HTMLに存在していることが条件です。

落とし穴2:無限スクロールでリンクが存在しない

一覧ページの無限スクロールは、UXとしては優れていてもクローラーには不可視です。Googlebotはスクロールしないため、2ページ目以降のコンテンツにもリンクにも到達できません。

打ち手は、無限スクロールを維持したまま ?page=2 形式のページネーションリンクをHTML内に併存させることです。実装としては、無限スクロールで追記していくのと同時に、ページ送りの a タグを(視覚的に控えめでも)出力しておく形になります。UXを変えずにクロール経路だけを確保できるため、費用対効果の高い改修です。

落とし穴3:canonicalやmetaをJSで後から書き換えている

SPAでルーティングするときに、document.title や <link rel="canonical">、meta robots をJavaScriptで差し替える実装がよくあります。これは危険です。

• meta robots の noindex:生HTMLに noindex が入っていると、Googleはその時点で処理を打ち切り、レンダリングをスキップすることがあります。つまり「生HTMLではnoindex、JSで外す」実装は、外される前に判断されて終わります。これは方向として最も事故が大きいパターンです
• canonical:JSで挿入したcanonicalが読まれることはありますが、確実ではありません。生HTMLに1本だけ正しい値を出力するのが唯一の安全な実装です
• title / description:レンダリング後の値が使われることもありますが、初回HTMLの値が使われる場合との差異が検索結果のブレとして現れます

要件は「canonical・meta robots・title・descriptionは、サーバーが返す初回HTMLの中で確定させる。JSで書き換えない」です。

落とし穴4:ソフト404

SPAでは、存在しないURLに対してもルーターが200 OKで「見つかりませんでした」という画面を返してしまいがちです。Googleから見ると「200が返る有効なページ」であり、これが数千ページ積み上がると、薄いページの塊としてサイト全体の評価に影響します。

要件は「該当データが存在しない場合、サーバーが404(または410)のステータスコードを返す」です。画面の見た目ではなく、HTTPステータスコードが判定対象です。ブラウザの開発者ツールのNetworkタブか curl -I で確認できます。

# ステータスコードだけ確認する
curl -sI "https://example.com/jobs/does-not-exist/" | head -1

落とし穴5:URLがハッシュフラグメント(#)で分かれている

https://example.com/#/jobs/sales/osaka/ のように、# 以降でページを切り替えている構成です。# 以降はサーバーに送信されず、Googleは原則としてURLの一部として扱いません。 この構成では、全ページが https://example.com/ という1つのURLとして認識されます。何ページ作っても、検索対象は1ページです。

かつて存在した #! を使うクロール方式は既に廃止されています。対応は、History API を使った通常のパスベースのURL(/jobs/sales/osaka/)への移行一択です。移行時は旧URLからのリダイレクトが # 以降を扱えない点に注意が必要なため、切り替えのタイミングでの被リンク・流入の引き継ぎ方を事前に設計してください。

6. 開発チームへの依頼粒度

JavaScript SEOの施策は、100%が実装依頼になります。ここで粒度を誤ると、着手されないか、範囲が広がって事故になります。

必要な要素は対象・条件・実装・対象外・検証の5点です。

【対象】/jobs/{職種}/{地域}/ 一覧テンプレート（約8,000ページ）
【条件】全リクエスト（ログイン状態・非ログイン状態を問わない）
【実装】
  - サーバーサイドで求人一覧データを取得し、初回HTMLに以下を含めて返す
    ・求人カード（求人タイトル・企業名・勤務地・給与）を1ページ分すべて
    ・各求人詳細への <a href="/jobs/{id}/"> リンク
    ・ページネーションの <a href="?page=N"> リンク（無限スクロールと併存）
  - <link rel="canonical"> をパラメータ除去後のURLで初回HTMLに出力
  - キャッシュ: ISR、再検証間隔 600秒
【対象外】
  - /mypage/ 配下、/admin/ 配下（検索流入対象外のためCSRのまま）
  - 絞り込みパラメータ（experience / salary）付きURLは本チケットの範囲外。別途判断
【検証】
  - curl で取得した生HTMLに求人タイトルが20件分含まれること
  - 生HTML中の <a href> が該当ページの求人件数＋ページネーション分だけ存在すること
  - Search Console のURL検査「テスト済みのページ」で読み込めなかったリソースが0件
  - ステージングで先行確認したうえで、本番は当該テンプレートのみ先行リリース

「対象外」を明記することが特に重要です。 これがないと、開発側が善意で範囲を広げ、SSRが不要なページまで対象に入って見積もりが膨らむ、あるいはリリースの影響範囲が想定外に広がります。

落とし穴系の修正は、もっと小さい単位でチケットにできます。

【対象】全テンプレートの遷移用UI要素
【条件】クリックでページ遷移が発生するすべての要素
【実装】onClick のみで遷移している div / button / span を、href 属性を持つ a タグに置換する
　　　　（クリック時のクライアントサイド遷移の挙動は現状維持でよい）
【対象外】モーダル開閉・タブ切り替えなど、ページ遷移を伴わないUI
【検証】主要5テンプレートについて、curl で取得した生HTMLに含まれる <a href> の本数を
　　　　改修前後で比較し、画面上のリンク数と一致すること

見積もりを取るときは、SEO側のインパクトだけで優先順位を作らず、開発工数と並べて開発チームと一緒に順序を決めてください。実装3ヶ月の施策が最上位に来ると、実行そのものが止まります。

7. 実例:HTML段階で1割しか読めなかったプラットフォーム

当社が診断した荷物預かりプラットフォームでは、HTMLの段階で読み取れるコンテンツが全体の1割程度しかない状態でした。残り9割はレンダリング頼み——つまり、評価されるかどうかがGoogleの処理タイミング次第という状態です。

このサイトで実際に起きていたのは、単に「順位が低い」ではありませんでした。生HTMLにリンクがほとんど存在しなかったため、内部リンク構造そのものがクローラーから見えていない、という状態です。ページは存在するのに、そこへ辿り着く経路が無い。サイトマップに載せていても、リンクによる評価の受け渡しが発生しないため、個々のページが孤立します。

このケースで最初に着手したのは、全面的なSSR移行ではなく、4章で書いた優先順位のとおり検索流入の主戦場となるテンプレートの生HTML出力と、生HTML中のaタグの確保です。「レンダリング方式を変える」という大きな意思決定の前に、リンクをaタグにするという小さな改修だけでクローラーの到達範囲が変わる余地が残っていることは珍しくありません。

診断でこの状態が判明したことの価値は、それまで検討されていた施策(コンテンツ追加)が無意味だと確定したことにあります。生HTMLが空のままコンテンツを増やしても、評価の土台が無いところに積むことになります。順序を間違えないための診断です。

8. よくある質問(FAQ)

Q. GoogleはJavaScriptを実行できるのに、なぜSSRが必要なのですか? A. 実行できることと、全ページを安定して処理してくれることは別だからです。レンダリングは初回のHTML取得とは別のキューで行われ、タイミングをサイト側で制御できません。数千ページ規模なら実務上ほとんど問題になりませんが、数万〜数十万ページ規模では、インデックス登録の遅れやテンプレート単位でのインデックス率低下として表面化します。ページ数が多いほどSSR/ISRの投資対効果が上がる、という関係です。

Q. 自社サイトが対応必要かどうか、最短で判断するには? A. view-source: を付けてページを開き、主要な本文テキストと <a href> リンクが生HTMLに含まれているかを確認してください(0章)。含まれていれば対応不要です。開発者ツールのElementsパネルはJS実行後のDOMなので判定に使えません。必ず view-source: か curl で確認します。

Q. 動的レンダリングで対応してもよいですか? A. 新規に選ぶ方式としては推奨しません。Googleは動的レンダリングを恒久的な解決策ではなく回避策として位置づけています。ユーザー向けとクローラー向けで出力が2系統に分かれるため内容のズレを検知しにくく、レンダリング用サーバーが単一障害点にもなります。既に安定運用しているものを急いで剥がす必要はありませんが、これから工数をかけるならSSRまたはISRに投資するほうが将来の負債になりません。

Q. SSRとSSG、ISRのどれを選ぶべきですか? A. ページ数・更新頻度・開発リソース・インフラコストの4軸で決まります(3章)。更新が日単位以下でページ数が数万を超えるデータベース型サイトは、ISRが最も費用対効果の高い選択になることが多いです。価格や在庫が分単位で変わり、それが検索結果の表示内容に直結する場合は、主要テンプレートをSSRにする合理性があります。ページ数が数百規模で更新頻度も低ければ、SSGで十分です。

Q. SSR化したのに順位が上がりません。何が起きていますか? A. レンダリングは前提条件であって、それ自体が順位を上げる施策ではありません。SSR化で「評価の土俵に乗る」ところまでは進んだので、次はテンプレートの中身(title生成ルール、一覧ページの独自情報、内部リンク設計)の問題です。加えて、5章の落とし穴——リンクがaタグでない、canonicalをJSで書き換えている、ソフト404が大量にある——が残っていないかを先に確認してください。SSR化しても、これらは自動的には解決しません。

まとめ:判断のフロー

1. view-source: で生HTMLを見る(0章) — 主要コンテンツとリンクが含まれていれば対応不要
2. 5つのチェックで症状を確定する(2章) — 特にSearch Consoleの「読み込めなかったリソース」
3. 4つの判断軸で方式を選ぶ(3章) — ページ数・更新頻度・開発リソース・インフラコスト。動的レンダリングは選ばない
4. 主戦場テンプレート1つから段階移行する(4章) — 全ページ一斉は企画ごと止まる
5. 落とし穴を潰す(5章) — aタグ、無限スクロール、JSでのmeta書き換え、ソフト404、# URL
6. 5点セットで開発に依頼する(6章) — 対象・条件・実装・対象外・検証

JavaScript SEOは、突き詰めると「クローラーに何を渡しているか」の設計です。渡せていないものは評価されず、渡せてさえいれば、あとは通常のSEOの勝負に戻ります。逆に言えば、ここが壊れているサイトでコンテンツ施策に投資しても回収は見込めません。順序の問題として扱うのが正解です。

サイト全体の設計から整理したい方は、データベース型サイトのSEO完全ガイドで、クロール・インデックス・テンプレート・ページ生成・計測の5レイヤーを解説しています。

自社サイトのどのテンプレートがクローラーから見えていないのか、どこから移行すべきか——具体的な診断をご希望の方は、データベース型サイトSEOコンサルティングのページをご覧いただくか、無料相談をご利用ください。実装可能な要件の粒度までご提案します。

株式会社ハウクレイジー 代表取締役 関口拓人

早稲田大学在学中に月間数千万PVのメディアをゼロから立ち上げ、株式会社ゲームエイトの創業に参画。同社執行役員として月間3億PV規模サイトのSEO・広告事業を統括。業界No.1プログラミングスクールを運営する株式会社インフラトップのCMOを経て独立し、株式会社ハウクレイジーを設立。大規模メディアからデータベース型サイトまで、累計50サイト以上のマーケティング支援を実施。

プロフィール詳細

自社サイトがどのレンダリング方式で配信されていて、Googleに本文が届いているのか。実際にHTMLを取得して診断し、SSR/SSG/ISRのどれに寄せるべきかまでお伝えします。

無料でレンダリング方式の診断を依頼する