Query strings are a factory for URLs you never published
A query string is part of the address, not a note attached to it. Change one character and you have published a different URL, and your site will happily serve it, link to it and let it be indexed.
The short answer
Every distinct query string is a distinct URL to a crawler, so one page with five optional parameters can present as dozens of addresses holding the same content. Sorting and filtering parameters multiply; tracking parameters duplicate; a session identifier in the URL is the worst case, because it generates a unique address per visitor.
Every distinct query string is a distinct page
This is the mechanical fact the whole check rests on, and it is easy to nod at and then forget. /shop, /shop?sort=price, /shop?sort=price&page=1 and /shop?page=1&sort=price are four addresses. The last two differ only in the order of the parameters and are still two URLs, because nothing normalises them.
Which means the arithmetic gets away from you quickly. Three filters with ten values each, combinable, plus two sort orders and a page number: that is tens of thousands of addresses generated by a page that shows a few hundred products. Every one of them is crawlable if something links to it, and most of them show overlapping subsets of the same items.
The consequence is not a penalty. It is attention: a crawler spending its requests on filter combinations is not spending them on your product pages, and the pages it does index are chosen from a set you did not curate. That is the same argument the duplication guide makes about causes, seen from the parameter end.
Which parameters are safe, and which multiply
Parameters are not equally dangerous, and treating them the same is why the usual advice feels unusable.
parameter changes content? what to do
--------------- ---------------- ----------------------------------------
?page=3 yes index it. it is a real, distinct page
?id=8812 yes index it, though a path would be nicer
?q=carbon yes, per visitor noindex. an unbounded set of results
?sort=price no canonical to the unsorted URL
?colour=red sometimes index if people search for it,
canonical if it is one of forty facets
?utm_source=x no canonical, and never link to it yourself
?sessionid=... no remove entirely. see the next section
?ref=nav no remove. this is tracking you addedThe middle row is the only genuinely difficult one, and the test is demand rather than technology: if people search for red knives, the filtered view is a page worth having and probably worth a real path. If nobody searches for a combination, it does not need to be indexable and often should not be linkable either.
On the search parameter, the fourth row: an internal search results page generates a new URL for every query anybody types, forever. Those pages are thin by construction and unbounded in number, which is the one case where noindex is unambiguously right.
A session identifier in a URL is the worst case
If your site puts a session or a token in the query string, every visitor is handed a unique address for the same page. Each of those addresses can be shared, bookmarked, linked from a forum and crawled, and each one is a duplicate of the page with an identifier nobody else can use.
It produces failures that look unrelated to each other. Duplicate URLs in numbers proportional to your traffic. Analytics that cannot group anything. Shared links that expose one person's session to whoever clicks. And a canonical tag that, if it is generated from the request URL, faithfully names the parameterised address on every one of them.
The fix is architectural: keep session state in a cookie, and if a URL-based token is genuinely unavoidable, keep it out of anything a crawler can reach. This is one of the few findings in an audit that is a security consideration before it is an SEO one, and it should be treated with that priority.
The related habit worth dropping: internal tracking parameters.
Appending ?ref=nav or ?src=sidebar to your own links, to see which module people click, means your own navigation is generating duplicate URLs at every position on every page. The information is available in your analytics through other means, and the cost is a multiplication of your entire URL space by the number of places you link to a page from.
Campaign parameters on external links are different and fine. The problem is specifically putting them on links inside your own site, where the crawler will follow every one.
Inspect the query string on one URL
This reads the query string of the URL you enter and classifies what it finds: campaign parameters, session identifiers, or something functional. That tells you what this address is, which is one instance of a problem that lives across your whole site.
No signup required. Each free search audits one page, paste any URL to see it in action.
Does this affect AI search?
Yes, and the effect is concentrated in citations. When something quotes your page it cites the URL it fetched, and if that URL carries a campaign parameter from wherever it was discovered, the citation carries the parameter too. It circulates that way, gets clicked, and your analytics attribute a stream of visits to a newsletter from two years ago.
There is a deduplication effect as well. A corpus builder deciding whether two fetches are the same document uses the URL as a first-order key, and a page reachable at forty parameterised addresses looks like forty documents until something collapses them. What decides whether they collapse cleanly is the canonical on the page and whether your other self-declarations agree with it.
The budget argument applies too, more sharply than for search. An agent following a couple of links from a filter interface can spend its entire visit inside your facet space and never reach a product.
Why hygiene rates above readability
Its neighbour, the check about whether a path is readable, is a Refinement. This one is Important, and the difference is that a query string does something. An ugly path is a page nobody enjoys reading the address of. An uncontrolled parameter space is thousands of URLs competing for crawl attention, splitting signals and duplicating your content.
It stops short of Critical because nothing is excluded. Your real pages are still crawled, still indexed and still ranked. What you lose is efficiency and control over which variant represents you, and both of those are recoverable with a canonical tag and a link audit.
The rating would rise on a site with session identifiers in its URLs, and this is worth saying plainly because the chip cannot distinguish. That specific case is a defect with a security dimension, generating duplicates in proportion to traffic, and it should be treated as more urgent than the rest of this check.
Finding the parameters your own site hands out
Your own links are the strongest statement about which URLs you want crawled, so start there rather than with your analytics.
# every parameter name your own pages link to, counted
for page in / /shop /guides /blog; do
curl -s "https://example.com$page"
done \
| grep -o 'href="[^"]*?[^"]*"' \
| sed 's/.*?//;s/"$//' \
| tr '&' '\n' \
| cut -d= -f1 \
| sort | uniq -c | sort -rn
# and the canonical on a parameterised URL: does it name the clean one?
curl -s 'https://example.com/shop?sort=price&utm_source=news' \
| grep -o 'rel="canonical" href="[^"]*"'The first command usually surprises people. Parameters you thought were only used in campaigns turn up in your own navigation, and a tracking parameter appearing in that output means every page of your site is linking to duplicates of itself.
If the second command returns the parameterised address rather than the clean one, your canonical is being generated from the request. That is the single most common implementation error in this area, and it means the tag is confirming the duplicate instead of resolving it.
Questions this check raises
- Do URL parameters cause duplicate content?
- They cause duplicate URLs, which is the mechanism behind most duplicate content findings. The page body is identical and the address is not, so the crawler has several candidates and no stated preference. A self-referencing canonical on the clean URL resolves it without removing the parameters people actually use.
- Are UTM parameters harmful for SEO?
- Not inherently, but every shared link carrying one creates another indexable address for the same page. Canonicals handle it, which is why a self-referencing canonical matters most on pages that get campaign traffic. The real risk is a site that generates internal links with tracking parameters attached, because then the duplicates come from you.
- Why are session IDs in URLs so bad?
- Because they give every visitor, including every crawler pass, a unique address for the same content. There is no upper bound on the number of URLs generated, no two crawls agree on what the site contains, and no canonical set can be maintained by hand. Session state belongs in a cookie.