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.
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.
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.
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).
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.
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.
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.
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.
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.