Canonical URLs tell search engines which public address should represent a page when the same or very similar content is reachable through more than one URL. The duplicates usually come from HTTP and HTTPS variants, www and non-www hosts, tracking parameters, filtered category pages, print views, or older paths that still load after a redesign.
The durable workflow is to choose one preferred URL, keep that URL crawlable, and make every canonical signal point to the same place. Current Google Search Central guidance treats redirects and rel="canonical" as strong signals, while sitemap inclusion is only a weak signal, so mixed signals are more likely to produce the wrong selected canonical.
The preferred URL must stay useful as the indexed page. Google says not to use robots.txt or noindex as a replacement for canonicalization, recommends an absolute canonical URL in the HTML head, and exposes both the User-declared canonical and Google-selected canonical in Search Console so the final selected URL can be checked after indexing.
Steps to use canonical URLs for your website:
- Choose the exact public URL that should represent the page and decide which duplicate URLs still need to stay reachable.
Preferred: https://www.example.com/guides/canonical-url Duplicate: https://example.com/guides/canonical-url?utm_source=newsletter Duplicate: http://www.example.com/guides/canonical-url
Keep the protocol, hostname, trailing-slash style, and path form consistent so the canonical target is unambiguous before any markup or redirects are changed.
- Redirect every duplicate URL that no longer needs its own public page to the preferred URL.
Google treats redirects as a strong canonical signal. Keep a duplicate URL live only when it still serves a real purpose, such as a tracked campaign URL, filtered listing, or print view.
- Add one absolute rel="canonical" link element that points to the preferred URL in the HTML head of the preferred page and of any duplicate page that must remain reachable.
<link rel="canonical" href="https://www.example.com/guides/canonical-url" />
Google accepts the canonical link element only in the HTML head and recommends an absolute URL instead of a relative path. For non-HTML files such as PDFs, return the canonical as an HTTP Link response header instead of an HTML tag.
- Keep the rest of the site pointing at that same canonical URL, including internal links, breadcrumbs, structured data references, hreflang mappings, and XML sitemap entries.
If hreflang is in use, point each language version to a canonical page in the same language, or the closest available substitute language when an exact match does not exist.
- Confirm that the canonical target returns 200 OK, stays indexable, and matches the content of the duplicate pages closely enough to be treated as the representative version.
Do not use robots.txt, the URL removal tool, or noindex as a shortcut for canonicalization, and do not point canonical tags at fragment URLs, unrelated pages, or redirect chains.
- Open the page in a browser, view the page source or developer tools, and confirm that exactly one canonical target appears in the HTML head with the full preferred URL.
If a CMS or SEO plugin inserts the wrong value, fix the page template, metadata setting, or plugin configuration instead of adding a second canonical tag.
- Inspect the URL in Google Search Console and compare the indexed result's User-declared canonical and Google-selected canonical fields.
The indexed result shows Google's current canonical choice. The live test can confirm whether Google can fetch the page now, but it cannot predict canonical selection for duplicate pages.
- Recheck the page after each fix until redirects, canonical markup, internal links, sitemap entries, and Search Console all agree on the same preferred URL.
Canonicalization is still a hint rather than a hard rule, so Google can keep a different URL when the preferred page is weaker, inconsistent, or less useful than another duplicate.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
