Link Plumbing

When Google Canonicalises Two Unrelated Pages Together

A search engine overriding your self-referencing canonical in favour of a near-duplicate sibling is ordinary behaviour. A search engine overriding it in favour of a page from a completely different section is not, and it points at a much narrower set of causes.

The distinction is worth holding onto, because the two cases get the same generic advice (“make the pages more unique”) and only one of them deserves it. Within a cluster of near-identical location or variant pages, similarity thresholds are a plausible explanation. Across a cluster boundary — a service page canonicalised to an unrelated category page — similarity of the published content usually isn’t the mechanism at all. Something is telling the crawler those two URLs are the same resource.

That canonicals are hints rather than commands explains why the override is possible. It doesn’t explain the pairing. The pairing is the diagnostic.

Three things that group unrelated URLs

1. The rendered HTML, not the source HTML.

Duplicate detection operates on what the crawler ends up with. If the pages are client-rendered, the pre-JavaScript state of every page in the template is byte-identical: same shell, same nav, same loading skeleton, no body copy. Two pages from different sections can be indistinguishable before hydration and completely distinct after it.

Compare what a non-executing fetch returns, not what your browser shows:

curl -s https://example.com/a/page-one/ > one.html
curl -s https://example.com/b/page-two/ > two.html
diff one.html two.html

An empty diff on two pages you consider unrelated is the answer. Whether a crawler renders JavaScript before clustering is not something you can rely on per-URL, and the pre-render state is what’s guaranteed to be seen. Navigation That Only Exists After JavaScript Runs covers the same asymmetry from the link-discovery side.

2. A shared identifier that isn’t a link.

Templating accidents propagate identity in places nobody greps:

  • og:url hardcoded to a single URL, or built from a variable that isn’t per-page.
  • JSON-LD with a fixed @id or url property — often left over from copying a snippet between templates.
  • A stale rel="alternate" (hreflang or media) pointing at an unrelated URL, which asserts an equivalence relationship between the two pages.
  • A <link rel="canonical"> emitted twice: one self-referencing from the framework, one hardcoded in a partial. Two canonicals on one page is not resolved in your favour; it’s resolved however the parser decides, and it may ignore both.

Check the shipped <head> of both URLs and compare them field by field. This is a five-minute check that people skip because canonical audits usually only diff the canonical tag.

3. Redirect and error residue.

If URL A ever redirected to URL B, or B was created as a temporary A/B variant of A, the relationship can outlive the configuration. A 302 in particular asserts that the target is a temporary stand-in and the original is the resource; crawlers may keep the original as canonical. A variant page that ran briefly and was then deleted can end up as the selected canonical for the page it was cloned from — at which point the survivor is unindexed and the winner is a 404. The cure is the same as the diagnosis: check whether the selected canonical still returns 200, and redirect it to the page you want if it doesn’t.

The pattern people usually notice first is that the affected pages have slightly weaker internal linking than their unaffected siblings. That correlation is real and worth acting on, but it’s better read as a tiebreak than a cause. When two URLs are in the same cluster, the crawler picks a representative, and the URL with more internal signals pointing at it is a natural pick. Internal links don’t put two unrelated pages in a cluster in the first place; they decide which one wins once something else has.

Which is why adding in-content links to the preferred URL often does flip the selection back, and why it doesn’t stop the clustering from happening again on the next page the template touches. Both things are true. If you want the fix to stick, find the identifier; if you want the page indexed this week, strengthen the signals. See Internal Linking as Plumbing for how those signals are read.

An order of checks

  1. Confirm the pair. Read the Google-selected canonical for the affected URL, and check whether the selected URL is in the same section, in a different section, or no longer resolves.
  2. Fetch both without JavaScript and diff. Empty diff → rendering is the cause.
  3. Diff the two <head> blocks field by field: canonical, og:url, JSON-LD @id/url, rel=alternate, rel=amphtml. Any field that matches when it shouldn’t is a candidate.
  4. Check the selected URL’s status code and history. A 302, a chain, or a dead URL as the selected canonical is a redirect problem wearing a canonical costume.
  5. Only then look at content similarity and internal link equity — and treat both as tiebreaks in a cluster you’ve already explained.

What “fixed” looks like

Canonical selection is re-evaluated on crawl, so nothing changes at the moment you deploy. The observable sequence is: the page gets crawled, the identifier no longer matches, the cluster dissolves, and the URL’s own canonical is accepted. On a low-traffic templated page that can take a while, because the crawl rate on a page a search engine has decided is a duplicate is low by definition — the URL it considers canonical is the one getting attention.

Two practical consequences. First, make the change on one low-risk URL and wait for it to be recrawled before rolling it across four hundred pages; you learn which of your three candidate causes was the real one. Second, don’t delete or redirect anything in the cluster while you’re waiting. If the search engine is currently treating an unrelated page as the canonical for your page, removing that page removes the address your content is indexed under, and the recovery is slower than the original problem.

canonicalsinternal-links