On a project with three languages and a catalog of 20,000 products, an incorrectly chosen approach to storing translations turns every update into triple work for the content manager. Errors in hreflang configuration cause Google to show the Russian version to German users, and RTL languages (Arabic, Hebrew) require a complete CSS rewrite. We solve these problems architecturally, not through workarounds.
Which approach to choose: multisite or subdirectories?
Bitrix lacks a built-in 'multilingual' module like WPML or Laravel Translatable. Language versions are implemented through kernel mechanisms.
Multisite via SITE_ID — each language as a separate site: s1 — Russian, s2 — English, s3 — German. Each site gets its own domain or subdomain, its own template, its own language files. Infoblocks are bound to the required sites. This provides complete content isolation and no cache overlap, but requires duplicating infoblocks. Multisite is 30% faster in page loading due to separate caching compared to subdirectories.
Subdirectories — one site, language versions in /en/, /de/. Language detection via the first segment of the URL. One infoblock with additional properties for each language: NAME_EN, DETAIL_TEXT_EN, etc. The advantage is a single product management point. The downside is property bloat: with 5 languages, each text field multiplies by 5, and components need customization.
In practice, for commercial projects, multisite often works better — it is architecturally cleaner, although more expensive to set up.
Why hreflang is mandatory for a multilingual site?
Without hreflang, Google may show the Russian version to German users. According to Wikipedia, this attribute tells the search engine which language version to use. Implementation:
<link rel="alternate" hreflang="ru" href="https://company.com/catalog/product/" />
<link rel="alternate" hreflang="en" href="https://company.com/en/catalog/product/" />
<link rel="alternate" hreflang="de" href="https://company.com/de/catalog/product/" />
<link rel="alternate" hreflang="x-default" href="https://company.com/catalog/product/" />
Bitrix does not have built-in hreflang. We add it via header.php or the OnEndBufferContent handler. The key difficulty is matching URLs of different languages. If URLs are generated from symbolic codes, the codes must be transliterated into each language. Matching is done through a common ID or a binding property.
Content translation: manual, automatic, hybrid
Manual translation — high quality, low speed. For a catalog of 20,000 products with 5 fields and 3 languages — 300,000 translation units. A professional translator processes 2–3 thousand words per day, and the total cost depends on scope. In contrast, machine translation is significantly more affordable for large volumes.
Machine translation — Google Translate API, DeepL API. We integrate into the admin panel: a 'Translate' button when creating an element. Quality is sufficient for technical descriptions.
Pitfalls:
- Terminology — need a glossary with exceptions.
- HTML markup — parse and translate only text nodes.
- API limits — Google Translate charges per character. A catalog of 50,000 products with descriptions — 10–50M characters. Calculate in advance.
- SEO quality — only manual translation for landing pages.
Hybrid approach — machine translation for product cards, manual for strategic pages. Works in 80% of projects and reduces costs by up to 40% compared to fully manual.
How to implement RTL for Arabic and Hebrew?
If Arabic or Hebrew are among the target languages, this is a separate layer of work.
- Attribute
dir="rtl" on <html> — toggle based on LANGUAGE_ID.
- CSS — use
logical properties instead of margin-left/margin-right.
- Fonts — Arabic typography requires its own fonts.
- Numbers, dates, currencies — need formatting.
Bitrix does not support RTL out of the box. Solution: a separate CSS theme for RTL languages, loaded by LANGUAGE_ID, or a PostCSS plugin that generates mirror CSS.
What is included in the work
We are a certified Bitrix partner with over 30 completed multilingual site development projects on 1C-Bitrix. Our deliverables include:
- Analysis of target languages and markets (3–5 days).
- Selection of architecture: multisite or subdirectories (2–3 days).
- Infrastructure setup: creating sites/subdirectories, language files, routing (1–2 weeks).
- Template adaptation: interface localization, hreflang, language switcher, RTL if needed (2–4 weeks).
- Content translation: translator API integration, manual proofreading (2–8 weeks).
- SEO audit: check hreflang, canonical, sitemap for each language (3–5 days).
- Handover of documentation and training for content managers, plus ongoing support after launch.
Example of hreflang implementation in OnEndBufferContent
// handler in init.php
AddEventHandler("main", "OnEndBufferContent", "addHreflang");
function addHreflang(&$content) {
if (defined('SITE_ID') && SITE_ID == 's1') {
$tags = '<link rel="alternate" hreflang="en" href="https://en.company.com'.$_SERVER['REQUEST_URI'].'" />';
$content = str_replace('</head>', $tags.'</head>', $content);
}
}
Comparison of URL approaches
Subdomains (en.company.com) provide clear separation and separate analytics, but each subdomain is considered a new site by search engines, requiring its own link mass. Subdirectories (company.com/en/) preserve SEO weight due to the common domain, but routing in Bitrix is more complex (requires urlrewrite.php). Separate domains (company.de) offer maximum geo-targeting, but site management becomes more complicated.
Estimated timelines
| Scale |
Timeline |
| 2 languages, corporate site up to 50 pages |
4–8 weeks |
| 3–5 languages, catalog up to 10,000 products |
8–14 weeks |
| 5+ languages, e-commerce with 1C integration, RTL |
14–24 weeks |
The cost is calculated individually after analyzing the content volume, number of languages, and chosen translation strategy. Contact us for a consultation — we will assess your project and offer an optimal solution. Order multilingual site development on 1C-Bitrix today.
How to properly design infoblocks?
When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.
Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.
Why 1C-Bitrix outperforms most CMS for business
The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.
What highload blocks are and how they speed up the catalog
Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.
From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.
What integrations are critical for 1C-Bitrix stores
Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.
What's included in 1C-Bitrix website development
Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.
- Technical specification – user stories, infoblock diagrams, integration schemas.
- Source code in Git – with commit history, release tags, branching rules.
- Administrative documentation – description of custom components, deployment instructions, list of agents and events.
- Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
- Access to staging during development – test before production deployment.
- Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).
Our process and technologies
| Project type |
Timeline |
Complexity |
Key features |
| Corporate website |
from 1 month |
Medium |
Catalog, news, forms, CRM integration |
| Online store |
from 2 months |
High |
54-FZ, marketplaces, 1C exchange, SKU |
| B2B portal |
from 3 months |
Very high |
Personal prices, document flow, Bizproc |
| Landing page |
from 2 weeks |
Low |
LCP < 2s, composite cache, static |
| Multisite structure |
from 1.5 months |
High |
Separate content, shared catalog, hreflang |
Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.
Process:
-
Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
-
Design – UI/UX with design system. Components are reusable.
-
Development – write components with custom templates in
local/templates/. Business logic in local/modules/.
-
Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
-
Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.
Multilingual support and redesign
Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.
Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.
Guarantee and support
We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.
