Canonical URLs: one page, one address

Why the same page lives at a dozen addresses, what rel=canonical can and cannot do about it, and the canonical mistakes that quietly undo your own SEO.

SEO · Published: 29 September 2026 · 6 min read · Ольга Мирошник

To you, a page is a piece of content. To a search engine, a page is a URL. If the same content answers at ten URLs, the crawler sees ten pages, has to work out that they are copies, and then has to guess which one you meant. Canonicalisation is the job of making that guess unnecessary.

How one page gets many addresses

Nobody publishes duplicates deliberately. The server just accepts more variants than you think:

• Host. www.example.com and example.com both answer.
• Protocol. http:// still serves the site instead of redirecting to https://.
• Trailing slash. /pricing and /pricing/ return the same document.
• Case. /Blog/Post and /blog/post both work on a case-insensitive server.
• Index files. /docs/ and /docs/index.html are the same file.
• Query parameters. ?utm_source=newsletter, ?sort=price, ?sessionid=… — every combination is a new URL with identical or near-identical content.
• Pagination. /blog?page=2 is a real, different page — but it is often wrongly treated as a duplicate of page one.

Multiply these together and a site with a hundred pages can expose thousands of addresses. Links, shares and crawl attention get split between them.

One host, enforced with a 301

The cheapest duplicates to remove are the ones at the host and protocol level, and the right tool is a permanent redirect, not a tag. Pick one form — say https://example.com — and send every other combination there in a single hop:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Two details matter. The redirect must be a 301 (or 308), not a 302: a temporary redirect tells search engines the old address is still the real one. And it should be one hop: http://www going to https://www and then to https:// works, but wastes a round trip on every first visit. Do the same for trailing slashes: choose one style and redirect the other.

rel=canonical is a hint

For duplicates you cannot redirect — tracking parameters, sorting, print versions — you declare the preferred address in the page head:

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

This is a hint, not a directive. Google weighs it together with redirects, internal links, the sitemap and hreflang, and may pick a different canonical if those signals disagree. Your job is to make every signal point at the same URL.

Good practice:

• Self-referencing canonicals. Every indexable page names itself. That protects it from parameter variants you never anticipated.
• Absolute URLs. A relative href="/pricing/" is valid, but it resolves against whatever host and protocol the copy was served from, which is exactly the duplicate you were trying to fix.
• Pagination canonicalises to itself. Page 2 names page 2, not page 1; otherwise everything linked only from page 2 becomes harder to discover.

Non-HTML files use a header. A PDF has no head, so send it in the response instead:

Link: <https://example.com/guide.pdf>; rel="canonical"

Mistakes that do real damage

Canonical to the home page everywhere. A template sets the same canonical on every page. You have just told the search engine that your whole site is a duplicate of /.

Canonical to a page that is not there. The target redirects, returns 404, or carries noindex. The signals contradict each other, and the search engine usually ignores the hint.

Conflicts with hreflang and the sitemap. The sitemap lists /pricing, the canonical says /pricing/, hreflang points to a third variant. Each of these should list exactly the canonical URL.

JavaScript changes it. The server HTML says one thing, a client-side router or SEO plugin rewrites the tag after load. Crawlers may see either version. Render the correct canonical on the server and leave it alone.

Several canonical tags. Two plugins each add one. With conflicting values, the hint is usually ignored altogether.

How to check

Fetch the raw HTML and look at what the server actually sends, not what DevTools shows after scripts have run:

curl -s https://example.com/pricing/ | grep -i 'rel="canonical"'
curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)'

The second command should show a single 301 to your chosen host. A SiteScan report covers part of this automatically: it flags pages with no canonical link, pages whose canonical names a different address, sites where both the www and non-www hosts answer 200 instead of one redirecting permanently, and host redirects that use a temporary 302.

Check-list

1. One host and one protocol; every other combination returns a single 301.
2. One trailing-slash style, the other redirected.
3. Every indexable page has an absolute, self-referencing canonical.
4. Canonical targets return 200, are indexable and do not redirect.
5. Sitemap, hreflang and internal links use exactly the canonical URLs.
6. Paginated pages canonicalise to themselves.
7. PDFs and other files send a Link header where needed.
8. The canonical in server HTML matches the one after JavaScript runs.