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.

Ajay Goel

Ajay is the founder of GMass and has been developing email sending software for 20 years.