Got Redirects? Successful Redirect Governance in Sitecore

Redirects are a helpful mechanism for managing moved pages, sub domain management (ex. non www to www or vice versa) and helping direct users to the desired destination. They also assist with maintaining “link juice” from an SEO perspective. However, they are also a crutch that can lead to an unmanageable mess that is never cleaned up… risking your user journeys, performance, and potentially causing a site down.

Do I Have a Redirect Problem?

Do you have redirects? Then you have a redirect problem… at least not yet, but you need to do a few immediate things to prevent a nightmare from beginning. This starts with documenting your redirects in an Excel document with the following fields:

• Redirect Name – Having the name of the redirect helps to reference the redirect (Ex. Redirect Page X to Page Y)
• Redirect Purpose – Beyond the name, clearly define its purpose. Is this for a promotion, old page to new page (301), domain management (ex. non www to www)?
• Redirect From URL – List the full URL you are redirecting from. Note that if you have multiple URLs going to the same “To” URL you should still list a redirect per line as the source “From” URL matters
• Redirect To URL – List the full URL you are redirecting to.
• Redirect Retention – How long will the redirect be used? In many page level redirects, you may not want them to be in use forever, but rather have your end users navigate to the desired pages directly. While 301s signal a permanent redirection and are SEO allowed, every time you rebrand or change a path you can end up with more redirects… and a huge amount of redirects can lead to issues.
• Redirect Location – Where is the redirect located? Is it on an edge device like CloudFlare? an F5 Load Balancer? Sitecore server?

With the current redirects documented, you need to create a governance policy and standard for how redirects are added/managed in your environment. This should be focused on making it somewhat difficult to obtain a redirect in order to really focus on if the redirect is required. To that end, it is not recommended to allow users, like content authors to add their own redirects… as it’s a dangerous governance precedence that lacks centralized control.

Rebranding is an instance where you likely need the redirects (at least for a while… see the section on killing redirects later in this article), but other redirects need to be evaluated to determine if they are truly needed or if they are “redirects for the sake of redirects” versus allowing new pages to stand on their own.

Note: Some redirects, especially www to non www or vice versa should be easier to add, as this is base domain redirect management, but should still go through the governance process.

Check out the following to learn more about governance and get a governance template: Sitecore Governance: How To and a Template Too

When Are Redirects a Problem?

So when are redirects a problem? When they can cause some of the following issues:

• Redirect loops – When you have too many redirects, or improperly create a redirect (happens more than you think), you can end up in a redirect loop where pages or even entire domains just constantly redirect and redirect… potentially to the point of taking a site down
• Performance impact – Redirects can impact performance, while a few may not, imagine a number like 5,400 and how this could definitely cause a performance challenge
• Ever growing redirects and poor management – With more variables, you are more likely to have an issue. Undocumented and ever-growing redirects lead to poor management as no one can keep up… which just adds to technical debt
• Increases load times from the redirect – A redirect can cause an increase in load time, at first it may be small, but get a few redirect chains and problems abound… which leads to…
• Redirect chains – Too many redirects can cause your site to not load as you have a redirect pointing to another redirect, etc. and Google won’t be able to index this (in fact, this and redirect loops will hurt your SEO)

Where to Apply Redirects

Where redirects should be applied can be a contentious discussion. Some prefer to add them all to edge devices to prevent load on application servers (or app services) and not wait for a redirect to be executed on machine to flow back out to the edge device.

Others prefer to centrally manage all redirects on the application server and are prepared to absorb the performance impact.

Some follow a hybrid approach where domain and subdomain redirects, like non www to www and vice versa, are managed on the edge device and page level redirects are managed on the application server as part of its Web.config or Web.config using an IIS Rewrite Map.

Whatever path you choose, ensure you have clear rationale and track what redirects are where, as you should centralize redirects where possible. If you take a hybrid approach, this could mean domain redirects on edge devices and page redirects on the application servers.

When To Kill a Redirect

This one is tough, but there is a time to kill to a redirect. A few instances come to mind:

• Is the page you are redirecting from of low SEO value/page rank?
• Is your new page ready to stand on its own as enough time has passed that Google recognizes that this new page is the authority and not the old redirect?
• Is the redirect event based and the event has now passed (ex. a promotion)?
• Are old sites no longer pointing to the redirects but have updated to the new URL?
• Does most of your traffic come from search results vs. direct links that hit your redirect URL? This is an important nuance since if most of your traffic is from search (including search ads), then who would be clicking on your redirect? If the answer is low to no one, shut down the redirect.

In fact, John Mueller of Google weighed in on when to kill redirects with helpful advice that also leans towards a retention policy for redirects:

A good read about 301s and how long to keep them can be found at: How Long Should You Keep a Redirected (301) URL before Shutting it Down? – HigherVisibility.

The key point is that you should keep redirects for as long as they are useful, and you need to track your redirects with a clear retention policy and careful approach before removing them using the criteria listed in the first part of this section.

What About Empowering Content Authors with Rewrite Tools?

While you can offer content authors the ability to create their own rewrites via a module like: https://github.com/iamandycohen/UrlRewrite, should you?

From a governance perspective it is not recommended to allow content authors to create their own rewrites/redirect rules, as they may lack visibility into other redirects that can conflict with each other, it’s harder to know when they are created/track, and it creates an atmosphere where redirects are created with not as much consideration as they should have.

To that end, it’s critical that you create a clear and communicated governance policy and standard for redirects where a Sitecore Administrator or other centralized resource creates a redirect after it has been reviewed, documented, and approved as part of your governance process.

Conclusion

Governing redirects is a nuanced topic, but one that can lead to better management of your redirects while reducing risk and performance.

Bottom line, redirects are a very useful tool and required in many instances, but they require governance and regular pruning to reduce your technical debt and keep a clean SEO presence.