Moving a WordPress Site to SSL (Updated: 2017)

It was exactly two years ago today that I wrote a blog article “Moving a WordPress Site to SSL” that covered my experience moving a previously non ssl/https WordPress site to be full https. At the time I was getting calls, mostly from SEO folks because Google had made some announcements about how they were going to give SEO “points” to sites that ran SSL.

From Friendly Suggestion to Being Penalized

Fast forward to today, Google seems to not only be “giving points” to those site that are SSL compliant but actually penalizing those that are not. Just do a search for “google to penalize non ssl” and you will see all the talk. It also looks like they are taking things a little farther and actually shamming website owners into going full ssl by displaying messages to users that let them know the connection is not secure.

chrome displaying not secure message

The Chrome browser for example will now display “Not Secure” in the address bar when there is a form present on the screen. Yikes!

Forcing all Sites to SSL is a Good Thing, Here is Why:

Is the Site You Are On the Real Deal?

When an SSL certificate (what makes the site work on SSL/HTTPS) is issued there are various levels of authentication that occur that ensure that the requesting business/person is who they say they are, that they truly own and control the relative domain and some go as far as to validate an organization’s state and government filings. The idea being that when you visit a site with that little padlock, you can trust that the site is authentic and not a phishing copy designed to lure you in and gather personal information… yes people are evil and yes people do this kind of crap to each other.

No Middle Man

Probably most importantly, an SSL website encrypts all data between the user’s browser and the server that serves its content. This basically means that anyone (or thing) that ‘grabs’ that data in transit can’t decipher what it is. I guess we don’t really care that they can’t make out the image you are looking at (unless of course you are looking at something you shouldn’t be) but now think about all that good personal data you provide when filling out online forms, using personal accounts, etc. Scary right?!

There are all kinds of man-in-the-middle attacks and making your transmitted data a bunch of gibberish that only your browser and the server can make out, makes for a really annoying time for any would be attacker – that is a good thing.

Even More Security in Encryption

Just as the man (or woman, or robot) in the middle (explained above) can’t see or tamper with what you are doing, end to end encryption ensures security when transmitting sensitive data such as credit card numbers, personal identifiable information (PII for you government types). Again the idea here is that only your browser and the server that is processing your data can make any sense of the information.

Performance Hits and Technical Complexity (Myth Busting):

You Must Lease a Unique IP (nope)

Two years ago when I wrote my first post about this, if you had called your hosting company and asked for a an SSL hosted site, they would have leased you a unique IP address. Unique IP addresses are limited and a real commodity for hosting companies – many charged a premium to get one under the requirement that an SSL site required a unique IP address. This is no longer true, new technologies allow multiple secure sites to run under a single IP address. This has reduced the overhead for hosting companies making the new push for an all encrypted web a more reasonable idea.

Now with that said, there are still some browsers that will have trouble rendering a secure site that does not use a unique IP address but those are old and outdated. Old and out dated doesn’t mean they don’t exist so it is something for you to consider if for any reason your site serves a user base on legacy systems.

SSL Will Slow Your Site Down (kind of but don’t let it ruin your day)

It is true that encrypted pages take more time to load and for those of you who have put efforts into making sure your site as fast as possible, this may sound alike a horrible black eye. There is just no getting around it, when encrypted data is sent and received it must be first encrypted and decrypted and each transmission must follow this routine. That’s a lot more work for a server than just sending plain text. However we are talking milliseconds here.

Modern web servers are very efficient at doing this, modern browsers are also very efficient at doing this. Also just think if you are considering this because Google told you you should, then I am certain they are factoring this minor performance hit into their algorithms and the “points” you get for going SSL greatly outweigh the hit you take for slowing things down just a little bit… and it is just a little bit.

Get To the Point… Moving WordPress to SSL

We are two years from when I wrote that first post on moving WordPress to SSL and back then I sighted several areas that provide challenges in the process. These areas really have not changed when we are talking about WordPress.

Non-compliant Plugins

All major plugin authors at this time should have updated their plugins to work with SSL as they have had several years to do this. It’s the little guys, the one that have not been updated in a while that you might have to worry about. If for any reason the plugin utilizes third party resources (see below) and they are not utilizing https/ssl connections to those resources, the plugin will be non-compliant.

Non-compliant Themes

Take it from a support guy who typically doesn’t build sites but works in sites built by others… there are a lot of shitty commercial themes out there! Bad coding practices can make it nearly impossible to run SSL on your WordPress website. Often a developer can overcome these shortfalls by creating a child theme, but many times these commercial themes are so poorly constructed that the effort becomes too great versus a rebuild of some kind.

Though I bet things have gotten better over the years as theme developers/designers have been under pressure to make compliant themes, it’s not going to help you if your site is running a theme from years ago. The theme is a major point of failure when trying to convert a site to SSL. Sometimes you just have to give up and go with a rebuild…. Yes I know that is expensive and inconvenient.

Mixed Content

mixed content error in browser

Mixed content errors occur when you have referenced files (images and scripts) within your content that do not resolve to an httpS address. The browser then senses that the connection is not completely secure and warns the user. You can typically take care of this with database find and replace but you will still need to check your site (each page if possible) to make sure all linked assets are secure and your users aren’t getting scary warnings.

Third Party Resources

This is related to themes and plugins as these can sometimes depend on third party resources in order function. Most the website owners I work with have no idea how much their site actually relies on third party resources to work. Often theme and plugin developers will connect to scripts hosted on other servers around the internet. For example many social media widgets are run by scripts hosted by the companies that runs the network. A WordPress website can reference dozens of third party resources and each one of these must also have SSL running or else you get that dreaded mixed content warnings. Again, its one of those deals where any reputable source should be running SSL now but there may be some outliers that don’t and therefore will introduce a challenge into your switch over.

You may also find some places in your theme or plugins that are hardcoded to the http address of a third party resource and all it takes is to change that reference from http to https, assuming the third party is indeed running SSL. The catch here is that these hard coded resources will not be changed automatically and you have to consider what kind of hacking you want to do to your theme or plugins in order to change that resource path.

Our Experience

At FatLab we have done a few of these conversions for our clients and for the most part they have gone fairly smooth. It seems to really depend on the age of the site, the complexity of the site and whether it is up to date (plugins, WordPress core and themes). It’s typical for us to find some mixed content that is easily fixed and we have had to hack a few themes (we try and use child themes unless that site is already using bad practice) when third party resources have been hardcoded.

We have run into a few third party connections that don’t provide SSL yet so we have had to come up with work arounds. Once even a call to to the provider, The Better Business Bureau, sorted out what path we should be using for a validation icon.

Newer sites built to best practices are definitely easier to convert. Though we haven’t run into one yet that we were unable to get converted, we warn clients that there are variables that may make the job take an unreasonable level of effort to complete. Sites with hacked themes, bad build practices and lots of plugins are definitely  going to be much tougher to complete.

We typically budget about 5-10 hours to work through a site of good size, this includes getting the certificate issued and installed on the server.

photo by Aaron Patterson / cc

Receive Periodic Updates from FatLab