Articles Tagged with HTTPS

Caught Out by Canonicals – A Quick Tip When Migrating from HTTP to HTTPS

Cannonical! Get it? Canonical, cannonical?! Ahahahahahaaa...It’s been a while since my last post on here (over 4 months – yikes!) but I thought I’d quickly put this out there based on a recent private Facebook group interaction. A few people said it was a good tip, so I thought it’d be a good idea to blog about it just in case anyone else encounters the issue as well…

A friend of mine added me to a private SEO group on Facebook and subsequently posted asking the group for advice. His client had just migrated their website from HTTP to HTTPS (something I’ve written about before by the way, if you’re looking for a guide) but unusually the Google Search Console (GSC) profile for the HTTP version (e.g. “http://www.example.com/”) was still showing data in its Search Analytics section and he couldn’t figure out how or why.

Funnily enough, I’d just had this exact issue with a client of mine so I chipped in with my experience. The culprit? That cheeky canonical! *shakes fist*

Short version: if you’re migrating from HTTP to HTTPS, making sure your canonical URLs follow suit, i.e. they all reference HTTPS versions of the URLs, not HTTP versions!

Seems obvious, right? And it might be. But it’s worth double-triple-checking just in case they don’t behave as expected, especially if you have some that have been manually configured in the past (in which case they may not simply auto-update in conjunction with your migration efforts).

For more detailed info, read on…

That pesky canonical tho

First things first, my friend didn’t reveal his client, and I’m under an NDA with my client, so this is going to be an entirely anonymous anecdote. Sorry!

A canonical URL tells search engines that the page you’re serving is the ‘primary’ version of the URL, which is a good way to side-step potential duplicate content issues. There’s a good guide on canonicals over on Moz if you’re new to the concept and want to learn more about it.

Click to read more!

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.

Click to read more!