Building a multisite structure on 1C-Bitrix is the only sensible solution when a client launches a second brand. Double license, double exchange with 1C, double admin panel. A month later it turns out: the product base is shared, managers are in different admin panels, stock sync breaks. We have been designing multisite architectures for over 10 years — certified Bitrix partners with more than 100 successful projects — and know all the pitfalls: from cache leaks to incorrect sitemaps. Contact us for a consultation — we will assess your project in 2 days.
When is multisite justified?
A holding with five brands. A franchise with regional offices. A group of companies where each direction has its own domain but a shared product base. The alternative is five separate Bitrix installations, five licenses, five servers, five exchanges with 1C. Multisite on one installation — one server, one license (starting from the "Business" edition), one admin panel. License and support savings reach 30–50% (e.g., $3,000 per year saved per installation). Shared database reduces license costs by 50% compared to separate installations.
Not justified — when sites have no data, audience, or business logic overlap. Then binding through one database only complicates deployment and increases the blast radius in case of failure.
Architecture: shared database vs. separate
Bitrix supports two multisite modes.
Shared database, shared files
All sites live in one MySQL database and one filesystem. Separation is via SITE_ID in tables. An infoblock can be attached to multiple sites through b_iblock_site. A user registered on site A is automatically authorized on site B (shared b_user table, shared sessions).
Pitfalls:
-
Component cache — if SITE_ID is not specified in the cache key, a news.list component on site B will return data cached for site A. Standard Bitrix components usually account for SITE_ID, but custom ones do not until you add
$this->arParams['CACHE_GROUPS']and include SITE_ID ingetAdditionalCacheID(). With 5 sites sharing a catalog of 50,000 items, the time for full cache refresh is reduced by 60% if keys are configured correctly. - Access rights — user groups are shared. A content manager of site A might accidentally edit an infoblock of site B if a permission matrix is not set at the infoblock level.
- SEO module — sitemap.xml is generated via seo.sitemap.run. You need to create a separate map for each SITE_ID, otherwise URLs from site B will appear in the sitemap of site A.
Separate databases
Configured via .settings.php, connections section. Each site connects to its own database. Full data isolation, but no shared users or shared infoblocks. Rarely used — mainly for complete separation when a shared admin panel is only needed for server infrastructure management.
How to solve the shared cache problem?
In a multisite structure, cache is the main headache. Without binding to SITE_ID, one site may display data from another. The solution is at the developer level: in result_modifier.php, add SITE_ID to the cache key via $arParams['CACHE_GROUPS'] and CPHPCache::SetCache(). For composite cache, configure a separate domain in the "Composite Site" module. This ensures that the HTML snapshot of site A is not served on domain B.
More about cookie mechanisms — Wikipedia.
Shared user base
The main advantage of a shared database is unified authentication. A user registers on brand-a.com, visits brand-b.com — already authorized. This works via the shared b_user table and shared sessions.
But there is a catch. Sessions are stored in files by default — in /bitrix/sessions/. With two domains, the PHPSESSID cookie is not transferred between them (different domains, different cookies). Solutions:
- SSO via token — we pass a one-time token in the URL when switching between domains, and on the receiving side we create a session. The socialservices module or custom handler.
- Common top-level domain — .company.com, the cookie is set on .company.com, works for a.company.com and b.company.com.
- Redis for sessions — sessions are stored centrally, but the cookie problem remains. Redis solves a different task — horizontal scaling, not cross-domain authentication.
Content: what to share, what to separate
Infoblocks are attached to sites via admin settings. One infoblock can be accessible on several sites. A typical scenario: a product catalog — shared (SITE_ID: s1, s2, s3), news — each site has its own.
An important point: infoblock properties are shared. You cannot add a "Promotion" property only for site A if the infoblock is attached to sites A, B, C. All three sites will see this property. Solution — use a multiple property of type "Binding to site" and filter in the component.
Trade catalog. The catalog module allows setting different price types for different sites. A wholesale site shows wholesale prices, retail site shows retail ones. Stock balances are shared or separated via binding to stores (b_catalog_store).
SEO settings — META templates through iblock.type.edit are set at the infoblock level, not site level. For different sites with one infoblock, you'll need to generate META programmatically in result_modifier.php, substituting the required values by SITE_ID.
Common issues when scaling
- 1C exchange — the catalog.import.1c module imports products into infoblocks. If the catalog is shared across three sites, there is one import. If each site has its own catalog — three separate exchanges, three profiles in 1C. With 50K+ items, each exchange locks tables for 15–30 minutes. We spread them across cron to avoid overlaps.
- Search — the built-in search.title indexes all sites into one b_search_content table. Results are filtered by SITE_ID, but the index is shared. With 5 sites of 100K pages each — an index of half a million records, reindexing takes hours. Elasticsearch instead of the built-in search — if data volume is substantial.
- Composite cache — the composite module works correctly with multisite but requires separate configuration for each domain. Without it, the HTML snapshot of site A might be served on domain B.
What is included in multisite development (Deliverables)
- Audit of current infrastructure and integrations.
- Architecture design: site matrix, infoblocks, access rights, templates.
- Core configuration: site creation, domain binding, session and cache settings.
- Template development: shared base template + individual site templates.
- Content migration and SEO module configuration for each domain.
- 1C exchange setup (if required).
- Testing cross-site scenarios: authentication, cache, sitemap.
- Training editors to work in a unified admin panel.
- Post-launch monitoring.
- Documentation and access credentials.
How to compare shared database vs. separate?
Shared database is 2 times cheaper in licenses and easier to maintain; separate ones are faster under peak loads and isolate failures. The choice depends on SLA and budget: for most projects, a shared database with proper caching is sufficient.
Indicative timelines
| Scale | Timelines |
|---|---|
| 2-3 sites, shared catalog, different templates | 6-10 weeks |
| 5+ sites, separate catalogs, SSO | 10-16 weeks |
| Regional network of 10+ sites with 1C integration | 14-24 weeks |
Pricing is calculated individually after detailed analysis — we will assess your project in 2 days.
Typical challenges and their solutions
| Problem | Solution |
|---|---|
| Cache from one site leaks into another | Add SITE_ID to component cache key |
| Authentication does not work between domains | SSO via one-time token or common cookie domain |
| SEO module generates sitemap with foreign URLs | Create separate map for each SITE_ID |
| 1C import locks tables | Spread imports across cron and use different profiles |
Our services include 1C-Bitrix multisite development, Bitrix multisite architecture, shared catalog for multiple sites, unified authentication with SSO, multisite templates, 1C exchange for multisite, Bitrix cache configuration, and project assessment. With over 10 years of experience and more than 100 successful Bitrix multisite projects, we are certified partners. Contact us for assessment of your project. Get a consultation — we will select the optimal architecture without overpayments.