Moving from HTTP to HTTPS

Posted: Apr 07, 2017

HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted.

Data sent using HTTPS is secured via Transport Layer Security protocol (TLS), which provides three key layers of protection:

Encryption. Encrypting the exchanged data to keep it secure from eavesdroppers. That means that while the user is browsing a website, nobody can "listen" to their conversations, track their activities across multiple pages or steal their information.

Data integrity. Data cannot be modified or corrupted during transfer, intentionally or otherwise, without being detected.

Protection. Protection is important when it comes to handle money transfers like with online banking or for e-commerce sites, so you definitely don't want anyone malicious to send another copy of commands and transfer twice.

Authenticity. Proves that your users communicate with the intended website. It protects against man-in-the-middle attacks and builds user trust, which translates into other business benefits. This is the major benefit of sending data via HTTPS as it tells the end user that the content delivered is from the source and it hasn't been tampered with in any way.

Moving Forward

Start with a test server. This is important because it lets you get everything right and test without screwing it up in real time. Even if you are doing the switch without a test server, there’s almost nothing you can do that you can’t recover from, but it’s still best practice to have a plan and have everything tested ahead of time.

Crawl the current website so that you know the current state of the website and for comparison purposes.

Read any documentation regarding your server or CDN for HTTPS. I run into lots of fun CDN issues, but it can also be straightforward.

Get a security certificate and install on the server. This will vary depending on your hosting environment and server setup too much for me to go into details, but the process is usually well-documented.

Update references in content. This can usually be done with a search-and-replace in the database. You’ll want to update all references to internal links to use HTTPS or relative paths.

Update references in templates. Again, depending on how you deploy, this might be done with Git or simply Notepad++, but you’ll want to make sure references to scripts, images, links and so on are either using HTTPS or relative paths.

Update canonical tags. Most CMS systems will take care of this for you when you make the switch, but double-check, because that’s not always the case.

Update hreflang tags if your website uses them, or any other tags such as OG tags for that matter. Again, most CMS systems will take care of this, but it’s best to QA it just in case.

Update any plugins/modules/add-ons to make sure nothing breaks and that nothing contains insecure content. I commonly see internal site search and forms missed.

CMS-specific settings may need to be changed. For major CMS systems, these are usually well-documented in migration guides.

Crawl the site to make sure you didn’t miss any links and nothing is broken. You can export any insecure content in one of the Screaming Frog reports if this is the crawler you are using.

Make sure any external scripts that are called support HTTPS.

Force HTTPS with redirects. This will depend on your server and configuration but is well-documented for Apache, Nginx and IIS.

Update old redirects currently in place (and while you’re at it, take back your lost links from redirects that haven’t been done over the years). I mentioned during the Q&A portion of the Technical SEO Panel at SMX West that I’ve never had a site drop in rankings or traffic when switching to HTTPS, and a lot of people questioned me on this. Due diligence on redirects and redirect chains is likely the difference, as this is what I see messed up the most when troubleshooting migrations.

Crawl the old URLs for any broken redirects or any redirect chains, which you can find in a report with Screaming Frog.

Update sitemaps to use HTTPS versions of the URLs.

Update your robots.txt file to include your new sitemap.

Enable HSTS. This tells the browser to always use HTTPS, which eliminates a server-side check and makes your website load faster. This can also cause confusion at times, since the redirect will show as 307. It could have a 301 or a 302 behind it, though, and you may need to clear your browser cache to see which.

Enable OCSP stapling. This enables a server to check if a security certificate is revoked instead of a browser, which keeps the browser from having to download or cross-reference with the issuing certificate authority.

Add HTTP/2 support.

Add the HTTPS version of your site to all the search engine versions of webmaster tools that you use and load the new sitemap with HTTPS to them. This is important, as I’ve seen traffic drops misdiagnosed because they saw the traffic in the HTTP profile drop, when the traffic in reality moved to the HTTPS profile. Another note for this is that you do not need to use the Change of Address Tool when switching from HTTP to HTTPS.

Update your disavow file if you had one for the HTTPS version.

Update your URL parameter settings if you had these configured.

Go live!

In your analytics platform, make sure you update the default URL if one is required to ensure that you are tracking HTTPS properly, and add notes about the change so that you know when it occurred for future reference.

Update your social share counts. There’s a lot of gotchas to this, in that some of the networks will transfer the counts through their APIs, while others will not. There are already guides for this around if you are interested in keeping your share counts.

Update any paid media, email or marketing automation campaigns to use the HTTPS versions of the URLs.

Update any other tools such as A/B testing software, heatmaps and keyword tracking to use the HTTPS versions of the URLs.

Monitor everything during the migration and check, double-check and triple-check to make sure everything is going smoothly. There are so many places where things can go wrong, and it seems like there are usually several issues that come up in any switch to HTTPS.