Many filter addresses share the same main text in our sample
facet_url_space_explosion · Review item
We found at least 100 permitted addresses for a filter pattern. The first 20 addresses, chosen before comparing their content, contain few distinct main texts. Review whether those addresses need to be discoverable. This is a sample, not proof that every filtered page is a duplicate.
Severity: Medium. Review the filter pattern before changing it: a useful filtered page may deserve its own address.
Why it matters
Google warns that large sets of filter addresses can consume server resources and slow discovery of useful pages.
What to do
- Read the recorded filter declaration, discovered addresses and captured sample. Decide which filtered views need to be discoverable.
- Remove unnecessary links or change the filter generator so it does not keep exposing unwanted combinations. If those addresses should not be read, apply an appropriate robots.txt restriction and test it against useful pages too.
- Run a new full audit. Adding a canonical or noindex tag alone does not close this problem.
When to leave it as it is: Leave the review item if these are useful views with intentionally similar text. Compare the actual items or rendered results before blocking them.
What we read
We reuse captured HTML, original links, local GET filter controls, the full captured sitemap set and a separately captured robots.txt. We count addresses actually discovered and permitted; we do not generate possible filter combinations.
For one matching filter pattern, N is the number of permitted discovered addresses, S is the usable captured sample and M is its number of distinct main-text hashes. The first 20 sorted members are selected before their hashes are read. A finding requires N ≥ 100, S ≥ 20, M ≥ 1, N ≥ 10 × M and S ≥ 10 × M.
The affected addresses are the captured sample. The discovered count can include addresses whose bodies were not read. Missing or ambiguous early members cannot be skipped to choose a later sample.
Example & evidence
Illustrative filter pattern, not a live audit.
/catalog?color=c000
/catalog?color=c001
…
/catalog?color=c099An original GET filter control declares these values. All 100 addresses were discovered and allowed by the recorded robots.txt. The first 20 usable responses share one main-text hash: N = 100, S = 20, M = 1. The pattern is kept for review; the other 80 response bodies are not claimed to have been compared.
A later full audit must independently compare the original pattern and retained evidence. A smaller sample or a missing control page does not demonstrate a fix.
Confirm & check again
Check for yourself: Open the sampled filter views and compare what visitors actually see. Check which filter addresses your links and sitemap expose, then test the intended robots.txt policy.
Check again: Full audit — Run a new full audit. It compares the original captured sample, controls, discovery sources and retained membership. Complete evidence that the old membership ceased, or explicit robots.txt denial of all old members, can establish a change. Missing old sources, sitemap roots, policy or comparison coverage leave the problem unresolved. A new positive pattern cannot replace unresolved evidence from an earlier audit.
Limits & sources
This is a static main-text heuristic with a high false-positive risk. It does not run JavaScript, compare every discovered body, measure Google’s crawl budget or prove an indexing loss. A partial audit may retain a proved positive, but missing coverage cannot prove a clean comparison.
Confidence: Medium The counts and sample hashes are recorded observations; deciding whether similar filtered views are useful requires review.
Sources
- Google, Managing crawling of faceted navigation URLs — Explains the resource cost of filter addresses and ways to manage their discovery and crawling. The sample thresholds are our policy, not Google limits. Checked 8 October 2026.
Editorial review: 2 November 2026