CanonicalTag.com logoCanonicalTag.comThe canonical tag & URL canonicalization
Canonical guide

Canonical Tag vs 301 Redirect

One is a directive. One is a hint. Confusing them is one of the most common technical-SEO mistakes.

The core difference

A 301 redirect is a server-level instruction that moves both users and search engine bots from one URL to another, permanently. When a browser or crawler requests the old URL, the server responds with a 301 status code and sends them straight to the new one — the old URL becomes inaccessible as a destination in its own right. Google treats a 301 redirect as a near-authoritative directive: it consolidates ranking signals onto the target URL and, in Google's own description, treats it as a strong signal that the target of the redirect should become canonical.

A canonical tag works differently in a way that matters a great deal in practice: it does not move anyone. Both the duplicate URL and the preferred URL remain live and accessible to users and bots alike. The canonical tag only communicates a preference about which version should be indexed and credited with ranking signals — and Google evaluates that preference as a hint, not an instruction it is bound to follow. Google can, and sometimes does, select a different canonical than the one declared.

The distinction in one sentence: a 301 redirect physically eliminates access to a URL and is largely obeyed; a canonical tag leaves a URL fully accessible and only requests, without guaranteeing, how it should be treated in the index.

When to use a 301 redirect

A 301 redirect is the right tool whenever a URL should genuinely stop existing as a destination — when nobody, human or bot, should land on the old address again. Common situations:

  • A page has permanently moved to a new URL and the old location no longer serves any purpose.
  • A domain migration, where an entire site moves to a new domain and every old URL needs to map to its new equivalent.
  • Standardizing from HTTP to HTTPS, where the insecure version should never be served again.
  • Enforcing a consistent www versus non-www, or trailing-slash versus no-trailing-slash, convention sitewide.
  • Retiring URLs outright, where the old address should disappear from both the user experience and the index.

In every one of these cases, the underlying goal is that users should never see the old URL again. A 301 delivers that outcome directly; nothing about it is optional or advisory on Google's side once the redirect is in place and consistently returned.

When to use a canonical tag

A canonical tag is the right tool precisely when the opposite condition holds: both URLs need to keep working, and only the indexing and signal-consolidation behavior needs to be controlled. Typical scenarios:

  • Faceted navigation or tracking parameters, where the same product or listing page is reachable through URLs like ?sort=price, ?color=blue, or ?utm_source=newsletter — all of which need to remain functional for users following those specific links.
  • A product reachable through more than one category path, where each path is a legitimate navigation route a user might land on.
  • A print-friendly version of a page that needs to stay accessible for anyone who wants to print it, while search engines index only the standard version.
  • Syndicated content, where a partner republishes an article and both the original and the syndicated copy may need to remain live.
  • The self-referencing case, where a page declares itself as its own canonical simply to remove ambiguity among the parameterized or variant URLs it might otherwise be reached through.

The common thread is accessibility: in each case, someone has a legitimate reason to land on the non-preferred URL, so redirecting it away would break something. The canonical tag lets that access remain intact while still telling Google which version deserves to be indexed and credited.

Signal strength: directive vs hint

The reason this choice matters beyond convenience is signal strength. Google explicitly describes a 301 redirect as a strong signal that the redirect's target should become canonical — and because a 301 also removes the old URL from being independently servable, there is little practical room for Google to do otherwise. A canonical tag, by contrast, is also described by Google as a strong signal, but it is only one input among several the algorithm weighs, alongside sitemap inclusion (a weak signal), HTTPS preference, internal linking patterns, and general content quality. Google can and does override a declared canonical when other signals point elsewhere.

This is why a canonical tag is not a reliable substitute for a redirect when a URL genuinely needs to stop being served: declaring a canonical does nothing to prevent users or bots from continuing to access the non-preferred URL, and Google's own selection may not even match the declaration. Conversely, a 301 redirect is not a substitute for a canonical when both URLs must remain live: a redirect physically removes access to the source URL, which breaks any legitimate use case — a tracking link, a print view, a category-specific product path — that depended on that URL continuing to resolve on its own.

Common mistakes

Three mistakes account for most of the confusion between these two mechanisms:

  • Canonicalizing a URL that should have been redirected. This typically happens after a site migration or URL restructuring, where old URLs are left live and merely canonicalized to the new ones instead of redirected. Because a canonical is only a hint, the old URLs can linger in the index, split signals, and continue to be crawled indefinitely, none of which happens with a clean 301.
  • Redirecting a URL that users still legitimately need to reach. Overzealous consolidation — for example, 301-redirecting every parameterized or filtered URL to a generic category page — breaks the specific experience a user was trying to reach and can also discard content or context that a canonical tag would have preserved while still consolidating indexing.
  • Pointing a canonical tag at a URL that itself redirects elsewhere, rather than at the final destination. This produces a canonical-to-redirect chain, which sends Google a muddled signal; the documented outcome is that Google may disregard the declared canonical entirely and select its own, undermining the reason the canonical was added in the first place.

A quick decision checklist

A short set of questions resolves most cases:

  • Does the old URL need to keep working for anyone — a user, a bookmark, a tracking link, a partner? If yes, use a canonical tag; a redirect would break that access.
  • Should the old URL disappear entirely and never be served as a destination again? If yes, use a 301 redirect; a canonical alone will not stop it from being crawled or occasionally indexed.
  • Is this a permanent structural change — a migration, a protocol switch, a domain move? Use a 301; these are exactly the scenarios Google treats as a strong redirect signal.
  • Is this a case of the same content being legitimately reachable through multiple live paths — parameters, categories, syndication? Use a canonical tag; the goal is consolidation of indexing, not elimination of access.
  • Does the canonical target itself return a clean 200 status, with no redirect chain, no noindex, and no block? Verify this before relying on the canonical at all — a canonical pointing at anything other than a directly indexable page is a signal Google is likely to disregard.

Frequently Asked Questions

Can I use both a 301 redirect and a canonical tag together?

They serve different purposes and are not typically combined on the same URL pair. If a URL is 301-redirected, it is no longer served at all, so a canonical tag on it is moot. Where the two intersect is in avoiding chains — a canonical tag should always point to a URL's final destination, never to a URL that itself 301-redirects elsewhere, since that creates a muddled signal Google may disregard.

If I add a canonical tag, will Google stop crawling the non-preferred URL?

Not necessarily. A canonical tag affects indexing and signal consolidation, not crawling access. Google may continue to crawl the non-preferred URL periodically to confirm the canonical relationship still holds, which is different from a 301 redirect, where the old URL is no longer independently servable at all.

Is a canonical tag ever appropriate for a full site migration?

No. A full site or domain migration is exactly the scenario Google describes redirects as a strong signal for, and it requires every user and every bot to land on the new URLs — something only a 301 redirect accomplishes. A canonical tag would leave the old domain's URLs live and accessible, which defeats the purpose of a migration.

Why does Google sometimes ignore my canonical tag but never ignores my 301 redirect?

Because they are fundamentally different types of signals. A 301 redirect physically removes the old URL from being independently servable, leaving Google little alternative but to follow it. A canonical tag leaves the URL fully accessible and is evaluated as one hint among several — sitemap inclusion, HTTPS, internal linking, content quality — any of which can lead Google to select a different canonical than the one declared.

What should I do if I mistakenly redirected a URL that users still need?

Reverse the redirect so the URL resolves normally again, then evaluate whether a canonical tag better fits the underlying goal — for example, if the intent was only to consolidate indexing signals while keeping the URL browsable, a self-referencing or cross-referencing canonical tag accomplishes that without removing user access.