HTTP to HTTPS Migration Guide for WordPress Websites

Disclaimer: I work extensively with WordPress, so while some of what I have to say here is WordPress-specific, you can still expect most of it to be the same for sites on other platforms, as well.

What is HTTPS and what does it do?

HTTPS is HTTP (hyper-text transfer protocol) sent over an SSL (secure sockets layer) or TLS (transfer layers secure) connection. Every website on the Internet uses either HTTP or HTTPS, regardless of which platform the site is designed on.

Since I’ve seen many people confuse the security of serving pages on HTTPS with security against hackers or injection attacks on their website, let’s clarify the difference between site security and data transfer security.

HTTPS is a protocol which encrypts data transferred between browsers and the server, so it can’t be deciphered. Its primary intent is to protect information your users enter into text input fields on your site’s pages. Unique SALTS and KEYS provide each site with distinctive encryption methods, so even if a third party were to intercept the data being transferred, it would be impossible to decipher it. Thus, it protects against man-in-the-middle attacks.

Site security, on the other hand, is comprised of many different facets, all of which are intended to prevent third parties from detecting some pieces of information about a website and using that information to modify files or embed malicious files – attacks based upon the vulnerabilities of a plugin or a theme, for instance.

Migrating your website to HTTPS provides no protection whatsoever against hackers who are trying to exploit a vulnerability of a plugin or theme. If site security is what you’re concerned with, here’s a handy 2-part guide on WordPress site security.

Do you need to migrate to HTTPS?

The long answer is no, if:

1. You don’t care that your competitors may get a ranking boost that you won’t get;
2. You don’t care that browsers like Chrome and Firefox will be displaying “˜this site is not secure’ warnings in the address bar for any page with any input fields loaded over HTTP;
3. You don’t care that similar warnings may soon be posted adjacent to any input fields on your pages;
4. You don’t care that a Google engineer recently said, “eventually, Chrome will show a Not Secure warning for all pages served over HTTP, regardless of whether or not the page contains any sensitive input fields”;
5. You don’t care that your users’ PII (personally identifiable information) may be intercepted by others;
6. You don’t care that many users may be scared away from your site by the lack of HTTPS;
7. You have no input fields on your pages – this will include login, subscribe and search fields (the address bar warning may still appear, even without input fields);
8. You don’t handle any financial transactions on your site.

The short answer is yes. Because why would you want to give your competitors an edge? Why would you be willing to endanger your users’ PII? Why would you not care about any of the above?

So, if you’re presently running on HTTP, I strongly recommend you migrate to HTTPS as soon as possible. Google has said they intend to start displaying these warnings “in October”. That may be anytime in Oct. ““ as usual, they weren’t specific. But that could be as soon as only a couple of weeks away.

Certificates

Types of certificates and how to select

The type of certificate you need will depend upon what sort of user inputs you accept on your site. If you’re accepting financial or otherwise sensitive information, you’re already obligated to have those pages secured, Google’s preferences notwithstanding. And a free certificate, such as those provided by Let’s Encrypt, probably isn’t the best choice for an ecommerce site. You’d want to consider a paid certificate, possibly a OV or even an EV.

A few notes on the different types of SSL/TLS certificates (Secure Sockets Layer/Transport Layer Security).

The first and most basic is DV, or Domain Validation. They are verified against the domain registry. Basically, this just means that this certificate is issued to this domain. This is the sort of certificate provided by free Certificate Authorities like Let’s Encrypt. This type of certificate is generally inappropriate for commercial sites. Bonus: Let’s Encrypt certificates renew automatically”¦ most others must be manually renewed.

The next level up is OV, or Organization Validation. This means that some governmental authority has verified that the organization or business using the certificate actually exists, by that organizational name.

Finally, the EV, or Extended Validation certificate, is issued under much more strict conditions than an OV certificate. It is the most trusted and it’s extremely difficult to replicate the site, in an effort to fool visitors (such as via a phishing attack).

But if your site is just a company information site or a blog, with no sensitive user information being exchanged, a free certificate is normally going to be fine. And many hosts are now offering Let’s Encrypt certificates at no charge. Since the vast majority of sites aren’t ecommerce sites, I’m going to focus on the simpler migration process, via Let’s Encrypt.

Ease of implementation

If your host offers Let’s Encrypt, you’ll be able to locate it in your hosting CPanel, probably under the Security section ““ if not, look for something like Installers.

Installing Let’s Encrypt is a simple two-click process, and the installation typically takes less than 30 seconds. However, any image URLs that were hard-coded as HTTP URLs will still have to be changed to HTTPS, or you’ll have mixed content. That would cause a warning to appear on those pages.

There are three ways to fix those remaining HTTP URLs. The first may be the easiest if your site is relatively small, with very few images. You can just visit each page’s editor and look for HTTP image links and add the s to make the link HTTPS. If your site is brand new, with only a handful of images, you might opt to do that.

The second way is using a plugin, called Really Simple SSL (https://really-simple-ssl.com/). Install and activate the plugin (at which point, you’ll be logged out, so you’ll have to log back in). The plugin developer tells me that this plugin edits individual links independently from HTTP to HTTPS, which avoids embedding multiple redirects and will resolve any mixed content issues. This is a good approach, as redirects consume time and the whole idea of building a website for a user base that is increasingly on mobile devices is to keep your load time as short as possible.

Simply because I prefer avoiding the use of plugins where practical, my preferred method is to use a script called searchreplacedb2.php, which can be downloaded from GitHub at https://github.com/jmandala/searchreplacedb2. This script allows you to search and replace items in MySQL databases. It’s a simple matter of downloading the script and uploading it to your root directory, then telling it to replace all HTTP items with HTTPS in the database.

CRITICAL: The searchreplacedb2.php script includes no authentication or other security measures, so it presents a serious security risk, if left in place. As soon as you’ve successfully rewritten the protocols in your database, delete the script from your root directory! Don’t forget this important step!

Forced redirect to HTTPS

At this point, you should be able to navigate to every page on your site and find each page secure. Nevertheless, if you type just your domain into the address bar, without the https://, you’ll still land on the old http:// version. This is corrected with a global redirect in the htaccess file.

Go to your hosting CPanel and click on File Manager. Check the box to Show hidden files and go to your root directory. There, you’ll find the htaccess file. Highlight the file and in the top navigation, click on Edit. It’s always a good idea to back up your htaccess file before making any changes, because an error can break your site.

Now between RewriteEngine On and all the WordPress rules (which will be the series of entries immediately before # End WordPress, you’ll be dropping this rewrite directive:

RewriteCond %{HTTPS} !^on$
RewriteRule (.*) https://example.com/$1 [NC,R=301,L]

Obviously, you’ll be embedding your own domain in this directive, in place of example.com.

WordPress Dashboard

In your WP dashboard, go to Settings/General and add an ‘s’ to the HTTP in both your WordPress Address (URL) and Site Address (URL)

Google Search Console

Now you’ll need to create two new properties. You should already have the http versions of both www and non-www – now you’ll need to add the https versions of both, as well.

Edit: It’s also important to update your Google Analytics account to HTTPS, to ensure your reporting is active. While you’re in GA, make an annotation of when you migrated, so months down the road, you won’t have to trust your memory. (H/T to Casey Markee of MediaWyse for these two tips.)

XML Sitemaps

Finally, regenerate new XML sitemaps and submit them to Google in the Search Console. You may see some drop in traffic until Google gets around to re-crawling and indexing your pages, but that’s to be expected with any significant site changes.

Another tip from Casey: After you’re done with all the above, don’t forget to check for redirect chains. One tool for that is httpstatus.io.

And you’re done! Your site will now be served over a secure connection.