BlazorのSEOとPrerendering対応とは?|ASP.NET×Blazor入門 9.2

9.2 PrerenderingとSEOへの影響

モダンWebアプリでは、「SEO(検索エンジン最適化)」と「初期表示速度」が重要な要素となります。Blazorを用いる場合、ServerとWASMではこの対応が大きく異なります。本セクションでは、Prerendering(事前描画)の仕組みとSEOとの関係性を整理します。

Blazor WebAssemblyの課題:SEOに不向き

WASMでは、最初にHTMLを読み込んだあと、JavaScript経由で.NETランタイムとコンポーネントが読み込まれます。このため、検索エンジンのクローラーがアクセスした際には、「中身がまだ表示されていないHTML」しか見えません。

  • 初期HTML: 空に近い構造
  • 表示内容: JavaScript実行後に描画(クローラー非対応の可能性)
  • 対策: 動的レンダリングやスクリーンショットベースのSEO施策が必要

Blazor Serverの強み:Prerendering対応

Blazor Serverでは、ASP.NET Coreの機能と統合されているため、Razor PagesやViewとしての描画が可能です。これにより、HTMLを事前にサーバー側で生成し、最初のレスポンスでそのまま返す「Prerendering」が機能します。

  • 初期HTML: コンポーネント描画済みのHTMLを返却
  • 表示内容: ユーザーにもクローラーにも完全に見える状態
  • 利点: SEOに強く、初期表示も高速

Prerenderingの実装例

Prerenderingは、主に _Host.cshtml にて以下のように実装します。


<component type="typeof(App)" render-mode="ServerPrerendered" />
  

render-modeには以下の3つがあります:

  • ServerPrerendered:最初にHTMLを描画して送信後、SignalRで接続
  • Server:空のプレースホルダーを返し、初回接続後に描画
  • Static:完全にHTMLとして静的描画、双方向性なし

まとめ:SEO対応ならBlazor Server

現時点では、検索エンジンとの親和性を重視するなら、Blazor Serverが適しています。一方、WASMでのSEO対応はハードルが高いため、動的レンダリングやプリレンダリングSPAの工夫が求められます。

次のセクションでは、Blazor WebAssemblyの制限とパフォーマンスに関する実務的な考察を行っていきます。

2025-05-10

下田 昌平

開発に関するインプットをアウトプットしています。