Articles Tagged with Technical SEO

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

Published on December 20, 2018August 4, 2020 by Steve

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

Published on March 2, 2017 by Steve

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 https://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…

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!

Getting Bulk PA Data for 404s with URL Profiler

Published on December 5, 2015December 5, 2015 by Steve

I’ve been using URL Profiler on-and-off for a few months now, mainly for full-on link analysis – especially when it comes to penalty removal and disavow work. However, as I’m sure other folks have discovered, there’s a few other cheeky ways that the software can be put to good use. I found one, and after a chat with Patrick (one of URLP’s founders), I thought it’d be a good idea to throw it up as a quick blog post.

The challenge – 404orama!

I have a client who – despite only having a 1,000-page website – has over 5,000 404 (Page Not Found) errors associated with it. Over 5,000! (Pity it’s not over 9,000, otherwise I could use this. Anyhow…)

The number is so high due to a variety of reasons:

They’ve redesigned the site a few times in the past, which has included URL changes, but have never redirected old URLs to the new URLs,
A lot of random and/or duplicate URLs have been auto-generated due to a bug or two caused by their CMS system,
Simply due to pages being removed by the client’s internal teams (for archiving purposes) but not being redirected.

When you’re dealing with such a high quantity of 404s, it’s difficult to know where to start. My plan was to get PA (Page Authority) data on every URL, so that I could at least work through the list bit-by-bit starting with those with the most SEO value and therefore the most urgent to fix.

Enter URL Profiler. One of the many bits of data that it can grab is none other than PA. This gave me an idea…

The process

The process was dead simple. Instead of putting in a list of external URLs (as one might do when using it to conduct link analysis), I put in the whole list of 5k+ internal URLs, which was collated using a mix of Google Search Console data and a full-site Screaming Frog crawl.

I asked URLP to find PA data on all of them, let it run, and boom: PA data on 5k+ URLs. Sort from highest PA to lowest and that’s your priority order sorted.

The only problem? I now have the delightful task of figuring out where they should be redirected to. Hopefully chunks of them will follow patterns, and that I won’t need to run through all 5k+ individually(!), but either way – wish me luck…!

3 Interesting Observations From 3 Recent Small Business Domain Migrations

Published on November 26, 2013November 26, 2013 by Steve

Since going freelance over 6 months ago, I have helped a few small businesses with domain migrations, making sure that they’re all done in an SEO-friendly fashion.

What is a domain migration? Some people might call it something else (e.g. site migration, domain change, etc.) but it’s basically the case of moving your site from one domain to another. For example, I might consider moving SEOno.co.uk to SEOno.com, with all of its URLs following suit – e.g. SEOno.co.uk/category/seo/ would become SEOno.com/category/seo/, with the former (ideally) redirecting to the latter in each and every instance.

A simple domain migration is when none of the URLs are changing (except for the domain itself). Obviously a domain migration involving a complete URL restructure can complicate things slightly.

A tale of 3 domain migrations

There’s a number of reasons why someone might want to migrate domains…

In one of the cases, the client mainly wanted to move from a .co.uk to a .com (to improve his chances of rankings more globally and attracting international enquiries) but also wanted to use it as an excuse to ‘rename’ the business slightly.

For the other two clients however, it was my recommendation. They were using EMDs (Exact Match Domains) – i.e. keyword-heavy domains (e.g. seo-in-cardiff.com rather than actualbusinessname.com) – which I have never been a big fan of, so I recommended that they migrate to more brand-focused domains, which I thought would improve their click-through rate from the SERPs and look more trustworthy to searchers. In both cases we had only just started working together, so it made sense to make the change ASAP, before tasks such as link building and citation building were carried out in full force.

While all 3 sites are only small (we’re talking no more than 100 indexed pages for the biggest; only 20 for the smallest), they all had different circumstances, with none of them being quite the same. Only 2 of them were migrating from EMDs to branded domains. Only 2 of them were retaining all the URLs on the new site (i.e. not changing any URLs around in the process). Only 2 of them mapped out the redirects (with one of them, all the old domain’s URLs simply redirect to the new domain’s homepage instead). And only 2 of them utilised the Change of Address tool in Google Webmaster Tools.

Here’s a table, because none of that probably made any sense…! Please forgive the plainness of its appearance (there’s a good reason why I’m an SEO and not a graphic designer):