GET parameters create the same content at many URLs — tracking tags, filters, session identifiers — and Yandex may treat the results as duplicates. This tool tells the robot which parameterised URLs to crawl and index and which to ignore, which reduces crawl load and makes the intended page the one that appears.
How the page works
Under Indexing → Configure GET parameters, the console lists every parameter the robot has found on the site. You can add your own; you can delete parameters you added, but not ones the robot discovered. Each parameter gets a value in the “Consider the parameter?” column:
- No value or Yes — pages with the parameter are indexed and can appear in results.
- No — pages with the parameter are not indexed.
For manually added parameters you can also scope the rule: all pages, the home page only, or a specific section. Changes take effect within a week.
The conflict rule, which is the important part
The same behaviour can be configured in robots.txt with Clean-param. When the console and the file disagree, Yandex applies the rule that prevents indexing. The strictest setting wins, not the most recent. So a site with a forgotten Clean-param line cannot re-enable those URLs from the interface — the file has to be edited. Anyone debugging “I set it to Yes and nothing happened” is looking at this.
What to mark as not considered
Analytics and campaign tags (utm_*, click identifiers), session identifiers, sort order, and view-mode switches — anything that changes presentation or tracking rather than content. What to leave alone: parameters that genuinely select different content, such as a category or a product variant that should rank on its own.
Why this matters more on Yandex
Yandex exposes this as an explicit control, whereas Google leaves you inferring from canonical tags and hoping. Being able to see the full list of parameters the robot has actually encountered is itself an audit: parameters nobody on the team recognises usually mean a tracking integration or a filter generating URLs nobody planned.
How we apply this
We open this list on every technical audit and read it as a discovery report before changing anything — the parameters the robot has found are frequently news to the client. The rule we spend the most time explaining is the conflict rule: the strictest setting wins, so a stale Clean-param line in robots.txt silently overrides everything set in the interface, and the interface gives no indication that it has been overruled.
Related services