When three posts on this site ended up covering the same AI-prompting topic from three slightly different angles, the fix wasn’t a canonical tag — it was a 301 redirect, and Google’s own duplicate-content guidelines explain exactly why that was the right call instead of the more commonly recommended option. This is a walkthrough of that decision, using Google Search Central’s documented criteria rather than guesswork.
The problem: three posts, one topic, no clear winner
During a period of high-volume publishing on this site, the same underlying topic got written up three separate times under three different titles and angles, each a few hundred words, each hitting roughly the same search intent. None of the three was wrong, exactly — each had a slightly different framing — but together they split internal links, confused which URL should rank, and read, to anyone landing on all three, like the same article rewritten three times. That pattern of overlapping, thin coverage was part of a broader problem that contributed to this site’s own AdSense disapproval for low-value content, which is the reason this blog now runs a much smaller, much deeper daily publishing schedule instead of a high-volume one.
The fix was to merge the three posts’ useful material into a single, substantially longer article, and get rid of the other two URLs for good — not keep them live and just point search engines toward the survivor.
What Google’s own guidelines actually say about the choice
Google’s duplicate content documentation lays out three ways to tell Google which URL should be treated as canonical when near-duplicate pages exist: a redirect, a rel="canonical" annotation, or inclusion in a sitemap. It ranks them by how strong a signal each one sends. A redirect is described as “a strong signal that the target of the redirect should become canonical.” A rel="canonical" annotation gets the identical description — also “a strong signal.” Sitemap inclusion is explicitly weaker: “a weak signal that helps the URLs that are included in a sitemap become canonical.”
So on signal strength alone, a redirect and a canonical tag are treated as equivalent. The deciding factor is what you actually intend to do with the non-canonical pages, and Google’s documentation is specific about this rather than leaving it to interpretation.
| Method | What Google’s docs say to use it for |
|---|---|
| 301 / permanent redirect | “Use this only when deprecating a duplicate page” — meant for pages you’re retiring, not keeping around |
rel="canonical" | Described as “the preferred solution” when duplicates need to stay accessible to users |
| Sitemap inclusion | A supporting, weak signal — simple to maintain at scale but not a substitute for the other two |
noindex | Explicitly discouraged for this purpose: “We don’t recommend using noindex to prevent selection of a canonical page within a single site,” since it removes the page from Search entirely rather than consolidating it |
That single distinction — “deprecating” versus pages that need to stay accessible — is the entire decision rule. A canonical tag is for when you want to keep publishing both pages but tell Google which one to show in results. A redirect is for when one of the pages has no reason to keep existing at all.
Why this case was a redirect, not a canonical tag
The three overlapping posts weren’t variations worth keeping side by side — they were the same article written three times because of a volume-first publishing schedule, and keeping two of them live under a canonical tag pointing at the third would have meant leaving thin, repetitive content sitting on the site indefinitely, still indexable, still something a reader could land on directly from an old internal link or a bookmark. A canonical tag doesn’t remove a page from existence; it just asks Google to prefer a different one in results while the duplicate keeps serving traffic from any link that already points at it.
Retiring the two weaker posts outright and merging their useful material into the surviving one matched Google’s own “deprecating a duplicate page” language exactly. The 301 redirect means anyone who still has the old URLs bookmarked, linked from another site, or saved in a feed reader lands on the merged, more complete article instead of a thin stub — and the redirect’s “strong signal,” per Google’s own description, passes that consolidation benefit to the surviving URL rather than splitting it across three pages indefinitely.
What the merge actually involved
Mechanically, the process was the opposite of complicated, which is part of why it’s easy to put off:
- Read all three posts side by side and identify which one had the strongest structure and the most complete coverage — that one became the base.
- Pull any genuinely distinct material from the other two — a point the base post missed, an example it didn’t cover — into the base post, rather than just picking a winner and discarding the rest wholesale.
- Expand and rewrite the merged result so it meets the site’s current depth standard rather than averaging three thin posts into one still-thin post.
- Set up server-side 301 redirects from both retired URLs to the surviving one.
- Check every internal link across the site that pointed at either retired URL and update it to point directly at the surviving post, rather than relying on the redirect to carry internal link equity indefinitely.
That last step is easy to skip and shouldn’t be. Google’s documentation recommends linking internally to the canonical URL directly as a best practice regardless of which consolidation method you use — a redirect handles external links and old bookmarks, but it shouldn’t be the only thing standing between your own site’s internal links and a result that used to exist.
What a canonical tag would have gotten wrong here
It’s worth spelling out the counterfactual, because “just add a canonical tag” is the first instinct for a lot of people fixing duplicate content, and it’s not automatically wrong — Google’s documentation calls it “the preferred solution” for selecting a canonical page within a site. It’s the preferred solution specifically because it keeps all the duplicate pages live and accessible while still consolidating ranking signals onto one of them, which is exactly right when the duplicates serve some ongoing purpose — a print-friendly version of a page, a tracking-parameter variant, a page that legitimately needs to exist in two places in a site’s structure.
None of that applied here. The two retired posts had no reason to keep existing once their useful content moved into the merged article — they weren’t serving a distinct purpose, they were redundant. Leaving them live under a canonical tag would have meant permanently maintaining three pages to serve the job one page could do, with two of them sitting as dead weight that still needed monitoring, still showed up in internal search, and still cluttered the sitemap.
The takeaway for anyone cleaning up a backlog of overlapping posts
If you’re staring down a backlog of posts that cover the same ground — common after any period of volume-over-depth publishing — Google’s own framing gives you a clean test to apply to each cluster of overlapping pages: are you keeping every page in the cluster for a real reason, or are some of them just redundant? If they’re redundant, the documentation’s own word is the one to use — deprecate them, merge what’s worth keeping, and redirect. If they’re legitimately different enough to both deserve to exist, a canonical tag pointed at whichever one should rank is the better fit. Treating every duplicate-content problem as a canonical-tag problem, or every one as a redirect problem, misses the distinction Google’s own guidelines are actually built around.
For the technical side of making sure a sitemap reflects changes like these correctly after the fact, see our write-up on diagnosing a stale Rank Math sitemap after posts are created or changed via the REST API. For getting the structured data right on whichever post survives a merge like this, see our Rank Math Article schema checklist against Google’s own guidelines, and for a related before-and-after on rewriting thin content rather than just merging it, see this thin-page rewrite case study.
There’s also a smaller, easy-to-miss detail in the same documentation worth building into any cleanup checklist: a self-referential canonical tag on the surviving page itself. Google’s guidance recommends every canonical page carry a rel="canonical" pointing at its own URL, which sounds redundant until a CMS or caching layer later generates a tracking-parameter or trailing-slash variant of that same URL — at that point the self-reference is what keeps the merged post, not some accidental duplicate of it, treated as canonical.
FAQ
Does a 301 redirect pass all of a retired page’s ranking signals to the new URL?
Google’s documentation describes a redirect as a strong canonicalization signal but doesn’t quantify it as “all” of anything — it’s a strong signal among several factors Google’s systems weigh, not a guaranteed one-to-one transfer.
Should I ever use a 302 (temporary) redirect instead?
Not for this situation. Google’s guidance specifically frames permanent redirects as the tool for deprecating a page for good; a temporary redirect signals the opposite — that the original URL might come back — which doesn’t match a page you’ve decided to retire permanently.
Sources: Google Search Central, “How to specify a canonical URL with rel=canonical and other methods.”
Featured image: “Desktop with laptop and calculator” via Wikimedia Commons, released under CC0.
