22

For the purpose of this conversation, let's leave URL rewriting that doesn't result in a browser redirect off the table.

Here are a number of URL Redirect scenarios that are regularly encountered for SEO purposes. Which ones should be handled by IIS UrlRewrite and which should be implemented by the Sitecore developer (using off-the-shelf or custom modules)

  1. Canonical Hostnames ex: mysite.com 301 to www.mysite.com
  2. Replacement Hostnames ex: myoldhostname.com 301 to mynewhostname.com
  3. Enforcing HTTPS ex: http://host.com 301 to https://host.com
  4. Marketing URLs ex: /myshortpath 301 to /the/actual/path/to/item
  5. Dead URLs ex: /myoldpage 301 to /mynewpage
  6. Relocated Branches ex: /myoldbranch/* 301 to /mynewbranch/here/*

(other scenarios welcome!)

Improve this question
5
  • 1
    An argument can also be made that enforcing ssl should be done at the load balancer level. – Pete Navarra Oct 25 '16 at 18:24
  • One other scenario to consider is when you move an item from one location to another and it accepts querystring parameters. Most Sitecore implementations I've seen don't handle the querystrings well on the redirect. Usually this requires an IIS rewrite rule to enforce the preservation of the querystring params. – Jason St-Cyr Oct 25 '16 at 19:23
  • @JayS - It's not that a Sitecore-based solution can't handle the querystring, they're just not written to do so. I would argue that if you're protecting 404'd querystrings, you need to revisit your SEO URL strategy. – Sergeant Sitecore Oct 25 '16 at 19:25
  • I guess I've just seen too many 'older' sites have things like "productid=12345" in the old URL and then they transition the page to another location but still need to keep that querystring. Ideally, yes, transition to a more SEO-friendly url, but that's not always available as an option. – Jason St-Cyr Oct 25 '16 at 19:28
  • For those, I'd consider building a Handler or Pipeline Processor, but not make them content-based redirect rules. – Sergeant Sitecore Oct 25 '16 at 19:32
23

Using IIS URL Rewrite (or firewall/load balancer/CDN) is appropriate for all domain-name and protocol changes (i.e. everything to the left of "/"). This covers #1, #2, and #3 from your list.

I'd argue that Sitecore should be used for any redirect (other than the above redirects) that editors/authors are responsible for. Putting those redirects in Sitecore allows the editors/authors to change the redirects without asking IT/development to make any changes. This covers #4, #5, and #6 in your list.

Improve this answer
3
9

If it was my decision I would insist that everything that is configured once and you don't plan to change it (like 1, 2 and 3 from your list) always should be set before they even hit Sitecore. IIS UrlRewrite module is one of the options. No points in wasting any IIS resources for them. They won't be changed by authors, editors, marketers or administrators anyway.

All the things which can be changed frequently, should go to Sitecore. This way authors/editors/whateverwecallthem can manage urls in one place and adding new rule doesn't require application restart (like it is with web.config changes).

Your 4, 5 and 6 doesn't necessarily fit to either of those sets above. There is no one good solution here. You should always think of what is best in your scenario.

Improve this answer
4

As developers, we sometimes too focused on our application and forget about other cool tools we have around us. In your question you are referring to two options - IIS and Sitecore, but there is at least one more.

I am talking about network hardware that handles traffic between user and IIS. It is not uncommon to find 'smart' Load Balancer or Firewall that is already implemented as part of the solution and can perform 301 redirects. Ask your IT team if you are not sure. If it is not there yet, you have one more reason to install one.

Moving 301 redirects away from application is preferable option for me for number of reasons:

  • In case you have Web Farm (2+ CD servers), implementing rules in IIS will require repeating work on every CD server. With Load Balancer you need to do it only once.
  • URL Redirect module can update web.config file and trigger Sitecore restart and site downtime.
  • Network implementation has much better performance and secutiry. IIS and Sitecore pipelines are designed for more complicated scenarios and not so efficient.
  • Application and Redirects are two separate concerns and splitting them into two independent components make solution more manageable
  • It looks better on deployment diagram :)
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.