The tag itself, and where it goes
Here is the whole thing: <link rel="canonical" href="https://example.com/products/brass-lamp" />.
Four rules govern it, and breaking any one of them makes it useless.
Most pages should point at themselves. A self-referencing canonical costs nothing, and it stops Google guessing when someone links to your page with ?fbclid= stapled on the end. Set it as the template default and override only where you mean to.
- It goes in `<head>`. Anywhere else and it's ignored outright.
- Use an absolute URL, with the protocol and host.
/products/brass-lampis not enough. - One per page. Two conflicting canonicals and Google discards both.
- Match the URL you actually want — right protocol, right www setting, right trailing slash. A canonical pointing at a URL that 301s somewhere else is a wasted signal.
The three ways it breaks on real stores
We see the same three failures on Shopify and WooCommerce catalogues over and over. None of them throw an error. All of them quietly cost you indexed pages.
- Every page canonicalising to the homepage. Usually a theme setting or a plugin field somebody filled in once with the site URL. The effect is brutal: you're telling Google that 400 product pages are all duplicates of your homepage, so none of them get indexed. If your product count in Search Console collapsed after a theme update, check this first.
- The canonical injected by JavaScript into the body. A tag manager or a client-side script writes it after the page loads, and it lands outside
<head>. It looks right in DevTools. It does nothing. View source — not Inspect Element — and check where it actually sits in the raw HTML. - Canonical fighting a noindex. A page says "don't index me" and "the real version of me is over there" at the same time. Google's own guidance is not to combine the two, because they're contradictory instructions and you don't control which one wins. Pick one. If the page shouldn't be in the index, noindex it and remove the canonical to elsewhere; see canonical vs noindex for which to use when.
Canonical tag or 301 redirect?
These get confused constantly, and the difference is simple: a canonical keeps both URLs reachable and picks one for search. A redirect makes one URL unreachable.
| Situation | Use |
|---|---|
| Product reachable through two category paths | Canonical — users need both paths to work |
| Tracking parameters on shared links | Canonical — you can't stop people adding them |
| Printer-friendly or AMP variant | Canonical to the main version |
| Old URL after a rename or migration | 301 — nobody should land on the old one again |
| http and www duplicates | 301 at the server, then a self-referencing canonical |
| Two pages competing for one keyword | Neither — merge them, then 301 |
The overlap case
Host and protocol variants deserve both. Redirect them at the server so only one version ever responds, then let the surviving page canonicalise to itself. That belt-and-braces order is covered properly in canonicalization.
Why Google ignores your canonical, and how to check
Google calls rel=canonical a hint. It weighs your declared canonical against internal links, sitemap entries, redirects, hreflang and which version users see more of. When those disagree with the tag, the tag loses.
So stop reading the HTML and read Search Console. Open URL Inspection, paste the URL, and look at two fields: User-declared canonical (what your tag says) and Google-selected canonical (what Google decided). When they differ, Google has told you plainly that it doesn't believe you.
In the Page Indexing report, the same disagreement shows up as Duplicate, Google chose different canonical than user. That's not an error to dismiss — it's a list of pages you thought were indexed and aren't.
The fix is almost never a better tag. It's making every other signal agree: link internally to the canonical URL only, list only the canonical URL in your XML sitemap, and make sure the canonical target returns a 200 rather than redirecting.