I recently moved some of my sites from regular HTTP to HTTPS. This was something entirely new for me. And it was something that I had been dreading for a while, mainly because of the risk of damaging my sites’ search rankings, breaking inbound links, and losing traffic.
The reasons I wanted to move them to HTTPS were mostly to do with investments in the future. My sites don’t currently handle any sensitive information like credit cards or addresses. But there are other reasons to switch to HTTPS.
- I wanted to take advantage of the speed benefits of HTTP/2.
- Google prefers HTTPS now and uses it as a ranking factor, and it’s pretty clear that that will only increase over time.
- I wanted to lock down the back end of my site with encryption so that when I log into my WordPress dashboard while traveling there’s much less risk of someone intercepting my login credentials (I also typically use a VPN, but every now and then I’ll come across a wifi network that blocks VPNs).
- And I wanted my site’s visitors to have that little bit extra assurance with the green padlock at the top of the browser window.
None of that was urgent. But I knew that I wanted to make the move at some point and figured that it would be less painful now than later.
And so I recently decided to pull the trigger. Here are some of the things that I learned along the way in the hope that they might be useful for others looking to move their sites over.
But first I want to emphasize that this is not a guide to moving WordPress sites HTTP to HTTPS. Since I originally published this post I’ve moved several more sites to HTTPS, but I am by no means an expert on it. But if you’re looking for an excellent guide, I recommend Brian Jackson’s guide. That’s what I used for the basis of my move. Google has their own guide. And John Mueller’s FAQs are also definitely worth looking at.
And it’s definitely worth noting that I’m using managed hosting. In my case it’s Kinsta. They can set up the server better, faster, and more securely than I can myself, and they can fix any problems that come up much quicker than I can. Basically, it’s a better investment for me to pay a bit extra for premium hosting than to spend time doing it myself. Over the years I’ve set up and run my own servers, but I can tell you that “site down” messages aren’t much fun when you’re about to board a ship to Antarctica or running to catch a bus in Vietnam. I like that to be someone else’s problem so I can focus on shooting photos and writing posts. So it was the experts at Kinsta who actually installed the certificate and set up the server-side 301 redirects for me while I focused on changes needed on the site like changing links from HTTP to HTTPS, troubleshooting in-page SSL errors, relinking external services like the CDNs, fixing sitemaps, and modifying my Google Search Console properties.
Site Speed Improved
Years ago, the processing overhead from HTTPS encryption could slow page loading down. And it’s still widely believed that that’s the case. But it turns out that it’s no longer true. And not only are HTTPS not slower, they can actually be quite significantly faster. That’s thanks to the speed benefits that come with the vastly more efficient HTTP/2 protocol. I’ve found marked speed improvements on all my sites that I’ve moved. This alone is reason enough for me to move most of my remaining sites over to HTTPS.
Google Indexing Took a (Temporary) Hit
I followed the recommended practices in all of the links mentioned above. I used 301 redirects, claimed all the relevant properties is Google’s Search Console (formerly Webmaster Tools), and submitted new sitemaps that had the HTTPS versions. My Google indexing status went from 100% to 0% in 24 hours. And while I hoped they would recover, I also knew it was entirely possible that I’d done something wrong and just wiped my sites off the face of the internet. So I rechecked everything again and asked my host to recheck the server-side 301 redirects.
It turns out it was done correctly all around and I just had to wait out Google getting to know my sites again. It took a few weeks, but my sites recovered back to their pre-switch indexing levels.
Here’s an example from Google Search Console. This is using the newly claimed HTTPS version of the property, which is why it starts at 0.
The images tab for the same website is even more dramatic.
And here’s a very different one from another site that I moved at the same time. So this is over the same time spread at the charts in the first site above.
And the images tab from that same site:
Honestly, this surprised me. Google is at the forefront of encouraging users to move sites to HTTPS. And I interpreted these comments by Google’s John Mueller as suggesting that it would be smoother than it ended up being.
Will I see a drop in search? Fluctuations can happen with any bigger site change. We can’t make any guarantees, but our systems are usually good with HTTP -> HTTPS moves.
Do I lose “link juice” from the redirects? No, for 301 or 302 redirects from HTTP to HTTPS no PageRank is lost.
It turns out I just needed to be patient, but that’s a big leap of faith when your site is a big part of your business. And it seems like this is an area where Google could make things go more smoothly — or at least offer more reassurance. If they want to encourage more people to move to HTTPS, they could make it less of a leap of faith, at least as it concerns Google indexing status.
But the good news was that the dramatic drop-off in indexing didn’t mean a dramatic drop-off in traffic. I suspect that there’s an overlap while the old HTTP versions were still be indexed and the new HTTPS are being picked up.
I did see a bit of a traffic drop-off. While it still counts as a significant amount, it’s not as much as I’d feared. But it proved to be only temporary and it bounced back a couple of weeks later. It’s now sitting a little above the pre-HTTPS-switch levels. It’s impossible to tie that directly to the move to HTTPS, but it’s a possibility.
There are Different Kinds of Certificates
This might be really obvious, but since I’d never looked into it I didn’t know. There’s actually several different ways to procure a certificate, from the traditional buying one to using one that’s bundled with services like Cloudflare Pro, to using Let’s Encrypt.
And it’s important to get the right certificate. I originally purchased individual certificates for each individual domain. But for whatever reason, my hosts could only install one certificate on my server. I don’t know if that was for technical or policy reasons, but it’s worth checking with your host before you buy the certificate.
In my case, the best fit was what is known as a multi-domain certificate. If you want to include subdomains, you’ll probably need a wildcard certificate.
There are also different categories, from ones that simply validate your domain to others that validate the company behind the domain and then others that take that a step further and add the green bar in the browser window.
The simplest ones–simple domain validation–are also the quickest. I got mine within about 15 minutes. The extended validation ones require the certificate authority to research the company as well, and they can take a week or two to be issued.
Let’s Encrypt Works
It’s also possible to use free certificates through an initiative called Let’s Encrypt. I don’t understand the ins and outs of it, but I know as an end-user that it works.
Let’s Encrypt is a bit different to the other certificate authorities. It’s an initiative with a lot of backers to make SSL more accessible. And it’s something that needs to be handled on the server side with a certificate management agent. Some hosts and services have it built-in and offer it. Cloudflare and KeyCDN are examples where it’s built-in to their services. In my case, it meant I didn’t need to buy a separate wildcard certificate for my cdn subdomains. And it’s something I’m curious to learn more about, because it’s possible it might meet my needs perfectly well without needing to pay separately for domain certificates.
Some Embedded Content Might Not Work
When I first switched over, I was getting the “https://” in the URL location bar but not the green lock. That’s because some of the embedded items in my page weren’t being called over SSL. It was the mixed content problem.
An example was the Mailchimp signup forms. (Here’s the fix I used). Some plugins did it too. And at least one of my graphics was being called from a non-encrypted source.
So I had to go through and find all of the parts that were breaking the SSL trust. In most cases, that was just tedious. Finding them was pretty easy using Chrome’s Developer Tools.
But I did run into one major unpleasant surprise, and that is that the Photoshelter HTML5 galleries that I use extensively on the site don’t work with HTTPS. They’re aware of the issue and apparently working on a fix, but I have no idea how long that will take. For now, I’ve had to find another solution, which has proved a bit of a headache.
Google Adsense Embed Code Update
If you’re using Google Adsense (or another ad provider, for that matter) you might need to update your embedded ad code to serve only HTTPS ads. Here’s the info for Adsense.
While the process hasn’t been perfectly smooth all the way, overall I’ve been pleasantly surprised by how it has gone and I’ll be moving more of my sites over at some point soon. The speed improvement I’ve seen with HTTP/2 alone is enough to convince me that it’s well worth doing.