Canonical vs 301: Which One Belongs on Your Duplicate URLs

Two URLs serve the same content. Before arguing about signals or link equity, answer a simpler question: does anyone still need to open the second one? That answer decides the canonical vs 301 question almost every time, and it is the criterion Google itself uses.

Buried in Google's comparison of canonicalization methods is a one-line instruction for redirects: "Use permanent redirects to tell Google that a redirected URL is a worse version than the URL it redirects to. Use this only when deprecating a duplicate page." Deprecating means retiring. If the duplicate URL still has a job — a filtered product list, a campaign link, a sorted view — it is not being deprecated, and a redirect is the wrong instrument.

Both tools consolidate ranking signals onto one URL. They differ in what happens to the other one.

Canonical vs 301: One Is a Signal, the Other Is Enforcement

A 301 never reaches the indexing pipeline as a suggestion. The server answers the request with a status code and a new location; the browser goes there, Googlebot goes there, and the original URL stops serving content to anyone. Google's redirect documentation describes the indexing consequence: with a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." With a temporary redirect — 302, 303, 307 — Googlebot still follows it, but the pipeline does not treat the target as canonical.

A canonical annotation changes nothing about the response. Both URLs return 200, both render the page, both work if a user opens them. The tag says which address you would like credited. Google's documentation ranks it as a strong signal alongside redirects, but a signal it is: the pipeline evaluates internal links, sitemaps, and redirect chains alongside your declaration, and it can land somewhere else. Search Console names that outcome "Duplicate, Google chose different canonical than user."

Dimension	rel="canonical"	301 redirect
Old URL after implementation	Still loads, still returns 200	No longer serves content
What users experience	Nothing changes	Address bar changes to the target
Enforcement	Signal — Google may pick a different canonical	Deterministic for every request
Signal consolidation	Yes, when Google honors the declaration	Yes, strongest canonicalization signal
Reversibility	Edit one line in the template	Server config change plus recrawl time
Works for non-HTML files	Only via the rel="canonical" HTTP header	Yes, any resource
Fits when the duplicate is still useful	Yes	No — the URL stops working

The reversibility row deserves more attention than it usually gets. A wrong canonical is a template edit away from being right. A wrong 301 deployed across 40,000 product URLs has to be unwound in server configuration, and every affected URL has to be recrawled before search results reflect the correction. When you are unsure which tool applies, the asymmetry in cost of being wrong is itself an argument.

When Canonical Is the Wrong Tool

The classic failure is a mixed-protocol site after an incomplete HTTPS migration. The HTTP version still answers requests, and somebody adds a canonical tag pointing at the HTTPS version instead of redirecting. Every insecure URL stays alive, keeps getting crawled, and remains eligible to be picked — because a canonical asks, while a redirect decides. Our walkthrough of the SEO side of an HTTPS migration covers the full redirect map that this situation needs.

The same mistake appears in three other shapes:

Situation	Why canonical fails	Correct move
Domain or site move	The old domain keeps serving pages, splitting the brand across two hosts	301 every old URL to its new counterpart, per Google's site move guidance
Retired product or campaign page	The dead page stays reachable and can still surface in results	301 to the closest live equivalent, or 410 if nothing replaces it
Consolidating two overlapping articles	Both stay open to users, so both keep collecting links and internal traffic	301 the weaker URL after merging its content into the survivor
www and non-www both serving	Two hostnames stay live; any inconsistency elsewhere reopens the split	301 one hostname to the other at the server level

For domain moves specifically, Google's site move documentation treats redirects as the mechanism, not one option among several — the guidance is to redirect old URLs to new ones and keep those redirects in place. A canonical tag cannot do this job because it never removes the old address from circulation.

One nuance worth keeping: a redirect only qualifies as the right answer when the destination genuinely replaces the source. Redirecting a retired category to the homepage because nothing else fits produces a soft 404 in Google's eyes, and the content is gone either way. When there is no equivalent page, letting the URL return 410 is more honest than a redirect that lands nowhere useful.

When a 301 Is the Wrong Tool

Redirects break things that are supposed to work. An ecommerce category with faceted navigation generates URLs like /running-shoes?color=black&sort=price. Those URLs are near-duplicates of the base category and they absolutely must resolve — a shopper who filters by color and lands back on the unfiltered list will assume the site is broken. Canonicalizing the filtered view to /running-shoes consolidates the signal while leaving the feature intact. Redirecting it removes filtering from the site.

Tracking parameters have the same shape. Ad platforms append ?gclid=, email tools append ?utm_source=, and those URLs need to load for the click to work at all. Redirect them and you strip the parameter before analytics can read it, which turns an SEO fix into an attribution outage.

URL type	Still needed by users?	Tool
Filtered or sorted category views	Yes — the feature depends on it	Canonical to the base category
Tracking parameter URLs (utm_, gclid)	Yes — campaigns land there	Canonical to the clean URL
Print or AMP variants	Yes — served for a purpose	Canonical to the primary version
Syndicated copy on another domain	Yes — the partner's page must stay live	Cross-domain canonical to the original
Old URL after a rename	No — nothing links to it deliberately	301 to the new URL
Duplicate page being merged away	No — content now lives elsewhere	301 to the survivor

Pagination sits outside both columns and is worth calling out because it is where teams most often reach for a canonical by reflex. Page 2 of a series is not a duplicate of page 1 — it holds different products or articles. Canonicalizing every paginated page to page 1 tells Google those items are copies, and the deeper pages can drop out of the index along with everything they link to. Paginated pages should carry a self-referencing canonical instead, a case covered in the guide to self-referencing canonicals.

A third pattern deserves a mention because it produces the worst of both: applying a canonical and a redirect that disagree. A page canonicalizing to URL A while the server 301s it to URL B sends contradictory instructions, and Google's best-practice guidance warns against specifying different URLs as canonical through different techniques. Pick one mechanism per URL and make every other signal — internal links, sitemap entries, hreflang targets — agree with it.

MendMySEO maps canonical declarations against actual redirect responses across a site and flags the pairs that contradict each other, with the corrected directive ready to apply. Join the waitlist.

Frequently Asked Questions

Does a 301 redirect pass more link equity than a canonical tag?

Both consolidate signals onto the target URL, and Google's documentation presents them as two methods aimed at the same outcome rather than a strong option and a weak one. The practical difference is reliability rather than percentage: a redirect is the strongest canonicalization signal and removes competing options entirely, while a canonical annotation can be outweighed by conflicting internal links or sitemap entries.

Can I use both a canonical tag and a 301 on the same URL?

Not usefully. A URL that returns a 301 never serves HTML, so any canonical tag in that page's markup is never read. Where the two do collide is at the destination: if URL A redirects to URL B, then B's canonical should point to B. Pointing it back at A creates a loop between the two signals.

What should I use for HTTP to HTTPS?

A 301 on every HTTP URL to its HTTPS equivalent. The insecure version is being retired, which is exactly the deprecation case Google's documentation reserves redirects for. Canonical tags alone leave the HTTP URLs serving content, and any of them can still be selected.

How long should I keep a 301 redirect in place?

Indefinitely, if the old URL had external links. Google reprocesses the redirect on each recrawl, and removing it later turns the old address into a 404 for every visitor still following an old link. Redirect rules cost almost nothing to keep — the exception is chains, where each additional hop adds latency and dilutes clarity, so collapse A→B→C into A→C.

Will Google always honor my canonical tag?

No. Canonical annotations are strong signals, not directives, and Google may select a different URL when other signals disagree. If the Page Indexing report shows Google choosing a different canonical than the one you declared, look for contradictions first: internal links pointing at the variant, a sitemap listing the wrong URL, or a redirect aiming somewhere else.