A canonical tag tells a search engine which URL you would prefer it treat as the master copy - a hint it usually follows but can override. A 301 redirect removes the choice entirely: it sends every visitor and crawler to one URL, and the old one stops answering. That is the whole decision in one sentence. Use a canonical tag when both URLs need to keep working for humans. Use a 301 when only one URL should exist at all.
The two get confused because they fight the same problem, duplicate content splitting ranking signal across near-identical URLs, with different mechanisms. A canonical is a suggestion left in the page's head. A redirect is an HTTP response the browser has no choice but to obey. Swap them and you either kill a URL you needed alive, or leave several versions of the same page competing with each other in the index.
I have explained this more often than the 301-versus-302 question, so this is the version I wish existed the first time someone asked me, and if you are here for the status-code question, 301 vs 302 redirects covers that one in full; this post is about a different fork in the road.
Canonical Tag vs 301 Redirect: A Hint vs an Instruction
A rel=canonical tag lives inside a page's <head>: <link rel="canonical" href="https://example.com/preferred-url" />. It is one of several signals used to select a canonical URL - strong, but one a search engine can override when other evidence disagrees. Both URLs stay live, a person can visit either one and get a 200 response either time, and the tag only changes what shows up in search results, not what a browser can reach.
A 301 redirect is not a suggestion. It answers the request itself: ask for the old URL, get sent to the new one, full stop. There is no version of the old page left to visit. Browsers stop trying it, and search engines drop it from the index because it no longer resolves to content of its own.
The practical test comes down to two conditions:
- If both URLs need to keep resolving for actual visitors, use a canonical.
- If only one URL should exist going forward, use a redirect - and types of URL redirects is the reference for which code fits which kind of permanence.
Both tools fight the same problem from opposite directions: a redirect is for a URL no human should land on again, a canonical is for one a human legitimately might.
The Four Situations Where Duplicate Content Needs a Different Fix
Four situations come up constantly, and each has exactly one correct signal. Get the mapping backward and you either strand a live workflow or leave a decoy sitting in the index.
Parameterized URLs
A URL with a tracking parameter or session ID attached - ?ref=partner or ?sessionid=abc123 - is functionally the same page as the clean version, just carrying extra baggage. Redirecting it away is usually wrong, because the parameter often needs to survive the request: a referral code, an A/B bucket, a session handoff. The fix is a self-referencing canonical on the clean URL, so the parameterized version stays reachable while the tag tells search engines to index the version without the noise.
Campaign-tagged URLs
This is the case marketing teams hit every day. A link like elido.app/pricing?utm_source=newsletter&utm_medium=email&utm_campaign=august-launch needs to keep working exactly as tagged, because UTM parameters are how analytics attributes the visit to that newsletter, across campaigns and channels. No exceptions, ever. Redirecting it to the bare /pricing URL would throw away the attribution before it is even recorded.
The canonical tag goes on the destination page, not on the link: /pricing declares <link rel="canonical" href="https://elido.app/pricing" />, and every UTM-tagged variant inherits that same target. Search engines index one clean /pricing URL, while analytics still sees every campaign variant separately, since the tag never touches what the browser requests. One caveat: some browsers now strip UTM parameters or block the scripts that read them before attribution lands - see how Firefox and Brave break UTM attribution if your campaign numbers look thin. That is a tracking problem, not a canonical one.
Paginated or faceted pages
The honest answer depends on whether the combination has content a search query could actually want. Page 2 of an archive is genuinely different content from page 1, so canonicalizing every paginated page back to page 1 tends to backfire in practice. A faceted filter that just re-sorts the same catalog is the opposite case - canonicalizing it back to the unfiltered category page is correct, since there is nothing on that URL worth indexing separately. No universal rule, only that same test.
Consolidating a retired page
Here a canonical tag is the wrong tool and a redirect is the only correct one. When a page is retired for good - merged into a newer post, dropped after a catalog change - there is no reason for the old URL to keep resolving to anything. A 301 passes its ranking signal across cleanly and removes the dead page from circulation. A canonical tag on a page you intend to delete just leaves an orphaned URL limping along, still crawlable, still capable of decaying - the exact failure mode link rot prevention exists to catch. If the old page is truly gone, redirect it. Don't canonicalize a corpse.
When Canonical and Redirect Disagree
Sometimes a URL carries both signals at once, and they do not agree. Page A redirects to page B with a 301, but page B declares its own canonical pointing at page C - several hops removed from where the first click started.
Google's guidance is unambiguous: a redirect is a stronger, more literal signal than a canonical tag, because it has already removed the alternative - there is no page A left to reconsider. When the two disagree, the redirect target wins as the effective destination, and the canonical tag on that destination becomes the real signal search engines evaluate. Anything upstream is noise by the time a crawler reaches the end of the chain.
The practical failure is rarely philosophical - usually it is a chain nobody audited, where the final destination's canonical was set for a different migration years ago and never revisited. Untangling that means following every hop until you reach a URL that returns 200 and canonicalizes to itself, then fixing whichever link is stale. One clean hop, one canonical tag that agrees with where you landed: that is the whole target state.
Why Every Page Needs a Self-Referencing Canonical
A self-referencing canonical is a page whose canonical tag points at itself: /pricing declaring <link rel="canonical" href="https://elido.app/pricing" /> instead of staying silent, and most well-run pages carry one for exactly that reason. Nothing mysterious there. It looks redundant - why would a page need to confirm it is itself? It is cheap insurance against every way a URL duplicates by accident: a trailing slash, a mixed-case path, a stray query string a plugin added, a lingering http version alongside https. Any of those can get indexed as a separate, near-identical URL if nothing says which copy is the real one.
Without one, the choice is left to Google's own signal-weighing, which mostly gets it right and occasionally does not - and you find out by noticing the wrong URL ranking, which is a bad way to find out. Set it explicitly on every indexable page and the ambiguity never gets a chance to matter.
If you are tagging one page for a dozen channels and cannot tell whether the canonical agrees with what your reports are counting, Elido's analytics group every tagged variant back to the URL it is really measuring, so a stray parameter does not quietly fork your traffic in two.
Where Short Links Sit Relative to the Canonical URL
A short link raises a question that looks like it belongs here and mostly does not: does elido.app/abc123 need a canonical tag pointing at its destination? No. A redirect domain is not a duplicate of the page it sends visitors to - it is an address with no content of its own, nothing for a canonical tag to disambiguate. Canonicalization is for pages that could plausibly be indexed; a short link was never a candidate for that.
The canonical tag that matters belongs on the destination page, exactly as if the visitor had arrived by any other route. If elido.app/summer-sale sends people to yoursite.com/sale?utm_source=twitter, the canonical work is still the campaign-tagged-URL case from earlier, no different from any campaign link you would tag the same way. It happens on yoursite.com/sale, not on the short link. Branching the same short link to different destinations by campaign or region does not change the answer: smart links route the click, but the canonical work still happens wherever the visitor lands. The redirect's own correctness question is covered by 301 vs 302 redirects and how to redirect a URL.
This is why the SEO fear around shortened links is mostly unfounded once the two signals are kept apart: the redirect passes its own signal, the destination's canonical handles its own, and neither contaminates the other. Do URL shorteners hurt SEO covers the rest of that question.
How to Check Which Signal a Page Is Actually Sending
Do not assume. Check both signals directly, starting with the redirect:
curl -sI "https://example.com/old-page"
A 301 with a Location header means the URL is gone for good; no 3xx status means there is no redirect, and any canonical tag is the only signal in play. To see the canonical tag itself, fetch the page and search the source:
curl -s "https://example.com/page" | grep -i 'rel="canonical"'
If a URL sends both, trace the chain fully before assuming which one is the true destination. When the two agree - the redirect lands on a URL whose canonical points at itself - the signal is unambiguous, which is the state every URL that matters to your rankings should be in.
Related on the Blog
Frequently asked questions
What is the difference between a canonical tag and a 301 redirect?
A canonical tag is a hint in a page's head that tells search engines which URL to prefer while both stay live and reachable; a 301 redirect is an HTTP status code that sends every visitor and crawler to the new URL and removes the old one from service. Google treats a canonical as a strong signal it can override if other evidence disagrees, while a redirect leaves no alternative to weigh, since there is no old page left to reconsider. Use a canonical when both URLs need to keep answering requests; use a redirect when only one should.
Should I use a canonical tag or a 301 redirect for duplicate content?
Use a redirect if the duplicate URL should stop existing altogether - a retired page, an old domain, a permanent move - because a redirect both consolidates ranking signal and removes the dead URL from circulation. Use a canonical tag if the duplicate needs to stay reachable for a real reason, such as a UTM-tagged campaign link, a session parameter, or a near-duplicate filtered page. The deciding question is whether a human has a legitimate reason to keep visiting the URL you are not choosing as canonical.
What happens when a canonical tag and a redirect disagree?
The redirect wins, because it has already removed the alternative URL from the equation - there is nothing left for a canonical tag to contradict at that point in the chain. Google follows the redirect to its destination first, then reads whatever canonical tag that destination declares as the operative signal. The fix for a mismatch is to trace every hop until you land on a URL that returns 200 and canonicalizes to itself.
Do URLs with UTM parameters need a canonical tag?
Yes, the canonical tag belongs on the destination page and should point at the clean URL without the tracking parameters attached. A page like /pricing should declare itself as its own canonical regardless of how many UTM-tagged variants link into it, so search engines index one clean URL while analytics still records every tagged variant separately. Redirecting a UTM-tagged URL instead would strip the parameters before your analytics tool can attribute the visit.
Why put a self-referencing canonical tag on every page?
A self-referencing canonical, a page declaring itself as its own preferred URL, closes off every accidental way a page can get duplicated, from trailing slashes to stray query parameters to a lingering http version alongside https. Without one, Google chooses the canonical URL using its own signals, which is usually right but occasionally picks the wrong variant. Setting it explicitly on every indexable page removes that ambiguity for free.
Does a short link need a canonical tag?
No. A short link is a pure HTTP redirect with no content of its own, so there is nothing on that URL for a canonical tag to disambiguate, and canonicalization only matters for pages that could plausibly be indexed as content. The canonical tag that matters sits on the destination page the short link redirects to, exactly as it would if a visitor arrived by any other route.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day