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の制限とパフォーマンスに関する実務的な考察を行っていきます。
下田 昌平
開発に関するインプットをアウトプットしています。検索ログ
開発・技術相談
システム開発や技術検証、要件定義の作成、アーキテクチャ設計、 テスト設計、運用設計まで、一気通貫で支援しています。 企画段階の「まず相談したい」レベルから、実装・運用まで 幅広く対応できますので、お気軽にお問い合わせください。
お問い合わせ