Setting Up Episerver To Always Use WWW Links

Probably, one of the most forgotten about features developers forget to set-up is to enforce either a WWW or non-WWW Url strategy on a website. The WWW/non-WWW debate has been waging for years and a lot of my non-technical clients are unsure of what is the difference between www vs non-www URLs in terms of Episerver site URLs?

I don’t think the confusion is just non-tech people related and I’m sure there are a few developers out there who, if they owned up, are still a bit unsure about which one is ‘better’and what strategy they should pick for Episerver and SEO. In today’s guide, I’m going to go into this topic in a bit more detail to hopefully help you understand the difference between www vs non-www and which one is better for Episerver SEO.

What Is The Difference Between WWW and non-WWW URLs?

If you haven’t come across this topic before, it’s all based on how you should structure your websites URLs; for example, should your links have www. at the front like this, http://www.website .com, or should you make your links slightly shorter and remove the www. part, like this URL http://website.com.

Google have stated that they will penalise websites if they allow both types of URLs because a search engine might see it as duplicate content. In terms of an SEO strategy for your website, having the right strategy is key to getting a good page ranking in Google.

So here’s the good news, Google doesn’t care which way you go and to them it makes no difference if your website has all WW URLs or non-WWW URLs. All Google cares is that your website doesn’t have duplicate URLs. This means the choice between the two approaches really boils down to a personal choice. The main thing is that you pick one and stick to it.

Technical Difference between WWW vs non-WWW

Episerver will work with both approaches. Personally, I tend to favour using a WWW approach. With a WWW approach, you get a few technical benefits compared to using a naked domain (non-www). Some of these benefits include:

  • WWW give your IT team flexibility when restricting domains internally
  • WWW allows more flexibility if you have different subdomains in your network
  • WWW makes it obvious your URL is a website, when you use a naked domain you don’t necessarily know which service you might be working with.
  • Flexibility with DNS (here

As far as I’m aware, naked domains don’t have any technical advantages over WWW. The reason why some people like them is they make your URLs shorter. When I make an architectural decision about a website, I tend to make it in terms of the choice that will give me the biggest benefit long term, so I’ve always stuck with a WWW approach and I’ve never had any issues.

How To Force WWW in Episerver

If you agree with a WWW approach then I will show you a URL ReWrite to enforce this on your site. If you really wanted to you could do this same logic in an initialization module, or as Alf Nilsson suggested in the ‘Redirect’ function, in the Admin mode.

Adding redirects here would work but the request would take slightly longer to process compared to using an IIS module, as the redirect is happening slightly further down the pipeline.

url_rewrite_pipeline

As you can see from this handy diagram by Microsoft, with a URL ReWrite the request happens at the resolve cache level. An Initialization module will be called in the ‘Execute Handler’ stage which will add a little bit more overhead.

How To Setup A Url Rewite Redirect?

If I have convinced you UrlRewrite is the way to go, then you need to make sure you have UrlRewrite installed on all of your live Episerver nodes. If you use a load balanced environment, if you forget to add it on, your website will blow-up. You can download urlReWrite here. In your web.config you will need to add this rule in your system.webServer section:

<rewrite>
<rules>
<rule name="Redirect Non WWW" stopProcessing="true">
<match url=".*" />
<conditions>
<add input="{HTTP_HOST}" pattern="^(?!www\.)(.*)" />
</conditions>
<action type="Redirect" redirectType="Permanent" url="http://www.{C:1}/{R:0}" />
</rule>
</rules>
</rewrite>

This rule will redirect all URLs that don’t have a WWW prefix, to use a WWW prefix.

Conclusion

In today’s post, we’ve covered the differences between WWW URLs and non-WWW URLs. My opinion (for what it’s worth) is that it doesn’t matter which one you use. As long as you pick one and stick with it your SEO won’t be affected. My preference is using WWW as it provides some slight technical benefits but if I had to use non-WWW I wouldn’t lose any sleep over it.

When you implement the Rewrite rule, you should ensure your website loads regardless of WWW or non-WWW requests. After you make your mind up, you can simply use Url Redirect to perform the re-direct.

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

More Posts

3 replies
  1. Alf Nilsson
    Alf Nilsson says:

    Hi,

    Great post. What are the differences between setting this up in web.config and use the “Redirect” function in the Admin mode when you’re editing the website hosts?

    Reply
    • Jon D Jones
      Jon D Jones says:

      As Url ReWrite is an IIS module, the re-direct should occur with less processing than anything you do in your application. The ‘Resolve Cache level is executed before the ‘Execute Handler’ level which is where I think the admin mode re-direct occurs.

      Reply

Trackbacks & Pingbacks

  1. […] content and can penalize your search rankings. I’ve written a more in-depth article in, Setting Up EpiServer To Always Use WWW Links to learn how to sort this one. As the www rule will never change I recommend putting these types of […]

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

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