SEO URL Design in 1C-Bitrix: Preserve Rankings During Migration

When a project comes to us for URL structure rework, the first thing we find is that SEF was enabled "as in the documentation" without considering semantics?

The catalog lives at /catalog/element/12345/, the filter generates /catalog/section-23/filter/price-500-1000/apply/, and sections mix Latin and translit. According to Google Search Console, incorrect URL structure can lead to up to 30% loss of indexing. The SEO specialist says promotion is impossible with this, but changing URLs is scary — hundreds of pages in the index. Our experience shows that a proper migration with 301 redirects not only preserves positions but also increases traffic: in one project with 40,000 SKUs, traffic grew by 18% in 6 weeks after URL rework. We design URL structures from scratch or rework existing ones — with guaranteed ranking preservation. Average savings on SEO rework after migration amount to 30,000–50,000 RUB per month.

Designing URL structure and SEF in 1C-Bitrix is the intersection of platform technical capabilities, SEO requirements, and content logic. Getting it right the first time is many times cheaper than fixing it later. Get an audit of your project in one day — contact us. 10+ years of experience and over 500 successful projects guarantee results.

How SEF works in 1C-Bitrix

Bitrix implements SEF at the component level. Key parameters are SEF_MODE (enable/disable semantic URLs), SEF_FOLDER (base folder of the component), SEF_URL_TEMPLATES (URL templates for each component action).

For the bitrix:catalog complex component, it looks like this:

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 infoblock section and element. If CODE is empty or filled with Cyrillic, SEF either doesn't work or generates ugly URLs. This is the first point of failure in typical projects.

The second layer is .htaccess and RewriteRule rules. Bitrix manages this via urlrewrite.php — a file generated automatically when SEF is enabled on the site. It stores routing rules for each component in SEF mode. Manual editing of urlrewrite.php is bad practice: when site settings are re-saved, the file gets overwritten.

How to design URL structure to avoid losing rankings?

Section hierarchy. URLs should reflect the logical structure of the catalog, not the technical nesting of the infoblock. If the infoblock has three nesting levels but only two are important from an SEO perspective, you need to decide how to reflect this in the URL template.

Smart filter. bitrix:catalog.smart.filter generates URLs like /catalog/section/filter/prop-color-is-red/apply/. Questions: which properties are filterable (i.e., appear in the URL) and which are not (to avoid duplicates). For each filterable property, configure SEO_FILTER_URL and CODE. Non-filterable properties do not appear in the URL, but also do not 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 from the start: canonical to the first page or pagination is indexed. This affects the PAGE_VAR parameter in the component.

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

Why trust URL design to professionals?

From our practice: an online store of building materials with 40,000 SKUs, catalog on bitrix:catalog, SEF enabled, but URLs looked like /catalog/sections/section-productname-12345-detail.php. Transliteration was not set up, element codes were generated from the Cyrillic name + ID.

Goal: bring URLs to the form /catalog/category-slug/product-slug/ while preserving search positions.

Work stages:

1. Audit of existing URLs. Through CIBlock::GetList() and CIBlockElement::GetList(), we exported all active sections and elements with their current codes. Found 3,200 elements without CODE — their URLs didn't work at all.

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

3. SEF template setup. Fixed the template for elements: /catalog/#SECTION_CODE#/#ELEMENT_CODE#/. Two-level structure — section and product — without the full path through all levels (otherwise URL changes when product is moved).

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

5. Indexing check. Via Search Console, we monitored that new URLs returned status 200, old ones returned 301. No cannibalization occurred.

Work took 12 working days. The cost of audit and migration at this scale starts from 150,000 RUB. After 6 weeks, traffic recovered and grew by 18% due to correctly indexed filter pages. Design costs pay off in 2–3 months.

$element = \CIBlockElement::GetList([], ['IBLOCK_ID' => $iblockId, 'CODE' => false]);
while ($el = $element->Fetch()) {
    $code = \Bitrix\Main\Text\StringHelper::convertToLatin($el['NAME']) . '-' . $el['ID'];
    $el->Update(['CODE' => $code]);
}

Our experience — 10+ years in Bitrix, over 500 successful projects, including URL migrations for catalogs up to 100,000 items. We guarantee ranking preservation when changing structure. Get a consultation for your project — contact us.

Typical mistakes when configuring SEF in Bitrix

Most often we encounter three mistakes: enabling SEF without filling codes (the component generates URLs with empty segments or 404), duplicate codes for elements in the same section (Bitrix does not prohibit CODE duplicates at the database level if the corresponding infoblock option is not enabled), and missing canonical for filter pages (the smart filter with 20 properties can create thousands of duplicate URLs). These problems are solved at the design stage.

Compare two approaches to URLs:

What is included in URL design?

• Full audit of the current URL structure with code export and error detection
• Development and approval of semantic URL scheme
• Configuration of SEF templates for all catalog and filter components
• Generation of element and section codes with uniquing
• Creation of 301 redirects via the SEO module
• Testing all URLs' functionality and fixing 404 errors
• Documentation of the new URL structure
• Support during the indexing phase (monitoring recommendations)

Deadlines

Designing a URL structure for a new project (catalog up to 10,000 SKUs) takes 3–5 days: semantic analysis, template selection, agreement with SEO specialist, implementation, and testing. For an existing project requiring URL migration, it takes 10–20 days depending on content volume and redirect complexity. The cost is calculated individually, but the average bill for a project with 40,000 SKUs is 150,000–200,000 RUB.

Official documentation on SEF in Bitrix (dev.1c-bitrix.ru). Learn more about URL structure on Wikipedia. Contact us for a project evaluation — get an audit of your current URL structure and improvement recommendations.

Project Architecture Design on 1C-Bitrix: Avoiding Common Mistakes

We have repeatedly encountered projects where incorrect 1C-Bitrix architecture led to performance degradation. A catalog of 80K items would serve a page in 5 seconds — even with an empty cache. The architecture determines performance and support costs. Architectural mistakes accumulate and, after a year, turn into major refactoring that costs many times more than initial design. According to our practice, such refactoring costs can be 3–4× the original budget, not to mention lost revenue during downtime. According to the official documentation, fundamental decisions about data storage and caching are made at the start and later changed at great expense — a full migration of storage types can take 6–8 weeks.

Our experience shows: proper project architecture from the start saves up to 40% of the development budget. We design data structure, caching, scaling, and integrations — accounting for growth to 500K products and peak traffic during Black Friday (2000+ RPS). Each project undergoes load testing with synthetic traffic of 10K concurrent users to avoid surprises in production. Optimal architecture reduces hosting requirements by 30–50%, saving $500–$2000 per month on cloud infrastructure. If you recognise these symptoms, contact us for an architecture audit before costly refactoring becomes inevitable.

How to Choose Storage Type for 1C-Bitrix?

This is the first and most expensive architectural decision. Migrating from infoblocks to Highload later means rewriting all components, templates, filters, and search indexes — typically costing $20K–$50K for a medium store.

Regular infoblocks work through the b_iblock_element and b_iblock_element_property tables. Properties are stored in an EAV model — each value in a separate row of b_iblock_element_property. With 50 properties and 100K elements, you get 5 million rows in one table. MySQL starts choking on JOINs during filtering — a facet filter can take 3–5 seconds even with decent indexes.

Infoblocks are good for:

• Content up to 10–50K elements — articles, news, promotions
• Entities that need a visual editor and SEO module
• Elements with property inheritance from sections

Highload blocks are flat tables. One entity — one table with columns. No EAV. Filtering on indexed columns works an order of magnitude faster. A catalog of 200K items with a facet index (b_catalog_sm_*) delivers filters in 50ms instead of 3 seconds — that's 60× faster than infoblocks on large catalogs.

Highload blocks are required for:

• Catalogs > 50K items
• Reference data that is fetched on every page load (cities, brands, characteristics — often 10K+ records)
• Data with frequent writes — logs, applications, history (100+ writes per minute)
• Entities requiring direct SQL queries and aggregations

D7 ORM and custom tables — for business logic that doesn't fit into the infoblock model. Many-to-many relationships, computed fields, custom aggregations. Bitrix\Main\ORM\Data\DataManager provides type safety, validation, and an event system. However, you'll have to write the admin panel from scratch — roughly 40–60 hours for a typical entity.

Scaling 1C-Bitrix Without Performance Loss

Horizontal scaling is a topic where 90% of projects fail. However, people think about it only when the site is already down.

The first step — move sessions from files to Redis. Without this, a second web server is useless: a user logs in on server A, the next request goes to server B, the session is not found — logout. In .settings.php:

'session' => ['value' => ['mode' => 'redis', 'host' => '127.0.0.1', 'port' => 6379]]

Next:

• nginx upstream or HAProxy distributes requests. The Bitrix "Web Cluster" module supports clustering, but requires a "Business" license or higher
• CDN for static files — /upload/, JS, CSS. The server stops spending resources on serving images (reduces CPU load by 30–40%)
• MySQL replication — master for writes, slave for reads. Bitrix supports up to 9 slave connections via .settings.php. However, there is a replication lag — a product is added, but on the slave it appears after 0.5–2 seconds. Use sticky reads for critical data

Vertical scaling is cheaper and faster initially:

• EXPLAIN every heavy query. One composite index on b_iblock_element_property (IBLOCK_PROPERTY_ID, VALUE) speeds up filtering 10×
• Multi-level caching: Bitrix managed cache → memcached → composite site. Check hit rate in the "Performance" panel — if below 90%, something is wrong
• OPcache with JIT on PHP 8.1+ — free 15–30% acceleration

Composite site mode can serve pages in 0.1s for anonymous users — we use it for 80% of traffic.

Offloading Heavy Processes from the Monolith

Bitrix is a monolith, and that's fine. Breaking it into microservices is madness. But offloading heavy processes is the right move.

Import/export is the most common pain. Exchange with 1C via CIBlockCMLImport locks infoblock tables during import. 100K items — that's 20–40 minutes when filtering on the site slows down. Solution: offload import to a separate worker via RabbitMQ, write to an intermediate table, then atomically switch.

• Search — Elasticsearch instead of the built-in search.title. Full-text and faceted search, autocomplete, typo correction. Load on MySQL is completely removed. We achieve <100ms for full-text search on 500K products.
• Notifications — push, SMS, email via queue. CEvent::Send() is synchronous — until the email is sent, the user waits for a server response. A queue (RabbitMQ or Redis list) reduces response time by 200–500ms.
• Report generation — PDF, Excel on large volumes (10K+ rows). Separate process, result — a download link.

API: REST, GraphQL, Webhooks

Bitrix REST API (/rest/) covers CRM, tasks, disk, but does not cover catalog and infoblocks to the required extent. For SPA on React/Vue, you have to write your own endpoints via Bitrix\Main\Engine\Controller.

• GraphQL — for mobile applications where traffic is expensive. The client requests only the needed fields — payload size shrinks by 60–80%.
• Webhooks — event model: new order → POST to external URL. No need to poll the API every 5 minutes.
• Versioning — /api/v1/, /api/v2/. Without this, API updates break all consumers at once.
• OpenAPI/Swagger — auto-generation of documentation. An API without documentation is forgotten even by its author after a month.

Main Sources of Technical Debt in Bitrix

Technical debt in Bitrix is specific. Three main sources:

1. Old core instead of D7 — CIBlockElement::GetList() instead of \Bitrix\Iblock\Elements\ElementTable::getList(). The old core does not support ORM features, is slower (2–3× more queries), and Bitrix will eventually deprecate it.
2. Direct SQL in component templates — $DB->Query("SELECT...") directly in template.php. Move to service classes, replace with ORM.
3. Business logic in result_modifier.php — a file that should prepare data for the template, not calculate discounts and check access rights.

Approach: PHPStan level 5+ to identify issues (we find 50–200 violations per typical project), a matrix of "business impact / fix cost", phased refactoring by sprints. Not everything at once — but the trend must be downward.

Avoiding Costly Refactoring

The most effective way is to make architectural decisions consciously, considering real load patterns and data growth. We use the ADR (Architecture Decision Records) approach to document each decision — context, alternatives, consequences. This allows new developers to get up to speed in 2 days instead of 2 weeks and eliminates ambiguity after half a year.

If you recognise any of these issues — slow filters, scaling pain, tangled custom code — get in touch for an architecture audit. We'll identify technical debt and propose a migration plan.

Documentation: ADR Instead of Word Files

• ADR — Architecture Decision Records. A short file: context, decision, consequences. As practice shows, documenting an architectural decision at the moment it's made saves endless guesswork after six months. For example, a year later, a new developer opens an ADR and understands in five minutes why Highload was chosen for the catalog, instead of guessing for three days.
• Diagrams — servers, data flows, integration points. PlantUML or Mermaid, stored in the repository next to the code.
• ER diagrams — infoblocks, properties, relationships. Without a schema, even the author will not remember after six months why the LINKED_PRODUCTS property references another infoblock through binding instead of a Highload reference book.
• Runbook — deployment, rollback, scaling, actions during a crash. Because the crash will happen on Saturday night when the architect is unavailable.

How We Design Architecture

1. Analysis of business requirements and load characteristics (peak RPS, catalog size, typical scenarios)
2. Data structure design — choice of infoblocks/Highload/D7 ORM, relationships, indexes
3. Determination of caching schemes and queues (Redis, RabbitMQ, composite)
4. Prototyping and load testing on real data (200K records, 30+ properties)
5. Documentation — ADR, ER diagrams, runbook, API specifications
6. Project review — internal and with the client

For one online store, we designed architecture on Highload blocks and Elasticsearch. Product filtering down to 50ms, time to first byte 0.3s. Hosting cost savings: 45% per month.

Scope of Work

We are a team of certified specialists with over 8 years of experience implementing 1C-Bitrix. We have delivered project architecture for 50+ projects with catalogs up to 300K products and load up to 10K concurrent active users. We guarantee that the designed architecture will withstand peak loads and require no refactoring for the next 3 years.

Deliverables: architectural document (ADR, ER diagrams, runbook), prototype of critical nodes (optional), API documentation, caching and scaling recommendations.

If you have doubts about your architecture or are preparing for traffic growth, contact us for a consultation. We will audit the current structure and propose an optimal strategy. Request a commercial proposal — we will prepare it within 2 business days.