Does a cross-domain canonical work?
Yes, as a hint: Google accepts a rel=canonical that points to a URL on another domain and weighs it the way it weighs any canonical. For syndicated articles, though, Google now prefers that the partner site noindex its copy rather than rely on a cross-domain canonical.
A cross-domain canonical is a rel=canonical tag whose target sits on a different domain from the page carrying it. The markup is identical to any other canonical; only the host differs:
<link rel="canonical" href="https://original-site.com/original-article/">If that tag appears on https://partner-site.com/republished-article/, it asks Google to index the original-site.com version and treat the partner copy as a duplicate. RFC 6596, which defines the canonical link relation, allows targets on other domains, so the pattern is standard. Google may still decline it, and is more likely to when the two pages are not close duplicates.
When a cross-domain canonical is the right tool, and when it isn't
There are legitimate uses. One is consolidating genuinely identical content that you own and publish on more than one domain, such as the same page mirrored on two domains you control, where you want signals to consolidate on one of them. Another is a syndication partner voluntarily canonicalizing a near-identical republished article back to the original source.
The broader syndication case is shakier. Syndicated pages are often not identical to the original: a different surrounding template, added commentary, different formatting, sometimes an edited excerpt. When the pages differ meaningfully, treating one as a strict duplicate of the other does not hold up, and Google may simply decline the hint.
Why Google now prefers noindex for syndication
Since around May 2023, Google has stopped recommending cross-domain canonicals as the way to handle syndication. In Google's words: "The canonical link element is not recommended for those who want to avoid duplication by syndication partners, because the pages are often very different." Google says the most effective solution is for syndication partners to block indexing of the syndicated copy with noindex.
The reasoning follows from the similarity problem. A canonical asks Google to judge two pages as one; noindex on the copy removes the need for that judgment. The copy stays readable for the partner's audience, and it simply does not compete in search, however much it differs from the original. Pairing that noindex with a cross-domain canonical on the same copy is a separate mistake: pick one of the two.
Canonical, noindex, or a 301: choosing across domains
| Situation | Tool | Reason |
|---|---|---|
| The same page lives on two domains you own, and both must stay live | Cross-domain canonical | Both URLs stay reachable while signals consolidate on one, subject to Google agreeing |
| Content is moving to another domain permanently | 301 redirect | The old URL should disappear; Bing's advice is "Moving content? Think 301, not rel=canonical" |
| A partner republishes your article | noindex on the partner's copy | Google's current recommendation, and it works however much the copy differs |
| A partner will not add noindex | A canonical back to the original, or at least a link back | A weaker fallback that still identifies the source |
| You republish another publisher's article | noindex on your copy, or a canonical to the source | The same logic from the other side |
In every syndication row the tag goes on the copy, not the original, which means the original publisher depends on the partner to add it. The real implementation step is the syndication arrangement itself: ask for noindex (or, failing that, the canonical) as a condition of republishing, before the article runs. A canonical on the original page naming itself does nothing to the partner's copy.
How to implement a cross-domain canonical
For the narrower cases where a cross-domain canonical still makes sense, the rules match any other canonical: one tag, in the raw HTML head (or an HTTP header) rather than injected only by JavaScript, pointing to the exact preferred version on the target domain.
<link rel="canonical" href="https://original-site.com/original-article/">A cross-domain canonical cannot be written as a relative URL at all. Relative references resolve against the page's own host, so the full scheme and hostname are required to reach another domain. For a republished PDF or other non-HTML file, the same declaration can be sent as an HTTP Link header, which Google supports for web search:
Link: <https://original-site.com/downloads/report.pdf>; rel="canonical"Before relying on the arrangement, confirm with the other site that the target is stable, returns a clean 200, and is not itself redirected or noindexed. A canonical to a redirect or an error page gives Google a target it cannot index cleanly.
Checking a cross-domain canonical from each side
What each party can see depends on which site it runs.
- On the site carrying the canonical (the copy): URL Inspection in Search Console shows the user-declared canonical and, from indexed data, the Google-selected canonical. When Google accepts the hint, the copy typically appears in the Page indexing report as "Alternate page with proper canonical tag," and cross-domain syndicated copies are one of the normal reasons for that status. The live test cannot predict which URL Google will choose.
- On the original site: URL Inspection only accepts URLs in a property you have verified, so the partner's page cannot be inspected. Check its declaration from outside by searching the HTML for
rel="canonical"and by reading the response headers, since a canonical sent in aLinkheader never appears in View Source. If noindex was the agreement, check for that too. - On both sides: allow time. Delays in cross-domain canonicals taking effect have been reported, and Google's troubleshooting guidance suggests allowing up to about two weeks for re-evaluation after a fix.
curl -s https://partner-site.com/republished-article/ | grep -i 'rel="canonical"'
curl -s -D - -o /dev/null https://partner-site.com/republished-article/ | grep -i '^link:\|^x-robots-tag:'One more reading applies when nobody declared anything. Google's canonicalization troubleshooting page notes that "hosting misconfigurations may cause unexpected cross-domain URL selection," so a Google-selected canonical on a domain you do not recognize deserves a look even when no cross-domain tag exists.
Risks: ignored hints, hijacking, and slow updates
- It is only a hint. Google may ignore a cross-domain canonical, particularly when the two pages differ meaningfully, which is common in syndication.
- Injected cross-domain canonicals are a known hijacking technique. RFC 6596's security section warns that on a compromised site the canonical "can be implemented with malicious intent to designate the attacker's IRI as the preferred version." Google's troubleshooting page likewise lists hacked sites inserting a "cross-domain rel=canonical link annotation." Injections can be cloaked to show only to Googlebot, so a clean View Source in your own browser does not rule one out; the Google-selected canonical in URL Inspection is the better check.
- Templates can print someone else's domain. A site that builds its canonical from the request's
Hostheader, which the client controls, can be made to emit a canonical naming another domain, and a cache that stores that response serves it to crawlers as well. The host in a canonical should be fixed in configuration, never read from the request. - Updates can be slow. Cross-domain canonical signals do not necessarily take effect quickly, so a change may lag in Google's index.
Monitoring follows from these risks. Compare the user-declared and Google-selected canonical for pages that carry a cross-domain canonical; a persistent mismatch means Google is not honoring the hint. Crawl your own site periodically for canonicals that point off-domain when none should, since an injected one is easy to miss without a deliberate check.
Frequently asked questions
Does Google still support cross-domain canonical tags?
Yes, technically, as a hint, the same way Google treats any rel=canonical. Since around May 2023, however, Google no longer recommends cross-domain canonicals as the solution for duplication caused by content syndication.
What does Google recommend instead of a cross-domain canonical for syndicated content?
Google recommends that syndication partners block indexing of the syndicated copy with noindex. Its stated reason is that the canonical link element is not recommended for this purpose because syndicated pages are often very different from the original. The noindex goes on the partner's copy, so it has to be agreed with the partner.
Why might Google ignore a cross-domain canonical?
Because it is only a hint, and because the two pages involved are often not truly identical. Syndicated content frequently differs in surrounding template, formatting, or added commentary, which weakens the duplicate claim a canonical makes. A target that redirects, errors, or carries noindex also gives Google a reason to choose its own canonical.
Can a cross-domain canonical be used maliciously?
Yes. Injected cross-domain canonicals are a known hijacking technique: an attacker who can modify a page inserts a canonical pointing to a domain they control, attempting to pull that page's signals away from the legitimate site. RFC 6596 and Google's troubleshooting documentation both describe the risk.
Should I use a cross-domain canonical when moving a site to a new domain?
No. A permanent move calls for 301 redirects, which send users and crawlers to the new URL and are a strong canonical signal. A cross-domain canonical leaves both URLs live and is only a hint, which suits content that must stay on both domains, not content that is moving.
Can the syndicated copy carry both noindex and a cross-domain canonical?
It should carry one or the other. noindex asks Google to drop the copy while the canonical asks Google to consolidate the copy's signals onto the original, and the two requests conflict. For syndication, Google's recommendation is noindex.
How do I check whether Google is honoring a cross-domain canonical?
On the site carrying the canonical, use URL Inspection in Search Console to compare the user-declared canonical with the Google-selected canonical; a persistent mismatch means Google is not following the hint. The original publisher cannot inspect a partner's URL, but can confirm the partner's tag or header is present with View Source and curl.