Last year Google announced that they encourage webmasters to encrypt their websites with SSL, and they even state it is a ranking signal. Many thought following this advice would give their sites a ranking boost, but this is actually not yet the case, as the effect is probably so small it is impossible to measure between the hundreds of other ranking signals.. Still though, security is never a bad thing, and the fact that Google mentioned it explicitly would suggest it could get a larger ranking advantage in the near future, similar to what is happening with mobile-friendely sites. So, what can you do to make the switch with your Joomla site?

As a start, you should read this excellent blogpost on the Moz website. It contains an excellent checklist for sites moving to HTTPS. I decided to use it as a start, and see how the separate steps can be achieved in Joomla. All steps are covered in the Joomla version of the tutorial:

Get an SSL-certificate

Of course you should first set-up an SSL-certificate. The easiest is often to ask your host to set it up for a small (yearly) fee, though more advanced and secure certificates can become more costly. By the way, lately some hosts started offering free Let's Encrypt SSL certificates, like Siteground does.

Create 301-redirects to HTTPS

All, all existing URL's should be changed to the HTTPS version through a permanent (301) redirect. This will ensure that search engines will update their index for your site as soon as possible. You would expect the Joomla option for this (in Global Configuration) to arrange that for you, and luckily it does, in your Global Configuration settings (Server tab):

 

A more advanced solution is provided by Yireo's SSL Redirect plugin (free if you don't need support). Next to taking care of 301 redirects (a configurable parameter), it is also capable of setting the HSTS Header that is advised for full-SSL sites (see the Moz tutorial on details of this):

Using this plugin we have taken care of 2 of the most important ones on the Moz list: 301 redirects and the HSTS Header. By the way, if you prefer code to plugins, you can also enforce SSL URL's in .htaccess:

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Also you should be able to set the HSTS header here (take care, I did not test this myself, solution taken from stackoverflow.com):

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

All resources should be HTTPS: no Mixed-content!

Make sure every element of your website uses HTTPS, including java script, CSS files, images, etcetera. Actually, this step is often the one giving the biggest headaches, all other steps are pretty straightforward. This should not really be a problem, as most resources will be loaded relative to the site root, which is now HTTPS. However, there could be instances loading absolute URL's, like an image here and there. Maybe one of your extensions is a bit messy and does so. If this happemns, your browser will give you so-called mixed-content warnings. Usually for 99% you should be fine, but sometimes you need to be sure, or extensions load stuff where it is hard to set a relative path. Note that this also counts for embedded resources, like Youtube video's Adsense scripts, etcetera! If a secure page loads an image or any other resource from a non-secured path, the user will not have a nice green notification in the address bar, but a warning, and this should be avoided:

Internet Explorer users get an even more scary message, and they might actually leave your site because of this. In the ideal case, you should simply check all your links and resources, and set them to load from a relative path. If you really have issues with that, maybe because the absolte path has been forced by a plugin, and you cannot correct it manually, Akeeba's AdminTools comes to the rescue. AdminTools contains a small feature under SEO & Link Tools that can arrange exactly this:

Note that this option will always convert EVERY URL it encounters, always. It will not check whether this breaks functionality or not. Also, it can will convert your outgoing links, and make them point to the SSL version of the remote site, which can be less desirable. Still though, it might be wise to use it. Any non-SSL element on the page will throw an insecure warning to the user browsing, and it will make them feel more unsecure then a standard non-SSL site would.... Also any internal links you created (including redirects in the Redirect Component or in .htaccess) should have relative paths. If you have created URL's with absolute paths they will still be picked up by the 301 redirects you created, but is is better to avoid these.

An excellent tool to help you determine whether you still use insecure resources is the Screaming Frog SEO Spider tool. Crawl your site with the tool and ten run the Insecure Content option from under Reports:

You will get a spreadsheet containing all insecure links. Do this: it really helped me solve issues that I would otherwise have overlooked. An even easier tool that I use myself is the Website Auditor tool by SEO POwersuite (also available in the free version). It recently came with a tool to check HTTPS pages with insecure content:

It tells you on which pages the issue arose and which code is reponsible for the problems. I highly recommend this tool (I use the Pro-version myself), see my review here.

Check your canonical URL's

In most cases, your canonical URL's will be created from the site root, so they will be nicely changed for you to SSL. However, if you manually created canonocal URL's with absolute paths, make sure to check them. I had one site where I had set a few in SH404SEF and in Hikashop products that I had to update. Missing these might have serious consequences for rankings, so check them. I also use the Firefox plugin SEO Doctor to check that my pages are indexable or not. Incorrect URL's will be spotted by the plugin.

Check Robots.txt and .htaccess

Check that your robots.txt and .htaccess files do not not contain non-SSL links. Maybe your robots.txt file has a link to your sitemap. In .htaccess, maybe you created custom redirects to absolute URL's. Check these.

Check your sitemap(s)

Check your sitemap files. If you use an extension like OSmap or Jsitemap, the links will probably be automatically updated to the HTTPS version, but if you use a sitemap generated manually or by an online sitemap generator, you need to recreate it, or simply update it in a code-editor, replacing HTTP by HTTPS.

Register the HTTPS version in Webmaster Tools

This is a very important step: you need to register the HTTPS version of your site again (and also with and without www again):

You will have to repeat the whole process that you earlier did for the non-SSL version again, like setting geographic preferences and preferred domain, etc. Very important however: re-submit your new sitemaps. Especially doing this will ensure swift updating of the Google index. Moz even suggests leaving the old sitemaps i place for a while next to the new sitemaps so that the old links will be found as 301-redirected ones, but I should think that should not be really necessary (but it sure won't hurt either). Also Moz suggests to use the Fetch and Render function in Webmaster Tools to ensure Google can properly crawl and render your site (it also let's you request re-indexing of the site, which should help Google to swiftly update the index).

Some final steps

  • If necessary, update your analytics tracking code. Most modern Google Analytics tracking snippets already handle HTTPS, but older code may need a second look.
  • If you have a disavow file, be sure to transfer over any disavowed URLs into a duplicate file in your new Webmaster Tools profile.
  • Your social share links may not be able to reflect the count-status of the HTTP site anymore. It differs a bit per channel which one will pick up the old counts and which one not. Facebook, Google+ and Linked should be fine, but Twitter and Pinterest start over. Note that there are techniques to retrieve the old counts, but this goes beyond the scope of this blogpost.
  • If you use a CDN, also make sure the CDN side of things works correctly. KeyCDN has a nice tutorial for this that explains the whole process, also applicable to non-KeyCDN users.

And finally, manually monitor and review your site. Your site could have specific issues that need to be sorted. Just to be sure, run some automated checks on the validity of your SSL-installation. You can use sites like www.whynopadlock.com and www.sslshopper.com for this.