Designing URL Structure and SEF URLs in 1C-Bitrix

Designing URL Structure and SEF URLs in 1C-Bitrix

When a project comes to us for a URL structure overhaul, the first thing we find is that SEF (search engine friendly) URLs were enabled "as per the documentation" without any thought given to semantics. The catalog lives at addresses like /catalog/element/12345/, the filter generates /catalog/section-23/filter/price-500-1000/apply/, and section paths are a mix of Latin characters and transliterated Cyrillic. The SEO specialist says promotion is impossible with this setup, but changing the URLs is scary — hundreds of pages are already indexed.

Designing URLs in Bitrix is an intersection of the platform's technical capabilities, SEO requirements, and content logic. Getting it right from the start is many times cheaper than fixing it later.

How SEF URLs Work in 1C-Bitrix

Bitrix implements SEF URLs at the component level. The key parameters are: SEF_MODE (enable/disable semantic URLs), SEF_FOLDER (the component's base folder), and SEF_URL_TEMPLATES (URL templates for each component action).

For the bitrix:catalog composite component, this looks as follows:

SEF_URL_TEMPLATES => [
    'section'  => '#SECTION_CODE_PATH#/',
    'element'  => '#SECTION_CODE_PATH#/#ELEMENT_CODE#/',
    'compare'  => 'compare/',
    'search'   => 'search/',
]

The variables #SECTION_CODE_PATH# and #ELEMENT_CODE# are substituted from the CODE fields of the info block section and element. If CODE is not filled in or contains Cyrillic characters, SEF either doesn't work or produces ugly URLs. This is the first failure point on typical projects.

The second layer is .htaccess and RewriteRule directives. Bitrix manages this through urlrewrite.php — a file that is auto-generated when SEF mode is enabled on the site. It stores routing rules for every component running in SEF mode. Manually editing urlrewrite.php is bad practice: the file is overwritten whenever site settings are saved.

Designing the Structure: What to Decide Before You Start

Section hierarchy. URLs should reflect the logical structure of the catalog, not the technical nesting of the info block. If the info block has three levels of nesting but only two matter from an SEO standpoint — you need to decide how to represent this in the URL template.

Smart filter. bitrix:catalog.smart.filter generates URLs like /catalog/section/filter/prop-color-is-red/apply/. Questions to address: which properties are filterable (i.e., appear in the URL) and which are not (to avoid duplicate content). For each filterable property, SEO_FILTER_URL and CODE must be configured. Non-filterable properties don't appear in URLs and don't participate in SEO filtering.

Pagination pages. By default, Bitrix appends ?PAGEN_1=2 or /page-2/ depending on the component settings. For SEO, it's important to agree up front: canonical pointing to the first page, or paginated pages being indexed. This affects the PAGE_VAR parameter in the component.

Multilingual support. If the site is multilingual, the URL structure is designed to include language prefixes (/en/, /de/) or subdomains. Bitrix handles this through SITE_ID and language sites, but the SEF templates for each language site may differ.

Case Study: Reworking the URL Structure for a Building Materials Online Store

A project with 40,000 SKUs, a catalog running on bitrix:catalog, SEF enabled — but URLs looked like /catalog/sections/раздел-nazvanie-товара-12345-detail.php. Transliteration had not been configured; element codes were auto-generated from the Cyrillic title plus an ID.

The goal: bring URLs to the form /catalog/category-slug/product-slug/ while preserving search engine rankings.

Work stages:

1. Audit of existing URLs. Using CIBlock::GetList() and CIBlockElement::GetList(), we exported all active sections and elements with their current codes. Found 3,200 elements with no CODE — their URLs were entirely broken.

2. Code generation. Wrote a transliteration script based on \Bitrix\Main\Text\StringHelper::convertToLatin() with ID postfixing for uniqueness. All codes were checked for duplicates within their respective sections.

3. Configuring SEF URL templates. Fixed the template for elements: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/. A two-level structure — section and product — without the full path through all levels (otherwise, moving a product changes its URL).

4. 301 redirects. Using the seo module, created a mapping of old URLs to new ones. For 40,000 items, this was done programmatically via \Bitrix\Seo\UrlRewriter.

5. Indexing verification. Monitored through Search Console that new URLs return 200 status, and old URLs return 301. No cannibalization occurred.

The work took 12 business days. Six weeks later, traffic recovered and grew by 18% thanks to the correctly indexed filter pages.

Typical Mistakes

• Enabling SEF without filled-in codes — the component will start generating URLs with empty segments or throwing 404 errors.
• Duplicate codes for elements within the same section — Bitrix doesn't prohibit duplicate CODE values at the database level (unless the corresponding info block option is enabled), but they create routing ambiguity.
• Not configuring canonical tags for filter pages — with 20 filterable properties, the smart filter can generate thousands of URLs, most of which are duplicates or low-frequency pages with no traffic.

Timeline

Designing a URL structure for a new project (catalog up to 10,000 SKUs) takes 3–5 days: semantic analysis, template selection, coordination with the SEO specialist, implementation, and testing. For an existing project requiring URL migration — 10–20 days depending on the volume of content and the complexity of the redirects.