A query string is the portion of a URL that contains key-value pairs providing additional information to the web server or application, appearing after a question mark ? character at the end of the URL path. In https://example.com/search?q=redirect+management&sort=relevance&page=2 the query string is q=redirect+management&sort=relevance&page=2: the entire portion after the ?. Each key-value pair, q=redirect+management, sort=relevance, page=2: is a URL parameter within the query string, with multiple parameters separated by ampersand & characters.

The term query string reflects the original web application context in which it was most prominently used, database query results. Early dynamic web pages would pass search terms and filter criteria to server-side scripts through URL parameters, the string of parameters in the URL was the query specification for the database query the server would execute to generate the page content. The terminology persists even though query strings now serve many purposes beyond database queries.

Query strings are technically distinct from the URL path, the path identifies the base resource while the query string modifies how that resource is served. https://example.com/products is the base resource, the products page. https://example.com/products?sort=price&colour=blue is the same base resource with a query string specifying that it should be displayed sorted by price and filtered to blue products.

For SEO and redirect management query strings are a significant source of complexity, they create URL variants that may or may not represent meaningfully distinct content, consume crawl budget, fragment SEO equity, and require explicit management strategies to handle correctly.

Query string syntax and structure

The query string follows a defined syntax, understanding its structure clarifies how parameters within query strings are parsed and processed.

The question mark delimiter: the ? character marks the boundary between the URL path and the query string. Everything before the ? is the path, everything after is the query string. The ? itself is not part of either the path or the query string, it is the delimiter separating them.

Key-value pairs: query string parameters are expressed as key-value pairs in the format key=value. The key identifies what the parameter controls, sort, colour, page, q. The value specifies the parameter’s current value, price, blue, 2, redirect+management. The = sign separates key from value.

The ampersand separator: multiple parameters within a query string are separated by & characters. ?sort=price&colour=blue&page=2 contains three parameters, sort=price, colour=blue, and page=2. The & separates each key-value pair from the next, it is not included in the key or value itself.

Parameter ordering: the order of parameters within a query string is technically arbitrary, ?sort=price&colour=blue and ?colour=blue&sort=price are semantically equivalent. However from a URL identity perspective they are different strings, and therefore technically different URLs. This parameter ordering variation creates URL duplicate content issues that must be managed through canonicalisation.

URL encoding in query strings: query string values may contain characters that are not permitted in URLs, spaces, special characters, non-ASCII characters. These characters must be URL-encoded: replaced with percent-encoded sequences. A space is encoded as %20 or + in query strings, q=redirect+management encodes the space between redirect and management as +. An accented character like é is encoded as %C3%A9.

Empty parameters: parameters may have empty values, ?sort=&colour=blue: where sort has no value. Empty parameters may be treated as absent parameters by some applications or as having an empty string value by others. Empty parameter handling varies by application implementation.

Query strings vs URL paths

The distinction between query strings and URL paths is fundamental to understanding URL structure and its SEO implications.

Path segments identify base resources: the URL path, /products/blue-widget: identifies which specific resource is being requested. Different paths represent genuinely different resources, /products/blue-widget and /products/red-widget are different products. Path changes require 301 redirects to preserve SEO equity when URLs change.

Query strings modify resource presentation: query strings typically modify how a resource is presented rather than which resource is requested. ?sort=price and ?sort=name on the same path both request the same product listing, the query string specifies how to display it. The resource is the same, the presentation varies.

This distinction, path identifies, query string modifies, is the foundation for clean URL design recommendations. Content that represents genuinely distinct resources should have distinct URL paths. Content that represents the same resource displayed differently should use query string parameters, or better yet clean URL equivalents with proper canonicalisation.

The clean URL alternative to query strings: clean URL conventions increasingly replace query string parameters with path segments for key identifying information. example.com/products/blue/large is a path-based URL specifying colour and size as path segments. example.com/products?colour=blue&size=large achieves the same filtering through query string parameters. The clean URL path-based approach is more readable, more shareable, and provides clearer content hierarchy signals, but requires redirects and comprehensive canonical management when transitioning from query string-based URLs.

Query strings and SEO

Query strings create specific SEO challenges that require systematic management, the same challenges discussed in the URL parameter article but examined specifically through the lens of the query string as a complete URL component.

Query string-generated duplicate content: every unique query string creates a technically distinct URL. example.com/products?sort=price and example.com/products?sort=name are different URLs. example.com/products?sort=price&colour=red and example.com/products?colour=red&sort=price are different URLs, despite containing identical parameters in different order. Multiply the number of parameter keys by the number of possible values for each key and the number of possible query string combinations grows exponentially.

An e-commerce site with sorting, 5 options, colour filtering, 10 options, size filtering, 8 options, price range, 5 ranges, and pagination, 20 pages, generates up to 5 × 10 × 8 × 5 × 20 = 40,000 URL variants for a single category page. Each variant is technically a distinct URL. Without canonicalisation all 40,000 variants may be crawled and indexed independently, a massive crawl budget waste and duplicate content problem.

Search engine treatment of query strings: search engines have developed heuristics for handling query string parameters, identifying which parameters modify content versus which are purely functional, but these heuristics are imperfect. Explicit canonical signals, canonical tags on parameterised pages pointing to the canonical URL, are more reliable than relying on search engine heuristics.

Google Search Console provides URL parameter configuration tools that explicitly inform Googlebot how specific parameters should be handled, whether they change content, which value is default, and whether Googlebot should crawl parameterised variants. This explicit configuration supplements canonical tags in managing query string URL spaces.

Query strings and link juice: backlinks pointing to query string URLs accumulate link juice at the specific parameterised URL rather than at the canonical clean URL. A link to example.com/products?id=4532 does not benefit example.com/products/blue-widget unless either a 301 redirect sends the parameterised URL to the clean URL or a canonical tag on the parameterised page points to the clean URL.

Query strings in different use cases

Different query string use cases have different SEO implications and appropriate management approaches.

E-commerce filtering and sorting: the highest-volume source of SEO-relevant query string complexity. Filter parameters, ?colour=red&size=large&price_min=10&price_max=50: and sort parameters, ?sort=price&order=asc: create extensive URL spaces. Management approaches include canonical tags on all filtered and sorted views pointing to the canonical base category URL, robots.txt blocking of high-volume parameter combinations, and selective indexation of filter combinations that represent genuinely valuable standalone pages, a specific brand + category combination, versus those that are too narrow to be worth indexing independently.

Pagination: ?page=2, ?page=3, ?p=2: pagination parameters identify specific portions of a paginated content set. Pagination is handled differently from filter parameters, paginated pages contain distinct content, different articles, different products, rather than the same content displayed differently. Self-canonicalising paginated pages, each page’s canonical tag points to itself, allows each paginated page to be independently indexed. Rel=prev and rel=next link annotations communicate pagination structure to search engines.

Search queries: ?q=search+term, ?search=term: internal site search result pages generated from user search queries. Internal search results typically contain thin, near-duplicate content, different queries often return the same or overlapping results. These pages are best excluded from indexation, noindex directives or robots.txt blocking, rather than indexed independently. The content value of search result pages is low and the crawl budget cost of indexing them is high.

Session identifiers: ?sessionid=abc123, ?sid=xyz789, ?PHPSESSID=abc: server-side session tracking parameters that identify specific user sessions. Every user session generates a unique URL, effectively infinite URL duplication. Session parameters should be managed through HTTP cookies rather than URL parameters, existing session parameter URLs should be redirected to clean URLs or canonicalised.

Tracking and analytics parameters: ?utm_source=email&utm_medium=newsletter, ?ref=homepage, ?fbclid=abc123: marketing attribution parameters that record traffic source without affecting content. These parameters must remain accessible for analytics attribution but should be canonicalised to the clean URL for SEO. Canonical tags are the appropriate management tool, not redirects, because redirecting tracking parameter URLs can break attribution in some analytics configurations.

A/B testing parameters: ?variant=b, ?test=checkout-v2: parameters that control which version of content is served during A/B testing. A/B testing with URL parameters creates variant content that temporarily coexists with the canonical version. Canonical tags on variant URLs pointing to the canonical URL prevent variant versions from being independently indexed and competing with the primary version.

Query strings in redirect management

Query strings require specific handling in redirect configurations, both when redirecting URLs that contain query strings and when configuring redirect rules that should handle query string variants.

Redirect source URLs with query strings: when a specific query string URL needs to be redirected the redirect rule source should match the exact query string if the redirect is specific to that parameter combination, or match the path regardless of query string if the redirect should apply to all variants of that URL.

A redirect rule for example.com/old-page?param=value matching only that specific URL with that specific parameter value is a narrow rule, other query string variants of /old-page are not redirected by this rule. A redirect rule for example.com/old-page matching the path regardless of query string is a broad rule, all query string variants are redirected.

Redirect management platforms differ in whether they match paths or full URLs including query strings, understanding the platform’s default matching behaviour prevents unexpected redirect outcomes.

Stripping query strings in redirect destinations: redirect destinations should typically be clean canonical URLs without unnecessary query strings. A redirect from old-domain.com/page?utm_source=email should go to new-domain.com/page: not new-domain.com/page?utm_source=email. Carrying tracking parameters through redirects adds unnecessary parameters to the destination URL.

Function-relevant parameters, sort order, filter state, may warrant preservation through redirects if the destination page supports them. A user who was on a sorted product listing may benefit from being redirected to the sorted equivalent at the new URL, new-domain.com/products?sort=price: rather than the unsorted base URL.

Query string parameter normalisation in redirects: redirect platforms may normalise query string parameter ordering, ensuring that ?colour=blue&sort=price and ?sort=price&colour=blue are treated as the same URL for redirect matching purposes. This normalisation prevents duplicate redirect rules for the same conceptual URL with different parameter orderings.

Redirect chains from query strings and clean URLs: a common redirect chain pattern involves query string to clean URL transitions. A legacy query string URL, example.com/products?id=4532: redirects to a clean URL, example.com/products/blue-widget: which then has a canonical tag. The chain is: query string URL → clean URL → canonical (same URL). This is a single-hop redirect followed by a self-canonical, not a true chain, and is correct. A chain would occur if the clean URL itself redirected elsewhere, monitoring redirect destination health prevents this.

Common query string mistakes

Allowing session IDs in URLs: implementing user session tracking through URL parameters rather than cookies. Creates essentially infinite unique URLs, each user session generates a completely unique URL for every page visited. Migrate session management to cookies and redirect or canonicalise existing session parameter URLs.

Not managing tracking parameter canonicalisation: allowing UTM parameters and other tracking parameters to be indexed as separate pages. Google indexes example.com/page?utm_source=email as a separate page from example.com/page: splitting equity across tracking parameter variants. Add canonical tags to all tracking parameter variants pointing to the clean URL.

Inconsistent parameter value formatting: ?colour=blue and ?colour=Blue: treating case-variant parameter values as different without normalisation. Case variants in parameter values create URL duplicates, server-side normalisation of parameter value formatting prevents this.

Missing query string handling in redirect rules: configuring redirects that match paths but not query string variants, or vice versa, leading to some variants being redirected while others return 404 errors or serve old content. Test redirect rules against both parameter-free and parameterised variants of every source URL.

Infinite parameter combinations in sitemaps: including query string URL variants in XML sitemaps. Sitemaps should contain only canonical URLs, never query string variants of canonical pages. Including parameter variants in sitemaps signals to search engines that those variants should be indexed, contradicting canonical tags that point to the clean URL.