シングルページアプリケーション (SPA) を検索エンジンで発見してもらうのは簡単なことではありません。シングルページアプリケーションのSEOは、あなたのウェブアプリケーションがより多くのオーガニックビューを獲得するのに役立ちます。

HTMLベースのウェブサイトは、クローラーに構造化されたマークアップを提供するため、アクセスしやすく、クロールしやすく、インデックスしやすいです。

したがって、HTMLページでコンテンツを持つことは、より良い検索ランキングにつながり、単一ページのアプリよりも最適化が容易です。

SPAsは、訪問者のサイト上でのアクションに基づいてコンテンツを動的に書き換えるためにJavaScriptに大きく依存しています(「展開可能なテキスト」や「ポップアップボックス」を考えてみてください)。

したがって、それはGooglebotsがページのコンテンツをインデックスすることを困難にします、なぜならそれはクライアントサイドのJavaScriptコンテンツを実行しないからです。

この記事では、SPAを使用する際の実際の課題について説明し、シングルページアプリのSEOを行ってより良い検索ランキングを獲得するための完全なプロセスを共有します。

重要なポイント

  • シングルページアプリケーションのSEOは、JavaScriptで駆動されるSPAがクロールボットから重要なコンテンツを隠してしまうことが多いため不可欠です。
  • サーバーサイドレンダリング(SSR)やプリレンダリングを使用して、クロールボットに完全にレンダリングされたHTMLバージョンのページを提供します。
  • 重複コンテンツを防ぎ、ルート全体の関連性を維持するために、シングルページアプリケーションのSEOには動的なタイトル、メタディスクリプション、およびカノニカルタグが重要です。
  • 内部リンク、クリーンURL、XMLサイトマップ、および正しいHTTPステータスコードを組み合わせて、検索エンジンがSPA内のすべての主要なルートを発見しインデックス化するのを助けます。

シングルページアプリケーション (SPA) のSEOとは?

シングルページアプリケーションのための検索エンジン最適化とは、React.js、Angular.js、Vue.js などのJavaScript フレームワークで構築された SPA を、検索エンジンがアクセスしやすくインデックス可能にするプロセスを指します。

シングルページアプリケーションのSEOには以下が含まれます:

  • サーバー側レンダリングまたはプリレンダリング
  • タイトルタグ、メタディスクリプション、および構造化データの最適化
  • URLおよびカノニカルタグの最適化
  • 内部リンクの最適化
  • [サイトマップ]作成と送信
  • [リンクビルディング]

Google、Bing、Baidu、DuckDuckGo、その他の検索エンジンは、SPAsがクライアント側で[コンテンツを動的に読み込む]ため、JavaScriptコンテンツをクロールしてインデックスするのが難しいと感じています。

したがって、SPA SEOは、検索エンジンでのシングルページアプリの発見可能性とウェブプレゼンスを改善するための戦略とベストプラクティスで構成されています。

シングルページアプリケーションの例

こちらがSPAのトップ例です:

Gmail

GmailはSPAの教科書的な例です。ログインすると、受信トレイ、フォルダ、チャットを含むユーザーインターフェース全体が一度に読み込まれます。

その時点から、「メールを閲覧」したり、「スレッドを開く」ことや新しいメッセージを作成する際に、ページ全体のリロードは必要ありません。

JavaScriptは、舞台裏でルーティングとコンテンツの変更を管理し、体験を迅速かつシームレスにします。

Googleは、非同期リクエストを使用して必要なデータのみを取得し、レイテンシーを削減しユーザー体験を向上させています。

Google Maps

Google Maps SPA

Google Mapsは、パン、ズーム、および位置の検索などのリッチなインタラクティブ機能を同じページ内で提供します。

新しい[方向]を要求したり、[衛星]と[地図の表示]を切り替えたりしても[再読み込み]されません。

代わりに、データはAJAXを介して取得され、地図タイルやUIコンポーネントが動的に更新されます。これにより、Google Mapsは非常に応答性が高く、遅い接続でも使いやすくなります。

Facebook

完全にSPAではありませんが、Facebookの大部分はSPAアーキテクチャを使用しています。

ユーザーがニュースフィードをスクロールしたり、投稿を開いたり、リアクションしたり、コメントしたりする際、すべての更新はページのリロードなしで行われます。

メッセージ、通知、マーケットプレイスのようなページ間を切り替える際にも、サイトはJavaScriptフレームワーク(Reactなど)を使用したクライアントサイドルーティングでコンテンツを動的にレンダリングし、サーバーへの呼び出しを減らし、読み込み速度を向上させます

Netflix

netflix

Netflixのウェブインターフェースは、もう一つの注目すべきSPAです。映画やテレビ番組の提案を閲覧していると、トレーラーが自動再生され、コンテンツの詳細がリロードなしで即座に表示されます。

タイトルをクリックすると、コアインターフェースをそのままにしてモーダルオーバーレイまたは新しいビューが開きます。

ルーティング、[recommendations]、ユーザープロファイルの変更はJavaScriptによって管理されており、待ち時間が短く、一貫したエクスペリエンスを提供します。

シングルページアプリケーションはSEOにとって「良い」ですか?

はい、単一ページアプリケーションは、SPAsのための正しい最適化のヒントを知っていれば、SEOにとって良いです。

Googleのような検索エンジンはJavaScriptをレンダリングできますが、ユーザーの操作を必要とするコンテンツのクロールを遅らせたりスキップしたりする場合があります。

それを避けるために、サーバーサイドレンダリング、静的サイト生成、クリーンURLルーティング、および動的メタデータ更新を使用できます。

Next.js、Nuxt.js、React Helmet、Vue Metaのようなツールは、それらすべての作業を手助けします。

適切な設定があれば、SPAは従来のサイトと同様にランク付けされることができます。しかし、「適切なSEO調整」なしでは、検索エンジンが構築した多くの部分を見逃す可能性があります。

[関連記事]: 動的コンテンツのためのSEOを実行する方法

シングルページアプリケーションのためのSEOの方法

ここでは、シングルページWebアプリのための最高のSEOソリューションを紹介します:

サーバーサイドレンダリング (SSR) を使用する

シングルページアプリケーションは、コンテンツを動的にロードするためにJavaScriptに依存しています。

しかし、検索エンジンは、コンテンツにアクセスしクロールしインデックスするために、HTTPレスポンスで完全なサーバーHTMLを期待しています。

したがって、ページをブラウザに送信する前にサーバーでレンダリングするために、サーバーサイドレンダリングを実装する必要があります。

サーバー側レンダリングでは、ブラウザがHTMLファイルをリクエストし、サーバーがすべてのデータを取得します。それにより、すべてのコンテンツが即座に表示可能でクロール可能であることが保証されます。

サーバーサイドレンダリングのインフォグラフィック

頻繁にアクセスされるページをキャッシュして、読み込み時間を短縮し、コンテンツをより速く提供します。主要な要素に対してクライアントサイドレンダリングを避けてください。検索エンジンがJavaScriptが多用されたビューを処理できない可能性があります。

静的ルートに対するプリレンダリングを実装する

すべての訪問者に同じコンテンツを表示するルートは[事前レンダリング]する必要があります。これにより、ビルド時にHTMLを生成し、ランタイムレンダリングの必要がなくなります。

その結果、検索エンジンはページに瞬時にアクセスできます。

Next.jsやNuxt.jsのようなフレームワークの"静的生成ツール"は、[ランディングページ]、[ブログ]、または[製品概要]のようなルートの"静的ファイル"を作成するのに役立ちます。

これらのプリレンダリングされたページは、読み込み速度と可視性を向上させるためにContent Delivery Networkまたはウェブサーバーを通じて提供する必要があります。リアルタイムデータやユーザー固有のデータを含むビューにはプリレンダリングを適用しないでください。

クリーンでクロール可能なハイパーテキストマークアップ言語出力を追加

検索エンジンが簡単に解釈できる構造化された「HyperText Markup Language」出力を生成する必要があります。

クリーンなマークアップは、ボットがページのレイアウト、階層、および主要な要素を理解するのに役立ち、JavaScriptの実行に頼らずに済みます。

ページの読み込み後にコンテンツを動的に挿入することは避けてください。代わりに、重要なテキスト、見出し、リンクがソースコードに直接表示されるようにしてください。

Ciara Edmondson[シングルページアプリ]でSEOに取り組むとき、最も重要なのはGoogleがページを人間と同じように見ているわけではないということです。[JavaScript]でコンテンツを読み込むため、クローラーが空白のページしか取得できないことがあります。したがって、Googleに読んでもらいたい内容が実際にhtmlに表示されるようにしてください。

- Ciara Edmondson, SEO & コンテンツマネージャー at Max Web Solutions

<header>や<main>、<article>、<footer>のようなセマンティックタグを使用して、明確な構造を提供します。

意味のあるコンテンツを曇らせる可能性のある「インラインスタイル」とスクリプトの散乱も最小限に抑えるべきです。

ドキュメントを読みやすく、軽量に保ち、クロールの高速化とインデックス作成の向上を図ります。

各ルートの静的HTMLを生成するために、サーバーサイドレンダリングまたはプリレンダリングを使用します。これにより、クローラーが初回のリクエストでページ全体のコンテンツにアクセスできることが保証されます。

クローラー用の静的スナップショットを公開する

クローラーが完全なコンテンツにアクセスできるようにするために、特にクライアントサイドのレンダリングがページ出力を遅らせる場合には、静的スナップショットを公開する必要があります。

静的スナップショットは、ページの完全にレンダリングされたバージョンで、事前に生成され、特にボットに提供されます。

この戦術は、アプリケーション全体でサーバーサイドレンダリングや事前レンダリングが実行不可能な場合に役立ちます。

スナップショットは、クローラーがJavaScriptを実行せずに構造化されたHyperText Markup Languageにアクセスするための別のパスを提供します。

サーバーを設定して、Googlebotのようなユーザーエージェントを検出し、それらのリクエストに対して事前に構築されたスナップショットを提供する必要があります。

RendertronPrerender.io、またはカスタムヘッドレスNodeJSレンダラーのようなツールは、スナップショットを確実に生成および配信するのに役立ちます。

Prerender

各スナップショットがページの完全な内容と構造を反映していることを確認し、「タイトル」、「メタデータ」、「リンク」、および「スキーママークアップ」を含めます。

ニュージーランドに拠点を置くエージェンシー、Somar DigitalのSafiraは、すべてのSPAがSEOのためにスキーママークアップを使用することを推奨しています。

Safira Mumtaz私はSPAに構造化データスキーママークアップを使用することをお勧めします。[組織]、[ウェブページ]、[パンくずリスト]、[FAQ]などの関連スキーママークアップを統合してください。

私は、スキーママークアップがソースコードやGoogle Rich Results Testに表示されないことがあると気づきましたが、スキーママークアップバリデーターを使用してスキーマをテストすると、結果に追加されたスキーママークアップが表示されます。これは、スキーマを注入するSPA(JavaScript経由)が初期ロード時にこれを利用できないためです。しかし、GoogleはJavaScriptをヘッドレスで読み取ることができます。

- サフィラ・ムムタズ, SEO/SEMスペシャリスト [at] Somar Digital

クローラーがスナップショットを意図した通りに処理していることを確認するために、インデックスカバレッジも監視する必要があります。

静的スナップショットを提供することにより、複雑なレンダリングロジックを持つページの可視性が向上し、一貫したインデックス作成とSEO価値の維持に役立ちます。

各ビューに対して[正規]タグを設定する

"あなたは[設定する]必要がある"正規タグ単一ページアプリケーションのすべてのルートで重複コンテンツの問題を避けるために。

ほとんどの場合、SPAsは同じコンテンツに対して複数のアクセス可能なURLを生成します。

例えば、同じコンテンツが異なるクエリ文字列、フィルター、またはトラッキングパラメータを持つURLに存在することがあります。カノニカルタグは、検索エンジンが優先バージョンを理解するのを助けます。

canonical タグのイラスト

各ルートには、そのビューの元のURLを指す<link rel="canonical">タグを含める必要があります。それにより、同じコンテンツを持つ異なるURL間でのリンクエクイティの希釈が防止されます。

アプリケーションがクライアント側でメタデータを更新する場合は、特にルートが変更されたときにカノニカルタグを動的に挿入する必要があります。

ルーティングフックまたはミドルウェア関数を使用して、すべてのページ遷移で正しいタグを割り当てます。

すべてのルートをホームページに向けたり、静的なカノニカル値を使用したりすることを避けてください。すべてのユニークビューは、その独自の論理的なURLを反映させることで、関連性とインデックスの正確性を維持する必要があります。

適切な正規化を実装することで、インデックス作成が明確になり、ページの権威が向上し、検索結果での不要な重複を防ぐことができます。

404やその他のステータスコードを正しく処理する

シングルページアプリケーション内のすべてのビューに対して正確なステータスコードを設定し、検索エンジンがサイト構造を適切に解釈できるようにする必要があります。

多くのSPAはすべてのリクエストに対してデフォルトのHTMLシェルを提供し、存在しないルートに対しても200 OKを返すことがあります。

無効なURLに対しては、適切な404 Not Foundレスポンスが返されるべきです。

NodeJSでサーバーロジックまたはミドルウェアを使用して、一致しないルートを検出し、正しいステータスコードとカスタムエラーページを送信します。

Google 404エラー

また、リダイレクションのための301や302、サーバーエラーのための500など、他の応答も処理する必要があります。

これらのステータスコードは、検索エンジンに各リクエストをどのように処理するかを知らせ、クロールとインデックスカバレッジの整合性を維持します。

クライアント側のエラーハンドリングのみに頼ることを避けてください。クローラーはJavaScriptを実行しない場合があるため、誤ったステータス応答が検索エンジン最適化シグナルを損ない、インデックス作成を誤解させる可能性があります。

動的URLをGoogle Search Consoleに送信する

すべての重要な動的URLをシングルページアプリケーションからGoogle Search Consoleに、URL検査ツールを使用して送信する必要があります。これは、検索エンジンのボットが従来のクロールでは表示されない可能性のあるコンテンツを発見し、インデックスするのに役立ちます。

URL検査ツール

SPAsはクライアントサイドルーティングを通じてコンテンツを読み込むため、直接リンクがないとクローラーが内部ページを見つけられない場合があります。

可視性を確保するために、これらのURLをXMLサイトマップにリストし、コンソールインターフェースを通じて送信します。

新しいルートが追加されたり変更されたりするたびに、サイトマップを更新する必要があります。各エントリは、ユーザーやクローラーが見る最終的でクリーンなURLを反映している必要があり、ハッシュや不要なパラメータを除外してください。

動的URLを送信することは、Googleにアプリケーションの構造の明確な地図を提供し、正確なクロールと迅速なインデックス化の可能性を向上させます。

フォールバックを使用して[レイジーローディング]を有効にする

画像、ビデオ、または[画面下部]のセクションなどの[非本質的な要素]の読み込みを遅らせることによって、SPAのパフォーマンスを向上させるために遅延読み込みを有効にする必要があります。

初期のロード時間を短縮し、デスクトップとモバイルの両方でユーザーエクスペリエンスを向上させます。

検索エンジンはJavaScriptを介して読み込まれるコンテンツをトリガーしない場合があり、これによりインデックスの見落としが発生する可能性があります。

クロールする際にすべての重要な要素が見えるようにするため、プレースホルダーコンテンツや <noscript> タグのようなフォールバックを提供する必要があります。

ネイティブブラウザ機能を使用して、loading="lazy"属性を利用するか、JavaScriptを通じてスクロールベースの読み込みを管理します。Google Search Consoleのようなツールを使用して、常に可視性を確認する必要があります。

検索の可視性に寄与する重要なコンテンツやリンクを遅延させることは避けてください。信頼できるフォールバックを伴う適切なレイジーローディングの使用は、より速い読み込み速度と完全なコンテンツカバレッジをサポートします。

非クリティカルなJavaScriptを遅延させる

シングルページアプリケーションで重要なコンテンツのブロックを減らし、初期ページレンダリングを高速化するために、重要でないJavaScriptを「遅延」させるべきです。

ファーストビューのコンテンツに必須でないスクリプトは、ユーザーのインタラクションとクローラーの可視性の両方を遅らせる可能性があります。

初回ページ読み込み時の不要な実行を防ぐために、スクリプトタグでdeferまたはasync属性を使用します。

非必須スクリプトは、ドキュメントの末尾に配置するか、コアコンテンツがレンダリングされた後に読み込んでください。

レイアウト、メタデータ、またはルーティングロジックに影響を与えるスクリプトを特定し、それらを分析、チャットウィジェット、またはアニメーションから分離する必要があります。

"ツール [like]"LighthouseChrome DevToolsスクリプトの動作とロードシーケンスを監査するのに役立ちます。

[Chrome Dev Tools]での[Load sequence]

SPAルート間の内部リンクを実装する

クローラーがサイトを通過するのをガイドするために、シングルページアプリケーション内のすべてのルート間で明確な内部リンク構造を作成する必要があります。

従来のウェブサイトとは異なり、SPAはクライアント側のナビゲーションに依存しており、リンクが正しく追加されていない場合、検索エンジンがすべての内部ページを発見できないことがあります。

アンカータグには、JavaScript関数やボタンだけでなく、実際のパスを反映する適切なhref属性を使用してください。意味のあるURLなしでonClickハンドラーのような要素を使用しないでください。これらはクローラーによって無視されることが多いです。

すべての重要なページがアプリケーションの他の部分、特にホームページや高い権威を持つページからリンクされていることを確認する必要があります。これにより、効率的なクロールのための関連性と権威のシグナルが伝わります。

ナビゲーションメニュー、パンくずリスト、関連ビュー間のコンテキストリンクで論理的な階層を維持します。ページのトピックを強化するために説明的なアンカーテキストを使用します。

内部リンクはクロールの深さを向上させ、権威を分散し、アプリケーション全体の検索エンジン最適化パフォーマンスを強化します。

すべての重要なルートを反映するサイトマップを使用する

シングルページアプリケーションのすべての重要なルートを含むサイトマップを生成して送信する[必要がある]。

SPAsはクライアントサイドのルーティングを使用するため、多くの内部ビューは従来のクロールでは発見されない可能性があります。

インデックス用に意図されたすべての静的および動的ルートを一覧表示するXMLサイトマップを作成します。不要なパラメータ、フラグメント、またはセッションデータなしで、クリーンで[canonical]なURLのみを含めます。

新しいルートが追加、削除、または変更されるたびに、サイトマップを更新する必要があります。自動化ツールは、各デプロイメント時にサイトマップを再生成して正確さを保つことができます。

Google Search Console にサイトマップを [提出] する と、検索エンジンが重要なコンテンツを見つけて優先順位を付けるのに役立ちます。これは、[完全なインデックス カバレッジ] をサポートし、ルート レベルの可視性を強化します。

サイトマップを[送信]

適切に管理されたサイトマップは、クローリング効率を改善し、重要なビューが必要な注目を受けることを保証します。

サーバーログでクローラーの動作を監視する

検索エンジンがあなたのシングルページアプリケーションとどのように相互作用しているかを理解するために、サーバーログを分析する必要があります。

ログは、どのルートがクロールされているか、それらがどのくらいの頻度でアクセスされているか、そしてボットがエラーや遅延に遭遇しているかどうかを明らかにします。

HTTPステータスコード、ユーザーエージェント、およびタイムスタンプを確認して、インデックス作成のギャップやクロールの非効率性を検出します。

見逃したコンテンツの兆候、無関係なページへの繰り返しアクセス、または可視性を損なう可能性のある失敗した応答に注意してください。

Googlebotが動的ルートをどのようにナビゲートするかを追跡し、重要なビューがクロールの注目を受けていることを確認する[必要があります]。ログデータとGoogle Search Consoleのようなツールからの洞察を組み合わせて、インデックスカバレッジを[クロスチェック]してください。

ページインデックス

サーバーログ分析ツールを使用するか、NodeJSサーバー環境からデータをエクスポートして、[deeper visibility] を得ます。

リアルタイムのボット活動をモニタリングすることは、「クロールの無駄」を特定し、「発見可能性の問題」を修正し、全体的なSPA SEOパフォーマンスを最適化するのに役立ちます。

動的コンテンツのレンダリング問題を解決する

シングルページアプリケーションにおけるレンダリングの問題を解決し、動的コンテンツが検索エンジンに完全に表示されるようにする必要があります。

JavaScriptの実行に依存するコンテンツは、読み込みが遅すぎる場合やユーザーの操作を必要とする場合、クロール中に表示されないことがあります。

各ルートを監査して、重要なテキスト、リンク、および見出しがレンダリングされた出力に含まれていることを確認します。GoogleのURL検査ツールLighthouseなどのツールを使用して、初期レンダリングから欠落しているコンテンツを検出します。

必要に応じて、サーバーサイドレンダリングやプリレンダリングのような技術を適用して、完全に構築されたページを配信するべきです。

クライアントサイドのレンダリングでは、データが迅速にロードされ、遅延トリガーに依存しないようにしてください。

クローラーがページを処理した後に重要な情報を注入することは避けてください。レンダリングの遅延は、部分的なインデックス化や検索結果からの除外につながる可能性があります。

レンダリングの問題を修正することは、重要なコンテンツの完全な可視性を確保し、より良いインデックス付けをサポートし、SPAの全体的な検索エンジン最適化の結果を強化します。

JavaScriptの実行をクローラーの能力に合わせる

JavaScriptの実行を構造化して、特にGooglebotのレンダリングキューとリソース制約に合わせて現代のクローラーの処理限界に一致させる必要があります。

クローラーは各URLに対して時間予算で動作します。したがって、過剰な依存チェーン、非同期データのフェッチ、またはレンダーをブロックするロジックは、重要なページの不完全なインデックス化を招く可能性があります。

初期のペイントフェーズで「重要なパスコンテンツ」を優先的にレンダリングします。入れ子になった「ハイドレーションレイヤー」や遅延した「DOM変異」、またはクライアント専用コンポーネントの過剰な使用を避けてください。

実行時のコンテンツ注入を、サーバーで事前取得したデータや、完全なサーバーHTMLが実現不可能な場合はスケルトンレイアウトに置き換えます。

実行時間を監査するには、Chrome DevTools Performance panelのようなツールを使用し、PuppeteerやヘッドレスNodeJSレンダラーでクローラー条件をシミュレートします。

キャッシュなしの条件で、インタラクティブまでの時間 (TTI)、最大コンテンツ描画 (LCP)、および合計ブロッキング時間 (TBT) をトラックします。

ルート固有のメタデータ、カノニカルタグ、およびスキーマが同期的にマウントされることを確認します。意味のあるレンダー出力を遅延させる重いライブラリやランタイムルーティングフレームワークへの依存を減らします。

専門ツールでSEOパフォーマンスを監査する

シングルページアプリケーションの「可視性の問題」を検出するために、検索エンジン最適化のパフォーマンスを定期的に監査する必要があります。

標準のブラウザベースのチェックは、JavaScriptが多用される環境に特有の問題を見逃します。

高度なツールを使用することで、ページが検索エンジンによってどのようにレンダリングされ、インデックス化され、スコアリングされるかについて深い可視性を提供します。

SEOptimerは、そのようなツールの一つで、[実行]します。包括的な監査技術的、[on-page]、およびパフォーマンス層にわたって。

SEOptimer ホームページ

それは各ページをスキャンして、メタデータの品質、モバイル対応性、内部リンク構造、およびコンテンツ対コード比率を確認します。

SPAsに対して、SEOptimerはクロールのしやすさに影響を与える不足している"HyperText Markup Language"要素、誤って設定されたカノニカルタグ、および弱いヘッダー構造を特定するのに役立ちます。

主要なアップデートを展開したり、新しいルートを開始した後に、SEOptimerの監査を実行する必要があります。このツールは、「レンダリング遅延」、[broken links]、およびコンテンツが正しく読み込まれるのを妨げるJavaScript依存関係を警告します。

SEOptimerパフォーマンス監査

SEOptimerをGoogle Search Consoleやログ解析ツールのようなツールと組み合わせて、現実世界のクロール条件下で結果を検証します。

定期的な監査により、ルーティングロジック、コンテンツ配信、およびレンダリングの動作がすべて持続可能なSEOパフォーマンスをサポートすることが保証されます。

なぜSEOはSPAsにとって難しいのか

SEOはシングルページアプリケーションにとって難しいです。なぜなら、メタデータ、ルート固有のコンテンツ、および適切なステータスコードがクローラーによって見逃されたり誤解されたりする可能性があるためです。

こちらがSPAsにおけるトップのSEOチャレンジです:

1. クライアントサイドレンダリング

検索エンジンは、最初のHTML応答に意味のあるコンテンツが含まれていることを期待しています。SPAsはページが読み込まれた後にJavaScriptを使用してコンテンツをレンダリングするため、可視性が遅れます。

クローラーがレンダリングが完了する前にページにアクセスすると、[text] や [links] のようなキー要素が処理されない可能性があります。これにより、検索エンジンが不完全または空のページをインデックスするリスクが生じます。

その結果、ユーザーが見ることができるコンテンツは検索エンジンの結果に到達しません。

2. クロールの制限

SPAsは、伝統的な静的リンクを通じてすべてのページを公開しないため、クロールがより複雑になります。

多くのページは内部クライアントサイドのナビゲーションを通じてのみアクセス可能であり、検索ボットはそれに従わないかもしれません。

現代のクローラーであるGooglebotでさえ、JavaScriptのレンダリングには遅延と限られた処理時間があります。複数のレンダリングサイクルやネストされたデータフェッチを必要とするページは、クロール予算を超える可能性があります。

重要な「ビュー」が完全に見落とされる可能性があり、検索結果でのサイトの可視性が弱まることがあります。

3. 動的メタデータ処理

各ビューは、手動で設定しない限り、SPAにおいてユニークなメタデータを欠いています。

タイトル、説明、およびカノニカルタグを動的に更新しないと、すべてのURLが検索エンジンには同一に見えます。

これにより、インデックスエラー、「関連性の低下」、および「クリック率の低下」が発生します。

URLの変更に関連付けられたメタデータは、ライブラリまたはカスタムロジックを使用してリアルタイムで注入する必要があります。これを管理しないと、異なる検索クエリでアプリケーションが適切にランク付けされるのを妨げます。

4. 非標準URL構造

SPAは、ハッシュフラグメントやブラウザ履歴操作に依存するURLを使用することがあります。これらの形式は、クリーンで正規化されたパスを好む検索エンジンにとって混乱を招く可能性があります。

ルートに適切な構造が欠けている場合、インデックスされないか、重複として扱われる可能性があります。

不一致なURLは、ユーザーのナビゲーションやクロールの深さにとって重要である「ディープリンク」をも壊します。

SEOのパフォーマンスは、ボットが実際の明確なURLを解釈またはアクセスできない場合に悪化します。

5. 不正確なHTTPステータスコード

従来のサイトとは異なり、SPAは存在しないルートに対しても200 OKで応答します。

これは検索エンジンを誤解させて、エラーページや [irrelevant] なコンテンツをインデックスすることになります。

404 [「Not Found」] や 301 [「Redirect」] のような正しいコードがないと、クローラーは古いページを削除したり、新しいパスをたどることができません。

ボットは、サイト構造やコンテンツの変化を解釈するために正確なステータス信号を必要とします。

これらの応答を誤処理するSPAは、検索結果におけるコンテンツの表示方法を制御できなくなります。

6. ナビゲーション中のページリロードなし

SPAsでは、ルートの変更がページを再読み込みすることなくブラウザ内で行われます。これにより、検索エンジンがナビゲーションイベントを新しいページとして認識するのを防ぎます。

ボットはユーザーがまだ同じページにいると仮定することがあり、これにより新しいビューのインデックス作成が制限されます。

マルチページサイトとは異なり、SPAはSEOツールがこれらの遷移を検出するためにシミュレートしなければなりません。これがないと、ルート固有のコンテンツが見落とされたり誤分類されたりします。

7. コンテンツの遅延レンダリング

SPAsは、複数のJavaScript依存関係と非同期ロードのために、目に見えるコンテンツを遅延させます。

このため、検索エンジンのクローラーは重要なデータが表示される前にページを処理する可能性があります。

レンダー時間が長いと、「部分的なインデックス」、「見出しの欠落」、および「不完全なページ要約」が発生する可能性があります。

クロール中に意味のあるコンテンツが準備されていない場合、検索エンジンはそのページに価値がないと見なすか、ページを「薄いコンテンツ」と見なす可能性があります。

これは最終的にランキング、[visibility]、およびトラフィックを減少させます。

結論

シングルページアプリケーションのSEOを正しく行うことは簡単ではありません。

検索エンジンは、スクリプトが後からコンテンツをロードするのを待たずに、すぐに実際のコンテンツを見る必要があります。そのため、各ルートを本物のページとして扱い、ユーザーがアプリを移動するにつれてタイトルと説明を更新しながら、適切なHTMLを送信する必要があります。

また、ステータスコードを管理し、内部リンクを構築し、構造化データを追加し、検索エンジンがサイトのすべての部分をクロールできるようにする必要があります。すべてが整ったとき、"single page application" はインデックスされやすくなり、ランク付けも容易になります。