With the announcement of the Linux Foundation’s Let’s Encrypt project, the thought of migrating a website fully to the secure HTTPS protocol quickly, easily, and free of charge has passed from fantasy to reality. Accordingly, I’m sitting here scratching my head trying to dream up reasons why you still ought to hesitate to make this change on your site, or other considerations that you should mull over before pulling the trigger, and I’ve got bupkis. And now that our very own upbuild.io has taken the initiative, we’d be safe from charges of hypocrisy should we badger others to do likewise. So let the badgering begin!
Now, what do you actually stand to gain by doing this?
- HTTPS provides greater user security. HTTPS distinguishes itself from HTTP primarily by transmitting data over the Secure Sockets Layer (SSL).This ensures that the data being transmitted are encrypted throughout transmission and decrypted only upon receipt either by the site’s server or by the user’s browser, making it impossible for any third party to intercept them. It also provides trustworthy server authentication, complete with certification that hackers cannot spoof, such that concerned users can be certain they are talking to the right server. Sites that straddle the threshold, making some pages available only in HTTP and others only available in HTTPS — and even sites that present all their HTML documents in HTTPS but that load other resources (such as JS or CSS files) over HTTP or by way of an unsecured CDN — are eternally at risk of sensitive user information being exposed. Making the whole site accessible exclusively in HTTPS is the simplest protection against this risk. Read this essay from the Electronic Frontier Foundation for the clearest rigorous explanation of HTTPS available on the web.
- Sites that split their presence across the two protocols tax their servers with numerous redirects that would otherwise be unnecessary. The concept of a site presenting certain pages only in HTTP and other pages only in HTTPS is rational enough on its face, but this choice requires the site’s server to be prepared to fire a 301 redirect every time a page is requested in the wrong protocol, which is a drain on the server to maintain, and which slows page loads in every case when one of these redirects actually fires.
- Sites that split their presence across the two protocols are at greater risk of generating duplicate content and sending confusing signals to Google. Sites that run certain pages in HTTP and other pages in HTTPS are in fact required to manage the entire site in both HTTP and HTTPS, and to maintain careful and precise control over the redirects that are counted on to serve the right version of each page to each user. It is perilously easy for a site in this position to accidentally let one or more pages resolve in both protocols, which results in two versions of a single page being crawled and indexed by Google, which in turn leads to depressed search visibility for the page (as Google sees the two versions as being in competition with one another). Even when this risk is successfully obviated, Google will sometimes index the incorrect versions of certain pages (i.e. the ones in the wrong protocol), requiring unnecessary redirects for users that click through from search results, which in turn creates needless server strain, dilutes search authority, and slows page loads. Since pages that handle PII (personally identifiable information) must by necessity be in HTTPS, the choice to consolidate the site entirely within HTTPS rather than HTTP is an easy one.
- HTTPS is correlated with superior organic search visibility. Google announced in August 2014 that it would begin rewarding pages secured by HTTPS with higher rankings in search results. Though it took until spring 2015 for the correlation between HTTPS and higher rankings to became statistically significant, independent forensic analysis conducted by SearchMetrics at that time verifies that it is:
[Graph and accompanying legend/analysis courtesy of http://blog.searchmetrics.com/us/2015/03/03/https-vs-http-website-ssl-tls-encryption-ranking-seo-secure-connection/.]
This is almost certainly the strongest point that UpBuild as an SEO agency can make in support of a full migration to HTTPS: there is every reason to believe you will rank better in Google organic search on competitive keywords once your site is in HTTPS. - HTTPS signals a site of higher quality to Google. If you run a “your money or your life” (YMYL) site, which is a distinction that Google makes in its Quality Rater Guidelines for sites on which money or health information changes hands, then according to those same guidelines, your site will be held to a higher quality standard and expected to offer particularly robust security. Owing to the vulnerabilities of mixed-protocol sites described in Point 1, the choice to place your whole site in HTTPS rather than reserving it for PII-specific pages would indicate more strongly to Google that the site takes user security seriously. This would be expected to improve their assessment of the authority of the site, which would lead to superior search visibility. Read our own Ruth Burr Reedy’s excellent unpacking of those Quality Rater Guidelines for more.
- HTTPS is a prerequisite for AMP (Accelerated Mobile Pages). AMP is a young open-source initiative that offers webmasters an easy way to create lightweight versions of mobile pages that load super fast, which in turn boosts the site’s visibility in mobile organic search. Unless and until your site is exclusively available in HTTPS, it will not be eligible for AMP. HTTPS is also a prerequisite for use of the HTTP/2 protocol, which is still rolling out, but which is expected to explode in its adoption over the coming years for the greatly increased speed afforded by its “multiplexing” technology (greatly reducing page load times and latency). You should put your site in a position to take full advantage of this coming revolution as well.
- HTTPS ensures more accurate transmission of referrer string data. Sites that dwell mostly in HTTP are often denied access to referrer string data on visits referred by sites in HTTPS. This isn’t a specific objective of HTTPS sites; it’s more that HTTPS sites are often cautious to a fault about making any identifying information at all accessible to insecure (HTTP) sites, and that outgoing referrer strings can easily become casualties of this zeal with which they protect themselves. The resulting problem is that a number of referral visits to HTTP sites end up wrongly classified as direct visits in the sites’ analytics. If you migrate entirely to HTTPS, fewer referrer strings will be dropped from referral visits, and the site’s analytics will become more accurate.
So there you have it! Did I forget anything? Have any of you had positive or negative experiences with this migration, especially through Let’s Encrypt? Now would be the time to say so, in the comments. Otherwise, happy encrypting!
