In 2017, I advocated migration to HTTPS before Google started making it seriously painful for sites who didn’t. Well guess what? Google just made the privacy pain official by announcing the Chrome 68 update, which will mark HTTP sites as “not secure.” The browser update is expected to roll out in July 2018. If you’ve still managed to drag your feet on HTTPS until now, time’s up. This post will give you a detailed walk-through of all the steps you’ll need to go through, common problems, and a lot of deeper resources you can share with your team.
So why does HTTPS matter? In some cases it’s a matter of perception. Not all websites collect or transfer sensitive data, which was the deciding factor to secure a site in the past. But, because one of the internet’s leading platforms (*cough*Google) is driving the charge to an all-HTTPS web, failing to follow suit will more than likely either confuse your prospects and customers on Chrome, or worse yet instill distrust in your site and your brand.
HTTPS migration is more complicated than it looks. Here’s how we handle migrations and all the pesky details at Portent.
Create a game plan for HTTPS migration
Like most dev projects, you should start with a plan. Sites have different setups and variables to take into account. Now is the time to analyze the site you’re working on and strategize.
Some site setups allow for a series of steps to be completed on the live site. Others may require a database freeze on the live site while all appropriate HTTP references are updated and tested in a staging environment, then re-synced to production. I highly recommend working with the latest database and code base in a staging environment that is HTTPS-capable to apply and test your work.
Also, if you’re able, this is a good time to upgrade your environment to utilize HTTP/2 while migrating to HTTPS. HTTP/2 offers some amazing site speed improvements. Like all things dev, there are multiple approaches here. I wrote an article about what I consider a really solid solution and a phenomenal deal offered by Cloudflare.
Set up SSL for your domain
Whether you are using a CDN-provided SSL cert or you’re purchasing and installing one yourself, get it set up. We recommend your cert have 2048 bit encryption and use the SHA-2 hashing algorithm. For more details on SHA-2 vs SHA-1, read this FAQ.
Test and verify that the cert is properly installed and your HTTPS URLs are not throwing common name errors. A common name (mismatch) error is the result of the SSL cert not matching the domain URL. A possible example could be that your site is setup for https://example.com but the cert’s common name is configured only for https://www.example.com.
If you are having common name errors, check out this article for more information and resolution options.
Take inventory of all HTTP assets
Take inventory of all assets affected by the migration: Those links have to change to “https” links. A majority of sites reference assets that are not hosted internally.
In order to avoid content mismatch errors, all assets must reference valid HTTPS URLs.
Do you have a CDN? Is the CDN SSL-enabled? Test and verify. Be sure to keep track of the HTTP and HTTPS URLs for the search & replace step.
Many times, Customer Relationship Management (CRM) systems are involved and need to be carefully analyzed and included in the game plan. If your site is integrated with a CRM (like Pardot or HubSpot for example), address these questions:
- Is your CRM SSL-enabled? Test and verify.
- Are you using custom templates? Do they reference your main site? Update all CRM templates that reference HTTP resources to HTTPS. Test and verify.
- Does your site integrate with Form Handlers? Update any references to HTTPS.
- Do you like pictures of broken padlocks? That’s a rhetorical question. Make sure the CRM uses HTTPS by default going forward.
Does your site reference any other assets that do not have a valid HTTPS URL? If so, you will want to either host that asset yourself or strongly consider removing it — or face content mismatch errors, which erodes trust from your users.
Check your codebase for HTTP URLs
Often times, developers or content teams will hardcode absolute URLs into their code. I definitely recommend against this, but sometimes it happens. Now would be a good time to make those references relative to the configuration of the entire site. Either way, be sure that any asset references are either relative or hardcoded to HTTPS.
If any CDN or CRM URLs are hardcoded, update those as well.
Replace database references
Stop. Before you proceed, backup your database!!
There are a handful of approaches for handling this step, and the best choice for your site may depend on your application and the type of database. My examples are for MySQL-based applications — and more specifically, PHP-based. This is because I’m most often working with WordPress-based sites.
Be sure to analyze your application and verify whether you will need to search and replace for URLs stored as serialized data. If you’re not familiar, serialized data is a methodology used to represent data in object form. What makes it tricky in this scenario is that the length of each attribute value is stored in tandem with the actual value.
a:10:{s:3:"key";s:19:"field_55df88891f7f2";s:5:"label";s:18:"Webinar Signup URL";s:4:"name";s:18:"webinar_signup_url";s:4:"type";s:4:"text";
s:5:"value";s:41:"http://www.example.com/analytics-webinar/"}
In the example serialized data above, there are 8 key/value pairs and every value has its length defined.
Executing a straight search/replace without handling the length element will break or corrupt that serialized data object. To read more about serialization, click here.
WordPress
Install Better Search Replace or Search Regex plugins. I recommend Better Search Replace because it handles serialized data, has the ability to query all the database tables, and has recent support/updates.
Let’s say the final URL you want is https://www.example.com. Execute search/replace for:
http://example.com => https://www.example.com (or //www.example.com)
http://www.example.com => https://www.example.com (or //www.example.com)
https://example.com => https://www.example.com (or //www.example.com)
[Any CDN URLs HTTP] => [HTTPS equivalent]
[Any CRM URLs HTTP] => [HTTPS equivalent]
Additionally, look for references in theme settings, widgets, menus, etc.
- Check the Appearance->Customize area
- Check custom theme settings/options
- Check widgets for hardcoded links
- Check menus for custom links
MySQL Search/Replace
Another option is targeting specific database tables and utilizing MySQL’s REPLACE function. This is the equivalent of the Search Regex WordPress plugin defined above, except you are writing and executing MySQL scripts directly on the database versus executing a PHP script.
update TABLE_NAME set FIELD_NAME = replace(FIELD_NAME, 'text to find', 'text to replace');
Keep in mind that function does NOT work for serialized content, but is perfectly capable of replacing URLs in say, your wp_posts_old table.
Advanced
If you’re on a customized CMS or one that’s more complex than WordPress you may have to get more advanced. For example, many complex systems have enormous databases. The search and replace queries can be very heavy, especially if you’re dealing with a data set that is massive. We’re talking millions of rows or more, and a database size of a gigabyte or more. In this case, consider scripting some of the search-and-replace.
For MySQL and PHP applications, I found the search and replace tool by interconnect/it to be a solid solution. It has many options, but it is a good fit for large data sets because it does batch processing so it can properly handle the task. It also handles serialized content.
301 redirects
Redirects are an important component in migrating to HTTPS because it retains link authority for SEO purposes. Be sure to address these items:
- Setup cardinal 301 redirect for HTTP URLs to their HTTPS counterpart
- Update all existing 301 redirects and remove redirect hops.
If you have 301 redirects already defined like:
^/blog/some-article-title/$=>http://www.example.com/blog/new-article-title/$They all need to be updated to:
^/blog/some-article-title/$=>https://www.example.com/blog/new-article-title/$This includes your non-www or www redirect. For example, if you already had
http://example.com301 redirecting tohttp://www.example.com, it now needs to redirect directly tohttps://www.example.com - Check both your web server config (ie. .htaccess, etc.) as well as any database or file-based redirects. A popular WordPress redirect plugin is Redirection
PPC and Analytics
In coordination with the go-live launch, be prepared to update any PPC campaigns and analytics profiles. Portent’s Analytics Architect, Michael Wiegand, advises that any paid campaigns with tracking parameters pointed at the non-secure version of the site will almost always be stripped.
Bottom line:
Making sure all of your paid search and paid social ads get updated links from HTTP to HTTPS is critical to maintaining clean information and reporting in your analytics.
Additionally, reporting in Google Analytics on the full URL with the protocol (ie. HTTP:// or HTTPS://) included is not the default in the content reports. You have to add “Hostname” as a secondary dimension to compare HTTP and HTTPS traffic on pages with the same URL.
Run a crawl of your site to prepare for HTTPS migration
Running a crawl on your site is a great way to get an inventory of URLs and detect errors. I recommend running a crawl as part of your planning process to help detect the URLs you will need to update. Keep in mind we’re only truly interested in assets and forms that are embedded in the source code. There is nothing wrong with using a standard href link to an HTTP URL from HTTPS.
Additionally, a crawl can help you spot:
- Mixed content issues
- 301 redirect infinite loop errors. AKA a ‘Spider Trap‘
- 404s to see if you messed up a search/replace or some other issue
In summary
I have a feeling a lot of sites will be scrambling to migrate to HTTPS once Chrome 68 is released and bold red “not secure” warnings are being displayed prominently. Consult with your dev teams and stakeholders now to mitigate any panic with this release. We’ll skip the site-migration-traffic-dip horror stories, but believe you me, they’re real.
A migration to HTTPS can seem like a daunting task, especially for large websites. Break it down into smaller steps and have a plan of attack. Did I miss any steps? Leave them in the comments below.
