Canonicalization is a way of telling Google: “I have multiple versions of this page, but this one is the official version.” It sounds technical. It is. But it matters for SEO.
Without proper canonicalisation, Google might index duplicate versions of your pages. Your link equity gets split across multiple URLs. Your content gets diluted. Your rankings suffer.
This post covers why canonicalisation matters, how to implement it, and the most common mistakes teams make.
Why Canonicalisation Matters
The web has a duplicate problem. A single product page might be accessible via three different URLs:
- example.com/products/wallet
- example.com/products/wallet?ref=internal
- www.example.com/products/wallet (with www)
To humans, these are the same page. To Google, they’re three different pages.
Google will try to figure out which is the “real” version. Sometimes it guesses right. Often it doesn’t. The result: your link equity gets split across URLs. Rankings get hurt. You lose visibility.
Canonicalisation solves this. You tell Google: “Here’s the one authoritative version. Treat all duplicates as pointing to this one.”
How Canonicalisation Works
You implement canonicalisation using a `` tag in the HTML header of your page:
``
This tag says: “The official version of this page is example.com/products/wallet. Even if you’re reading this from another URL, know that it’s a duplicate.”
You place this tag in every version of the page. All three URLs above would have the same canonical tag pointing to the same “official” version.
Scenarios Where Canonicalisation Matters
Scenario 1: Query parameters. Your site uses multiple URL parameters for filters, sorting, or tracking. example.com/products?sort=price and example.com/products?sort=rating are the same content. Canonicalise both to the base URL.
Scenario 2: WWW vs non-www. Your site is accessible with and without www. Pick one. All non-www versions should canonicalise to the www version (or vice versa). Be consistent site-wide.
Scenario 3: HTTPS vs HTTP. Older sites might have both. Canonicalise HTTP to HTTPS (which is the modern standard anyway).
Scenario 4: Mobile vs desktop versions. If you have separate mobile and desktop URLs, canonicalise the mobile version to the desktop version. (Most sites are now responsive and don’t need separate mobile versions.)
Scenario 5: Duplicate content across domains. You might syndicate content to Medium, LinkedIn, or other platforms. Canonicalise their versions back to your original on your domain. This tells Google your site is the primary source.
Scenario 6: Paginated content. A blog archive with multiple pages (page 1, page 2, page 3). Page 2 should not have a canonical tag (or should canonicalise to itself). Treat paginated content carefully.
Self-Referential Canonicals
Every page should have a canonical tag. Even the “official” version.
The official version should canonicalise to itself. This might sound redundant, but it’s important. It tells Google: “I’ve thought about this and confirmed this is the version I want indexed.”
Example: example.com/products/wallet has the canonical tag `` See technical SEO basics. See redirection management.
This is standard practice and protects you if someone accidentally creates a duplicate of your page elsewhere.
Relative vs Absolute URLs
Always use absolute URLs in canonical tags, not relative URLs.
Wrong: ``
Right: ``
Google is more reliable at processing absolute URLs. It removes any ambiguity about the full domain.
Common Canonicalisation Mistakes
Mistake 1: Canonicalising to the wrong version. If you canonicalise page B to page A, but page B is better-optimised for a specific keyword, you’re hurting your rankings. Be intentional about which version is “official”.
Mistake 2: Cross-domain canonicals without HTTPS. If you’re canonicalising from HTTPS back to HTTP, Google might not follow it (HTTPS is preferred). Always canonical to HTTPS.
Mistake 3: Canonicalising paginated content incorrectly. Don’t canonicalise page 2 to page 1. Let paginated pages canonicalise to themselves. Treat each page as a separate entry point.
Mistake 4: Forgetting query parameters on the canonical URL. If a page is accessed via example.com/products?category=wallets, the canonical should include the query parameter: ``
Mistake 5: Inconsistent canonicalisation. If you sometimes canonicalise www to non-www and sometimes the reverse, Google gets confused. Pick one and stick with it site-wide.
Mistake 6: Using canonicalisation as a shortcut for redirects. Canonicalisation is not a redirect. It doesn’t preserve all link equity perfectly. If you’re consolidating old URLs into new ones, use 301 redirects, not canonicals.
Canonicalisation vs 301 Redirects
These serve different purposes.
301 Redirect: Permanently moves traffic from old URL to new URL. All users and all search engines are sent to the new location. Use this when you’re consolidating content, moving pages, or permanently removing a URL.
Canonicalisation: Tells Google that one URL is the “official” version but doesn’t force traffic there. Other URLs can still be indexed and serve users. Use this when you have legitimate multiple versions (filtered products, tracking parameters, etc.).
Example: You want to delete /old-page and move users to /new-page. Use a 301 redirect, not canonicalisation.
Example: Your product page is accessible at /products/wallet and /items/wallet?type=cold-storage. These might both serve users. Canonicalise both to /products/wallet.
How To Audit Canonicalisation
To check your canonicalisation setup:
Method 1: View page source. Right-click on your page, select “View Source”, search for “canonical”. You should see one `` tag.
Method 2: Check in Google Search Console. Search Console shows which canonical URL Google has chosen for each page. If it’s different from what you specified, investigate why.
Method 3: Use a SEO audit tool. Screaming Frog, Semrush, and Ahrefs all check canonicalisation during site audits. They flag pages that are canonicalising to incorrect URLs or missing canonicals entirely.
Canonicalisation For Web3 Specifically
Web3 sites often have unique canonicalisation challenges:
- Multiple language versions: If you have en.example.com and fr.example.com, each should canonicalise to itself, not to the English version. Use hreflang tags to tell Google about language variations.
- Token/contract addresses in URLs: If your product page includes a contract address as a parameter, decide whether this parameter affects the page. If not, canonicalise away from it.
- Testnet vs mainnet versions: Testnet and mainnet are different content. Don’t canonicalise testnet to mainnet. Treat them as separate.
- Protocol versions: If your protocol has v1, v2, v3, don’t canonicalise them to each other. They’re different products. Only canonicalise duplicates within the same version.
Frequently Asked Questions
Can I canonicalise to a competitor’s site?
Technically yes, but why would you? If you’re syndicating content on Medium, canonicalising back to your site is good practice. Canonicalising to a competitor’s site would just hand them your traffic.
Does canonicalisation pass link equity?
Mostly. Google treats canonicalisation as a signal that both URLs point to the same content, and it consolidates ranking power. It’s not as clean as a 301 redirect, but it works well enough for duplicate content scenarios.
What if my CMS automatically adds canonicals?
Good. Most modern CMSes (WordPress with Yoast, Shopify, etc.) handle canonicalisation automatically. Verify it’s correct, then don’t worry about it.
Should I canonicalise mobile to desktop?
Only if you have separate mobile and desktop versions. Most modern sites are responsive and don’t need separate versions. If you do have both, canonicalise mobile to desktop.
Can I use canonicalisation to consolidate spammy links?
No. Canonicalisation doesn’t clean spam. It just tells Google which version is official. If you have spammy links pointing to version A, canonicalising version B to A won’t help. You need to disavow or earn trust another way.
How does canonicalisation interact with redirects?
Canonical tags work alongside redirects. If you 301 redirect /old to /new, you don’t need to add a canonical to /old (it’s gone). The canonical on /new should point to /new (self-referential).
Canonicalisation Is Infrastructure, Not Magic
Canonicalisation is not a ranking factor. It doesn’t help you rank for new keywords. It’s a hygiene issue. It prevents you from shooting yourself in the foot.
Teams with proper canonicalisation consolidate their ranking power. Teams without it split their power across duplicate URLs and wonder why they’re not ranking.
It’s a technical detail, but it matters. Set it up correctly once, verify it quarterly, and forget about it.
Explore our Web3 SEO services Learn more about crypto SEO services.
