If you own or publish a website, you will be responsible for deciding where and how to host it. Finding the right criteria for such a decision can be a puzzle, especially if like most of the world, technology is not your day-job. This write-up offers some top-level factors that website owners can use to evaluate and select the right web host…
1. INTERNAL OR THIRD PARTY?
The first decision is whether to host it on an internal server, or host it on a server provided by a third-party web host provider. The key here is whether you want to absorb the risk of being responsible for a smoothly operating server, or if you’d prefer to off-load this risk to a company that does this for a living.
In a related point, you need to look at how much traffic you get. If you are lucky enough to find your content goes viral and you get a crush of new visitors, an in-house server may crash under the unexpected and unplanned for load.
Giant global websites mitigate this problem by using Akaimi or Limelight to distribute the site to many servers across the globe, and let caching activity balance the load. Most sites, however, are far from this category of service needs. Let’s suppose you have decided to off-load risk to someone else, and are rubbing your hands together at the prospect of one day drawing plenty of visitors. This puts you on the path to choosing a third-party Web host. So what’s the next decision fork?
You may also be given an opportunity to host your Web site on a server provided by your web developer. There may be technical reasons why it is required to host with them, if you choose them as the provider. Or perhaps they offer discount pricing and it simplifies maintenance issues for them.
As the customer, when you weigh this choice, the one thing I always urge people NOT to give up is control over their domain registration. The URL of your site can be pointed at any server, and it is easy to split ownership of the domain registrar and the web host. Doing so can protect you from a lock-in situation where unnecessary obstacles are put in the path of you making changes down the road. In the worst case scenario, some unscrupulous developers have been known to take websites “hostage” using this ultimate leverage over your content to get their way on some dispute.
2. DEDICATED OR SHARED SERVER?
For many, the next factor to think about is whether you want a dedicated server, or you are willing to share space on another server with other websites. This is a decision that is usually invisible to the user. Who cares what’s on the server with you? Why does it matter?
In an age of spam and email list owners who fail to delete bad email addresses, it may matter more than you think. Both conditions may prompt an Internet service provider to punish website owners on the offending server. If another website owner who shares your server is blacklisted, you may find that your email and communication from that server has also been blocked. It’s an unhappy stand-off to find yourself in, and usually resolves itself eventually. But in the meanwhile, your business or Web publishing enterprise may suffer.
The cost of a dedicated server may not be worth the risk, however. But make the decision with open-eyes.
3. OPERATING SYSTEM OF SERVER?
Depending on the type of server your site is hosted on, you may have problems being found via search if users type in the wrong case (upper not lower, lower not upper, etc.) for your URL path names.
There are three types of standard Web servers: Apache, Linux and Windows. If you elect to be in an Apache or Linux environment, beware that there is a case sensitivity issue in how you name your Web files. Microsoft IIs servers are usually case-insensitive (upper or lower work)
Some Web host providers offer multiple server types, so you should ask about getting your Web files placed in the environment that meets your needs.
Google is case-sensitive on the URL path after the domain.
Technically speaking, the following URLs are all the same:
However, these are not:
- http://domain.com/PATH/file.htm (a different path)
- http://domain.com/path/FILE.htm (a different file name)
- http://www.domain.com/path/file.htm (a different host name)
There is a way to get out of this jam if you end up on a server that has case sensitivity. Always use lower-case naming conventions for your content. Plus:
Make sure all your internal links point to the same version of the URL, or the search engines may recognize two or more and you won’t get credit for page ranking purposes.
Have your technical lead put a piece of code on the server to resolve case-sensitive issues But beware of making these changes if you don’t know what you are doing, because it can get more complicated than you care for.
Post a permanent 301 redirect for URLs that are not already part of the problem.
Having grappled with the operating system question and the demands it may put on your Web developers, the next key performance item I’d look at is remote back-up and redundancy.
4. REMOTE BACK-UP AND REDUNDANCY
Remote backup preserves a record of your files should it be necessary to roll-back to an earlier version of the site, or to reconfigure the site should there be any damage to the server.
Your webmaster typically has a current version of the website files and assets, but if there is no versioning of the information, so rolling back to a earlier edition is subject to your web host agreement. And don’t count on this service if it is not part of your contract. As the owner of the site, it is worthwhile for you go get a free FTP service, such as Filezilla, and do your own regular backups of what is published on the web.
Several server environments may exist for giant complex websites:
- Staging: where you prepare your content before it goes live
- Sandbox: for testing and development
- Test: for previews and approval before it goes live
- Production: where the live website lives
- Training: a look-alike site where new content managers can practice
- Fail-over: with a mirror copy of your site to activate in emergencies
Giant complex sites often have the site in several environments at once – staging content before production. A sandbox may exist for developers to do testing and development. A test server may exist to help content managers ready the content for publication and get it approved before it is live. Finally, the live server, sometimes called the production server, is where it is posted when it is in the public domain. Finally, if you are training new content managers on a regular basis you may want to have an environment where they can do exercises on a look-alike site with no risk that your live site will publish these experiments.
Redundancy is a set-up where you have at least and sometimes multiple servers ready to pick up the load of your existing server and has a mirror copy of your site there. That way, if the server fails the duties are automatically picked up by the next in line server in your configuration. A fail-safe that lets you sleep better.
5. MONITORING AND RELIABILITY
This brings us to the need to know about server monitoring for reliability – uptime, downtime and speed, or average response time.
My own web host, named Laughing Squid, provides standard and cloud hosting services. It uses the third-party provider for monitoring called Pingdom. Their report on uptime/downtime gives you an easy to digest format that lets you select which server you are on – assuming you are not on a dedicated server – along with the uptime, downtime and average response time.
6. CUSTOMER BASE AND HISTORY
Take a look at the business mix of their customer base, how many customers they serve and who they market to if that information is available from their materials. If they appear to focus on small sites, as a small business customer you can have some comfort that you will not be overshadowed by larger business interests or customers that provider may have.
And has the provider been in business long enough to give you peace that they are not fly-by-night? Take a look-see to find out how long they have been in business as another one of your evaluation factors.
7. CUSTOMER SERVICE
On customer service, it is worth your while to do a little mystery shopper test. Figure out where to send an email question via their support page and see how long it takes to get a response. Do they give a phone number or is it email service only? Do they have a ticketed help desk system that can give you more professional service?
Look at their forums, where current customers ask questions, if this is part of their support page apparatus. Or do a Google-search on outside IT forums and see if you see any complaints or concerns by current customers.
If there is no phone number listed, this could put you in an awkward position should you need to contact the firm for service in an emergency. Limited phone support is okay, but the provider should be open and transparent about when and where they can be reached and use an effective e-ticket system to provide quick support to routine questions.
Of course, you must also consider cost. Take a look at how they tier their plans and if they have add-on fees for things like redirecting a domain to the primary URL – something you might do if you want those who visit the dot org or dot net version of your domain name to seamlessly go to your site on the dot com site.
I’ve found very good service on all the criteria that matter to me at Laughing Squid, by the way. They offer a variety of plans including an inexpensive $8/month version that is suitable for a small site with low traffic, and a more robust $12/month plan that lets me be ready with more space, more email and more SQL databases for your site.
When selecting a provider to become your web host, choosing where to host your website is a decision that deserves a checklist. To sum up:
- Internal server or 3rd party web host?
- Dedicated or shared server?
- Operating system?
- Remote back-up and redundancy?
- Uptime, downtime, server response time/speed – what server monitoring exists to help you measure reliability?
- Customer base and history
- Customer Service: Help desk, e-ticketing and phone support