Setting up multiple websites on a single 1C-Bitrix license

1C-Bitrix Multisite: Where the Shared License Breaks

1C-Bitrix multisite is designed as a standard mode: one license serves several domains, each with its own folder, its own template, and its own section tree.

In practice, things break not at the enablement stage, but at the third or fourth site, when shared settings begin to conflict with site-specific ones. Let's break down exactly where.

The first typical failure is template conflict. Sites share a single set of components, and editing a template for one domain silently changes the output on the others: a developer fixes a block on site A, and on site B the layout falls apart. The second is duplicate rules.

Event handlers, routing rules, and permission settings get registered again for each site, and instead of firing once you get two or three times, and the order in which they run depends on which site was opened first.

The third and most costly is loss of manageability. The single admin panel stops being single: some settings live at the site level, some at the module level, and some are hardcoded in the template code.

Figuring out where what changes can only be done by trial and error, and rolling back one edit drags other sites along with it. This is exactly where 1C-Bitrix multisite turns from a license saving into a constant source of incidents.

We start with an audit: we break the settings down by level, record what is truly shared and what should be isolated, and separate the templates so that editing one site physically cannot affect a neighboring one.

Then come unified rules instead of duplicates and a transparent structure where you can see which domain is governed by what. That way, several sites on one license stay predictable instead of turning into a lottery with every update.

What correct multi-site capability on a single license delivers

Multi-site capability in 1C-Bitrix is built on separating content by site within a single core: shared modules, templates, and handlers exist in a single instance, while content is linked through site binding.

In practice, this means a new site is brought up not by copying the codebase, but by adding a site to the existing structure — with its own domain, template, and access rights, but without a second core and a second license.

A single point of management delivers a direct, measurable effect: core, module, and security rule updates are performed once and propagate to all sites at once.

Previously, with three separate installations, a security patch had to be applied three times, and any forgotten copy remained vulnerable. Now version drift between sites is eliminated technically rather than by policy.

Independent domains retain their autonomy: each site has its own section structure, its own template, its own SEO settings, and separate statistics. A user of one domain does not see the content of another, and rights are delineated at the site level.

This removes the customer's main fear — that the sites will "merge" into one and lose their individuality.

The speed of launching new sections and sites grows through reuse: a standard template, shared components, and configured information blocks are already in place, and all that remains is to bind them to the new domain.

The time to release a site shrinks from weeks to days, while the reduction of duplicates — in code, templates, and settings — eliminates an entire class of errors where an edit in one place fails to reach the other copies.

Organization methods: comparison of approaches

Multi-site in 1C-Bitrix is implemented in three ways, and the choice between them determines not only the license cost but also how you will update, deploy, and separate access permissions.

The difference shows up not at the start, but in the second or third year, when there are more sites and the team is more than one person.

The first option gives maximum savings on the license and a single update point, but any error in the shared code spreads across all sites. The second is a compromise: content and markup are isolated, while the infrastructure is shared.

The third removes coupling entirely, but returns you to N independent projects with N sets of backups and monitoring.

In practice, a hybrid is most often chosen: a shared core for related sites and a separate instance for the site that, due to security or load requirements, cannot be kept alongside the others. Let's break down how to distribute this across the infrastructure without losing manageability.

Implementation order: from audit to handover

Work proceeds in stages, and each ends with an artifact that can be verified: without this, multi-site turns into a set of manual edits that break on the first update. Below is the order in which we run the project, from the initial review to handover to your team.

1. Structure audit. We compile a map of the current sites, domains, sections, and templates: what already lives on a single core, where settings are duplicated, which components are tied to a specific site. The output is a list of bottlenecks and a list of what cannot be migrated without rework.
2. Schema design. We determine how sites are distributed across the core and license, where templates are shared and where they are separate, how permissions and language versions are separated. We lock down the schema on paper before setup begins — this way, contentious points surface at the design stage, not on launch day.
3. Multi-site setup. We bind domains, configure the binding of sites to sections and information blocks, migrate content and templates, and tidy up routing rules and redirects. Every change goes into the configuration, not "by hand in the admin panel," so the result is reproducible.
4. Verification. We run scenarios for each site: login, registration, orders, forms, exchange with 1C, access permissions, behavior when one of the sites is disabled. Separately, we check that shared components do not pull data from another site.
5. Documentation. We describe the schema, bindings, extension points, and the procedure for adding a new site. The document stays with you — it is needed both by your developers and by us on the next engagement.
6. Handover. We show the team how to make edits and what cannot be changed without rebuilding the schema, hand over access credentials, and establish the update regulations.

This order delivers a predictable launch: each stage is verified separately, rather than "everything at once in production." Describe your task — we will come back with an estimate and a plan following these steps.

Access policies, templates, and permissions on each site

Multisite in 1C-Bitrix is built on a shared codebase: one core, one license, but each site has its own domain, its own template, and its own user group.

If permissions and routing are not separated, the administrator of one site sees and edits the neighboring site's content, and editing a template breaks the layout across all projects at once. Let's break down how we close this off at the settings level.

Separation of administrator permissions

We grant permissions not "to the portal" but to a specific site: the administrator role is tied to a site through user groups and module access levels.

A content manager of one project does not get access to another's information blocks and settings — even if both work in the same control panel.

Template isolation and domain routing

Each site gets its own template and resource directory; we move shared components into a separate layer so that editing one site does not affect the others.

We configure routing by domain: the rules determine which site handles a request, where the redirect goes, and how language versions are laid out. This way, changing the structure of one project does not change URLs on neighboring ones.

• Separate user groups and module access levels for each site
• Binding administrator roles to a specific site rather than to the entire installation
• Own template and resource directory for each project
• Shared components in a separate layer — edits do not affect neighboring sites
• Domain-based routing rules: request handling, redirects, language versions
• Protection against mutual influence: an error in one project does not bring down the others
• Separation of access to information blocks, settings, and the media library
• Permission-granting policy: who can change what on each site

We verify the result on a test environment: under different accounts we make sure that access is restricted and routing does not overlap. Such an environment eliminates a whole class of incidents where editing one site takes the others down.

Case study: how one holding company consolidated five websites without increasing licenses

A holding company with five brands came with a typical pain point: each website ran on a separate instance of 1C-Bitrix with its own license, its own core, and its own database.

Security updates had to be run five times, content templates were edited in five admin panels, and rolling out a new section into the header stretched over days. Plus five sets of modules — and as a result, five different versions of the same code.

Everything was migrated to multi-site within a single license: one core, one database, five websites as separate entities with their own domains, templates, and permissions.

Shared modules and settings were moved to the platform level, while brand differences went into templates and content binding. The migration was done in stages, site by site, with redirect verification and preservation of indexing.

Metrics before and after

What this delivered in operations

Management moved into a single panel: permissions are assigned per website, content editors see only their own sections, and development maintains shared code.

Backup and monitoring are configured for one circuit instead of five — recovery after a failure fits into a predictable window rather than a sequential troubleshooting of each instance.

A separate effect is release predictability. Previously, version desynchronization between websites produced different bugs on the same code. Now an update runs once and identically for all brands, and rollback is possible to a shared previous snapshot.

How does multisite differ from separate instances?

Multisite in 1C-Bitrix is a mode where a single product instance serves multiple domains under a shared license, a shared core, and a single admin panel.

Each site, however, gets its own settings: template, section structure, user group permissions, binding to warehouses and currencies in the e-commerce catalog.

There is one core — which means updates, security patches, and edits to shared modules are applied once and immediately to all properties.

Separate instances are independent installations: their own database, their own code, their own update contour.

This scheme is justified when properties must be isolated from each other: different development teams, different release cycles, requirements to keep data on separate servers or in different jurisdictions.

Isolation provides resilience — a failure or an unsuccessful update on one property does not affect the others, and the load can be distributed across different servers without a shared bottleneck.

The key selection criterion is how similar the sites are in logic and how strictly they need to be separated.

If these are branches, regional offices, or brands of one group with a shared catalog and shared users — multisite eliminates duplication: one product catalog, one set of prices, one cart, unified authorization across domains.

An edit in a shared module does not turn into the task of "applying the same thing across five installations and not forgetting any of them."

The flip side of multisite is the shared resource. A heavy query or an error in a custom component on one site affects all of them, and a core update touches the entire contour at once.

That is why, before choosing a scheme, we look at the load profile of each property, the release frequency, the data isolation requirements, and how willing the teams are to coordinate a shared update schedule.

These inputs determine where a single instance is more advantageous and where it is more reasonable to split the sites into separate installations.

What the client receives after setup

Setting up multi-site on a single license is not a one-time configuration tweak, but a set of artifacts that can be used to further operate the system, hand it over to another team, and restore it after a failure. Below is what exactly remains with you as a result of the work.

• Core and module configurations. An export of the working configuration with multi-site settings: binding sites to the license, shared and separate modules, caching settings for each site. The file can be deployed on a test environment and its behavior compared with production.
• Domain routing schemes. A mapping of "domain → site → directory", rules for handling addresses and redirects, entry points for each site. We separately document how routing behaves when a new domain is added.
• Access policies and permission separation. A matrix of roles by site and admin section: who sees the content of which site, who manages users, who has access to shared settings. This removes the risk of an editor of one site accidentally editing another site's data.
• Maintenance regulations. The procedure for updating the core and modules when several sites run on a single license, backup rules for each site, and the sequence of actions in case of failure. The regulation describes what to do before and after an update so as not to bring down all sites at once.
• Instructions for administrators. Step-by-step scenarios for typical tasks: adding a site, migrating between environments, changing a domain, diagnosing module conflicts. Designed for an administrator without deep knowledge of the system's internal structure.
• Backup and recovery scheme. What is backed up and how often, where the copies are stored, and how quickly an individual site can be restored without stopping the others.

The set is handed over in a work-ready form: configurations as files, schemes and matrices in the documentation, regulations and instructions in text form. Describe your task — we will come back with an estimate and a plan for the composition of artifacts for your environment.

Let's discuss your multi-site task

To come back with an estimate and a multi-site plan, we need to understand your current structure: how many sites, on which domains, what each one has of its own, and what is shared — catalog, cart, users, checkout.

This determines whether everything fits into a single 1C-Bitrix license or an extension is required, and how to properly separate content so the sites don't interfere with each other.

Describe the task in free form: which platforms are already running, which ones you plan to add, where content is currently duplicated, and what hurts — speed, updates, separate editor access.

If you have access to the current configuration or a deployment diagram, attach it — this will speed up the analysis and eliminate unnecessary questions.

We will come back with an estimate and a work plan: we'll break multi-site down into stages, show what we move to a shared core and what we keep isolated, and outline the migration order without downtime for the existing sites.

The plan will show which settings are affected, how rights are distributed, and at which stage you can verify the result.

Let's discuss the task concretely — without generic talk about "flexibility" and "scalability." The more specific your input on your site structure, the more accurate the estimate and the fewer edits will have to be made during the process.