What is a GET Parameter?

A GET parameter, also called a query parameter, is a key-value pair appended to a URL after a question mark. The syntax is ?key1=value1&key2=value2, where the & character separates multiple pairs. The server receives that string along with the request and decides what to do with it: filter, sort, or display a specific page.

The part of the URL before the question mark, the domain and path, identifies the underlying resource. Parameters do not change that resource, they only control how it is presented. That is why shop.com/shoes?color=blue and shop.com/shoes?color=red point to the same shoe catalog, just with a different filter applied.

Values can contain spaces, symbols or accented characters, but a URL only allows a limited character set. Everything else gets encoded through percent-encoding, the same mechanism that turns a space into %20 and relies on the ASCII Code to represent each character.

Multiple parameters can combine freely as long as each pair stays separated by &. A real online store often produces a URL like shop.com/shoes?color=blue&size=42&brand=nike. Reserved characters such as ?, & or = cannot appear unencoded inside a value, or the structure of the query breaks apart.

Context matters here as much as the technical mechanics. A search form or a product filter fits GET, because the result deserves its own shareable URL. A login or payment form fits POST, because the data should not be visible or stored in the browser history.

When a user applies a filter, moves to another page, or clicks a tracking link, the browser builds the URL with the corresponding parameters and sends it to the server as a GET request. The server reads the query string, interprets it according to the application logic, and returns a response, almost always the same HTML template with different data.

Four uses come up most often. Filtering (?color=blue&size=m) to narrow down a catalog. Sorting (?sort=price) to change a list's ordering criterion. Pagination (?page=2) to split long result sets. And tracking, with UTM parameters (?utm_source=newsletter&utm_medium=email) as the best-known example, letting Web Analytics tools identify where a visit came from.

An older, now abandoned practice was passing the session identifier as a GET parameter (?sessionid=abc123) to recognize a user across pages. That approach was dropped because the identifier stays visible in browser history, server logs, and any link shared by mistake. Today that job almost always falls to a session cookie, which is harder to expose accidentally.

In a real catalog, shoppers usually combine several filters at once, for example ?color=blue&size=42&brand=nike&sort=price, and the server applies every condition together before returning the list. The more combinations are possible, the more versions of the same page exist, which connects directly to the duplicate content problem covered below.

<!-- Same page, but with parameters in a different order: to the server these are two different URLs -->
https://zds.es/en/what-is-a-title-tag?utm_source=newsletter&sort=date
https://zds.es/en/what-is-a-title-tag?sort=date&utm_source=newsletter

The most common SEO problem caused by GET parameters is duplicate content. If ?color=blue&size=m and ?size=m&color=blue show the same product listing, Google sees two different URLs for the same content. Multiplied across faceted navigation on a large catalog, this can generate thousands of URLs competing with each other instead of reinforcing one.

That URL surplus also wastes crawl budget: if Googlebot spends time working through parameter combinations that add no new content, less budget remains to find pages that are genuinely different, an issue that gets worse on large sites handled as part of Technical SEO.

Google shut down the Search Console parameter tool in April 2022, which had previously let site owners manually specify which parameters to ignore. Since then, management relies on three mechanisms: the canonical tag pointing to the preferred version, selective robots.txt blocks for low-value parameter patterns, and consistent internal linking that always uses the same parameter order.

This decision reaches beyond individual pages. Faceted navigation with ten filters can theoretically produce thousands of combinations, even though only a handful ever get visited. Without clear rules, in the worst case Google ends up indexing exactly the variants nobody searches for, instead of the pages that could actually bring traffic.

• Point the canonical tag of every parameter variant to the URL without parameters or to the preferred combination.
• Keep the same parameter order in internal links at all times, so you do not create new variants by accident.
• Block parameter patterns that generate no distinct content in robots.txt, such as session or redundant sorting parameters.
• Use cookies instead of GET parameters to store session identifiers or sensitive data.
• Encode values with spaces, accents or symbols correctly before publishing the link.
• Check crawl reports for how many parameter URLs Google indexes and compare that against the ones that actually bring traffic.

• Still expecting to find the parameter tool in Search Console: it was shut down in April 2022 and has no direct replacement.
• Not canonicalizing campaign URLs with UTM parameters, leaving them competing with the original page in the index.
• Publishing links with unencoded characters, which break the parameter and sometimes trigger a 400 Error for a malformed request.
• Shortening a URL with tracking parameters without checking that the URL Shortener preserves or redirects those parameters correctly.
• Letting faceted navigation generate endless parameter combinations, each one crawlable, with no limit or blocking rule.