Canonical Tags and URL Parameters

What a canonical does to a parameter URL, and what it does not

A canonical tag consolidates duplicate parameter URLs into one indexed version, but it does not stop Google from crawling them. For tracking codes and a few sort orders that is usually all a site needs; for faceted navigation, where filter combinations multiply into thousands or millions of addresses, Google's own guidance rates robots.txt rules and URL fragments as more effective than rel="canonical".

URL parameters (also called query parameters or the query string) are the ?key=value&key2=value2 portion of an address. Each distinct string is a distinct URL to a crawler. Google names the output of sorting and filtering on category pages as one of the routine sources of duplicate content, next to protocol, device and regional variants.

The canonical states which member of a duplicate cluster the site prefers. Google describes rel="canonical" as "a strong signal" and the declared canonical as "a hint, not a rule," which means Google may agree or may pick another URL from the cluster. When it does agree, links and other signals pointing at the variants are credited to the preferred URL.

What the canonical cannot do is reach back in time to the crawl decision. Googlebot has to fetch a URL to read the tag on it, so every new parameter combination still costs a request. Google's faceted navigation documentation says a canonical "may, over time, decrease the crawl volume" of the non-canonical versions, and in the same passage calls it less effective in the long run than the alternatives.

Matching the parameter type to the control

The right control depends on whether the content changes, whether outside links land on the URL, and whether anyone searches for the filtered state.

The table exposes the most common error: using a single control for every parameter on the site. A robots.txt rule broad enough to catch sort and filter strings will also catch the utm_ landing pages that paid campaigns point at, and the equity from those links is then stranded on URLs Google is not allowed to read.

Faceted navigation is a crawl problem before an indexing problem

Faceted navigation is the filter panel on a category or listing page (color, size, price, brand), sometimes called faceted search, filtered navigation or, in Magento and Adobe Commerce, layered navigation. Its URLs look new to a crawler, and a crawler cannot tell whether a new URL is useful without fetching it. Googlebot ends up spending time on filter permutations instead of new products.

Per Search Engine Land's account of a 2026 Search Off the Record episode, faceted navigation made up half of the crawling issues in Google's 2025 year-end review. That figure is a podcast remark reported secondhand, so read it as direction, not measurement.

The Search Central page on managing faceted URLs, published in December 2024 and revised since, lists four ways to keep facets from being crawled when they do not need to appear in Search:

1. robots.txt disallow on the filter parameters: stops the fetch outright.
2. URL fragments for client-side filtering: Google generally ignores the part after #, so filtered states never become separate URLs.
3. rel="canonical": consolidates, and may reduce crawl gradually.
4. rel="nofollow" on filter links: only works if every link to the URL carries it.

The order is the point. Canonical sits third, and the page does not recommend noindex for facets at all. A noindex page still has to be requested before it can be dropped, which is exactly the crawl cost faceted sites are trying to avoid.

Platform defaults rarely solve this. Adobe Commerce emits a self-referencing canonical on a filtered layered-navigation URL rather than pointing it at the clean category. WooCommerce adds no canonical, noindex or robots.txt handling to its filter URLs by default, leaving that to an SEO plugin or custom code. On Shopify, ?sort_by and filter strings that escape the theme's canonical logic are a routine audit finding.

Implementation: canonical, robots.txt and status codes

For a tracked landing URL, the page served at the parameterized address carries an absolute canonical to the clean URL, in the <head>, and nowhere else declares a different one:

<!-- served at https://www.example.com/dresses/green-dress.html?utm_source=newsletter -->
<link rel="canonical" href="https://www.example.com/dresses/green-dress.html">

For facets with no search value, Google's example robots.txt blocks the filter keys while leaving one deliberate state open:

user-agent: Googlebot
disallow: /*?*products=
disallow: /*?*color=
disallow: /*?*size=
allow: /*?products=all$

Test patterns like these against real URLs from the server logs before shipping them. A wildcard that matches color= will also match any other key that ends in those letters.

If facet URLs must stay crawlable, Google asks for hygiene that keeps the URL space finite:

• Separate pairs with &, not commas, semicolons or brackets. (Google's URL structure page does allow commas between multiple values of one key; the rule is about the separator between pairs.)
• Keep filters in a consistent order and reject duplicate filters in path-based URLs.
• Return a 404 for a combination with no results, served at the URL that was requested, not a redirect to a shared "not found" page and not a 200 page saying nothing matched (a soft 404).
• Keep session state in cookies rather than the URL.

The retired Search Console tool and Bing's surviving equivalent

Older guides tell readers to declare parameters in Search Console. That setting is gone: the URL Parameters tool went offline on April 26, 2022, per Search Engine Roundtable, after Google said (as quoted by Search Engine Land) that only about 1% of configured settings were useful. Existing settings stopped being used; nothing replaced them. Asked in 2024 whether the tool might return, Illyes answered "In theory yes. in practice no."

Bing kept its version. Its 2012 blog post pitched URL normalization as "better than canonical" because the crawler would then skip URLs carrying the ignored parameters, apart from occasional tests. The current Bing Webmaster API exposes it through AddQueryParameter, GetQueryParameters and EnableDisableQueryParameter, with a cap on how many a site may register. The contrast is instructive: a canonical tag was never a crawl control at either engine.

Signal combinations that cancel each other

Most parameter problems seen in audits are not missing canonicals. They are two controls applied to the same URL that defeat each other.

• Canonical plus robots.txt disallow. A blocked URL is never fetched, so its canonical and any noindex are never read. The URL can still be indexed from links, shown without a description.
• robots.txt used as removal. Disallowing already-indexed parameter URLs freezes them in the index. Let Google recrawl a canonical or noindex first, then block once they have dropped.
• noindex used as a crawl saver. It trims the index but not the requests; Google's crawl budget guide calls this wasted crawling time.
• Partial nofollow. One followed link from a sitemap, breadcrumb or footer undoes nofollow on every other link.
• Tracking parameters on internal links. John Mueller has called canonical-tagged UTM internal links "mixed signals": the link says one URL, the tag says another.
• A fragment as the canonical target. Google says not to point a canonical at a # URL, and not to use robots.txt or noindex for canonicalization within one site.

Measuring the parameter footprint

• Server logs are the ground truth for how many Googlebot requests hit parameterized URLs, broken down by key. The Crawl Stats report in Search Console gives a coarser view.
• A crawler such as Screaming Frog or Sitebulb, run with parameters allowed, shows how large the URL space is. Compare the canonical column with the indexability column: parameter URLs that are indexable and self-canonical are the leak.
• URL Inspection on a sample parameter URL shows the user-declared canonical next to the Google-selected canonical.
• The Page indexing report groups the results into statuses such as "Alternate page with proper canonical tag" (the expected state for a canonicalized tracking URL) and "Indexed, though blocked by robots.txt" (the signature of the blocked-canonical conflict).
• Bing: GetQueryParameters lists the normalization parameters already registered.

A quick check with curl -s "https://www.example.com/page?utm_source=x" | grep -i canonical confirms the tag is in the raw HTML rather than injected later by JavaScript.

When a canonical alone is enough

Google aims its crawl budget guidance at large sites (a million or more unique pages changing weekly) and medium sites (ten thousand or more changing daily), plus sites with many URLs stuck in "Discovered - currently not indexed." A catalog of a few thousand pages with a handful of sort keys is outside that frame. There, a correct canonical on each parameter URL is usually the complete fix, and robots.txt rules are more likely to cause damage, by blocking a campaign URL or a demanded facet, than to save meaningful crawl.

The calculation flips when logs show Googlebot spending most of its requests on filter permutations,. At that point a canonical is the wrong primary tool, and the order of work is: build indexable landing pages for the facets people search for, move the rest to fragments or robots.txt, and keep the canonical as the backstop for whatever still gets fetched.

Frequently asked questions