SPAはSEOに弱いか｜フレームワーク別整理（Next.js・React Router他）

Next.js や React Router でフロントエンドを組んだあと、「このページソースの出し方は SEO 上問題ないか」という不安を持つことがあります。多くの場合、論点は Next.js や React Router というフレームワーク自体ではなく、そのフレームワークをどのレンダリング方式で使っているかです。

01.結論：弱いのは「CSRだけのSPA」

「Next.js は SEO に強い」「React の SPA は SEO に弱い」という言い方は、どちらも半分だけ正しく、半分は不正確です。実際に効いてくるのはフレームワークの名前ではなく、ページの HTML がいつ・どこで組み立てられるかという一点です。

その「最初の1枚の HTML がどこで作られるか」には、大きく3つのやり方があります。CSR（クライアントサイドレンダリング）は、ブラウザ（クライアント）が JavaScript を実行してその場で HTML の中身を組み立てるやり方です。SSR（サーバーサイドレンダリング）は、サーバーがリクエストのたびに HTML の中身を組み立ててから返すやり方です。SSG（静的サイト生成）は、サイトを公開する前のビルド時に、あらかじめ HTML の中身を作っておくやり方です。

上の図を、今度はクライアント（ブラウザ）とサーバーの間でどんなリクエスト・レスポンスが行き来しているかという角度から見ると、次のようになります。

この軸を踏まえたうえで、まず注意したいのは「React」と「Next.js／React Router」は別レイヤーだという点です。

Next.js も React Router 7 も、何も特別な設定をせず標準の使い方をしていれば、上の図でいう SSR 寄り（サーバー側で本文入りの HTML を組み立ててから返す動作）になります。意図的に CSR だけの構成に寄せない限り、view-source の時点で本文が空になることは多くありません。逆に、データ取得や画面の組み立てをすべてブラウザ側の JavaScript に任せる構成にしてしまうと、フレームワークの種類にかかわらず CSR と同じ弱点を抱えます。

もう一つ、SPA でよく心配される点に「ページごとに URL が分かれず、検索エンジンが個別ページを発見できないのでは」というものがあります。これは /#/about のような ハッシュルーティングを使っていた時代の SPA に特有の弱点で、Next.js の App Router（ファイルベースのルーティング）も React Router 7（History API を使ったパスベースのルーティング）も、既定では実在するパス（/products/123 のような形）を使います。ハッシュルーティングをあえて選んでいない限り、この点は心配しなくて構いません。

ここまでの構図は Next.js・React Router 7 に限った話ではありません。主要な UI ライブラリはどれも、単体では CSR（クライアントサイドレンダリング）前提で、SSR（サーバーサイドレンダリング）や SSG（静的サイト生成）を既定にした対応するメタフレームワークが別に存在するという、同じ2階建て構造を持っています（表中の CSR・SSR・SSG もこの略称です）。

フロントエンド全般に共通する、この「ライブラリ単体で組んだか、SSR 既定のメタフレームワークに乗ったか」という選択を踏まえたうえで、ここから先は Google が実際にどう処理しているかを見ていきます。

02.Googlebotが見るのは「レンダリング後のHTML」

Google のJavaScript SEO の基礎によれば、Googlebot は JavaScript を使ったページをクロール → レンダリング → インデックスの3段階で処理します。クロールで生の HTML を取得したあと、レンダリングキューに送られ、実際に Chromium で JavaScript を実行してから、その結果をもとにインデックスします。

重要なのは、レンダリングがクロールと同時に終わるわけではない点です。Google 自身も、レンダリングキューに入ったページは「数秒で処理されることが多いが、それより長くかかることもある」と説明しています。CSR に寄った構成では、この2段階目（レンダリング）が終わるまで、Googlebot にとってページの中身は空に近い状態が続くということです。SSR なら、この2段階目を待たず、1段階目（クロール）の時点ですでに本文が存在します。

03.view-sourceとDevTools「Elements」で見え方が違う理由

Chrome で「ページのソースを表示」（view-source）と、開発者ツールの「Elements（要素）」パネルを見比べると、内容が違って見えることがあります。これは Next.js や React Router 特有の現象ではなく、ブラウザが2種類の異なる情報を表示しているために起きます。

SSR のページでは、view-source の時点ですでに title・h1・本文がテキストとして入っています。そのうえで、hydration に使うデータや、クリックなどの操作をブラウザ側で処理する部品（Next.js では Client Component と呼びます）用の JavaScript も同じ HTML に埋め込まれるため、生のソースを開くと本文と大量の script タグが混在した、読みにくい見た目になります。この「script が多くて読みにくい」状態と、「本文そのものが入っていない」状態は別物です。前者は SSR の正常な出力、後者が CSR 特有の弱点です。

04.Next.js：SEOに強い設定・弱くなる設定

Next.js の App Router は、ファイルに何も指定しなければ、そのページが既定でServer Component（サーバー側で HTML の中身まで組み立てるコンポーネント）として動きます。つまり素直に組むだけで SSR の恩恵を受けられる、という設計です。そのページの SEO が弱くなるのは、次のような組み方で、本来サーバー側で済ませられるはずのデータ取得・描画をクライアント側の JavaScript に寄せすぎたときです。

見落としやすい設定

• title・meta・h1 の値を、マウント後の useEffect 内で API から取得して差し替えている（初回描画では既定値のまま）。
• JSON-LD などの構造化データを、クライアント側のみで生成して head に注入している。
• h1 に相当する見出しが、ローディング表示の裏でクライアント側の状態管理を待ってから描画される。

これらはいずれも画面上は正しく動きますが、Googlebot のレンダリング完了を待つ前提に依存しています。SSR であれば、これらの値はサーバー側ですでに確定しているため、この種のリスク自体が発生しません。

generateMetadataはServer Component専用

Next.js 公式ドキュメント が明記するとおり、静的な metadata オブジェクトや動的な generateMetadata 関数は、Server Component からしかエクスポートできません。 page.tsxの先頭に "use client"を書いてしまうと、同じファイルから metadata をエクスポートできなくなります。

対処はシンプルで、ページのファイル自体はServer Componentのまま残し、クライアント側の処理だけを別ファイルのClient Componentに切り出す構成にします。

// app/products/[id]/page.tsx（Server Component）
import type { Metadata } from "next";
import { InteractiveComponent } from "./interactive-component";

export const metadata: Metadata = {
  title: "商品ページ",
};

export default function Page() {
  return <InteractiveComponent />;
}

// app/products/[id]/interactive-component.tsx
"use client";

export function InteractiveComponent() {
  // クライアント側の状態・イベントハンドラはこちら側に閉じ込める
}

こうすると、page.tsxは Server Component のままなので metadata を宣言でき、インタラクティブな部分だけを Client Component に任せられます。

ストリーミングでmetadataが遅れて届くケース

Next.js は、外部データの取得に時間がかかる generateMetadata について、先に画面本体を送りつつ、metadata タグをあとから body 側に追記する「ストリーミングmetadata」という仕組みを持っています。Next.js の公式ドキュメントは、これがJavaScriptを実行してDOM全体を確認するボット（Googlebotなど）には正しく解釈されることを確認済みとしつつ、facebookexternalhit のようにJavaScriptを実行しないボットには従来どおり待たせる、と説明しています。

つまり Google 向けにはこの仕組み自体が問題になりにくい一方で、SNS のカード表示や一部の外部ツールのように JavaScript を実行しないクローラー向けには、metadata の反映が遅れて見えることがあります。

05.React Router 7：SEOに強い設定・弱くなる設定

React Router 7 は「ライブラリモード」と「フレームワークモード」の2つの使い方があり、どちらを選んでいるかで SEO への強さが変わります。

ライブラリモードとフレームワークモードの違い

react-router パッケージだけを使い、createBrowserRouter でルーティングを組む従来型の使い方（ライブラリモード）は、CSR 前提です。SSR を使いたい場合は、Vite プラグインを使うフレームワークモードを選びます。既定の弱点はここで決まり、ライブラリモードを選んでいる時点で、他の設定に関わらず view-source の時点では本文が空に近い状態になります。

ライブラリモードのまま title・meta を出し分けたい場合、react-helmet-async のようなライブラリで head タグを動的に書き換える方法もよく使われます。ただしこれはあくまで JavaScript 実行後にタグを差し替える仕組みで、view-source の時点では反映されません。CSR の根本的な弱点（本文が生 HTML に無い）を解消するものではなく、フレームワークモードへの移行までの応急処置と考えるのが実態に合っています。

ssr: true / false とprerenderの使い分け

フレームワークモードでは、 react-router.config.tsの ssr オプションで挙動を切り替えます。React Router 公式ドキュメント によれば、既定値は true で、ランタイムでサーバーレンダリングします。

// react-router.config.ts
import type { Config } from "@react-router/dev/config";

export default {
  ssr: true, // 既定値。リクエストごとにサーバーレンダリングする
} satisfies Config;

ssr: false にすると、ランタイムのサーバーレンダリングを止め、事前生成した index.html を配る SPA モードになります。ここで見落としやすいのは、ssr: false にしてもルートルート（レイアウトの最上位）自体はビルド時にサーバーレンダリングされるという点です。つまり view-source を開くと、ルートの title やレイアウト直下の内容は最初から入っていますが、その先の個別ルート（一覧・詳細ページなど）の title や本文は、ハイドレーション後のクライアント側ルーティングで初めて反映されます。

// react-router.config.ts
import type { Config } from "@react-router/dev/config";

export default {
  ssr: false, // ランタイムSSRを無効化し、事前生成したindex.htmlを配るSPAにする
} satisfies Config;

個別ルートまで検索エンジンに認識させたいのに SSR 用のサーバーは持ちたくない、という場合は prerenderオプション を使います。ビルド時に指定パスを静的 HTML 化する仕組みで、ssr の true / false どちらとも併用できます。

// react-router.config.ts
import type { Config } from "@react-router/dev/config";

const slugs = getPostSlugs();

export default {
  prerender: [
    "/",
    "/blog",
    ...slugs.map((s) => `/blog/${s}`),
  ], // 指定パスをビルド時に静的HTML化する
} satisfies Config;

06.よくある失敗

07.よくある質問（FAQ）

08.まとめ

Next.js・React Router 7 の SPA が SEO に弱くなるのは、フレームワーク自体の問題ではなく、CSR だけでページを組んだときです。SSR、React Router 7 の prerender を使っていれば、title・meta・h1・構造化データは最初のレスポンスの時点ですでに文字列として存在します。

フレームワークごとの弱点になりやすいポイントも押さえておきます。Next.js では generateMetadata が Server Component 専用であること、React Router 7 ではライブラリモードかフレームワークモードか・ssr の設定・prerender の対象範囲が、見落としやすい設定です。

リリース前の技術的なSEO診断や、継続的な改善の相談先を探している場合、自社だけで判断を固めるより、レンダリング方式の設計から一緒に見られるパートナーがいると安心です。弊社ではTANTOUというAI活用型の運用代行で、技術的なSEO診断からコンテンツ改善・継続的な計測まで支援しています。