Should you adopt SSL?

Unless you’ve been living under a rock, you’ve probably noticed that Google’s been encouraging a transition to SSL-secured websites for a while now. Before going further, note that this is a little long, so if you got here searching for something specific, you may have to scroll down a ways.


I’d noticed that most posts revolving around SSL focus on the adoption rate, ranking benefits, why it’s being done, how to make it faster, etc. There hasn’t been much discussion around how hard it is, pitfalls to watch out for, negative side-effects, or how to go about doing it. Maybe nobody wants to be the “bad guy”. So I’m volunteering.

Note that while I really focus on the negative aspects here, I’m not trying to discourage anyone from making the move (after all, my sites all support SSL so I can’t be that against it). But if you do a little searching, you’ll find there’s no shortage of people who tried moving to https thinking it would be a small change for a slight ranking boost, and dropped severely in rank, had their site’s performance plummet, or had something else unfortunate happen. I think it’s worth warning people about some potential pitfalls.

Should you adopt SSL on your website?

But first, the good!

Benefits of HTTPS/SSL

There are a few benefits if you’re thinking of moving to an SSL-enabled site:

  1. Your ranking (through Google, anyway) might increase very slightly. And by very slightly, I mean that from all the forums and various comments I’ve read, it seems as though it has about as much impact as a rounding error. This could, obviously, increase over time.
  2. In very specific circumstances, your website might load faster. This only happens if a lot of resources have to be fetched from your domain to load your page, and your server supports the SPDY protocol, and you’ve implemented it, and your visitor’s web-browser supports it too. It can be a drastic improvement, but only in that very specific case.
  3. Your site won’t be as vulnerable to MITM injection that some internet providers use against their users to inject ads, track what they’re doing, etc. I use “internet providers” loosely here – everything from hotels to airports to wifi hotspots can be culprits here. The tracking (spying) aspect actually extends to other areas, but it all falls under the same umbrella – someone’s intercepting traffic between the visitor and the website.

With all those pros, how come everyone hasn’t moved to SSL yet?!

Actually, I suspect that for most of the web, it’s going to be a really slow transition, as there are a few downsides…

The Downsides

  1. SSL is slower. Granted, there’s always the possibility that your website was horribly unoptimized, and you managed to get both SPDY and stapling working during your certificate install, and the site overall managed to be faster for some web browsers. But that’s a really specific, and unlikely combination.
  2. Optimizing SSL can be tricky. If your experience when it came to site optimization started and ended when you installed a WordPress caching plugin, you might be in for a bit of hurt when it comes time to, say, get OCSP stapling working. On the other hand, if you’re with a shared host, you might be at the mercy of whatever SSL-implementation they currently have set up.
  3. Old browsers probably won’t be able to reach your site unless you have a dedicated IP address too. For the most part, the web’s completely broken for many of these browsers anyway, but as an example, you can forget about traffic from anyone on XP running Internet Explorer unless you also have a dedicated IP address on your https site.
  4. Misconfiguration can result in a loss of traffic. A broken/invalid certificate chain, errors, and even mixed-content warnings are usually worded and presented by web browsers in such a way that people are led to believe that a hacker’s probably intercepting their connection to your site. Many people feel safer on an unencrypted http connection than they will on an https connection that has their browser sending constant warnings at them.
  5. Ad revenues may drop. Virtually 100% of the ads out there can be served to an http site. Not all of them can be served to an https site though, so competition (bids) are lower. As advertisers start realizing they can get more bang-for-their-buck by supporting delivery via https due to the decreased competition, I suspect the margin will narrow.
  6. Your Google ranking and traffic may fluctuate (or go down). It shouldn’t, but it might. A few major reasons for this…
    • It’s common for “rel canonical” tags to exist on your current site that point to the http version. When you switch to https, if these don’t change, you have a situation where your website is telling search engines to show the old http version instead of the new one, which can confuse a search engine if you’re redirecting to the new https version.
    • Just like and are technically different sites, so are an http and https version (yes, you could technically show http visitors entirely different content). It seems that some people see a dip in their http traffic before they see a bump in their https traffic as search engines sort this out.
    • Search results have started showing sites available over https, which can have a couple side effects. First, the site URL is a little harder to parse at a glance, so if you had a really catchy/clever site name, fewer people will notice it in the search results.
    • There are a number of people out there who don’t understand the web, have misconceptions, have learned to fear anything that looks unusual, and have been trained over the years to correlate https (and/or the lock icon) with financial transactions. When they come across your “cute cats” site and see https or the lock, some of these people might feel uneasy, as though their financial information is somehow involved or exposed in some way. Silly as that may sound to the well-informed, many people have been scammed/tricked/burned over the web and become very uncomfortable when they see something they’re not used to. Fortunately, it’s a problem that time will solve.
  7. Mixed content issues can be tough to sort out. The most obvious example that many sites face is that a bunch of images within their pages are hard-linked to http instead of https. There are ways to mass-change these via search & replace, but if you embedded images from another site (shame on you!), and if those images don’t support https, you might start paying the price for it by trying to re-link those images now.
  8. It (usually) costs money. Note that it is possible to get a free (or cheap) certificate and install it yourself. Otherwise, unless you have a web host that loves you deeply, you’ll probably have to pay to get it installed (I believe HostGator charges about $10 to install a certificate you bought elsewhere). If you’re really unlucky, your host might insist that you buy a certificate they offer. And finally if you’re looking to buy a certificate from a host that will handle all the dirty-work for you, you’ll usually be paying a premium regardless.
  9. It’s another maintenance item – an annoying one. Your certificate will eventually expire. Unlike a domain that can be renewed with a couple clicks and continue on like nothing happened… to get a new certificate, you have to go through the same lengthy process again and get the new certificate installed on the server.
  10. It’s a 1-way trip. Once you start getting inbound links to your https site, you’re going to have to keep a certificate active even if years down the road you decide to switch back to http for some reason. Otherwise, a redirect from https back to the old http variant won’t work.
  11. It’s can be tricky to (a) get the certificate, and (b) get it installed. (Note that many hosts will take care off all this for their own certificates). If you get confused by the following terminology, skip this bit and assume I left off at “it’s tricky”. Just generating a CSR is something the average person struggles with. Assuming you manage to get through that initial bit, merging the CRT’s you receive into a proper trust-chain is another matter. Evidently, instead of writing instructions for each certificate variant they sell, most authorities decided they could only hire a writer for 10 minutes for 1 variant, and that everyone would figure out the rest based on those specific directions for that specific cert. After wading through that, the certificate has to be added to the web server. If you did something wrong during the process and it doesn’t work or the certificate shows as broken afterwards, you might not even know where to start looking. It’s not newcomer-friendly.

Other items tend to get very use-case specific (Varnish-Cache for example), so I’ll leave it there.

So, with that out of the way, are you geared up and ready to make the move to SSL!? (this is where you say “absolutely I am!”). Great!

The Easy Way Out

I’d be remiss if I didn’t mention CloudFlare. If you somehow haven’t heard of them, their site has a bunch of pretty pictures and videos to show you who they are and what they do, so I won’t go over all the details, but the big reasons they’re relevant here are:

  • They’ll effectively give your site free “https” as long as your site is served through them.
  • They’re service is free (with paid plans available too).

The way it works is… your visitors would connect to CloudFlare over https, and CloudFlare would connect to your website over http and serve the content for you. It’s probably the fastest, easiest way to offer https availability. CloudFlare on the whole has it’s pros and cons, it’s not something that would work for *every* site, and doing a little searching before going this route would certainly be wise. That said, they’re worth a look.

Shopping for a Certificate

Let’s assume you’re not going the CloudFlare route. Don’t overspend on a certificate if you can help it.

For a standard “DV” certificate (domain-validated, which is enough for most people – usually used to cover a www and non-www version of a site), paying anything more than $10 for the year is probably overpaying. The exception is if you’re paying a host to handle all the dirty-work with little/no interaction from you, in which case paying a lot more is common. If that’s the case, just keep in mind that hosts do tend to charge a good bit more if they’re handling everything ($40-$50/year looking at a couple popular ones just now). If you’re going that route, feel free to skip the rest of this section.

Otherwise, you can get a free 1-year certificate for your own personal site from StartSSL. You could actually do this each year and not pay anything. The biggest downside is that it’s a hassle to do so each year. Rather than a username/password to log into their site, the StartSSL website ties itself to the computer/browser you used, so logging in from another browser can be a bit frustrating. The site’s not terribly easy to use either (in my opinion), but free is free.

If StartSSL doesn’t tickle your fancy and you’re looking for a “cheap” and “easier” DV certificate, GoGetSSL is currently the cheapest reseller I’m aware of (currently $6/year for the cheapest Comodo certificate – cheaper if you buy a 2-5 year cert), and they have an “Online CSR Generator” that saves you the hassle of having to generate that stuff (though doing it yourself anyway would arguably be more secure since a key is involved). Don’t get me wrong: merging the trust chain and installing it on the server is still a hassle, but at least you avoid the most annoying early steps. You can get a free 90-day “trial” certificate if you’re just looking to check them out.

You’ll run into terms like “EV / Extended Validation” and “Wildcard Certificates” when looking for a certificate, so I’ll mention those next.

“EV” certificates give visitors the “green bar” (visit PayPal’s website to see an example). They’re quite a bit more expensive, and take some time to get because the authority has to verify your business/organization information. There’s no technical benefit to those certificates so unless you like the green bar or want customers to be able to click the lock and see your organization’s address, they’re probably not worth the money.

Wildcard certificates on the other hand apply to multiple subdomains on a site. So if you had,,,, and, you might need to pony up the money to spring for a wildcard cert unless you’re ready to merge all those to a single subdomain.

Getting and Installing the Certificate

If you’re not in a position to work through the process of getting a certificate on your own, note that as mentioned previously, some hosts have an easy ordering process for certificates they sell (and then install) if you’d like to avoid the pain and anguish doing it yourself.

If you’re not familiar with server administration and are planning to obtain a free/cheap certificate from someone who isn’t-your-web-host, find a friend or colleague who’s installed a certificate before and have them available to answer questions or walk you through the process of actually generating the stuff needed to obtain one and install it on your server.

Otherwise, if you’re “doing this all on your own”, either grab something like GoGetSSL’s 90-day trial certificate, or generate and install a self-signed certificate first to “get your feet wet” with the process. There are a number of guides out there that will walk you through it. Obviously, do NOT start redirecting traffic to your site until you have a genuine certificate.

Once you’re up-and-running, test your site through Look through the results and see if anything looks misconfigured, or if there are features (like OCSP stapling) you might want to enable before moving forward. Now’s the time to get everything working the way you want.

Avoid adding the Strict-Transport-Security header – it’s a one-way trip that you’ll regret if you have to change back to http for some reason. You can always add it later. It’s not something you want on Day 1. If you want to test it out anyway, set the time to be very short (a couple minutes or something).

Preparing your Site

If at all possible, make your site protocol-less beforehand. This means that instead of internal links, javascript, and images pointing to , have them point to // or more simply, /stuff/things.html . This makes it really easy to transition back and forth between http and https.

A few “gotcha” areas to check:

  • CSS – sometimes there are hardcoded links to background images, fonts, etc. They tend to look like url(‘’) – the easiest way is to hard-code these to https (an http site won’t complain if a resource is requested via https), though a better way is to avoid the protocol and host altogether when you can.
  • Javascript – plugins are a big one for hardcoding images (similar to the above).
  • External resources – if you have very old Adsense or Analytics code, it might be hard-coded. Get the new stuff.
  • HEAD section of html – many things do not (and some can not) be made protocol-less. Change what you can and note what you can’t.
  • Server header – you’ll want to check here to make sure you don’t have stuff that’s hard-coded to point at the http version. Easiest way is to visit your site via https and then check the headers.

Note that CMS’s like WordPress can be a little challenging here because it often hard-codes http or https in certain areas based on your settings. There are ways to search & replace in the database to make your content protocol-less, but make sure you have a few backups before going that route. WordPress also adds a “rel canonical” to pages automatically which *should* update automatically if/when you permanently change your default in the settings, but can be disabled temporarily with a plugin, or a short line of code in your functions.php file if you need to.

Do some thorough testing before you actually swap over. If it’s a situation where there’s no way to make everything protocol-less, make sure you have a list ready with your hard-coded protocols so that you know what to tackle once you make the switch.

Redirecting to the SSL-version of your site

Instead of doing a 301-direct to the new https version right away, consider using “rel canonical” at first instead. Here’s why:

Search engines are supposed to be less aggressive with this change. If they haven’t indexed the https version of your site (and thus, don’t know about it), there’s a good chance they won’t drop the http version from their index until they’ve actually got the https version in their index and have decided that “hey, these 2 pages are the same, but it looks like the site owner wants us to start showing the https version“. Compare that to a 301 which is a little more “brute force” and doesn’t give the search engine much flexibility in the matter.

It’s also harder to shoot yourself in the foot. Search engines take the canonical tag as a hint (as opposed to a 301), so if you’ve got a “canonical” in the server header saying http and one in the html saying https, there’s a good chance that search engines will recognize the mixed signals and simply ignore it. You’ll have time to find the problem and fix it when you realize that days have gone by and the SSL version of your site isn’t showing up in the search results.

Testing once the SSL-version is live

Hopefully you tested thoroughly beforehand, but do a few checks to ensure that everything’s running as expected, that any canonicals in the server header (and html <head>) are pointing the right way, that no pages are broken, etc. If you’re using WordPress, hopefully you remembered to change the site address in the WordPress settings.

Running a few speed tests via might be helpful.

It’s probably a good idea to get your new https site added to Google’s Webmaster Tools (and/or Bing’s variant) as soon as possible too.

Keep an eye on your traffic. If traffic goes south, don’t immediately take the knee-jerk reaction of trying to reverse everything right away (lest you confuse the search engines even more). Verify that there are no underlying issues. Request a 2nd pair of eyes if need be to thoroughly go over your server headers and html code, and give the search engines a little time.


Assuming a few days (or weeks) have gone by and things are running smoothly on the https version, a few things to look into:

  • If you were using the “canonical” tag, double check to make sure that search engines are listing the https version for all your pages, and then feel free to set up a 301 redirect from http to https if you want to force all traffic to that version. Wait a few days before removing any “canonical” tags to make sure the search engines are clued in to the 301’s (though technically if the canonicals are set up correctly, leaving them in shouldn’t pose any problems).
  • If you have inbound links that you have control over, it might be worth slowly migrating them to the https version to avoid the extra redirect.
  • If you were planning to implement the Strict-Transport-Security header, now is probably a safe time to do it. Remember that it will cause web browsers to refuse connecting over standard http for the period of time you select, so don’t do it if you think you might be reverting your site at some point.

A Few Things Necessary to Increase Adoption

This last bit is just my opinion (not that I’m implying the above isn’t swimming in my opinion…). But if Google’s looking to encourage wide-spread SSL adoption, a number of things have to start happening:

  1. Certificates on the whole have to get cheaper, which will only start happening once awareness spreads that they *can* be found cheaper. I’ve been shocked to see the number of posts/blogs out there say something to the effect of “you can usually get a basic certificate for under $100/year”. REALLY!? No wonder adoption is low. After hearing that, I’d be surprised if anybody even looks. “Anywhere from free to around $50 depending on whether or not you want to do any legwork” is more accurate.
  2. Certificates have to be simpler to obtain. There’s no reason that certificate authorities can’t provide the option to autogenerate the csr/key for you, merge the chains for different configurations, and let you download the key and CRT(s) (with chains pre-configured) for whatever configuration(s) you want from their site. It’s almost as though they’ve gone out of their way to make things as complicated and inconvenient as possible.
  3. Google probably has to bump up the ranking boost to a point that at least mitigates the losses people seem to see after they transition. Sure, it might be the user’s fault that their site got even slower, or that something was misconfigured leading to a ranking drop. And I’m sure some people have been subjected to ranking drops that were-going-to-happen-anyway and the timing just led them to believe it was the SSL switch. But if the perception is that you’re spending money and doing a lot of work for something minimal in terms of positive effects, but that might lower your ranking… people aren’t going to bite.

So… should you adopt SSL?

Because of the potential downsides and the minimal advantages it currently has, I’d be inclined to suggest moving towards it gradually rather than jumping in face-first. If it’s not something that would cause financial grief, grab a certificate and make your site available over both HTTP and HTTPS, with a “canonical” pointing towards the original HTTP version (triple-check that it’s pointing correctly in the Server Headers and the HTML <head> section on both variants of the site).

Spend a bit of time playing with the HTTPS version and make sure everything functions well – try to tweak things so they work correctly on both protocols as you move forward, but avoid anything that would result in visitors landing on (and linking to) the https version. If you decide it’s worth the transition a few months down the road, it’ll be an easy transition. On the other hand, if the certificate nears the expiry date and you haven’t felt a need to move, you won’t have lost much by simply testing it out.