URL parameters are not inherently harmful. Problems begin when temporary, unstable, duplicative, or user-relative parameter states become persistent crawlable URLs without a consistent generation, linking, normalization, canonical, and response policy.
- Classify each parameter by what it changes before choosing an SEO control.
- Stable content-identity and pagination parameters behave differently from tracking, sorting, or session parameters.
- Temporary parameters should not become permanent internal-link inventory.
- Equivalent query states should normalize to one consistent URL representation.
01
Definition
A query parameter is a key-value instruction appended to a URL after a question mark.
https://www.example.com/shoes?color=green&sort=priceIn that example:
/shoesis the path.colorandsortare parameter keys.greenandpriceare values.&separates parameter pairs.
The presence of a question mark does not make a URL bad, duplicated, or unindexable. A parameter can identify a genuine product variant, a page in a paginated series, a filtered collection, a temporary session, a tracking label, or a purely visual preference. Those states should not receive one universal treatment.
Google recommends ordinary ?key=value parameters, warns against repeatedly using the same key, and advises sites not to create internal links containing temporary values such as session IDs, tracking codes, changing times, or unstable user-relative states. Designing a URL structure for ecommerce websites[1]
The correct first question is:
What does this parameter change?
02
Mechanism
Classify each parameter into a functional family.
Identity parameters
An identity parameter selects a durable resource.
/product?sku=1234If the value consistently identifies one product and the URL is the intended public address, the parameter can be crawlable and indexable. It should receive stable internal links, a self-canonical, and sitemap treatment consistent with other canonical pages.
The weakness is not the parameter syntax. The weakness appears when the same product also resolves through several uncoordinated paths, case variants, IDs, names, and tracking states.
Pagination parameters
Pagination exposes a sequence of inventory.
/articles?page=3A valid page should have a unique URL when it exposes content not available on page one. Keep page numbering stable. Decide whether page one consistently includes or excludes ?page=1, then use the same choice in links and canonicals.
Impossible page numbers should not silently return the first page with a 200 response. Return an honest not-found response when the requested inventory does not exist.
Filtering parameters
A filter changes the included records.
/shoes?color=greenSome filtered collections may satisfy durable search intent. Others exist only to help the current user narrow inventory. The faceted-navigation guide explains how to divide those classes and prevent combinatorial URL growth.
Sorting parameters
Sorting usually changes order rather than membership.
/shoes?sort=priceA price-sorted page may be useful to a visitor without deserving a separate search result. The usual starting policy is to let users apply the sort while avoiding a separate indexable URL inventory. The exact mechanism depends on application design and crawl requirements.
Tracking parameters
Tracking parameters attribute a visit or campaign.
/article?utm_source=newsletterThey ordinarily do not change the page. Do not generate tracked internal links throughout the site. When external campaigns create tracked URLs, preserve analytics attribution while keeping the clean page as the preferred canonical.
Session parameters
Session IDs identify a user interaction rather than public content.
/cart?sid=abc123Do not place session IDs in durable internal links or public sitemaps. A canonical is not enough to make an uncontrolled session-URL inventory good architecture. Use cookies, server-side sessions, or another appropriate state mechanism.
Presentation parameters
Presentation parameters change layout.
/catalog?view=gridGrid and list views usually represent one resource. Preserve the user preference without creating competing indexable pages unless the presentation genuinely changes the primary content and serves an independent public purpose.
User-relative parameters
A value such as nearby=true or time=last-week can change meaning by user, time, or location.
Google specifically warns against internally linking temporary and user-relative values. Prefer durable states such as an explicit location slug or stable date archive when the content deserves a public URL. Designing a URL structure for ecommerce websites[1]
03
Examples
| Parameter class | Changes primary content? | Stable? | Default starting policy |
|---|---|---|---|
| Identity | Yes | Yes | Crawl and index when it is the preferred public URL |
| Pagination | Yes | Yes | Crawl valid pages and keep numbering consistent |
| Filtering | Sometimes | Usually | Selectively expose valuable combinations |
| Sorting | Usually no | Yes | User-accessible, usually not independently indexed |
| Tracking | No | Often | Avoid in internal links and canonicalize cleanly |
| Session | No public content | No | Prevent persistent URL generation |
| Presentation | Usually no | Yes | Preserve preference without separate search inventory |
| User-relative | Sometimes | Often no | Replace with explicit durable states where needed |
| Internal search | User-generated | Variable | Constrain crawling and indexing aggressively |
Normalize equivalent states before they spread.
Potential equivalents include:
/catalog?color=green&size=small
/catalog?size=small&color=green
/catalog?color=green&size=small&
/catalog?color=Green&size=small
/catalog?color=green&size=small&view=gridA normalization policy should define:
- Parameter order
- Parameter-name case
- Value case
- Empty values
- Default values
- Duplicate keys
- Repeated values
- Encoding
- Trailing delimiters
- Unknown parameters
Do not normalize blindly. Parameter order can be meaningful to some applications, and repeated keys can encode arrays. The application contract must define equivalence before the SEO layer declares it.
The durable fix occurs where the site generates URLs and links. Cleaning millions of parameter variants after they have entered crawlers, sitemaps, analytics, and backlinks is possible, but it is the expensive version of deciding what the parameter meant in the first place.
Use the downloadable URL parameter audit template to record each parameter’s purpose and intended behavior.
For each parameter, answer:
- Does it change the primary content?
- Is the resulting state stable?
- Does it serve independent search intent?
- Should the site create crawlable links to it?
- Should it appear in a sitemap?
- Should it self-canonicalize?
- Should it canonicalize to another URL?
- Should it redirect?
- Should invalid values return
404? - Should crawler access be prevented?
04
Boundaries
Canonical consistency matters, but canonicals do not replace URL discipline.
Google recommends using the preferred URL consistently in internal links, sitemaps, and canonical annotations. It also describes rel="canonical" as a strong signal rather than an absolute directive. How to specify a canonical URL with rel=canonical and other methods[2]
Internal links should expose actual resolvable destinations. Google’s link guidance says it can generally crawl anchors containing an href, while script-only link imitations are less dependable. SEO link best practices for Google[3]
Avoid these patterns:
- Tracking values in sitewide navigation
- Session IDs in public URLs
- Timestamps that create a new URL every request
- Two parameter orders for the same state
- Duplicate keys with ambiguous meaning
- Empty parameters that return the same content
- Invalid filters that return
200 - Parameter URLs listed in the sitemap while canonicalizing elsewhere
- Internally linked redirects that strip parameters
- Fragments used to represent content that needs an independent URL
- Search-result pages generated for unlimited arbitrary queries
Use the URL-control decision guide when deciding whether to redirect, canonicalize, noindex, block crawling, authenticate, or return an error. Use the Google-chose-different-canonical guide when Google rejects the declared preference, and the duplicate-without-user-selected-canonical guide when no clear preference exists.
References
Sources behind this record
- Designing a URL structure for ecommerce websites — Google (accessed July 29, 2026)
- How to specify a canonical URL with rel=canonical and other methods — Google (accessed July 29, 2026)
- SEO link best practices for Google — Google (accessed July 29, 2026)
Corrections
Correction history
No corrections recorded.
To report an error, use the public corrections path.
The correct treatment depends on whether a parameter materially changes the resource, remains stable, serves independent user intent, and can be supported as a durable public URL.