What is a canonical URL, and when to use one

What rel=canonical actually does

The same content is usually reachable at more than one URL. Tracking parameters, session identifiers, a trailing slash, http alongside https, www alongside the bare domain, a print view, a sorted listing: each of those is a separate URL serving the same words. Left alone, a search engine picks one of them itself, and it may not pick the one you would.

A canonical is how you make that choice explicit:

<link rel="canonical" href="https://example.com/shoes">
Link: <https://example.com/shoes>; rel="canonical"

Two properties are worth internalizing. First, it is a hint, not an instruction. Google weighs it against redirects, internal links, sitemap entries and the content itself, and it can and does choose a different canonical than the one you declared. Second, it consolidates rather than deletes. Signals from the duplicate accrue to the canonical, which is the difference from noindex, where the duplicate simply stops existing as far as search is concerned.

Self-referencing canonicals

Every indexable page should declare itself as its own canonical. It sounds redundant and it is the single most useful line of the three, because it is what neutralizes parameters you did not anticipate. When /shoes?utm_source=newsletter declares https://example.com/shoes, the campaign URL folds into the clean one automatically instead of competing with it.

Three rules for getting them right: use absolute URLs including the scheme, emit exactly one canonical element per page (a page with two conflicting canonicals has all of them ignored), and keep the canonical consistent with the rest of your signals. A canonical pointing at a URL that redirects elsewhere, or that returns 404, or that carries a noindex, sends contradictory instructions and gets discounted.

Cross-domain canonicals

A canonical can point at another domain. That is the correct mechanism when you syndicate an article to a partner site or a news aggregator: the copy on their domain declares your URL as canonical, so the search rankings accrue to your original rather than to their republication.

It is also what makes canonicals dangerous. Nothing stops a page from nominating a URL on a host it has no relationship with, and nothing about the syntax makes an accidental cross-domain canonical look wrong. This is where the staging failure comes from.

The staging canonical failure

Most frameworks and content management systems build the canonical by concatenating a configured base URL with the current path. That base URL lives in an environment variable, a database option row or a config file, and it is different in every environment. When the staging value reaches production, every page on the live site declares that the real version lives at https://staging.example.com/....

What follows is quiet and slow. The live pages keep returning 200 and keep serving the right content. But each of them is telling Google that the authoritative copy is somewhere else, and that somewhere else is either unreachable, password-protected or noindexed. Pages start dropping out of results one recrawl at a time, and because there is no error to alert on, the first signal is usually a traffic graph a week later. The repair is covered in fixing a canonical that points to staging.

Canonical, redirect or noindex

The three get used interchangeably and they are not interchangeable:

• 301 redirect when the duplicate should not be reachable at all. The strongest signal available, and the right answer for a retired URL or a domain move.
• rel=canonical when both URLs must stay reachable but only one should rank. Parameters, print views, syndicated copies, filtered listings.
• noindex when the page must stay reachable and must not rank, and there is no equivalent page to consolidate into. Internal search results, thank-you pages, account areas.

Do not stack them. A canonical on a noindexed page is contradictory, since you are asking for consolidation into a page and simultaneously asking for that relationship to be ignored.

Verify what you actually serve

Reading the template is not verification, because edge workers, plugins and server-side logic all inject canonicals that never appear in your repository. Read the response instead: curl -s https://example.com/ | grep -i 'rel="canonical"'. To check the whole site rather than one page, the free site crawl tool reports a canonical status per URL, marking the pages where it is missing and the pages where it points somewhere other than the page itself. Watching those pages for the day the value changes is the job of a website monitoring service.