<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1822615684631785&amp;ev=PageView&amp;noscript=1"/>

A better way to get an IIS site to redirect to www and https

redirecting to www and https

If you’ve deployed sites to IIS, at some point, you probably Googled how to make your site redirect from the non-www to the www version and from the insecure http version to the more secure https version — meaning, if someone types http://yourdomain.com, you want them to be redirected to https://www.yourdomain.com.

In wanting this for my website, I read every article I could, but I didn’t find a technique that accomplished everything I wanted. This is how I did it.

Why care about redirecting to www and https?

Because you want to avoid having “duplicate content” on two or more technically different URLs for the benefit of SEO. If you have http://domain.com and https://www.mydomain.com serve up the same page, you will be penalized by Google because it’s now considered “duplicate content.” If, however, https://domain.com does a permanent 301 redirect to https://www.mydomain.com, then you’re following the best practice for SEO.

What’s wrong with other people’s solutions?

If you Google for this topic, you’ll find a few articles, like this Namecheap article. However, it only covers redirecting to https and not to www.

This Stack Overflow article has the right idea, but its recommended solution is to combine the forcing of www and SSL into one rule. I disagree with that because it doesn’t allow for the ease of setting up a development server at dev.domain.com, where www and SSL aren’t desired.

This ServerFault article only addresses the https redirection without taking into account the www issue.

This dinbror article does a great job, but it teaches you how to convert the www version to non-www, which is a rarer scenario than wanting to redirect the other way around.

My better way

Here’s what the URL Rewrite rules in my web.config look like. I have two separate rules, one for redirecting the non-www version to www, and one for redirecting the http version to https.

 
<rule name="https fixer" stopProcessing="true">
 <match url=".*$" />
  <conditions logicalGrouping="MatchAll">
   <add input="{HTTPS}" pattern="^OFF$" />
   <add input="{HTTP_HOST}" pattern="dev" negate="true" />					
  </conditions>				
  <action type="Redirect" url="https://www.gmass.co{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" />
</rule>
				
<rule name="www fixer" stopProcessing="true">
 <match url=".*$" />
  <conditions logicalGrouping="MatchAll">
   <add input="{HTTP_HOST}" pattern="www" negate="true" />
   <add input="{HTTP_HOST}" pattern="dev" negate="true" />
  </conditions>
  <action type="Redirect" url="https://www.gmass.co{REQUEST_URI}" appendQueryString="false" redirectType="Permanent" />
</rule>	

Why not put all this into one rule, as other articles have suggested? Because then, if you have a development server, like dev.domain.com, and you use the same web.config file, then it will attempt to redirect to https://www.dev.domain.com and you likely don’t want that. Instead, you want it so that if you’re on dev.domain.com, then no redirects occur, because you probably don’t want to purchase an SSL certificate for your development server. Of course, you could purchase a wildcard SSL cert that covers all sub-domains, but those are expensive.

By breaking the redirects into two different URL Rewrite rules, you can:

  1. Still ensure that non-www is redirected to www
  2. Still ensure that http is redirected to https
  3. Use the same web.config with your production and your development server, making it so that you don’t have to keep track of two config files.

Additionally, note that the domain, gmass.co is hard-coded into the redirect destination URL. That is intentional so that you only ever need one redirect instead of two to fix both the www and https issues. You might be tempted to use {HTTP_HOST} in its place, but if you do that, your results will be wonky, and in some cases, two redirects will be needed instead of one. The “https fixer” rule won’t redirect to the www version of the site, and the “www fixer” rule won’t direct to the https version of the site.

If you use “https://www.{HTTP_HOST}” in the “www fixer” rule, then that would work, but if you did that in the “https fixer” rule, then if the user went to http://www.domain.com, the user would get redirected to https://www.www.domain.com, and you don’t want two sets of wwws. Finally, if you use just {HTTP_HOST} in the “https fixer” rule, then if the user went to http://domain.com, the “https fixer” rule would trigger and redirect the user to https://domain.com, and then the “www fixer” rule would kick in to redirect the user to https://www.domain.com. That accomplishes the objective, but now you’ve sent the user through two redirects rather than just one. Hard coding your domain into the rule avoids these hassles.

Essentially the logic that you desire, in boolean English, is:

(non-www OR http) AND (not “dev”) THEN REDIRECT (https://www.gmass.co/{QUERYSTRING})

Of course, with URL Rewrite rules, you can’t use parentheses in your boolean logic. You’re restricted to using a match type of MatchAny or MatchAll. If you were to combine everything into one rule using MatchAll, that comes close to working, but it fails in the case of one condition already being true (www or https) but the other being false. Meaning, if the user goes to http://mydomain.com, the user will then be redirected to https://www.mydomain.com as you desire, BUT if the user goes to https://mydomain.com, the user will NOT be redirected to https://www.mydomain.com. Similarly, if the user goes to http://www.mydomain.com, the user will NOT be redirected to https://www.mydomain.com.

By using two individual rules, however, you can achieve the logic you want, which, in boolean English, is:

(non-www AND not “dev”)
redirect to www

(http and NOT “dev”)
redirect to https

See it in action

You can test this using various gmass.co URLs. If you go to http://gmass.co, you’ll be redirected to https://www.gmass.co. Be sure to turn on Chrome’s Developer Tools to see the Network tab so you can see where you’re actually being redirected. The latest versions of Chrome hide the “www” in the address bar, so you can’t always decipher the exact URL you’re visiting.

If you go to https://gmass.co, you’ll be directed to https://www.gmass.co. If you go to http://www.gmass.co, you’ll be redirected to https://www.gmass.co.

Email marketing, cold email, and mail merge inside Gmail


Send incredible emails & automations and avoid the spam folder — all in one powerful but easy-to-learn tool


TRY GMASS FOR FREE

Download Chrome extension - 30 second install!
No credit card required
Love what you're reading? Get the latest email strategy and tips & stay in touch.
   


4 Comments
  1. This is pretty cool. Can you share what the rules would be if you wanted to redirect WWW to non-WWW and HTTP to HTTPS?

    Thanks!

  2. First of all I want to say great blog! I had a quick question which I’d like to ask if you don’t mind. I was interested to know how you center yourself and clear your mind before writing. I have had trouble clearing my mind in getting my thoughts out there. I truly do take pleasure in writing but it just seems like the first 10 to 15 minutes tend to be wasted simply just trying to figure out how to begin. Any suggestions or tips? Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

Find out why GMass is the most popular Gmail mail merge tool in the world

Easy to learn. Easy to use. Packed with time saving, email enhancing features.

Try GMass for free Then check out the quickstart guide to send your first mail merge email in minutes!

GMass

Share This