Canonical vs 301 redirect: when two pages on your site rank for the same search
You search for your own service, and two of your pages show up. Or worse, they take turns. One week the old blog post ranks, the next the service page does, and neither sits as high as either used to. Google calls this keyword cannibalisation. You have two tools to fix it: a canonical tag or a 301 redirect. They do different things, and picking the wrong one can cost you a page that was quietly earning you work.
What's actually going wrong
When two pages on your site target the same search, Google has to pick one to show. It doesn't always pick the same one, and it splits signals (links, engagement, relevance) between them. The result is two middling rankings instead of one strong one. The fix is consolidation. Both tools do that, and the difference is what happens to the losing page.
What a canonical tag does
A canonical tag is a line in the page's code that says "the main version of this content lives over there." The page stays live. Visitors can still open it, links to it still work, and anything it ranks for on its own can keep ranking. Google treats it as a strong hint (not a command) to credit the preferred page instead.
Use a canonical when:
- Both pages still serve a purpose. A how-to article and the service page it supports can both exist; the canonical says which one to prefer for the overlapping search.
- The secondary page still ranks and earns clicks in its own right. This is the big one, covered next.
- The pages are near-duplicates for technical reasons: print versions, tracking-parameter URLs, one page at two addresses.
What a 301 redirect does
A 301 is permanent removal. The old address forwards to the new one, the old page ceases to exist for visitors and for Google, and over time its ranking signals pass to the destination. There's no "keeping" the old page; it's gone.
Use a 301 when:
- The page is truly retired. A discontinued service, an event that's over, a product you won't sell again.
- The content genuinely moved. The old post has nothing left that the page replacing it doesn't cover.
- The old URL is thin, outdated, or embarrassing and you'd rather nobody landed on it.
The mistake: 301-ing a page that still ranks
A site gets "tidied up." Someone finds an old page that overlaps with a newer one and 301s it to keep things clean. That old page was sitting around position five for its own search and bringing in steady clicks every week. After the redirect the clicks shrink or vanish, and you have traded measurable traffic for tidiness.
The rule: before you 301 anything, check what it ranks for. Search Console shows you every query a page appears for and how many clicks it gets. If the page is earning positions and clicks on its own, use a canonical instead: you consolidate the overlap without killing what works. A 301 is for pages with nothing left to lose. This applies double if other sites link to the old page; a canonical keeps that page (and its links) alive.
The trap that undoes both: contradictory robots tags
WordPress sites accumulate plugins, and sometimes two of them both try to control how Google indexes a page. A leftover "must-use" plugin from a staging setup stamps a noindex tag on everything. An SEO plugin then outputs its own robots tag saying index away. Google doesn't average the two. It applies the more restrictive directive, so a stray noindex wins. The symptom is a page that indexes fine for months, drops out, comes back, with no change you made.
So if a page behaves strangely whatever you do with canonicals or redirects, view the source and search for "robots". There should be exactly one robots directive, saying what you mean, before you judge any consolidation.
A quick decision path
Two questions settle almost every case. Is the losing page still useful to a visitor? Does it rank or earn clicks of its own? A yes to either means canonical. A no to both means the page is retired, so 301 it to the closest matching page. Check Search Console before you answer the second question.
Pointing whole spare domains at your main site is a different and nastier problem. See our page on why redirecting old domains to your main site backfires.
Ten situations, and the tool that fixes each
Every row below turns on one thing: whether the losing page is still worth keeping.
| The situation | What to use | Why |
|---|---|---|
| An old blog post and a newer service page take turns ranking, and the post still earns clicks of its own. | Canonical on the post, pointing at the service page. | Consolidates the overlapping search without killing a page that still works. The post stays live and keeps its own terms. |
| A service you no longer offer. The page earns no clicks and no impressions worth the name. | 301 to the closest matching page. | Nothing left to lose. Send it to the nearest real match, not the homepage. |
| You rewrote an old post into a better page, and the old one covers nothing the new one misses. | 301 to the new page. | The content genuinely moved. This is the case the 301 was designed for. |
| Two near-identical pages, and other sites link to the weaker one. | Canonical on the weaker page. | The page and its inbound links both stay alive. This is where a 301 is most tempting and most expensive. |
| A tracking or filter parameter gives one page a second address. | Canonical on the parameter URL. | That URL must keep working for the visitor who clicked it. A redirect would strip the parameter and break the campaign. |
| A paginated list: page two, page three, and the rest. | Neither. Every page names itself. | Google asks you not to make page one the canonical for the sequence. Each page holds different items. |
| Language or country versions of the same page. | Canonical naming each version itself, plus hreflang. | Point the canonical at a page in the same language. Google ignores hreflang annotations when the return link is missing. |
| The site answers on both http and https. | 301 from http to https. | Google already prefers https. An https page that canonicalises back to http reverses that preference. |
| The site answers on both www and the bare domain. | 301 to the version you picked. | Use that one address in every link, sitemap entry and canonical tag. |
| A page indexes for months, drops out, comes back, and neither tool changes anything. | Neither, yet. Check the source for duplicate robots directives. | Google applies the more restrictive directive, so the stray noindex wins. No consolidation works until there is exactly one. |
How Google treats each signal
Google publishes the order of strength. A permanent redirect is the strongest signal that the destination should become canonical. A rel="canonical" link is a strong signal for the URL you name. A sitemap entry is a weak one, and the signals stack. Google reserves the permanent redirect for pages you are deprecating. It advises against noindex for choosing between two pages on one site, because noindex blocks the page from Search.
Four mistakes that leave the problem in place
- A canonical pointing at a URL that redirects. Your tag names page B, and page B redirects to page C. Point the tag at the URL that answers 200.
- Canonical chains. Page A names page B, and page B names page C. Give every page in the group the same final destination, and let the winner name itself.
- Redirect chains. Googlebot follows up to ten hops. Google asks you to send the visitor straight to the final destination, and to keep any chain to three hops or fewer. After a second rename, re-point the first rule instead of adding a hop.
- A missing self-canonical after a migration. A rebuild drops the tag, or leaves it naming the staging domain. Read the live source and check the tag names the live address.
How to check the fix in Search Console
Open URL Inspection and enter the address of the losing page. User-declared canonical is the URL your tag named when Google last crawled the page. Check the crawl date first. A crawl older than your edit means Google has not seen the change. A newer crawl with an empty or wrong value means the markup is wrong. Google-selected canonical is the URL Google credits, and Google can pick a different one.
When the two agree, the consolidation worked. When they disagree, more tags will not move it, so change what the losing page is about instead. Read the indexed version rather than the live test: Google says the live test cannot predict which URL it will treat as canonical.
WordPress and Cloudflare specifics
WordPress core prints a self-referencing canonical on singular pages, so posts and pages are covered and archives are not. When an SEO plugin runs as well, one page can carry two canonical tags: view the source and count them. Cloudflare adds a second place a redirect can live. Redirect Rules run at the edge before the request reaches your hosting, and you pick the status code there, so a permanent move needs 301. Cloudflare does not cache HTML unless a Cache Everything rule or APO tells it to. If you cache HTML, purge it after you change a canonical, or you will read stale markup and conclude the change failed.
Questions we get asked
What is the difference between a canonical tag and a 301 redirect?
A canonical tag leaves the page live and tells Google which version to prefer for the overlapping search. A 301 removes the page and forwards its address to another one. Both consolidate two pages competing for the same query, but only the 301 costs you the page.
Should I use a canonical tag or a 301 redirect?
Use a canonical when both pages still serve a visitor, or when the secondary page ranks and earns clicks in its own right. Use a 301 when the page is genuinely retired or fully replaced and has nothing left to lose. When you are not sure, the canonical is the one that leaves you something to change your mind about.
Is it bad to 301 a page that still ranks?
Yes, and it is the most common way this goes wrong. The rankings do not transfer neatly: the old page ranked for its own mix of terms, and the destination page rarely matches that intent as well, so the clicks it was earning shrink or vanish. Check Search Console before you redirect anything, and use a canonical instead when the page is still earning.
Does a canonical tag pass ranking signals the way a 301 does?
Not in the same way. A 301 is permanent, and over time the old page's ranking signals pass to the destination. A canonical is a strong hint rather than a command: Google usually credits the page you nominate, it can decide otherwise, and the page you canonicalised stays live and can keep ranking for searches of its own.
Why does Google keep ignoring my canonical tag?
View the page source and search for robots. If two things in your stack emit a robots directive, such as a leftover must-use plugin from a staging setup stamping noindex alongside an SEO plugin saying index, the page is sending contradictory instructions and Google applies the more restrictive one, so a stray noindex wins. There should be exactly one robots directive, and it should say what you mean.
Search Console says Google chose a different canonical. What should I do?
Google treats your tag as a strong signal rather than a command, so it can credit another URL. Check that the tag names the right address and that the address answers 200. If it does, Google has judged the two pages different enough to keep both. To consolidate anyway, make the losing page a true copy of the winner, or 301 it once it has nothing left to lose. Otherwise accept Google's choice.
Does the winning page need a canonical tag pointing at itself?
Google recommends one, and it costs nothing. A self-referencing canonical states the address you want credited. That helps when the same page also answers on a parameter URL, or on both www and the bare domain. Rebuilds drop this tag often, so check it after any migration.
General guidance only: check your own site's data in Search Console before removing or redirecting any page.
Where this comes from
Google's own documentation, so you can check any of this yourself:
- How to specify a canonical URL: the consolidation methods and how strongly each counts.
- Redirects and Google Search: which status code to use, and when.
- Search Essentials: spam policies, which cover sneaky redirects.