ASP.NET Core MVC SEO-Framework

Following my last post on my ASP.NET MVC SEO-Framework I started looking at adding support also for ASP.NET Core MVC, with its superior Dependency Injection and Tag Helpers.

The previous post shows examples on how to use attributes to set SEO-specific values for Controller-Actions and in Views, which is also used in ASP.NET Core MVC. What is new to Core MVC is how you register the SEO-helper as a Service for Dependency Injection and use Tag Helpers instead of HTML Helpers.

To register the SEO-helper as a service for Dependency Injection you just need to use the framework's provided extension-method in the ConfigureServices-method inside Startup.cs:

public class Startup
    public void ConfigureServices(IServiceCollection services)


These SEO-values can easily be accessed and rendered as HTML-tags inside Views through provided Tag Helpers:

    <seo-title />

    <seo-link-canonical />
    <seo-meta-description />
    <seo-meta-keywords />
    <seo-meta-robots-index />

To access these Tag Helpers you need to reference them in you _ViewImports.cshtml:

@addTagHelper *, AspNetSeo.CoreMvc
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

See the README-file on GitHub for the latest detailed information about this ASP.NET SEO-framework. Or try it out through Nuget by running Install-Package AspNetSeo.CoreMvc or Install-Package AspNetSeo.Mvc in your project. You can even follow the absolutely latest build on MyGet.


For any serious web-application you should always implement a solid Search engine optimization-strategy, but there is no standardized way to handle this in ASP.NET MVC, out of the box.

You could easily use the ViewBag-object to send dynamic values from Controller-Actions into Views, like this, for example:

public ActionResult Index()
    this.ViewBag.PageTitle = "This is the page title";

    return this.View();

Then you'd have to make sure you correctly spell or copy-paste ViewBag.PageTitle correctly into your View:

    <!-- More head-values -->

One problem is that if you refactor the naming for ViewBag.PageTitle into, for example ViewBag.Title, this will break the functionality, potentially website-wide, because you won't get any tooling-help from Visual Studio for that rename.

This is why I created a framework for ASP.NET MVC SEO, to get structured and reusable functionality around the SEO-data for a web-application. The framework is available on Nuget, with the source-code on GitHub.

Setting SEO-values

You can set SEO-values using the properties on a SeoHelper-object in Controller-Actions and Views, or you can use ActionFilter-attributes in Controllers, to set SEO-related data like:

  • Meta-Description
  • Meta-Keywords
  • Title, split on page-title and base-title (website-title)
  • Canonical Link
  • Meta No-index for robots

This can be done inside Controllers and Controller-Actions:

[SeoBaseTitle("Website name")]
public class InfoController : SeoController
    [SeoTitle("Listing items")]
    [SeoMetaDescription("List of the company's product-items")]
    public ActionResult List()
        var list = this.GetList();

        if (list.Any())
            this.Seo.Title += $" (Total: {list.Count})";
            this.Seo.LinkCanonical = "~/pages/list.html";
            this.Seo.MetaRobotsNoIndex = true;

        return this.View(model);

If you don't want to inherit from SeoController to get access to the this.Seo-property, you can use the extension-method GetSeoHelper:

public class InfoController : Controller
    public ActionResult List()
        var seo = this.GetSeoHelper();

        seo.Title = "Page title";

        return this.View(model);

You can even set SEO-values inside Views:

    this.Layout = null;
    this.Seo.MetaRobotsNoIndex = true; // Always block Robots from indexing this View

Rendering SEO-values

These SEO-values can easily be accessed and rendered as HTML-tags inside Views through provided HtmlHelper-extensions:



See the README-file on GitHub for the latest detailed information about this ASP.NET MVC SEO-framework. Or try it out through Nuget by running Install-Package AspNetSeo.Mvc in your project. You can even follow the absolutely latest build on MyGet.

IIS URL Rewrite-Rules Skipping Files-types

IIS Welcome

If you need to put in a rule for the IIS URL Rewrite Module, but need the rule to skip some file-endings and/or targets that are directories or actual files on disk, this is the post for you.

Following some SEO best-practices that tells us to use trailing slashes on our URLs I used the IIS Manager and added the IIS URL Rewrite-module's built-in rule "Append or remove the trailing slash symbol", which creates the following rule:

 <rule name="Add trailing slash" stopProcessing="true">
  <match url="(.*[^/])$" />
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
  <action type="Redirect" redirectType="Permanent" url="{R:1}/" />

This rule takes into account and doesn't apply the rule to files and directories that exists on disk. But there is a big problem with this generic rule.

If you are dynamically serving up files with extensions, then an URL like:

will become:

Adding conditions for specific file-endings

To solve this you can add conditions for certain file-endings, like .html and .aspx:

  <!-- ... -->
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.html$" negate="true" />
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.aspx$" negate="true" />

Since the rules above already don't apply for files physically on disk, you don't need to add file-endings like .css, .png or .js.

Update: Match ANY file-ending

If you want to match just any file-ending at all, you use the following pattern:

  <!-- ... -->
  <add input="{URL}" pattern=".*/[^.]*\.[\d\w]+$" negate="true" />

Guidelines for URI Design

Jacob Gillespie has worked on a post concerning URL Guidelines, that underwent much revision and was posted as a guest post on CSS-Tricks named Guidelines for URI Design.

Clean URIs are one component of a clean website, and it is an important one. The majority of end-user access to the Internet involves a URI, and whether or not the user actually enters the URI, they are working with one nonetheless.

Here is an outtake of the general principles of the article:

  • A URI must represent an object, uniquely and permanently - The URI must be unique so that it is a one-to-one match – one URI per one data object.
  • Be as human-friendly as possible - URIs should be designed with the end user in mind. SEO and ease of development should come second.
  • Consistency - URIs across a site must be consistent in format. Once you pick your URI structure, be consistent and follow it!
  • “Hackable” URIs - Related to consistency, URIs should be structured so that they are intelligibly “hackable” or changeable.
  • Keywords - The URI should be composed of keywords that are important to the content of the page. So, if the URI is for a blog post that has a long title, only the words important to the content of the page should be in the URI.

When it comes to technical details, here are their concerned bullet-points:

  • No WWW - The www. should be dropped from the website URI, as it is unnecessary typing and violates the rules of being as human-friendly as possible and not including unnecessary information in the URI.
  • Format - Google News has some interesting requirements for webpages that want to be listed in the Google News results – Google requires at least a 3-digit unique number.
  • All lowercase - All characters must be lowercase. Attempting to describe a URI to someone when mixed case is involved is next to impossible.
  • URI identifiers should be made URI friendly - A URI might contain the title of a post, and that title might contain characters that are not URI-friendly. That post title must therefore be made URI friendly. [...] Spaces should be replaced with hyphens.

Scott Mitchell has written an article on about Techniques for Preventing Duplicate URLs in Your Website.

A key tenet of search engine optimization is URL normalization, or URL canonicalization. URL normalization is the process of eliminating duplicate URLs in your website. This article explores four different ways to implement URL normalization in your ASP.NET website.

The important subjects of this article are the following:

  • First Things First: Deciding on a Canonical URL Format - Before we examine techniques for normalizing URLs, and certainly before such techniques can be implemented, we must first decide on a canonical URL format.
  • URL Normalization Using Permanent Redirects - [...] when a search engine spider receives a 301 status it updates its index with the new URL. Therefore, if anytime a request comes in for a non-canonical URL we immediately issue a permanent redirect to the same page but use the canonical form then a search engine spider crawling our site will only maintain the canonical form in its index.
  • Issuing Permanent Redirects From ASP.NET - Every time an incoming request is handled by the ASP.NET engine, it raises the BeginRequest event. You can execute code in response to this event by creating an HTTP Module or by creating the Application_BeginRequest event handler in Global.asax.
  • Rewriting URLs Into Canonical Form Using IIS 7's URL Rewrite Module - Shortly after releasing IIS 7, Microsoft created and released a free URL Rewrite Module. The URL Rewrite Module makes it easy to define URL rewriting rules in your Web.config file.
  • Rewriting URLs Into Canonical Form Using ISAPI_Rewrite - Microsoft's URL Rewriter Module is a great choice if you are using IIS 7, but if you are using previous version of IIS you're out of luck.
  • Telling Search Engine Spiders Your Canonical Form In Markup - Consider a URL that may include querystring parameters that don't affect the content rendered on the page or only affect non-essential parts of the page.
    In the case of YouTube, all video pages specify a <link> element like so, regardless of whether the querystring includes just the videoId or the videoId and other parameters:
    <link rel="canonical" href="/watch?v=videoId">

ASP.NET WebForms SEO: Compressing View State

In my previous post about Moving View State to Bottom of the Form I touched on one way to do some Search Engine Optimization in ASP.NET WebForms. Another thing you can do is to compress large View States on a page.

All the code in this article should be put in a class inheriting from System.Web.UI.Page. Like a page's Code-behind file or your own PageBase-class.

First we need some common logic for both loading and saving a compressed View State, the name of the hidden field to use.

private const string ViewStateFieldName = "SEOVIEWSTATE";

We start with the loading-part, where you see the use of my implementation of the CompressionHelper-class, which simplifies compression. It also solves the issue with DeflateStream and GZipStream inflating already compressed data, which is resolved in .NET Framework 4.

protected override object LoadPageStateFromPersistenceMedium() {
    return LoadCompressedPageState();

private object LoadCompressedPageState() {
    string viewState = Request.Form[ViewStateFieldName];
    if(string.IsNullOrEmpty(viewState)) {
        return string.Empty;

    byte[] bytes = Convert.FromBase64String(viewState.Substring(1));

    bool isCompressed = Convert.ToBoolean(Convert.ToInt32(viewState.Substring(0, 1)));
    if(isCompressed) {
        bytes = CompressionHelper.Decompress(bytes);

    string decompressedBase64 = Convert.ToBase64String(bytes);

    ObjectStateFormatter formatter = new ObjectStateFormatter();
    return formatter.Deserialize(decompressedBase64);

We then move on to the implementation of saving the page's state.

protected override void SavePageStateToPersistenceMedium(object state) {

private void SaveCompressedPageState(object state) {
    byte[] viewStateBytes;
    using(MemoryStream stream = new MemoryStream()) {
        ObjectStateFormatter formatter = new ObjectStateFormatter();
        formatter.Serialize(stream, state);
        viewStateBytes = stream.ToArray();

    byte[] compressed;
    bool successfulCompress = CompressionHelper.TryCompress(viewStateBytes, out compressed);
    string compressedBase64 =
        Convert.ToInt32(successfulCompress) + Convert.ToBase64String(compressed);

    ClientScript.RegisterHiddenField(ViewStateFieldName, compressedBase64);

So the summary is that this will compress the View State of an ASP.NET WebForms page, if the View State is large enough. Otherwise it will just keep it the way it is.