Query Strings Creating Infinite Pages

How forty products become thousands of addresses

A listing page with filters appends its choices to the address: a category, a price range, a colour, a sort order, a page number.

Each combination is a distinct address, and combinations multiply rather than add.

Six filters with a handful of options each produce more addresses than most small shops have products, and almost all of them show a subset of the same items.

None of that is wrong. Filters are useful and customers want them. The problem is only what happens when those addresses are treated as pages worth crawling and indexing.

Two different sources

Worth separating, since they need different handling.

Functional parameters change what the page shows: filters, sorting, pagination, search terms. Those are generated by your own site as people use it.

Tracking parameters change nothing about the page and exist to record where a visitor came from, appended by advertising platforms, email campaigns, and social links.

The first creates near-duplicate pages. The second creates exact duplicates of the same page under many addresses.

Both are resolved mostly by the same measure, and the tracking case is the one that quietly affects small brochure sites with no filters at all.

What it costs

• Crawl effort spent on variations instead of real pages.
• Near-duplicate pages competing with the main listing.
• Analytics splitting one page across many rows.
• Thin pages indexed showing two or three products.
• Server load from crawling combinations nobody visits.

The third affects everybody, including sites with no filters, because a page reached from an advertisement appears as a separate row from the same page reached organically.

The canonical does most of the work

The single measure that resolves the majority of this.

Every filtered or parameterised view should carry a canonical tag declaring the clean address of the underlying page.

So a listing filtered by two options declares the plain listing address, and a page reached with tracking parameters declares itself without them.

Most platforms do the second automatically and are less consistent about the first.

Check by opening a filtered view on your own site and looking at what its canonical says: if it declares the filtered address, every combination is presenting itself as a distinct page.

That check takes a minute and tells you whether you have a problem at all.

Do not link to filtered views

The behavioural half, and it matters more than people expect.

Crawlers follow links. A filtered address that is never linked from anywhere is largely invisible, whatever exists in theory.

Problems appear when filtered views are linked deliberately: from a navigation menu, from a category page, or from a sidebar offering shortcuts.

Those links advertise the combinations and invite them to be crawled.

Where a filtered view is genuinely valuable enough to link to, such as a popular category, the better answer is a real page at a clean address with its own content, rather than a filter with a link pointing at it.

A worked example

A small shop with about forty products had filters for category, price, size, and sort order.

Search Console reported many thousands of addresses discovered and a small fraction indexed, which they read as a problem with the site.

Checking one filtered view showed its canonical declaring the filtered address rather than the plain listing, so every combination was presenting itself as an independent page.

Their sidebar also linked to a dozen filter combinations as shortcuts, which is how the crawler had found so many.

They corrected the canonical behaviour, replaced the sidebar shortcuts with three real category pages, and left the filters working normally for customers.

The discovered count fell over a couple of months and their actual product pages were crawled noticeably more often, which was the point.

Keep them out of the sitemap

A small check that reinforces everything above.

A sitemap should list clean addresses only, and some generators include parameterised versions if they have been visited.

Listing a filtered address tells search engines you consider it a page worth indexing, which contradicts the canonical you just set.

Open the sitemap, search it for a question mark, and remove anything that appears.

The same applies to internal links used in your own advertising: sending traffic to a tracked address is fine, and it should not be the address you link from your own navigation.

Analytics needs the same treatment

The other half of the split, which is a reporting problem rather than a search one.

Tracking parameters produce separate rows for the same page, so a page's true total is spread across an organic row, an email row, and several advertising rows.

Most analytics tools can exclude specified parameters from the page address while still recording the source, which is the arrangement you want.

Set that up once, listing the parameters you actually use plus the common advertising ones.

Otherwise the annual review of which pages produced anything is being read from a table where the best page appears four times.

The counter-case

This is a shop problem and a large-site problem more than a small business problem.

A brochure site with no filters, no search, and no product listings has nothing here except tracking parameters, which the platform almost certainly already handles.

Search engines have also become considerably better at recognising parameter patterns and ignoring redundant combinations without being told.

There is a genuine risk in blocking parameters aggressively, since blocking a pattern can prevent crawling of pages that matter, and it is easy to be broader than intended.

Check the canonical on one filtered view. If it is right, this subject is closed for you.

The check

1. Open a filtered view and read its canonical.
2. Confirm it declares the clean address.
3. Look for links to filter combinations.
4. Replace valuable filters with real category pages.
5. Search your sitemap for a question mark.
6. Exclude tracking parameters in analytics.
7. Avoid blocking patterns unless you are certain.

Step one settles whether any of this applies to you, and for most small sites the answer is that it does not.

How the tag itself works is covered in canonical tags pointing at the wrong page.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.