In one paragraph
A canonical pointing to another domain signals that a different URL should represent duplicate or very similar content. That can be intentional, but a wrong production base URL can unintentionally point every page away from your site. Inspect the destination and content relationship before changing it. Canonical is a strong preference signal, not a guaranteed instruction to index or rank another URL.
Why it matters
Search engines select a representative URL when content is available at several addresses. A rel="canonical" annotation helps state your preferred representative and can support consolidation of relevant signals. Google still evaluates other evidence and can select a different canonical.
Common accidental causes include a copied template, staging hostname left in production configuration, or an old domain preserved after migration. The fix often belongs in one shared URL-generation setting rather than hundreds of manual page edits.
A different host is not automatically a different business, and same ownership is not proof that two pages should be consolidated. A legitimate cross-host architecture can be deliberate. Translations and genuinely distinct pages generally need their own appropriate canonical treatment rather than being collapsed just to make a check pass.
How WebAuditOS evaluates this finding
The supplied rule resolves HTML canonical href values and compares their hostname with the scanned site's hostname, ignoring a leading www. Same host passes; another host or an unparseable canonical fails at medium severity. No canonical is not graded here.
It reads served HTML on eligible HTML responses, not canonical HTTP Link headers. Scheme and port are not part of this host comparison, while sibling subdomains count as different. A same-host HTTP canonical can therefore pass this rule despite conflicting with the intended HTTPS URL. The result does not validate destination status, equivalence, or Google's selected canonical.
How to fix it
- Inspect the actual annotation in the final page source and any canonical response header or runtime output. Record the full resolved destination, not just the hostname highlighted by the finding.
- Determine the preferred location for this content. Check whether the target is a real equivalent, an obsolete domain, a preview environment, or a deliberate representative. Document intentional cross-host consolidation before making bulk changes.
- For a normal standalone production page, generate the clean preferred absolute URL in the head. For example:
<link rel="canonical" href="https://example.com/pricing">Replace the example with the real page URL. Do not paste the same homepage canonical into every route.
- Fix the shared source of the host: CMS site settings, framework metadata base, environment variables, or template configuration. Do not build public canonical URLs from unvalidated arbitrary request hosts.
- Align other signals. Internal links and sitemap entries should normally use preferred URLs, and deprecated duplicate URLs can redirect when appropriate. Keep language alternates and canonical choices coherent rather than canonicalising every translation to one language.
- Avoid contradictory canonical sources. Google supports HTML and HTTP-header annotations, but maintaining both can introduce disagreements. Prefer a clear consistent implementation rather than adding duplicate methods merely to satisfy a scanner that sees one.
- Test deep pages, pagination, parameterised variants, and preview environments. Ensure valid production pages do not all point to one destination or an inaccessible target.
- Deploy, recrawl representative URLs, and inspect available Search Console canonical information. Selection and indexing can take time and remain Google's decision. Rescan while retaining any intentional exception with its reason.
What the fix can break
Changing a legitimate representative can alter consolidation and the URLs shown in search. Evaluate current signals and intent rather than automatically replacing every cross-host canonical with self-reference.
A wrong template can propagate rapidly. Sample multiple route types before publishing a global setting, and preserve rollback information.
Do not use a canonical to hide distinct pages solely because their titles are similar. Nor should a robots.txt block be used to force canonical selection: blocked content can leave search engines without the evidence you intended them to read.
Questions
Is every cross-domain canonical wrong?
No. It can be intentional for equivalent content, but requires a justified representative and consistent signals. The scanner cannot infer that intent.
Does Google have to follow the annotation?
No. It is a strong signal among others, not an absolute instruction or an indexing guarantee.
Why does an owned subdomain fail?
The supplied comparison treats it as another host. Ownership alone does not determine canonical equivalence.
Which related checks help?
Review missing canonicals, noindex, and the indexing checklist.