Cross-domain canonical tag

When <link rel="canonical"> on example.com/page points to other-domain.com/page, you’re telling search engines: “Don’t rank me — rank them.” Google honors this most of the time. Your URL silently disappears from the index while the other domain inherits the signals.

Cross-domain canonicals are sometimes correct — syndication agreements, sister domains where one is the primary. Most of the time, they’re a leftover from a migration, a copy-paste accident, or a CMS that hard-codes a domain in the template.

How to detect it

curl -s https://example.com/some/page \
  | grep -oE '<link[^>]*rel="canonical"[^>]*>'

If the href doesn’t start with your domain, you have a cross-domain canonical. Audit at scale by crawling the site and grouping canonicals by host.

In Google Search Console: URL Inspection → User-declared canonical shows the URL you declared. If it’s on a domain you don’t own, that’s the problem.

Decide first — is it intentional?

Run the three-question test:

1. Do you have a documented syndication agreement with the target domain? (e.g. you publish on Medium and want Medium to rank the canonical.) If yes, leave it — but be aware you’ve handed ranking to them permanently for that piece.
2. Is the target a domain you own, and you’ve decided it’s the primary brand? If yes, leave it — and add 301 redirects from the secondary domain to the primary so the cross-domain canonical becomes redundant.
3. Neither of the above? It’s a bug. Fix it.

The fix

Universal — point canonical at your own URL

<link rel="canonical" href="https://example.com/some/page" />

If you genuinely want to consolidate two domains, do it with 301 redirects in addition to (not instead of) the canonical:

HTTP/1.1 301 Moved Permanently
Location: https://canonical-domain.com/some/page

Redirects are stronger than canonicals and decisive.

WordPress

Common source: a content migration where the import included the original site’s domain inside the canonical field. Yoast and Rank Math both store the canonical as a post meta field — fix in bulk:

UPDATE wp_postmeta
SET meta_value = REPLACE(meta_value, 'https://old-domain.com/', 'https://example.com/')
WHERE meta_key = '_yoast_wpseo_canonical';

Then clear all caches.

Shopify

Shopify stores can end up with cross-domain canonicals when a theme hard-codes the production URL while the store is being developed on *.myshopify.com. Grep the theme for the wrong domain:

<!-- bad — hard-coded -->
<link rel="canonical" href="https://wrong-domain.com{{ canonical_url | remove: shop.url }}">

<!-- good — uses Shopify's built-in -->
<link rel="canonical" href="{{ canonical_url }}">

Next.js (App Router)

The most common bug is a stale metadataBase in the root layout:

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL("https://example.com"), // must match production
  alternates: {
    canonical: "/", // page-level overrides set this to the page path
  },
};

If metadataBase points to an old preview domain or a placeholder, every page emits a cross-domain canonical to that placeholder.

Syndication done right

If you syndicate to another platform and want them to rank for the content, set canonical on their version pointing to yours, not the other way around:

<!-- On medium.com/your-post -->
<link rel="canonical" href="https://example.com/your-post" />

That keeps the original on your domain ranking, with syndicated copies pointing back. Most platforms support this — Medium, Substack, LinkedIn — but you have to set it up explicitly.

Pitfalls

Don’t accept cross-domain canonicals from syndication partners blindly. Publishing partners sometimes set canonicals pointing to themselves by default — meaning when you republish their content, you canonical to them. Check before publishing.

Don’t fix a cross-domain canonical by removing it entirely. A missing canonical is also a problem. Replace it with a self-referential canonical to the correct URL.

Don’t 301 to fix a cross-domain canonical conflict unless you actually want to remove the page. A 301 permanently moves the URL. If the page should still exist on its own URL, fix the canonical instead.

Stale migration leftovers are the #1 cause. When you move from old.com to new.com, the canonical tags in the imported content frequently still reference old.com. Audit before launch, not after.

Fix at the edge with Serpwise

When the cross-domain canonical lives in a CMS template you don’t control — a hosted vendor, a third-party section behind reverse proxy — fixing the source is slow.

Serpwise can rewrite or remove <link rel="canonical"> at the edge based on URL patterns. Replace a leftover old-domain.com canonical with example.com everywhere it appears. Strip cross-domain canonicals on a specific section of the site. Audit the rewrites in one place. The long-term template fix lands on its own schedule.

See pricing or run a free AI visibility audit.