Cross-Domain Canonicals: When They’re Correct

A cross-domain canonical is a rel=canonical tag on one domain pointing to the equivalent page on a different domain, telling Google to index and rank the other domain’s URL instead of this one. It is the correct tool in a narrow set of cases — content syndication, duplicate catalogues across owned brands, and migrations where the old domain has to stay live — and the wrong tool almost everywhere else, including the two situations people reach for it most often: multilingual sites and simple domain moves.

Google has supported cross-domain rel=canonical since 2009, and the mechanism hasn’t changed since. What trips sites up isn’t the syntax, it’s picking it over a 301 redirect or hreflang when one of those two is actually the right tool for the job.

What is a cross-domain canonical, exactly?

A cross-domain canonical is the same <link rel="canonical" href="..."> tag used for same-site duplicate consolidation, except the href points to a URL on a different domain entirely. Google’s consolidating duplicate URLs documentation confirms the target doesn’t have to share a domain, subdomain, or even a TLD with the page carrying the tag — it just has to be a genuinely similar or duplicate piece of content.

Both URLs stay live and independently reachable. That’s the core difference from every other consolidation tool: nothing about a cross-domain canonical removes a page, breaks an existing link to it, or stops a browser from loading it directly. It only tells Google’s indexing systems which of the two copies should get the ranking credit.

When is a cross-domain canonical actually the correct choice?

Three situations justify it, and outside these three, a different tool is almost always a better fit.

• Content syndication. A publisher picks up your article and republishes it on their own domain. If they add a cross-domain canonical pointing back to your original, Google consolidates ranking signals onto your version instead of treating the two as competing duplicates.
• Duplicate catalogues across owned domains. A company running two branded storefronts with identical product listings — common after an acquisition — can canonicalise the secondary domain’s product pages back to the primary domain rather than maintaining separate content or paying for a full technical merge.
• Migrations where the old domain must stay live. If a legal, contractual, or technical reason keeps an old domain online and unable to fully redirect (a common situation during a slow multi-phase migration), a temporary cross-domain canonical can point Google at the new domain while the old one still resolves for direct visitors.

Outside these three, reach for a 301 redirect or hreflang first — both are covered below, and getting this choice wrong is one of the more common reasons a migration or syndication deal underperforms on search visibility.

Cross-domain canonical vs 301 redirect vs hreflang: which one applies?

The most expensive version of this mistake is using a cross-domain canonical on a genuine one-time domain move. It leaves the old domain sitting in the index competing with the new one, splitting authority, when a 301 would have consolidated it cleanly in one pass.

What does a correct cross-domain canonical implementation need?

Five requirements for a cross-domain canonical to hold up

• Content on both pages is genuinely similar — Required. Not identical, but close; wildly different content breaks the consolidation.
• Target domain is fully crawlable — Required. If Googlebot can’t reach the target, it won’t honour the canonical.
• Target URL returns a 200 status — 200 OK. Never a redirect chain, a 404, or a login wall.
• Direction is one-way and unambiguous — One-way. Two domains canonicalising to each other creates a loop Google resolves unpredictably.
• No noindex on the target — None. A canonical pointing at a noindexed page is a direct contradiction.

Every one of these is checkable in a standard crawl. The one that gets missed most often is the third: a syndication partner’s CMS frequently appends tracking parameters or wraps the URL in a redirect for analytics reasons, which quietly breaks the canonical chain even though the tag itself is correctly written.

What mistakes make Google ignore a cross-domain canonical?

The same signal-conflict problem that breaks same-domain canonicals applies here, with one addition specific to cross-domain setups: you don’t control the other domain. A syndication partner can change their template, drop the tag during a redesign, or add their own competing canonical without telling you. Treat any cross-domain canonical you depend on as something to re-verify periodically, not a one-time setup task. This matters more on sites already carrying index bloat from junk pages, since a broken cross-domain canonical adds another source of duplicate, competing URLs to an index that’s already accumulating them.

The rules that keep a same-domain canonical tag working correctly — one tag per page, absolute URLs, a 200-status target, and consistency with other signals — apply identically here. A cross-domain canonical is not a special case; it’s the same mechanism pointed at a URL you don’t control.

How do you verify a cross-domain canonical is actually working?

Use the URL Inspection tool in Search Console on the domain carrying the tag and check “Google-selected canonical” against “User-declared canonical.” If they match the cross-domain target, it’s working. If Google has selected something else — often the page’s own URL — one of the five requirements above is failing, most commonly the target returning something other than a clean 200. For syndication deals specifically, re-check this quarterly, since it’s the partner’s page that most often drifts out of compliance, not yours.

Frequently asked questions

What is a cross-domain canonical tag?

A cross-domain canonical is a rel=canonical link element on one domain that points to the equivalent page on a different domain, telling Google to index and rank the other domain’s URL instead of this one. It works the same way as a same-domain canonical, but consolidates signals across two separate sites rather than two pages on the same site.

Is a cross-domain canonical the same as a redirect?

No. A cross-domain canonical is a hint for indexing that leaves both URLs live and reachable, while a redirect forcefully sends users and crawlers from one URL to another and effectively retires the original. Use a cross-domain canonical when the origin domain needs to stay online for reasons other than search, and a redirect when it should stop existing.

When is a cross-domain canonical the correct choice?

It’s correct for content syndication, where a publisher republishes an article and wants ranking credit to stay with the original; for multi-brand duplicate catalogues, where the same product listing exists on two owned domains; and for site migrations where the old domain must stay live for non-search reasons and a full 301 redirect isn’t possible yet.

Can I use a cross-domain canonical instead of hreflang?

No. Cross-domain canonicals tell Google to consolidate and index one URL instead of another, which is the wrong behaviour for translated or region-specific pages that should all remain indexed for their own market. Hreflang tells Google these pages are equivalent alternates for different languages or regions, and all of them should stay in the index.

Does the syndicated publisher need my permission to add a cross-domain canonical?

Yes, functionally. The tag has to be added to the syndicating publisher’s own page in their own head section, so it requires their cooperation. Most syndication agreements should specify this in writing rather than assuming the partner will add it correctly, since a missing or misdirected canonical is one of the most common syndication disputes.

Sources

• How to Specify a Canonical with rel=”canonical” — Google Search Central
• Handling Legitimate Cross-Domain Content Duplication — Google Search Central Blog
• Technical SEO: The Complete Working Guide