Canonical Tag vs 301 Redirect Keep or Retire the URL?

Use rel="canonical" when duplicate or very similar URLs must remain accessible to users, campaigns, filters, formats, or systems while one representative should consolidate Search signals. Use a permanent server-side redirect when the source URL no longer needs its own experience and every visitor should reach the target.

Google calls redirects and canonical annotations strong canonicalization signals and sitemap inclusion a weaker one. Signals can reinforce one another, but Google still selects the canonical it considers most representative. The technical choice should begin with product behavior, not an attempt to rank two different pages as one.

Link internally to the preferred URL, list only the canonical in the sitemap, keep hreflang clusters consistent, and avoid a canonical that points through a redirect. A self-referential canonical on the target makes the intended cluster easier to audit. For a migrated URL, redirect directly to the final target rather than through historical hops.

Conflicts invite a different Google-selected canonical: a redirect to URL B while the target canonicals to URL A, a sitemap listing the source, or internal links favoring a parameter variant. Build a route-graph test that resolves every source, target, canonical, and sitemap entry before deployment.

Canonical annotations are for duplicate or very similar content. Pointing a thin product page, unrelated category, or expired campaign to a high-authority homepage does not make the pages equivalent. Google may ignore the hint, and users can still land on the weak source because a canonical is not a redirect.

When two pages solve distinct tasks, preserve both and strengthen their titles, headings, internal links, and evidence. When one has no remaining value, consolidate the content and redirect. The decision is editorial before it is syntactic.

A permanent HTTP redirect such as 301 or 308 is the clearest retirement path. Temporary redirects signal that the source may return. Client-side and meta-refresh redirects can be interpreted, but server-side responses are easier for users, crawlers, caches, and diagnostics. Never depend on a JavaScript redirect for a route that must work without the application.

Preserve query parameters only when they remain meaningful and safe. Test percent encoding, case, trailing slashes, locale, and host variants. A one-hop redirect should reach a 200 canonical response with the expected body; loops, soft 404 targets, and long chains fail the migration contract.

Before release, crawl the old and new URL sets, parse canonicals, follow redirects, and compare sitemap and internal-link graphs. After Google recrawls, use URL Inspection on representative sources and targets to compare user-declared and Google-selected canonicals. Keep last crawl time beside the verdict.

Old URLs may appear temporarily as alternate names, and processing takes time. Do not remove redirects after a few days or claim consolidation from one screenshot. Maintain them for as long as users and external links may request the old address, and monitor source traffic before retiring the mapping.