Learn the fundamentals and best practices of SEO (search engine optimization) in Blazor.
By the end of this post, you will understand why SEO works differently in Blazor than in traditional ASP.NET Core MVC or Razor Pages and why it might matter to your apps even if you do not know it yet.
Why SEO Matters (Even for Internal Apps)
We need to differentiate between public-facing and internal Blazor web applications.
For public-facing apps, search engine optimization is important for helping customers find the app on Google and other search engines.
However, if you think that it is not important for internal applications, consider this: SEO also affects social sharing previews (links sent via internal communication tools such as Microsoft Teams or similar), accessibility, AI crawlers and semantic indexing of internal websites.
In some form or another, SEO affects all modern web applications, whether public-facing or not.
SEO Differences Between Blazor Render Modes
In previous versions of Blazor, Blazor in general and Blazor WebAssembly in particular had a bad reputation for being non-SEO-friendly. And this reputation is based on facts and not feelings alone.
However, with modern .NET 10+, Blazor provides much more nuanced rendering modes. SEO quality generally depends on the chosen render mode rather than Blazor as a framework.
Blazor provides four render modes:
For public marketing pages, such as a homepage (landing page) of a web application, documentation, blogs or other product pages, I highly recommend using Static SSR.
Static SSR delivers the best SEO performance because the server returns pure HTML and provides a fast Time-To-First-Byte (TTFB).
Static SSR is, as the name suggests, a static mode. It means you can use the Blazor component model to implement the pages, but there will not be any interactivity once the webpage is rendered in the browser. It’s an excellent choice for static pages, such as those mentioned above.
Interactive Server means that interactivity runs on the server, and the client receives a pure HTML response. Because of the interactivity, TTFB is slower than Static SSR.
Interactive Auto and Interactive WebAssembly are more complex for SEO. In general, I would advise not using them for SEO-relevant web applications unless you are experienced with them and know how to properly implement prerendering.
What Crawlers Actually See
To better understand the theory from the previous chapter, consider the following HTML startup code the browser sees for a Blazor WebAssembly web application (with prerendering disabled):
And compare it to the same application implemented using Static SSR:
With Static SSR, the pure HTML response is sent to the client and rendered in the browser. Web crawlers can read a page’s content, index it and use it to provide meaningful search results pages (SERPs).
Besides page content, metadata remains very important for SEO and social media previews.
Meta tags, such as the title and description tags, are used to build SERPs.
This is the metadata definition of my personal website.
You can see that the title and description I defined in the code are used to create a SERP in Google.
Open graph tags allow you to configure the content that shows up when the page is shared on Facebook, LinkedIn and X (formerly Twitter).
The most important tags are:
- og:title – The headline of the content
- og:description – A short summary of the page
- og:image – A URL of an image that will appear when sharing the post
- og:url – The canonical URL for the content
- og:type – The type of content (article, website, video, etc.)
Hint: A canonical URL is the master version of a webpage. It is often used when multiple URLs point to the same content. Its purpose is to solve and prevent duplicate content problems when multiple URLs return the same content.
Hint: A canonical URL is the master version of a webpage. It is often used when multiple URLs point to the same content. Its purpose is to solve and prevent duplicate content problems when multiple URLs return the same content.
You can edit static metadata directly in the App.razor file. However, most of the time, you want the description and title tag to dynamically change depending on the page you’re rendering.
There are several built-in components, such as the PageTitle component, which allows us to set the browser tab text from within each Blazor page.
Similarly, the HeadContent component allows us to set metadata from each Blazor page. Consider the following example:
We use the HeadContent component and set the description tag from within our Blazor page. Imagine this page provides dynamic content. For example, depending on the article ID provided, another article is rendered.
We set the Description property within the code section and reference it in the template code.
Routing and SEO-Friendly URLs
Independent of the web technology you use, implementing SEO (and human) friendly routes is important.
A good example is: /products/blazor-grid
And a bad example is: /page?id=42
You want URLs to be short but communicative. Meaningful routes help humans and machines to better understand the page content.
Routes should always be defined in lowercase and avoid random globally unique identifiers (GUIDs) in addition to object identifications.
In good applications, routes are as stable as possible. This means that overhauling a web application should not require a complete redesign of the URL structure. Otherwise, you will risk breaking existing links and bookmarks.
In Blazor, we use the @page directive with parameters to intuitively build those routes:
Performance Matters for SEO
Besides properly providing metadata and rendered HTML, performance is becoming an increasingly important factor in how websites rank in SEO.
Using Static SSR where possible and utilizing interactive islands, such as an interactive search box or a pricing calculator, is a modern architectural approach we should adopt for Blazor and other web development.
In practice, it means that we implement several components without interactivity (Static SSR) and apply an interactive render mode to specific components, such as the search box.
Clearly separating dynamic from static content provides many benefits, including better maintainability and performance.
Common Beginner Mistakes
Let’s discuss the four most commonly made mistakes I see beginners make when it comes to SEO for Blazor web applications:
Mistake #1: Choosing WebAssembly for Marketing Pages
Blazor WebAssembly is often not ideal for SEO-heavy content sites. It takes a long time to load, and makes rendering complex (prerendering).
Mistake #2: Forgetting Metadata Per Page
Every relevant page should at least have a title and description meta tag. For public-facing applications, I’d also add the Open Graph tags to each page.
Mistake #3: Rendering Content Only After API Calls
The page should appear as complete as possible without API-provided data. Crawlers will read the website without executing the API calls. For example: Always render the structure of a table even if you only load the content from an API call.
Mistake #4: Ignoring Semantic HTML
Even when using custom components, implementing proper HTML still matters. Using <main>, <article>, <section>, etc. helps establish a clear page hierarchy, helping with SEO and accessibility.
There are many more mistakes you can make, but those four cover the most important topics and get you started.
Why Blazor Prerendering Matters
This chapter applies only to Blazor WebAssembly applications. With prerendering, the web app is first rendered on the server and then rerendered on the client once the app is fully loaded.
This causes page flickering because the content is replaced during the second render cycle.
Prior to .NET 10, some developers disabled prerendering. However, without prerendering, no HTML is sent to the client before the page loads. This is bad for SEO, as we previously learned.
Starting with .NET 10, the PersistentState attribute helps mitigate this issue, allowing you to use prerendering without experiencing the flickering.
Hint: Always use prerendering when using Blazor WebAssembly to avoid SEO and performance issues.
Hint: Always use prerendering when using Blazor WebAssembly to avoid SEO and performance issues.
Practical Recommendations
Based on my experience developing Blazor web applications for more than six years across various settings, I recommend using Static SSR whenever possible.
For interactive components, consider the SEO implications and complexity you will add to the project by choosing Blazor WebAssembly over Blazor Server. For most projects, Blazor Server is a better option, at least in the early stages.
For completely internal applications, SEO might not be important to you. Still, accessibility and the preview you see when sharing links to internal applications might be reasons to implement the title, description and Open Graph tags across all your Blazor applications. As a best practice, I recommend always including those meta tags.
If you have to use Blazor WebAssembly for a valid reason, I highly recommend implementing prerendering properly. It is important for the application’s performance and usability, and it has SEO implications.
Conclusion
Selecting the right render mode, using the right metadata items and implementing SEO-friendly URLs are all essential steps to keep your application discoverable, accessible and performing well for users and search engines.
By following best practices, such as using Static SSR for public pages, properly managing metadata and leveraging prerendering when necessary, you can create highly optimized Blazor web applications.
Paying attention to these details will help your applications, whether they are public-facing or internal, and provide a better user experience.
If you want to learn more about Blazor development, watch my free Blazor Crash Course on YouTube. And stay tuned to the Telerik blog for more Blazor Basics.
