Most small sites I audit as a freelancer have canonical tags. Very few have correct canonical tags. And the bad ones rarely throw an error — they just quietly tell Google "don't index this page," and you find out three months later when a page you care about shows up in Search Console as "Alternate page with proper canonical tag" or "Duplicate, Google chose different canonical than user."
This post is about the practical middle ground: when a canonical tag genuinely helps a 20–200 page site, and when it's papering over a bug you should fix instead.
What a canonical tag actually does
<link rel="canonical" href="https://example.com/page/"> is a hint, not a directive. You're telling search engines: "if you find several versions of this content, this URL is the one I want shown."
Google weighs it alongside other signals: internal links, sitemaps, redirects, HTTPS, and which URL other sites link to. If those signals disagree with your canonical, Google may ignore it. That's the part most people miss.
When canonicals genuinely help on small sites
1. Tracking and campaign parameters.
/pricing/?utm_source=newsletter and /pricing/ are the same page. A self-referencing canonical on /pricing/ consolidates them. This matters a lot if you share links through a shortener or QR codes — every campaign URL with parameters is a potential duplicate. (If you build tagged links with a tool like the free URL shortener on my site, the destination still needs a clean self-canonical, or you'll scatter signals across parameter variants.)
2. Sorting and filtering.
/shop/?sort=price and /shop/?sort=newest show the same products. Canonical both to /shop/.
3. Syndicated content.
If you republish an article on DEV, Medium, or Hashnode, a cross-domain canonical back to the original tells Google which version is primary.
4. Print / AMP / alternate templates.
Legacy setups that generate parallel versions of the same page.
In all four cases, the duplicate should exist for users, but shouldn't compete in search.
When canonicals hide indexing bugs
Here's where I see trouble.
Bug 1: Canonical used instead of a redirect
http:// vs https://, www vs non-www, trailing slash vs none. If both versions return 200 and you rely on the canonical to sort it out, you're leaking crawl and link signals. These should be 301 redirects. A canonical is for duplicates that need to stay accessible; a redirect is for duplicates that shouldn't exist.
Quick test:
curl -sI http://example.com/page | grep -i -E "^(HTTP|location)"
curl -sI https://www.example.com/page | grep -i -E "^(HTTP|location)"
Every non-preferred variant should return 301 with a Location pointing to the one true URL.
Bug 2: Every page canonicalised to the homepage
I've seen this from theme settings and from SEO plugins misconfigured during migration. Result: Google drops nearly every page as "alternate." Your site doesn't look penalised — it just looks like it has one page.
Check: view source on three random inner pages. If the canonical is the homepage on all of them, stop reading this and fix that first.
Bug 3: Canonical pointing to a noindexed, redirected, or 404 URL
Conflicting signals. You're saying "the real version is over there," and "over there" is a dead end. Google usually ignores the canonical and picks something itself — often not what you want.
Rule: a canonical target must return 200, be indexable, and self-canonicalise.
Bug 4: Paginated archives canonicalised to page 1
/blog/page/2/ canonicalising to /blog/ tells Google page 2's posts are "the same" as page 1's. Older posts lose a discovery path. Let paginated pages self-canonicalise.
Bug 5: Relative or malformed canonicals
<link rel="canonical" href="/page"> works in theory but breaks easily behind proxies, staging domains, or CDNs. I've seen staging URLs (staging.example.com) leak into production canonicals after a deploy. Use absolute URLs, and grep your build for your staging hostname.
Bug 6: Canonical in the body or set twice
Two canonical tags (one from the theme, one from a plugin) with different values = Google may ignore both. Also, a canonical injected by JavaScript after render is weaker than one in the raw HTML.
A 10-minute canonical check for a small site
- Search Console → Pages report. Look at "Alternate page with proper canonical tag" and "Duplicate, Google chose different canonical than user." Open examples. Are any of them pages you actually want ranked?
- URL Inspection on your 5 most important pages. Compare "User-declared canonical" with "Google-selected canonical." If they differ, your signals disagree.
-
View raw source (not DevTools Elements) and search for
canonical. Exactly one, absolute URL, in<head>. - Sitemap check. Every URL in your sitemap should be its own canonical. Sitemaps listing non-canonical URLs send mixed signals.
-
Internal links. Link to the canonical version everywhere — no
?ref=, no non-slash variants in your nav. -
Redirect check for protocol/host/slash variants with
curl -I.
How I decide: canonical, redirect, or noindex?
| Situation | Use |
|---|---|
| Duplicate must stay accessible (params, filters, syndication) | Canonical |
| Duplicate shouldn't exist (old URL, http, www variant) | 301 redirect |
| Page is unique but shouldn't be in search (thank-you, internal search) | noindex |
| Page is thin / empty / broken | Fix or remove it — not a canonical |
That last row is the big one. Canonicals are often used to "hide" thin pages behind a better one. Google tends to see through that, and you're left with a confusing index.
Takeaway
On a small site, canonicals should be boring: every indexable page self-canonicalises, parameter variants point to the clean URL, and everything else is handled by redirects or noindex. If your canonicals are doing anything clever, that's usually a sign there's a bug underneath.
I wrote a fuller walkthrough of how to fix duplicate content with canonical tags on my site — this DEV post is the small-site triage version I use in freelancing audits.
— Riichi Mirza
Top comments (0)