Redirect Options

7

July 22, 2012 by Alistair Deneys

I almost can’t remember the last time I built a website and it was the first for an organisation. The internet is old enough now that everyone already has a website, so new builds now are to replace an existing web presence. Whenever replacing an existing site we need to consider how the changes could impact on Search Engine Optimisation (SEO) and in particular, how to maintain whatever rank your pages have already achieved.

One particular challenge in preserving the page rank is if the information architecture (page structure) of the new site will be different to the old. Search engines aside, you still need to help users of your site find their way in the new site. Perhaps it’s not a new site we’re building but instead we’re binding a new domain to the website and need traffic to be directed through to the new domain. In addition, what about existing incoming site links from other sites and user’s bookmarks. These also need to be preserved.

The most common tool of choice for this challenge is redirects. And more often than not, permanent (301) redirects. A 301 redirect instructs the users browser or the search engine that the particular resource they’ve requested has moved permanently to a different location. This helps the user get to the page they were after at the new location as well as having the search engines update their references to your site and it’s URLs.

There are a plethora of redirect options available when working with a Sitecore project. So which to choose…

The first question to answer is if the content author will be managing the redirects or an administrator. At the simplest, a redirect rule will contain a 1 to 1 relationship between the old page URL and the new page URL. And it only gets more complex from there:

“If the user enters on domain 1 and requests anything from the news section, they should redirect to the news search page with the page name prepopulated in the search field”

Something like the above rule would probably be too complex for a content author (well, a non-technical user) to manage. And after all, that’s not their job anyway. They should be focusing on the content.

Some questions to consider when choosing a redirect option:

  • Will administrators be managing the redirects or CMS users?
  • Will redirects be done 1 to 1 or will we need to implement complex rules?
  • Is the target Sitecore item likely to change name or path?
    Below is a list of several redirect modules which you could use to help manage the redirect rules.

Administrator Modules

The below modules are more appropriate for administrators or developers as they are both configured through the web.config file (or the IIS admin console for IIS URL Rewrite).

These modules are appropriate for all your complex rules that can cover many cases, or if only the administrator will be managing the rules.

IIS URL Rewrite

The IIS URL Rewrite module is an official Microsoft module for IIS. It allows administrators and developers to manage redirect rules either through IIS itself or through web configuration files. This module is good for complex rules as well as any rule to do with domain redirects. It can also handle request rewriting, presenting your application with a different URL than was requested by the user.

Let me just give you a quick example of when that might be useful. Let’s say we’re adding a language variant to our site. The main English site is hosted at http://www.mysite.com and now we’re adding a German version at http://www.mysite.de. Another SEO best-practise is to provide an XML sitemap file to help robots navigate all the pages of your site. A handy module for automatically generating this file in Sitecore is the Sitemap XML module.

Now although we can have multiple different sitemap.xml files of different names, all referenced from the robots.txt file, for some reason I want the language specific sitemap.xml files to be served from their respective domains. Using IIS URL Rewrite I can rewrite any requests for the sitemap.xml file for either domain to a different filename. To the outside world it looks like I’ve requested http://www.mysite.de/sitemap.xml but the URL that my application sees is http://www.mysite.de/sitemap-de.xml.

Being that this module is an IIS module, it must be installed. It’s also only available for IIS 7. So if you’re working on IIS 6 or previous, or if you don’t have access to install anything on your web server then perhaps the next module can help.

UrlRewriter.net

This one has been around a while, but can still come in handy when you’re running on IIS before version 6 or if you can’t install anything on your web server.

UrlRewriter.net is an HTTP Module handling redirect and rewriting rules from within your ASP.NET application. Because it’s a module it doesn’t need to be installed, simply drop the DLL (which you’ll need to compile from source) into the bin folder, some web.config updates and the module will be handling your requests.

I have in some cases had issues with this module cooperating with Sitecore. For example, when a request is made for an item which doesn’t exist in Sitecore and a rule is matched which produces a redirect, Sitecore would override the redirect with it’s own to the “item not found” URL. But seeing as though you need to compile the module from source, you can easily update that source before compiling to complete the current HTTP request before Sitecore get’s a go (call HttpContext.Current.ApplicationInstance.CompleteRequest() after the redirect is set).

CMS Modules

If you need authors to be able to manage the redirects or if you don’t have easy access to the config files, then you’ll need to expose the redirect functionality through Sitecore itself. And there are several modules available to handle your redirects inside Sitecore too.

One benefit some of the CMS modules have over the administrator modules is that you’re dealing with Sitecore items now, referencing them by ID rather than simple URLs in strings. This means that if the target item name changes, or if it’s path changes, the redirect doesn’t break and doesn’t need to be updated.

301 Redirect Module

The 301 Redirect Module allows creating both 1 to 1 mappings from old URLs to items as well as creating regular expression based redirects allowing a single rule to map multiple URLs onto multiple items.

The 1 to 1 mappings allow selecting a target item using a droptree field. The value of this field is an ID, so the rule will be resilient to name and path changes of the target item.

The regular expression rules (redirect-pattern rule) uses a regular expression to match the incoming URL and makes use of capture groups to perform a regular expression replacement to a Sitecore path.

The redirect rules are created inside the Sitecore content tree so they are easy to backup (serialise via the Developer tab in the content editor), put into source control through TDS or package and deploy via the Sitecore package manager.

Redirect Manager Module

The Redirect Manager Module allows creating 1 to 1 URL to item mappings. It includes UI integration with the content editor to easily display what redirects are pointing at the current item.

This module also supports “automatic redirects”, detecting when an item is moved or renamed and adding a redirect rule to ensure requests for the previous path still resolve to the item.

Unlike the other CMS modules the rules are stored in a SQL DB. This makes it a little harder to backup the rules (you can always use SQL tools to backup the DB), put them in source control or move the rules between servers.

Sitecore Redirect Manager Module

The Sitecore Redirect Manager Module is very similar to the 301 Redirect Module in that it allows creating rules to map between URLs and items.

Conclusion

The above gives a few options for implementing redirects on your Sitecore site and the reasons to use each.

I generally prefer to handle the redirects using the IIS URL Rewrite module as I normally find that most content authors don’t want to think about redirects and don’t need to manage them themselves. To be honest, I’ve never received a request from any content author to be able to create redirects themselves, this is normally an administrator task.

Advertisements

7 thoughts on “Redirect Options

  1. ricmanalac says:

    Hello Alistair. I have installed IIS URL Rewrite to our server, but it seems to be clashing with the Sitecore Nexus HTTP Module. Did you do any other extra configuration so that URL Rewrite and Sitecore can play nicely with each other? Thanks!

    • Alistair Deneys says:

      Hi Ric,
      I seem to recall someone telling me a while ago that they had issues with IIS URL rewrite and Sitecore 6.2. I haven’t used the module with that version of Sitecore, so I’ve not witnessed the behaviour myself. If that’s the case, then you may have to look into UrlRewriter.net. Though, using that module on IIS 7 I’ve witnessed some issues with the redirect not firing immediately and Sitecore still handling the request. In the end I had to download the source (you have to build from source anyway, no compiled release) and update it to abort the request if a redirect is set. However, I wasn’t able to reliably reproduce the issue later on when I was working on a proper patch for it…it seemed to just work…

      • ricmanalac says:

        Hi Alistair. Thanks for the response. I have tried URLRewriter.net as well and also encountered the issue that you have described. I just need to find the right spot to add the code to prevent Sitecore from double-handling the request.

        Cheers,

        Ric

      • Alistair Deneys says:

        Hi Ric,
        All I did to make this work for me was update the SetRedirectLocation() method on the HttpContextFacade class to complete the request once the redirect location was set. Here’s my updated method:

        namespace Intelligencia.UrlRewriter.Utilities
        {
        internal class HttpContextFacade : IHttpContext
        {

        public void SetRedirectLocation(string url)
        {
        HttpContext.Current.Response.RedirectLocation = url;
        HttpContext.Current.ApplicationInstance.CompleteRequest();
        }

        }
        }

        I would have liked to submit this update back to the module source but as I said I couldn’t reliably reproduce the issue on my dev box. I hope the above code helps. Let me know how you go.

  2. […] you may recall I recently blogged about redirect components that can be used with Sitecore? Yeah. Here’s the gotcha. Make sure your redirect rules aren’t […]

  3. Michael Green says:

    Alistair, it seems like the only method to handle 301 redirects with international versions of content in Sitecore is to use the IIS filter method? If you have redirects you have to setup for US, UK, FR and MX for example.

    • Alistair Deneys says:

      Hi Michael,
      Yes, I imagine the Sitecore language resolver may get in the way if you’re trying to setup a 301 for an international code as an alias within your site. As I mention in the conclusion, I prefer to use an IIS module to handle this kind of redirect as it’s more of a behaviour of the site rather than something an author would need to manage.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

The views expressed on this blog are solely my own and do not necessarily reflect the views of my employer.
%d bloggers like this: