Filter addresses use inconsistent separators or ordering

In the reportFacet parameters use non-standard separators or inconsistent ordering, multiplying duplicate URLs

facet_parameter_hygiene · Review item

Short answer

Review the recorded filter spellings. Use ampersands between fields and emit each combination in a consistent order. The ordering check is our duplicate-response policy.

Severity: Low. Review the filter spelling and the duplicate-response evidence before changing useful views.

Why it matters

Google recommends standard separators for crawlable filter URLs. Our ordering predicate detects an observed duplicate response pair.

What to do

  1. Read the original declaration, literal spelling and any recorded ordering pair.
  2. Use ampersands between fields and a consistent parameter order in emitted links. Preserve the intended filter values.
  3. Run a new full audit so the old literals, controls and members are checked.

When to leave it as it is: Keep intentional distinct views when the recorded server main text hides a meaningful browser difference; investigate that difference before normalizing their addresses.

What we read

A filter pattern must be proved from original local GET controls with supported action, names and values. A query keyword or matching text alone does not establish a filter.

We reuse original captured HTML, links, member responses and the same main-content preparation. We do not generate filter combinations or introduce a new sentinel request.

The stable subject uses the rule, origin, exact path and sorted proved filter names. Changing values, representatives or samples does not replace the old member/source obligations. Report examples are limited; comparison debt retains the full original set.

Separator evidence requires literal commas or semicolons between proved filter fields in a captured anchor. Encoded delimiters, punctuation inside values and bracketed names do not qualify.

Ordering requires two discovered addresses with the same unique key/value tokens in different order, direct 200 responses and exactly matching nonempty main-text hashes. Repeated names, ambiguous encodings, redirects and missing peers remain unknown.

Example & evidence

Illustrative example, not a live audit.

Supported controls: color=red, size=s
Literal separator: /catalog?color=red,size=s
Ordering pair: /catalog?color=red&size=s
               /catalog?size=s&color=red

Confirm & check again

Check for yourself: Inspect the original filter controls and the literal links in page source. Request both ordering variants and compare their own-address responses and main content.

Check again: Full audit — Run a new full audit. It must read every retained old member, original control and literal source. Corrected literals and genuinely distinct or gone ordering variants can resolve their obligations. A new clean sample, lost markup, robots restriction or an unread old member cannot prove a fix.

Limits & sources

This is a static, bounded observation. It does not prove every combination is duplicated, measure crawl-budget waste or require query sorting as a Google rule.

Confidence: High Literal separators require proved field boundaries; ordering requires exact captured main-text equality.

Sources

  • Google, Managing crawling of faceted navigation URLs — Recommends ampersands as field separators. Its logical-order guidance concerns path filters; the query-order duplicate comparison is our policy. Checked 13 October 2026.

Editorial review: 2 November 2026