Canonical to the Wrong Host: HTTP and WWW Variants
I carried my coach over the hedge into the back lane and informed the post that the back lane was my proper address.
The short answer
- What it is
- This issue means the canonical tag sits on the http or https, or the www or bare, counterpart of the main origin. The path is right, but the host or protocol is not.
- Why it matters
- The page asks search engines to index an address the site does not want to use. That creates conflict with redirects and sitemaps, and it can put the wrong version in search results.
- How a crawler should report it
- Report the page URL, the canonical target, and which part differs: scheme, www prefix, or both. Mark the page as canonicalized to another host, and note whether the target redirects back.
- Live examples
/lab/canonical-host-variant/(positive), on the second shelf/lab/canonical-host-variant/near-miss/(near miss)
When a Page Names the HTTP or WWW Twin as Its Main Version
A canonical to the wrong host is often left over from a site move. A team switches to HTTPS and updates the redirects, but the old base URL stays in a settings file. The same thing happens when a site drops or adds www. CDN and reverse proxy setups can also cause it, since the app may see an internal scheme and print http in the tag. The path looks right, so the error is easy to overlook.
This setup usually creates a loop of mixed signals. The page says the HTTP address is preferred. That address redirects back to HTTPS. So the canonical points to a redirect, and the redirect points to the original page. Search engines have to settle the conflict themselves. Google says it prefers HTTPS pages as canonical in general. It may overrule your tag, but you should not count on that result.
To detect it, compare the scheme and host of each canonical with the site's main origin. A site-wide problem shows up as the same variant on every page. Also request all four combinations of http, https, www, and the bare domain. Each one should end at a single address in one redirect. Note any variant that answers 200 by itself, because that creates a duplicate copy of the whole site.
To fix it, set one preferred origin in your site configuration and build all canonicals from it. If a proxy sits in front of the app, make sure it passes the original scheme, often through the X-Forwarded-Proto header. Redirect all other hosts with a 301. Update your sitemap and your internal links to match. After that, inspect a few URLs to confirm Google now reports the host you chose.