by Path Digital on March 5, 2018
/ 0 comments leave a reply
The rel=canonical tag is a piece of HTML code inserted in the <head> to indicate to search engines the “master copy,” or canonical, URL to index where the same or very similar content exists across URL versions. It’s useful in cases like these:
1) When filters and other parameters are appended to the URL (?color=red, ?color=blue)– a common situation with ecommerce platforms especially – the canonical tag indicates only one URL version should get indexed
2) Across sites/domains (HTTP, HTTPS, www, no www) to indicate to Google a preferred site to index
3) As a ‘self-referencing’ canonical (a URL with a canonical tag pointing to itself), which can act as a reinforcement signal
4) For migration SEO efforts, as a reinforcing signal to search bots that a new site version should be indexed over old versions
The last case is what we want to focus on here, since there’s still some confusion on the use of the canonical tag for HTTP>HTTPS and other domain-wide migrations. From Luna Metrics: “Using a self-referring canonical on the destination page of 301 redirects is a one-two combo for successfully transferring a page. Google will follow the 301 to the new destination, when it gets there the self-referring canonicals acts as a confirmation that the page they have landed on is indeed the new location of the old page. It is of utmost importance that these two are correct and are working together.”
And Google confirms in its“Moving a Site with URL Changes” guide, “Each destination URL should have a self-referencing rel=”canonical” LINK tag.”
SO, assuming a common, straightforward migration where every URL on your current site has a matching URL on the new site (like an HTTPS switch), the belowsitewide rel=canonical tactics are easy enough for anyone with a working knowledge of WordPress to do — and as added “reinforcement,” they may help your brand new domain or HTTPS site get indexed by Google faster. Yay! Yes, I’m saying that these steps can help with site migrations, assuming that A) your new domain/HTTPS URLs are “copies” of the old domain/HTTP URLs, B) you have backend access to make a simple, programmatic sitewide change.
Note: if you’re moving across platforms in addition to a site migration (where the new site & URL structure get completely revised), proceed with caution. Step 1 below can still apply.
Within WordPress, these are simple code adds to either your functions.php or header.php files.
Let’s look at one of the most common WordPress migrations, a simple switch from HTTP to HTTPS where on-page content and URL strings stay intact. (Assuming page content/URL strings stay constant, you can apply these to a domain migration and to other platforms as well. With WordPress, we utilizeYoast SEOto make this as simple as humanly possible.)
For HTTP>HTTPS, as part of your migration SEO effortyou can simply remove the rel=canonical directive in your HTTP WordPress installation telling Google that “HTTP” is canonical before you switch.
And if you’ve got the Yoast SEO plugin set up, that can be as simple as uninstalling Yoast.
But if for whatever reason you don’t want to or aren’t able to uninstall Yoast from the HTTP site, you can also add this code to your functions.php file:
One scenario where you may not want to uninstall Yoast: for cross-domain migrations.If your WordPress site uses Yoast for XML sitemaps and is moving to a new domain, for example, you should keep the old XML sitemap index active if possible; this is mentioned in the Luna Metrics link above and other migration SEO guides as a reinforcement step. In that case, keep Yoast installed on your old site and use the code above.
Next, simply installing Yoast — with self-referencing canonicals “out of the box” — on the new site/HTTPS will act as a signal to Google to index HTTPS instead. With site migrations being one of the most complex, difficult SEO tasks out there, we want to utilize the power of rel=canonical to aid with re-indexingsitewide… while your one-to-one 301 map does the heavy lifting at the page level.
I’ve seen many cases where sites have completed an HTTP>HTTPS switch and the HTTP pages remain in Google’s index for months… so I’d also recommend this step in combination with #2 below if you’re seeing an old site still getting crawled and indexed in Google Search Console several months after a site migration, for example.
As a reinforcement signal to Google that HTTPS should be canonicalized across all of your HTTP pages, we can go one step further to get your new HTTPS site version indexed quickly. (Credit to bryanhadaway.com for the original code, which I modified very slightly by adding an “s” to “http”.)
In the old HTTP installation (with Yoast canonicals removed – step 1), before doing the sitewide redirect add this in WordPress>Appearance>Editor>”header.php” before the closing <head>:
This way, you now have canonical tags set up across HTTP/HTTPS site properties indicating to Google that HTTPS is canonical. Often it takes a long time for the HTTP version to fully drop out of Google’s index, so that’s why I’d recommend this for a larger site especially. (Of course, the above assumes your URLs stay constant other than adding “s” to “http.” A variation of this could also work for a domain migration where only the domain address changes, and URL strings are constant.)
Don’t have a way to modify your old/HTTP site’s “functions.php” in WordPress?
It’s definitely not uncommon for a HTTP>HTTPS migration to not go smoothly… especially if a site migration doesn’t followbest-practice SEO steps involved. In the particular case I encountered a few months back — a client with a sitewide redirect set up and Search Console indicating HTTP pages still visible in Google’s index — we were working with a WordPress installation that had Yoast installed, and the site developer was able to work out a custom functions.php add that did the trick. (He took a Yoast SEO hook from a forum resource I found, and customized it as follows.)
The below should work to indicate “HTTPS” canonical domain-wide if your HTTP site is redirecting to HTTPS, as it did quite effectively for my client’s site per the screenshot above. Add to your HTTPS “functions.php”:
If you try this last tactic, please let me know how it goes in the comments!