Sitecore Alias as Redirect

One feature of Sitecore that I have always disliked is Alias’s. On each page of a site, content editors have the ability to click an alias button on the presentation tab and add alternative urls for the page.

Alias Toolbar

Once added these will appear in the Aliases folder under system.

Alias

However all this accomplishes is multiple URLs existing for one page which is a big SEO no no.

Content editors like to do this in order to create simple URLs for things like landing pages. e.g. himynameistim.com/Sitecore but search engines hate it as they see multiple pages with the exact same content. As a result the value of each page gets lowered and appears lower in search engine results. What Content editors really want is to set up a 301 redirect so that they can have the simple URL but redirect users to the actual page on the site.

Aliases as Redirects

One solution is to updated the aliases functionality to cause a redirect to it’s linked item rather than resolve the page.

To do this we need to create a pipeline processor that inherits from AliasResolver.

using Sitecore;
using Sitecore.Configuration;
using Sitecore.Diagnostics;
using Sitecore.Pipelines.HttpRequest;
using System.Net;
using System.Web;
using AliasResolver = Sitecore.Pipelines.HttpRequest.AliasResolver;

namespace HiMyNameIsTim.Pipelines
{
    public class AliasAsRedirectResolver : AliasResolver
    {
		public override void Process(HttpRequestArgs args)
		{
			if (!Settings.AliasesActive)
			{
				return; // if aliases aren't active, we really shouldn't confuse whoever turned them off
			}

			var database = Context.Database;

			if (database == null)
			{
				return; // similarly, if we don't have a database, we probably shouldn't try to do anything
			}

			if (!Context.Database.Aliases.Exists(args.LocalPath))
			{
				return; // alias doesn't exist
			}

			var targetID = Context.Database.Aliases.GetTargetID(args.LocalPath);

			// sanity checks for the item
			if (targetID.IsNull)
			{
				Tracer.Error("An alias for \"" + args.LocalPath + "\" exists, but points to a non-existing item.");
				return;
			}
			var item = args.GetItem(targetID);

			if (database.Aliases.Exists(args.LocalPath) && item != null)
			{
				if (Context.Item == null)
				{
					Context.Item = item;
					Tracer.Info(string.Concat("Using alias for \"", args.LocalPath, "\" which points to \"", item.ID, "\""));
				}

				HttpContext.Current.Response.RedirectLocation = item.Paths.FullPath.ToLower()
					.Replace(Context.Site.StartPath.ToLower(), string.Empty);
				HttpContext.Current.Response.StatusCode = (int)HttpStatusCode.MovedPermanently;
				HttpContext.Current.Response.StatusDescription = "301 Moved Permanently";
				HttpContext.Current.Response.End();
			}
		}
    }
}

And patch in in place of the regular Alias Resolver.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <pipelines>
      <httpRequestBegin>
        <processor type="HiMyNameIsTim.Core.Pipelines.AliasAsRedirectResolver, LabSitecore.Core" 
                   patch:instead="*[@type='Sitecore.Pipelines.HttpRequest.AliasResolver, Sitecore.Kernel']"/>
      </httpRequestBegin>
    </pipelines>
  </sitecore>
</configuration>

The above code is adapted from a solution given by Jordan Robinson but with a bug fixed to stop every valid URL without an alias writing an error to the log file.

Advertisements

Updating the response headers on your 404 Page in Sitecore

A few weeks ago I blogged about how to create a custom 404 Page in Sitecore. Following on from that, one thing you may notice in the response header of your 404 Page is the status code is 200 Ok, rather than 404 Page not found.

When Sitecore can’t find a page what actually happens is a 302 redirect is issued to the page not found page, which as its an ordinary page will return a 200 Ok. Thankfully Google is actually quite good at detecting pages a being 404’s even when they return the wrong status code, but it would be better if our sites issues the correct headers.

Method 1

The simplest solution is to create a view rendering with the following logic and place it somewhere on your page not found page. This will update the response headers with the correct values.

@{
      Response.TrySkipIisCustomErrors = true;
      Response.StatusCode = 404;
      Response.StatusDescription = "Page not found";
}

However personally I don’t think this a particularly neat solution. The contents of a view should really be left for what’s going in a page rather than interfering with its headers, even if it does have access to the Response object.

Method 2

Rather than using a view my solution is to add some code to the httpRequestEnd pipeline that will check the context items Id against a setting where we will store the Id of the 404 page item in Sitecore and if the two match then update the response header.

The solution will look like this

Pipeline logic

using Sitecore.Configuration;
using Sitecore.Data;
using Sitecore.Pipelines.HttpRequest;

namespace Pipelines.HttpRequest
{
    public class PageNotFoundResponseHeader : HttpRequestProcessor
    {
        private static readonly string PageNotFoundID = Settings.GetSetting("PageNotFound");

        public override void Process(HttpRequestArgs args)
        {
            if (Sitecore.Context.Item != null && Sitecore.Context.Item.ID == new ID(PageNotFoundID))
            {
                args.Context.Response.TrySkipIisCustomErrors = true;
                args.Context.Response.StatusCode = 404;
                args.Context.Response.StatusDescription = "Page not found";
            }
        }
    }
}

Patch config file

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>    
    <pipelines>
      <httpRequestEnd>
        <processor
          patch:after="processor[@type='Sitecore.Pipelines.PreprocessRequest.CheckIgnoreFlag, Sitecore.Kernel']"
          type="Pipelines.HttpRequest.PageNotFoundResponseHeader, MyProjectName"  />
      </httpRequestEnd> 
    </pipelines>
    <settings>
      <!-- Page Not Found Item Id -->
      <setting name="PageNotFound" value="ID of 404 Page" />
    </settings>
  </sitecore>   
</configuration>

What’s the TrySkipIisCustomErrors property

Quite simply this stops a scenario where you end up on IIS’s 404 page rather than your own. If you don’t set this, when you update the header status code to 404, IIS likes to return the page from it’s settings rather than continuing with your own.

SEO Friendly URL’s in Sitecore

As silly as it seams to the average developer, URL’s are an important factor when it comes to SEO. As ridiculous as some of the requirements are (like not having spaces in a URL) they are unfortunately requirements that we have to live with. Here’s how to deal with not having upper case letters in a URL, replacing spaces with hyphens and getting rid of that pesky aspx extension.

Removing Spaces from a URL

A space in a URL actually gets translated to %20, which for the average user isn’t very readable. I would argue that as well as doing the translation, browsers could actually just hide this fact from users, and Google could also hide it as well. But alas that hasn’t happened and the accepted solution is to replace spaces with a hyphen.

Within a patch config file add the following:

    <encodeNameReplacements>
      <replace mode="on" find=" " replaceWith="-" />
    </encodeNameReplacements>

What this will do is replace every space in an items name with a hyphen as links are rendered. When a request comes into Sitecore it will also replace all hyphens with a space, so that the URL’s still resolve.

However this does cause a problem for any items you have that already had a hyphen in them. Sadly the best we can do for this is to stop content editors including hyphens in item names with the following config patch:

    <settings>
      <setting name="InvalidItemNameChars">
        <patch:attribute name="value">\/:?&quot;&lt;&gt;|[]-</patch:attribute>
      </setting>
    </settings>

Make URLs all lower case

Believe it or not URL’s are actually case sensitive. Maybe not in the Windows / IIS world, but with Linux and the rest of the web they are. So the simplest solution is to make all the URL’s on the site lower case.

Sitecore 6.6 and above

If your using Sitecore 6.6 or above then you in luck, there’s a config setting on the linkManager to set all urls to lower case

    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="sitecore">
          <patch:attribute name="lowercaseUrls">true</patch:attribute>
        </add>
      </providers>
    </linkManager>

Sitecore 6.5 and below

If you using 6.5 or below you need to do a little more work.

One way is using the same encodeNameReplacements config as we used before and replace every upper case letter in the alphabet with the lower case equivalent.


    <encodeNameReplacements>
      <replace mode="on" find="A" replaceWith="a" />
      <replace mode="on" find="B" replaceWith="b" />
      <replace mode="on" find="C" replaceWith="c" />
      <replace mode="on" find="D" replaceWith="d" />
    </encodeNameReplacements>

Personally this doesn’t seen the nicest solution and I expect will lead to a lot of replace functions being called.

Another solution is to create a class that overrides the Sitecores LinkProvider and simply makes the result of GetItemUrl lowercase

namespace YourNamespace.Providers
{
    public class LinkProvider : Sitecore.Links.LinkProvider
    {
        public override string GetItemUrl(Sitecore.Data.Items.Item item, Sitecore.Links.UrlOptions urlOptions)
        {
            return base.GetItemUrl(item, urlOptions).ToLower();
        }
    }
}

And then add a patch config to tell Sitecore to use your LinkManager rather than the default.

    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="sitecore">
          <patch:attribute name="type">YourNamespace.Providers.LinkProvider, YourProjectName</patch:attribute>
        </add>
      </providers>
    </linkManager>

Getting rid of the aspx extension

By default Sitecore puts a .aspx extension on the end of a url. Changing it is just a config setting:

    <linkManager defaultProvider="sitecore">
      <providers>
        <add name="sitecore">
          <patch:attribute name="addAspxExtension">false</patch:attribute>
        </add>
      </providers>
    </linkManager>

Creating a custom 404 Page in Sitecore

Nobody wants to see the standard Sitecore 404 page. Thankfully it’s really easy to change the error pages a user is redirected to through some config settings.

Your error pages can be pages in Sitecore or static HTML files. For 404 pages I would normally use a Sitecore page, that way content authors can still manage its content. For an Error Page I would recommend a static html file to avoid issues with the Error page potentially error-ing.

Add these to a patch file and update the urls accordingly:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
      <!--  ITEM NOT FOUND HANDLER
            Url of page handling 'Item not found' errors
      -->
      <setting name="ItemNotFoundUrl">
        <patch:attribute name="value">/ErrorPages/404.html</patch:attribute>
      </setting>
      <!--  LINK ITEM NOT FOUND HANDLER
            Url of page handling 'Link item not found' errors
      -->
      <setting name="LinkItemNotFoundUrl">
        <patch:attribute name="value">/ErrorPages/404.html</patch:attribute>
      </setting>
      <!--  LAYOUT NOT FOUND HANDLER
            Url of page handling 'Layout not found' errors
      -->
      <setting name="LayoutNotFoundUrl">
        <patch:attribute name="value">/ErrorPages/404.html</patch:attribute>
      </setting>
      <!--  ERROR HANDLER
            Url of page handling generic errors
      -->
       <setting name="ErrorPage">
        <patch:attribute name="value">/ErrorPages/Error.html</patch:attribute>
      </setting>
    </settings>
  </sitecore>
</configuration>


These settings are already defined in the web.config file and changing them here will have the same effect, but I recommend adding patch config files as it will make your solution easier to update in the future.