Canonical URL

Canonicalization is how a search engine picks one address to represent a set of duplicates. It reads several signals. In order of strength, Google lists redirects, then rel="canonical" link annotations, then sitemap inclusion. They are signals rather than commands, so the canonical you declare can be overruled when the others disagree with it.

Duplicates are usually accidental: a trailing slash, a parameter, an uppercase path, or a platform's default subdomain still answering. Google's advice is to use consistent absolute URLs and to make the signals agree.

Why it matters for a marketing site

Tracking parameters, trailing slashes and staging domains all create extra addresses for one page. Without a clear canonical, ranking signals split across them and search results can show the version you did not want. During a migration, a canonical copied from the old platform can point every new page back at the site you are leaving.

How I handle it

This site's layout writes each page's canonical from its own path, so a new page cannot forget one and a template cannot hand out someone else's. On a migration I keep the existing URL shape unless there is a reason to change it, and check the canonicals on the built site, because that is where a stale domain or a mismatched slash shows up.

Example

Say a page answers at /pricing/, /pricing and /pricing/?utm_source=newsletter. All three carry rel="canonical" pointing at https://example.com/pricing/, and the unslashed path also redirects there. Search engines group the signals on one address, and the campaign link keeps working.

Common mistakes

• Pointing at the staging domain. A staging canonical that ships to production tells Google the real page is somewhere else.
• Sending mixed signals. A canonical to one URL, a sitemap entry for another and internal links to a third leave Google to guess.
• Using noindex on test variants. Google recommends rel=canonical for alternate test URLs, and warns that noindex there can have unexpected effects.