SharePoint redirects revisited: using 301 instead of 302 (without code!)

Nearly a year ago I wrote an article about why you should be using permanent redirects (301) instead of temporary redirects (302) which are SharePoint defaults. Back then I presented a custom HTTP Module as a possible solution. Since then things changed a little: we have SharePoint 2010, which still has the same challenge, and we have IIS7 which allows us to get things done without a single line of code.

Using permanent redirects instead of temporary is important from the search engines optimization point of view and might help you increase the search results for your content. On the other hand deploying a custom HTTP Module that does the job correctly might be a too high price to pay. Since the code will be fired on every single request it is really really important that you do it right. Not surprisingly a common advice is to avoid custom HTTP Modules whenever possible. Luckily IIS7 provides with a great alternative that allows us to achieve similar results without a single line of code!

Permanent redirects with URL Rewrite

URL Rewrite is one of IIS7 extensions provided by Microsoft that allows you to configure URL rewriting and redirection on sites hosted on IIS. It is a free extension and can be downloaded from the IIS website. The important thing to notice is that it’s really the only thing that you need to replace our “legacy” HTTP module.

Once you have URL Rewrite installed on your Web Front End you can start the configuration process.

Important: Since URL Rewrite stores the configuration in web.config you will have to do the same configuration steps on all Web Front Ends if you work with a multi-WFE environment. Additionally you want to be extra careful when working with SPWebConfigModifications since they might break your URL Rewrite configuration.

When defining the URL Rewrite rules there are three different URLs that you have to take into account:

  1. Root URL, eg. http://publishing
  2. Site URLs with trailing slash, eg. http://publishing/ or http://publishing/press-releases/
  3. Site URLs without the trailing slash, eg. http://publishing/press-releases

Root URL

Let’s start off by taking care of the root URL. Since there is no path the rule for this URL is very easy:

^$

Which basically means empty URL. The Redirect URL should be set to:

{R:0}/pages/default.aspx

And the whole rule should look like this:

URL Rewrite rule configuration for the root URL.

As you can see we now get a permanent redirect from the root URL to the Welcome Page.

Firebug shows permanent redirect when requesting the site using the root URL.

URLs that end with a ‘/’

This is probably the most frequently used notation for site URLs. Using regular expressions we can define a simple rule that will match all URLs that end with a ‘/’:

(.*)/$

The Redirect URL should be set to:

{R:1}/pages/default.aspx

What basically means everything except the trailing slash plus the page URL. And the whole rule should look like this:

URL Rewrite rule configuration for URLs ending with slash.

And to confirm that, if we request the Press Releases subsite using http://publishing/pressreleases/ we will get a permanent redirect as well:

Firebug shows permanent redirect when requesting a subsite using a URL with trailing slash.

Site URLs without the trailing slash

Site URLs without the trailing slash are probably the trickiest part of the configuration. If you for example would create a rule opposite to the previous one (a URL that ends with a character different than ‘/’) the rule would indeed match site URLs without the trailing slash but also all URLs of all the pages, images, etc. What you really need is something a little more complex:

[^/]+\.[^/]+$

This rule will match any file with extension at the end of the URL. And because that’s exactly what we don’t want to match, you have to configure the rule to be applied whenever the requested URL doesn’t match the pattern:

URL Rewrite rule configuration for site URLs without the trailing slash.

The last thing you have to do is to set the Redirect URL to:

{PATH_INFO}/pages/default.aspx

and when you check the rule:

Firebug shows permanent redirect when requesting a subsite using a URL without the trailing slash.

once again you will see a permanent redirect.

Additional considerations

While the solution I’ve described in this article is relatively easy to configure and maintain there are a few considerations you should take into account before implementing this in your website.

Use with caution when variated

As you noticed I’ve hardcoded the site-relative page URL in all rules. While my previous solution based on a custom HTTP Module was retrieving the page URL from the site, it was performing worse than hard-coding the URL. The truth is, that the URL Rewrite rules don’t allow you to dynamically compose the Redirect URL.

The reason this is important when working with Variations is, that in every language the URL of the Pages Library, where Publishing Pages are stored is different: it’s Pages in English, Pagina’s in Dutch and Seiten in German. If you work with a website that uses Variation you might extend the sample rules I showed you so that all URLs will be redirected properly.

Locales

The same applies in the situation when you use multiple locales to create subsites. Although you won’t be using Variations, still sites created based on templates in different locales will have different names for their Pages Library: definitely something you want to take into account when configuring URL Rewrite rules.

Beware of the Welcome Page

One more case when you want to be extra careful is when using different names for the Welcome Pages. SharePoint 2010 allows users to configure the Welcome Page: they might stick with the standard default.aspx but they might choose something else like home.aspx or overview.aspx.

As I mentioned before, although using URL Rewrite with hard-coded Redirect URLs is better performing than dynamically retrieving the URL of the Welcome Page, it comes with the price of flexibility and functionality. Once you choose for URL Rewrite you have to educate your users that they cannot change the name of the Welcome Page because it will break the site.

Summary

Using permanent redirects instead of temporary redirects can help you improve the search results for your content. It can be achieved in many different ways, among which, through configuration using the URL Rewrite module for IIS7. Although this approach is pretty easy to configure it comes with some trade-offs that you should take into account before implementing it into production.

Technorati Tags: SharePoint 2010,SEO

Others found also helpful: