Setting up Bitrix24: why sites break after launch
Publishing a site on the portal is not the final point, but the beginning of operation. By Bitrix24 site setup we mean the rules that start working after migration: template binding, access rights to sections, approval procedure, and behavior under load. While they are absent, the site holds until the first content edit or the first traffic spike.
Mismatched templates are the most common mistake at site launch. A landing page assembled in the page builder picks up the portal design after migration: headings change size, margins collapse, buttons lose color.
The cause is theme inheritance — some styles sit in page settings, some in the common site template.
Access rights to sections during migration are set to “everything” — it is faster to launch. Then the editor changes the section structure and publishes bypassing approval, and a draft ends up on the live page. The right to edit layout goes along with content rights.
Peak load finishes off what did not fall on the test environment. A page with many blocks and dynamic queries takes longer to assemble on live traffic, the cache is not warmed — the portal returns an error instead of the catalog.
All four classes of failures lie in setup, not in page markup — we break down how this is closed.
What a managed portal gives: speed, roles, stability
A managed portal begins when content edits stop being slowed by the release cycle. A department editor changes text or a block directly in the interface — publication takes minutes instead of days waiting for a deployment window. The developer queue is removed: a heading on a page is changed without a release.
Department access separation closes the class of “editing outside your area” problems. Roles are configured by sections and block types: the editor sees only their own pages, the department head approves, the administrator manages the structure. The change log turns incident investigation into a matter of minutes.
Load resilience rests on architecture, not heroic efforts. Server caching and delivery of prepared pages handle peak traffic: during a campaign, response time remains within the usual limits, and a targeted cache reset updates only the changed section.
Downtime reduction is a policy: scheduled backups, regular recovery testing on the test environment, on-call availability monitoring. Recovery after a failure fits within tens of minutes, and the share of support requests for routine edits falls — editors close them themselves.
This is the portal acceptance checklist: edit publication time, recovery speed, share of changes closed without a developer, and the eliminated class of failures due to edits outside the area of responsibility. Each item is testable on the test environment before launch.
Sites on the builder and custom templates: comparison of approaches
The deployment option determines who can change pages after launch and how quickly. The page builder inside the portal gives edits to the marketer, but limits the structure to a set of ready blocks.
Custom layout and a separate site outside the portal remove these limits, but add a development cycle and a separate update environment.
In practice, the options rarely compete directly: landing pages for campaigns are assembled in the builder, while the corporate section with a catalog and 1C exchange is kept on a custom template.
The comparison below is about how many edits the customer will close themselves and what remains on support.
Real deployment options
| Option | When suitable | Limitations |
|---|---|---|
| Page builder in the portal | Fast landing pages, campaign landings, offer testing | Structure limited by builder blocks; non-standard forms and logic require code inserts |
| Ready template with adaptation | Corporate site on a typical structure, launch in a tight timeframe | Inherits someone else's markup and extra scripts; deep design rework runs into the template |
| Custom template on the portal | Unique design, 1C integration, personal accounts and roles | Longer launch; some content edits go through the developer |
| Site outside the portal | Public resource with high requirements for load and indexing | Two update environments and shared authorization — more expensive to maintain |
Transition between options is not one-way: pages assembled in the builder are moved to a custom template later. To prevent this from becoming rework, at the start we fix the rules for URLs, headings, and data structure — otherwise migration runs into manual markup.
Implementation procedure: from audit to handover to the team
Implementation of Bitrix24 sites follows one route: first we fix the current portal state and scope of work, then assemble the structure and roles, and only after that enable publication.
The order is fundamental — setting rights and moving content on a live portal almost always cause section divergence and lost pages, and rolling this back is more expensive than doing it sequentially.
- Portal audit. Collect a map of existing sections, pages, templates, and access rights. Note what we reuse, what we rewrite, and where new entities are needed.
- Sections and roles scheme. Design the section tree, page types, templates, and access matrix: who edits, who publishes, who only reads.
- Publication setup. Bind templates to sections, define draft and publication rules, and restrict authors to their area of responsibility.
- Scenario testing. Run typical paths on the test environment: page creation, approval, publication, version rollback, moving to another section. Catch rights and template errors before migration.
- Content migration. Move pages and files preserving URLs and links, and configure redirects for changed paths.
- Acceptance. Compare the result with the sections scheme and check access under each role. Record discrepancies and close them before handover.
- Handover to the team. Train editors and administrators, provide the publication policy and a contact point for questions.
After handover, the team has a working scheme, not a set of disparate settings: a new section is added by a clear rule, not by rebuilding the portal.
Policies, roles and schemes: what remains in your hands
Setup is considered complete when the portal can be run without us. Therefore handover includes not a set of screenshots, but documentation tied to real portal objects: templates, sections, user groups.
Using it, your team publishes materials themselves, grants access to new employees, and restores operation after a failure.
What remains in your hands:
- Template and section scheme: which template is assigned to which section, where common blocks are — editing the header does not break the layout of already published pages.
- Role matrix: author, editor, publisher, administrator — tied to sections and groups, not “full access to everyone”.
- Access policies: rights to files, the media library, and information blocks; separately — who is allowed data export and form download.
- Publication policy: route “draft → review → publication”, who unpublishes a page, and how to roll back to the previous version.
- Page acceptance checklist: responsiveness, forms and their recipients, broken links, metadata, mobile speed.
- Instructions for editors: step-by-step materials on real portal screens and analysis of typical errors — accidental edit of a common block, loss of template binding.
- Portal documentation: map of sites and sections, domain binding, metadata settings, backup schedule, and recovery procedure.
- Change log with responsible persons: visible who and when changed structure, rights, or template.
The final step — your team performs the first publication independently, and the engineer on call resolves controversial points.
Case: the portal stopped breaking on content edits
What was
The portal on Bitrix24 grew spontaneously: pages were assembled in the builder, but half of the blocks were edited manually in templates.
Editing one page took 40-60 minutes and required a developer — the content manager changed text, touched markup, and broke the layout of neighboring blocks.
Per month, 3-4 failures accumulated after content updates, each from half an hour of downtime, plus 18-22 support requests, two thirds of which were about the same thing.
What changed
As part of Bitrix24 setup, sites were divided into two independent environments: content lives in the visual editor with a fixed set of blocks, templates and markup are the developer area, closed by rights.
Before publication, preview and page backup are mandatory, so a failed edit is rolled back in a minute, not by rebuilding the section. Assembly of typical pages was moved to repeatable templates: a new section page is assembled from ready blocks without code edits.
What became
- page edit time: 40-60 minutes → 5-7 minutes by the content manager, without developer involvement;
- downtime during updates: 3-4 failures per month → none in a quarter of observations, because content physically does not intersect with templates;
- support requests: 18-22 per month → 2-3, and those about new tasks, not breakages.
The result rests not on editors' accuracy, but on access separation and predictable templates — so it does not roll back when the person responsible for content changes.
What to do if the portal is already deployed and in use
A live portal does not need to be stopped to restructure. Sections and rights are migrated in layers: a new section is prepared in closed form, filled and tested on a narrow group of employees, then opened to others.
On Bitrix24.Sites, node structure is separated from content, so such migration does not affect the work of departments that continue using current sections.
First we take a map of URLs and transitions: which links live in search, internal documents, emails, and employee bookmarks. Then staged migration goes ahead — one section per approach.
Materials are copied to the new branch, rights are configured anew, and the old branch remains working until switchover. If a section has forms, approvals, and related business processes, they are checked before opening access.
URL preservation is solved by permanent redirects: each old URL gets a rule to the new one, including nested pages and pagination. Thus search results do not lose positions, and employees do not hit broken links in their bookmarks.
We keep redirect rules in the portal configuration, not manual edits — for the next restructuring of sections, they are reused.
Access rights are migrated together with the structure: department groups, inheritance from the parent section, roles for creation and publication.
Switchover is done during non-working hours or pointwise by department, so no one is left in the middle of a task without their section.
The previous structure is preserved until confirmation from responsible persons — rollback takes minutes and does not require recovery from backup.
From you we need portal administrator access, a list of responsible persons by department, and an understanding of which URLs are critical for search. Describe the task — we will return with an estimate and migration plan.
Technical questions: rights, publication, migration
Setup of Bitrix24.Sites rarely runs into layout. The main questions surface during handover of the system to operation: who manages what, how edits are approved, and what will happen to accumulated content. Below are engineering answers to four doubts that most often slow launch.
How to separate department rights?
Rights are issued to user groups and tied to sections and content types, not to people. Marketing edits only its landing pages, and the sales department cannot unpublish the corporate section. Employee departure is closed by changing the group — no need to sort personal permissions.
How is publication approval arranged?
The draft lives outside the public zone, the editor sends it for review to the responsible person, and only after confirmation does the page appear in the section.
Version history stores previous revisions — a controversial edit is rolled back pointwise, without restoring the entire site.
What about backups?
Copies are taken on schedule and uploaded to external storage, not stored on the same server. The retention rule keeps several latest snapshots, and once a quarter we deploy a copy on the test environment: an unchecked copy is a hypothesis, not protection.
Can existing pages be migrated?
Yes. We migrate by structure: URLs, nesting, meta tags, attachments. We set redirects to old URLs so accumulated positions do not burn. Bulk content goes through exchange; manually we reassemble only unique templates and forms.
Let's discuss the task and return with an estimate and plan
To make the estimate substantive, not “by feel”, we start with task analysis: which sections and templates are needed, who will run content, and what rights employees and contractors have.
One meeting is enough — after it, the scope of setup and what is already ready on the platform side is visible.
Then we proceed step by step, and each ends with a clear result:
- Task and current state analysis: which pages, forms, and roles are needed, what is already configured in Bitrix24, and what needs to be assembled from scratch.
- Scope approval: fix what is included in site setup and what remains with your team or other contractors.
- Estimate and work plan: timeline by stages, order of section rollout, and points where your approval is needed.
- Access and test environment: deploy a copy on a separate environment so edits do not affect the working site.
- Implementation stages: structure and templates, then request forms, data exchange with the accounting system, and content migration.
- Acceptance and handover: check scenarios, fix rights settings, and show your team how to run the site independently.
Describe the task in two or three paragraphs — we will return with an estimate, stage plan, and timeline.