URL carrying more than three query parameters

This check counts the query parameters on the page's address and reports it when there are more than three.

Parameters are counted by NAME. A multi-select filter that sends ?colour=red&colour=blue is using one parameter, not two, and is counted once. Names are compared exactly, because ?a=1&A=2 really does reach two different addresses.

For a URL to pass this check:

• It carries at most three distinct query parameter names.

Example: https://example.com/shop?page=2 passes. https://example.com/shop?colour=red&size=l&sort=price&page=2&view=grid does not: five parameters.

Each additional parameter multiplies the number of addresses the same content can be reached at. Four independent parameters with five values each describe over six hundred URLs for one page of products.

• Crawl budget: search engines spend their allowance on parameter combinations instead of on pages you want indexed.
• Duplicate content: the same items appear at many addresses, splitting the ranking signals that should have accumulated on one.
• Reporting: analytics and Search Console report each combination separately, so the page's real performance is scattered across dozens of rows.
• Shareability: a five-parameter URL is not one anybody copies by hand.

This is reported as a suggestion and never deducts from the health score. The harm parameters actually do to indexing is already scored by "Parameterised URLs left indexable" -- charging for the count as well would be the same fact twice. What this row adds is the reading: an address with this many knobs is one nobody can type, share or reason about.

1. Move state that is not content out of the URL. Display preferences -- grid or list, items per page, a chosen currency -- belong in a cookie or in local storage, not in an address that search engines will crawl.

2. Turn important filters into paths. A filter that people search for is a page: /shop/running-shoes/red reads better and indexes better than /shop?category=running-shoes&colour=red.

3. Give parameterised pages a clean canonical. Where the parameters must stay, point the canonical at the unparameterised address so the signals consolidate.

4. Strip tracking parameters from internal links and sitemaps. Campaign parameters belong only on the links you publish elsewhere.

5. Collapse related parameters. Several parameters that are always sent together can usually be expressed as one.

6. Check the value order is stable. ?a=1&b=2 and ?b=2&a=1 are two addresses to a crawler; emit them in a fixed order.

Example 1: A page with one parameter

Scenario: Page two of a paginated listing.

Passes because: one parameter name.

https://example.com/shop/running-shoes?page=2

Example 2: A multi-select filter

Scenario: A colour facet with three values selected.

Passes because: the repeated key is one parameter, not three.

https://example.com/shop?colour=red&colour=blue&colour=green

Example 3: Filters, sorting, paging and a view preference

Scenario: A faceted listing that puts every piece of UI state in the URL.

Fails because: five distinct parameter names.

https://example.com/shop?colour=red&size=l&sort=price&page=2&view=grid

Corrected version: the two filters people actually search for become a path, the sort and view preferences move into a cookie, and paging stays.

https://example.com/shop/running-shoes/red?page=2

1. Parses the page's final address. After redirects, PixyScan reads the query string of the URL the page was actually served at.

2. Lists the parameter names. Every name in the query string is collected. Repeated values of the same name count once, because a multi-select filter sending the same key three times is still one parameter.

3. Compares names exactly. colour and Colour are two different parameters, because a server may treat them differently and they reach two distinct URLs.

4. Applies the limit of three. Three parameters pass; four or more is reported.

5. Reports the count and the names. The finding lists exactly which parameters it found, so the ones that can be removed are visible on the row.

A parameter with no value (?a&b&c&d) still counts. An empty query string (?) counts as none.

Storage Level

Page Level

Database Table / Prisma Model

audit_issues.details

Stored Fields

Detection Dependencies

• HTTP Response
• The page URL as the crawler fetched it

Note

The evidence is kept on the finding rather than in a per-page table. The urlParameterAudit row records which parameters a page carries for the page report; this check is about how MANY of them there are.