Moving SEOno to HTTPS: How Using Cloudflare Caused a Duplicate Content Issue

HTTPS Secure badge image
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…

SEOno Google SERP screenshot
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…

SEOno HTTP canonical screenshot
…and here’s the one for HTTPS…

SEOno HTTPS canonical screenshot
Bollocks.

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):

SEOno HTTP redirect check screenshot
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…

SEOno SSL Mixed Content in browsers screenshot
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…

SSL Insecure Content Fixer plugin settings screenshot
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:

Image URLs in widgets screenshot
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:

SEOno SSL Secure in browsers screenshot
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:
JitBit SSL tool screenshot
* 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.

Google Analytics https URL tweak screenshot
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:

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.

6 Comments

  • James Cavanagh

    March 6, 2017 at 3:24 pm Reply

    As you changed your analytics URL, did you change your search console verification too? I recently discovered a potentially huge duplicate content issue thanks to the use of varying TLDs and them all showing in search because they don’t 301 redirect to a “primary site”

    • Steve

      March 7, 2017 at 8:44 am Reply

      Hi James. Do you mean the ‘preferred site’ setting or something else? I think I’ve got that sorted (if you mean the former). Thanks for the heads-up either way!

  • Junade Ali

    March 6, 2017 at 3:47 pm Reply

    Hi Steve;

    Mixed-Content issues in WordPress can be a pain and certainly aren’t unique to using Cloudflare. We have a breakdown on how the broken lock icon or redirect loops can be fixed here: https://support.cloudflare.com/hc/en-us/articles/203487280-How-do-I-fix-mixed-content-issues-or-the-infinite-redirect-loop-error-after-enabling-Flexible-SSL-with-WordPress-

    Additionally, when enabling SSL, it’s a good idea to use the “Always Use HTTPS” Page Rule option in Cloudflare as this will mean that all non-HTTPS pages will be redirect to HTTPS.

    • Steve

      March 7, 2017 at 8:45 am Reply

      Awesome, thanks Junade! I think I chose “Always Use HTTPS” but I’ll double-check. Thanks for passing on that link as well – very handy. đŸ™‚

  • Anna

    March 23, 2017 at 11:15 am Reply

    Thanks Steve ! This is very useful and interesting information
    I have a problem with this

  • […] Moving SEOno to HTTPS: How Using Cloudflare Caused a Duplicate Content Issue (main pic) […]

Post a Comment