In Sitecore solutions there are often requirements around the URL structure or domain on which the site will live. This is often driven by SEO and perhaps the Sitecore site even needs to share the same domain with a non-Sitecore site. This article will look at several common options and will explain when they should be used.

Below flowchart shows which option to choose depending on your needs. None of the options are mutually exclusive and they can be combined to meet multiple requirements:

Option 1: Reverse proxy/application gateway

In some cases requirements are more complex, for example your company’s Sitecore site needs to be hosted at mycompany.com but complete different servers needs to host mycompany.com/careers. This might not even be an IIS site but a site hosted on Apache or Nginx.

There are several ways to do this depending on the infrastructure which is in place. If Sitecore is hosted in the cloud here are some options which can route the traffic accordingly to prevent it from even hitting IIS

• Azure Application Gateway is a load balancer which can route traffic based on attributes in the HTTP Request
• AWS Application Load Balancer is an HTTP load balancer which can route traffic to a different target based on the HTTP Request

In an on-premise setup there might be similar infrastructure which can do this routing. IIS can also do this routing through the Application Request Routing (ARR) extension. In general routing this traffic away before it hits IIS is the preferred solution as it reduces the load on IIS.

Below is a sample reverse proxy rule in ARR which will route all traffic under /Careers to http://internalcareersite. This is all achieved through the routing and the site will be exposed over mycompany.com/careers:

<rewrite>
    <rules>
        <rule name="Reverse Proxy to Careers" stopProcessing="true">
            <match url="^Careers/(.*)" />
            <action type="Rewrite" url="http://internalcareersite/{R:1}" />
        </rule>        
    </rules>
</rewrite>

Option 2: IgnoreUrlPrefixes setting

The IgnoreUrlPrefixes setting tells Sitecore which Paths to exclude from Sitecore. This setting comes in handy if there is another site which needs to be hosted on the same domain, and the site can be hosted in the same IIS site as Sitecore. This is often an easy solution which can be helpful in many circumstances.

It can be challenging to update this setting in a clean way as there are already a number of entries of Sitecore in this setting. This article provides a good solution to only patch in your solution specific values.

URL Rewrite/Redirect

Before diving into the next few options let’s be clear on the difference between a redirect and a rewrite:

• Redirect: a redirect happens when the servers responds to the client/browser and tells it to load a page or resource from a different location. The client can then retrieve the resource from the location provided by the server. For example, you can have a vanity URL at mycompany.com/mycampaign which redirects to mycompany.com/some/long/path/mycampaign
• Rewrite: a rewrite is when IIS modifies an incoming request before it hands it off to its handlers (inbound rewrite) or modifies an outgoing response before it sends it to the client (outbound rewrite). In this case there are no additional request/responses like there are in case of a redirect.
  An example of this could be to rewrite all the incoming request starting with mycompany.com/english to mycompany.com/en-us. In this case the URL in the browser would be mycompany.com/english, but on Sitecore it would appear as if it came at mycompany.com/en-us as IIS modified it before handing off to Sitecore. These techniques can be powerful in a variety of situations, for example to have different URL structure then what Sitecore OOTB supports with language and sites.

There are a variety of Sitecore modules which can help with redirects which are managed in Sitecore, SXA also has a redirect module. Also IIS has a redirect/rewrite extension which is already a prerequisite for Sitecore installations.

3. Rewrite through IIS rewrite module

Sometimes it can be challenging to meet certain URL requirements with Sitecore without making any customizations, for example there might be a need to have the language in the URL as /english or /spanish etc. Implementing this in Sitecore can be complex as it requires customizations to processor(s) in the httpRequestBegin pipeline as well as the logic to generate links correctly. Below inbound and outbound rewrite rule will have the URL as /english but to Sitecore it appears as /en-us.

An important consideration when doing this is that in Sitecore the links will still show as /en-us, for example in the analytics.

Inbound rule: to make sure /english and anything after it gets send to /en-us on the same path, e.g. /english/products will go to /en-us/products:

<rewrite>
	<rules>
		<rule name="Englist to en-us">
			<match url="^english/(.*)" />
			<action type="Rewrite" url="en-us/{R:1}" />
		</rule>
	</rules>
</rewrite>

Outbound rule: to make sure any link in an anchor text gets “en-us” replaced with “english”. Depending on your setup more rules might be required to update the links in other places:

<rewrite>            
	<outboundRules>
		<rule name="Update en-us to english in anchor">
			<match filterByTags="A" pattern="^/en-us/(.*)" />
			<action type="Rewrite" value="/english/{R:1}" />
		</rule>
	</outboundRules>
</rewrite>

Option 4: Redirect through IIS Rewrite module

Some redirects rarely change and therefore are not managed by content authors, for example a redirect from http to https, to lowercase URLs or to enforce a trailing slash. In such cases it makes sense to have the redirects in IIS as it is acceptable to update these only with a deployment. Another advantage of doing this through IIS is that the request never hits Sitecore, it gets redirected straight from IIS which is more efficient. Below is a sample IIS redirect which redirect from http to https:

<rule name="Redirect to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
	<match url="*" ignoreCase="true" negate="false" />
	<conditions logicalGrouping="MatchAny" trackAllCaptures="false">
	  <add input="{HTTPS}" ignoreCase="true" matchType="Pattern" negate="false" pattern="OFF" />
	</conditions>
	<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" />
</rule>

Option 5: Custom Sitecore processors

Sometimes there is a need to do something similar to a rewrite (option 3), but it cannot be done with the rewrite module because it requires information from the Sitecore context. In this case perhaps the OOTB item resolution logic does not resolve the desired item or a different context language or site needs to be set. Before getting into more detail here are some common use cases:

• Sitecore’s language or site resolution logic does not meet the requirements. For example the language does not need to come from the URL but from the Sitecore IP Geolocation service.
• A Single Page Application (SPA) is used which uses push-state. In this case it is common to want to deep link into these push state route. For example the SPA could live in mycompany.com/myspa, with myspa being the Sitecore item. There could be a route like /myspa/filter/category1. Sitecore would try to resolve an item under that path but it is not there so it would return a 404. In this case the Sitecore ItemResolver can be customized to still resolve the correct item. An more detailed approach for this can be found here

In these cases the correct Sitecore processor needs to be updated. Below are the 3 most common processors which need to be updated. They are all part of the HttpRequestBegin pipeline:

• Sitecore.Pipelines.HttpRequest.SiteResolver: as the name suggests this processor resolves the site from the context. This processor serves as a good starting point to adjust the resolution of the context site.
• Sitecore.Pipelines.HttpRequest.LanguageResolver: the language resolver determines the correct language based on the context. The default Sitecore language resolution can put some constraints on the URL structure as the language needs to match a culture. Often business wants user friendly language in the URL like English, Spanish, French etc. In these cases customizing the language resolver can be a good option.
• Sitecore.Pipelines.HttpRequest.ItemResolver: this resolves the context item in Sitecore and might be the most customized processor in Sitecore to solve a variety of different issues. There are even some popular modules that customize this like the wildcard module

Updating Sitecore processors can be tricky as they can also run outside the scope of your solution, for example when a user logs into Sitecore CMS (/sitecore/login). If possible it is a good idea to keep the existing logic as is, but run additional code in case the existing resolution fails because the custom solution requirements are different.

Updating these processors will ensure Sitecore handles incoming requests correctly, however the links Sitecore generates to other pages will not take this logic into account. To ensure these links work correctly there are 2 options:

• Put in a redirect to send the links to the correct location
• Override Sitecore’s logic to generate links by putting in a custom link provider or a custom renderfield pipeline

Option 6: Sitecore Redirect Module

In many cases the content authors need to manage redirects along with other content updates they make in Sitecore. In these cases it is recommended to manage the redirects in Sitecore content as well. There are a variety of Sitecore modules which can help with redirects and SXA also has a redirect module.

HTML caching is arguably the best way to improve Sitecore performance. Sometimes you can run into issues when you enable HTML cache on a rendering and the rendering has been added to the same page multiple times. This will only happen if the renderings do not have a datasource or share the same datasource, but will still render different content. This could happen for example when the renderings have different rendering parameters or have some custom logic which changes the content.

This can be fixed in a generic way by overriding the GenerateKey method of the GenerateCacheKey RenderRendering Processor. Below code will add the UniqueId of each rendering to the cachekey which will ensure the cached output is unique for each rendering.

using Sitecore.Mvc.Pipelines.Response.RenderRendering;
using Sitecore.Mvc.Presentation;

namespace Foundation.Pipelines.RenderRendering
{
    public class GenerateCustomCacheKey : GenerateCacheKey
    {
        protected override string GenerateKey(Rendering rendering, RenderRenderingArgs args)
        {
            var cacheKey = base.GenerateKey(rendering, args);

            cacheKey += rendering.UniqueId;

            return cacheKey;
        }
    }
}