Faceted Navigation Auditor

Free, no signup. Paste category parameter URLs to classify filters, sort, pagination, tracking, and unknown keys. The audit stays in your browser and never crawls beyond the supplied list.

Built by Patrick Stox

No evidence bundle loaded.

Runs entirely in your browser — nothing you paste is uploaded or stored. Anonymous run-level outcome counters may be used for aggregate research; URLs, domains, IPs, and identifiers are never included, and no statistic is released below 100 runs.

Feedback
Report a bug

Found something broken in Faceted Navigation Auditor? Let us know what happened — this goes straight to a private triage queue, not a public list.

What will be sent 
 No tool inputs, uploads, pasted source, complete results, query parameters, or URL fragments are attached automatically. You can edit or remove the selected passage above. Browser and anti-abuse metadata is processed for spam prevention. 
  
 
  
 
 
  
 
 
  
 
Sample report Built-in deterministic example
…/shoes?color=blue&size=10: filter, filter
…/shoes?sort=price&page=2: sort, pagination
…/shoes?utm_source=newsletter: tracking
Advice: Review canonical/noindex rules for crawlable filter combinations.
 
 
 
How to use it
  1. Paste up to 150 absolute HTTP(S) category URLs, one per line.
  2. Select Audit facets, or load the built-in deterministic example.
  3. Review each parameter type and any over-parameterized row.
  4. Use server logs, crawl data, index coverage, and search demand before deciding which combinations should be indexable.
 
 
      
 
    
What the results mean
  • filter — common product/category attributes such as color, size, brand, price, or category.
  • sort — sort, order, or view controls.
  • pagination — page, p, or offset keys.
  • tracking — common campaign/click identifiers.
  • unknown — no rule matched; inspect its purpose manually.
  • trap — a row has more than five parameters, or the supplied list crosses the shared calendar/high-cardinality pattern thresholds.
 
How it works
The browser parses each supplied URL with the native URL API, classifies every query-key name through explicit regular-expression rules, and applies row-level and grouped-pattern warnings. Calendar groups over 60 unique URLs and other groups over 100 are labeled with the same deterministic caps used by the crawl frontier. If any row includes a recognized filter, it returns the canonical/noindex review reminder. No requests leave the browser.
 
Features
  • Up to 150 supplied URLs.
  • Five transparent parameter classes with common material, gender, rating, availability, and price-range facets.
  • Optional no-new-crawl evidence join from a shared audit bundle.
  • Safe DOM output for user-supplied URLs.
  • Built-in example and actionable validation errors.
  • Entirely client-side processing.
 
Limitations
Parameter names do not reveal content value or indexability. The tool does not crawl links, test robots/canonicals/noindex, read logs, or observe Google. Pattern counts apply only to the pasted list; the row warning and grouped thresholds can flag legitimate URLs or miss traps outside the sample.
 
Frequently asked questions
What is faceted navigation?
Faceted navigationFaceted navigation (faceted search, product filtering) lets visitors refine a list of products or content by attribute — price, color, size, brand, rating. The SEO problem: each filter combination can spawn a distinct crawlable URL, turning a small catalog into millions of near-duplicate pages that waste crawl budget and dilute ranking signals. lets users filter or sort a listing by attributes such as color, size, brand, or price. Each combination can create a distinct parameter URL.
What parameters does the auditor recognize?
It recognizes common filter names, sort/order/view, page/p/offset, and tracking parameters such as utm_, gclid, and fbclid. Everything else is labeled unknown.
Does every filter URL need noindex or a canonical?
No. Some combinations deserve crawlable landing pages, while others should be consolidated or blocked from crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor.. Decide from demand, uniqueness, internal linksAn internal link is a hyperlink from one page on a website to another page on the same website. Internal links help search engines discover your pages and pass ranking signals (PageRank and anchor-text context) between them., and crawl behavior rather than applying one rule universally.
Does this tool crawl my navigation?
No. It audits only the absolute URLs you paste, up to 150 rows. It cannot discover combinations, measure crawl volume, or confirm directives.
What triggers the trap warning?
A supplied URL with more than five query parameters is labeled Too many parameters. That is a simple row-level warning, not proof of an active crawl trap.
Next stepSEO Incident Simulator — practice the same investigation on labeled fixtures.

Explore more
ToolLog File AnalyzerToolGoogle Index CheckerToolCanonicalization CheckerArticleEcommerce SEOArticleTechnical Ecommerce SEOArticleFaceted Navigation
 
 
 
Feature requests for Faceted Navigation Auditor
 

Upvote what you want most. New ideas can be submitted from the floating Feedback menu;
      requests appear here once approved, and the most-wanted rise to the top.

   
Loading…
  
  ➕ Request a feature   
New requests are reviewed before they appear here.
 
     
  
  
 
 
 
 
   
       
 
Common issues & how to fix them
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Filter parameter creates crawlable duplication
 
Recommended action: Allow only valuable filter combinations to be indexed and canonicalize or block low-value variants consistently.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Sort parameter creates duplicate URL variants
 
Recommended action: Canonicalize sort-order URLs to the unsorted category and keep sort links out of crawlable index paths.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Pagination pattern expands crawl space
 
Recommended action: Keep paginated URLs crawlable only when they expose unique products, with stable links and self-canonicals.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Tracking parameter creates indexable variants
 
Recommended action: Strip tracking parameters from internal links and canonicalize parameterized variants to the clean URL.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Facet variant lacks canonical consolidation
 
Recommended action: Add a canonical from the low-value facet variant to the preferred indexable category URL.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Low-value facet remains indexable
 
Recommended action: Noindex or otherwise remove low-value facet combinations from indexable crawl paths while preserving useful categories.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Calendar URL pattern creates a crawl trap
 
Recommended action: Limit crawlable calendar paths and expose only useful date pages through internal links and indexable URLs.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.
 
 
 
 
 
 
 
Faceted Navigation Auditor · one finding
 
Parameter pattern has high cardinality
 
Recommended action: Consolidate or block low-value generated variants and keep a bounded set of crawlable landing pages.
 
Fix principle: Faceted, sorted, paginated, and tracking-parameter URLs multiply combinatorially, and Google's own guidance is that crawling them "tends to cost sites large amounts of computing resources due to the sheer amount of URLs and operations needed to render those pages." Before changing anything, diagnose which specific parameter patterns actually create duplicate content or an unbounded crawl space, decide per pattern whether it should be crawlable at all, and then enforce that decision with the one mechanism suited to it — crawl-blocking, canonicalization, or indexing control are different remedies with different consequences, and using the wrong one for a given pattern either wastes crawl budget or hides real defects from Google entirely.
 
 
 
 Implementation for your setup 
 
Confirm first: A filter, sort, or tracking-parameter combination produces a crawlable URL that duplicates the content of its unparameterized page, without a consistent decision about which variant should be indexed. A pagination or facet-combination pattern expands the crawlable URL space faster than it expands unique, valuable content — including patterns with unbounded or very high cardinality (for example date/calendar-style parameters that can generate endless future or past URLs). A facet variant serving indexable content lacks canonical consolidation to the preferred category URL, so Google may select the low-value variant instead of the intended one. A low-value facet variant remains indexable despite offering no unique content or user value over its parent category.
 
Do not apply when: The parameter pattern is confirmed not to create duplicate content (each combination genuinely renders unique, valuable content) and the site has made a deliberate, consistently enforced decision that the pattern should be crawlable and indexable. The URL pattern is already excluded from crawling or consolidated via canonical, and no crawlable, indexable duplicate or unbounded variant remains reachable through internal links, sitemaps, or pagination.
 
Likely control points: cms-app · server · edge-cdn · managed-vendor
 
   
Choose the layer that owns the final response.
 
 
 
Generic HTTP / HTML
 
Status: supported · Location: Origin template or application layer that generates facet/sort/pagination/tracking URLs, plus robots.txt and canonical output
 
Steps
  1. Enumerate the site's actual parameter patterns (filter, sort, pagination, tracking) and classify each one: does it produce unique, valuable content worth indexing, or does it duplicate/thinly vary an existing page? Treat these as separate decisions per pattern, not one blanket rule.
  2. For patterns you decide should never be crawled at all (most tracking parameters, and any pattern with effectively unbounded cardinality such as calendar/date combinations), disallow the pattern in robots.txt using the site's actual parameter names, for example `Disallow: /*?*utm_`, keeping the industry-standard `&` separator between parameters so the pattern matches predictably.
  3. For patterns that should consolidate to one indexable URL rather than disappear from crawling entirely (most sort orders, and filter combinations with no independent value), keep the URL crawlable and point rel=canonical at the preferred unparameterized or lightly-parameterized URL — do not also block that same URL in robots.txt, because Google cannot see a canonical or noindex tag on a page it is not permitted to crawl.
  4. For the small set of filter combinations you deliberately want indexed as their own landing pages, keep them crawlable, self-canonical, and reachable via a stable, crawlable link path — not only via a client-side filter control — and return an HTTP 404 for combinations that produce no results rather than a soft-404-style empty page.
  
Verify on this platform
 
  • Fetch a robots.txt-disallowed sample URL and confirm it is excluded from crawling; separately fetch a canonicalized sample URL to confirm it is still crawlable and its canonical tag names the intended target.
  • Confirm no URL is simultaneously robots.txt-disallowed and carrying a canonical or noindex tag meant to consolidate or deindex it — that combination cannot take effect.
  • Rerun Faceted Navigation Auditor against a representative set of parameter combinations and confirm the filter, sort, tracking, canonical-gap, indexability, calendar, and high-cardinality findings addressed by this change no longer trigger for the enumerated patterns.
 
Rollback
  1. Remove the new robots.txt disallow rule or canonical target if it excludes or consolidates a URL pattern that turns out to carry unique, valuable, previously-ranking content, then re-diagnose which specific pattern actually needs the change.
 
Caveats
  • Blocking crawling and noindexing are different remedies: a robots.txt-disallowed URL can still be indexed (typically without a snippet) if Google discovers it linked elsewhere, and a noindex tag is never seen if the page is also blocked from crawling. Choose one mechanism per URL pattern, not both.
  • Do not use robots.txt or noindex for canonicalization — Google's own guidance recommends redirects or rel=canonical for that goal instead.
  • The Search Console URL Parameters tool was retired in March 2022; Google's crawlers handle parameter discovery automatically now, so no equivalent parameter-configuration UI exists to fall back on. Decide and enforce parameter handling directly on the site instead.
 
Official sources
 
 
WordPress
 
Status: supported · Location: robots.txt (via a site-wide SEO plugin's virtual robots.txt or a physical file) and per-template canonical output for catalog/archive plugins
 
Steps
  1. Identify which plugin or theme generates the site's filter, sort, and pagination URLs (commonly a catalog or product-filter plugin), and confirm which single layer is authoritative for the resulting URL patterns before changing crawl or canonical behavior.
  2. Apply the same per-pattern decision as the generic variant — disallow patterns that should never be crawled, canonicalize patterns that should consolidate — using whichever mechanism your SEO plugin exposes for editing robots.txt rules and archive/taxonomy canonical output, or a physical robots.txt file if none is in use.
  3. Confirm the plugin's own pagination and archive templates emit a self-referencing canonical on pages you intend to keep indexable, rather than pointing every paginated or filtered page at page 1.
  
Verify on this platform
 
  • Fetch a disallowed sample parameter URL to confirm exclusion, and a canonicalized sample URL to confirm it remains crawlable with the intended canonical target.
 
Rollback
  1. Restore the previous robots.txt rules or canonical template output if the change excludes or consolidates content that needs to stay independently indexed, then re-diagnose the specific pattern before reapplying.
 
Caveats
  • This recipe does not name a specific plugin's settings screen for editing robots.txt rules or archive canonical output — those admin paths were not verified against current plugin documentation this session. Confirm the exact location in whichever plugin the site actually runs before making the change.
  • A commerce-catalog or filter plugin's own documentation was checked this session and did not address canonical or crawl handling of the parameter URLs it generates; treat that plugin's specific behavior as unverified until confirmed against its own current docs.
 
Official sources
 
 
Shopify
 
Status: not-verified · Location: Search & Discovery app filter configuration and Online Store theme collection templates
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask Shopify support or the Search & Discovery app's own current documentation to confirm whether filter-generated collection URLs are canonicalized to the base collection automatically, and whether robots.txt or theme-level canonical control is available for filtered URLs.
  
Caveats
  • Shopify's own Search & Discovery filters documentation, checked this session, describes filter configuration but does not address how filter query-parameter URLs are canonicalized, blocked from crawling, or otherwise handled for SEO. No specific canonical or robots.txt behavior for Shopify filter URLs is claimed here because it could not be confirmed.
  • Do not assume Shopify's theme.liquid canonical_url output (verified for standard product/collection/content pages in the canonical-signals recipe) also self-corrects for every filter-parameter combination — that behavior for filtered collection URLs specifically was not confirmed.
 
Official sources
 
 
Platform-managed / ask the vendor
 
Status: platform-managed · Location: Vendor-owned catalog, search, or filtering system
 
Implementation is controlled by the platform or vendor.
  
Verify on this platform
 
  • Ask the vendor which parameter patterns are crawlable today, whether each is canonicalized, robots-blocked, or indexable by design, and confirm by fetching representative sample URLs directly.
  
Caveats
  • Escalate when the vendor cannot enumerate its own parameter patterns, cannot state a deliberate crawl/index decision for each, or when robots.txt blocking and canonical/noindex signals are found layered on the same URL pattern.
  • Do not accept a claim that faceted URLs are "handled" without directly fetching sample URLs for each pattern and confirming the actual robots, canonical, and status-code behavior.
 
Official sources
 
 
 
 
 How to verify 
 
  1. Enumerate the site's actual filter, sort, pagination, and tracking-parameter patterns and confirm each has one deliberate, documented crawl/index decision.
  2. Fetch representative sample URLs for each pattern and confirm the applied mechanism (robots.txt disallow, canonical, or intentional indexability) actually took effect, and that no URL carries conflicting signals (both blocked and canonicalized, or both blocked and noindexed).
  3. Confirm any pattern kept crawlable and indexable returns unique, valuable content, is reachable via a stable crawlable link path, and returns 404 for combinations with no results.
  4. Rerun Faceted Navigation Auditor on the same representative parameter set.
 
Escalate when
 
Escalate when ownership of the URL-generating system is unclear, no one can state a deliberate per-pattern crawl/index decision, or fetched sample URLs keep showing conflicting robots/canonical/index signals after the enumerated patterns have been addressed.