SEO-friendly URL setup for 1C-Bitrix filters: complete guide

Bitrix filter SEF URLs: how parameters in the URL break indexing

The standard smart filter builds the address as a query string: property values go into parameters after the question mark and are joined by ampersands, while the enumeration order is set by the module itself.

The number of combinations is the product of variants for each property — a catalog of several hundred items expands into tens of thousands of URLs, even though only a handful of them are meaningful selections.

Indexing URL parameters works differently from crawling static sections: the robot follows links and either hits the depth limit or discards parametric URLs as low-value.

Some filter pages do not get crawled at all, and a product that is actually in stock is simply invisible to search. The dropped URLs have neither a title, nor a description, nor their own text.

When pages do get crawled, page weight dilution begins: the same selection is available at several URLs — with a different order of parameters, with added sorting, with a pagination tail.

The canonical URL is either not set or points to the catalog root, so search engines see mirror URLs of the results and choose an arbitrary one for display. Duplicate catalog pages compete with each other in the snippet, and none gains enough weight.

Hence the task: not to prohibit filters, but to describe rules by which parameters turn into path segments, some combinations become indexable, and the rest are closed from crawling.

We analyze how this works in Bitrix filter SEF URLs and what changes in indexing after the migration.

What changes after moving to short URLs

A short URL is not link cosmetics, but a different mode of catalog crawling. While the filter serves the same product list at dozens of parametric URLs, the robot spends its crawl on copies, while product pages and sections wait in line.

Moving to human-readable URLs with a single canonical page view in 1C-Bitrix returns crawling to where it brings traffic.

The difference is visible only when comparing identical slices. Before work, we take a baseline: crawl export from server logs, an indexing report and sitemap, distribution of visits by filter URL.

After rollout, we repeat the same slices — this way it is clear that the result came from the new URL format, not seasonality or content edits.

Configuration options: component rules, sections and static URLs

URL processing rules and catalog component settings solve the same task with different means: the former rewrite the incoming URL before the catalog is called, the latter build a human-readable URL from filter parameters.

The choice depends on how many combinations need to be promoted and who will maintain them. Below are four schemes that are actually chosen between on projects.

In practice, the hybrid scheme is chosen more often: rules provide dynamics for all combinations, while static landing pages cover top queries.

Mandatory conditions are a canonical URL, redirect when the template changes, prohibition of indexing empty combinations, and correct cache operation. Then, as the catalog grows, the number of URLs does not grow linearly, and rollback to the previous scheme remains manageable.

Order of work: from URL audit to rule handover

SEF filters change the appearance of catalog links, so the order of work here is no less important than the rules themselves.

First we look at what is already in the index, and only then touch the URL scheme: otherwise search gets hundreds of new URLs, while the old ones remain accessible.

1. Catalog URL audit. We collect URLs from crawling and statistics: which filter parameters are actually used, which produce duplicates, how many URLs fall on a section. The output is a list: what to keep, what to merge, what to close.
2. Designing the short URL scheme. We define the base section, property order, separators, and behavior for multiple selection. The scheme is fixed before edits in templates and components.
3. Configuring rules. We transfer the agreed scheme into URL processing rules and 1C-Bitrix component settings — the URL must be built on the server side, not by a script in the browser.
4. Checking URL merging. We run variants with different property order, case, and extra parameters: all of them must lead to one canonical URL.
5. Crawl control after release. We look at the number of URLs in the index, duplicate growth, and pages that needed to be preserved. We correct deviations before changes take hold in search results.
6. Handover of the URL processing policy. We provide a document: how to add a property to the filter, which rules to update, which checklist to use to check merging, and when to launch recrawling.

Handover package: rules, redirect map, policy

After project delivery, the client is left not with server access, but with a set of artifacts that allow the catalog to be developed without us. Each item covers its own class of tasks — from editing a single selection value to rebuilding links between sections.

• URL rules file — rules that turn selection parameters into a readable path, with comments: which properties are involved, which are excluded, and why.
• Redirect map — a table "old URL → new URL → response code" for all filtered pages: accumulated search traffic moves to new paths instead of an error.
• Catalog section scheme — links between sections and selection values: where paths duplicate and merging is needed, and where the filter is intentionally left as a parameter.
• Instructions for the catalog editor — what can be changed independently (titles, texts, value order) and what requires editing URL rules.
• Post-edit checklist — a sequence of steps: control URLs, response codes, canonical links, absence of duplicates.
• Change policy — who makes edits and when, how new rules are fixed, and where the redirect history goes.

The package is stored in the project next to the catalog configuration, so the next time the assortment is expanded, the logic does not have to be restored from memory.

Case study: how URL duplicates were removed and catalog traffic returned

Before

The catalog on 1C-Bitrix built the filter URL from all parameters in a row: sort order, display type, and number of products per page went into the URL as ordinary selection conditions.

Each set of values produced a separate URL, and with dozens of characteristics the count ran into tens of thousands of combinations — all of them opened the same product list.

Crawling spent its limit on service variants: pages with reverse parameter order, empty selections, sorting URLs. Sections with real demand were crawled less often, and some product pages dropped out of the index.

What was changed

We fixed a single URL template and left in it only conditions meaningful to the buyer — category, brand, characteristics.

Service parameters were removed from indexing and stitched to the base page with a canonical URL; redirects were set up for already indexed combinations, and only clean filter URLs were included in the sitemap.

Metrics before and after

• Before: 21,000 filter URLs in crawl, duplicates — 83% of them, 6,400 pages in the index.
• After: 2,400 URLs, duplicate share less than 6%, 9,800 pages in the index, catalog crawl increased 1.6 times, visits to sections — plus 41%.

The freed crawl limit went to product pages and sections with product demand, so index growth was not accompanied by an increase in the number of same-type pages.

The template rule is transferred to new filters automatically — when a characteristic is added, the URL is built according to the same scheme.

What to do if filters are already indexed: cleanup and migration

If filters have already made it into the index with parameters in the URL, changing the template alone will not fix anything: the old URLs will continue to appear in search results and compete with the new ones.

The search engine sees two sets of pages with identical content, and duplicates begin to dilute positions for commercial queries.

We go through the accumulated list: export all indexed catalog URLs from the webmaster panel and compare them with the new format.

For each one that has traffic or external links, we set a permanent redirect to the corresponding SEF URL — at the web server configuration level, not with a script inside the page: redirects rendered by code pass weight unreliably.

Merging catalog pages is a separate task. If different filter combinations show the same set of products, we leave one URL and mark it as primary, and close the rest from indexing.

This way accumulated weight is collected on one document instead of being dispersed across dozens of nearly identical pages.

Then we fix the result: update the sitemap, internal links, pagination, and cross-linking so that recrawling goes to the new URLs instead of keeping the old ones alive.

In the first weeks, position fluctuations are possible — this is a normal migration phase, and it is more important not to disturb the structure again.

What we do not do: mass temporary redirects, closing pages in robots.txt that already bring traffic, and combining such a migration with other major catalog changes. We also keep a rollback scenario to the previous scheme in the plan — it takes one release.

Technical doubts before launch: point-by-point analysis

Before launch, doubts usually arise not about the filter itself, but about how it will coexist with the existing catalog structure and external traffic. We address the four most frequently asked questions.

What happens to pagination in the catalog?

The URL of the second and third pages preserves the selection parameters, so paging does not reset the user's choice. Each page gets its own canonical URL, not a link to the first one — otherwise products deep in the results remain invisible to search.

Does the order of selection values affect the URL?

This is a frequent source of duplicates: the same selection can be assembled in a different order and produce two URLs with identical content. We bring parameters to a fixed order and normalize case — each combination keeps one URL.

Will advertising click statistics be lost?

We preserve clicks on previous URLs: we set up a redirect with source parameter transfer, so campaign tags and accumulated statistics are not reset. Before launch, we check active ads — a click on an old link does not turn into an error, and the goal continues to be recorded.

Let's discuss the task: we'll build a URL map and come back with a plan

To make the discussion substantive rather than hand-wavy, input data on the catalog is enough: section structure, list of filters, and current URLs. Then the catalog URL map is built based on facts, and the estimate and work plan rely on real scope, not assumptions.

To analyze, send:

• an export of the catalog structure: sections, subsections, and the number of products in each;
• a list of filters and their parameters — which properties are involved in selection, which only in sorting;
• examples of current filter page URLs: with parameters in the query string, with SEF URLs, merged with each other;
• a list of already indexed URLs and click statistics for several months, if analytics is maintained;
• the rules the business needs: which filter combinations we close from indexing, which we leave open;
• requirements for multi-regional and multilingual URLs, if any;
• access to a test environment or catalog copy — on it we check routing rules without risk to the production site.

Based on the conversation, you receive a URL map with templates for each filter level, a scheme of merges and redirects, as well as an estimate and work plan broken down by stages.

We discuss the launch order separately: what we close first, what we run in parallel with current site improvements, so as not to stop releasing catalog changes.