glimanaDocs Open Glimana →

Issue guide · Indexability

Canonical points to another domain

SeverityHigh
CategoryIndexability
ScopePer page
EffortSmall
Verified byRe-crawl after you mark the task done
Rule keycanonical_external

Short answer

The rel=canonical on this page names a URL on another domain. Google may index that other URL and show it instead of yours. If you did not mean to hand the page to another site — syndication is the one legitimate case — change the canonical to the page's own URL.

Why it matters

A canonical is your statement of which URL is the original. Cross-domain canonicals are supported precisely for syndication: a partner republishes your article and canonicalises back to you. When it happens by accident — a theme copied from a staging domain, a CMS setting still pointing at the old brand, a CDN rewriting hosts — you are telling Google that your own page is a copy. Google treats the canonical as a strong hint and usually follows it when other signals (links, content) agree; your page can disappear from results while the other domain's version appears.

How Glimana detects it

The crawler reads the canonical from the HTML <link rel="canonical"> and the Link: HTTP header and compares its host with the site's host (www and non-www are treated as the same site). The rule fires when the canonical's host is a different domain; the evidence shows the canonical URL.

How to fix it

  1. Find the affected pages in Glimana. Open Issues › Canonical points to another domain. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
  2. Apply the fix on your platform.

    1. Most often the SEO plugin's canonical field has a pasted URL. Open the page → Yoast/Rank Math Advanced → Canonical URL and clear it (an empty field produces a self-referencing canonical).
    2. If every page is affected, Settings → General → Site Address is wrong, or a search-and-replace after migration missed the canonical template. Fix the address and clear caches.

    Shopify writes {{ canonical_url }} in theme.liquid. If the theme was copied from another store, the value may be hard-coded; restore {{ canonical_url }}. Apps that add canonicals for duplicate collections can also point to the wrong domain — check their settings.

    Build the canonical from the request's canonical host in configuration, never from a constant. For syndication partners, keep the cross-domain canonical only on their copy.

  3. Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with curl -s https://your-domain/page | grep -i '<title\|canonical\|robots' that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached.

  4. Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when each page's canonical host is this site. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.

How the fix is verified

Affected pages are re-crawled; the task closes when each page's canonical host is this site.

FAQ

We syndicate our content to a partner. Which side should carry the cross-domain canonical?

The partner's copy should canonicalise to your original. Your page keeps a self-referencing canonical.

Sources