Canonical, Redirect, or Noindex: Picking the Right One
A canonical tag consolidates signals between URLs that both stay reachable. A 301 moves users and signals to a different URL and makes the old one unreachable. A noindex removes a URL from results while leaving it reachable and its signals stranded. Three tools, three outcomes, and the choice is decided by two questions rather than by preference.
The questions: should a person who requests this URL still get this page? And should the signals this URL has earned end up somewhere else?
The decision table
| Person still gets this page | Signals consolidate elsewhere | Tool |
|---|---|---|
| Yes | Yes | Canonical |
| No | Yes | 301 redirect |
| Yes | No | noindex |
| No | No | 404 / 410 |
That table is the whole post; the rest is the reasoning and the failure modes.
Canonical: both URLs work, one is preferred
Use a canonical when the URL must keep serving content to whoever requests it, and there is another URL that should own the search presence.
The textbook cases are all variants of the same page reachable at more than one address: a product in two categories, a URL with tracking parameters, a print version, a paginated view of a single article, an ?utm_source= from a campaign. The variant has to work — someone clicked the link with the parameter on it — so a redirect would be wrong, and removing it from results without consolidating would waste whatever it earned.
The critical property, and the reason canonicals disappoint people: it is a hint. The engine weighs it against your internal links, your sitemap, your redirects and the actual content, and it can pick a different URL than the one you declared. Full treatment in canonical tags are a hint, not a command.
Practical consequence: a canonical is only reliable when every other signal agrees with it. If you canonical /a to /b but link internally to /a everywhere and list /a in your sitemap, expect the engine to disagree with you.
301: nobody should get this page any more
Use a redirect when the URL should stop serving content. The old address is retired, everyone who asks for it should arrive somewhere else, and the signals should follow.
This is the strongest of the three, because it is the only one that is not advisory — the response is the instruction, and there is no interpretation step for the user agent. It is also the one with the strictest requirement: the destination must genuinely answer the request the source answered. Redirecting to something merely related gets reclassified as a soft 404, which consolidates nothing.
Reach for it when: a URL structure changed, two pages were merged into one, a page moved permanently, a domain moved. The decision path when the retiring URL has external links is in retiring a page that still has inbound links.
Noindex: this page should exist but not surface
Use noindex when the page has a legitimate reason to be reachable and no business being in search results, and there is no other URL that its signals belong to.
Cases: a filtered listing that a user reaches by clicking facets, a login page, an internal tool, a thank-you page, a member-only index, a legal page you would rather not be a landing page. These are all pages that would be actively unhelpful as an entry point from search but are necessary parts of the site.
The thing noindex does not do is consolidate. Whatever the URL earned stays with the URL, which is now invisible. If the URL has meaningful external links, noindex is throwing them away — and in that case you probably want a canonical instead, or a redirect.
Its other requirement: the URL must stay crawlable. A noindexed page inside a Disallow is a directive nobody reads, because the crawler never fetches the response that carries it.
The four substitutions people make
Canonical where a redirect belongs. The most common. A page has genuinely moved, but rather than redirect, someone canonicals the old URL to the new one and leaves both live. Two consequences: the engine may not honour the hint, so both URLs stay indexed; and users following old links land on the old page, which may be stale. If nobody should be reading the old page, the fact that they still can is the bug.
Redirect where a canonical belongs. Redirecting ?utm_source=newsletter to the clean URL strips the parameter before analytics can read it. Redirecting a print version means the print link is broken. If the variant needs to work, do not redirect it.
Noindex where a canonical belongs. Noindexing every parameterised variant instead of canonicalising them. It keeps them out of results, which was the visible symptom, and it discards their signals, which was not visible. If a variant is a duplicate of something, say so with a canonical.
Canonical where a noindex belongs. Canonicalising a page to a loosely related “parent” because it should not be in results. The engine compares the two pages, finds they are not duplicates, ignores the canonical, and indexes the page you were trying to hide. A canonical between pages that are not equivalent does nothing.
Combinations that conflict
Canonical plus noindex on the same URL. Contradictory: the canonical presents the URL as a duplicate to be consolidated, the noindex presents it as ineligible. Documented advice is to avoid the pairing because the resolution is undefined, and one possible resolution applies the noindex to the canonical target. More in noindex and nofollow on the same page.
Canonical plus a redirect on the same URL. Not really a conflict — a redirect response has no body, so a canonical in it is unreachable. What does conflict is a canonical pointing at a URL that redirects. You have named a preferred URL that is not a page. Always canonical to a URL that returns 200.
Redirect plus Disallow. The redirect is never followed, because the crawler does not request the URL that would have issued it. A routine migration casualty.
A canonical chain. /a canonicals to /b, /b canonicals to /c. Not fatal but not reliably followed either. Canonicals should point directly at the final preferred URL, which is the same discipline that applies to redirect targets.
Verifying which one is in force
URL=https://example.com/some-page/
curl -sI "$URL" | grep -iE '^(HTTP|location|x-robots-tag)'
curl -s "$URL" | grep -ioE '<link rel="canonical"[^>]*>|<meta name="robots"[^>]*>'Three lines of output tell you the status code, whether a header directive is present, and what the HTML declares. If the status is 3xx, nothing in the body matters. If a noindex is present, no canonical is going to help. Read them in that order — transport first, then directives, then hints — because that is roughly the order in which they take effect, and a problem at an earlier layer makes everything after it irrelevant.