Setting up 1C-Bitrix multisite

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Our competencies:
Development stages

Setting up multi-site functionality in 1C-Bitrix

Multi-site functionality in Bitrix — this is when multiple sites with different content, design, or language run on a single installation (one codebase, one database). Typical case: company main site and separate landing page for promotion, or Russian and English versions of a store. Without multi-site functionality, you have to run separate Bitrix instances — doubling licensing costs, maintenance, and data synchronization.

How multi-site functionality works internally

Each site in Bitrix — is a record in the b_lang table. The LID field (two-character identifier: s1, s2) — is the key by which the system determines which site is requested. Site determination happens in bitrix/modules/main/include/prolog_before.php based on:

  1. Domain nameSERVER_NAME field in site settings
  2. DirectoryDOC_ROOT and DIR fields, if sites are in different folders
  3. Conditions in dbconn.php file (deprecated approach) or via SITE_ID in .settings.php

Content binding to site: iblocks, catalog sections, menu items, templates — everything is bound to LID. One iblock can be available on multiple sites, or on just one.

Step-by-step setup

1. Site creation. Admin panel → Settings → Product settings → Sites. Create a new site:

  • LID — unique two-character code (s2)
  • Name — for identification in admin panel
  • DomainSERVER_NAME, for example promo.example.com
  • Site folder/ if separate domain, or /promo/ if subfolder
  • Template — can assign separate template from /bitrix/templates/ or /local/templates/

2. Web server setup. For separate domain you need a vhost pointing to the same DOCUMENT_ROOT:

server {
    server_name promo.example.com;
    root /home/bitrix/www;  # same root
    # other directives identical to main site
}

3. Iblock binding. In each iblock settings — "Sites" tab. Mark which sites it's available on. Components bitrix:news.list, bitrix:catalog.section automatically filter content by current SITE_ID.

4. Component templates. If different sites need different display of same component — create template with site suffix: .default for s1, promo for s2. In site template specify needed component template.

5. Menu. Menu files (.menu.php) sit in site root or subfolder. With multi-site and different folders — each site automatically takes its own menu. With one root — use bitrix:menu component with MENU_CACHE_TYPE parameter and SITE_ID check.

Common mistakes

One template for two sites with different designs. Don't clutter the template with if ($SITE_ID == 's2') — better create separate template. Conditions multiply, code becomes unreadable.

Cache. Bitrix caches content with SITE_ID binding, but if manually forming cache key in custom components — need to explicitly include SITE_ID in $cacheId. Otherwise user on s2 sees content from s1.

Email. Mail templates (b_event_message) are bound to site. If you created new site but didn't bind mail templates — notifications about orders, registration etc. won't be sent. Check in Settings → Mail events.

Setting up multi-site functionality takes about one working day provided content architecture is already planned — which iblocks are shared, which separate, how many templates are needed.