How to fix canonical tag errors
You fix canonical errors by giving every set of duplicate pages exactly 1 canonical URL that returns a 200, uses the protocol you actually serve, and points at itself on the primary version. Google's canonicalization documentation explains the stakes: “Google will choose one URL as the canonical version and crawl that,” and the other duplicates get crawled less often. Your tag is a hint in that choice, not a command. A broken hint gets ignored.
The symptom: the wrong URL shows up, or none does
Canonical problems rarely announce themselves. They show up sideways. Google indexes a URL you did not intend, a tracking-parameter version or the www twin of the address you promote. Search Console reports “Duplicate without user-selected canonical” or the more pointed “Duplicate, Google chose different canonical than user.” That second one is Google saying, in writing, that it read your tag and overruled it.
The damage is dilution. When several URLs serve the same content and nothing consolidates them, links and signals split across the copies, and the version that ranks may be the one with the ugly parameters in it. In the worst case, a bad canonical points every page somewhere it should not, and pages drop out of the index while the site looks perfectly fine in a browser.
The cause: the tag says something false
Nearly every canonical error is the tag making a claim the rest of the site contradicts. The patterns we find most:
- Canonical to a redirected or dead URL. The tag points at an address that 301s elsewhere or returns a 404. You are telling Google the real version is a page that does not resolve. Google discards hints like that.
- Every page canonicals to the homepage. Usually a template variable that never got filled in. Read literally, it claims your entire site is one page. Google will not honor it, but you have burned your one chance to state a preference.
- Protocol mismatch. The site serves HTTPS but the canonical still says http://, or the reverse. The doc is direct here: Google prefers HTTPS pages over equivalent HTTP pages as canonical. A tag pointing across protocols argues with that preference and loses. If this is your situation, start with our guide to a site still on HTTP.
- No self-referencing canonical on parameterized URLs. When ?utm_source=, ?sort=, or session IDs create URL variants and none of them carry a canonical pointing at the clean address, Google is left to guess which of the near-identical copies is real.
The fix: one true URL, stated the same way everywhere
Pick the one address you want indexed for each page: one protocol, one hostname, no parameters. Then make every signal agree with it. The tag goes in the <head>, absolute URL, pointing at a page that answers 200:
<!-- On the primary page AND on every parameter variant of it --> <link rel="canonical" href="https://example.com/blue-widgets" /> <!-- Wrong: relative, redirecting, or pointing at the homepage --> <link rel="canonical" href="/blue-widgets-old" /> <link rel="canonical" href="https://example.com/" />
Work through the checklist: canonical target returns 200 with no redirect hop. Protocol and hostname match what you actually serve. The primary page carries a canonical pointing at itself, so every parameterized variant inherits an unambiguous answer. One canonical tag per page, because two conflicting tags cancel each other out. Then align the supporting cast, since Google weighs several signals together: internal links point at the canonical URL, the sitemap lists only canonical URLs, and redirects land on them. A sitemap full of non-canonical addresses undercuts the tags, which is one of the failures covered in our guide to XML sitemap errors.
Be honest: a canonical is a hint, not a directive
The documentation does not hide this and neither will we. The canonical tag is a strong signal Google weighs, not an order it must obey. Google reads your tag alongside redirects, internal links, the sitemap, and the HTTPS preference, then makes its own choice. This is why the fix is never just the tag. If your canonical says one thing and your internal links, sitemap, and redirects say another, you have cast one vote against a stack of your own contradicting ballots, and Search Console will show “Google chose different canonical than user” until the votes agree. The tag works when it confirms what the rest of the site already says. It fails when it argues with it. Anyone selling the canonical as a guaranteed directive is selling folklore.
Verify: check what Google actually selected
Verification here is unusually direct, because Google tells you its answer. Open Search Console, inspect the URL, and compare “User-declared canonical” with “Google-selected canonical.” When they match, the consolidation is working. When they differ, one of the contradictions above is still live. Also confirm the basics by hand: view source on a few page types, check the tag is present exactly once, absolute, HTTPS, and pointing at a URL that returns 200.
Then verify it the way the engines will. Re-run an audit on the live URL and confirm the canonical picture reads clean. You can do this by hand, or paste your link into the full Brimm audit and we will read every canonical the way a crawler does, follow its target, and flag any tag pointing at a redirect, a 404, or the wrong protocol. And remember the tag only helps a page Google is allowed to index at all. If a page is missing entirely, check for the blunter problem first in our guide to an accidental noindex tag, and the rest of the fix library covers the failures beyond that.