簡単な答え: シングルページアプリケーション（SPA）のSEOは難しいです。なぜなら、初期のHTMLがほとんど空であり、コンテンツがページ到着後にJavaScriptを通じて読み込まれるため、クローラーが空のシェルをインデックスする可能性があるからです。解決策は、サーバーサイドレンダリング（SSR）やプリレンダリングを使用して、すべてのURLが完全なHTMLを返すようにすることです。これには、実際にクロール可能なURL、正しいHTTPステータスコード、サーバーレンダリングされたメタ情報やスキーマも含まれます。Shopifyのストアフロントはすでにサーバーレンダリングされているため、これは主にカスタムまたはヘッドレスビルドに関係します。

シングルページアプリケーションは、ウェブをソフトウェアのように感じさせました。瞬時のナビゲーション、完全なリロードなし、アプリのようなインタラクションです。しかし、これによりSEOの古い仮定の一つが静かに破られました。それは、サーバーが送信するHTMLがクローラーが読むコンテンツであるということです。デフォルトのクライアントレンダリングされたSPAでは、サーバーはほとんど空のシェルを送り、JavaScriptがブラウザ内でページを構築します。そのため、JavaScriptを実行しないクローラーはインデックスするものが何も見えません。解決策はSPAアーキテクチャを放棄することではなく、サーバーサイドレンダリングで実際のHTMLを送信することです。このガイドでは、なぜSPAがSEOにとってリスクがあるのか、その解決策となるレンダリング戦略、そしてShopifyでどのように影響するかを説明します。これは、ほとんどの商人にとってはヘッドレスに移行する場合にのみ関係します。

シングルページアプリケーションがSEOにリスクをもたらす理由

従来のウェブサイトは、各URLに対して完全なHTMLドキュメントを送信します。シングルページアプリケーション（SPA）はこれを逆転させます。最初の応答はほぼ空のシェルとJavaScriptバンドルであり、ブラウザはそのJavaScriptを実行してデータを取得することで表示ページを組み立てます。高速なデバイスを使用するユーザーには最適ですが、スクリプトを実行せずにHTMLを読むものにとっては問題です。

クローラーはまさにそれです。クライアントレンダリングされたSPAをインデックスするには、クローラーがシェルをダウンロードし、JavaScriptを実行し、データの読み込みを待ってからコンテンツを確認する必要があります。Googleはこれを行うことができますが、遅延した第2パスで行われ、数日遅れることがあり、スクリプトエラーやリソースのブロックが発生すると静かに失敗します。Bingはこれに対して弱いです。そして、回答エンジンの背後にあるAIクローラーはさらに弱く、多くは生のHTMLを取得し、まったくレンダリングしません。したがって、デフォルトのSPAは、クローラーがあなたのコードを正しく実行する意欲と能力に賭けることになり、検索がAIにシフトするほどその賭けは悪化します。

症状はおなじみです：ランク付けされないページ、Googleでほぼ空のキャッシュバージョン、空白のタイトルを表示するソーシャルおよびAIプレビュー、そしてあなたには完璧に見えるがボットには見えないサイト。根本的な原因は常に同じです — コンテンツがHTMLに含まれていないのです。

修正方法: 実際のHTMLを送信

SPAのSEOに対するすべての解決策は同じことを行います。それは、クローラーがJavaScriptを実行せずに各URLに対して完全にレンダリングされたHTMLを受け取ることを確実にすることです。これを達成する方法は3つあります。

方法 仕組み 最適な用途 制限事項
サーバーサイドレンダリング (SSR) 各リクエストに対してサーバーでHTMLを構築し、ブラウザでライブアプリに変換します。 動的コンテンツ—商品ページ、検索結果、パーソナライズされたコンテンツや頻繁に更新されるコンテンツ。 サーバーランタイムが必要で、最適化されていない場合は遅延が発生する可能性があります。
静的サイト生成 (SSG) / プリレンダリング デプロイ時に事前にHTMLを構築し、ルートごとに静的ファイルを提供します。 安定していて、すべての人に同一のページ—マーケティングページ、ブログ投稿、ドキュメント。 次のビルドまでコンテンツが固定されるため、ライブで常に変化するカタログには適していません。
動的レンダリング クローラーを検出し、ユーザーには通常のSPAを提供しつつ、別途プリレンダリングされたHTMLバージョンを提供します。 すぐに再構築できない既存のクライアント専用アプリのレガシーブリッジ。 メンテナンスが重いレンダリングパイプラインを追加し、Googleはこれを推奨ではなく回避策として扱います。

サーバーサイドレンダリング (SSR) は、各リクエストに対してサーバーでHTMLを構築し、ブラウザでライブアプリに変換します。クローラーは最初の応答で完全なコンテンツを取得し、ユーザーは変換後にSPA体験を得ます。これは最も堅牢なオプションであり、商品ページ、検索結果、パーソナライズされたものや頻繁に更新されるコンテンツなど、変更されるコンテンツに最適です。Next.js、Nuxt、Remix、ShopifyのHydrogenなどのフレームワークはこれを基に構築されています。

静的サイト生成 (SSG) / プリレンダリング は、デプロイ時に事前にHTMLを構築し、ルートごとに静的ファイルを提供します。これは最速で最もクロールしやすいオプションで、すべての人に同一のページ—マーケティングページ、ブログ投稿、ドキュメントに理想的です。制限は、次のビルドまでコンテンツが固定されることなので、安定したページには適していますが、ライブカタログには適していません。

動的レンダリング は、クローラーを検出し、ユーザーには通常のSPAを提供しつつ、別途プリレンダリングされたHTMLバージョンを提供します。Googleはこれをレガシーの回避策として扱っており、メンテナンスが重いレンダリングパイプラインを追加しますが、すぐに再構築できない既存のクライアント専用アプリには実用的なブリッジとなることがあります。

多くのチームが新たに始める場合、SSR（適したページには静的生成を併用）が答えです。これにより、クローラーのレンダラーへの依存が完全に排除され、Google、Bing、AIエンジン全体でインデックス作成を決定的にする唯一の方法となります。

レンダリングを超えたSPA SEOの基本

HTMLのサーバーレンダリングは必要ですが、それだけでは不十分です。SPAは、マルチページサイトが自動的に得られるものを尊重する必要があります。

ビューごとの実際のURL。 インデックス可能なすべての状態には、History APIを使用してクロール可能な独自のURLが必要です。フラグメント（#）やメモリ内の状態ではいけません。ビューにURLがない場合、それはインデックスされず、リンクもできません。ルートごとのメタデータ。 各ルートは、ユーザーがナビゲートする際に更新され、サーバーレンダリングされたHTMLに存在する独自のタイトル、メタディスクリプション、カノニカルを設定する必要があります。クライアントのJavaScriptによってロード後にパッチされるだけではいけません。ページごとの構造化データ。 JSON-LD — Product、Article、FAQPage — をサーバーレスポンスで出力し、最初の読み込み時に利用できるようにします。正しいステータスコード。 サーバーレンダリングされたアプリは実際の404や301を返すことができますが、クライアントのみのアプリはしばしばすべてに対して200を返し、ソフト404でインデックスを汚染します。クリーンな内部リンク。 クローラーがそれをたどれるように、クリックハンドラではなく、href属性を持つ実際のアンカータグを使用します。

レンダリングを正しく行い、これらを無視すると、異なる理由でページが見えなくなります。

Shopifyでの具体的な影響

ほとんどのShopifyマーチャントはこれに触れることはありませんが、その理由を明確にしておく価値があります。Liquidテーマを使用した標準的なShopifyストアフロントはサーバーレンダリングされており、Shopifyはすべての製品、コレクション、ページに対して完全なHTMLを送信します。そこでのSEO作業は、コンテンツ、メタ、スキーマ、インデックス化といった古典的なShopify SEOスタックであり、レンダリングではありません。なぜなら、プラットフォームがすでにサーバーでレンダリングしているからです。

SPA SEOが問題になるのは、ヘッドレスに移行する場合のみです。ShopifyのHydrogenフレームワークや、手作りのReact、Vue、Svelteフロントエンドを使用してStorefront APIと通信するカスタムストアフロントを構築する場合です。このデカップリングにより、デザインとパフォーマンスの自由が得られますが、レンダリングの責任も戻ってきます。これがまさにHydrogenがデフォルトでサーバーレンダリングを行い、Oxygenにデプロイされる理由です。Shopifyは、クライアントのみのヘッドレスストアフロントがSEOのリスクであることを学び、そのギャップを埋めるためのフレームワークを提供しています。ブラウザでのみレンダリングされるカスタムヘッドレスビルドは、このガイドで説明されているすべての問題を再現する場所です。

実践的なルールとしては、Liquidテーマを使用している場合、これはあなたの関心事ではありません。コンテンツとスキーマを最適化してください。ヘッドレスに移行する場合は、最初からSSRフレームワークを選択し、クライアントのみのレンダリングを後で修正するフェーズではなく、避けるべきミスとして扱ってください。

SSRとAI検索

サーバーサイドレンダリングは、AI時代においてより重要になっています。ChatGPT、Perplexity、Claude、AI Overviewsの背後にあるクローラーは、GoogleよりもJavaScriptの実行が苦手で、多くは生のHTMLを取得し、何もレンダリングしません。Googleが最終的にレンダリングするクライアント専用のSPAは、回答エンジンには完全に見えない可能性があります。つまり、購入者が離れていくチャンネルでゆっくりとランクインする一方で、移行先のチャンネルでは引用されることができません。

サーバーレンダリングされたHTMLはAI検索への入場券であり、クリーンな構造化データとllms.txtマニフェストが、レンダリングされたページを引用可能にする層です。これは、インデックス可能性の上に構築される生成エンジン最適化の作業です。まず、コンテンツがHTMLに含まれている必要があり、その後、持ち上げるのに十分な構造化が必要です。

結論

シングルページアプリケーションはSEOに悪いわけではありませんが、クライアントのみのレンダリングは問題です。これは、JavaScriptを実行しないクローラーからコンテンツを隠してしまうためです。そして、特にAIエンジンの中でそれを実行しないものが増えています。解決策は、実際のHTMLを送信することです。動的コンテンツにはサーバーサイドレンダリング、安定したページには静的プリレンダリング、そして動的レンダリングはレガシーブリッジとしてのみ使用します。さらに、実際のルートごとのURL、メタデータ、構造化データ、ステータスコードも必要です。Shopifyでは、標準のLiquidテーマでは問題になりませんが、ヘッドレスに移行した瞬間に最重要事項となります。そのため、Hydrogenはデフォルトでサーバーレンダリングを行います。サーバーでレンダリングすれば、SPAも従来のサイトと同様にインデックス化され、引用可能になります。

RankEngineは、ストアフロントのSEOおよびAI検索シグナル（メタ、スキーマ、インデックス、llms.txt、AIクローラーアクセス）を監査し、標準のShopifyテーマでもヘッドレスビルドでも、確認済みの修正を適用します。ヘッドレスストアの場合、まずレンダリングを正しく行い、その後にRankEngineがオンページおよびAI検索レイヤーを処理します。