Multi-Brand Storefront Development on 1C-Bitrix
A multi-brand storefront is a shop where several brands are presented as separate "mini-shops" within a single platform. The buyer sees a Nike section, an Adidas section, a Puma section — each with its own visual style, its own banners, and its own navigation. But the cart, checkout, and user account are shared. These are not simply catalogue categories; they are separate spaces within a single site.
Data Storage Architecture
The multi-brand storefront catalogue is built on the Bitrix catalogue info block with a section hierarchy. Structure:
b_iblock_section (catalogue)
├── BRAND_ID: 1 (Nike)
│ ├── Sneakers
│ ├── Clothing
│ └── Accessories
├── BRAND_ID: 2 (Adidas)
│ ├── Sneakers
│ └── Clothing
A brand is the top-level section or a separate brands info block linked to products. The second option is more flexible: one "Brands" info block contains brand metadata (logo, colours, description, banners), while each product in the catalogue info block has a BRAND_ID property of type "Element".
"Brands" info block (IBLOCK_BRANDS):
-
LOGO— SVG or PNG logo -
BANNER_DESKTOP,BANNER_MOBILE— brand section banners -
PRIMARY_COLOR,ACCENT_COLOR— colours for CSS variables -
DESCRIPTION— brand history -
BRAND_URL— official website -
OFFICIAL_DEALER— authorised dealer status (flag)
Dynamic Section Branding
When a user opens a brand section, the template changes colours, the header, and the banner. This is implemented via CSS variables generated by PHP and injected into <head>:
// In the brand section's template.php
$brandId = $arResult['SECTION']['UF_BRAND_ID']; // custom section field
$brand = BrandTable::getByPrimary($brandId)->fetch();
if ($brand) {
$APPLICATION->SetAdditionalCSS('
:root {
--brand-primary: ' . htmlspecialchars($brand['PRIMARY_COLOR']) . ';
--brand-accent: ' . htmlspecialchars($brand['ACCENT_COLOR']) . ';
}
');
}
The brand logo in the section page header replaces the main site logo. In other sections the regular logo is shown. This is done via a global variable in the template:
// In the template's header.php
global $currentBrand;
echo $currentBrand
? '<img src="' . $currentBrand['LOGO_URL'] . '" alt="' . $currentBrand['NAME'] . '">'
: '<img src="/local/templates/main/img/logo.svg" alt="Store">';
Filtering and Navigation by Brand
Inside a brand section, the catalogue filter works only within that brand's products. The standard smart filter component bitrix:catalog.smart.filter must be parameterised:
$APPLICATION->IncludeComponent('bitrix:catalog.smart.filter', '', [
'IBLOCK_ID' => CATALOG_IBLOCK_ID,
'SECTION_ID' => $brandSectionId, // root section of the brand
'DEPTH_LEVEL' => 5, // nested sub-sections of the brand
'HIDE_NOT_SELECTED' => 'Y',
// ...
]);
The smart filter calculates available values (b_catalog_smart_filter) only for products in the specified section — this works correctly out of the box.
Breadcrumbs show the path: "Home → Nike → Sneakers". The bitrix:breadcrumb component works automatically with the correct section structure.
Brand Page: Landing + Catalogue
A brand page is not just a product listing. It is a storefront with: a brand banner, brand history, key collections, new arrivals, and bestsellers.
Brand page composition via $APPLICATION->IncludeComponent():
// brand.php — separate page template
IncludeComponent('custom:brand.page', '', ['BRAND_ID' => $brandId]);
// Inside the component:
// - Brand banner
// - "About the brand" block from DESCRIPTION
// - catalog.section component with product listing
// - New arrivals block (filter by date added)
// - Bestsellers block (filter by sales count)
Cross-Brand Product Comparison
The standard comparison component bitrix:catalog.compare.buy works within a single info block. For a multi-brand storefront, comparison must work across brands for similar characteristics (e.g., Nike vs Adidas vs Puma sneakers).
This is technically achievable: the comparison list is stored in the session, characteristics come from info block properties. The challenge — different brands may have different sets of characteristics. Solution: a fixed set of "common" properties for comparison (upper material, sole type, last type), with unique properties per brand shown separately.
Managing Content in Brand Sections
If each brand has its own manager, access must be restricted:
// The "Nike Brand Manager" group has access only to elements with BRAND_ID = 1
// Configured via info block access permissions at the section level
CIBlock::SetPermission(CATALOG_IBLOCK_ID, $nikeSectionId, $nikeManagerGroupId, 'W');
Bitrix's standard access control allows granting access at the info block section level — a Nike manager sees and edits only products in the Nike section.
Analytics by Brand
Storefront owners need a breakdown of sales and traffic by brand:
-
Traffic: page events by brand are sent to Yandex.Metrica via
dataLayerwith abrand_idparameter -
Sales: the
BRAND_IDfield is written to order item properties (b_sale_order_props), aggregated via SQL - Conversion: brand-level funnel in a BI tool (ClickHouse + Metabase or Power BI)
SEO for the Multi-Brand Storefront
Each brand is a potential search entry point. A brand page should be optimised for queries like "buy Nike in London":
- SEO description for the brand section in
b_iblock_section.DESCRIPTION - Individual
META_TITLEandMETA_DESCRIPTIONfor the brand page -
BreadcrumbListSchema.org markup - Canonical to the brand page when filtering
Timelines
| Scale | What's included | Timeline |
|---|---|---|
| 3–5 brands, basic branding | Section structure, brand pages, filter | 3–5 weeks |
| 5–20 brands | + dynamic colours, brand manager dashboard, analytics | 6–10 weeks |
| 20+ brands, marketplace | + partner cabinet, financial calculation, API | 12–20 weeks |
A multi-brand storefront complicates the catalogue but creates a competitive advantage: buyers come not for a specific product, but to a "place" where they compare several brands of the same product type.