動的ページの schema は SSR で実装するべき:なぜ SPA のルーティング切り替え後に schema
# 動的ページの schema は SSR で実装するべき:なぜ SPA のルーティング切り替え後に schema が消えてしまうのか
あなたがデプロイしたばかりの SPA アプリでは、/about ページに Organization schema を正しく記述し、テスト時には正常に表示されていた。しかし、ユーザーが /service や /contact などのサブページにアクセスし、ブラウザをリロードすると、schema が突然消えてしまう。Google の構造化データチェックツールでもそのデータが検出されず、これらのページは富結果(Rich Results)や AI Overviews に表示されず、ChatGPT による引用も不可能になる。
これはあなたの schema に間違いがあるわけではなく、SPA の動作原理が本来 SEO の原則と矛盾しているからである。Vercel + Next.js + React を使って動的なウェブサイトを構築しようとしている場合は、この記事が「なぜ SPA は SEO の可視性を達成できないのか」、そして「なぜ TrueLink は SSR を AI が信頼する時代の基盤インフラとして堅持しているのか」を理解するためのヒントとなる。
SPA のルーティング設計は、本来 SEO と互換性がない
SPA(Single Page Application)の中心的なロジックは、JavaScript を使ってフロントエンドでコンテンツを動的に読み込むことで、サーバーにリクエストを送ってHTMLを再描画するわけではない。この方法はユーザー体験(UX)に非常に有利で、ページ切り替えがスムーズで高速であるが、SEO にとっては致命的な欠点となる。
SPA の世界では、すべてのルーティング切り替えはブラウザの JavaScript が担当する。ユーザーが /about をクリックした場合、ブラウザは /about 用の HTML ファイルを新たにダウンロードするのではなく、react-router-dom(または類似のルーティングライブラリ)がフロントエンドで画面を更新する。これはサーバーが /about、/service などのルートごとに独立した HTML ファイルを準備していないことを意味し、常に同じ index.html が使用されている。
この構造は致命的な問題を引き起こす:schema.org の構造化データは /about ルートの HTML にのみ固定され、他のサブルートには独立した schema マークアップが存在しない。
もしユーザーがブラウザのアドレスバーに /service を入力し、リロードを実行した場合、サーバー(例:Vercel)は /service.html が存在するかを検索する。しかし、SPA がパッケージングされた後は index.html だけが存在するため、サーバーは該当ファイルを発見できず、404 エラーを返す。その結果、ブラウザはエラーページにリダイレクトされ、コンテンツと schema が瞬時に消えてしまう。
> 📌 出典確認:SPA のルーティング切り替えはブラウザ側の JavaScript が処理しており、サーバーのデフォルト動作はサブルートに404エラーを発生させる。この点は実装済みであり、Vercel のアーキテクチャドキュメントでも明記されている。[9][10]
schema が消えた結果:AI エンジンがあなたのコンテンツを読み取れない
Google、Perplexity、ChatGPT などの AI エンジンは、人間のように「メニューをクリックし、ページを切り替える」ことはせず、URL に対して直接クローリングを行う。もし /service ページに実際の HTML ファイルが存在しない場合、AI エンジンはそのページのコンテンツや schema データを読み取ることができない。
これにより、3つの深刻な結果が生じる:
1. Google 検索結果に富結果(質問、コメントなど)が表示されない:schema が見つからないため。 2. AI Overviews があなたのコンテンツを引用できない:構造化データのソースが見つからないため。 3. ChatGPT が「あなたのブランドを明確に推薦できない」:AI の世界ではあなたのページが存在しないと判断されるため。
今や「SEO が重要かどうか」ではなく、「GEO(生成式検索最適化)」がトラフィックの命運を左右する時代である。もしウェブページが AI エンジンによって読み取られたり、引用されなかったら、それは検索市場で「存在しない」ことと同等である。
なぜ TrueLink は SSR を「デジタル信頼の基盤インフラ」と強調するのか?
TrueLink は単なる SEO ツールではなく、私たちが解決したい根本的な課題は、AI エンジンが「あなたのブランドのコンテンツを信頼し、引用する」方法である。
これを実現するには、以下の2つの前提条件を満たす必要がある:
1. コンテンツが実際に存在し、直接読み取れる(JavaScript で動的に挿入するのではなく)。 2. コンテンツに構造化データ(schema.org)と著者実体(Person/ Organization)が結びついている。これにより、AI エンジンは「この文章は誰が書いたのか、誰が発信したのか」を識別できる。
このため、TrueLink は SSR(Server-Side Rendering、サーバーサイドレンダリング)をコアアーキテクチャとして選択した。SPA とは異なり、SSR はサーバーサイドで各ルートごとに独立した HTML ファイルをレンダリングする。これにより、各ページには完全な schema データが含まれており、AI エンジンが一瞬でデータを取得できる。
> 📌 TrueLink の実装経験:ブログセクションでは SSR アーキテクチャを採用し、SVG チャートや markdown テーブルを用いて構造化データを埋め込む。この方法により、SVG テキストと schema は実際の HTML コンテンツとして存在し、AI が読み取れない画像や動的 JavaScript ではない。[7]
これは単なる技術的な選択ではなく、戦略的な布陣である:私たちが目指すのは「検索順位の最適化」ではなく「デジタル信頼の構築」である。
なぜ SSR が未来のトレンドなのか?Google が E-E-A-T を強化する理由
Google がウェブページのコンテンツを評価する基準は、もはや単純な「キーワード密度」から、「E-E-A-T」(Experience、Expertise、Authoritativeness、Trustworthiness)という4つの次元に移行した。特に、Trustworthiness(信頼性) は構造化データの完全性と密接に関連している。
もしあなたのコンテンツに Person や Organization schema が欠けていたら、AI エンジンは「これは誰が書いたのか、誰が発信したのか」を把握できず、あなたのコンテンツは「匿名の情報」として分類され、信頼性が著しく低下する。その結果、引用リストに含まれる可能性は極めて低い。
> 📌 Google のガイドラインでは、E-E-A-T がコンテンツが役立つかどうかを評価する中心的な基準とされている。[8]
これは、今後 SEO の勝敗が「Google があなたのページを認識し、信頼し、引用するか」にかかっていることを意味する。そして、そのすべての起点は、SSR、schema.org と実体リンク(sameAs)の上に築かれる。
アーキテクチャの選択:SPA と SSR の比較と提言
SPA は決して悪い選択肢ではない。もし開発するアプリケーションが高度なインタラクションや操作のスムーズさを重視するもの(例:ECカート、SNS)であれば、SPA は依然として最適な選択肢である。しかし、あなたの目的が「AI エンジンがコンテンツを読み取り、引用する」ことである場合、SPA は信頼チェーンに断絶を生み出す。
以下のような評価基準を参考にして選択することをおすすめする:
| 面向 | SPA | SSR |
|---|---|---|
| SEO の可視性 | ❌ ルーティング切り替え後に schema が消える | ✅ 各ルートに独立した HTML がある |
| AI による引用可能性 | ❌ 機械が読み取れない | ✅ 構造化データが完全で引用可能 |
| メンテナンスコスト | 🟡 SSR 転送機構を追加する必要がある | ✅ 各ページを独立してデプロイ可能 |
| 開発難易度 | 🟢 簡単 | 🔴 高く、SSR 機構を処理する必要がある |
もしあなたのビジネスの中心が「知識型コンテンツ」、「業界白書」、「質問回答データ」である場合、SSR は必須条件である。TrueLink のコンテンツラインも SSR アーキテクチャを採用しており、ローカル GPU インフラで原稿を生成し、クラウドモデルで品質を校正している。この方法により、各コンテンツのマージナルコストはほぼゼロに近づき、構造化データの完全性と AI エンジンの読み取り性が保証されている。
> 📌 注:私たちの実装経験によると、SEO/GEO コンテンツラインを自社の GPU インフラに移行することで、マージナルコストを抑えつつ、外部品質を維持できる。[1]
結論:アーキテクチャの選択は、あなたのデジタル信頼の基盤を選択すること
SPA は間違いではない。しかし、「AI が引用する必要がある」ようなアプリケーションには不向きである。もし目的が「ユーザーがアクセスして読むこと」だけであれば、SPA は十分かもしれない。しかし、もしあなたの目標が「AI エンジンが自動的に引用する」ことであるなら、フロントエンドのアーキテクチャを再評価する必要がある。
生成式検索最適化の時代において、ウェブサイトは「人間に見える」だけでなく、「機械に読まれる」ことが必要である。このトラフィック争奪戦の基盤となるのは、SSR、schema.org、および実体への信頼である。
TrueLink のコア価値は、単なる SEO ツールではなく、「ChatGPT があなたのブランドを引用する」ことである。もし、あなたのコンテンツが AI エンジンによって読み取られ、引用され、未来のトラフィックの源となることを望むなら、今日はもう SSR の重要性を無視する時代は終わった。

