Checklist while migrating a WordPress site from HTTP to HTTPS

Hello fellow developers!

Here is the checklist that I look upon whenever a WordPress site is migrated from plain old HTTP to HTTPS. At the end of the checklist, there are links to some useful websites where you can verify if everything has gone through correctly.

Step 0: Backup and local testing:

Nothing is more important than taking a backup before making any (important) changes on a site. So, take a backup and make sure it works on your local environment. Do not skip this step. If you do skip this step, you are putting yourself and your client in a world of uncertainty.

Try all the following steps in your local environment before proceeding to the staging and then to live environment. Again, if you don’t use a staging environment, no matter how small your client’s site is, you are doing_it_wrong.

Step 1: Get SSL Certificate

As mentioned earlier, even if you test locally, get a local certificate using any of your preferred method. I personally use mkcert by Filippo Valsorda. Earlier, I’d used my own tool that is a lot complicated than mkcert.

Step 2: Configure Webserver

Where you use Apache, Nginx or something else, please configure your web server to let the WordPress site to be accessible via both HTTP and HTTPS. The basic idea is to test the site in HTTPS and when everything is okay in HTTPS, we have to update web server to do a 301 redirect from HTTP to HTTPS. You’d still need to let certain parts of the site to be accessible via HTTP. Can you guess what it is? No? See the above step.

Still clueless? It’s for SSL certificate, particularly for Let’sEncrypt. If you don’t use Let’sEncrypt or if you use Let’sEncrypt with DNS verification, then you may, of course, do a 301 redirect for all the resources. If you still don’t get it, please post it in the comments.

Step 3: Fixing mixed-content errors and warning

There are plenty of articles available on the internet on how to fix mixed-content error. As a first step, I configure wp-config.php file to set WP_HOME and WP_SITEURL dynamically. I use the following code to do the same…

$wplt_protocol = 'http://';
$wplt_domain = $_SERVER['HTTP_HOST'];

if (isset($_SERVER['HTTPS']) &&
    ($_SERVER['HTTPS'] == 'on' || $_SERVER['HTTPS'] == 1) ||
    isset($_SERVER['HTTP_X_FORWARDED_PROTO']) &&
    $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
  $wplt_protocol = 'https://';
}

define('WP_HOME', $wplt_protocol . $wplt_domain);
define('WP_SITEURL', $wplt_protocol . $wplt_domain);

I’d keep an eye on the following areas to fix the mixed-content errors quickly….

• Menu items (especially custom links)
• Hard-coded links in the theme files (especially in functions.php file)
• Visual builders: If you use any visual builders, I can’t think of any safe way to update the links than doing it manually. An automated way to update links in visual builder blocks can break the site functionality.
• Uploaded content (including images). All links to uploaded content can be migrated to SSL using a plugin such as Velvet Blues Update URLs plugin . If you indeed use it, on the old URL field, enter http://example.com/wp-content/uploads/ and then in the new URL field, enter https://example.com/wp-content/uploads/.
• If you still get some warnings, then it could be due to some plugins that fetch “WordPress Address” and “Site Address” from the database that still points to non-ssl version of your site. Even if you don’t get any warning, it’s time to go live with HTTPS. So, go ahead and update both values using your preferred method. Don’t worry about the HTTP version of the site. It will continue to be served as it is, as long as the web server hasn’t been updated with 301 redirection.

Once you’ve fixed the mixed-content errors and warnings, it is time to switch the entire site into HTTPS by implementing a 301 redirect in the web server.

Step 4: Post-migration

This is equally an important part of the migration. So, don’t go away, yet! There are a few things to do post-migration.

• Internal links: First post-install step is to update the internal links to HTTPS. We could’ve done this earlier too. However, remember that we were using both HTTP and HTTPS until the completion of the last step (step 3: fixing mixed-content errors and warnings). So, if your site has thousands of posts, it may take a while to update them all. We don’t want to keep serving the visitors (and search engines) with both HTTP and HTTPS for long. It may lead to duplicate content, depending on how fast a search engine crawls your site.
• Sitemaps: If your favorite sitemap generator may have already generated a static sitemap that may have links to posts in HTTP. So, it is time to update them to point to HTTPS. Simply refreshing the sitemap generator would do the trick.
• Robots.txt file: If you generate your robots.txt file manually and if you have an entry for sitemap in it, please be sure to update it.

Tools (to validate migration)

Here’s the list of links that I often go and check how things are…

• Mozilla Observatory (to verify SSL related configurations)
• JitBit SSL Check (to scan the site for non-secure content)

Do you have any other tips to include in the above list?