A canonical tag tells search engines which URL you prefer when several addresses contain the same or very similar content. It is written as a link element in the HTML head, using rel="canonical" and an absolute target URL.
The tag is a strong signal, not an absolute command. Search engines combine it with redirects, internal links, sitemap entries, page content, protocol choices, and other evidence. If those signals disagree, the search engine may select a different canonical.
Why duplicate URLs exist
Duplicate content is often a technical by-product rather than copied writing. One page may be accessible through HTTP and HTTPS, www and non-www hosts, trailing-slash variants, print views, tracking parameters, sort orders, session IDs, and multiple category paths.
Search engines group sufficiently similar URLs and choose a representative version. Google calls this process canonicalisation and explains it in its canonicalisation documentation.
What a canonical tag looks like
A typical HTML head contains a link element pointing to the preferred absolute URL. The target should return 200, allow indexing, and represent the same content. A self-referencing canonical points a page to its own preferred URL.
Self-referencing canonicals are useful because they state the intended version even when the page is reached with harmless tracking parameters. They also make template errors easier to detect during audits.
Canonical signals should agree
The preferred URL should receive internal links, appear in the XML sitemap, use the correct protocol and hostname, and avoid unnecessary redirects. Duplicate versions should not be promoted throughout the site.
If page A declares page B as canonical but all navigation links to A and the sitemap contains A, the configuration sends mixed signals. Search engines can still decide correctly, but the site is making the task harder.
When to use a canonical tag
- Tracking parameters produce the same primary content.
- A product appears under several navigational paths.
- Print or simplified views duplicate the main page.
- Syndicated or republished content has an agreed preferred source.
- Minor sorting variants do not create distinct search value.
The pages can remain accessible to users while signals consolidate around the preferred URL.
When a redirect is clearer
If visitors and search engines should never use the duplicate URL again, a permanent redirect is usually stronger and simpler. Domain migrations, changed slugs, HTTP-to-HTTPS consolidation, and retired duplicate pages often belong in this group.
A later guide will compare the two mechanisms directly. For now, remember that a canonical keeps both URLs accessible, while a redirect sends requests to a different URL.
Common canonical mistakes
Pointing every page to the homepage
This does not consolidate an entire website safely. Unrelated pages are not duplicates, so the signal can be ignored and individual pages may disappear from indexing consideration.
Canonicalising to a redirect or error
The target should be a live final page. A canonical chain creates ambiguity, while a target returning 404 or noindex cannot serve as a reliable preferred version.
Using relative or malformed URLs
Relative canonicals can work, but absolute URLs reduce interpretation errors. Check protocol, hostname, path, escaping, and trailing-slash consistency.
Conflicting desktop and mobile signals
Separate mobile URLs require reciprocal annotations and consistent content. Responsive design avoids much of this complexity by serving one URL across devices.
Changing canonicals with JavaScript
Google can process JavaScript-injected canonicals, but putting the correct tag in the initial HTML is more dependable. Avoid shipping one canonical in the source and replacing it with another after rendering.
Canonical tags and noindex are not substitutes
Noindex requests exclusion from search. A canonical suggests which duplicate should represent a group. Combining the two on the same page can produce unclear intent.
If a page is a duplicate, canonicalise or redirect it. If it should not appear in search for another reason, use noindex. The sitemap guidance in whether noindex pages belong in sitemaps follows the same principle of clear signals.
How to audit canonical implementation
Crawl the site and export each page’s canonical target. Flag missing tags on duplicate-prone templates, multiple canonical elements, targets on another unexpected host, non-200 targets, loops, chains, and pages whose canonical disagrees with the sitemap.
Then inspect representative URLs in Search Console. Compare the user-declared canonical with Google’s selected canonical. A difference is not automatically an error, but it indicates that other signals may be stronger than your declaration.
December migration caution
Year-end redesigns and platform changes often introduce canonical mistakes because production templates inherit staging hosts or old paths. Before launching during a holiday period with reduced staffing, crawl the full staging build and verify that every canonical points to the intended production URL.
After launch, sample all templates again. Canonical errors can affect thousands of pages from one shared line of code.
The practical rule
Use canonical tags for accessible duplicate or near-duplicate URLs. Point them directly to a live indexable preferred page. Support that choice with internal links, sitemap entries, and stable URL conventions.
Canonicalisation works best when it confirms a consistent architecture. It should not be used to compensate for uncontrolled URL generation or unrelated pages.
Build authority you can keep working with.
If you are already investing in content and off-site SEO, a dedicated editorial portfolio can add a managed publishing layer around your priority pages and campaigns.
Request a portfolio assessment