Canonical URLs: telling search engines which URL counts

Two addresses can point at one page. example.com/about and example.com/about/ read as the same page to a visitor. A search engine treats them as two, and splits everything this page has earned, links, trust, relevance, between them instead of counting it once.

A single tag fixes this. Most sites never add it.

This is the same blind spot the rest of SEO lives in. Nothing breaks. Nothing warns. The page just ranks a little worse than it should, for a reason invisible from the browser.

What the canonical tag actually does

A canonical tag sits in the head of a page and tells search engines which URL among several near-identical ones should be treated as the real one. Think of it as the page pointing at itself, or at another URL, and saying: this is the version that counts, index this one, send the ranking signals here.

<link rel="canonical" href="https://example.com/about/" />

It is a hint, not a command. Search engines can override it if the signals disagree strongly enough. But in the ordinary case, trailing slashes, tracking parameters, http versus https, it works exactly as intended. Every duplicate collapses into one entry in the index, and the ranking signals that were scattered across every version now belong to a single address.

Where the duplicates come from

Nobody sits down and decides to publish the same page under five different names. It happens as a side effect of how the web works.

Trailing slash. A URL with the slash and the same URL without it are two different addresses as far as a search engine is concerned, even though a browser treats them the same.
```
https://example.com/about
https://example.com/about/
```
Protocol. The http and https versions of a page are separate unless something forces a redirect from one to the other.
```
http://example.com/about/
https://example.com/about/
```
www versus the bare domain. These resolve to different hosts unless one is redirected to the other.
```
https://www.example.com/about/
https://example.com/about/
```
Tracking parameters. A link shared from an email or a social post often carries a query string for analytics. Every distinct parameter creates what looks, to a crawler, like a new page.
```
https://example.com/about/
https://example.com/about/?utm_source=newsletter
```
Separate mobile or print versions. A page served at its own URL for print or for older mobile browsers duplicates the same content under a different address.
```
https://example.com/about/
https://example.com/about/print
```

Getting it right

The safest default is for every page to point its canonical tag at its own clean URL, no parameters, no trailing inconsistency, just the one address that should show up in search results. Pages further down a paginated list should point at themselves, not at page one, since the second page of results is not a duplicate of the first. And a page reached through a filter or a sort order should point back at the unfiltered version underneath it, since the content is the same either way.

How it goes wrong

A canonical tag pointing at the wrong place does more damage than no tag at all. It actively tells search engines to consolidate signals onto an address that was never meant to receive them.

Pointing at the wrong URL. A templating system that builds the canonical from a slug or an ID can drift out of sync with the page it actually sits on, and the tag ends up disagreeing with reality.
```

<link rel="canonical" href="https://example.com/" />
```
Pointing at a page that redirects. If the canonical URL itself sends a visitor somewhere else, search engines may ignore the tag entirely rather than follow the chain.
```

<link rel="canonical" href="https://example.com/old-about/" />
```
Pointing at a page marked not to be indexed. Telling a search engine to consolidate here, while also telling it not to index here, is a contradiction it has to resolve on its own.
```
<link rel="canonical" href="https://example.com/about/" />
<meta name="robots" content="noindex" />
```
No tag at all. Left with no signal, a search engine picks one of the duplicates itself, and it will not always pick the one that was intended.
```

```
A relative address instead of a full one. Some crawlers resolve a partial URL incorrectly. The safe version is always the complete address, protocol included.
```

<link rel="canonical" href="/about" />


<link rel="canonical" href="https://example.com/about/" />
```

More than one canonical tag on the page. Only one is valid. When two are present, most search engines ignore both rather than guess which was intended.

<!-- Wrong: two canonical tags in the same head -->
<link rel="canonical" href="https://example.com/about/" />
<link rel="canonical" href="https://example.com/about-us/" />

<!-- Right: exactly one -->
<link rel="canonical" href="https://example.com/about/" />

Why this stays invisible so long

Nothing checks whether a canonical tag points somewhere sensible. A page can render perfectly, the tag can be present and well-formed, and the address inside it can still be wrong, pointing at a staging URL, a page that no longer exists, or simply the wrong page, and none of it produces an error anywhere in the process of shipping the site.

The place this finally surfaces is Google Search Console, under the report for pages excluded because of a duplicate without a user-selected canonical. By the time it shows up there, the ranking signal has already been diluted for as long as the mistake existed, which is often longer than anyone would guess from looking at the site itself.