シングルページアプリケーションのSEO：SPAをGoogleにインデックスさせ、AIに読ませる方法

シングルページアプリケーションのSEOとは、React、Vue、Angular、Svelteで構築したJavaScriptアプリを、従来型のWebサイトと同じくらいクロールしやすくするための一連の手法です。この問題は広く知られています。GoogleはJavaScript SEOの基本で、JavaScriptページを3つのフェーズ（クロール、レンダリング、インデックス登録）で処理すると説明しており、SPAの弱点はすべてこの流れのどこかにあります。このガイドはSPAに焦点を当てています。JavaScriptサイト全般については、JavaScript SEOのガイドをご覧ください。

シングルページアプリケーションとは何か、なぜSEOが難しいのか？

従来のWebサイトは、URLごとに完全なHTMLドキュメントを返します。SPAはどのURLに対してもほぼ同じドキュメントを返します。空の<div id="root">、いくつかのmetaタグ、そして大きなJavaScriptバンドルです。ブラウザがバンドルをダウンロードし、APIを呼び出してから、ページを描画します。訪問者がリンクをクリックすると、JavaScriptがページを再読み込みせずにコンテンツを入れ替えます。

高速なスマートフォンを使う人にとっては、一瞬で表示されるように感じます。しかしクローラーにとって、最初のレスポンスは空のシェルです。見出しも、テキストも、リンクもありません。すべては、ボットがJavaScriptを実行するかどうか、そしていつ実行するかにかかっています。この1つの事実が、SPAのSEO問題のほとんどを説明します。

• コンテンツの遅延や欠落：テキストはレンダリング後にしか存在せず、Googleはそのレンダリングを後回しにし、他のボットは省略します。
• 複数の画面に1つのURL：古いSPAはフラグメント（/#/pricing）でルーティングしますが、#以降の部分はサーバーに送信されないため、すべての画面が1つのURLにまとまってしまいます。
• 同一のタイトルとディスクリプション：シェルには<title>が1つしかなく、ルーターが更新しなければ全ページで共有されます。
• hrefのないリンク：ボタンやonClickハンドラーはユーザーを遷移させますが、クローラーがたどれるものは何も残しません。
• ソフト404エラー：存在しないページを含むすべてのパスにサーバーが200を返すため、エラー画面が低品質なページとしてインデックスされます。
• 重いJavaScript：大きなバンドルは初回表示と操作への反応を遅くし、Core Web Vitalsを悪化させます。

GoogleはSPAをどのようにクロールし、レンダリングするのか？

Googlebotはまず生のHTMLを取得し、そこにあるリンクと指示を読み取ります。200ステータスを返したページは、ヘッドレスChromiumであるWeb Rendering Serviceのキューに入れられます。Googleによると、ページは「このキューに数秒間とどまることもありますが、それ以上かかる場合もあります」。レンダリング後、生成されたHTMLがコンテンツとリンクのために再度解析され、インデックスに登録されます。

Googleのドキュメントのうち、SPAにとって重要な点は4つです。

1. hrefを持つ<a>要素だけが確実なリンクです。JavaScriptで挿入されたリンクも、この形式に従っていれば問題ありません。
2. フラグメントは別ページではありません。Googleは#ルートではなくHistory API（pushState）を使うよう求めています。旧来のAJAXクロールスキーム（#!のURL）は2015年10月に非推奨となりました。
3. 元のHTMLにあるnoindexが優先されます。Googleはnoindexを見つけるとレンダリングを省略することがあるため、後からJavaScriptで削除しても効果はありません。
4. レンダリングにはキャッシュされたファイルが使われます。GooglebotはJavaScriptとCSSを積極的にキャッシュするため、古いバンドルを避けるにはフィンガープリント付きのファイル名（ファイル名にコンテンツのハッシュを含める）を使いましょう。

実務上の結論はこうです。GoogleはクライアントサイドレンダリングのSPAもインデックスできますが、すべてのページに2つ目のステップ、遅延、障害点が加わります。レンダリング中のタイムアウト、ブロックされたAPI呼び出し、JavaScriptエラーがあれば、インデックスされるバージョンは空になります。Googleに何が見えているかはSearch ConsoleのURL検査ツールで確認し、ページがインデックスされないままならGoogleのインデックス登録の仕組みに関するガイドをお読みください。

ChatGPT、Claude、PerplexityはJavaScriptを読むのか？

ほとんど読みません。VercelとMERJは、Vercelのネットワークのトラフィックをもとに2024年12月に公開した調査で、「主要なAIクローラーはいずれも、現時点でJavaScriptをレンダリングしていない」ことを明らかにしました。GPTBot、OAI-SearchBot、ChatGPT-User（OpenAI）、ClaudeBot（Anthropic）、PerplexityBot、Meta-ExternalAgent、Bytespiderは、いずれも生のHTMLしか読みません。JavaScriptファイルをダウンロードはしますが（ChatGPTのリクエストの約11.5%、Claudeの約23.8%）、実行はしません。例外は、Googleのレンダリング基盤を利用するGeminiと、ブラウザベースのクローラーを使うAppleBotです。

つまりクライアントサイドレンダリングのSPAでは、ChatGPT、Claude、Perplexityにデータを供給するAIクローラーには空のページしか見えません。あなたの製品がGoogleで上位表示されていても、AIの回答にはまったく現れないことがあります。アシスタントがその内容を一語も読んでいないからです。SNSやメッセージアプリのリンクプレビュー用ボットの多くも同様で、生のHTMLにあるOpen Graphタグを読み取ります。コンテンツがHTMLに含まれたら、robots.txtで必要なAIクローラーを許可しているかも確認しましょう。

SPAはどのレンダリング戦略を選ぶべきか？

解決策は、最初のレスポンスで本物のHTMLを送ることです。Googleはダイナミックレンダリングのドキュメントで、ダイナミックレンダリング（プリレンダリングしたバージョンをボットだけに配信する方法）を「回避策であり、推奨される解決策ではありません」としており、代わりにサーバーサイドレンダリング、静的レンダリング、ハイドレーションを勧めています。以下の定義は、web.devのリファレンス記事Rendering on the Webに基づいています。

最近のフレームワークの多くは、ルートごとに戦略を組み合わせられます。マーケティングページは静的に、カタログはサーバーでレンダリングし、ログイン後のアプリはクライアントでレンダリングする、といった具合です。このハイブリッド構成なら、検索流入がある場所ではクローラーに完全なHTMLを渡し、SPAの体験が価値を生む場所ではそれを維持できます。

フレームワーク別の選択肢

AIによるWebサイトビルダーで生成されたサイトには特に注意が必要です。その多くは、クライアントサイドレンダリングのReactアプリを出力します。こうしたツールでサイトを作った場合は、GoogleやChatGPTが読めると決めつける前に、LovableのSEOとGEOに関する解説をご覧ください。

SPAのSEOチェックリスト：ルートごとに直すべきこと

1. すべての画面に、クロール可能できれいなURLを与える

History APIを使い（/pricingとし、/#/pricingは使わない）、1つのコンテンツに1つのURLを割り当て、訪問者が直接アクセスしてもアプリ内の遷移で来ても同じURLにします。どのURLも新しいタブで開いたときに正しいコンテンツを読み込む必要があります。これこそがクローラーの行うテストです。

2. 本物のリンクを使う

インデックス対象のページへ移動するナビゲーション要素は、すべて<a href="/path">にすべきです。フレームワークのリンクコンポーネント（Link、NuxtLink、routerLink）はこのマークアップを出力しますが、divやbutton要素に付けた独自のクリックハンドラーは出力しません。適切なリンクはサイト構造も伝えます。リンクされていないページは、クローラーにほとんど見つけてもらえません。

3. ルートごとにタイトル、ディスクリプション、canonicalを更新する

各ルートには固有のタイトル、メタディスクリプション、canonical、Open Graphタグが必要で、可能な限りサーバー側で生成します。設定すべき項目はmetaタグのページにまとめています。canonicalタグは1つだけにしてください。GoogleはHTML内で設定することを推奨しており、JavaScriptで変更する場合も、元の指定と矛盾してはいけません。

4. 正直なステータスコードを返す

存在しない商品や削除された記事が、エラーメッセージ付きで200を返してはいけません。SSRなら、サーバーから本物の404または410を返します。純粋なSPAでは、Googleは2つの代替策を認めています。404を返すURLへJavaScriptでリダイレクトするか、エラー画面にnoindexのrobots metaタグを追加するかです。

5. メインコンテンツと構造化データをHTMLに含める

見出し、本文、価格、よくある質問、JSON-LDの構造化データは、クリックやスクロールの後に読み込むのではなく、サーバーのレスポンスに含めるべきです。必要に応じてレンダリングされるタブの中や、「もっと見る」ボタンの後ろにあるコンテンツは、見落とされることがよくあります。

6. JavaScriptを軽く保つ

ルートごとにバンドルを分割し、最初の画面に不要なものは遅延させ、ハイドレーション中にページ全体を再レンダリングしないようにします。なお、Chromeのフィールドデータ（CrUX）は、アプリ内遷移の指標を訪問者が最初に読み込んだURLに割り当てるため、主要なテンプレートは個別にテストしてください。

7. ボットが受け取る内容をテストする

主要なテンプレートごとに、3つのバージョンを比較します。生のHTML（ソースを表示するか、コマンドラインツールでページを取得）、GoogleがレンダリングしたHTML（URL検査から「クロール済みのページを表示」）、そしてJavaScriptを無効にしたページです。メインのテキストが2つ目のバージョンにしか現れないなら、AIクローラーには見えていません。無料のAI向けクローラビリティ監査とインデックス可能性チェッカーで、任意のURLに対してこれらのチェックを実行できます。

SPAにSEOの問題があるかどうかを見分けるには？

SPAのSEOとGEO：Googleで見つかり、AIに引用されるために

長年、クライアントサイドレンダリングは管理可能なリスクでした。Googleが最終的にはJavaScriptをレンダリングしていたからです。しかし今では情報探索の一部がChatGPT、Claude、Gemini、Perplexityで行われており、そのコストは変わりました。JavaScriptの実行後にしか存在しないページは、ほとんどのアシスタントが読める情報源から抜け落ちてしまいます。生のHTMLにおけるクローラビリティは、生成エンジン最適化の第一条件になりました。

HTMLが完全になれば、あとは通常のルールに従います。1つの質問に明確に答え、出典のある事実と構造化データを備えたページこそ、アシスタントが引用するページです。SorankのGEO最適化機能はそうしたコンテンツの執筆と公開を支援し、AIメンション追跡は、レンダリングの修正後にChatGPT、Claude、Geminiがあなたのブランドを引用しているかどうかを示します。

シングルページアプリケーションのSEOの鉄則は、1文にまとめられます。GoogleにランクづけさせたいものやAIに引用させたいものは、すべてサーバーが送るHTMLに含めなければならない。SPAはログイン後の体験に使い、公開ページはサーバー上またはビルド時にレンダリングし、リリースのたびに、その前後でボットが受け取る内容をテストしましょう。