SEF generation in 1C-Bitrix: human-readable URLs, codes, redirects

URL setup in 1C-Bitrix: where indexing breaks

A dynamic address like /catalog/index.php?SECTION_ID=42&PAGEN_1=2 gets into the index on par with the human-readable one.

Address duplicates dilute weight between copies, and the section stops merging into a tree — search sees a set of disconnected pages instead of the catalog structure.

Then a chain starts. A template or rule change generates new addresses, old ones remain working or return 404 — broken transitions eat up accumulated links.

Case, trailing slash, www and sorting parameters add even more layers of copies if redirect and canonical address are not set.

URL setup in 1C-Bitrix is not a single checkbox for enabling SEF in module settings.

You need rewrite rules, separate handling of pagination and faceted filter, a unified address form for sections and detail pages, end-to-end redirects when moving sections and products between them.

SEF and indexing are directly connected: until the site's address structure is reduced to one variant per page, any catalog edit generates new duplicates.

The consequence is falling out of search results for entire branches: products and articles remain accessible but stop receiving transitions from search.

We break down how this is closed: from rewrite rules and the redirect map to comparing the crawl before and after release — so that moving the structure does not lose positions.

Effect of correct SEF URLs: what changes in operation

Managed addresses give a measurable effect in three places: indexing, visitor behavior and structure flexibility.

The first consequence is merging duplicates: the same section opened through a filter, sorting or with a trailing slash looks like several pages to the search engine, and link weight is diluted between copies. Address handling rules in 1C-Bitrix reduce all variants to one canonical form.

Second — human-readable addresses. An address like /katalog/nasosy/tsentrobezhnye/ reads both in search results and in the browser bar, so a visitor more often lands in the right section from the first transition.

In numbers it looks like this: the share of transitions deeper into the catalog grows and the number of returns to the search bar from an internal page falls.

Third — stable search results when section structure changes.

Moving a category, splitting a large section or merging two close ones stops being an operation with a collapse in positions: old addresses are closed by redirects according to a pre-described rule, external links lead to the same materials, and the search engine sees a planned update rather than a stream of errors.

In sum, the structure moves from a state of "scary to touch" to manageable: sections are rebuilt for business tasks, accumulated traffic is preserved. We break down what rules your catalog needs and how to check the result before launch.

Ways to enable SEF: comparison of operation modes

SEF mode is set once, but then determines the entire address structure: how addresses of new cards are formed, what address handling rules apply to sections, what happens when the catalog is moved or the output template changes.

In practice, the choice comes down to three schemes — automatic SEF, manual addresses and a hybrid, where automation covers the mass and manual editing covers points important for search.

Automatic mode works while the catalog is homogeneous and filled by editors: code is assembled from the name by template, conflicts are resolved by a numeric suffix.

Manual addresses give control where a short Latin link or a unified form for old and new sections is needed — but require discipline: a missed symbolic code gives a duplicate address, not an error in the interface.

Changing mode on a live project is no longer about setup but about compatibility: old links must be closed with a permanent redirect, otherwise external transitions and accumulated search results go nowhere.

Therefore the scheme is fixed before filling the catalog, and address handling rules are checked on a test copy — with import, pagination and filters.

Implementation order: from address audit to handover

Addresses in 1C-Bitrix live on several layers: SEF templates in infoblock properties, handling rules in urlrewrite.php, server-level redirects and canonical addresses in the template.

You cannot change them one by one — some pages start returning 404, some go into duplicates, and the search engine pulls both versions into the index. Therefore address setup goes step by step, with the result checked at each step.

1. Address audit. Collect everything the server actually returns: request logs, sitemap, export from analytics systems, active rules. Separately mark addresses with traffic and external links — they cannot be lost.
2. Redirect map. For each old address, assign a target and response code: 301 for a permanent move, 302 for temporary. Remove chains of two or three transitions, bring slash, case and query parameters to a unified form.
3. SEF scheme. Set templates for sections and infoblocks, transliteration rules, decide what goes into the address — symbolic code, SKU or date. Check that new addresses do not overlap with existing ones.
4. Test environment. Deploy a copy with the same set of rules and redirect map, crawl the full list of addresses, compare response codes and canonical addresses. Only after that do we transfer to production.
5. Transition approval. Show the map to the client: what changes, what remains, where the redirect is placed. We make edits before publication, not after.
6. Setup on production. Enable the rules, clear the cache, update the sitemap and keep response codes under observation in the first hours.
7. Handover. Provide the redirect map, SEF templates, regulation for adding new sections and the procedure for checking an address before publication.

What we hand over: files, schemes, regulations

URL setup in 1C-Bitrix does not end the moment addresses start opening. Without fixed agreements, the first new catalog section breaks template logic, duplicates spread across search results, and old addresses go nowhere.

Therefore we deliver a package by which the work can be repeated and handed to another contractor without getting into someone else's head.

• Address scheme — map of levels with SEF templates: which parts are formed from symbolic code, which are set manually, where nesting is limited deliberately.
• Working configuration — address handling rules with priorities, infoblock and section settings that affect code generation.
• Transition map — table "old address → new" with duplicate merge rules, slash and case normalization, separately — addresses after a catalog structure change.
• Configuration rules — what can be changed on site and what only through approval: transliteration, separators, code length, handling of occupied addresses.
• Work regulation — sequence of address editing: who initiates, at what moment the rule is updated, what checks are passed before deployment.
• Content manager instruction — how to create a section or card so that the code is generated correctly, and what to do when moving material.
• Set of checks and change log — list of control addresses for a run after release and rollback points if the rule worked incorrectly.

The package is designed for a person who was not involved in the setup: from it one can see why the address looks exactly this way and what will happen on the next section addition.

Case: merging address duplicates and restoring search results

Starting point

In a catalog on 1C-Bitrix, the same card opened via seven addresses: with a numeric code and with a symbolic one, with a www prefix and without, with a trailing slash and without, with sorting and page number parameters.

The robot crawled all variants, search results received several copies of one text and chose now one, now another. The number of indexed addresses grew, while transitions from search became fewer — traffic leaked to duplicates.

What we did and what we achieved

Enabled SEF mode and set a unified template for the catalog, sections and detail pages; symbolic codes are assembled by transliterating the title with truncation and duplicate check.

Old variants were closed with a permanent redirect to the canonical address — some rules at the server level, some in handlers, so as not to lose addresses with filter parameters.

Sorting and pagination pages received a canonical address and were removed from the crawl, the sitemap was reassembled: only main addresses got into it.

After the recrawl, the number of indexed addresses decreased from 41,000 to 5,700, while pages with unique content in the index became more, not less.

Transitions from search to the catalog grew by about a third, robot crawl fits within a day instead of a week, and new sections get into search results within days — the SEF mechanics for them are already set.

Technical doubts before starting work

A working site is not a blank sheet: there is indexing history, external links and sections users are used to. Before changing the address scheme in 1C-Bitrix, we compare what has been accumulated, and only then touch the rules.

How does this work for language versions of the site?

Each version gets its own catalog prefix or a separate domain; the address formation rule is common, and the prefix is substituted automatically.

We separately monitor transliteration: Cyrillic and Latin have different rule sets, otherwise addresses of different versions will start matching each other.

What about old links and accumulated positions?

We close old addresses with permanent redirects, the sitemap is regenerated for the new structure. External links and user bookmarks continue to work.

If the structure has to be changed again — will everything go in circles?

We move address templates to one place — infoblock and module settings, not component code. Then repeated structure changes come down to editing a rule and adding to the redirect map, without rewriting links across templates.

Let's discuss your address and redirect task

To come back with an estimate and work plan, not clarifying questions, we need input data on the current address structure. Gather what you have at hand — our engineers will take the rest from the project itself and server settings.

• Map of current addresses: export from the sitemap file or list of sections already indexed by search.
• Existing redirect rules: contents of .htaccess, address rewrite file and server-level settings.
• SEF templates by sections and infoblocks: where SEF is enabled, where links are assembled manually, and where the address is formed from symbolic code.
• Untouchable addresses: those already distributed across advertising, printed materials, applications and partner cabinets.
• Sources of external transitions: where links come from, so the redirect does not break working connections.
• Report on 404s and support requests: will show the real impact of address errors, not the supposed one.
• Deployment restrictions: release regulation, presence of a test environment and the window during which rules may be changed.

Based on this data we prepare a work plan: which addresses we edit, where we place a permanent redirect, how we check coverage of the old link map and in what order we deploy changes so that search does not lose pages.

If something is missing — no problem: we will clarify what is missing on a call and fix it in the estimate.

How an SEF address differs from a dynamic URL

A dynamic address is a request to the infoblock with identifiers in parameters: ?SECTION_ID=, ?ELEMENT_ID=. The same content is served, but the link can neither be dictated nor shortened without losing meaning.

SEF is a mode where the address is assembled from symbolic codes of sections and elements, like /catalog/plitka/keramogranit/.

In 1C-Bitrix both variants are switched in the information blocks module settings — by the fields "Section page URL" and "Detail page URL".

The difference shows during migration and duplication. In dynamic mode, renaming a section or changing the parent breaks nothing: the identifiers are the same, the address is built anew on each output.

In SEF, the address changes together with the code, and previously published links return 404 until redirect rules are set for them. Plus one element becomes available both by SEF and by dynamic address — two pages with identical content.

This is where a canonical address is needed: <link rel="canonical"> points to the main URL, and other variants are not indexed as independent.

The choice of address mode is dictated by the section purpose: where the link is passed to a client or partner, SEF is needed, while for service selections parameters are enough — with closing the excess from indexing.