So if you are considering moving your entire site to HTTPS / SSL (secure socket layer), you know making the little padlock appear in the browser… I have to assume you are thinking of at least one of the following:

  1. It will help SEO as Google announced last year that a minor bump in rankings would be given to sites that used a security certificate.
  2. You want to take one more step to assure your visitors that you are the real deal and a security certificate (that little padlock) provides that warm fuzzy feeling.
  3. You have an ecommerce website and figure you might as well run the entire site on SSL and not just the payment forms.

Please note: I’m not an SEO expert so I’m not going to get into whether the longer load times of SSL pages and the penalty/reward Google gives for page load speed outweighs the reward it gives for security. However there is plenty of debate online about this if you are interested. Regardless you should know that there are some issues to consider, some of which I discuss below.

I recently moved fatlabwebsupport.com to all SSL but not really for the reasons mentioned above, instead I figured it was only a matter of time before I started getting such requests from clients and I wanted to see how easy (or hard) it was to retrofit a currently running WordPress site.

Let’s Make This Site All SSL

Fast forward to after the CSR was generated, the ssl certificate ordered, corporate identity confirmed, certificate delivered and finally it was installed on the server and on the security proxy… we were ready to accept secure traffic to fatlabwebsupport.com.

Fist Step, The Admin Section (easy)

Now came the challenge of moving the site to SSL. I started by moving just the admin section to SSL, this is was easy as configuring WordPress to force SSL on the admin… done. Everything worked like a charm.

Second Step (site settings)

Next I simply tried changing the domains in the settings page from http… to https… the site immediately broke. My stylesheets were not loading, some fonts were not loading, basically it was a big mess. Of course I never thought it would be that easy, so I changed it back and went for a different approach.

Let’s Try a Plugin

Despite my hesitation to use plugins (I just don’t like when a site gets too plugin heavy), I gave the WordPress HTTPS (SSL) plugin a shot. It is super easy to install (just like any other WordPress plugin) and configuration is jut a few checkboxes. I got it running, everything looked good in the back-end so I loaded up the front end… broken.

Same deal as before: stylesheets where not loading, fonts where missing and mixed content warnings were abundant. I uninstalled the plugin and thought about how I was gong to approach this project now, you know with two strikes against me already.

Mixed content warnings occur when there is a mix of secure and none secure content within a web page. The browser may block some assets or give the user a warning. Regardless of the browsers behavior, it is not good.

Because it was the stylesheets and fonts that broke each time, I figured that was a good place to start. This site is like so many others out there, it is a commercial theme modified (heavily) by using a child theme. Now the important point here is that it is a commercial theme and updated by the about a year old.

The Theme Was Not Built for SSL

I started digging through the files and realized that the theme had been built in such a way that without alteration a full SSL site would never be possible. Of course any modification to the main theme should be done in the child theme, right? However as I dug into this I realized that it was going to take a ton of work to move all the related functions and calls to the child theme… so I did it… I altered the parent theme.

I know, yell at me. I know better and would never have done this if it was not my own site. Regardless the effort was a success and I was able to change the setting page now to https and only minor issue where present.

Combing through every page

Every time you add an image to a post or page WordPress by default uses the full domain and changing the domain in the settings doesn’t change these static references within the page/post content, custom fields, etc. So somehow you have to go through and find all these. My site isn’t that big (about 150 pages) but I figured the ‘right’ way to do this was to run a find and replace query directly in the database. There are many scripts out there that will help you do this.

Despite the fact that working in the database should catch just about everything, it didn’t and I was still getting mixed content errors on a few pages. Not a big deal – but if I found it on one page, it means I have to check the entire site… very time consuming. I ended up recruiting a little help on this one.

Non-Compliant Plugins

I did have a couple legacy plugins that were not compatible with SSL traffic, meaning the produced errors. However both of these were coincidentally older plugins that had not been maintained so it would be considered best practice to replace them anyway.

Ok, So that Wasn’t That Bad – Done?

At the end of the effort the site was responding well to HTTP/SSL connections and once I felt confident that all was working, I setup a redirect so that all non-ssl traffic got moved to the new https address (this would also aid in moving the site seamlessly in Google and other search engines).

The ‘end’ result.

Traffic and Search Engine Positioning
I lost no rankings in Google, the transition was seamless and easy form that perspective. Just be sure to update your Google Analytics property settings and you will need to create a new Google Webmaster Tools profile.

Site Maintenance
I’m still finding a finding a few mixed content errors here and there. They mostly come up on orphaned pages that were put up ages ago I had forgotten about. All in all things are working though.

Site Speed
There is a definite difference in reported response times. I think maybe I took a double hit because we have to also install SSL at the security proxy (an un-researched theory). However actual page load times are still good so I am currently ignoring this.

Conclusion

On sites I have built and maintained I have used to use SSL on only the pages that needed it (donation forms, forms that pass personal identifying information, etc). I think the trend is defiantly one of security and we’ll see more and more sites go all https.

Would I recommend you do it for a slight bump in page rank from Google?
Probably not but please consult your SEO consultant.

Would I recommend you do it so that visitors get a warm fuzzy when they see that padlock on your site?
No not really, I think the public has been trained to look for that on financial forms but are not really caring anywhere else.

If you wanted to simply ignore the last two points, would I recommend that you tackle this for your site?
If you are a geek like me and don’t mind opening the hood, dealing with challenges of non-compliant themes and plugins, I say go for it. You’ll also need a few extra bucks for the SSL certificate and maybe a cost difference in hosting. Beyond that.. It might not be worth the time and cost.

If you are a manager of a site, my friendly advise would be to wait until your next rebuild and research it as a possible criteria at that time.

Final Notes

(As if this was not long enough already)
New technologies are coming out over the next couple years that will help negate the page load time issue and it is clear that organizations like Google are giving credit for the steps you take to secure your visitor’s experience so it’s all on the horizon. I think I probably moved this site over a little early, but an all SSL site is something to consider during your next web build project.

photo by Aaron Patterson / cc