A few days ago, I moved this blog to fully (and only) HTTPS. I’d been on Cloudflare for a few months but I didn’t realise that it was inadventently causing a site-wide duplicate content issue (between HTTP & HTTPS URLs). In this post I document the discovery of the issue, the process I took to fix it, and the potential knock-on effects of the change, such as needing to set up a new Google Search Console profile, ‘mixed content’ issues and more…
A few months ago, I moved SEOno to Cloudflare. The site was getting a ridiculously high number of malicious login attempts, and while none of them got through (thankfully), I looked into it and the volume of them suggested that it was slowing my site down. I moved onto Cloudflare – a fairly quick, painless process – and not only have the login attempts ceased, but the site is tons faster. Job done.
At the time, I noticed that HTTPS URLs were working on the site, in addition to HTTP URLs. In other words, https://seono.co.uk/ loaded the homepage, as did http://seono.co.uk/, whereas only the latter had done previously. “Cool,” I thought, thinking nothing of it for ages – I figured that the rel="canonical" tag of the HTTP URLs would take precedence, and at some point I’d sort it out properly.
Then, a few days ago, I was chatting to someone at my coworking space and did a very specific Google search that only brought up seono.co.uk results. And that’s when I spotted it: Google was indexing both HTTP and HTTPS URLs separately…
Uh-oh. This full-on flummoxed me for a few moments, until I checked the canonical tags of both versions. Here’s the one for HTTP…
…and here’s the one for HTTPS…
Rather than having the same canonical tag (and therefore one ‘version’ taking precedence over the other), they were each referencing themselves separately. This meant that the introduction of the HTTPS URLs had resulted in a duplicate content issue site-wide, with every page of the blog having two URLs showing the exact same content. Given the fact that Google was indexing some URLs of one type and some of the other (rather than all of one and none of the other), it was looking as though Google was struggling to understand which version to show predominantly. And worst of all? I hadn’t noticed for months, despite picking up on issues like this when I do technical SEO audits for clients. D’oh.
This was the motivation to move the blog fully onto HTTPS. By “fully” I mean that only HTTPS URLs would be live – if someone accessed a HTTP version of the URL, they’d be 301 redirected to its HTTPS counterpart.
Going fully HTTPS with Cloudflare
Thankfully, Cloudflare makes this process really easy. I found their article titled “How do I redirect all visitors to HTTPS/SSL?“, which says that you can create a Page Rule that enforces HTTPS. With this activated, HTTP URLs do indeed 301 redirect to their HTTPS counterparts, which is the ideal outcome. I double-checked a few random HTTP URLs in a server header checker tool, just to be sure (here’s a link to the results page for a random URL):
I’d also like to give this article by Pantheon a mention, as it was also pretty handy.
Job done! …Or was it?
Addressing and fixing ‘mixed content’ issues
Job done! Of course it wasn’t! Because life sucks and nothing’s ever easy.
While every page now only ‘lived’ on a HTTPS URL, browsers weren’t reporting that it was ‘secure’. Chrome would show an ‘(i)’ icon while Firefox did the same but also included a more alarming-looking exclamation-mark-in-a-yellow-triangle…
Cloudflare to the rescue again! As a follow-on from the first article (linked above), they also had an article titled “How do I fix the SSL Mixed Content Error Message?“. This explained that ‘mixed content’ was when a URL was showing as HTTPS, but the content showing on its page wasn’t fully secure. It turned out that some of the images on the site were still hosted on HTTP URLs. I followed the steps in another related Cloudflare article (“How do I use Automatic HTTPS Rewrites?“) in an attempt to address the issue, but my site’s pages were still showing as having ‘mixed content’…
So I took two additional courses of action:
1) Using the SSL Insecure Content Fixer plugin
I was nervous about using a plugin to help out, but when I saw that SSL Insecure Content Fixer had an average score of 4.9 out of 5, I was reassured that my site wouldn’t suddenly explode.
I installed and activated the plugin, and gradually tried the different settings…
Given the message right at the top of the page…
Select the level of fixing. Try the Simple level first, it has the least impact on your website performance.
…I was reluctant to put it on a high setting, so I gradually tried different options.
2) Manually changing image links from HTTP to HTTPS
Truth be told, I probably could’ve used a higher setting of the plugin without any problems, but to be on the safe side, I left it on ‘Simple’ or ‘Content’ (I can’t remember which)* and then also manually changed the URLs of images in the blog’s sidebar:
In the example screenshot above, this was previously saying “http” rather than “https”. I made the change to “https” to all images in the sidebar, even going as far as two images that weren’t even hosted on SEOno (which was probably overkill, but I wanted to be sure and thought that I might as well change those as well, while I was editing the others)…
I also edited my SEOno logo (right at the top), using the Customise function on the theme (rather than via Appearance > Widgets).
As a result of both of these actions (although the right setting in #1 could’ve been enough admittedly), I started to see the ‘Secure’ badge in both Chrome and Firefox for various pages:
Job done – FINALLY. Phew.
I also used this SSL crawl checker tool by JitBit to check a few URLs. Previously it was reporting a problem with all URLs that it crawled, but now it was reporting that everything was a-ok:
* It’s currently on ‘Content’ in my site’s settings, but while I was playing around with these tweaks, it might’ve still been set to ‘Simple’. Hope that makes sense.
The knock-on effects of going HTTPS
Despite recently recommending to clients that it might be worth considering going fully HTTPS because Google recommends it and because they’ve been saying for years that it helps your SEO, it’s not as simple as redirecting HTTP URLs to HTTPS and that’s it (as I found out above). However there are a few other knock-on effects that need to be considered and/or other things you’ll need to do as part of the overall process:
Creating a new Google Search Console profile for HTTPS
This one’s not really an enormous hassle, but it’s easily forgotten about…
I had a ‘http://seono.co.uk/’ profile on Google Search Console for the blog (and even a ‘http://www.seono.co.uk/’ profile so that I could set my preferred domain), but not a ‘https://seono.co.uk’ profile. I quickly set one up following the move to HTTPS. However I also took the following steps:
- I removed the XML sitemaps on the http profile (so as not to confuse Google too much)…
- …And added XML sitemaps to the https profile instead
- I also used Google’s Fetch as Google tool to fetch https://seono.co.uk/ and requested indexing of the URL and its linked page (more info here)
There’s probably a ton more GSC-related stuff I could (or should) have done, but that’s all I did at the time. Perhaps more needs to be done, as the ‘transition’ hasn’t been especially smooth in Google’s results (more on that below)…
Quick Google Analytics tweak
I’m not sure if it’s even necessary(!), but to be on the safe side, I changed the Profile URL in the settings of SEOno’s Google Analytics account from HTTP to HTTPS.
It’s really quick and easy to do, as you’ll see here.
Could my backup plugin be affected?
I use UpdraftPlus to back up SEOno – and three other WordPress site that I manage – on a weekly basis. My immediate thought: would the plugin be affected?
A backup was due to be run about two days after the change, so I thought I’d wait and see what happened first. Thankfully it was all fine, and the backup ran as smoothly as always.
I noticed that UpdraftPlus has a section relating to HTTPS/SSL issues in its FAQ section, which would’ve been my next port-of-call had there been any problems – but it was all good.
It’s worth thinking about though: would the move to HTTPS affect your site’s backup plugin? It’s best to double-check that it’s still all working smoothly as soon as you can following the change – you don’t want to assume that it’s fine and then weeks/months/years later find out that it’s not been working properly the whole time…
And while we’re on the subject of backups, it might also be worth doing a full backup before you make the move to HTTPS. Just in case.
Link building: the ‘loss of SEO value’ in redirects
Despite Google saying a few months back that they were going to change the rules on how they would treat redirects, the classic stance is that 301 redirects pass on 90-99% of their SEO-y goodness to the destination. This means that 1-10% of that juicy SEO-y goodness is ‘lost’ in the process, from the original URL (HTTP) to the new URL (HTTPS).
SEOno has been going for nearly 6 years (since April 2011), and it’s accumulated inbound links from over 200 linking root domains in that time (according to Majestic). Of course, they’re all most likely linking to the HTTP versions of the URLs, meaning that they’re now 90-99% as effective, rather than 100%.
Now I could go around and change all of those that I have access to – e.g. social media profiles, other sites that I own (e.g. MOM), other sites that I write for and have direct access to (e.g. State of Digital), and so on – but it’s a lot of work, I’d probably only be able to change a handful of all the links out there, and it’d probably only give me minimal uplift (in other words, it’d be more hassle than it’s worth in terms of pay-off).
So while going HTTPS supposedly gives your site an SEO boost, you’re changing all your URLs and setting up redirects, which could potentially negate that boost. Be sure to keep that in mind if you decide to do the same.
The aftermath (a few days later)…
So… what of my rankings? Well, it’s only been a few days, so it’s far too early to tell yet. I wanted to get this post out there while everything was still fresh in my mind – the risk with waiting a few weeks/months in order to be able to also report back on rankings could’ve meant that I’d forgotten everything I’d done.
What I do know at this stage: I run a daily rank check and the HTTPS version of the homepage got picked up yesterday (1st March), a few days after the change. Half of the pages I’m tracking are still showing as HTTP, while the other half are HTTPS (admittedly I’m not tracking many keywords – only a dozen or so).
And as I publish this, here’s the ‘site:’ search numbers for HTTP vs. HTTPS:
- HTTP URLs in Google (site:http://seono.co.uk -inurl:https) = 183
- HTTPS URLs in Google (site:https://seono.co.uk -inurl:http) = 58
Still a ways to go. That said though, I checked the HTTPS number a couple of days ago and it was around 40, so it’s heading in the right direction – that much is for sure.
If anything weird/remarkable/out-of-the-ordinary happens then I’ll be sure to do a follow-up post offering a tad more insight.
Do you use Cloudflare? Have you migrated to HTTPS? Is your content fully secure, and what methods did you use to do so? What’s your experience of the whole process of going HTTPS from start to finish? Be sure to drop a comment below or tweet me if you have anything to share.