Why does my product page appear three times in Google?

What does canonicalizing URL parameters mean exactly

Suppose you sell shoes. Someone arrives at your site via an advertisement: your-shop.com/shoes?utm_source=facebook. Someone else sorts by price: your-shop.com/shoes?sort=low-high. Yet another person filters by size: your-shop.com/shoes?size=42. For the visitor this is all the same page with different variations. For Google, without intervention, this is three or more separate pages.

Canonicalizing means you tell Google: these are all variants, but the real, counting version is your-shop.com/shoes — without additions. That clean address is what we call the canonical URL. So you give one clear answer to the question of which version should appear in the search results.

This is not a matter of hiding or blocking something. The variants are allowed to exist and work for visitors who filter or sort. You simply tell search engines: count all value and authority to that one clean version, not to the ten parameter variants alongside it.

It resembles what happens with pagination, as we explain under pagination. There too there are multiple URLs that overlap strongly in content. The difference is that parameters are often more random: sorting and tracking add nothing to the content, whereas page numbers sometimes do.

How do you know if this applies to you

The quickest check: search Google Search Console for your own domain name with a site search, for example site:your-shop.com/shoes. If multiple variants appear with question marks and parameters in them, there is a good chance that this is not set up correctly. You can also simply browse through your site, turn on filters and sorting options and see what happens in the address bar.

In Search Console you can look under Pages at the reason why pages are not indexed. If it says something like duplicate content, Google chose a different canonical URL than the user, then this is often exactly your problem. It is one of the clearest signals this report gives.

Also check the source code of a filtered page, or ask someone to do that for you. There should be a line that refers to the clean URL as the canonical version. If that line is missing, or points to the parameter version itself, then there is work to be done.

You also get an indication through your analytics: if you see dozens of URL variants of what is essentially one page, each with a small amount of traffic, then that traffic has become fragmented across copies instead of being bundled on the main page.

What it costs if this is not in order

The biggest risk is wasted attention from Google on your site. Search engines spend a limited amount of time and capacity on crawling pages per site, also known as crawl budget. If Google spends that time on a hundred variations of the same shoe page, there is less left for new or important pages elsewhere on your site.

Additionally, you dilute your own relevance. If link value and signals of authority become spread across ten URL variants instead of concentrated on one page, no single variant is strong enough to rank well. You are essentially competing against yourself in the search results.

There is also a real risk that Google itself will choose a canonical version, and not always the version you would prefer. It could be a parameter version with an ugly URL, or a page that is not your preferred landing page for that search query. You then lose control over what people see and click on exactly.

AI assistants that summarize the web face the same problem, but more acutely. A language model that encounters three slightly different versions of the same product page can pick up confusing or contradictory information — for example, a different price due to an old cache of a sorting variant. Clarity about which version is correct therefore helps more broadly than just for Google.

What needs to happen to solve this

The core is simple: every variant of a page — with tracking, sorting, or filters in the URL — must indicate that the clean version is the real one. This is an instruction you set up once correctly per page type, not something you do manually for each page. Think of a fixed rule for all product pages, a different fixed rule for all category pages.

This belongs in a broader overview of what pages you have and how they behave, as we discuss in an indexation matrix per page type. There you determine per type of page, and thus also per type of parameter, what the intention is: may it exist, should it canonicalize, or should it not be included in the index at all.

Some parameters deserve a different approach than canonicalization alone. Internal search results, for example, where someone searches on your own site and that produces a separate URL, you can often better exclude directly from indexing, as detailed in internal search result pages on noindex. Canonicalization and exclusion are two different tools for different situations.

After implementing the change, allow a few weeks to pass and check again in Search Console whether the duplicate variants disappear from the issue report. This does not happen overnight: Google must revisit the pages and process the new instruction. Patience and repeated checks are part of this process.

How this relates to other technical basics

Canonicalization does not stand alone. If your robots.txt file already blocks parts of the site, as discussed in checkpoint 1.1 on robots.txt and checkpoint 1.2, this can interfere with the functioning of your canonical instructions. A page that is blocked cannot be visited by Google anyway to read the canonical instruction.

Also, poorly configured 404 handling affects this topic. If a deleted parameter version does not redirect neatly but delivers a confusing page without the correct status code, we are talking about a soft 404, explained in soft 404's. The same applies to poor custom error pages, see a helpful 404 page. All these points touch each other: it is always about providing clarity to Google about what a page actually is and means.

Finally: if your site relies heavily on JavaScript to display content, as discussed in core content accessible without JavaScript, it can already be difficult for Google to see the basic content, let alone the canonical reference that is sometimes added to it dynamically. A technically stable foundation makes canonicalization truly reliable.