Canonical URLs: How to Pick the Address That Gets Indexed
Several URLs can load one page on your site. See how to choose the one you want in search results, what to do with the rest, and when to leave it alone.
/ On this page8 sections
Several addresses can load the same page on your site, and a search engine treats each one as a separate page until it decides otherwise.
The canonical URL is the address it settles on. You get a vote.
Here is how to cast it: which address to pick, what to do with each of the others, and the places where the obvious answer turns out to be the wrong one.
What Makes One Address the Canonical One
A canonical URL is the single address a search engine treats as the real home of a piece of content, chosen from all the addresses that serve it.
Google's documentation puts the process first and the noun second. Canonicalization is the work of selecting a representative URL; the canonical URL is whichever one came out of it.
Say a page about desk lamps is reachable at five addresses:
https://example.com/desk-lampshttps://example.com/desk-lamps/http://example.com/desk-lampshttps://www.example.com/desk-lampshttps://example.com/desk-lamps?utm_source=newsletter
One page, five doors. A crawler coming through each door cannot know they all open on the same room until it has been through all five and compared what it found.
Which is why the choice is worth making at all. Whatever the copies have earned, a link from somebody's newsletter, a share, a mention, lands on the address that gets chosen rather than being split four ways.
The Word Does Two Jobs
The word canonical gets used two ways, and the two readings do not sit comfortably together.
A page is canonical: it is the one chosen to stand for the group. A page has a canonical declaration: a line naming which address it thinks should be chosen.
The declaration matters most on a page that is not the canonical one. The copy sitting at the tracking address is the one announcing that the clean address is the original.
Only the declaration is yours. Everything below follows from that gap.
Why a Site Has More Addresses Than Pages
Nobody sets out to publish one page at five addresses. It happens because several different systems each get to change what a URL looks like.
Google's canonicalization documentation gives five examples of what causes it, and they are worth sorting by whether anybody meant them to exist.
Three are deliberate. Region variants, where the same content sits at a US address and a UK one. Device variants, where a separate mobile address serves the same page. And site functions, which is Google's phrase for what sorting and filtering do to a category page.
One is a leftover. Protocol variants, where the insecure version of the site still answers, usually because a migration finished everywhere except the redirect.
One is an accident. Google's own example is a demo version of the site left reachable by crawlers.
Which of Those You Can Actually Decide
The first two are answered somewhere else entirely.
A US page and a UK one, or a desktop page and a mobile one, are not addresses you choose between. They are pairs you declare a relationship for.
What follows is about the rest, and about the kinds Google's five examples do not name.
That sorting matters more than the list does.
A deliberate address has a job and somebody will notice if it stops working. A leftover has no job and nobody will.
And the framing to drop before going further: this is not a penalty situation. Google states plainly that some duplicate content on a site is normal and is not a violation of its spam policies.
What Google Does When You Say Nothing
Google picks one for you. Knowing how it picks is worth the detour, because every lever you have works by feeding that same process.
When it indexes a page it works out the primary content, and where several pages look alike it clusters them.
It then chooses the one that, on the signals it has, is "objectively the most complete and useful for search users" and marks that as the canonical.
The chosen page does more than appear in results. Google's documentation adds that the canonical page will be crawled most regularly, and duplicates less often, to reduce the crawling load on your site.
The Three Ways to Vote, in Order of Weight
You can put your preference in front of that process. Google publishes the three ways to do it in a deliberate order, strongest first:
- Redirects, described as a strong signal that the target of the redirect should become canonical.
- A `rel="canonical"` declaration, a strong signal that the address it names should become canonical.
- Inclusion in a sitemap, a weak signal that helps the URLs listed become canonical.
Underneath those sits a preference Google applies without being asked: it prefers HTTPS over the equivalent HTTP page.
The methods stack. Google says using two or more increases the chance your preferred address is the one that appears.
None of It Is a Command
Every signal above is advisory.
Google's wording is that you can indicate your preference, but it may choose a different page, "for various reasons. That is, indicating a canonical preference is a hint, not a rule."
One further point sits at the end of Google's canonicalization page and is worth carrying. A search result usually points at the canonical page, unless one of the duplicates suits that particular searcher better.
Its own example: the result will probably point at the mobile page for someone on a phone, even when the desktop page is the canonical one.
So the canonical address is the one whose signals get consolidated. It is not a promise about what appears on screen.
Settle the Address Rules Once, Not Page by Page
Four of the most common duplicate patterns are not page level problems at all.
Secure or insecure, www or bare, trailing slash or none, upper case or lower: those are four answers about your whole site, and each one is given once.
Settle them and a large share of the duplicate addresses a normal site produces stop being generated. What survives is genuinely per page, and there is much less of it than people expect.
Secure, and Only Secure
Pick HTTPS, the secure form of the protocol a browser uses to fetch a page. Google leans the same way by default and prefers HTTPS pages over equivalent HTTP pages as canonical.
That preference is conditional, and the conditions are the useful part.
Google names four things that break it:
- An invalid certificate on the secure page
- Insecure dependencies other than images
- A secure page that redirects users to or through an insecure one
- A secure page declaring the insecure one as its canonical
Two of those cost more than a lost preference.
Google's guidance says a bad certificate or an HTTPS to HTTP redirect makes it prefer HTTP "very strongly", and adds that turning on HSTS, the header that forces browsers to use the secure version, cannot override that.
So the secure version has to be clean, not merely present.
One Hostname, and Do Not Agonize
www.example.com and example.com are two different hosts to a crawler, and it does not matter in the slightest which one survives.
What matters is that you keep one.
Redirect the other to it, permanently, and stop thinking about it. The redirect is what declares your preference, and it is a stronger declaration than anything you could put on the page.
The Slash and the Capital Letters
A trailing slash makes a different address. So does a capital letter in the path, on most servers.
Choose a convention for each and apply it in your templates, then redirect the other form. If your content system already emits one of them consistently, that is your convention and the decision is made for you.
On the desk lamp page above, those four answers leave https://example.com/desk-lamps and dissolve three of the other four into it. The fifth, the one carrying the tracking parameter, survives all four and is what the next section is about.
Then write the four answers down somewhere a person joining next year will find them.
The cost of skipping that is not a ranking problem. It is that the same argument gets had again next year by somebody who was not there the first time.
Use this chart — embed code and citation
<a href="https://neerajjivnani.com/blog/canonical-urls/"><img src="https://neerajjivnani.com/infographics/canonical-urls/settled-once-or-left-to-decide.png" alt="One page shown at five addresses, sorted into the two layers the decision actually has. The left panel, headed settled once for the whole site, carries three of them. The address ending in a trailing slash is answered by one slash convention applied in your templates, with the other form redirected. The address on the insecure protocol is answered by picking the secure form, which is the way Google leans by default since it prefers the secure page over the equivalent insecure one. The address carrying the www prefix is answered by keeping one hostname, redirecting the other to it permanently and not thinking about it again. A note beneath them records that the fourth rule, one case convention for the path, has no example in this particular set and is given the same way. The right panel, highlighted in orange and headed left to decide address by address, carries the one address that survives all of it: the same page with a newsletter tracking parameter appended, which is unaffected because the protocol, the host and the slash are already right. Under it sits the single question that settles what happens to it, whether a person still needs to reach this address and whether it was ever meant to be found, and beneath that the address being kept, which is the shortest one you would be content to see in a search result. A band at the foot carries the reason the split is worth making first: a crawler coming through each door cannot know they all open on the same room until it has been through all five and compared what it found, and four answers given once close three of those doors without any of it having to be revisited page by page." width="1200"></a>
<p>Chart: <a href="https://neerajjivnani.com/blog/canonical-urls/">Neeraj Jivnani</a></p>Neeraj Jivnani, "Canonical URLs: How to Pick the Address That Gets Indexed", neerajjivnani.com, https://neerajjivnani.com/blog/canonical-urls/Free to republish with a link back to this page.
Use this chart — embed code and citation
<a href="https://neerajjivnani.com/blog/canonical-urls/"><img src="https://neerajjivnani.com/infographics/canonical-urls/the-secure-version-has-to-be-clean.png" alt="The four conditions Google names as breaking its default preference for the secure version of a page, sorted by what the reversal actually costs. The panel on the left, highlighted in orange and headed Google prefers the insecure page very strongly, carries two of them. An invalid certificate on the secure page is the first, and it is not a tie broken the other way: Google's guidance says a bad certificate makes it prefer the insecure protocol very strongly. A secure page that redirects users to or through an insecure one is the second, named beside the bad certificate and carrying the same weight in Google's own wording. A box beneath the pair records that turning on HSTS, the header that forces browsers to use the secure version, cannot override either of them. The panel on the right, headed the preference is lost and nothing worse, carries the other two, and the split between the panels is our reading of which two Google names in its very strongly sentence rather than a grading Google publishes. Insecure dependencies other than images means anything the page loads over the insecure protocol, images aside. A secure page declaring the insecure one as its canonical is the last, and it is a preference you asked for, since the declaration is a strong signal pointing the wrong way. A band at the foot says what this changes about the protocol decision: picking the secure form is one of four answers you give once for the whole site, and it is the one that can be half done without looking half done, because the insecure version still answering is usually a migration that finished everywhere except the redirect." width="1200"></a>
<p>Chart: <a href="https://neerajjivnani.com/blog/canonical-urls/">Neeraj Jivnani</a></p>Neeraj Jivnani, "Canonical URLs: How to Pick the Address That Gets Indexed", neerajjivnani.com, https://neerajjivnani.com/blog/canonical-urls/Free to republish with a link back to this page.
Then Decide What Each Leftover Address Is For
Whatever survives the site wide rules is a real decision, and one question settles nearly all of them.
Does a person still need to reach this address, and was it ever meant to be found?
Three answers follow from it.
Nobody needs it: retire it. Redirect the address permanently to the one you kept. This is the strongest signal available and it also removes the problem rather than managing it.
Somebody needs it, and it is genuinely the same page: keep it and consolidate. A tracking link in a newsletter, a printable copy, a link somebody has bookmarked. The address stays live and declares the clean one as canonical.
Somebody needs it, and it was never meant to be found: keep it and keep it out. A sorted view of a list, a filtered view, an internal search result. These serve visitors and were never pages anybody would want returned by a search engine.
The third case is the one that gets handled wrongly, because it looks exactly like the second.
What is left after the four answers
List the addresses that load one of your pages, and mark the one you would keep. Each of the others is read against it here, in your browser. Nothing is sent anywhere.
The addresses that load this page
The shortest address you would be content to see in a search result is usually the one to keep.
Your pile, split in two
3 addresses are answered by 3 of the four rules you give once for the whole site, so they are not a decision about this page at all. 1 is left to decide, one address at a time.
Settle these rules once and the same addresses stop being generated on every other page of the site: trailing slash, protocol, hostname.
https://example.com/desk-lamps
The address you keep. Everything else on the site points at this one, starting with whatever you link from your own navigation.
https://example.com/desk-lamps/
Settled once, for the whole site
- Trailing slash. One slash convention, applied in your templates. Redirect the other form.
http://example.com/desk-lamps
Settled once, for the whole site
- Protocol. Secure, and only secure. Redirect the insecure form to it.
https://www.example.com/desk-lamps
Settled once, for the whole site
- Hostname. One hostname. Keep either one, redirect the other to it permanently, and stop thinking about it.
https://example.com/desk-lamps?utm_source=newsletter
Left to decide
It carries ?utm_source=newsletter, which survives every one of the four answers.
Does a person still need to reach this address?
One kind of address never reaches the question at all, because it is not a duplicate. Page two of a list holds items that are nowhere on page one, and gets a canonical naming itself.
Sorted and Filtered Lists Are the Exception
A category page ordered by price is not a copy of the category page. It is one arrangement of the same items, built on request, and a handful of filters can produce thousands of arrangements.
Google's guidance for these is not a canonical declaration. Its ecommerce documentation says to "block unwanted URLs from being indexed with the noindex robots meta tag or discourage crawling of particular URL patterns with a robots.txt file".
Which looks like a reversal, because elsewhere Google warns off both of those tools.
Its guidance on specifying a canonical rules out robots.txt for this work entirely, and rules out noindex too, on the grounds that it does not merely settle a preference, it takes the page out of search.
The two only conflict if you read them as answering one question. They answer two.
Deciding which of several pages you want indexed is one job. Deciding that a machine generated view was never a page you wanted indexed is another, and noindex is the honest answer to the second.
So the instrument follows from the question, and the question comes first.
Use this chart — embed code and citation
<a href="https://neerajjivnani.com/blog/canonical-urls/"><img src="https://neerajjivnani.com/infographics/canonical-urls/two-questions-two-instruments.png" alt="A two-part readout resolving what looks like a reversal in Google's own guidance, since its page on specifying a canonical rules out robots.txt for this work entirely and rules out noindex too, while its ecommerce documentation names those same two tools, either one, as what to reach for on sorted and filtered list variants. Question one is which of several pages you want indexed. Its instrument is a permanent redirect where nobody needs the address any more, and a canonical declaration where the address has to stay live. Ruled out by Google for that question, on its page about specifying a canonical, are robots.txt, entirely, and noindex, on the grounds that it does not merely settle a preference but takes the page out of search. Between the two questions sits the pair that gets handled wrongly: a tracking link somebody clicked in a newsletter and a category page ordered by price are both extra addresses serving content you already publish, they look exactly alike in a list of addresses, and the whole of the difference is that one of them was meant to be found and the other never was. Question two, highlighted in orange, is whether this was a page you ever wanted indexed at all. Its instrument is the noindex robots meta tag or a robots.txt rule discouraging the crawling of that URL pattern, both of which Google's ecommerce documentation names for sorted and filtered list variants. Not a canonical declaration, because a category page ordered by price is one arrangement of the same items built on request and a handful of filters can produce thousands of arrangements. A band at the foot gives the order that resolves it: the instrument follows from the question, and the question comes first." width="1200"></a>
<p>Chart: <a href="https://neerajjivnani.com/blog/canonical-urls/">Neeraj Jivnani</a></p>Neeraj Jivnani, "Canonical URLs: How to Pick the Address That Gets Indexed", neerajjivnani.com, https://neerajjivnani.com/blog/canonical-urls/Free to republish with a link back to this page.
What to Do About Tracking Parameters
A tracking parameter makes a new address, and there is no longer any setting that tells Google to disregard one. Declare the clean address on every page and never point at a parameterized copy from a sitemap or a menu.
?utm_source=newsletter, ?ref=twitter, a session identifier your platform appends: each produces a page a crawler can find and nobody ever linked to on purpose.
There used to be a direct control. Search Console carried a URL Parameters tool that let you tell Google how to treat a given parameter, and it is gone.
Google retired it in March 2022, and its announcement carries a measurement worth keeping: "only about 1% of the parameter configurations currently specified in the URL Parameters tool are useful for crawling".
The same post says that from then on "Google's crawlers will learn how to deal with URL parameters automatically".
So the levers are the ordinary ones. A clean address declared on every page covers parameterized copies of that page without anybody doing anything, because the copy serves your page and carries your declaration with it.
And where a parameter generates pages nobody was ever meant to find, in bulk, the fallback Google named in the same post is a robots.txt rule, which is the second question again.
None of that is as satisfying as a switch. It is what exists.
A Paginated List Is the One That Trips People
Give every page of a list its own canonical, naming itself. Not the first page.
This is the extra address that most reliably gets treated as a duplicate when it is not one. Page 2 of a list holds items that are nowhere on page 1.
Google's ecommerce guidance is explicit: "Don't use the first page of a paginated sequence as the canonical page. Instead, give each page its own canonical URL."
The old alternative is closed off on the same page. Google used rel="next" and rel="prev" to understand page relationships in the past, and its documentation now says "Google no longer uses these tags", while noting other search engines may.
So give each page a unique address, link the sequence in order, and let each page name itself.
That is also the shape of the mistake in general. When a declaration is ignored, nothing is lost; when one is acted on across pages that were never copies, a page you wanted disappears from results.
Four Answers and One Question
The choice has two pieces, and they are decided in completely different ways.
Settle four things for the whole site, once: secure only, one hostname, one slash convention, one case convention. That removes most of the duplicate addresses a normal site produces, and none of it has to be revisited page by page.
For whatever is left, ask the one question.
Nobody needs this address, so it goes.
Somebody needs it and it is the same page, so it stays and points home.
Somebody needs it and it was never meant to be found, so it stays and stays out of the index.
Check again in a few weeks using Search Console's URL Inspection tool, which reports the address Google selected beside the one you declared.
If those two differ, it is rarely the declaration that is wrong. It is your own site saying two things at once, and the address your links and your sitemap point at is the one that won.