How parameter handling works
A parameter is the part of a URL that follows the question mark — a name, an equals sign and a value, with further pairs joined by ampersands. Sites produce them constantly: to record where a visitor came from, to hold a filter or a sort order, to carry a search phrase, to number a page of results, or to identify a session. Every one of them creates an address that is technically different from the clean page it decorates.
Search engines treat a different address as a different page until something tells them otherwise. Parameter handling is the set of decisions that does the telling — which variants may be crawled, which may be indexed, and which should collapse back onto one address. The working controls are the canonical tag, robots.txt patterns that keep crawlers out of combinations nobody needs, a noindex instruction where a variant must stay reachable but out of the index, and the discipline of only ever linking internally to clean URLs. Google retired the URL Parameters tool that once sat in Search Console, so the levers that remain are on your own server.
Why parameter handling matters
Left alone, parameters multiply. A shop with a handful of filters that can be combined and reordered generates far more addresses than it has products, and a crawler will walk into all of them. Effort that should have gone to new stock goes to sorted, filtered near-copies instead, and genuinely new pages are found late.
The second cost is dilution. When links, shares and rankings land on several versions of one page, no single version carries the full weight. Reporting suffers too: analytics splits one page into a long list of near-identical rows, and the page that is actually earning the business looks weaker than it is.
Common mistakes with parameter handling
The most common is blocking parameter URLs in robots.txt and expecting them to consolidate. A blocked URL cannot be read, so the canonical tag inside it is never seen and any links pointing at it are wasted. Blocking is for crawl control; canonicals are for consolidation, and the two are not interchangeable.
The rest are quieter. Tracking parameters left on internal links, so every menu click creates a new address. Parameters written in a different order on different templates, doubling the variants again. A canonical on a filtered page that points to itself rather than to the clean category. And filtered combinations left sitting in the XML sitemap, which invites exactly the crawling you were trying to prevent.
How to act on it
Start by listing what exists. Crawl the site, pull the URLs your server has logged, and group them by parameter name so you can see which are tracking, which change the content and which change nothing at all. Anything that does not change what a visitor reads should point its canonical at the clean URL.
Then decide parameter by parameter. Filters worth ranking for deserve a clean, static URL of their own; the rest stay crawlable but out of the index, or sit behind a rule that stops crawlers combining them endlessly. Keep internal links, canonicals and the sitemap on clean addresses only, then re-crawl to confirm the variants have stopped appearing. On a large catalogue this is slow, unglamorous technical SEO work, and it overlaps closely with faceted navigation and crawl budget.