What a canonical tag is and is not
The relation rel="canonical" is defined in RFC 6596 and used in a <link> element in the page head or in an HTTP Link header. Google describes the ways of declaring a canonical as signals of different strength: a redirect is a strong signal, rel="canonical" is a strong signal, and inclusion in a sitemap is a weak signal. None is a command. Google looks at all of them and decides, which is why a mix of conflicting signals produces unpredictable results.
Google also states what not to do: do not use robots.txt for canonicalization, and do not use noindex to pick a canonical within a site, because noindex blocks the page from search entirely.
The mistakes
1. The canonical points to another host
The most damaging case: every page on the new production site has a canonical pointing at the staging host, or the other way round (staging pages claim the production URL, production claims staging). The tag was set from a configuration value (a “site URL” setting) that was never updated after the move. Search engines will treat the target host as the real site, and your production pages as copies.
2. Every page canonicalises to the home page
A template bug or an over-eager plugin outputs the home page URL as canonical for all pages. Individual pages are treated as duplicates of the home page and drop out.
3. No self-referencing canonical
Google lists omitting a self-referential canonical on the canonical page itself as a mistake to avoid. A self-referencing canonical on every indexable page protects you from parameters and tracking tags creating duplicates.
4. Relative or malformed URLs
Google supports relative paths but recommends absolute URLs, because a relative one can cause long-term problems, such as a staging copy that gets crawled and its canonical resolves to the staging host. A typo (a stray space, htp://) makes the tag unusable.
5. HTTP instead of HTTPS, or the wrong variant
A canonical to http:// on a site that has moved to HTTPS, or to the non-www form when everything redirects to www, creates a loop of signals: the tag says one URL, the redirect says another. Choose one form and make the canonical, redirects, internal links and sitemap agree. Google also lists HTTP URLs in a sitemap or hreflang annotations on an HTTPS site as a mistake.
6. Canonical and redirect disagree
If /a redirects to /b, then /b must not canonicalise to /a. Signals that contradict each other let Google decide for itself.
7. Two canonical declarations that differ
Google’s advice: do not specify different URLs as canonical for the same page using different techniques. A plugin outputs one in the HTML, the CDN adds a different one in the Link header. Pick one place.
8. Canonical in the body or added by JavaScript only
A <link rel="canonical"> must be in the <head>. A tag that appears in the body, or only after JavaScript runs, may not be recognised. Test what a crawler sees in the raw HTML.
9. Paginated and filtered pages
Pointing every page of a list at page 1, or every filter combination at the unfiltered list, hides products and posts that exist only on later pages. Use canonicals to consolidate real duplicates (tracking parameters, print versions), not to hide distinct content.
10. Linking internally to the duplicate
Google lists “linking internally to duplicate URLs instead of the canonical one” among the practices to avoid. Internal links, the sitemap and the canonical should name the same URL.
Find them
- View the rendered source of a page from each template and read the canonical. It should be an absolute HTTPS URL on the production host, equal to the page’s own URL.
- Check the response headers for a
Link: <...>; rel="canonical". - Crawl the site and export canonical, status and final URL for every page. Filter for pages where the canonical differs from the URL, or the canonical’s host differs.
- Use Search Console’s URL Inspection. It reports the canonical you declared and the one Google chose; when they differ, find out why.
- Compare with the sitemap. Every sitemap URL should return 200 and canonicalise to itself.
After a migration, re-check these three
- the canonical host (is it the new domain?);
- the scheme and the
wwwchoice; - canonicals on templates with parameters: category, tag, search, pagination.
How Beamfar helps
Beamfar reads the canonical link (HTML tag, or the Link header when there is no tag) on each monitored page and raises an SEO-risk alert when the canonical moves to another host. The alert is sent after a second sighting. Moves within the same host (for example to a different path) are recorded as changes on the timeline, not as alerts. It checks the pages you add as monitored URLs, so add one page per template.
Questions
Is rel=canonical a command or a hint?
Google calls it a strong signal, not a directive. It combines the canonical tag with redirects, the sitemap, internal links and other factors, so it may pick a different URL than the one you declared.
Should every page have a self-referencing canonical?
Every indexable page benefits from one. Google lists leaving it out on the canonical page itself as a mistake, because it helps when parameters or tracking tags create duplicate URLs.
Can I use noindex instead of a canonical for duplicates?
Not within one site. Google advises against it for choosing a canonical, because noindex removes the page from search entirely, while a canonical consolidates the signals onto the preferred URL.
Do canonical tags work across domains?
Yes, a canonical can point to another domain, which is why a wrong host is such a damaging mistake after a migration. Check that it points to your own production host.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- Google Search Central, Consolidate duplicate URLs (developers.google.com)
- RFC 6596, The Canonical Link Relation (www.rfc-editor.org)